Overview of Group Policy Infrastructure and Mechanics

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Group Policy uses a document-centric approach to creating, storing, and associating policy settings. Similar to the way in which Microsoft Word stores information in .doc files, Group Policy settings are contained in GPOs. GPOs are linked to the following Active Directory containers: sites, domains, or organizational units. The settings within the GPOs are then evaluated by the affected clients, using the hierarchical nature of Active Directory.

Linking Group Policy Objects to Active Directory Containers

GPOs cannot be linked directly to users, computers, or security groups. They can only be linked to sites, domains and organizational units.

A given GPO can be linked to more than one site, domain, or organizational unit. Conversely, a given site, domain, or organizational unit can have multiple GPOs linked to it. In the case where multiple GPOs are linked to a particular site, domain, or organizational unit, you can prioritize the order of precedence in which these GPOs are applied.

By linking GPOs to sites, domains, and organizational units, you can implement Group Policy settings for as broad or as narrow a portion of the organization as you want:

• A GPO linked to a site applies to all users and computers in the site.

• A GPO applied to a domain applies directly to all users and computers in the domain and by inheritance to all users and computers in child organizational units. Note that policy is not inherited across domains.

• A GPO applied to an organizational unit applies directly to all users and computers in the organizational unit and by inheritance to all users and computers in child organizational units.

To link a GPO to a site, domain, or organizational unit, use GPMC. In the console tree, locate the site, domain or organizational unit and then choose Link an Existing GPO or Create and Link a GPO Here.

Note that GPOs are stored in domains not in organizational units. For example, if you create and link a new GPO for an organizational unit, GPMC is actually completing two steps at once: creating a GPO in the domain and then linking that GPO to that organizational unit. The link is not a component of the GPO; it is a component of the container to which it is linked. Therefore, if you want to delegate the ability to manage links for a given container, it must be delegated on that container, not the GPO. In the GPMC tree view, GPO links on a given container are shown as child nodes of that container.

Although you can link a site, domain, or organizational unit to a GPO in another trusted domain, this is not generally recommended for performance reasons because of the potential delay of processing GPOs at logon.

Group Policy Hierarchy

By default, Group Policy is inherited and cumulative, and it affects all computers and users in an Active Directory container. GPOs are processed according to the following order:

1. Local GPO. Each computer has exactly one GPO that is stored locally, shared by all users of that computer. This processes for both computer and user Group Policy processing.

2. Site. Any GPOs that have been linked to the site that the computer belongs to are processed next. Processing is in the order that is specified by the administrator, on the Linked Group Policy Objects tab for the site in GPMC. The GPO with the lowest link order is processed last, and therefore has the highest precedence.

3. Domain. Processing of multiple domain-linked GPOs is in the order specified by the administrator, on the Linked Group Policy Objects tab for the domain in GPMC. The GPO with the lowest link order is processed last, and therefore has the highest precedence.

4. Organizational units. GPOs that are linked to the organizational unit that is highest in the Active Directory hierarchy are processed first, then GPOs that are linked to its child organizational unit, and so on. Finally, the GPOs that are linked to the organizational unit that contains the user or computer are processed.

At the level of each organizational unit in the Active Directory hierarchy, one, many, or no GPOs can be linked. If several GPOs are linked to an organizational unit, their processing is in the order in which GPOs are linked to the organizational unit. For example, if you link three GPOs to an organizational unit the first GPO you added has the highest precedence and overwrites the settings of all other GPOs. Alternatively, you can specify the order on the Linked Group Policy Objects tab for the organizational unit in GPMC.

This order means that the local GPO is processed first, and GPOs that are linked to the organizational unit of which the computer or user is a direct member are processed last, which overwrites settings in the earlier GPOs if there are conflicts. (If there are no conflicts, then the earlier and later settings are merely aggregated.)

In GPMC, you can view the precedence order of inherited GPOs for a given site, domain or organizational unit by navigating to the Group Policy Inheritance tab for any site, domain, or organizational unit.

Managing Inheritance of Group Policy

You can further control precedence and how GPO links are applied to specific domains, sites, or organizational units by:

• Changing the link order. Within each domain, site, and organizational unit, the link order controls when links are applied. To change the precedence of a link, you can change the link order, moving each link up or down in the list to the appropriate location. The link with the higher order (with 1 being the highest order) has the higher precedence for a given site, domain, or organizational unit. For example, if you add six GPO links and later decide that you want the last one that you added to have highest precedence, you can move the GPO link to the top of the list. However, the link order of an inherited GPO cannot be altered.

• Blocking Group Policy inheritance. You can block policy inheritance for a domain or organizational unit. Using block inheritance prevents GPOs linked to higher sites, domains, or organizational units from being automatically inherited by the child-level. By default, children inherit all GPOs from the parent, but it is sometimes useful to block inheritance. For example, if you want to apply a single set of policies to an entire domain except for one organizational unit, you can link the required GPOs at the domain level (from which all organizational units inherit policies by default), and then block inheritance only on the organizational unit to which the policies should not be applied. Blocking does not affect Local GPOs.

• Enforcing a GPO link. You can specify that the settings in a GPO link should take precedence over the settings of any child object by setting that link to Enforced (formerly known as "no override"). GPO-links that are enforced cannot be blocked from the parent container. Without enforcement from above, the settings of the GPO links at the higher level (parent) are overwritten by settings in GPOs linked to child organizational units, if the GPOs contain conflicting settings. With enforcement, the parent GPO link always has precedence. Note that Enforce policy options always take precedence over Block Inheritance.

• Disabling a GPO link. By default, processing is enabled for all GPO links. You can completely block the application of a GPO for a given site, domain, or organizational unit by disabling the GPO link for that domain, site, or organizational unit. Note that this does not disable the GPO itself, and if the GPO is linked to other sites, domains or organizational units, they will continue to process the GPO, if their links are enabled.

• Disabling user and/or computer settings. A GPO may have its user settings disabled, its computer settings disabled, or all settings disabled. By default, neither user settings nor computer settings are disabled on a GPO.

Figure 1 below shows a sample domain structure to illustrate how GPOs can be applied to containers in Active Directory.

Figure 1. Group Policy and Active Directory

Filtering the Scope of the Group Policy Object

You can further refine which groups of computers and users a particular GPO influences by using security groups or WMI filtering.

Security Filtering

Security filtering is a way of refining which users and computers will receive and apply the settings in a GPO. Using security filtering, you can narrow the scope of a GPO so that it applies only to a single group, user, or computer by specifying that only certain security principals within a container where the GPO is linked apply the GPO. Security filtering determines whether the GPO as a whole applies to groups, users, or computers; it cannot be used selectively on different settings within a GPO.

In order for the GPO to apply to a given user or computer, that user or computer must have both Read and Apply Group Policy (AGP) permissions on the GPO, either explicitly, or effectively though group membership.

By default, all GPOs have Read and AGP both Allowed for the Authenticated Users group. The Authenticated Users group includes both users and computers. This is how all authenticated users receive the settings of a new GPO when it is applied to an organizational unit, domain or site. Therefore, the default behavior is for every GPO to apply to every Authenticated User. By default, Domain Admins, Enterprise Admins, and the local system have full control permissions, without the Apply Group Policy ACE. However, administrators are members of Authenticated Users, which means that they will receive the settings in the GPO by default.

You can change these permissions to limit the scope to a specific set of users, groups, or computers within the organizational unit, domain, or site. Group Policy Management manages these permissions as a single unit, and displays the security filtering for the GPO on the GPO Scope tab. Using GPMC, you can add and remove groups, users, and computers to be used as security filters for each GPO. In addition, security principals used for security filtering also appear on the Delegation tab for a GPO as having Read (from Security Filtering), since they have read access to the GPO.

To modify security filtering, you add or remove groups in the Security Filtering section on the Scope tab of a GPO. In practice, you don't have to set the two access control entries (ACEs), because GPMC sets both for you when you set security filtering. In addition, The Read and AGP permissions are visible separately, and able to be set independently of one another, through the access control list (ACL) editor. In GPMC, the Security Filtering section of the Scope tab of a GPO shows only whether the GPO will apply. If you want to see the permissions separately, you can open the ACL editor by clicking the Advanced button on the Delegation tab for the GPO.

To prevent a GPO from applying to a specified group requires removal of the AGP ACE from that group. In the ACL editor, if you remove the AGP ACE (clear the Allow check box) for Authenticated Users, you can then explicitly grant this permission to individual security groups that should receive the policy settings. Alternatively, you could set AGP to Deny for certain classes of users, such as administrators, that will never need that policy.

Best Practice: If you disallow Apply Group Policy for a GPO for some users, consider also disallowing Read access to those users. When the Read ACE is allowed and the Apply Group Policy is not, the GPO is still processed by the user even though it is not applied to the user. Therefore, to improve performance, you should remove the Read Access Control Entry to prevent the user from processing the GPO. In addition, removing Read access increases security. With Read access allowed, it is possible for an inquisitive user with considerable knowledge of Active Directory to read the contents of that GPO, even if it's not applied to them. This may not be desirable in some cases, such as a GPO for a human resources group. It might be advisable to limit Read access on GPOs that affect the HR users to only those users.

Security groups and DACLs are also used to delegate control of GPOs, as explained in the section "Delegating Group Policy."

WMI Filtering

WMI filters allow you to dynamically determine the scope of GPOs based on attributes of the target computer.

When a GPO that is linked to a WMI filter is applied on the target computer, the filter is evaluated on the target computer. If the WMI filter evaluates to false, the GPO is not applied (except if the client computer is running Windows 2000, in which case the filter is ignored and the GPO is always applied). If the WMI filter evaluates to true, the GPO is applied.

WMI makes data about a target computer available for administrative use. Such data can include hardware and software inventory, settings, and configuration information. For example, WMI exposes hardware configuration data such as CPU, memory, disk space, and manufacturer, as well as software configuration data from the registry, drivers, file system, Active Directory, the Windows Installer service, networking configuration, and application data.

A WMI filter consists of one or more queries based on this data. If all queries are true, the GPO linked to the filter will be applied. The queries are written using the WMI Query Language (WQL), a SQL-like language. Queries can be combined with AND and OR logical operators to achieve whatever effect the administrator wants. Each query is executed against a particular WMI namespace. When you create a query, you must specify the namespace. The default is root\CIMv2, which is appropriate for most WMI queries. For more information, see Windows Management Instrumentation in the Microsoft Platform SDK at https://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/wmi\_start\_page.asp.

The WMI filter is a separate object from the GPO in the directory. To apply a WMI filter to a GPO, you link the filter to the GPO. This is shown in the WMI filtering section on the Scope tab of a GPO. Each GPO can have only one WMI filter, however the same WMI filter can be linked to multiple GPOs.

WMI filters, like GPOs, are stored on a per-domain basis. A WMI filter and the GPO it is linked to must be in the same domain.

Here are some sample uses of WMI Filters.

• Services – computers where DHCP is turned on.

• Registry – computers that have this registry key populated.

• Hardware inventory – computers with a Pentium III processor.

• Software inventory – computers with Visual Studio® .NET installed.

• Hardware configuration – computers with network adapters on interrupt level 3.

• Software configuration – computers with multi-casting turned on.

• Associations – computers that have any service dependent on SNA service.

• Ping – computers that can ping Server1 in less than 100 milliseconds.

WMI filtering allows administrators to filter the application of a GPO by attaching one set of Windows Query Language query to a GPO. The queries can be written to query WMI for multiple items. If the query returns true for all queried items, then the GPO will be applied to the target user or computer. The WMI filter applies to every setting in the GPO, so you will want to create separate GPOs specifically for WMI filtering.

There are two distinct parts to WMI filtering in Windows Server 2003:

• Server administration of WMI filters. This includes GPMC, changes to the Group Policy Object Editor, and filter specifications.

• Client side processing. (WMI supports batch processing of WMI filters.)

• For more information about WMI filtering including sample filters for specific scenarios, see "Appendix C" in this paper.

MMC Snap-in Extension Model

The nodes of the Group Policy Object Editor are also MMC snap-in extensions. These extensions include Administrative Templates, Scripts, Security Settings, Software Installation, Folder Redirection, Remote Installation Services, and Internet Explorer Maintenance. Extension snap-ins may in turn be extended. For example, the Security Settings snap-in includes several extension snap-ins. Developers can also create their own MMC extensions to the Group Policy Object Editor to provide additional policy settings.

For more information about creating MMC extensions, see the Microsoft Management Console section of the Microsoft Platform SDK documentation at: https://www.microsoft.com/msdownload/platformsdk/sdkupdate/.

By default, all the available Group Policy Object Editor extensions are loaded when you start the Group Policy Object Editor. You can modify this default behavior by creating a custom MMC console, or by using policy settings to control the behavior of MMC itself. MMC options are accessed under the User Configuration\Administrative Templates\Windows Components\Microsoft Management Console node. For more information, see:

"Specifying Group Policy to Control the Behavior of MMC and Snap-ins", later in this document.

Group Policy Object Editor Namespace

The root node of the Group Policy Object Editor is displayed as the name of the GPO and the domain to which it belongs, in the following format:

GPO Name [DomainName.com] Policy

For example:

Default Domain Policy [HQ-RES-DC-01.Contoso.com] Policy

Computer Configuration and User Configuration

Below the root node, the namespace is divided into two parent nodes: Computer Configuration and User Configuration. These are the parent nodes that you use to configure Group Policy settings. Computer-related Group Policy is applied when the operating system boots and during the periodic refresh cycle, explained later in this document. User-related Group Policy is applied when users log on to the computer and during the periodic refresh cycle.

Extensions to the Group Policy Object Editor

Three nodes exist under the Computer Configuration and User Configuration parent nodes: Software Settings, Windows Settings, and Administrative Templates. The Software Settings and Windows Settings nodes contain extension snap-ins that extend either or both of the Computer Configuration or User Configuration nodes. Most of the extension snap-ins extend both of these nodes, but frequently with different options. The Administrative Templates node namespace contains all policy settings pertaining to the registry; it can be extended by using .adm files.

The Group Policy extension snap-ins include:

• Administrative Templates. This extension contains all registry-based policy settings, including those for the Windows 2000 and Windows Server 2003 operating systems and their components as well as any registry-based policy settings provided by applications. You use these policy settings to mandate registry settings that control the behavior and appearance of the desktop, the operating system components, and applications that provide registry-based policy. This node uses .adm files to specify the registry settings that can be modified through the Group Policy Object Editor user interface. For more information about .adm files, see "Administrative Templates" later in this paper.

• Security Settings. The Security Settings extension is used to set security options for computers and users within the scope of a GPO. You can define local computer, domain, IP security settings, wireless configuration, and software restriction policy settings. For more information about security settings, see "Security Settings" and "Appendix A: Security Settings and User Rights" later in this paper.

• Software Installation. You can use the Software Installation snap-in to centrally manage software in your organization. You can assign and publish software to users and assign software to computers. For more information about software installation, see "Software Installation", later in this document.

• Scripts. Scripts are used to automate tasks at computer startup and shutdown, and at user logon and logoff. You can use any language supported by Windows Script Host. These include the Microsoft Visual Basic® development system, Scripting Edition (VBScript), JavaScript, PERL, and MSDOS®-style batch files (.bat and .cmd). See "Scripts", later in this document and Microsoft Windows Script Web site at https://www.microsoft.com/scripting for more information.

• Remote Installation Services. Remote Installation Services (RIS) is used to control the behavior of the Remote Operating System Installation feature as displayed to client computers. See "Remote Installation Services", later in this document.

• Internet Explorer Maintenance. Internet Explorer Maintenance is used to manage and customize Internet Explorer on computers running Windows 2000 or later. You can also export settings for Windows 95, Windows 98, and Windows NT® 4.0-based client computers (the settings are exported into an .ins and .cab file format for those platforms). Administrators can set options for Browser UI, connections, URLs, proxy settings, security zones, Favorites, and other options. See "Internet Explorer Maintenance", later in this document.

• Folder Redirection. You can use folder redirection to redirect special directories on Windows 2000 or Windows Server 2003 from their default user profile location to an alternate location on the network. These special folders include My Documents, Application Data, Desktop, and the Start menu. See "Folder Redirection", later in this document.

For more information about extending the functionality of the Group Policy Object Editor see "Implementing Registry-Based Group Policy" at https://www.microsoft.com/windows2000/techinfo/howitworks/management/rbppaper.asp.

Client-side Extensions to Group Policy

Some of the Group Policy Object Editor extensions also include client-side extensions. These extensions are DLLs that are responsible for implementing Group Policy at the client computers. For more information about the client-side extensions, see the "Client-side Processing of Group Policy" section later in this paper.

Group Policy Storage

A GPO is a virtual object. The policy setting information of a GPO is actually stored in two locations: the Group Policy container (GPC) and the Group Policy template (GPT). The Group Policy container is an Active Directory container that stores GPO properties, including information about version, GPO status, and a list of components that have settings in the GPO. The Group Policy template is a directory structure within the file system that stores Administrative Template-based policy settings, security settings, script files, and information regarding applications that are available for Software Installation. The Group Policy template is located in Sysvol in the \Policies sub-directory for its domain. GPOs are identified by their globally unique identifiers (GUIDs) and stored at the domain level. Replication of a GPO to other domain controllers happens through two different mechanisms. The Group Policy container is replicated by using Active Directory replication, whereas the Group Policy template is replicated using File Replication service (FRS). The settings from a GPO are only applied when the Group Policy container and Group Policy template are synchronized. For additional information about storage of Group Policy information, see"Appendix B: Group Policy Storage", later in this paper.