7.1 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 INIfiles (though that's strongly discouraged). None of these subtrees may be modified by nonadministrators.

7.1.1 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.

7.1.2 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.

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.

7.1.3 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.

7.1.3.1 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.

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

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

7.1.3.2 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.

7.1.4 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.

7.1.4.1 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.

7.1.5 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?

7.1.5.1 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.

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.

7.1.5.2 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:

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.