Using System Policy Templates

As a Windows NT systems administrator, part of your job is choosing the right tool to use for the job. One of the more versatile tools in NT is the System Policy Editor (SPE) because it enhances network administration. It lets an administrator configure the NT Registry either directly over the network, or by creating policy files that are applied to a computer's Registry when a user logs on. But, the SPE can modify only Registry entries for which a policy template exists.

Fortunately, you can create custom policy templates easily. For a recent project, I spent a lot of time writing custom policy templates. During the process, I learned that documentation on writing templates is scarce and that you can write more straightforward templates than the ones NT provides.

You can load templates into the SPE to configure custom changes to most parts of the Registry. When you use the SPE instead of the Registry editor, you reduce the possibility of accidentally damaging the Registry. You can easily make a mistake with the Registry editor, particularly if you need to set multiple values. But the SPE follows the actions you define in the policy template and always makes the same changes.

Custom policy templates play a large role in Microsoft's Zero Administration Initiative. The Zero Administration Kit (ZAK--available at http://www.microsoft.com/windows/zak) contains configurations for two sample end users: a task-based user who uses one task-based application (Taskstation) and a slightly more advanced user who has access to two or three line-of-business applications (Appstation). What makes the Task station and Appstation configurations work is in large part custom policies.

This article is not a tutorial on using the SPE. For this article, I assume you are comfortable using both the Registry editor and the SPE. (For a good description of using the SPE see Robert Slifka, "How to Edit NT 4.0 System Policies," February 1997, and Sean Daily, "Further Explorations of the NT System Policy Editor," April 1997. For more information on editing the Registry, see Christa Anderson, "Care and Feeding of the Registry," December 1996.) Once you understand the format and the limitations of policy templates, you can begin to apply them to suit your needs. We'll look at several scenarios to get you thinking about how you can use these powerful tools.

Policy Template Format
By default, NT stores policy templates in the \%systemroot%\inf directory. Each policy template file has three major sections: CLASS MACHINE, CLASS USER, and \[strings\]. The CLASS MACHINE section defines which options will appear for a computer policy, and it affects Registry entries in HKEY_LOCAL_MACHINE. The CLASS USER defines which options are available in the SPE when you work with a user or group, and it affects Registry entries in HKEY_CURRENT_USER. Finally, the \[strings\] section defines string variables that you can use in the other two sections. Screen 1 shows the SPE in policy mode. Each user and group icon represents a set of configuration instructions based on the contents of the CLASS USER section of the loaded policy templates. Each machine icon represents configuration information based on the CLASS MACHINE section of the loaded policy templates.

The major classes contain categories. Categories appear in the SPE Properties window as a book icon, as Screen 2 shows. You use categories to break up the policies into a logical hierarchical view. For example, in the WINNT.ADM policy template that comes with NT 4.0, the top-level categories for the CLASS MACHINE section are Network, Printers, Remote Access, Shell, System, and User Profiles. Categories can contain either other categories (in WINNT.ADM for example, the System category is further subdivided into Logon and File System categories) or policies.

Table 1, defines the format for policy templates. You can refer to these definitions when you write templates. Much of this information is available from other sources such as Microsoft's Zero Administration Kit and the Windows 95 Resource Kit (the NT policy templates are a superset of the Win95 templates). But some functions documented here (e.g., NoSort and ExpandableText) are not documented elsewhere.

When you edit a policy file or Registry with the SPE, policies appear in the top half of the SPE properties window with a check box. You might recall from Robert Slifka's article, "How to Edit NT 4.0 System Policies," February 1997, the SPE has two modes: Registry mode and Policy mode. You use Registry mode to directly edit the Registry and Policy mode to create or modify policy files. In Registry mode, the policy checkboxes have two states: On and Off. In Policy mode, these checkboxes have three states: checked (or apply in an on state), unchecked (or apply in an off state), and grayed out (or ignore this policy).

Simple yes/no-type policies don't need to go any further. However, if the Registry data is more complex than you can handle with a simple yes or no answer, a policy can have several parts. With a multipart policy, you can use the additional parts to control multiple values when the policy is in an on, or apply, state. An excellent example of a large, complex policy is the color scheme policy that comes in the COMMON.ADM standard template. Here, you can choose from several options and, based on your choice, modify 25 Registry entries.

What's Up with the \[strings\] Section?
The \[strings\] section defines text variables that you can use in other parts of the policy template instead of directly using the string. I'm not sure why you would want to do this, though. If you look at the policy templates that ship with NT and Win95, you see that Microsoft templates rarely use strings in-line in a template. These templates are full of lines such as CATEGORY!!VARIABLE_NAME. Variables tend to make templates less readable and double the file size. For every reference to a !!VARIABLE_NAME in the CLASS MACHINE or CLASS USER section, you must have an equivalent !!VARIABLE_NAME="Variable Text" in the \[strings\] section.

I prefer to put the text in-line in the template. In-lining the text makes the template shorter and easier to read. Unless I have a string that will appear more than twice in the template, I do not use string replacement variables. The clarity of the template more than makes up for any potential savings from using the variable instead of retyping the text.

Policy Limitations
Policy templates offer a convenient filter through which to view parts of the Registry. They have limitations, though. The Win95 Registry supports two data types in NT: variable-length string and binary. The NT Registry supports several other data types, but you can modify only the REG_SZ (string), the REG_EXPAND_SZ (expandable string), and the REG_DWORD (4-byte integer) entries through system policies.

Because policies do not support all the Registry data types, you cannot modify some Registry values. For example, you cannot write a policy to fix the replication bug in NT 4.0. Directory replication in NT 4.0 doesn't work until you add a line to the Allowed paths value in HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Control\SecurePipeServers\Winreg. Because this value is the REG_MULTI_SZ (multi-line string) type, the SPE cannot modify it. If you wrote a policy to modify this value, you might change the data type and cause unpredictable results. Luckily, most Registry entries are REG_SZ, REG_EXPAND_SZ, or REG_DWORD, which are the data types system policies support.

The rest of this article details several situations where no convenient user interface control exists for some feature in the Registry. For each situation, I explain how to create a policy template that lets you control an entry with the SPE.

SCENARIO 1
A System Policy for Controlling the WINS Proxy Flag
WINS resolves computer names to IP addresses. However, some older network client software (e.g., LAN Manager 2.x) does not support WINS. For these clients, you can configure an NT machine to act as a WINS proxy agent on the local network. Looking for a server's IP address, the non-WINS client will generate a broadcast on the local network. The WINS proxy agent will listen for these broadcasts, forward them to a remote WINS server, and return the desired server's IP address to the non-WINS client. Having one WINS proxy agent on a segment with non-WINS clients can let these clients access resources that they ordinarily wouldn't be able to. Having more than one WINS proxy agent on a segment or installing a WINS proxy agent on a segment that doesn't have non-WINS clients will not increase functionality but will create additional network traffic. (For more information on WINS proxy agents, see David Lafferty, "Setting Your WINS Strategy," and Mark Minasi, "WINS Proxy Agents")

In NT 3.51, the network applet in Control Panel lets you control whether an NT machine acts as a WINS proxy agent. In NT 4.0, this utility doesn't exist. Microsoft removed it because you rarely need proxies. If you need WINS proxies, you can create a policy template to have the SPE control this function.

The Registry entry that controls whether a computer will act as a WINS proxy agent is in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters. If you set EnableProxy to 1, the computer will act as a WINS proxy agent; if you set it to 0, it won't.

Creating a policy is fairly straightforward. Screen 3 shows how simple a policy entry in a template can be. The first line begins with the keyword Policy. The name of the policy as it will appear in the SPE (in this example, Enable WINS Proxy Agent) comes next. The second and third lines specify the Registry key and Registry value this policy will modify. The KeyName keyword specifies all but the hive of the Registration key. The policy class defines the hive. If the policy is in the CLASS MACHINE section, the hive is set to HKEY_LOCAL_MACHINE. If the policy is in the CLASS USER section, the hive is set to HKEY_CURRENT_USER. Because this value is in HKEY_LOCAL_MACHINE, this policy needs to be in the CLASS MACHINE section of the template. The ValueName keyword entry specifies the value.

For this scenario, set the Registry value to integer 1 or 0. You aren't limited to numeric values though. You can set the values to strings, such as ValueOn "on" and ValueOff "off." You can even delete an entry from the Registry with the ValueOff or ValueOn Delete statements.

Remember, ValueOn 1 is not the same as ValueOn Numeric 1. In the first case, the policy stores the value in the Registry as type REG_SZ (string); in the second, the policy stores the value as type REG_DWORD (integer). Accidentally storing a string value where the operating system expects an integer can cause unpredictable results (up to and including making your machine unbootable).

You must include both a ValueOn and a ValueOff statement for each policy you create. When you use the SPE in Registry mode, the SPE uses these statements to determine the current state of the Registry. If you don't include them, the SPE can make an incorrect assumption and when you save your changes, unintentionally modify something you did not want to change.

For example, consider the WINNT.ADM file that ships with NT 4.0. The first two policies in that file control whether NT will automatically create the administrative (c$, d$, etc.) shares. As shipped with NT 4.0, these policies don't have a ValueOn statement. If you edit the Registry with the SPE and don't specify that you want the administrative shares created, NT will remove the administrative shares by default. Service Pack 3 for NT 4.0 has an updated WINNT.ADM file that does not have this error.

Because you should install a WINS proxy agent on only one or two machines per subnet, you might want to display a message in the SPE explaining the rules for using WINS proxy agents. You can use a Text part in the policy to display a line of text in the bottom half of the policy editor dialog. Text parts only display information; they do not modify the Registry.

Because the SPE will not break text lines and doesn't have a horizontal scroll bar, take care to break the text lines at an appropriate place. Unfortunately, trial and error is the only way to determine the optimal line breaks.

I just described what you can do with a simple yes or no policy. To accomplish more, you must create a multipart policy.

SCENARIO 2
Automatic Logon
Suppose you want to configure a machine as a publicly accessible information kiosk. In this case, you don't want someone to be able to unplug and re-plug the power cable and get a logon prompt. You might consider using an automatic logon for an NT machine. This way, on power-up, the machine can automatically log on to the network and begin the kiosk application. You cannot configure automatic logon through the standard user interface, so you need to create a policy to configure automatic logon.

For an automatic logon to function, you must set four values in the Registry. In HKEY_LOCAL_MACHINE\SOFTWARE\Windows NT\CurrentVersion\WinLogon, set AutoAdminLogon to 1. Then, set DefaultUserName, DefaultPassword, and DefaultDomain to valid values.

Given this information, you want to create a policy that, when selected, requires the user to enter a value for the three logon values. Additionally, because DefaultPassword is stored in clear-text, when this policy is unselected, you'll want to delete these values from the Registry entirely.

Screen 4 shows the policy for this scenario. Notice that the policy does not specify KeyName. The policy inherits its KeyName from the category, and the parts of this policy inherit their default KeyName from the parent policy. This behavior is standard; if the KeyName is not defined for a category or policy, it is inherited from its parent category or class.

Note also that when you un-select this policy, the policy deletes all four values from the Registry. The policy deletes the AutoLogon value in the ValueOff statement and uses an ActionListOff statement to delete the other three values. Again, you must include the ValueOn and ValueOff statements in each policy so the SPE can determine the current state of the Registry when operating in Registry mode. You can configure the Domain part of this policy as a combo box (as I've done) instead of simple text. This approach lets you offer suggestions but still lets users enter whatever they want. The Maxlen parameter in the Domain part also prevents a user from entering a domain name longer than 15 characters. I've also made Username, Password, and Domain required so that if users select the automatic logon policy, they must enter a username, password, and domain in the SPE. After all, if you were able to turn on automatic logon and then leave the username, password, or domain field blank in the policy, the automatic logon wouldn't know what these values were and would fail.

SCENARIO 3
Domain Controller Functions
When a Backup Domain Controller (BDC) pulls changed security accounts database information from the Primary Domain Controller (PDC), the BDC checks the Replication Governor parameter to determine how much network bandwidth to use. By default, this traffic can take up to 100 percent of the network bandwidth and affect an end user's ability to access resources. On the other side, the PDC maintains a list of account changes that have not been replicated to the BDCs. By default, this log (\%systemroot%\netlogon.chg) size is 64KB.

If you reduce the value in the Replication Governor parameter, you can end up with more account changes waiting to be replicated than space available to hold them in the netlogon.chg file. In this case, NT marks the PDC for full database synchronization and sends the full accounts database to the BDC (in a large organization, perhaps 40MB), instead of sending only the changed account data. If you throttle back the Replication Governor on the BDCs, increase the size of the change log on the PDC. Because this increase carries no performance penalty, always increase the size of the change log.

Because these values affect only domain controllers, the user interface doesn't include controls to manage them. But, you can create policies that will let you set these parameters.

First, you need to adjust the Replication Governor parameter.This value is stored in HKEY_LOCAL_MACHINE\
SYSTEM\CurrentControlSet\Services\NetLogon\Parameters as the Replication Governor value. Because this value is a numeric percentage, valid values range from 0 to 100. In the example policy in Screen 5, the Replication Governor parameter has a minimum value of 0, a maximum value of 100, and a default value of 100.

When you define a part as numeric, the SPE puts spin buttons (the small stacked buttons that let you adjust a numeric value) to the right of the input field. The default increment for the spin button is 1. You can use the spin x keyword if you want to increment or decrement the spin control by more than 1. If you want to remove the spin control entirely, use spin 0.

How about the change log size? A couple of factors make using a simple numeric input type impractical. First, the change log can be as small as 64KB or as large as 4MB. Also, the change log size must be a multiple of 64KB. To top it off, NT must store the size as the total number of bytes. To prevent the user from entering an invalid value, use a drop-down menu, as the policy template in Screen 5 specifies and the window in Screen 6 shows.

Typically, when you use the SPE, items in a drop-down menu appear canonically. In the case of the policy you see in Screen 5, this type of organization would cause the SPE to display the entries out of order. I used the NoSort keyword to force the SPE to display the list in the same order as is in the template file. In Registry mode, the SPE will compare the current value in the Registry with the values in the list and display the appropriate name in the list box by default.

SCENARIO 4
Controlling the User Environment
When you type a universal resource locator (URL) into Internet Explorer (IE), the software remembers the typed URL and stores it in a drop-down menu in the address control. If you are an IS manager in a large company, you can customize the links IE displays in the address drop-down menu to include several company-specific sites.

You can go to each machine in your organization and manually enter the URLs, but that approach is time consuming. Instead, you can create a policy that will let you add links to this list. The list of URLs in the address drop-down menu is in HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\TypedURLs. NT stores each URL with the value name urlx, and the data is the URL, as Screen 7 shows.

For all the formats we've looked at so far, the Registry key and value that the template modifies are fixed when you write the policy. With the ListBox part, you specify only the Registry key, not the value. The data you enter in the policy determines the value.

Because the value names are all of the format url1, url2, etc., I used ValuePrefix "url," as the policy template in Screen 8 shows. This command makes the policy add the data from the policy into the Registry in the expected format.

Because you don't want to delete the user's favorite sites, the Additive keyword is important. This variable tells the policy to add the information to any existing values in the Registry. Without the Additive keyword, the policy will delete existing values and insert the entries from the policy template. Without the Additive keyword, users lose typed URLs each time they log on.

SCENARIO 5
File Associations
You don't need to specify a prefix using the ListBox part. Using ExplicitValue, you can enter the value and the data. For example, consider a policy that modifies HKEY_CURRENT_USER\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Extensions. Here, NT stores user preferences for fileassociations, as Screen 9 shows. This policy lets a user specify the application associated with a file extension. A standard way for enforcing standards for users' file associations on an NT network does not exist. But, you can create a policy.

If you want to register companywide preferences, you must specify the extension as the value, and program as the data. Instead of ValuePrefix, use Explicit Value, which will let you enter both the value and data. ExplicitValue and ValuePrefix are mutually exclusive; you cannot use them together. You can leave both out of the template, in which case the policy will use the data for the value name.

In the example policy in Screen 10, I used the Additive keyword so that when I apply the policy, I don't use the user preferences that the policy doesn't affect. However, if duplicate value names exist in the Registry and the policy, the policy replaces the value that is already in the Registry. For example, if a user has set the .doc extension to be associated with WordPerfect 5.1 and the policy is configured to associate .doc files with Word 97, the policy will overwrite the user preferences, ensuring a consistent organizational standard.

Wrapping It Up
The SPE is a powerful systems administration tool. But, it is only as powerful as the policy templates you use with it. I have shown you how to create a policy template that lets you control almost any aspect of the computers in your organization. Creating custom templates costs extra up front, but the speed and safety of using policies and the SPE to modify Registry parameters recovers those costs rapidly.