As mentioned many times in previous articles, group policy settings are applied in the order Local, Site, Domain, OU. This order controls which settings end up actually applying to a user or computer. Remember that all settings merge together by default, and that in the event of conflicting settings, the one applied latest will apply.
You may have noticed what many do when first looking at group policy application – that an administrator with control of only a single OU could possibly override settings set by a domain administrator. This is absolutely true, since OU settings will ultimately override those set at the domain level in the event of a conflict. However, this behavior can be controlled via two settings, Block Inheritance and No Override.
The Block Policy Inheritance setting may seem even worse. If an OU administrator were to set this on her OU, then all policies coming from ‘above’ would be completely blocked by default. That is, she could refuse to inherit any policy settings from the site, domain, or parent OU. Note that this feature is also a powerful capability, in that if you didn’t want any domain policies to apply to your developers, for example, you could simply block inheritance of policy at particular OU.
For those who feel uncomfortable with Block Inheritance, worry not. Another setting that can be set on a GPO is No Override, and No Override always beats Block Inheritance. As such, if I created a policy at the site level set to No Override, and the administrator of the Developers OU set the OU to Block Inheritance, the settings contained in the domain policy would still be applied regardless. Note that other policies without No Override enabled would still be blocked in this scenario. The No Override setting is set using the Options button on a GPO.
One last thing that you need to know about GPOs is that they can be filtered. That is, you can control exactly who a GPO will apply to by setting the appropriate permissions in the GPO’s ACL. For example, let’s say that you had an OU called Sales, and you wanted a GPO to apply to all users in the OU except for a user called SalesAdmin. By default, the GPO is always applied to all Authenticated Users, who have the Apply Group Policy and Read permissions set to allow. For out SalesAdmin user, we could prevent the GPO settings from being applied by giving him the Deny Apply Group Policy permission.
You should use filtering of GPOs sparingly, as it can complicate GPO troubleshooting. However, you should also recognize that it provides a powerful way to control policy application to users and groups, since GPOs cannot be linked to these types of objects.
