Group Policy Inheritance

Group policy inheritance affects the order in which different policies are processed. This may not sound impressive, but it’s important. Sadly, this is only true up to a point. There are other considerations. For example, a later GPO may not make any conflicting changes to an earlier policy so the earlier policy appears to survive. The picture is also complicated by the NO Override  and Block Policy Inheritance settings that can be applied to a GPO.

Use the buttons below to navigate through the lesson

GPO Application Order

This can be summarised thus:

GPO level	Applies to:	Overridden by:
Local	All users on the local computer.	GPOs applied to the site, domain or Organisational Unit.
Site	All users and computers in the site.	Group Policy Objects applied to the domain or Organisational Unit.
Domain	All users and computers in the domain.	GPOs applied to the Organisational Unit.
Organisational Unit	All users and computers in the OU	Nothing – OU GPOs have precedence over all other policies

To illustrate how GPO’s are applied, consider this site which contains two domains, each with two OUs, each with several local machines…

The Site GPO is applied next. The policy is that all screens shall be RED:

GPO’s are applied in this order:

• Local
• Site
• Domain
• Organisational Unit

Local policies are in effect on the local workstations to give them red or blue wallpaper as they choose.

The Site GPO is applied next. The policy is that all screens shall be RED:
The Site-level GPO affects everything in it, whether it’s a domain, OU or local machine.

The Domain GPO is applied next. A’s policy is that all screens shall be RED while B’s policy is to have Blue Screens.

The Domain-Level GPO affects everything in it, too.

The OU GPO is applied next. Bob’s policy is that all screens shall be Blue …

…while Alf’s policy is to have red screens.

Note that the last GPO applied can change what went before.

Ann’s policy is to have Blue Screens, while Bea’s doesn’t specify anything in this regard……so nothing apparently changes.

The default behaviour of group policy objects can be overridden using the Block Policy Inheritance and No Override options. If this latter option is selected for a GPO linked to the site or domain, policies further down the chain (such as in an OU) will not override them.

Ann’s GPO specifies a red screen. Normally, as the last applied GPO, it would be the one to count in this scheme of things, but…

…the Purple GPO specifies blue screens, and has the No Override option set for this link. The OU GPO does not override it

If the Block Policy Inheritance option is selected at the OU or domain level, the policies further up the chain (such as those applied to a site) will not take effect.

The Purple GPO specifies Red screens, but Ann OU’s Block Policy Inheritance prevents the Site GPO being applied in the first place.

If an OU has the Block Policy Inheritance option set, but the domain has No Override on one of it’s GPOs, the domain has its GPO applied. This is because a domain administrator may want to prevent the person delegated control of an OU from overriding their settings.
…the Purple GPO specifies blue screens, and has the No Override option set for this link. The OU’s Block Policy Inheritance cannot block this.

Click Start. Click Administrative Tools. Click Active Directory Users and Computers. Right click any OU that has a GPO linked to it. Right click any OU that has a GPO linked to it. Click Properties. Click Group Policy. Click Block Policy Inheritance. The OU GPO will now take priority, and all GPOs applied at the domain or site level will no longer apply to the objects in this Organisational Unit. Click OK.

Right-click the domain. Click Properties. Click Group Policy. Click Options. Click the No Override checkbox. Click OK. The tick means that “No Override” has now been selected for this GPO. It will propagate its policies to the OU GPO regardless of the Block Policy Inheritance setting. Click OK.

Group Policy Permissions

Using group policy permissions you can deny a user read permission to a GPO which will prevent the policy being applied to that user. This is useful when you don’t want to apply a GPO to a user but you want them to be a member of the container. You could , for example block a single user from using a GPO which automatically installs Microsoft Office.

Permissions can be configured by bringing up the properties for the GPO. A useful option in the GPO properties page is to disable the computer or user configuration. If you have no policies in one of the configurations then it can improve performance by disabling it. Select the Security tab to configure permissions. You can then add or remove permissions as needed.