Care and Feeding of the Registry

Edit your Registry safely and effectively to properly care for your system

The ability to navigate and, when necessary, edit entries in the Registry(Windows NT's system- and user-configuration database) is a vital skill forWindows NT administrators who need to fine-tune and troubleshoot their local orremote NT workstations and servers. The editing process is easy; what's harderis editing safely (i.e., avoiding changes that trash the system andforce you to reinstall NT), backing up critical files, and restoring systemfiles corrupted by erroneous changes to the Registry. To work with the Registrysafely and effectively, you need to understand how it's organized; how to backup and, if necessary, restore system files; and how to perform basic editing,including how to edit a remote system's Registry.

Hives, Subtrees, and Keys
The Registry stores most of its information in sets of files (called hives)based on different aspects of the NT environment. But, the Registry displaysits configuration data in a tree-like structure: The Registry database you viewand edit consists of five subtrees, each of which has a name startingwith hkey (which stands for "handle to a key"). Simply put, when youwork with the Registry, you view and edit subtrees and their contents, but youback up and restore hives.

To see the Registry subtrees (see Screen 1), run the program called RegistryEditor (regedt32.exe)--one of two NT tools for viewing and editing Registryvalues. (The other tool is regedit.exe, a new tool in NT 4.0 with many of thesame functions as the traditional regedt32.exe tool, plus an expanded searchcapability. Both tools are automatically installed when you install NT. Theexamples in this article use regedt32 because it supports some editingtools--such as Load Hive--that regedit does not.) The five subtrees are

* hkey_local_machine, which contains information about the system'scurrently installed hardware and operating system. You'll do most of your workin this subtree, configuring hardware settings or refining logons.

* hkey_classes_root, the "associations" subtree, which is similarto the Windows 3.x Registry and provides compatibility with it. All informationabout which executable files are associated with which file extensions is storedhere. (hkey_local_machinesoftwareclasses also displays this information.)

*hkey_users, which contains the user profiles on the computer, including adefault profile for a user who hasn't logged on before, and (in NT Workstation)the profile of the current user (i.e., hkey_current_user). This subtree does notcontain the profiles of users logged on to an NT Server machine--those profilesare stored locally.

*hkey_current_user, which contains information relating to the currentlylogged-on user.

*hkey_current_config, which contains information that relates to thehardware configuration you booted with. This subtree holds changes to thestandard configuration found in hkey_local_ machine's software and systemsubkeys, so you can think of this subtree as a condensed version of what appearsthere. (hkey_local_machine also displays this information in thesystemcurrentcontrolsethardwareprofilescurrent subkey.)

As you can see, some information appears in more than one subtree. Inparticular, if similar information exists in both hkey_local_machine andhkey_current_user, the data in the latter takes precedence (e.g., environmentvariables defined for the current user have higher priority than system values).

Subtrees in turn contain keys, subkeys, and valueentries. A subtree's keys are the folders shown in the left pane of theRegistry Editor window for that subtree (e.g., Screen 2 shows the Software andSystem keys for hkey_current_config.) Subkeys appear as subdirectories of keys.Value entries appear in the right pane of a subtree window and define the valueof the currently selected key or subkey. Value entries have three parts,separated by colons: a name, a data type, and a value. For example, in Screen 3,osloaderpath is a value entry that assigns the value ntwork4system32 to theSetup key.

The subtrees that you view and edit are not directly related to the hivesthat store the Registry information. For example, the default user profileinformation displayed in the hkey_users subtree is stored in two files in thesystem32config directory: default and default.log (which records changes to thedefault file). The data in these files comprises the hive. Note that someRegistry information is not in any hive--hives do not store volatileRegistry information (i.e., information created when the computer starts anddeleted when it stops). For example, the information displayed inhkey_local_machinehardware, which is re-created each time you boot the systemto adapt to changes in computer hardware, is not in a hive. Read "NT 4.0'sRegistry Hives," for more information about the standard NT 4.0 Registryhives and their associated support files.

Backing Up
Before you edit the Registry (and even if you don't plan to edit it directlyvia the Registry Editor), you need to back up its information. Backing up theRegistry regularly--preferably daily--protects you from incorrect changes to andaccidental deletions from settings or account information. Also, if you have toreinstall NT, you can simply restore the Registry from the backup, thus savingtime you'd otherwise spend reconfiguring your system.

Independent of any backups you make, NT has fault-tolerance capabilitiesthat protect the Registry from failed updates. For more information about how NTprotects its Registry hive files, see "How NT Protects Its Hives,"page 101. But when NT's automatic failsafes can't help (e.g., when youerroneously make a change), you'll need your backups.

If you have a tape drive attached to your NT system, backing up the hivefiles is easy: Run NT's tape backup program (ntbackup.exe), and select theBackup Local Registry check box in the Backup Information dialog. However, NTBackup is limited: It can back up the Registry of only the local system (youcan't use it to back up a computer's Registry over a network), and it backs uponly to tape.

If you don't have a tape drive on your local NT system, or if you want toback up the Registry hives of a remote computer, you must use anothermethod--either NT's rdisk.exe utility or an NT Resource Kit's backup utilities,regback.exe and regrest.exe.

rdisk. If you don't have an NT Resource Kit, you can copy hivefiles by running rdisk.exe, found in your NT system's support directory(system32). This utility updates repair data on the Emergency Repair Disk, inthe winntrepair directory, or both.

Note that to completely back up the hives, you must run rdisk.exe with the/s switch, as follows:

rdisk/s

You can think of the /s switch as standing for "security"; using/s adds the user account information to the Repair disk and the repairdirectory. If you run rdisk.exe without /s, the backup doesn't include the SAMand Security files and is thus an incomplete backup of the Registry. Forexample, if you add users to the account database and then update the EmergencyRepair Disk with rdisk.exe (without /s), those changes won't be added to therepair disk. And, if you delete accounts, you have to re-create them--they can'tbe recovered from the Repair disk.

regback and regrest. If you have an NT Resource Kit, you can usetwo of its utilities, regback.exe and regrest.exe, to back up and restore theRegistry. regback copies the hive files for hkey_local_machine orhkey_current_user to a user-defined location, and regrest lets you restore someor all of the files as necessary. Using these two utilities is easier than usingrdisk because you don't have to go through the NT restoration screens to restorethe backups.

To use regback, enter

regback

where DestinationDirectory is the name of the directory to which yousave the hive files. If you receive an error message stating that a file must bebacked up manually, you must save the file to a named file by using thealternative syntax

regback

where filename is the name of the file you're saving the originalfile to, hivetype is the type of hive (machine or users, the only typesyou can back up), and hivename is the name of one of the hives in eitherhkey_local_machine or hkey_current_user. If you're using the manual backupmethod because you received an error message during the normal backup, hivenameneeds to be the name of the hive that wasn't backed up.

Using regrest is somewhat more complicated. The syntax is

regrest

where newDirectory specifies the source of the backed-up hive filethat will replace a hive file in the system32config directory, and saveDirectoryis the location to which you'll copy the old Registry hive files. By default,regrest attempts to replace each file in the system32config directory with alike-named file from the backup directory, and copies all the old hive files tothe directory you specify. These directories must be on the same volume. Forexample,

regrest c:hivefiles.bku c:install.sav

copies the files in c:hivefiles.bku to the system32config directory andthen backs up the files that were in the system32config directory toc:install.sav. You reboot the system to activate the changes.

As with regback, a warning appears if there are hives you must restoremanually or if errors occur. To restore a file manually (for example, if yousaved it to another name using regback), the syntax is a little different. Youenter

regrest

where newFilename is the name and location of the file to be copiedto system32config and renamed, saveFilename is the name and destinationof the file to be copied to the backup location, hivetype is machine orusers, and hivename is a hive in hkey_local_machine orhkey_current_user. As with regback, you must reboot your system for thesechanges to occur.

rollback. Warning: One tool that you don't want to use toback up or restore a system's Registry is rollback.exe. As you may have heard,Microsoft mistakenly released some early editions of NT with a dangerous andundocumented OEM utility called rollback.exe in the support directory. Althoughyou may think this file is a tool you can use to roll the system back to aninstallation Registry, it's not. Activating this program can trash your system,requiring you to reinstall. Even worse, rollback.exe has no confirmationscreens: Click it, and good-bye installation.

Editing the Registry
Before you dive into editing the Registry, carefully consider the risks ofmaking such changes and whether you can instead change configuration settingsvia tools such as the Control Panel and the User Manager. These tools let youcontrol much of the Registry's contents and ensure that changes to the Registryare made correctly. Also, keep your knowledge of the Registry current: Registrysupport tools released with new versions of NT can decrease how often you needto directly edit the Registry and thus decrease the risk of faulty editing. Forexample, in NT 3.5x and earlier versions, to automate the user logon, you had touse the Registry Editor (regedt32) to add a few values and change some existingentries directly in the Registry. However, in NT Server 4.0, you can set up thesame logon options with the System Policy Editor.

To edit the Registry, you can use the Registry Editor (regedt32 orregedit), which you can start in one of the following ways:

From the Options menu in regedt32, you can click Read Only Mode to protectthe Registry from unintentional changes while you browse its contents (you turnoff this protection the same way). The mechanics of viewing and editing Registryentries are simple: Double-click a key or subkey to open it and display itssubkeys and value entries. Then double-click the desired value entry to add,delete, or modify information. You can also use options in the Registry Editor'smenus to make changes. Remember that when you edit the Registry, the change isimmediate and not reversible--you do not have an Undo button.

Editing Remote Registries
As an NT administrator, you can't always work directly from a local system;sometimes you have to access remote systems to support and maintain them. Tomeet this need, the Registry editors in Windows NT 4.0 include tools that letyou load the Registry hives of other NT machines to your system, either from anetwork-accessible drive, removable drive, or floppy, assuming you havepermission to access other registries (i.e., you are a member of that computer'ssystem administrators group).

To view and edit a remote computer's Registry, run regedt 32, click SelectComputer in the Registry menu, and double-click the computer's name from theSelect Computer list. The remote computer's hkey_users and hkey_local_machinewindows appear. You can view or modify all keys you have permission to access.When finished, click Close in the Registry menu for each subtree window to leavethe remote computer's Registry and complete the update.

Another method for editing a remote system's Registry is to use the LoadHive command in regedt32's Registry menu. This command lets you load part ofanother computer's Registry for editing, without affecting your own system'sRegistry. Before you can load a hive, you must save it as a file by usingregedt32's Save Key command in the Registry menu. Then click Load Hive in theRegistry menu to temporarily load the selected hive to your computer. The LoadHive dialog prompts you to type the name you want to use for the key where thehive will be loaded (shown in Screen 4). The file will appear as a subkey tothis designated key. When you're finished editing the other system's Registry,you can unload the hive (using Unload Hive from the Registry menu) and then usethe Registry menu's Restore command to replace the Registry key with the filecontents. Note that you can also use this method on your own computer,for example, if you want to edit a copy of a key rather than the original.

Unfortunately, you cannot use Load Hive with volatile Registry information,so if you think a system's configuration problems might lie inhkey_local_machinehardware (which is built each time you boot the system), youmust take another approach to view the data. An alternative is to dump theHardware key's contents into a text file and then view it with a text editor.First, select Save Subtree As from the Registry menu (you can also use thiscommand for a key) and save the Hardware key as a text file. Then scan theHardware key's contents to identify possible problems, which you can resolve bymaking appropriate changes.

Registry ConfidenceUnderstanding how Registry information is organized and stored can help youmonitor and fine-tune your NT systems' configurations. Recognizing when you needto edit the Registry directly and knowing how to edit the Registry properly aretwo important skills for any system administrator. Although working with theRegistry can put your system operations at risk, you can minimize that risk byregularly backing up critical system hive files that you can restore if changesto the Registry cause problems.

See Also "NT 4.0's Registry Hives"

RELATED ARTICLESPaula Sharick,
"Registry Secrets," October 1995