Before building system policies within Windows NT—especially if you’re going to migrate to Windows 2000—you must first understand the Registry’s structure and how it can be modified.

System Policies and the Windows NT Registry

Before building system policies within Windows NT—especially if you’re going to migrate to Windows 2000—you must first understand the Registry’s structure and how it can be modified.

• By Michael Chacon
• March 01, 1999

Despite increased attention to system policies and the Windows NT System Policy Editor, many people still view the underlying process of setting up a system as a black box. Day-to-day administration of Windows NT workstations can be tedious and time consuming. Many sites still manage and configure each desktop individually, often in response to configuration problems. This method, fraught with frustration and needless hours of support, is a major reason why Windows NT networks are perceived as difficult to manage. This needn’t be the case.

System Policies

The obvious solution is to create enforceable policies that can be centrally managed for any number of users. This means using the System Policy Editor, an often-ignored tool that sits under the Administrative Tools menu. This tool will become increasingly important as companies migrate to Windows 2000, because all the configurations that you perform with the many NT 4.x administration GUIs will be moved under the umbrella of the Computer Management section of the Management Console tool. In effect, the majority of the user’s environment configurations will be made through the process of system policies, which are essentially Registry edits applied in a controlled and systematic manner.

Even if you don’t plan to implement Windows 2000, you should still consider system policies as a professional method to manage networks. They’ll simplify network administration and support. But before you move forward and build a policy from the boilerplates that come with the System Policy Editor, you must first understand how this tool works and how it fits architecturally within NT. All roads lead to the Registry with NT, and policies are no exception. Therefore, the place to begin building a system policy is by understanding how the Registry is structured and how it can be modified.

Registry Fundamentals

All configuration information for NT is stored in the Registry. The Registry is actually several databases stored in WINNT\SYSTEM32\CONFIG (Figure 1). Unique NTUSER.DAT files for each local user are stored in WINNT\PROFILES\"Username" and are created as each user logs on and off a workstation.

Figure 1. The Windows NT Registry is composed of several databases that are collectively stored in WINNT\SYSTEM32\CONFIG.

Each Registry file is referred to as a hive, and each listed hive also has related files with the same name but different extensions, such as .SAV and .LOG. The .SAV extension is a remnant of the text portion of the NT installation process, and the .LOG files contain changes made to each hive. The hives are brought together and organized under handle keys, a name that refers to the handles used by programs to reference underlying keys and their values.

This handle architecture creates some consistency for the database hive files. The handle keys are most commonly seen in the Registry Editor, which displays five keys. In reality there are only two keys, HKEY_ LOCAL_MACHINE (HKLM) and HKEY_USERS (HKU). The other three keys visible in the Registry Editor are aliases that point to sections of one of the two fundamental keys. This is designed to simplify programmatic access and navigation. Changes made to aliases are actually made to HKLM or HKU, as you can see in Figure 2.

Figure 2. Changes made to aliases in the Registry Editor are actually made to the HKLM or HKU keys. In this case, the HKEY_CLASSES_ROOT handle key is actually an alias for the HKEY_LOCAL_MACHINE\SOFTWARE\Classes key.

Understanding the Registry structure is important not only for general support purposes, but also because creating and writing Registry keys is a core part of implementing system policies.

Before we jump into the Registry Editor, let me make this obligatory caution: Back up the Registry before you modify anything. Always start with the RDISK.EXE utility using the /S switch. This utility copies most of the Registry hives to the \WINNT\SYSTEM32\CONFIG directory and also lets you copy them to an Emergency Repair Disk (ERD). Make sure you use the /S switch or all files won’t be included. Keep in mind, however, that the ERD is a repair utility, not a backup tool. It also doesn’t copy all the NTUSER.DAT hives.

The approved method is to use a tape backup program. You need to check the Backup Local Registry box and select at least one file on the same partition. Another method is to use the REGBACK.EXE utility from the Windows NT Resource Kit, which copies all the open Registry hives to a location that you specify on the disk. These hives can then be restored with REGREST.EXE, which is also included in the Windows NT Resource Kit. If you type in either command with no arguments or parameters, a help screen will appear that explains the syntax for the arguments. As with all NT Resource Kit tools, this method is unsupported—but it works.

Lost Keys

There’s another method built into the Registry Editor that can be quite useful, particularly for quick restores when editing specific key branches. When you use tape to back up your Registry, it neglects to store one key: the list of shares that have been created on your server. This can be very disconcerting if you’re trying to get back online quickly. Imagine a hard drive fails and no mirrors are available (doesn’t mirroring always look better after a failure?). So you pull out your trusty verified tape and slap it on a new drive. The problem is, users will still complain that the system is broken because their shares aren’t present.

Instead of pulling out that hardcopy documentation of all your configurations (you did make a copy, right?) and re-creating the shares, try the following procedure. Open the Registry Editor to the HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares key, which will display all the shares on the machine, as shown in Figure 3.

Figure 3. Opening the Registry Editor to the HKLM\SYSTEM\ CurrentControlSet\Services\LanmanServer\Shares key will bring up a display of all the shares on your machine.

With the key highlighted, select the Registry|Save Key menu option. This will bring up the Save Key dialog box.

When saving the key, you can use any name you want. The best practice is to use something narrative and leave it in a directory where you can find it again when needed. Because this’ll be a regular unopened file, it’ll be backed up with the normal tape backup. When you have to rebuild a disk subsystem and restore the system from tape, you then use the Registry|Restore menu option and bring the key back into the Registry. Your shares will be available again immediately.

The procedure I just described works with other keys as well. For example, if you save a key before you install a software package and you have an installation problem, you can restore the key and go back to where you started. One thing to remember is that when you restore a key using this technique, the key is completely replaced. Instead of making selected changes, the process completely overwrites whatever information was there in the first place.

Another example of how the Registry is built and edited can be found in HKEY_USERS. If you open the HKEY_USERS handle key in Registry Editor, you’ll notice that you can only see the .DEFAULT hive and the currently logged-in user hive. This key is reflected in the alias handle HKEY_CURRENT_USER, which is actually the NTUSER.DAT file for that user.

Migrating Hives

There is a way to bring other users’ hives onto a particular machine, be it locally or remotely. Open the HKEY_USERS and, with the handle key highlighted, select the Registry|Load Hive menu option and navigate to the WINNT\PROFILES\ Username directory where the Username is the directory that reflects the user you want to modify. Select the NTUSER.DAT file in that directory. You’ll be prompted for a name. This name can be whatever you choose, because it’s only a label for use in the Registry Editor. Convention suggests that you use the Username. This will bring that user’s NTUSER.DAT hive into the Registry Editor (Figure 4).

Figure 4. After you bring another user’s hive onto your machine, that user’s NTUSER.DAT hive will be visible in your Registry Editor.

Now you can make any changes that you want. For example, you might want to copy a section of one user to another if an application’s setup program modified the Current User instead of all the users. You can use the Registry|Save menu option to create a hive and then use Registry|Restore to bring those entries into the other user’s hive, avoiding the need to reinstall the application under the new user. When you’re finished, you use the Registry|Unload Hive menu option to write the changes back to the NTUSER.DAT file, which will now reflect the changes you’ve made.

Keep it in Perspective

I’m not recommending that everyone start editing NTUSER.DAT files by this method. First, it isn’t the most efficient and scalable way to control these files. And second, if you don’t know what you’re doing, you’ll eventually trash your Registry. My point this month was to describe how the Registry works and how it relates to system policies. Working with the Registry Editor helps you understand this because system policies are actually systemic edits of the Registry on each local workstation. When a system policy is enforced, a preplanned Registry section or hive is written to the local Registry. Next month, I’ll discuss the Registry’s architecture further and how it relates to profiles and system policies. What I discussed this month is similar to profiles and system polices in how they function. Each, however, is a more sophisticated step in the road to the polices that will permeate Windows 2000 and beyond.