3.5 Restoring a Backed-up Registry

Now that you know how to back up your Registry, the next logical step is to learn how to restore it. You need to be comfortable enough doing this that the prospect doesn't scare you; no one looks forward to repairing a damaged Registry, but it shouldn't be frightening either. Practice until you're comfortable with the approaches described in the rest of the section.

3.5.1 The Old-Fashioned Way

Restoring the Registry from a manual backup isn't useful in all circumstances, since to restore the hive files you must be able to boot your machine and gain access to Windows 2000's boot partition, as described earlier in the chapter. Once you've booted your machine into DOS, Linux, or some other OS that gives you access to the partition where your hive files are stored, all you need to do is copy the backup copies over to the original hive directory. (Of course, you have to uncompress them first if they're compressed!) Reboot into Windows 2000, and you're done.

While this approach is appealingly simple, it has its disadvantages. Apart from requiring that you be able to boot into another OS, it has the drawback of being indiscriminate. When you restore a hive, you'll be restoring everything in the hive. This can have the unwanted consequence of removing changes you wanted to keep while fixing whatever problem originally required you to use a backup.

3.5.2 Using Windows 2000 Backup

Restoring a Registry backup with Windows 2000's backup utility is fairly painless. It's not smart enough to check whether you're restoring to the same machine you backed up from, so you must be careful to avoid installing the wrong Registry (including the SAM database and HKLM\SECURITY subtree) on the wrong machine.

Earlier in the chapter, you saw Figure 3.6, which shows NTBACKUP 's user interface. To make a backup, you had to select a drive (and its subfolders and files) to back up. Guess what? To restore from a backup, you do the opposite and select a tape to use for the restoration. Here's how the process works:

Figure 3.10. Restore Local Registry

3.5.3 Using REGREST

If you back up your Registry with REGBACK, naturally you'll use its companion, REGREST, to restore it. REGREST can use only the files created by REGBACK, but since they come as a pair, that shouldn't be an impediment. However (like its partner), REGREST has some limitations you should be aware of.

First, and most seriously, it runs only under Windows NT and Windows 2000. REGREST actually works by repeatedly calling the RegReplaceKey API routine, meaning that it has to have access to the Windows 2000 registry to do its work. Even though this routine exists in Win95, the Win95 version operates only on the Win95 Registry. If you can't boot your machine into Windows 2000, you'll need to use an ERD to fix it, not a REGREST backup.

Of course, you should plan on keeping a copy of REGREST on any boot disks you might use to effect a Registry repair.

Second, you can run REGREST only from accounts that have "Restore files and directories" privilege. In most cases, that means your local Administrator account, plus any accounts you've added to the Backup Operators group. (Of course, you can grant this right to any user.)

Next, REGREST works only with REGBACK files that are on the same volume as the hive files themselves. If your backup files are stored elsewhere, you have to move them to your Windows 2000 boot volume before running REGREST.

Finally, you have to reboot your machine before REGBACK 's changes will take effect. This is sometimes an annoyance, but it's actually a safety feature: you can undo or redo restores as much as necessary, and the changes won't be permanent until you reboot.

If you can live with these four restrictions, REGREST is fairly easy to use. It actually operates in three steps:

Like REGBACK, REGREST comes in two flavors. The first restores as many hives as it can find; it looks for files in the backup directory whose names match hive files in the hive directory. When it finds a match, it copies the matching file according to the previous three steps. You use it like this:

regrest backupDir saveFilesDir

backupDir

Specifies where the files generated by REGBACK are stored; must be on the same volume as your Windows 2000 system files.

saveFilesDir

Tells REGREST where to put the secondary backup files it creates. If necessary, you can copy these files back to the hive directory before rebooting to undo a restore.

REGREST warns you if there are hives it can't restore automatically, or if errors occurred. Here's a sample transcript:

C:\>regrest \regsave \backsave
replacing SECURITY with \regsave\SECURITY
replacing SOFTWARE with \regsave\SOFTWARE
replacing SYSTEM with \regsave\SYSTEM
replacing .DEFAULT with \regsave\DEFAULT
replacing SAM with \regsave\SAM

***Hive = \REGISTRY\USER\S-1-5-21-1944135612-1199777195-24521265-500
Stored in file \Device\Harddisk0\Partition1\WINNT\Profiles\Administrator
\ntuser.dat
Must be replaced manually
regrest <newpath> <savepath> users S-1-5-21-1944135612-1199777195-24521265-500

You must reboot for changes to take effect.

The second form of the command allows you to manually restore one hive at a time:

regrest backupFileName saveFileName hiveType hiveName

backupFileName

Specifies which hive file (including its full path, if desired) REGREST should restore.

saveFileName

Tells REGREST what name and directory to use for the copy it makes of the existing hive file.

hiveType

Just like REGBACK, REGREST accepts only two hive types. Specify machine for HKLM or users for HKU. If you provide any other hive type, REGREST will fail.

hiveName

Specifies a subkey immediately beneath either HKU or HKLM. If you specify any other key, REGREST will fail.

3.5.4 Using RegEdt32 and RegEdit

As you've seen in earlier sections, the two stock Registry editors shipped with Windows 2000 are useful when it comes time to back up your Registry data. Fortunately, they can also help you restore it should you need to.

3.5.4.1 Loading hives

You can load hive files created with RDISK, ERDisk, or RegEdt32 into your Registry. When you do, however, it's important to note that RegEdt32 creates a new key that contains your hive or honeycomb contents. That key and the hive or honeycomb it contains remain loaded until you explicitly unload them.

There's another wrinkle, too: RegEdt32 allow you to load hives only under HKU and HKLM. As a practical matter, this isn't a big deal; it just means that the hives you load are subkeys of one of those two roots, not subkeys of their subkeys. If you have anything other than HKLM or HKU selected when you give the command, you get an error dialog telling you that you don't have permission to load the hive.

When you use the RegistryLoad Hive command, RegEdt32 asks you for a hive file to load. Once you've identified a file, it asks for the name of the key you want the loaded hive to be under. For example, if you load the .DEFAULT hive to a new key named "MyDefaults" under HKU, you see that HKU\MyDefaults is now equal with HKU\.DEFAULT and HKU\sid, and it contains whatever the original hive or honeycomb file contained.

Once a hive's loaded, you can add, remove, or change keys and values in it like any other part of the Registry; the changes are reflected in the associated hive file.

3.5.4.2 Reloading saved keys

You can reload a previously saved key at any time using RegEdt32's RegistryRestore Key... menu command. However, this command is an accident waiting to happen. Why? Well, when you save a key, the saved key doesn't contain any path data. For example, if you save HKLM\SOFTWARE\Qualcomm\Eudora, its values and all its subkeys are saved--but not the fact that it originally came from HKLM\SOFTWARE\Qualcomm\Eudora. This in and of itself isn't so bad, but the real danger comes when you get ready to reload the key.

When you tell RegEdt32 to reload a key, you see a warning dialog (shown in Figure 3.11) telling you what's about to happen. It's not an idle warning, either; if you click Yes, the currently selected key in the Registry will have all its subkeys and values replaced by whatever's in your saved file. Not only does the saved key not go where you wanted it, it also destroys whatever happened to be underneath the key you selected! If you accidentally load HKLM\SOFTWARE\Qualcomm\Eudora while you happen to have HKCU\SOFTWARE\AppEvents selected (to pick a fairly innocuous victim), you'll find that RegEdt32 happily blasts your Eudora settings into the middle of Windows 2000's sound-to-event mapping list. The results are, at best, unpredictable.

Figure 3.11. RegEdt32 overwrite warning

Of course, this problem can be worked around with a little caution: make sure you have the correct key selected when using this command. Failing that, make sure you have a reliable, up-to-date backup.

3.5.4.3 Using RegEdit files

Since the .REG files produced by RegEdit contain the full path for each exported key, they're extremely simple to use. To reimport a .REG file, all you need to do is run RegEdit and use its RegistryImport Registry File... command. When you do, RegEdit imports the file's contents without any further intervention on your part;^[6] it automatically replaces existing keys and their values with whatever's in the file, as well as adding back any keys that are in the file but not in the Registry. It doesn't, however, delete keys in the Registry that have been added since the .REG file was created; you have to do that yourself if necessary.

^[6] This actually poses somewhat of a security risk, since any .REG file that a user can be tricked into double-clicking may make malicious changes. To fix this, change the default action for RegEdit to open .REG files with notepad.exe instead.