In his February article, "How to Edit NT 4.0 System Policies," Robert Slifka introduced the Windows NT 4.0 System Policy Editor (SPE) application and some of the ways you can use it to secure an NT network. He included information about the use and customization of policy template files (.adm files). This month, I expand on this topic, and present some other features and potential applications of this handy utility.

If you've ever administered a group of NT workstations on a network, you know the difficulty of maintaining a uniform configuration for all your computers. This problem is especially nasty in organizations that have corporate or MIS policies that mandate certain aspects of the user's environment, such as what programs users can access, what control they have over their machine, and the appearance of their desktop. Ever tried to make a custom Registry change or set the background wallpaper on 500 (or even 50) NT workstations? If so, you'll appreciate the problem and solution I describe here.

A Quick Review
NT stores all its configuration settings in the NT Registry database. You can view and modify these settings with one of the NT Registry editors (regedt32.exe or regedit.exe). When you examine the Registry, you see machine-related information in a branch of the Registry called the HKEY_LOCAL_MACHINE subtree. In addition, you see information related to the currently logged-in user. This information appears in the HKEY_CURRENT_USER subtree (for information about the NT Registry subtrees and tips on editing the Registry, see Christa Anderson, "Care and Feeding of the Registry," December 1996).

The HKEY_CURRENT_USER subtree also goes by another name: the current user's user profile. A user profile contains a variety of information about the user's desktop environment, such as Control Panel applet settings, network printer connections, Win32 application settings, and environment variables. ntuser.dat, the file that contains the user profile (the file from which the HKEY_CURRENT_USER Registry subtree is generated), is typically in the user's subdirectory under the user profiles directory on the local machine (e.g., c:\winnt\profiles\sean). The system can store the user profile on a network server if the administrator configured the user's account to use a server-based (e.g., mandatory, or roaming) profile. The HKEY_LOCAL_MACHINE subtree, in contrast, contains settings related to user logon, network access, and other system-related settings.

That information is fine, but what does this review have to do with SPE? Well, imagine creating a template, or mask, that the system automatically applies to an NT workstation's Registry each time a user logs on, so that all the restrictions that apply to both the machine and that particular user automatically take effect when the user logs in. Furthermore, imagine that this template is user- and group-specific, so that the restrictions taking effect depend on the user's logon name and group memberships. Well, SPE does just that.

How SPE Works
You probably know that SPE manages two distinct types of policies: the system policy for users and the system policy for computers. Together, these two entries restrict a user's access to the computer.

When users sitting at NT 4.0 computers log on to their domain with their domain user account, NT automatically merges the system policy for users portion of the file (the required name for an NT system policy file) with the user's profile (ntuser.dat), replacing any settings in ntuser.dat that don't match those found in ntconfig.pol. In addition, NT adds any machine-related settings defined in the system policy for computers to the HKEY_LOCAL_MACHINE portion of the Registry. The net effect? You get customized Registry settings for every NT computer and user in the domain, with all the appropriate restrictions in place.

First Things First: Installing SPE
The February article demonstrated how to start the SPE application, but this capability assumes that SPE is already installed on your system. In case it isn't (which is likely because NT doesn't install it by default), here's how to get SPE on your system. The utility ships only with the NT Server 4.0 CD-ROM and not with the NT Workstation version (presumably because SPE is an administrative-level tool). However, from the NT Server CD-ROM, you can install SPE on either an NT Server or NT Workstation 4.0 system.

To install SPE (which is part of a group of NT Server client-based administration tools), run the setup.bat file in the NT Server CD-ROM's \clients\svrtools\winnt directory. This batch file automatically detects your computer's processor type and installs the files SPE requires and several other NT Server administration tools. After installation, you must manually create shortcuts to the application poledit.exe, now in the \winnt\system32 subdirectory on your hard disk (neither the 3.51 nor 4.0 version automatically creates a program group and icons for these utilities; is this capability really too much to ask, Microsoft?).

Tips for Creating Your Organization's System Policy
Once you have SPE running and have created a system policy file, the next question is usually what SPE settings to be concerned with. The entries available in the system policy for computers and system policy for users include a variety of Registry entries that serve different purposes. For example, some Registry values are useful for enhancing security, and others help maintain a more consistent desktop look and feel. Still others relate to areas such as performance and task automation.

Although you can manipulate different settings with the default common.adm and winnt.adm templates, several settings are particularly worthy of mention. Tables 1 and 2 summarize some of the more useful computer and user-related system policy entries, where they're located, and what area the entry corresponds to (e.g., security, performance, uniform desktop). Table 1 lists computer-related entries, and Table 2 lists user/group-related policy entries.

To change a policy for a particular Registry change, navigate the policy tree by double-clicking the branch you want to expand (or click the + symbol at left to expand the branch's contents one level down). Once you've expanded a branch and located a value you want to change, you'll see a check box that will be in one of three states: grayed, white, or checked.

A grayed checkbox means that no change is stipulated for this entry. A grayed box tells SPE to keep the setting that is already in effect for this item from other policies or the system default. A white box tells SPE to disable the item, and a checked box tells SPE to enable the item.

When you enable certain entries, SPE sometimes requests additional information related to the item at the bottom of the dialog box. For example, if you check the box next to the NT System\Logon\Logon Banner entry to enable it, you must also enter a window caption and banner text for the custom logon banner in the boxes below. Screens 1 and 2 show samples of editing the system policy for computers and users, respectively.

Policy Precedence
What happens when more than one policy applies to a given user? That is to say, what if a user logs on to the domain, and the system policy file contains multiple user or group entries that apply to that user (for either computer or user policies)? In this situation, NT uses a policy evaluation process to determine the correct policies for that user.

The pecking order goes as follows: When an individual policy exists for a user, this policy is always used in preference to any group policies defined for groups that the user belongs to. If the user belongs to multiple groups and two or more of these groups have policies defined, to determine which group policy takes precedence, NT uses the group priority order that the administrator defines.

In much the same way individual policies beat out group policies, group policies take precedence over a default policy if one is defined. A default policy is used when no other policy definitions exist for a particular user. If you have only a default computer or user policy defined, SPE will apply this policy to everyone, including the administrator. Therefore, if you don't want to limit the administrator's access to the machine, at least be sure to define a group policy that creates no restrictions for the Domain Admins global group.

Using SPE as a Remote Registry Editor
You already know that you can use SPE to create policy files that automatically update an NT system's Registry. Perhaps you don't know, however, that you can also use SPE to directly edit the Registry of the local or remote NT computers. Let's say, for example, that you don't want to implement a domain-wide system policy, but want to use SPE to quickly and easily make the kinds of changes that Tables 1 and 2 describe to selected machines throughout the domain. Luckily, SPE lets you do this.

To open the Registry of a remote machine (which requires that you have administrative access to that machine), choose Connect from SPE's File menu. In the dialog box that appears, enter the NetBIOS name of the computer whose Registry you want to connect to (e.g., \\SEAN_PPRO). Next, in the Users on Remote Computer dialog, select the currently logged-on user (typically you'll find only one) whose user profile you want to modify. (If you plan to modify the user profile of a particular user, first make sure that the user is logged on to that computer; otherwise, you can't edit the user's profile via SPE.)

At this point, SPE displays icons for a computer and user as usual, but this time, the icons represent live entries from an NT system's Registry rather than a static system policy file. You can now make the same kinds of changes you usually make, but in this case, NT will change only that particular machine's configuration. When used this way, SPE is a graphical front-end for editing portions of the Registry. It provides better explanations of the Registry entries you're modifying and an easier interface for making the modifications than the standard NT Registry editors.

Some Potential Gotchas
Look out for a few gotchas with SPE. First, be careful editing system policies. Mistakes are easy to make, especially with items that are negative statements such as "Do not display last logged on user name," or "Disable Registry Editing Tools." Disabling these entries means that you do want that statement to be true (e.g., if you clear the check box to disable the first entry mentioned, you're saying, "Do display last logged on user name"). If you're not careful, you can set up an entry to do exactly the opposite of what you intend. Remember also that you are not obligated to set a checked or unchecked state for every item in the display. If a particular entry is irrelevant for your organization or already defaults to the correct value, you don't need to enable or disable the value.

Also, put the policy file for your domain in the proper place on the Primary Domain Controller (PDC). For system policies to take effect, the PDC must find a policy file, ntconfig.pol, in its NETLOGON share, which is the %SYSTEMROOT%\SYSTEM32\REPL\IMPORT\SCRIPTS folder by default. If the file is there and named correctly, the NT clients will automatically receive the Registry updates (in the system policy file) that are appropriate for their machine (based on the computer name, username, and group memberships). If the file has a different name or is elsewhere on the PDC, client workstations won't properly locate and process it.

Another oft-overlooked item is the failure to create special provisions for administrators and power users. The failure to create exception policies for these users when you define a system policy file can cause unnecessary restrictions on their desktop environments until you redefine the policy. When you create a new system policy file, set up policies with the appropriate settings for these users, right off the bat.

Finally, a special gotcha can occur in some multidomain environments. You can have problems when users log on to their domain account with a computer in another domain but the domains don't use system policies. Remember the source of a system policy is always the user's logon domain and not (necessarily) the domain where the computer is physically located.

Let's say you log on using your account in the SALES domain (your home domain) from a machine in the FINANCE domain (a foreign domain trusting the SALES domain). If system policies are in effect in the SALES domain, the machine you're logging on to will receive all the system policy updates. Even after a user logs off the machine in the FINANCE domain, the policies will remain in effect because later FINANCE domain logons won't reset system policy on that machine (because FINANCE doesn't use system policies). To prevent this situation when you're implementing system policies in a multidomain environment, be thorough and implement them in every domain; this method will ensure Registries are reset properly.

Differences Between the NT and Windows 95 SPE
If you've used the Windows 95 SPE to manage your Win95 workstations, you might wonder if you can combine functionality here. Can you use this NT version of SPE to create one unified system policy file for both your NT and Win95 client workstations?

The SPE online Help file alludes to the fact that some templates included with SPE contain Win95-specific Registry settings. Unfortunately, the differences in the NT and Win95 Registries preclude creating one, all-encompassing policy file that works with both Win95 and NT systems.

However, you can use the NT 4.0 SPE to manage your NT and Win95 system policy files independently of one another. To do so, you have to create and edit the ntconfig.pol file with SPE from an NT system and create and edit the Win95 system policy file while running SPE from a Win95 system. This last point is especially important: You can successfully create a Win95 policy only with NT 4.0's SPE from Win95. Although you can create Win95 system policy files with SPE under NT, they won't work once implemented. Furthermore, when creating and editing the NT system policy, be sure to have the common.adm and winnt.adm templates loaded; when creating the Win95 policy file, use the common.adm and windows.adm templates. The common.adm policy template file contains Registry settings common to both NT and Win95 computers, whereas the windows.adm and winnt.adm files contain Win95 and NT-specific Registry settings, respectively.

Although you can use the NT 4.0 SPE utility to create and manage a Win95 system policy file when using SPE from a Win95 workstation, be aware of a few differences between NT 4.0 SPE and the Win95 version. One difference is that the NT 4.0 version of SPE is capable of using multiple .adm Registry templates simultaneously; Win95 SPE can use only one at a time. Despite this limitation, I find that the default template file Win95 SPE uses (admin.adm) includes some useful entries I did not find in the two files (common.adm and windows.adm) the NT version includes. Capabilities such as restricting the Network Control Panel Applet are conspicuously absent from the NT version. Check the settings available in both the NT version and the Win95 version before deciding which SPE version to use. You can have the best of both worlds if you use the admin.adm template to create a Win95 policy file with NT SPE. Copy the admin.adm file to the \windows\inf directory of the Win95 workstation you use to create the policy.

An Invaluable Tool
NT SPE is an invaluable tool that no NT network administrator will want to live without. It is a multipurpose application that can serve as an alternative to the somewhat foreboding NT Registry editors, as a Registry editor for remote workstations, and as a centralized control mechanism for implementing domain-wide computer and user policies.