Understanding GP Inheritance and Application Order

Understanding the order in which Group Policy is applied is essential to administering Group Policy successfully. Without a clear understanding, Group Policy implementation and troubleshooting can be very difficult, even with the tools provided by Microsoft to help out with those very things.

Group Policy Inheritance

To maximize the inheritance feature of Group Policy, keep the following in mind:

• Isolate the servers in their own OU. Create descriptive Server OUs and place all the non “domain-controller servers in those OUs under a common Server OU. If software pushes are applied through Group Policy on the domain level or on a level above the server's OU and do not have the Enforcement option checked, the server's OU can be configured with Block Policy Inheritance checked. As a result, the servers won't receive software pushes applied at levels above their OU.

• Use Block Policy Inheritance and Enforcement sparingly to make troubleshooting Group Policy less complex.

Understanding the Order in Which Group Policies Are Applied

As stated previously, Group Policy objects are applied in a specific order. Computers and users whose accounts are lower in the Directory tree can inherit Policies applied at different levels within the Active Directory tree. Group Policy is applied in the following order throughout the AD tree:

• Local Security Policy is applied first.

• Site GPOs are applied next .

• Domain GPOs is applied next.

• OU GPOs is applied next.

• Nested OU GPOs and on down are applied next until the OU at which the computer or user is a member is reached.

If a setting in a Group Policy Object is set to Not Configured in a policy higher up, the existing setting remains. However, if there are conflicts in configuration, the last Group Policy Object to be applied prevails. For example, if a conflict exists in a Site GPO and in an OU GPO, the settings configured in the OU GPO will "win."

If multiple GPOs are applied to a specific AD Object such as a site or OU, they are applied in reverse of the order they are listed. The last GPO is applied first, and therefore if conflicts exist, settings in higher GPOs override those in lower ones. For example, if a Contacts OU has the following three Group Policies applied to it and they appear in this order (as shown in Figure 6.1) the policies will be applied from the bottom up:

Figure 6.1. Group policy object order.

• Contacts Default Group Policy

• Contacts Software Policy

• Contacts Temporary Policy

The Contacts Temporary Policy will be applied first. The Contacts Software Policy will apply next, and finally the Contacts Default Group Policy will be applied. Any settings in the Contacts Default Group Policy will override the settings configured in the two policies below, and the settings in the Contacts Software Policy will override any settings in the Contacts Temporary Policy.

Modifying Group Policy Inheritance

The Block Inheritance and Enforcement and Link Enabled features allow control over the default inheritance rules.

GPOs can be configured to use the Enforcement feature. This setting does not allow the parent organizational unit to be overridden by the settings of the child OU if conflicts exist. Additionally, it nullified the effects of Block Policy Inheritance if that functionality is applied on sub-GPOs.

GPOs can also be set to Block Policy Inheritance. This feature prevents the AD object that has the GPO applied to it from inheriting GPOs from its parent organizational unit, site, or domain (unless the parent GPO had Enforcement enabled as described previously).

Finally, the option exists that allows for the disabling of a Group Policy Object, also known as the GPO's Link Enabled status. By right-clicking on the Group Policy in the Group Policy Management Console and unchecking Link Enabled, you can disable the policy and render it unused until the time it is re-enabled. In Figure 6.2 the Contacts Temporary Policy Link Enabled state is disabled.

Figure 6.2. Disabling link enabled status.

Configuring Group Policy Loopback

Loopback allows Group Policy to be applied to the user logging in based on the location of the computer object, not the location of the user object in AD. Loopback applies a Group Policy based on the computer the user is using, not the user whom is logging into the computer. An example of a good use of the loopback option concerns Terminal Services. If you need to apply specific permissions to everyone who logs into a particular Terminal Server, regardless of his or her user group policies, loopback in replace mode will accomplish this objective by ignoring all user GPOs. Loopback also provides a merge mode that merges the GPOs that apply to the user and computer but gives precedence to the computer GPO's, overriding any conflicting user GPOs.