Order of Processing
LSDOU: Local, Site, Domain, Organizational Unit (OU). That is the order in which Group Policy applies. All local GPOs are applied first; this is followed by any applicable ones linked to a site. Next, GPOs linked at the domain are applied. Finally, GPOs linked to each OU are processed. These GPOs are applied in a top down approach. Higher OUs or levels such as a site or domain are applied first. Let’s look at a sample environment.
We have a computer named BR-01 that is in the Brunswick OU. Our domain only has a single site with no GPOs linked to it. This computer would apply its local policy, Default Domain Policy, Domain Computers GPO, and finally the Brunswick GPO.
To simplify processing, we are going to enable “Turn off Local Group Policy Objects processing” in our Default Domain Policy.
Now, BR-01 will apply the Default Domain Policy, Domain Computers GPO, and finally the Brunswick GPO. We have a second computer named GA-01 in the Glynn Academy OU. Because it inherits settings from the Default Domain Policy, it will not apply Local GPOs as well. It will apply the Default Domain Policy, Domain Computers GPO, Brunswick GPO, and the Glynn Academy GPO.
A junior administrator edits our Brunswick GPO and sets “Turn off Local Group Policy Objects processing” to disabled.
The computer in the Glynn Academy OU (GA-01) will now process the Default Domain Policy first. This policy will say “Hey – Turn off Local GPO processing!”. The computer will then process the Domain Computers GPO (which doesn’t have this setting configured). Next, it will process the Brunswick GPO. This policy will say “Hey – Turn on Local GPO processing!”. Because this GPO is closer to GA-01 than the Default Domain Policy, this policy will win (and “Turn off Local GPO processing will be set to disabled.)
If we configured the Glynn Academy GPO to contradict the Brunswick GPO, the Glynn Academy GPO would win because it is the closet OU to the computer.
This is all dandy except we still have a problem. We want “Turn off Local GPO processing” enabled for the entire domain (no matter what), and our junior administrator specifically ignored that. After talking to him, he agrees not to configure the “Turn off Local GPO processing” setting.
One day, you are looking around in the Group Policy Management Console and see this:
Someone has set Block Inheritance on the Brunswick OU! Because Block Inheritance is set, any normal GPO above the Brunswick OU will be ignored. Our default domain policy, which configures the “Turn off Local GPO processing” setting, will no longer be processed by computers at the Brunswick OU or below.
If we read the details of that setting, we see that if we “do not configure this policy setting, local GPOs continue to be applied.” By enabling Block Inheritance, our junior administrator was able to indirectly set “Turn off Local GPO processing” to disabled by setting it back to Not Configured.
Lucky for us, Microsoft planned for junior administrators that HR won’t fire. They gave us the ability to enforce a GPO!
When enforcement is set on the Default Domain Policy, computers in the Domain Computers OU (and below) will apply the GPO even if Block Inheritance is enabled! If our junior administrator configures the Brunswick GPO and enforces it, the Default Domain Policy will still apply. When two policies are enforced, the highest policy will always win! This allows top level administrators to configure global settings without having to worry about those settings being overwritten.
Being heading off to enforce GPOs and block OU inheritance, stick with me for a few more minutes. As a general practice, do not enforce GPOs or block OU inheritance if you can help it. When you do either of these actions, you are adding complexity to your environment. And as every IT administrator knows, complexity = interrupted vacation time!