Okay.
Let's now focus on the final bit of this equation, which is once you've linked in filter to GPO or
set of GPOs, what does the client do with that list?
How does it process those GPOs?
And that's where we want to talk about the order of processing.
So because it is this hierarchical structure.
In other words, you can have, oh, use and subclass and sub sub or use that contain users and computers.
And you can link GPOs to, you know, any number of containers at the site, the domain or the OAU level.
There has to be an order of precedence in GPO processing, especially if you run into situations where
before giving computer a user, you might have conflicting settings applying in one or two of those
GPOs.
So what does that order of precedence look like?
Well, the order is that once the computer or user figures out its list of GPOs that apply to it, the
very first GPO that is processed is the local GPO.
So if the local GPO has been defined with settings for either the computer or the user, then those
settings are processed first.
If the local GPO is empty because no one has done anything with it, then it's just ignored.
Then any site linked GPOs GPO is linked to add sites or subnets will apply and I can say that this is
that site link.
GPOs are relatively rare.
I don't see them implemented very often.
They are primarily for determining policy based on your IP subnet.
So if you have a good sense of your IP subnet structure, you could, you know, do things like printer
mappings if you're in the Dallas branch office site.
So those are the kinds of things that you can do with cycling.
GPOs.
Domain Link GPOs.
Again, apply to everyone in the domain computers or users and those are processed third after local
and site.
And then finally all you link GPOs.
Those GPOs that are linked closest to the user or computer object in most cases.
Those are applied last.
So there's this LSD.
Oh, you order.
It's easy to remember for processing, figuring out what order to apply group policy.
Again.
Why does the order care?
Because you can have a drive mapping for the drive.
Pointing at the sales share in one GPO and a drive mapping for the yes drive.
Pointing at the marketing share in another GPO.
So how do you decide which one wins?
And and that's where this LSW processing order comes into play.
So for a given user or computer account in AD, basically what happens is GPOs are evaluated based on
how they're linked.
So that computer account, lets take a computer account as an example.
Computer account exists in some O.U within the hierarchy of AD.
And when processing occurs for that computer account, it essentially evaluates all of the GPOs linked
up the tree to the domain level that applied to it.
So it makes that list of GPOs that are linked at each level of hierarchy up above that computer account
in ADI.
Then it looks at what filters might be on those GPOs and evaluates those based on whether it's a security
group filter, whether the computer object and ADI is in that security group or not, or WMI filter.
If it's like testing, for example, that the computer is running Windows seven, it evaluates that
and comes up with a filtered list of GPOs that apply to that computer account.
And then the client side extension sort of reordered those GPOs based on this LSW order.
So of course, the local GPO, which resides on the computer itself, always gets processed first and
then the domain or site or you linked GPOs get processed in the LSW order.
And essentially an ordered list of GPO is created.
Now, this, of course, implies that you can have multiple GPOs processed by a given computer or user
account in ADI.
And that's perfectly acceptable.
In fact, most group policy implementations that you'll come across on a given computer or user, they're
typically processing one five, ten, 1500s of GPOs in some cases.
And this is a perfectly acceptable use of group policy.
And certainly one that, while it does increase complexity, provides also a lot of flexibility for
you.
Now, in the case of conflicts, which is what we're really concerned with here and where LSW really
helps out, there's an order of processing that is dictated by LSW that essentially says the setting
in the GPL linked closest to the user account, an ad or computer account in ad wins.
So what this means is if let's say you've got five GPOs being processed by that computer account.
Well, the first one is going to be the local GPO, and that does its thing.
And then the next one will be any site linked GPOs, then domain linked GPOs and all you linked GPOs.
So the GPOs that are closest in terms of the view that the computer account resides in, if they contain
settings that are also contained in upstream GPOs like the domain linked ones.
Well those oh you linked ones will win if there are conflicts.
So if a domain linked GPO sets a setting to one and an audio link, GPO sets it to zero, then the zero
wins because it's linked closer and it's the last thing written by the computer object.
So I would be remiss if I didn't also mention some opportunities for modifying that default LSW order.
So there's two, let's call them flags within group policy that modify the default behavior of GPO processing
and inheritance.
One of those is called BLOCK Inheritance and the other is called enforced links.
Now, what BLOCK Inheritance is, is a flag that you set in PMC at a container level.
It's usually done at the domain or you level.
And it blocks all upstream GPOs from applying to those IOUs that are underneath or those computers and
users that are underneath that, oh, you or you set the flag.
And as you see in this screenshot, I can right click in this example my clients oyu under sales and
set block inheritance.
And what that means is any GPOs linked at the sales OYU or the at the domain or even on the site would
essentially be ignored by computers in the client.
So you and that's kind of what block inheritance does and it's typically used if you have some more
youth that contains exceptions, machines that you don't or users that you don't want policy to apply
to normally.
Now, the alternative to the block inheritance flag is enforcing a link flag.
So enforced links are done at the GPO link instead of on a container.
And what an enforced link does is it says no matter what is happening downstream.
In other words, if there's a block inheritance set on an IOU or whatever else may be happening, the
GPO link that you've set enforced on will always win.
In other words, it will always apply.
And enforce Trumps block inheritance.
So if you have a block inheritance flag set on an o u and a higher level GPO link has enforced, enabled,
then enforced always wins.
The idea there is that if you have an o u administrator that's decided, he doesn't want to receive
group policy and sets the block inheritance flag.
But you have an overall corporate administrator that might have, let's say, some domain wide settings
that they want to enforce no matter what.
You can set the enforced flag on that domain y GPO link and it will always win.
And again, it's set on the link, not containers.
So as you see in the screenshot, I've right clicked on that domain wide settings GPO that's linked
at the domain level and selected the enforced flag.
And it's usually set on links at the domain level because that's where it makes the most sense.
But it can also be set at the site level or at o use.
So if you have a hierarchy of O use, let's say in our scenario, you might want to set it at the sales
level.
If you ever GPO that's linked at the sales level, then you absolutely, positively want to apply to
either the client subcu or the users subcu.
So that's a good way of enforcing that kind of capability.