Are your users out of control? Try using profiles and system policies to manipulate the Windows NT Registry and regain control of your network.

Managing with Profiles and Policies

Are your users out of control? Try using profiles and system policies to manipulate the Windows NT Registry and regain control of your network.

• By Michael Chacon
• 04/01/1999

Last month, I discussed how the Windows NT Registry is responsible for each individual workstation configuration and the user’s desktop environment on each workstation. This architectural aspect of NT is the basis for the systematic configuration and control of the NT environment. If you haven’t read it, get out your March issue and grab last month’s column—and while you’re there, read Joseph Phillips’ article, "Practical Policies,” which ran in the December 1998 issue of MCP Magazine. Knowing how we can manually import and export portions of the Registry makes it easier to understand how profiles and system policies function on the network.

Managing User Environments

When a user first logs onto an NT client, a user profile directory is created using the logon name. The Default User directory contains an NTUSER.DAT file, which holds the information used to create each new user’s default information (see Figure 1).

Figure 1. The Default User directory contains the information used to create each new user's default information.

After the new user has logged onto the machine, an entire set of directories and the all-important new NTUSER.DAT are located in the new JULIAC directory (see Figure 2). The next time this user logs onto the machine, her USER.DAT file will be loaded into her HKEY_CURRENT_USER Registry key and applied. Knowing that NT functions in this way, you can create a reconfigured environment for each new user that logs onto a particular workstation.

By modifying the contents of the Default User directory, you can control how every new user’s environment will look and function as he or she logs onto the workstation. One way to accomplish this is to bring an NTUSER.DAT file into the Registry Editor, modify the contents of the hive, and then copy it into the Default User directory. There’s also a GUI applet that make this process less accident-prone and follows the Microsoft recommendation of not using the Registry Editor.

Figure 2. After the new user has logged onto the machine, an entire set of directories and the all-important NTUSER.DAT are saved in the new user’s directory— in this case, JuliaC.

The first step is to log onto the workstation with a template account and, by using the Control Panel applets (which are special-purpose Registry Editors), configure the desktop to look and behave as you want for all the users. This could include such areas as persistent network connections, start menu options, screen savers, or other display characteristics. When you log off the system, the Registry entries will be written to that account’s NTUSER.DAT file. In addition to the configuration changes to the NTUSER.DAT file, you can also place documents and Internet URLs into the appropriate Default User folders.

The next step is to log on as the Administrator account and open the Control Panel|System Properties applet. Select the User Profiles tab to bring up a listing of users who’ve logged onto the system and created NTUSER.DAT files (see Figure 3).

By selecting the “template” user, you can copy the profile to the another location—including the Default User directory—by selecting the Copy To button.

Once this is completed, each new user that logs onto the workstations will be presented with the environment that you predetermined from within the template user. As the users log off, these settings will be written back to their own NTUSER.DAT file and directory structure under their own logon name.

Figure 3. Selecting the User Profiles tab in System Properties displays a list of the users who’ve logged onto the system and created NTUSER.DAT files.

Maintaining Control

Editing NTUSER.DAT files is the most rudimentary form of profile management. While it is interesting, it raises many issues about control. First, although you can maintain a consistent environment for each user by storing their NTUSER.DAT file on the server, users can change their own environments and these changes will be written back to the areas in their profile directory. As the environments change from the standard version, new less-supportable versions are created. This problem can be simply resolved by renaming the NTUSER.DAT to NTUSER.MAN, thus creating a mandatory profile. This way, users can make changes to their environment while logged on, but the changes won’t be written out to the NTUSER.MAN file when they log off. When users log back onto the system, their unchanged NTUSER.MAN hive will be loaded into HKEY_CURRENT_USER and their environment will return to its original state.

Another issue is that you must follow the process I just described on each workstation so the same environment can be created on the entire network This is clearly unrealistic. An alternative solution with the Registry is to move these hives off of the workstation and onto a central server. Using the User Profiles applet again, you can move a user’s profile to a central location, change permissions to the profile, and have many users share the same profile. In addition, you can also rename the profile with the .MAN extension and prevent users from writing changes back to the profile.

This brings us to an interesting juncture. As I mentioned, when a user logs on, the local NTUSER.DAT file is loaded into the HKEY_CURRENT_USER key. If that user logs on with a roaming profile, however, the roaming profile hive is located and loaded into the same key, thereby overwriting the local profile. While the effect is that the roaming profile takes precedent and is what the user experiences, the system actually loads two profiles in succession. This is important to remember when we look at system policies.

Roaming profiles may move us toward a more manageable solution by centralizing the distribution of configuration information and delivering that information to multiple users, but they still pose management problems. First, we’re left manipulating multiple files on servers. Furthermore, to create these files we must be logged onto a workstation. Also, we’re stuck editing hives in the Registry Editor against Microsoft’s repeated disclaimers. This brings us to the System Policy Editor.

System Policies

The System Policy Editor is essentially another type of Registry Editor. It creates a hive that can be centrally located and used to update the Registries of multiple machines determined by the machine or the user that logs onto that machine. The System Policy Editor is a very powerful tool that rests on the laurels of profile technology.

If you look at the System Policy Editor screen, you can see that there are initially two objects in the GUI, using the terminology from the underlying profile technology: the Default Computer and Default User (see Figure 4).

These two icons map directly to the main two HKEYS in the Registry. Default Computer represents HKEY_LOCAL_MACHINE and Default User represents HKEY_CURRENT_USER. In fact, if you select the File|Open Registry menu option, the System Policy Editor will allow you to edit directly the Local Registry of the machine you run it from. In addition, if you select File|Connect and enter the NetBIOS name of a remote computer you can also directly edit remote Registries (see Figure 4).

Figure 4. The System Policy Editor initially has two icons: the Default Computer and Default User. These map directly to the main two HKEYS in the Registry, HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER. The Registry Editor lets you edit Registries on other machines, regardless of their physical location.

For example, the configuration that turns on or off a machine’s ability to be shut down at the logon screen is displayed in the System Policy Editor (see Figure 5). In this example the box is checked, so this option is enabled.

Figure 5. When editing a machine’s Registry using the System Policy Editor, you activate or deactivate options simply by checking the adjacent box. Here, the configuration that enables a machine to be shut down at the logon screen has been activated

When you select an option in the System Policy Editor, the change is actually made in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon key.

The GUI for the System Policy Editor is built using .ADM files that display the available Registry options. As you can also see in Figures 5 and 6, however, many more options are available in the Registry than are displayed in the default .ADM System Policy Editor files.

Figure 6. Changes made in the System Policy Editor are actually made in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon key. The change we made in Figure 5 shows up here as “1” to denote activation.

Powerful Network Management

Although the System Policy Editor can be used to edit Registry files directly, its real power is to create Registry hives that can be stored in a central location and applied to machines and users as they’re authenticated on the network. Refer to Joseph Phillips’ article to learn how to create configurations for specific machines, groups, and individual users. The article also shows how to save all of this information in one NTCONFIG.POL file stored on the Domain Controllers or on a specified server to be used as each person is authenticated on the network.

This is obviously a powerful method for managing networks. But you must keep in mind the entire profile and system policy process. When a user is authenticated, the local NTUSER.DAT file is loaded into the \HKEY\CURRENT_USER key, which is configured to tell the logon process to check for the Roaming Profile. If a Roaming Profile is available for the user, it’s copied to the workstation and overwrites the local profile. Then things really get interesting. If there’s an NTCONFIG.POL file, it’s parsed for the user’s account name, group membership, and machine name for hives created that apply for this authentication process.

If the user is a member of several groups that are specified in the NTCONFIG.POL file, each hive is downloaded and applied to the Registry in the administrator-specified order as they’re parsed. After the groups are parsed, the machine hive is downloaded to the workstation and that hive is also applied. In a poorly designed policy file, there could be several hive transfers that overwrite one another as they come down to the workstation. This could create significant logon traffic resulting in performance problems, especially over slow links. What this means is that the NTCONFIG.POL file is a reservoir of Registry hives that can be called down to a workstation, layer upon layer, until the final layer wins.

Similar But Different

Profiles and system policies are similar beasts. Both manipulate the Registry, but one is managed centrally and the other locally or with multiple central files. If you aren’t using system policy files today, you’d better get on the stick. Windows 2000 is all about policy files. The administration GUIs are replete with configuration options that will be writing to the Registry. Yes, the Registry still lives in Windows 2000. In fact, where the Registry ends and the Active Directory begins is still very much open to debate. But I’ll save that for another time.