Windows NT System Policies

Share and Share Alike
One advantage of the NT 4.0 Explorer shell is that you can represent most desktop elements, such as application icons and file folders, as simple file system objects--shortcut or .lnk files. NT 4.0's Explorer gives you better control over desktop objects than NT 3.51's Program Manager did (i.e., when program groups were binary files or binary Registry values that were difficult to manage). Explorer's default system policy templates let you create customized user- and machine-specific shared folders that you can centrally manage and deliver to the user's desktop in one step. Instead of sending shortcuts to hundreds or thousands of desktops when you implement a new application, you can use system policies to point users to a centralized folder on a server where these shortcuts reside. When you deliver customized user- or machine-specific folders via a system policy, the policy file redirects the user- or machine-specific path of various Explorer shell elements to the location you specify in the policy file.

For example, the default location for a machine-specific (or common-group) desktop icon is %systemroot%\profiles\All Users\desktop. But you can use a machine-specific setting in the NT shell policy, as Screen 1 shows, to redirect this path to a server share (e.g., f:\folders\desktop). The NT shell policy is part of the winnt.adm policy template file. When users log on to their workstations and receive the system policy, the policy redirects the machine-based, or common, desktop folder from the default location in the All Users directory to the server share you specified in the policy. Users who log on to local machines receive desktop icons from the server-based folder, so you can modify the contents of one server-based folder to make changes to hundreds or thousands of user desktops.

The machine-specific shared folders model also applies to user-specific shared folders. In a system policy file, you can specify custom folders for a user or user group. From the same NT shell policy, you can set server-based folder paths for the desktop, Programs folder, Startup folder, Network Neighborhood, and Start menu. These policy folders redirect user profile folders to other locations. For example, the default location for desktop icons on a per-user basis is %userprofile%\desktop. But you can create a policy for a user-specific custom folder, telling the Explorer shell to replace the user profile path with the path you provide in the policy. After the policy file is in place, you can redirect many user desktops to a shared area on a server, where you control the content. Give read-only access on this shared folder so that users can't write or delete icons that can affect other users, or place extraneous shortcuts, folders, or files on their desktops. This restriction is helpful if you use roaming profiles, because users who place large documents on their desktops and in their user profiles might adversely affect network performance at logon and logoff times.

NT System Policy Challenges and Benefits
Implementing NT 4.0 system policies can be complicated, and the current system policy architecture has limitations. But system policies provide significant benefits, and they will play an important role in NT 5.0.

You can distribute policies on a user, machine, and global group basis. If you plan to provide global group-based policy distinctions, limit the number of global groups in your policy--perhaps three to five groups. Managing global group-based policies can be difficult because of the nature of policy application. NT applies policies cumulatively (assuming you don't specify user-specific policies, in which case NT ignores all group policies), based first on Default User, then defined global groups, then machine-specific policies. You can prioritize NT's application of global group-based policies in SPE so that users who belong to multiple policy groups will receive a predictable policy. Every user gets the Default User policy, unless you define a user-specific policy or remove the Default User policy. Keep in mind that when a user gets an effective policy, this policy includes the information you defined in the Default User policy. If you retain the Default User policy, you must decide how you will use this policy group. Users who are not members of another defined policy group will receive only the information Default User gives them. You can lock down Default User and remove restrictions with other policy groups, or you can give an open desktop to users who aren't in a policy group.

Each policy item can be included (selected), unchanged (grayed out), or removed (blank). You can easily interpret these states independently, but when you apply multiple policy groups on top of each other, you might have trouble determining the resulting policy. A typical user gets the Default User policy and one or more global group-based policies. Thus, you must consider all the possible combinations of selected, grayed out, and blank policy items. If a user is a member of multiple policy groups, you need to know how each policy group is applied, and what the effective policy is when you apply all groups by priority. You must consider how policy items' states will affect users who move between policy groups. You need to ensure that you undo policy items correctly as a user moves from a more restrictive to a less restrictive policy group. To further complicate matters, some policy items can undo each other.

For example, if you use the ZAK policy templates, the Shell\Restrictions\HideDrives in My Computer policy, which is part of the common.adm template, conflicts with the ZAK Policies\Windows NT\Drives\Restrictions\Show Only Selected Drives policy, which is available in the zakwinnt.adm template. You have to gray the restriction in common.adm and use only the zakwinnt.adm restriction to hide drives. Otherwise, the common.adm policy item will automatically change when you save the policy.