Managing the Windows 2000 Registry By Paul Robichaux 1st Edition August 2000 1-56592-943-8, Order Number: 9438 558 pages, $39.95

Chapter 7
Using Group Policies

One of the most powerful capabilities included with Windows 2000 is the Group Policy mechanism. Active Directory provides a comprehensive way for administrators to manage network resources. When you use Active Directory, Group Policy allows you to apply policies to users and computers over the entire hierarchy of your network, from entire domains right down to individual computers.

As you learned in the preceding chapter, the Windows NT 4.0 System Policy Editor is used to configure membership-based permissions for users, groups, and computers in a domain. System policies, such as desktop appearance and program control, can be distributed and applied to whole domains. For Windows 2000 network clients, policies are no longer Registry-based; they're replaced by Group Policy. By associating policies with actual objects in Active Directory, each site, domain, and organizational unit can distribute its own set of policy demands. You manage this capability with the Group Policy snap-in for the Microsoft Management Console (MMC). Group Policy, sometimes referred to as the Group Policy Editor, uses policy files to interface to a system's Registry.

What Are Group Policies?

In a general sense, policies define what a user can and can't do. Under Windows 2000, system administrators use Group Policy to manage the policies that apply to computers and users within a site or domain. These policies define certain aspects of the user's desktop environment. They specify system behavior, and they restrict what users are allowed to do. In short, a policy is simply a group of related settings an administrator can set.

Many of these policy settings are applied to keys in the Registry. The specific keys and values written into the Registry depend on the policies you're trying to enforce. In the Windows NT world, policy changes are persistent because they're applied throughout the Registry, and no mechanism exists to sweep away the changes once they're made (though one policy's changes can be overwritten by another set of changes that occurs later).

Under Windows 2000, Group Policy settings that modify the Registry are always applied in one of four Registry subtrees. Microsoft recommends that Windows 2000-savvy applications should look for policy information in HKLM\Software\Policies and HKCU\Software\Policies. If they don't find their settings there, they can look in HKLM\Software\Microsoft\CurrentVersion\Policies and HKCU\Software\Microsoft\Windows\CurrentVersion\Policies. If the application still hasn't found the settings it needs, it can look elsewhere in HKCU or HKLM, or even in INI files (though that's strongly discouraged). None of these subtrees may be modified by nonadministrators.

Elements of a Group Policy

Much the same way that the Registry is arranged in a hierarchical structure, policies are categorized into sections and subsections. The sections and subsections that build the hierarchy of Group Policy are called categories. Think of categories like folders: a group policy contains one or more categories, and each category may contain subordinate categories. The subordinate categories may contain their own subcategories, and so on. In addition to containing subcategories, categories contain the specific policies an administrator can configure.

Each policy controls the behavior of one aspect of a user's environment. For example, a simple desktop policy specifies whether to hide all icons on the desktop. There are more elaborate policies that define the default quota limit and warning level for an individual filesystem.

Remember that these specific policies are applied to keys in the Registry. The number of Registry keys affected depends on the complexity of the actual policy. A single policy can consist of multiple settings, or parts. A part represents a single value that is stored in the Registry. Each policy is made up of zero or more parts. The policy for hiding icons on the desktop does not contain any parts; it's simply enabled or disabled. The quota limit and warning level policy, however, contains a number of parts, one for each value that needs to be stored: the default quota limit value, the measurement units for the quota limit, and so on. Since policies require values of various data types, parts differ as to their permissible values. Some parts require strings, some require numeric values, and some parts' values are restricted to a set of predefined values.

User Versus Machine Policies

There are two types of group polices: polices that apply to the computer and policies that pertain to users. Computer configuration policies apply to all users on a computer and are active whenever a machine is running. They're stored in the HKLM section of the machine's Registry and include policies that define security settings, desktop appearance, and startup and shutdown scripts. They're applied when the machine boots. This is different from System Policy Editor machine policies, which are applied when a user logs on.

User configuration settings, on the other hand, are active for each user on a computer. They're stored in the Registry under HKCU and define user-specific settings such as assigned programs, program settings, and desktop appearance. Unlike computer settings, which remain in effect until the computer is shut down, user configuration settings are reloaded for each new user. In this way, user policies can be downloaded for a user, regardless of what machine she logs into. You can specify user policies that can be applied to all users of a specific machine, or you can apply policies that apply only to specific users no matter where they log on.

TIP:  

Even though Microsoft uses the name Group Policy, you can't apply group policies to Windows 2000 groups (more on that later). This is a significant difference from the System Policy Editor mechanism.

Defining Group Policy Objects

In Windows NT 4.0, policies are created for users, groups, and computers. They're applied manually to individual machines or stored on domain controllers for replication throughout a domain. In Windows 2000, administrators can attach policies to Active Directory containers such as sites, domains, and organizational units (lumped together with the acronym SDOU), as well as to individual machines. These policies are stored in Active Directory Group Policy Objects, or GPOs. GPOs are associated with sites, domains, organizational units, and individual machines, and contain all the Group Policy settings an administrator can configure. The policy settings contained in a GPO are applied according to the SDOU membership of those users and computers; there's a set of rules I'll discuss in the next few pages that determines the effective policy applied to any given user or computer.

There are two types of GPOs: local GPOs and nonlocal GPOs (an inelegant if useful term). Local GPOs are stored only on local machines, while nonlocal GPOs are stored in Active Directory.

The local GPO

Regardless of whether a computer is part of an Active Directory environment or operates as a standalone machine, every system running Windows 2000 stores exactly one local group policy object (LGPO).[1] The LGPO contains the primary policies for that computer and the users on it. For a standalone Windows 2000 machine, these are the only group policies the computer sees. When the computer is component of a site, domain, or organization unit, nonlocal GPOs join and take precedence over the LGPO. If there's a conflict between LGPO policy settings and settings from the more influential nonlocal GPOs, the LGPO settings are overwritten.

TIP:  

GPO Rule #1: since local settings are applied first, they're always overwritten by settings in inherited nonlocal GPOs.

Policies and the Active Directory

The other type of GPOs, nonlocal GPOs (NGPOs), are stored in an Active Directory. Each NGPO is associated with a site, domain, or organizational unit. In contrast to locally applied policies, NGPOs are applied to users and computers that are members of various SDOUs. Each SDOU may have zero or more GPOs associated with it. The order of application determines which specific settings are applied.

The order in which nonlocal GPOs are applied respects the Active Directory hierarchy. Sites, the most broad and least restrictive of Active Directory containers, process group policies first. All groups within a site inherit the site's policies. Next, domain group policies are processed; containers beneath the domain inherit these settings. High- and low-level organizational units follow in succession.

How Are Policies Stored?

While the Group Policies snap-in quietly hides policy storage facilities from the user, seeing how policies are actually stored in Active Directory will help in understanding how effective policies are subsequently calculated and applied. In Windows NT 4.0, the System Policy Editor creates .POL files that contain Registry key and value pairs; these pairs are loaded into a machine's Registry when the policy is applied. Far from containing the contents of the entire Registry, these policy files contain only those values required to implement the desired policy. After the policy file is created, it can be applied manually to individual machines or stored on a domain controller for replication.

There's a similar mechanism for Windows 2000 policy settings stored in the Registry. The Group Policy snap-in stores Registry-based settings in a file named Registry.pol. The Registry.pol file is actually part of the group policy object. Although the format of the policy file differs from the Windows NT 4.0 style, the idea is the same. Separate Registry.pol files exist for the different root keys in the Registry that can be modified through Group Policy; one file contains customized Registry settings for HKLM, another contains settings for HKCU. When the Group Policies snap-in starts up, it creates temporary Registry hives for users and machines. If current policy files are available, they're imported into this temporary Registry. As you change policy settings, Group Policy modifies the temporary Registry under the node you've changed. When Group Policy exits, the temporary Registry is exported into the two Registry.pol files, from which the changes can be distributed.

Unlike Windows NT 4.0, however, policies are associated with sites, domains, and organizational units through GPOs. When Registry.pol files are created for nonlocal GPOs, they're stored in what's called a Group Policy Template. Along with administrative templates, scripts, and other GPO information, this folder structure includes user and machine subdirectories, which each contain their appropriate Registry.pol file.

The structure of the Group Policy Template

Group Policy Objects actually consist of two separately stored parts: the Group Policy Container (GPC) and the Group Policy Template (GPT). The snap-in doesn't differentiate between items that are stored in these two parts; all their data appears as a single seamless collection.

The Group Policy Template resides on the domain controller in a tree of folders called the System Volume (SYSVOL). SYSVOL serves the same function as the Netlogon share on a Windows NT domain controller. It's designed to store information that doesn't change very often. In addition to storing Registry.pol policy files, the GPT stores scripts, administrative templates, and other GPO-related files. The GPT is a folder structure with the following subfolders:

ADM

Contains administrative templates for this GPO

Scripts

Contains logon, logoff, startup, or shutdown scripts and other related files

USER

Contains the Registry.pol file applied to the HKCU portion of the Registry

USER\Applications

Contains application advertisement scripts (.AAS files) that advertise the availability of automatically installed applications to users when they log on

MACHINE

Contains the Registry.pol file applied to the HKLM portion of the Registry

MACHINE\Applications

Contains .AAS files for applications applied to computers, not to individual users

The GPC is an Active Directory object that contains metadata about the GPOs in it. Among other things, it contains information about the version of the templates it contains, status flags indicating whether the GPT is enabled or disabled for each SDOU, and a list of which items are contained in the GPO. This information indicates whether the GPO is enabled or disabled and helps keep the GPC synchronized with the GPTs.

How Are Policies Applied?

Applying a policy simply means merging the appropriate policy files into a computer's Registry under the respective root keys--HKCU for user-specific settings and HKLM for computer-specific settings. Once a policy file is retrieved, the individual policies contained within the file are compared against the Registry. As you'll see in the section that deals with editing policies, individual policies are set to one of three states: enabled, disabled, or not configured. Note that these states don't say what the policy does, just whether it is applied (enabled), not applied (disabled), or left alone (not configured).

When an enabled policy is encountered in the policy file, the parts of the policy are checked against the current settings in the four Registry subtrees that can contain policy settings. If a part's value matches the corresponding value in the Registry, no change is made. If, however, the part's value conflicts with the Registry setting, the Registry is changed to reflect the enabled policy. This value exchange is strictly a one-way push from the policy file to the Registry. Manual changes made to the Registry under HKCU or HKLM, with a Registry editor for instance, are not written out to a policy file. This keeps users from modifying administrator-defined policy settings.

Since each site, domain, or OU in Active Directory can have multiple policies, and since user and computer policies can exist both locally and in any SDOU, you probably have two questions at this point: when, and in what order, are policy files applied?

Applying computer and user policies

The only types of objects in the Active Directory environment that policies affect are users and computers. The Registry.pol file contained in the user subfolder of the appropriate GPT is downloaded and applied to the user (HKCU) portion of the Registry. Likewise, the Registry.pol file in the machine subfolder gets merged into the Registry under the machine (HKLM) root key. Machine settings are applied when the machine boots. User settings are downloaded each time a user logs on to a computer. This enables machine policies to persist while the more transient user settings are swapped in and out. This additionally allows users to log on to different machines and be greeted with a consistent set of policies (ignoring, for the moment, any differences in machine policies between different machines).

In addition to being applied during their respective initializations, both user and machine settings are applied during a periodic refresh cycle. This allows automatic updates of policies that have changed during the current session.

TIP:  

In Windows 2000, when user Registry settings conflict with computer Registry settings, computer settings generally take precedence. This is a convention followed by the operating system, rather than a rule of the Group Policy infrastructure.

Order of policy file application

I've answered the "when"; now on to the "in what order" question. Policy files are applied in a specific order that reflects the Active Directory structure. Since AD uses a hierarchy to categorize different objects in a network, its structure lends itself nicely to imposing a relative importance to policies. The order of application is as follows:

1. The LGPO for the target machine is applied first. Remember that one and only one LGPO exists on every Windows 2000 machine.
2. Any GPOs for the AD site are applied next, in an order you specify.
3. Any domain GPOs are applied next, again in the order you specify.
4. Any Organizational Unit GPOs are applied last, from the least restrictive to the most restrictive (parent, child, grandchild). At each OU level, order is specified by the administrator. For example, if a child OU has three policies specified, the administrator can arrange them in any order, but all the child OU policies are applied before any grandchild policies are applied.

The means that the last GPO to be processed is the GPO for the "lowest" OU. If you think about how Microsoft normally draws AD hierarchies (you know, the big triangle diagrams), this makes sense; the last GPO applied is the one for the SDOU that the user or computer is a direct member of. Processing the local GPO before any Active Directory GPOs gives the LGPO the smallest relative importance.

As policy files are processed, they're merged into the Registry under the appropriate keys. All applied policies contribute to the effective policy of the computer or user. Naturally, there will be instances where settings being applied for a policy conflict with earlier policy settings. By default, newer settings overwrite previous settings. In fact, these newer settings may in turn be overwritten by another, later GPO. It is possible, however, to enforce policies from a higher GPO (in effect, a policy applied earlier in the application order) so that they cannot be overwritten. This applies only to nonlocal GPOs; the LGPO settings can't be set absolutely. Later in the chapter, you'll see how the effective policies are calculated from the array of policy files that are applied to a system.

Introducing the Group Policy Snap-in

For defining and controlling how various components of Windows 2000 behaves for users and computers, Group Policy is used. Group Policy is a Microsoft Management Console (MMC) snap-in that allows you to manage the behavior of programs, network resources, and the operating system.

TIP:  

Under Windows NT 4.0, the System Policy Editor creates and edits system policies. While this editor is supplied in Windows 2000, its use is limited to supporting downlevel clients. Since it creates Windows NT 4.0-style system policy files, you still need it to support NT domains. Additionally, it's useful if you have Windows NT 4.0, 95, or 98 clients in your AD domains.

Adding the Group Policy Snap-in

To add the Group Policy snap-in to the MMC, run mmc.exe. From the Console menu in the MMC, choose Add/Remove Snap-in. Click the Add button on the Standalone tab and select Group Policy from the list of snap-ins provided. You're then required to choose a Group Policy Object to edit. Remember that group policy objects can be stored locally on a computer or can be linked to an Active Directory organizational unit, domain, or site. The Select Group Policy Object dialog defaults to the local computer as the target GPO but allows you to browse through domains, OUs, sites, and computers to select the GPO you're interested in editing.

Once you've decided on a GPO, click the Finish button and close the list of provided snap-ins. If everything went well, you're back on the Standalone tab of the Add/Remove Snap-in dialog, and you see your target GPO listed as a snap-in under to the Console Root. Figure 7-1 shows the Local Computer Policy as the only added snap-in.

Figure 7-1. The Add/Remove Snap-in dialog

You select the functionality of the snap-in by adding Group Policy extensions. Group Policy extensions correspond to areas of the Group Policy that you can edit. The following is a list of Group Policy extensions:

Administrative Templates (Computers)

Edits Registry-based policy information for computer configuration

Administrative Templates (Users)

Edits Registry-based policy information for user configuration

Folder Redirection Editor

Redirects Windows 2000 special folders (such as My Documents and My Pictures) to network locations

Remote Installation Services

Sets up client computers remotely

Scripts (Logon/Logoff)

Specifies scripts for user logon/logoff

Scripts (Startup/Shutdown)

Specifies scripts for computer startup/shutdown

Security Settings

Configures security for domains, computers and users

Software Installation (Computers)

Makes applications available to computers

Software Installation (Users)

Makes applications available to users

To add one or more extensions to the Group Policy snap-in, select the Extensions tab on the Add/Remove Snap-in dialog. By choosing Group Policy from the dropdown list of snap-ins that can be extended, the available extensions are displayed, as illustrated in Figure 7-2.

Figure 7-2. Available Group Policy Extensions dialog

You can select extensions on an individual basis or mass add all extensions by setting the Add all extensions checkbox.

TIP:  

To edit local group policy without having to endure the pomp and circumstance of the Microsoft Management Console and plug-ins, you can simply launch gpedit.msc. You'll be transported directly to a Group Policy window with focus on the local group policy object.

Learning the Group Policy Snap-in Interface

If you've already used any of the MMC snap-ins, you'll be instantly familiar with the interface for Group Policy. The console is divided into two panes: the left pane holds the console tree, and the right pane displays information such as policies and settings. Each node in the console tree under the Console Root represents an instance of an added snap-in. Thus, by adding Group Policy with different GPOs, you can manage multiple objects from the single console tree. Figure 7-3 shows a single GPO (the local group policy object) under the console root, with the Administrative Templates (Computers) and Administrative Templates (Users) extensions previously added.

Figure 7-3. The Group Policy MMC snap-in with Local Computer Policy added

Controlling what you see

The MMC provides a consistent interface for many facets of Windows 2000. The commands that modify the display apply to the MMC as a whole, not just Group Policy. The first thing you realize about MMC, as you start adjusting window sizes and resizing panes, is that MMC allows you to open more than one console window at a time. The Window New Window command creates a copy of the console window. This enables you to view policies of one GPO in the first window while concurrently viewing policies of a second GPO in another window.

The View menu provides a way to change the appearance of the console window. The View Customize command leads to a Customize View dialog that lets you configure which aspects of the MMC and snap-in you want available. Using the checkboxes in this dialog, you can hide or display the console tree, the standard menus, the standard toolbar, the status bar, the description bar, and the taskpad navigation tabs.

The right pane of the MMC displays pertinent information about the node selected in the console tree. The View menu provides four ways to view this information. The View Large Icons and View Small Icons commands provide pictorial representation in the right pane; however, this can be repetitious as Group Policy icons tend to be the same anyway. View List shows the same information in a single column. The most useful display command, View Detail, parses information into separate columns. Most leaf nodes in Group Policy contain a policy column and a settings column. In detail mode, you can sort this information by clicking a column heading; that column is sorted into either alphabetical or reverse alphabetical order.

The Vi ew Choose Columns command brings up a Modify Columns dialog that allows you to add and remove columns from the display list. This dialog additionally allows you to change the order of some columns.

Navigating the console tree

The console tree acts in much the same way as the Windows Explorer tree view. You expand branches by clicking the plus beside the node you want to expand and contract them by subsequently clicking the minus sign. You highlight a node to display its individual settings in the right pane. The up arrow icon on the standard buttons toolbar hikes you back up the hierarchical chain of the console tree until you reach the root.

Some of the nodes have special commands associated with them. For example, the Administrative Templates node allows you to Add/Remove Templates. To view the menu associated with a specific node, simply right-click that node. I'll explore some of these special commands in a bit.

Viewing policy properties

As stated previously and shown back in Figure 7-3, most Group Policy leaf node information contains policies and corresponding settings. To view the properties of a particular policy, right-click the policy in the right pane and select Properties.

Managing Policies

The Administrative Templates extensions to Group Policies handle all Registry-based policies in Windows 2000. In other words, Administrative Templates provide a mechanism for administrators to configure user interface settings that are stored in the Registry.

Two administrative template extensions can be enabled for a GPO, one for computers and one for users. In GUI terms, these extensions enable Administrative Template nodes in the console tree under Computer Configuration and under User Configuration. (Refer back to Figure 7-3 for a console tree that includes both Administrative Templates nodes.) Until administrative templates are added, however, these nodes are empty.

What Is an Administrative Template?

Administrative templates are ASCII text files, usually with a .adm extension, that tell the Group Policy interface what Registry settings an administrator can set. The template files specify what categories and subcategories should appear under the Administrative Templates node and how policy options are displayed. The Group Policy interface translates the template files into the GUI representation you see, from the intermediate folders down to the policy settings.

The Windows 2000 syntax for administrative templates encompasses the previous template syntax. You can use older NT 4.0-style administrative templates to create user interfaces in Group Policy, however, new templates can't be used with the System Policy Editor.

It's not a good idea, however, to allow NT 4.0-style policies to be applied to Windows 2000 clients, as could be the case in a mixed-mode domain with both NT 4.0 and Windows 2000 domain controllers. If, for instance, an NT 4.0 client is upgraded to Windows 2000, but the accounts of users on the machine continue to be managed by a Windows NT 4.0 domain controller rather than Active Directory, the user receives NT 4.0 user System Policy.

This could have an adverse effect on the computer's Registry. The reason is that Windows 2000 policies set keys and values in only specific areas of the Registry, namely:

• HKEY_LOCAL_MACHINE\Software\Policies
• HKEY_CURRENT_USER\Software\Policies
• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies
• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies

When Windows 2000 policy changes, these trees are cleared, and new policies are copied down. Windows NT 4.0 policies, however, don't recognize these Registry areas. The keys and values they write can invade any part of the Registry and persist until they're either manually deleted or reversed by a counteracting policy.

Adding Administrative Templates

Assuming you have the Administrative Templates extensions enabled for Group Policy, you can add administrative templates for computer and user configuration of a GPO. Under the GPO you wish to manipulate, expand either the Computer Configuration or User Configuration node. Right-click the Administrative Templates node and select Add/Remove Templates from the menu. The ensuing dialog, shown in Figure 7-4, lists the current policy templates.

Figure 7-4. The Add/Remove Templates dialog

To add additional templates to this list, select the Add button and browse for the desired template. Templates included with Windows 2000 are installed in the %SystemRoot%\inf directory and come with a .adm extension. I'll talk more about provided templates later in the chapter.

Understand that templates you add can contain settings for both Computer and User configuration. That is, there are sections for Registry keys under both HKLM and HKCU. It doesn't matter which node you add the templates from, the template is added to the Group Policy as a whole.

As you add administrative templates, category nodes appear beneath the Administrative Template branches in the console tree. Each template consists of a new set of categories, subcategories, and options to display to the user. These are interlaced into the settings of the currently loaded templates. Settings in the Computer section of the template appear under the Computer Configuration node; likewise, the User section populates the User Configuration Node.

Editing Policies

Using Group Policies to modify policies is quite easy. The templates you add to Group Policy provides the entire interface you need; what's left is deciding what values you want for your policies.

To edit a policy, expand the console tree until you find the category that holds the policies you want to edit. Once you highlight the target category, you see the category's policies in the right pane. If you've taken the advice earlier in this chapter, you have the display set to View Detail, and you can see the policies' current settings. A policy can have three settings; enabled, disabled, or not configured.

Right-click the policy you want to edit and select Properties (double-clicking works just as well). The property's edit dialog will appear. What you see--that is, what you're able to edit--depends on what parts make up the policy. You'll find that many policies are simply enabled or disabled, without any parts.

Figure 7-5 shows the policy edit dialog for the Limit profile size policy, which is found in the user section of the SYSTEM.ADM administration template, under the System category and Logon/Logoff subcategory.

Figure 7-5. The Limit profile size policy edit dialog

The policy tab is displayed by default. The Explanation tab merely contains a description of the policy. The first thing you see on the policy tab is a checkbox for the policy name. This is actually a checkbox with three states representing whether the policy is enabled (checked), disabled (cleared), or not configured (grayed out). When this checkbox is cleared or grayed out, the policy part inputs are disabled.

The policy in Figure 7-5 contains five parts that pertain to Registry keys and can be modified. The first part is an edit text box filled with a default string. The second and fifth fields are numeric inputs filled with default values. In addition to default values for numeric input fields, templates can also specify minimum and maximum values for acceptable user input. Lastly, two checkboxes accept Boolean input. In addition to strings, numbers, and Boolean values, part types include combo boxes and list boxes. Static text may also appear for directions or user information.

The buttons at the bottom of this dialog, Previous Policy and Next Policy, allow you to iterate through all the policies of this category without having to close and reopen the dialog.

Creating Your Own Administrative Templates

Since administrative templates are merely ASCII files, they can be opened with a text editor, modified, and loaded back into Group Policy. As you'll see in a moment, the syntax and language used in these files, while perhaps not instantly intuitive, is far from cryptic. These templates afford administrators the flexibility to create a "safe" conduit to nearly all Registry data that lives in HKLM or HKCU.[2] This can include configuration parameters for common programs such as Internet Explorer, as well as network and desktop settings. (However, note that there are already Group Policy templates for Office 2000 and Internet Explorer, provided as part of the Office Resource Kit. See http://www.microsoft.com/office for more details.)

Administrative Template files follow a basic structure that represents the hierarchy of categories, subcategories, policies, and parts you see in the Administrative Templates namespace. To illustrate the template format, here is an example template I cannibalized from the provided system template, system.adm:

CLASS USER 
 
CATEGORY !!SystemControl
  KEYNAME Software\Microsoft\Windows\CurrentVersion\Policies\System
 
  POLICY !!LimitSize
    KEYNAME "Software\Microsoft\Windows\CurrentVersion\Policies\System"
    EXPLAIN !!LimitSize_Help
    VALUENAME "EnableProfileQuota"
 
    PART !!SizeMessage EDITTEXT
      VALUENAME "ProfileQuotaMessage"
      DEFAULT !!DefaultSizeMessage
    END PART
 
    PART !!WarnUser CHECKBOX
      VALUENAME "WarnUser"
    END PART
 
    PART !!WarnUserTimeout NUMERIC REQUIRED SPIN 5
      VALUENAME "WarnUserTimeout"
      DEFAULT 15
      MIN    0
    END PART
  END POLICY ;LimitSize
END CATEGORY ;SystemControl
 
[strings]
DefaultSizeMessage="Storage space exceeded."
LimitSize="Limit profile size"
LimitSize_Help="Limits size of Profile."
SizeMessage="Custom Message"
SystemControl="System"
WarnUser="Notify user when profile storage space is exceeded."
WarnUserTimeout="Remind user every X minutes:"

Notice that this template consists of one category, SystemControl. Inside that category is a single policy, LimitSize. That policy is comprised of three parts, SizeMessage, WarnUser, and WarnUserTimeout. Let's dissect the template:

• The first statement, CLASS User, tells Group Policy that this policy falls under HKCU. Policies that come under HKLM appear with the CLASS MACHINE statement. Indeed, templates can and will contain both statements.
• The CATEGORY... END CATEGORY block defines the categories, or nodes, that fall under the Administrative Templates node in the console tree. This example contains one category, SystemControl. More elaborate templates contain a hierarchy of categories.
• The KEYNAME statement tells Group Policy that all polices and parts that belong to this category store their values under Software\Microsoft\Windows\CurrentVersion\Policies\System. Policies can specify their own key names as well. In this case, the keyname for the LimitSize policy is the same as the category keyname.
• The POLICY... END POLICY block defines a single policy. Each policy block corresponds to a policy item in the right pane of Group Policy you can right-click to display its properties. A policy can be enabled, disabled, or not configured. This template contains one policy item, LimitSize.
• Each PART... END PART block specifies a single part of the policy that encloses it. This appears as a control in the policy's property dialog, such as an edit field (EDITTEXT), a checkbox (CHECKBOX), or a numeric input field (NUMERIC). Default values for parts may be provided for a user to accept or reject. Policies that are either simply enabled or disabled won't contain parts. The policy to remove the search button from Windows Explorer, for example, doesn't require additional Registry values beyond the enabled status and therefore, doesn't contain any parts.

The policy in this example contains three parts, an edit text box, a checkbox and a numeric input field. The quoted VALUENAME is the name the value is stored as. The edit text box, SizeMessage, contains a default string value of "Storage space exceeded." The numeric user field contains a default value of 15 and a minimum value of 0.

• Tags that are preceded by a double exclamation point (e.g., !!LimitSize) are tied to character strings from the string section. This provides the text Group Policy uses to display the categories, policies, and parts.

The preceding Administrative Template contains a single, multipart policy. Figure 7-6 shows how the property dialog for this policy looks.

Figure 7-6. The example policy properties dialog

Distributing Policies

Computers that operate as standalone machines depend solely on local policy files for their policy settings. Networked computers, however, have the chore of obtaining policy files from the Domain Controller and merging them into their Registry. These downloaded policies contain the policies of the sites, domains, and organizational units that the computer and users are members of.

When you run the Group Policy snap-in, you're required to select the Group Policy Object for the settings you wish to modify. This can be a GPO associated with an Active Directory object, or it may be a local or remote computer GPO. The users and computers that the policy affects, however, depends directly on which GPO is chosen. The higher the GPO is in the hierarchy, the more machines the policy file is distributed to.

Understanding How Effective Policies Are Calculated

I said earlier that policies are applied to the Registry in a specific order. That is: the local GPO, site GPOs, domain GPOs, and then OU GPOs from largest to smallest. Clearly, since policies are cumulative, order of application is quite important. Policies set early in the process can be overwritten by later GPOs. Since local GPO settings are applied before nonlocal GPOs, the LGPO is considered to be the least influential of all GPOs. The important policies, then, are those held by nonlocal, or Active Directory, GPOs.

The hierarchy of the Active Directory is tree-like in that an Active Directory container can accommodate multiple containers beneath it. Each of those containers, in turn, can itself hold multiple containers. This continues down to the lowest-level OU container that actually houses actual users and machines. As the nonlocal policies are applied in the order described previously, each new policy file is merged into the Registry. This means that policy settings for site GPOs cover all domains, organizational units, users and machines within it. Settings for a domain GPO fan out to all the organizational units, users, and machines below the domain. Next, high-level organizational unit policies take effect and envelop all subordinate OUs. Policies of low-level OUs, while they are not as broadly applied as the higher nodes, are most likely to be applied, since they overwrite all conflicting policies previously merged into the Registry. Since policies are applied top-down in a single direction, policy settings applied at lower levels, such as subordinate OUs, don't affect higher group policy objects, such as site and domain GPOs.

Policy Inheritance

In the scheme of calculating effective policies, there are some basic rules that need to be understood about how policies are inherited. For the sake of clarity, let's discuss this in terms of parent and children GPOs, where a parent is any Active Directory Container, and a child is one of the containers directly beneath it in the Active Directory hierarchy.

First, you know from the previous discussion about editing policies that policies can be enabled, disabled, or not configured. Child containers don't inherit policies that aren't configured from their parent GPOs. This extends to the users and computers in those containers. Disabled policies are, however, inherited as disabled. Enabled policies, of course, are inherited as such. Furthermore, policy settings that are configured for a parent OU (that is, either enabled or disabled) and not configured for a child OU are inherited by the child. As an example, consider a desktop policy that hides the Internet Explorer icon on the desktop. A child OU inherits this policy if it's enabled or disabled for the parent OU. The child doesn't inherit it if it's not configured for the parent OU.

Inheritance additionally depends upon the compatibility of policy settings; that is, whether the intent of a setting inherently conflict with that of another policy setting. When a policy of a parent OU is incompatible with a policy of a child OU, the child doesn't inherit the parent's policy setting. Instead, the child's policy takes precedence and is applied. When a policy configured for a parent is compatible with the child's policy, both policies are used. The parent's policy is inherited and applied along with the child's policy; in this case, the effective policy is the sum of the parts of those two policies.

In some cases, an administrator may wish to keep a child GPO from inheriting policies from its parent and instead rely solely on the child's own policies. A third basic rule of policy inheritance allows child GPOs to block inheritance. If this option is set for a GPO, the GPO doesn't inherit any policy settings from its parent. This is useful when a parent GPO has general policies it wants to enforce on most of its child GPOs. Yet, there might be a child GPO that's exempt from these settings and should maintain its own set of policies. Blocking inheritance allows the subordinate unit to create its own policies without interference from its parent. Following the previous example, a child OU can disable or not configure the policy to hide the Internet Explorer icon while blocking inheritance from the parent OU. In this case, even if the hide icon policy is enabled for the parent OU, the effective child policy doesn't reflect that.

Lastly, there's an option for parent GPOs that give them the ability to set mandatory inheritance. By setting the No Override option on a parent GPO, all children GPOs must inherit all configured policies from that parent, regardless of compatibility or inheritance blocking on the child GPO. This can be used for parent GPOs that want their policy decisions to be unconditionally respected. This option also provides a means of making sure that incompatible settings don't keep child GPOs from inheriting parent GPO policies. Supposing that No Override is set for a parent OU that also enabled the hide Internet Explorer icon policy, its child OU unconditionally inherits that policy.

Managing Dispersal Through Group Policy Policies

The system administrative template includes a number of policies that define more concretely how and when Group Policies are retrieved and applied. These policies are found in both the computer and user sections of the system.adm file. To view the computer-specific policies in Group Policies, make sure system.adm is included as a current policy template. Under the Computer Configuration\Administrative Templates branch, the System category contains a subcategory for Group Policy. The following list describes some of these policies and what they mean:

Disable background refresh of group policy

Keeps group policy from being updated while a user is logged on. Not enabling it allows policy to be updated whether a user is logged on or not. When not enabled, update frequency is tied to the Group Policy refresh intervals for users and computers.

Apply group policy for computers asynchronously during startup

Allows the system to display the login prompt before the computer Group Policy is finished updating.

Apply group policy for users asynchronously during startup

Lets the system display the Windows desktop before the user Group Policy is finished updating.

Group Policy refresh interval for computers

Allows customization of policy update frequency. The policy's parts allow you to specify how often Group Policy is applied to computers. The default is 90 minutes.

There is an additional user-specific policy found under User Configuration/Administrative Templates in the System category and Group Policy subcategory. It works much like its computer-specific sibling:

Group Policy refresh interval for users

Like the computer refresh interval policy, this policy allows you to specify how often Group Policy is applied to users. The default is 90 minutes.

Setting Single Computer Group Policies

When you start Group Policy as a standalone MMC snap-in, a Select Group Policy Object dialog appears that allows you to choose the GPO to modify. The GPO for the Local Computer is entered as the default. You can browse for another GPO by selecting the Browse button. The subsequent browse dialog contains four tabs: Domains/OUs, Sites, Computers, and All. GPOs stored on local computers are found on the Computers tab. The radio buttons on this dialog allow you to toggle between the computer you're currently on and another computer, as shown in Figure 7-7.

Figure 7-7. Browse for Group Policy Object dialog

To modify the LGPO of another computer, type in the computer name or browse and select.

Setting Nonlocal Group Policies

You use the same dialog as shown in Figure 7-7 to select Active Directory Container GPOs to configure. These GPOs are divided into two groups, Domains/OUs and Sites. The Domains/OUs tab features a dropdown list to choose a container to look in as well as a list of GPOs in that container and their associated domain.

Similarly, you can specify a Site GPO on the Site tab. Again, a dropdown list contains the available sites to look in. To view all available GPOs in a certain domain, use the All tab and select the domain to look in. All GPOs in the selected domain will appear for easy pickings.

What's in the Standard Policy Templates?

Windows 2000 includes a number of administrative policy templates. Some are more general in nature and cover a wider scope; others pertain to specific applications. The first two templates are specific to Windows 2000 clients and are installed in Group Policy by default:

INETRES.ADM

Contains Internet Explorer policies for Windows 2000 clients; contains both machine and user settings. The HKCU settings, for the most part, regulate settings in the control panel of Internet Explorer. It has categories for the General tab, Content tab, Connection tab, Programs tab, Advanced tab, as well as some information delivery restrictions. The machine settings include categories for security and code downloading restrictions.

SYSTEM.ADM

By far the largest standard policy template. The machine portion of the template includes policy categories for administrative services, which encompasses login policies, file system settings, policy policies, and the task scheduler; networks; and printers. Registry settings under HKCU cover a broad range, from the control panel to Windows components to policies for system control.

The next administrative templates are specific to NT 4.0, 95/98, or both, and should be used with the System Policy editor rather than the Group Policies snap-in:

WINDOWS.ADM

Defines policy settings specific to Windows 95 and 98. The two categories included in the HKLM section of this template detail network and system policies, both of which encompass intermediate policy categories. Policy settings for the control panel, network sharing, system restrictions, and custom folders round out the user portion of this template.

WINNT.ADM

Defines user-interface options specific to NT 4.0. While some of the categories from the WINDOWS.ADM template appear here, the underlying subcategories and policies are different. As expected, this template contains both machine and user settings. The general machine categories cover policies for the system, networking, remote access, printers, user profiles and shell settings. The policy categories for the system, user profiles, and the shell are present under HKCU as well.

COMMON.ADM

Defines user interface options that are common to Windows NT 4.0, 98, and 95. In addition to system settings, it includes network settings for the machine and desktop settings for users.

Finally, here are a few templates included in the %SystemRoot%\inf directory:

CONF.ADM

Contains both user and machine policy settings for Microsoft NetMeeting.

INETSET.ADM

While INETRES.ADM contains policy settings for Internet restrictions, INETSET.ADM defines general Internet settings. The HKCU section of the template covers policy settings for colors, fonts, modem, and advanced settings.

WMP.ADM

Contains customization settings for the Windows Media Player.

TIP:  

For detailed information about these templates and the policies, Registry keys, and values that they cover, refer to Appendix A, User Configuration Group Policy Objects, and Appendix B, Computer Configuration Group Policy Objects.

---

1. You sometimes see reference to the local machine policy; that's just another name for the LGPO.

2. A second, but much more ambitious, way to extend the functionality of Group Policy is to write a software extension for the Group Policy snap-in. Software development, unfortunately, is beyond the scope of this book.

Back to: Managing the Windows 2000 Registry