Posted: Dec. 9, 2002

Group Policy was introduced with Windows 2000 Server to move beyond the simple management of Windows Registry settings introduced with Windows NT 4.0 System Policy. While System Policy is still available for various versions of Windows, including Windows 9x and Windows NT 4.0, Microsoft switched to Group Policy to provide an Active Directory (AD)-based architecture and to give customers the ability to manage Registry and security settings, software installation, script execution, folder redirection, and other Windows features and services.

System Policy

System Policy, the predecessor to Group Policy, allows administrators to manage the configuration of Windows 98, Me, and NT 4.0 by setting the values of the Registry keys, but administrators must use a version-specific version of the System Policy editor for each version of Windows. The System Policy editor creates a policy file (.pol file) that the administrator can then store on the local computer (standalone scenarios) or on the domain controllers (for networked scenarios).

Unlike Group Policy, System Policy suffers from several limitations:

• Only a small number of features can be managed.
• The default computer and user policy can be edited in such a way that even administrators are locked out of the computer.
• Changes managed by system policy "tattoo" (that is, actually change) the Registry: undoing a change created by system policy can require manually editing the Registry.
• Policy settings are written in a nonsecure location in the Registry, which allows users to undo the intended policy settings.

Group Policy

Group Policy expanded the scope of configuration management and introduced a new set of tools and processes to apply policy to Windows 2000 and XP desktops managed by AD.

Group Policy Configuration

For Group Policy, administrators define policies using the Microsoft Management Console and one of several snap-ins—typically, the AD Users and Computers snap-in—to create a Group Policy Object (GPO).

The configuration parameters managed by Group Policy fall into two broad categories: computer configuration and user configuration.

Computer configuration affects system startup parameters and settings that apply to all users of that particular computer.

User configuration affects individual users when they log on to any computer.

Within both the computer and user configuration categories, various settings include Software Installation (which controls the assignment and publishing of applications to computers and users), Windows Settings (which control the configuration of scripts and security settings), and Administrative Templates (which control Registry-based settings for Windows components, such as configuration of the Start menu, and applications such as Microsoft Office).

Processing Group Policy

The policy setting information of a GPO is actually stored in two locations. The Group Policy Container is an AD container that stores GPO properties, including version and status information. The Group Policy Template stores the information about template-based policies, security settings, script files, and information regarding applications that are available for software installation.

When a computer starts, it receives a list of applicable GPOs from the AD, and the computer policies are processed and applied. When a user logs on, a list of applicable GPOs is again processed and applied. By default, the processing of the computer policies are completed before the logon dialog boxes are displayed, and user policies are completed before the shell is active and available for the user to interact with it.

Policy is applied in a hierarchy: first any Local Group Policy Object policies are applied, and then GPOs linked to the AD site, domain, and organizational units (OUs) are applied. This appears to be a simple and straightforward hierarchy, but it is complicated by the fact that AD OUs can be nested hierarchically (an OU can contain one or more OUs, and so on). The order of the OU hierarchy affects the processing of Group Policy, with the local GPO being processed first and the OU containing the computer or user processed last.

This initial policy processing sequence is further complicated when security groups are used to filter or exclude group or users from the application of a specific policy or when options such as "no override" (a set policy cannot be overwritten) and block inheritance (do not inherit policy from a parent container) have been applied to a GPO.

This shows the real issue with Group Policy—determining which policy applies to which computer or user after all the GPOs, filters, inheritance, and no override parameters have been processed—the Resultant Set of Policy (RSOP). With Windows 2000 Server, Microsoft did a good job of designing this process to handle every possible scenario, but did not have the time to build tools to help administrators calculate the RSOP for particular users and computers.