Windows NT System Policies

Another challenge in implementing system policies in your enterprise is the limited tools available for managing the policies. Microsoft provides only SPE and a few policy templates. SPE is the only meaningful method for viewing the contents of a policy file. Most large enterprises have strict change and version control practices to prevent one change from crippling the computing environment. If you make frequent changes to an enterprise policy file that affects hundreds or thousands of workstations, the only version-control tools available are the policy file's date and timestamp. Moreover, the SPE has no reporting tools for you to list current policy settings or analyze the effective policies for user and group combinations. NT 5.0 needs to provide more tools for organizations to use policies effectively.

Despite the caveats, you can use system policies to deliver meaningful desktop control in your NT 4.0 environment. But you'll want to keep the number of global policy groups to a minimum (three to five), avoid using user- or machine-specific policies, avoid placing users in many overlapping global policy groups, and limit users to one global policy group at a time if possible.

You apply a policy file at the domain level. Therefore, try to keep the policies that you implement relevant to domain-wide changes, and avoid making many small, application-specific Registry changes within the policy. For example, if you want your users to use the same background bitmap on their desktops, use the policy file for such a change. But don't use policies to map drives or printer connections that might change frequently or that are specific to a user's location.

Avoid making frequent changes to your policy file. If you have to update your policy file frequently, record the date and timestamp of each version, and keep the last version available in case you need to revert to it. Remember that changing policy files for your entire domain is as easy as copying a file to your domain's replication directory.

Keep a chart that lists your current policies by group and current state. This chart helps you see how NT applies different policies as users move between global policy groups or become members of multiple global policy groups.

Troubleshooting and Tweaking
After you decide to implement system policies, you need to learn how to troubleshoot problems. System policies don't log information to NT's event logs when a user logs on, but you can log a policy file's activity. First, you need a copy of a checked-build or debug version of the NT userenv.dll system file. You can get this file from Microsoft Support or if you subscribe to the Microsoft Developer Network (MSDN). Make a backup copy of userenv.dll, and copy the debug version of this file to the %systemroot%\system32 folder on the system where you want to log the policy file's application. You need to modify the Registry to enable logging. In the Registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\ CurrentVersion\Winlogon, create a new value entry, User-EnvDebugLevel (type REG_DWORD), with hexadecimal value 10002. Shut down and restart your system. At next logon, your system will write the text file userenv.log to the C drive root. This file shows user profile and system policy processing. For information about reading the log file, see the Microsoft Support Online article Q154120 (http://support.microsoft.com/ support/kb/articles/q154/1/20.asp).

The default policy filename is ntconfig.pol, and the default location for the file is the Netlogon share on any domain controller in your authentication domain. However, if you need to implement multiple policy files in a domain, you can change the policy filename and location for each workstation. NT's common.adm template file has a policy setting for making these changes. From Default Machine, go to the Network\System Policies Update\Remote Update field. This policy adjusts the values in the Registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Update. The UpdateMode value controls whether the workstation looks in the Netlogon share (Automatic Path: Registry value of 0*1) or a path that you specify (Manual Path: Registry value of 0*2). If you specify a value of 0, the workstation ignores the policy files you have in place. If you specify Manual Path, the workstation uses the NetworkPath value. You can use NetworkPath to redirect your standard policy file to a directory other than Netlogon (e.g., c:\localpolicy\ntconfig.pol). You can also specify a different policy filename in the Netlogon share: Use the NT 4.0 environment variable %logonserver% in the path you specify. For example, to point a workstation to an ntconfig2.pol policy file, specify %logonserver%\ntconfig2.pol as the value of NetworkPath. Using alternative paths to policy files is useful for testing new policies before you put them into practice and affect all your users.

NT 4.0 policies have some unusual behavior. You must install Service Pack 3 (SP3) on your workstations for policies to function correctly. Without SP3, your system ignores global policy groups and adheres only to the Default User policy. This behavior also occurs if you use a version earlier than 4.11 of Novell's intraNetWare Client for Windows NT. I've had problems applying policies against built-in NT groups such as Domain Admins. When you create a policy to use against Domain Admins, the policy works only the first time a user in the group logs on to a workstation in the domain. Subsequent logons don't use the policy. This problem is most likely a bug in NT's system policies, although Microsoft hasn't documented the problem on its Support Online Web site.

System Policies in NT 5.0
NT 4.0's system policies are useful, and you can expect even better policies in NT 5.0. Policies will be more granular, and you will be able to apply them at the domain, site, or organizational unit (OU) level in Active Directory (AD). Policies will control more than desktop lockdown. NT 5.0's group policies will be a key element in the application management feature of the operating system (OS), where you distribute icons to users' desktops based on their location in the directory and the user groups they belong to. To prepare yourself for NT 5.0's system policies, you can implement policies in NT 4.0 today and learn about their powerful features and functions.