Understand Group Policy processing order and inheritance

- [Voiceover] When it comes to understanding the Group Policy processing order and application, there is a term that I really want you to become familiar with, and that term is L S D OU. Now you'll notice if you look on the screen that L S D OU is not really a term, it's just a bunch of letters, but I said it in the form of almost as though it's a word. Right, L S D OU, and the reason why is because the understanding of Group Policy processing order and application is so important that over the years as I've been working with it, it has just become basically like a word, or a term for me.

Alright, so what do these letters actually stand for? Well they stand for each of the containers that a Group Policy object can be linked to. Alright, so the first one, L, is simply local, and it's not so much that a Group Policy object can be linked to a local container, it's that we can have a local Group Policy object. Then from there, we do have the three types of container objects that we can link Group Policy objects to, and they are site, domain, and organizational unit.

So, that's just an understanding of the different places that we can have Group Policy objects being applied to and being linked to, but why do we specifically say L S D OU, or what is the importance of the order of local, site, domain, and organization unit? Well, let's talk about what happens when, for instance, a computer turns on, which is when the computer settings are applied. Well when the computer turns on, the first thing that happens is it looks at the local GPO, if one exists, and really I shouldn't say if it exists, because it always exists.

It's just a matter of whether any settings have been applied to it. If there are any settings applied to the local GPO, then it applies those to the computer that's being turned on. Then from there, the system will check to see what site a computer belongs to, and it will then look to see if there are any Group Policy objects that have been linked to that site and it will then apply any settings that are in any GPO's that are found linked to the site. It then proceeds to do the same process for whatever domain the computer belongs to.

Then it looks into the organizational unit that the computer account would belong to, or reside in and technically I really should say that L S D OU is L S D OU OU OU. The reason why is because typically we have not just one level of organizational units, but we have a hierarchy of them. When you look to see what container or what organizational unit an object resides in, it may not be a top-level organizational unit, it may be a child OU down in the hierarchy.

So what will actually happen there is while the computer account for instance, let's say, resides down in a child organizational unit, and I have it illustrated here as though it's a couple levels deep, what would actually happen is the system would first look at the top-level organizational unit, or the top parent-level organizational unit in that hierarchy, look to see if there's any Group Policy objects linked to that OU, and then apply them, and then it works its way down to the next level through the hierarchy, checking each step along the way to see if there's any Group Policy objects that are linked to that container, until it finally ends up down at the organizational unit level that the object resides in.

Now I mentioned that this happens when the computer turns on, and that is for the computer settings. This whole process will actually happen again when the user logs in and it will do it for the user-based settings, based upon what containers that the user may belong to or reside in. What does this matter, that we're talking about this whole L S D OU? Why does it matter that we go to local, then site, then domain, and then the organizational unit? Well, many of the GPO settings can be either set to enabled, disabled, or not confiigured and I like to think of it as almost kind of like saying, we're either going to turn something on, we're going to turn it off, or maybe we just leave it alone.

The problem that we run into is that we can have multiple GPO's that are applied to the same user or computer. This happens because, as you can imagine, the computer for instance, is part of a site, and it's part of a domain, and it resides in an organizational unit. There might be GPO's that are linked to all of those different containers, and some of those GPO's might have a conflicting setting from another GPO. So to really answer the question of why does the order matter, well it's how conflicts are resolved.

So let's go back to our illustration here of L S D OU OU OU, and let's say hypothetically that we have a GPO that has been linked to the domain. We'll say a user, just for the sake of argument, that a user resides in, and that GPO turns something on, or maybe it gives access to something. One thing that we'll actually see in other lessons is we'll see that by turning on the GPO, we may actually remove access from something.

Ok, but for the sake of argument, we're just going to say that this GPO turns something on. The user resides down in an organizational unit where there's another GPO that's been linked. In this GPO, it happens to turn off that exact same setting. So we have one GPO that turns it on, one GPO that turns it off. What is the end result? Now a lot of people like to think, based upon their knowledge of how many other aspects of Microsoft Operating Systems work, that the more restrictive tends to take precedence.

Right, if it turns it off, then let's leave it off, or maybe enabling it means that you've made something not available, so that wins. Well I can tell you that all of those rules, you can just throw them away. When it comes to GPO's, the rule is the last setting applied wins. So in this example, the GPO at the domain level would've turned on the setting, and that would've happened first. Then the GPO at the organizational unit level turned off the setting, and that would've happened afterward, and so that setting wins, meaning the setting is turned off.

So if we reverse this and we say that the GPO linked to the domain turns off something, and then the GPO linked to the OU turns on something, then in this case, the setting would be on. Alright, so it doesn't matter which one's on, which one's off. Neither of them has precedence over the other. The end result is the last setting applied. So this is default order of application and inheritance of Group Policy object settings.

It's really important that you allow L S D OU to become pretty much a term in your own mind, because it is truly the first step when it comes to understanding how settings end up being applied, and when it comes to troubleshooting any problems that you might be having with those settings.