The ability to navigate and, when necessary, edit entries in the Registry (Windows NT's system- and user-configuration database) is a vital skill for Windows NT administrators who need to fine-tune and troubleshoot their local or remote NT workstations and servers. The editing process is easy; what's harder is editing safely (i.e., avoiding changes that trash the system and force you to reinstall NT), backing up critical files, and restoring system files corrupted by erroneous changes to the Registry. To work with the Registry safely and effectively, you need to understand how it's organized; how to back up 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 displays
its configuration data in a tree-like structure: The Registry database you view
and edit consists of five subtrees, each of which has a name starting
with hkey (which stands for "handle to a key"). Simply put, when you
work with the Registry, you view and edit subtrees and their contents, but you
back up and restore hives.
To see the Registry subtrees (see Screen 1), run the program called Registry Editor (regedt32.exe)--one of two NT tools for viewing and editing Registry values. (The other tool is regedit.exe, a new tool in NT 4.0 with many of the same functions as the traditional regedt32.exe tool, plus an expanded search capability. Both tools are automatically installed when you install NT. The examples in this article use regedt32 because it supports some editing tools--such as Load Hive--that regedit does not.) The five subtrees are
* hkey_local_machine, which contains information about the system's currently installed hardware and operating system. You'll do most of your work in this subtree, configuring hardware settings or refining logons.
* hkey_classes_root, the "associations" subtree, which is similar to the Windows 3.x Registry and provides compatibility with it. All information about which executable files are associated with which file extensions is stored here. (hkey_local_machine\software\classes also displays this information.)
* hkey_users, which contains the user profiles on the computer, including a default 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 not contain the profiles of users logged on to an NT Server machine--those profiles are stored locally.
* hkey_current_user, which contains information relating to the currently logged-on user.
* hkey_current_config, which contains information that relates to the hardware configuration you booted with. This subtree holds changes to the standard configuration found in hkey_local_ machine's software and system subkeys, so you can think of this subtree as a condensed version of what appears there. (hkey_local_machine also displays this information in the system\currentcontrolset\hardwareprofiles\current subkey.)
As you can see, some information appears in more than one subtree. In particular, if similar information exists in both hkey_local_machine and hkey_current_user, the data in the latter takes precedence (e.g., environment variables defined for the current user have higher priority than system values).
Subtrees in turn contain keys, subkeys, and value entries. A subtree's keys are the folders shown in the left pane of the Registry Editor window for that subtree (e.g., Screen 2 shows the Software and System 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 value of 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 ntwork4\system32 to the Setup key.
The subtrees that you view and edit are not directly related to the hives that store the Registry information. For example, the default user profile information displayed in the hkey_users subtree is stored in two files in the system32\config directory: default and default.log (which records changes to the default file). The data in these files comprises the hive. Note that some Registry information is not in any hive--hives do not store volatile Registry information (i.e., information created when the computer starts and deleted when it stops). For example, the information displayed in hkey_local_machine\hardware, which is re-created each time you boot the system to adapt to changes in computer hardware, is not in a hive. Read "NT 4.0's Registry Hives," for more information about the standard NT 4.0 Registry hives and their associated support files.
Backing Up
Before you edit the Registry (and even if you don't plan to edit it directly
via the Registry Editor), you need to back up its information. Backing up the
Registry regularly--preferably daily--protects you from incorrect changes to and
accidental deletions from settings or account information. Also, if you have to
reinstall NT, you can simply restore the Registry from the backup, thus saving
time you'd otherwise spend reconfiguring your system.
Independent of any backups you make, NT has fault-tolerance capabilities that protect the Registry from failed updates. For more information about how NT protects its Registry hive files, see "How NT Protects Its Hives," page 101. But when NT's automatic failsafes can't help (e.g., when you erroneously make a change), you'll need your backups.
If you have a tape drive attached to your NT system, backing up the hive files is easy: Run NT's tape backup program (ntbackup.exe), and select the Backup Local Registry check box in the Backup Information dialog. However, NT Backup is limited: It can back up the Registry of only the local system (you can't use it to back up a computer's Registry over a network), and it backs up only to tape.
If you don't have a tape drive on your local NT system, or if you want to back up the Registry hives of a remote computer, you must use another method--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 hive files by running rdisk.exe, found in your NT system's support directory (\system32). This utility updates repair data on the Emergency Repair Disk, in the winnt\repair 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 repair directory. If you run rdisk.exe without /s, the backup doesn't include the SAM and Security files and is thus an incomplete backup of the Registry. For example, if you add users to the account database and then update the Emergency Repair Disk with rdisk.exe (without /s), those changes won't be added to the repair disk. And, if you delete accounts, you have to re-create them--they can't be recovered from the Repair disk.
regback and regrest. If you have an NT Resource Kit, you can use two of its utilities, regback.exe and regrest.exe, to back up and restore the Registry. regback copies the hive files for hkey_local_machine or hkey_current_user to a user-defined location, and regrest lets you restore some or all of the files as necessary. Using these two utilities is easier than using rdisk because you don't have to go through the NT restoration screens to restore the backups.
To use regback, enter
regback
where DestinationDirectory is the name of the directory to which you save the hive files. If you receive an error message stating that a file must be backed up manually, you must save the file to a named file by using the alternative syntax
regback
where filename is the name of the file you're saving the original file to, hivetype is the type of hive (machine or users, the only types you can back up), and hivename is the name of one of the hives in either hkey_local_machine or hkey_current_user. If you're using the manual backup method because you received an error message during the normal backup, hivename needs 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 file that will replace a hive file in the system32\config directory, and saveDirectory is the location to which you'll copy the old Registry hive files. By default, regrest attempts to replace each file in the system32\config directory with a like-named file from the backup directory, and copies all the old hive files to the directory you specify. These directories must be on the same volume. For example,
regrest c:\hivefiles.bku c:\install.sav
copies the files in c:\hivefiles.bku to the system32\config directory and then backs up the files that were in the system32\config directory to c:\install.sav. You reboot the system to activate the changes.
As with regback, a warning appears if there are hives you must restore manually or if errors occur. To restore a file manually (for example, if you saved it to another name using regback), the syntax is a little different. You enter
regrest
where newFilename is the name and location of the file to be copied to system32\config and renamed, saveFilename is the name and destination of the file to be copied to the backup location, hivetype is machine or users, and hivename is a hive in hkey_local_machine or hkey_current_user. As with regback, you must reboot your system for these changes to occur.
rollback. Warning: One tool that you don't want to use to back 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 and undocumented OEM utility called rollback.exe in the \support directory. Although you may think this file is a tool you can use to roll the system back to an installation Registry, it's not. Activating this program can trash your system, requiring you to reinstall. Even worse, rollback.exe has no confirmation screens: Click it, and good-bye installation.
Editing the Registry
Before you dive into editing the Registry, carefully consider the risks of
making such changes and whether you can instead change configuration settings
via tools such as the Control Panel and the User Manager. These tools let you
control much of the Registry's contents and ensure that changes to the Registry
are made correctly. Also, keep your knowledge of the Registry current: Registry
support tools released with new versions of NT can decrease how often you need
to directly edit the Registry and thus decrease the risk of faulty editing. For
example, in NT 3.5x and earlier versions, to automate the user logon, you had to
use the Registry Editor (regedt32) to add a few values and change some existing
entries directly in the Registry. However, in NT Server 4.0, you can set up the
same logon options with the System Policy Editor.
To edit the Registry, you can use the Registry Editor (regedt32 or regedit), which you can start in one of the following ways:
From the Options menu in regedt32, you can click Read Only Mode to protect the Registry from unintentional changes while you browse its contents (you turn off this protection the same way). The mechanics of viewing and editing Registry entries are simple: Double-click a key or subkey to open it and display its subkeys 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's menus to make changes. Remember that when you edit the Registry, the change is immediate 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. To
meet this need, the Registry editors in Windows NT 4.0 include tools that let
you load the Registry hives of other NT machines to your system, either from a
network-accessible drive, removable drive, or floppy, assuming you have
permission to access other registries (i.e., you are a member of that computer's
system administrators group).
To view and edit a remote computer's Registry, run regedt 32, click Select Computer in the Registry menu, and double-click the computer's name from the Select Computer list. The remote computer's hkey_users and hkey_local_machine windows 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 leave the remote computer's Registry and complete the update.
Another method for editing a remote system's Registry is to use the Load Hive command in regedt32's Registry menu. This command lets you load part of another computer's Registry for editing, without affecting your own system's Registry. Before you can load a hive, you must save it as a file by using regedt32's Save Key command in the Registry menu. Then click Load Hive in the Registry menu to temporarily load the selected hive to your computer. The Load Hive dialog prompts you to type the name you want to use for the key where the hive will be loaded (shown in Screen 4). The file will appear as a subkey to this 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 use the Registry menu's Restore command to replace the Registry key with the file contents. 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 in hkey_local_machine\hardware (which is built each time you boot the system), you must take another approach to view the data. An alternative is to dump the Hardware 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 this command for a key) and save the Hardware key as a text file. Then scan the Hardware key's contents to identify possible problems, which you can resolve by making appropriate changes.
Registry Confidence Understanding how Registry information is organized and stored can help you monitor and fine-tune your NT systems' configurations. Recognizing when you need to edit the Registry directly and knowing how to edit the Registry properly are two important skills for any system administrator. Although working with the Registry can put your system operations at risk, you can minimize that risk by regularly backing up critical system hive files that you can restore if changes to the Registry cause problems.
See Also "NT 4.0's Registry Hives"
RELATED ARTICLES
Paula Sharick,
"Registry Secrets," October 1995
