Hierarchy of Group Policy processing

To make use of Group Policy, you don't really have to understand how it works under the hood. You configure GPOs, which contain settings, and then you instruct Active Directory on who or what those GPOs need to apply to. Then, when those computers and users are connected to the corporate network, and therefore connected to Active Directory, they will automatically receive those GPO settings and put them into place on the computers. In other words, Group Policy processes those settings automatically.

What is very important to understand about Group Policy processing is the hierarchy that it follows. As with most Microsoft technologies, Group Policy processing follows a tree-scheme, where the application of settings flow down branches of a tree. There are four levels—also known as tiers or branches—in which Group Policy processing happens.

Levels of GPO processing

The four unique levels of hierarchy for Group Policy processing are called Local, Site, Domain, and OU. Let's spend a few minutes going through each one so that you can understand how they are different, and also how they fit together.

Local Policy

We already discussed Local Group Policy and using gpedit.msc to reference these settings. This is the Local Policy of a computer, and any settings that are plugged into Local Policy will process first when Windows starts. These settings affect the entire computer—it doesn't matter which users are logged in. It is very rare that companies would make use of Local Policy to push any settings, because it means that you would be manually touching each workstation to put these settings into place. That's not very time-friendly. What is most important to understand about Local Policy is that your settings that are plugged in at the local policy level may not always be in effect. Since Local Policy is first to apply, it means that any levels of the Active Directory Group Policy that we are about to cover in a minute will take priority over Local Policy. In other words, your computer might put your Local Policy settings into place, but milliseconds later during the boot process, those settings could be overwritten by AD policy settings.

Site-level policies

Something that is sort of outside the scope of this book, but is relevant here, is Active Directory Sites and Services. Inside any Active Directory environment, your DCs will automatically have this tool installed, called AD Sites and Services. The purpose here is to define your physical locations of the network, sites, if you will. The many small businesses have only a single site, and often they never have to even open this tool. Makes sense, as everything is always connected to the same site. However, as soon as you grow your business and expand to a second location, the network typically gets much more complex, and you now have IP subnets that are different between the two sites. Active Directory Sites are defined by what IP address space, or subnet, a computer is currently residing in. When your computer checks in with AD, it is automatically known what site you are part of based on the IP address of your computer.

Here is a quick picture of Active Directory Sites and Services, so you can see the layout and also see that the different sites are defined by which IP addressing spaces they contain:

Once your environment is large enough and you have defined your Sites inside this tool, you have now enabled Group Policy to be able to issue settings to computers (and users) based on the site that they reside in. Users follow the computers in this scenario. If a computer account is logging in and Group Policy recognizes it to be in the GrandRapids site, it will apply all GPO settings that are flagged for GrandRapids. The same is true of any users that log into that computer; since the computer is currently sitting in GrandRapids, any user-based policies that are filtered for GrandRapids will also apply.

Keep in mind that computers only receive site-based Group Policy settings while they physically reside in that site. If a computer moves to a new site, any site-level GPOs that were being applied will stop, and new site-level GPOs from the new site will apply.

Domain-level policies

Some policies and settings are going to be things that you want to apply to all of the machines or users in the entire domain, and the appropriate place for those settings are domain-level GPOs. It's important to point out that the GPOs themselves are not different as we talk about all of these different policy levels—a GPO is a GPO. The level at which the GPO is linked is what we are talking about when we discuss these hierarchical levels. So far, we haven't discussed GPO links, and that is because we will spend a lot of time discussing links and linking when we start to cover the bases on filtering these GPO settings, in upcoming chapters. For now, we simply need to understand that some GPOs will contain settings that need to apply to everything in the domain, and these GPOs will be linked at the domain level.

In the following screenshot, the Default Domain Policy has been linked at the top level, or root, of the domain:

When you link a policy at the top of the domain, that GPO will filter down to each user account and device account that is present inside the domain to where it is linked, theoretically applying to all workstations, servers, and users. I say theoretically because there are a couple of reasons why a domain-level GPO might not actually apply to everything inside the domain. One of those reasons would be that the GPO was filtered to only apply to certain machines or groups (we will discuss this much more in chapter 4, Advanced Filtering of Group Policy Objects). Another reason is that some locations inside Active Directory may have inherency blocking enabled, which would stop GPOs from applying to any objects contained inside those locations. These locations that I am talking about are called OUs, and they are our next level of GPO processing.

OU-level policies

OUs are containing folders for computer and user accounts that are joined to your domain. OUs themselves are managed and manipulated by using the Active Directory Users and Computers tool, and this is the way domain administrators commonly keep all of their objects organized. In a simple environment, you may have an OU for Users and another OU for Computers. Getting a little more advanced may bring you separate OUs for Accounting, Finance, Human Resources, and so on. Taking full advantage of OUs will result in multiple OUs contained within larger-scope OUs. For example, you may have an OU for Accounting user accounts, and a separate OU for Accounting computer accounts. Or you could even create separate OUs for desktop computers versus laptop computers. Maybe one for tablets, one (or many) for your servers... the list goes on and on. If you wanted to get really crazy, you could create a different OU for every single one of your computers! (Please don't do this, as the admin who takes your job after you retire will loathe you because of it.)

Nesting OUs is a very common practice as well. Just like creating folders inside of other folders by using File Explorer, you can use AD Users and Computers to create OUs inside other OUs. This is important for making a clean structure to contain all of your domain objects, but it is also important to the Group Policy processing... er... process.

When you ask any administrator who has worked with Group Policy before, "Where does that GPO apply?" they will almost certainly start thinking in terms of "What OUs does this GPO apply to?" Applying Group Policy at the OU level is our default mentality when working with GPOs, because it is by far the most common tier to which settings are applied. Linking GPOs to particular OUs gives us extreme flexibility in handing different settings to different groups of people or machines. In contrast to the domain-level GPO shown earlier, here is a screenshot of a GPO that is being linked to only one OU (Human Resources). Even though many other OUs exist and contain objects, the settings inside the Firewall Settings GPO will only be applied to those machines that are sitting inside the Human Resources OU:

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.