Further Explorations of the NT System Policy Editor

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.