October 2012 IT Business Consulting Newsletter

Registry Edits Can Kill Your Server!

By Tom K

Every Windows server has a “Registry”, a place where essentially all of the server’s configuration settings are stored. If the Registry is edited improperly and gets even a little messed up, the results can be bad to devastating. You can lose applications, core server functionality, even the whole server. One small “oops” and email or your core business application can be gone!

I recently helped a client through this trauma, and it was ugly... so I’m bumping the scheduled topic to give you this heads-up. In this month’s newsletter I discuss the Registry in general, present methods and pointers on how to properly edit the Registry (if you really have to), how to reduce the chances of catastrophe, and a few possible methods to recover from catastrophe.

What is this “Registry” thing?

The Registry is a centralized place on a Windows server where almost all the configuration settings and options are stored. The data is actually disbursed on the server, but the Registry is most easily visualized as a single hierarchical database. Essentially every setting the server needs to run itself, the services it provides, and the applications that are installed on it, are located in the Registry. I say essentially, as there are still a few applications that store their settings in .ini files, and some use .xml files, but most everything is now in the Registry.

The Registry is made up of Keys that hold Values (think database fields and data). There are seven “Root Keys”, each holding thousands of sub keys.

While this article focuses on servers, note that every Windows device has a Registry. If you do need to edit a PC’s Registry, everything that follows still applies.

Means to Edit the Registry

Any time you change a configuration setting on your server, you are typically editing the Registry. Thus, there are several things that will edit the Registry:

  • Making a change to the physical hardware or drivers
  • Changing an option in a Windows Server service or function
  • Changing an option in an application
  • Using any Wizard in Windows usually affects the Registry
  • Creating or making changes to a Group Policy
  • Adding a Program or a server function will add a whole section to the Registry
  • Removinging a Program or a server function will remove a whole section

The edits caused by these examples are automatic. The applications and wizards and config screens will automatically write the changes to the Registry, and this is usually quite safe.

There are, however, instances when there is no automated means to make a needed change, so the Registry needs to be edited manually. This is where you can run into trouble. The predominant means to manually edit the Registry is via a Registry Editor. If you are comfortable as a programmer, you can also edit via the command line (CMD window) and PowerShell scripts.

Microsoft provides Registry Editors with all their current products. Depending on your Operating System and machine type (32 or 64 bit), you can edit with Regedit.exe or Regedt32.exe. To launch one, just type it into Run or Search in the Start menu.

Why Might You Need to Manually Edit the Registry?

As mentioned, most Registry editing is done automatically under the hood. So why do we need to manually make changes in this very dangerous place?

One thing seen quite often is the result of a virus. The virus loads Registry keys for itself just like any program install would, so a proper virus removal process will automatically remove the viral traces from the Registry. However, many viruses will alter Registry keys not directly related to the virus to protect itself, like dismantling anti-virus apps and Windows Updates routines. These altered (or removed) keys need to be manually restored.

Another often seen issue is a poorly written program uninstaller. The uninstaller will miss something critical that can affect the server. I’ve also seen program upgrade routines that require manual Registry editing steps. (This is what burned my client).

You’ll often be required to edit the Registry when working with a software support tech, or via a support or upgrade instruction document. If you are researching an issue on the web, you’ll often be advised to edit the Registry. In all cases, be VERY careful. As mentioned, this can kill your server, or any of its most important functions.

In my client’s case, while following an upgrade document provided by the vendor’s support staff, they replaced a critical key value set with a single value needed by the application. The instructions should have indicated APPEND rather than REPLACE. Email was affected for about 24 hours.

Get Help!

If you believe you need to make changes to your Registry, I’d suggest that you get a little help. Server engineers work in the Registry all the time. It is a familiar place for us and, most often, the edit or set of edits is a pretty quick process for us.

If you do access the Registry via an editor, feel comfortable with what you see, and decide to proceed...

Back Up the Registry!!!

PLEASE, before you make ANY changes, back up the Registry. This is a very simple process, and can save you hours of downtime if you mis-configure an important key or value.

You can back up the whole Registry, a Root Key and all its sub-keys, a single branch if you are working in a limited area, or even a single key. I prefer to be pretty specific in what I backup, as it is easier to restore a little piece than a large chunk. Generally, edits will occur in a single branch or occasionally in two related branches, so I like to back up branches.

When the editor is open, select the first branch of interest and go to the File menu -> Export, select where you want to save it, and name it. It will be saved as a .reg file. That’s it! If you have other areas that you will be editing, export them as well.

When All Else Fails...

So, if you forgot to back up the Registry and you make a mistake, there are a few things that can be done.

In my client’s case, we determined what keys were compromised using the error codes from the application error logs, and then reverse engineered the values.

Your nightly server backups should be backing up the server System State that contains the Registry. This could be a viable solution if you have a backup that has a copy of the Registry in the state you need it – before the troublesome edit was made, but after any good edits were made.

You can re-boot the server using the “Last Known Good” option, via the Safe Mode F8 boot option. This sometimes works, and sometimes doesn’t. It will restore all settings to what their state was during the last re-boot. If the re-boot was a long time ago, all recent changes to your server, system, and Registry will be lost. I, therefore, try to avoid this. Also, if you rebooted after the bad edits, those bad edits are now part of the “Last Known Good” config.

You can try a System Restore if this is set up on your server and you have a good Restore Point, preferably just before the errant edits. Note that any changes that were made to the system after the selected Restore Point will be lost, i.e. application installs, configuration edits, system updates, etc.

If you ever find yourself at a point where you are contemplating one of these options, I strongly suggest you get help. Using these tools to recover from a serious system issue is neither easy nor clean and, as with many Microsoft tools, sometimes they work and sometimes they don’t.

As ever, if you need help with your Registry or have any questions or comments concerning this article, I’d be happy to discuss this with you at your convenience. Feel free to contact me at TomK@TomKConsulting.com, or via my cell 443.310.5110.

Next month I’ll get back to the scheduled security discussion with a look at the hows and whys of Security Audits. See "IT Security Audits"