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.

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.

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.

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.

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?