GPO workflow

Now that you know the four tiers of Group Policy processing, let's bring it back to the reason why this is even important. Certainly, you could start creating GPOs and handing out settings willy-nilly without knowing any of this, right? Yes, and you might get away with it for a long time as well, but eventually you'll have to troubleshoot a GPO or figure out where a particular setting is coming from, or perhaps why a setting is not showing up or not working. That is when this information comes into play.

It's also super helpful to know all of this when taking a new job at a new organization where you were not the original creator of the Group Policy infrastructure.

The four types of policy processing are listed in a particular order for a reason. This is the order that the workflow follows when Group Policy does its thing. When a computer boots, it processes the Group Policy settings in this order:

• Local Policy
• Site-level policies
• Domain-level policies
• OU-level policies

The machine flows through these policies from top to bottom, which is a good way to think about it, because when you are looking inside GPMC keeping a top-to-bottom mindset will also help you understand which policies are getting applied first. The settings contained within these policies are applied cumulatively, so they absolutely do have the capability to step on one anothers' toes. If you have conflicting policy settings among two tiers of GPOs, one of them is going to win and one is going to lose. Looking at this list will help you to determine which settings will exist at the end of a GPO processing cycle.

Looking at the processing order list brings to mind a few examples that may be helpful to round out your understanding on this topic:

• Since Local Policy goes first, anything inside any Active Directory Policy has the potential to nullify or change that local policy setting.
• Site-level policies received by a computer will change based on what physical location they are plugged into, so it is important to keep in mind that these settings can be fluid.
• If there is a domain-level policy setting that contradicts a site-level policy setting, the domain-level policy applies last, and therefore wins the day. That setting will be the one that ends up on the client workstation.
• If an OU-level policy applies that conflicts with a site-level or domain-level policy, the OU-linked policy will win every single time. 

OUs have even more to consider, because you could easily have multiple GPOs linked to the same OU that could conflict with each other. In this case, one of them is going to win, and in my experience it isn't always the same GPO. This can be a little confusing for sure, so it is critical that you plan the filtering of your GPOs appropriately when creating them.

The capability to have OUs nested inside other OUs also brings some complication to this scenario. Remember the general rule is that Group Policy processes from the top down, so GPOs that are linked to a nested OU will most likely outweigh GPOs that are linked at a higher-level OU.

When a machine receives a GPO setting from a tier that is above the OU where it is sitting, it is known as inheriting that GPO. The term inheriting will be important when we later discuss inherency blocking and the reasons why you may want to do that. Here is an example based on previous screenshots. Computers inside the Human Resources OU will be receiving the settings from inside the Firewall Settings GPO, because it is linked directly to that OU. Computers inside the Human Resources OU may also be receiving settings from the Default Domain Policy, which is being applied at the domain level, and in this case those computers would be "inheriting" those settings from the Default Domain Policy.