Scoping GPOs

Group Policy is a powerful tool for managing the Windows 2000 (and later) environment. The value of Group Policy can only be realized through properly applying the GPOs to the Active Directory containers you want to manage. Determining which users and computers will receive the settings in a GPO is referred to as “scoping the GPO”. Scoping a GPO is based on three factors:
•
The site(s), domain(s), or organization unit(s) where the GPO is linked.
•
The security filtering on the GPO.
•
The WMI filter on the GPO.

This section will discuss how to utilize GPMC to properly manage the scope of a GPO and the Active Directory components you want to manage. Figure 7 shows the GPO scope tab.



Linking GPOs

The primary mechanism by which the settings in a GPO are applied to users and computers is by linking the GPO to a site, domain, or OU in Active Directory. The location where a GPO is linked is referred to as the Scope of Management, or SOM (also sometime abbreviated as SDOU in previous white papers). There are three types of SOMs: sites, domains, and OUs. A GPO can be linked to multiple SOMs, and a SOM can have multiple GPOs linked to it. A GPO must be linked to a SOM for it to be applied.

Note:

GPOs are not stored on a per-SOM basis, but rather per domain. Thus, if you link a GPO to an OU, the GPO does not actually reside in that OU. A GPO is a per domain object that can be linked anywhere in the forest (although performance issues may exist where cross-domain links are used). One of the goals for GPMC is to make the distinction between links and actual GPOs clearer.

With GPMC, you can link a GPO to SOMs using any of the following methods:
•
Right click a domain or OU node, and choose Create and Link a GPO here. This option is analogous to choosing New in the old Group Policy user interface prior to GPMC. (This old Group Policy interface was the Group Policy tab on the properties dialog box of a site, domain, or OU in Active Directory Users and Computers or Active Directory Sites and Services snap-ins.). Although this operation is presented as one action to the user, there are actually two operations taking place. First, a GPO is created in the domain, and second, a link to that GPO is created on the domain or OU from where you started the shortcut menu.
•
Right click a site, domain, or OU node, and choose Link an existing GPO here. This option is analogous to choosing Add in the old Group Policy user interface prior to GPMC. This requires that the GPO already exists in the domain.
•
Using drag and drop, drag a GPO from under the Group Policy objects node to the OU. This drag and drop functionality can only be performed within the same domain.

Note:

By default, new user and computer accounts are created in the CN=Users and CN=Computers containers. These containers are not actually OUs, so GPOs cannot be directly applied to these containers, however, objects in these containers do inherit GPOs linked to the domain and sites. It is possible to specify a different container in which to place either new user accounts, new computer accounts, or both. This allows you to have greater control for applying GPOs to newly created user and computer objects, before they are moved to their final locations in Active Directory. To specify new locations for user or computer accounts, use Redirusr.exe (for users) or Redircomp.exe (for computers) in the domain you want to manage. The domain administrator can use these tools to specify an OU in which to place all new user or computer accounts when they are created. Redirusr.exe (for user accounts) and Redircomp.exe (for computer accounts) are two new tools included with Windows Server 2003 and are located in the %windir%\system32 directory. For more information about redirecting containers for users and computers, see article Q324949, "Redirecting the Users and Computers Containers in Windows Server 2003 Domains," in the Microsoft Knowledge Base. To find this article, see the Microsoft Knowledge Base link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

Security Filtering

By default all Authenticated Users that are located in the SOM (and its children) where a GPO is linked will apply the settings in the GPO.

You can further refine which users and computers will receive the settings in a GPO by managing permissions on the GPO. This is known as security filtering. In order for GPO to apply to a given user or computer, that user or computer must have both Read and Apply Group Policy permissions on the GPO. By default, GPOs have permissions that allow the Authenticated Users group both of these permissions. This is how all authenticated users receive the settings of a new GPO when it is linked to a SOM (OU, domain or site). These permissions can be changed however to limit the scope of the GPO to a specific set of users, groups, and/or computers within the SOM(s) where it is linked.

GPMC simplifies how administrators manage security filtering for a GPO. Without GPMC, administrators were required to use the ACL editor, to manually set the Read and Apply Group Policy permissions for various security principals (users, computers, and groups) to modify the scope of the GPO. In GPMC, this process is no longer necessary. The administrator can just add or remove security principals in the security filtering section in the Scope tab for the GPO or the GPO link. This will automatically set or remove the Read and Apply Group Policy permissions for that security principal on that GPO. In the example in Figure 7, the security filtering on the “Common Managed Settings” GPO has been modified so that only members of the “Managed Users” group can receive the settings. Note that members of this group that are not located in either the “Engineering – Offsite” or “User Accounts” OUs will not receive the settings in this GPO.

If the administrator needs to access the detailed permissions, they are still available using the ACL editor when you can access using the Advanced button on the Delegation tab for the GPO. For example, if you need to set permissions to Deny, you can do this using the ACL editor. Groups with Deny permissions will appear as having Custom permissions on the Delegation tab. In general, it is recommended that you avoid the use of Deny permissions for managing Group Policy.

Linking WMI Filters

WMI Filters allow an administrator to dynamically determine the scope of GPOs based on attributes (available through WMI) of the target computer. A WMI filter consists of one or more queries that are evaluated to be either true or false against the WMI repository of the target computer. 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.

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. If the WMI filter evaluates to true, the GPO is applied. Note that client support for WMI filters exists only on Windows XP and later operating systems. Windows 2000 clients will ignore any WMI filter and the GPO is always applied, regardless of the WMI filter.