Quis custodiet ipsos custodes
Who shall keep watch over the guardians?
Some may think I write about this subject (example) too often, but frankly, I don't think I write about it often enough:
Your server (or workstation) machine is important. Having it not boot up properly or operate normally can often mean serious loss of income. That's real hard-earned dollars that you CANNOT GET BACK. So why is it that so many Admins don't have a reliable backup and recovery strategy? Maybe we just think "it can't happen to me". Or maybe we're just plain stubborn and dumb!
The single most important ingredient of a recovery strategy is the ability to restore a known good Registry. Registry corruption often occurs when the machine is shutting down as OS changes are being written to the Registry. It can also occur if there is a network (TCP) glitch or a power glitch. The bottom line is this:
NOBODY IS IMMUNE TO REGISTRY CORRUPTION! NOBODY!
Registry corruption and its companion demon, system file corruption, can occur AT ANY TIME. Just because you've been lucky so far doesn't mean you are in the clear. Unfortunately, the typical configuration of a Windows Server 2003 or Windows Server 2008 machine does not make recovery of the Registry easy, and if you don't have the tools you need to get "back to first base", your ass is TOAST!
Windows NT-based operating systems automatically create a backup of each Registry hive (.BAK) in the %Windir%\System32\config folder. Any file can be restored from the Recovery Console. The Recovery Console can be invoked by booting off the original OS CD Rom or DVD Rom, or (if you have installed it) you can invoke it from the OS Boot menu.
On Windows NT-based systems, the Last Known Good Configuration option in startup menu relinks the HKLM\SYSTEM\CurrentControlSet key, which stores hardware and device driver information. However, these options are not always sufficient to completely recover a system. Often you may have a machine that either will not boot at all, or if it does, major portions of the operating system are rendered unusable because of a corrupted Registry. In these cases, you really want to have a "PE" (pre-installation) subset of the OS you can boot into. Bart's PE is the answer:
Although Windows Backup can back up the Registry, it only does so with a lot of extra baggage and is not fun to use at all. Needless to say, if you cannot boot into a GUI or your GUI environment is unusable due to Registry corruption, you may not be able to recover with Windows Backup at all.
If you use Backup to back up your system state, it also copies your existing registry hive files to the %SystemRoot%\Repair folder. This means you can restore your corrupted or missing registry hives by logging on with the Recovery Console and copying the files from %SystemRoot%\Repair to %SystemRoot%\System32\config.
A much better and easier to use solution doesn't come from Microsoft -- it is Lars Hederer's ERUNT. ERUNT, in it's default installation, will automatically save a complete copy of your Registry when the machine is successfully booted, in a folder called C:\Windows\ERDNT\Autobackup. These backups are created in subfolders with the current date, and ERUNT also places a recovery executable, ERDNT.EXE, which can be used to restore that registry backup. Double-click on this, and reboot, and you're all fixed. You can also run this from a Recovery Console prompt or a Bart PE command prompt. ERUNT runs on all Windows OS's, both 32 and 64-bit, and it's saved my butt more times than I care to admit.
If you do not have ERDNT installed, you can look for backup files in the \config folder as mentioned above. In Vista and Server 2008 there is a \RegBack folder under the main \config folder. Look at the file dates carefully to determine which hives are the most recent. In any case, you need to be able to gain access to these folders and the only way to do it is through either the Recovery Console or a utility CD such as Bart's PE - unless of course, you are able to boot in Safe Mode.
To replace bad system files (instead of doing a full installation with the (R)epair option) you can try running SFC /scannow from a command prompt. You'll need your original media, unless you've altered the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup key to have the SourcePath and other relevant entries point to a folder on your harddrive containing the setup from the media.
You should also be backing up the IIS Metabase and your machine.config files for ASP.NET. See the previous post linked at the beginning for how.
In sum: ERUNT to autobackup the Registry. Recovery Console to get at the hard drive when you cannot boot. Regular backups of the IIS Metabase, and .NET machine.config files. Those are all the ingredients you need.
Now, having repeated myself for the fifth time, let me ask you this question: DO YOU HAVE a reliable server OS recovery strategy, and ARE YOU SURE IT WORKS?
And so I leave you with this little gem:
Natasha: Boris, you got plan?
Boris: Beh-heh-heh! Plan? Of course I got plan! Dey don’t ever vork, but I got one!