Now that we've sort of gone over some of the different approaches.
In terms of designing your ad, I want to talk about some general best practices around group policy
deployment.
So I have a set of rules that I've sort of established over the years that are sort of are tried and
true in terms of how you should approach group policy deployment.
Rule number one is link your GPOs as close to the intended targets as possible.
So this is this notion that we don't really want to have to do security group filtering if we can link
GPOs really close to their targets, whether they be computers or users.
So instead of linking at the domain level, all of your GPOs and putting a bunch of security group filters
on them to control which computers and users process them, we want to link down in those values that
we talked about in the previous example.
So what the you for example, if we have a user policy that applies to sales users, we want to link
it at the sales user view in order to get the closest possible targeting.
And sort of the corollary to that is using filtering, security group filtering, WMI filtering or group
policy preferences item level target should be done on an exception basis.
Again, organizing aid to balance administration and group policy needs is a key piece here, and I
talked a lot about that in the last section, limiting the fingers in the pie.
What do I mean by this?
What I mean is keep the fewest possible number of administrators managing group policy as possible.
This prevents people from stepping on each other from not following standards and from just generally
making changes that other people don't know about.
So having control over who's editing group policy, remember our discussion about group policy delegation?
It's very easy to control who can do what within group policy using the delegation model, and I highly
recommend that.
So avoid that one setting, one GPO.
So this is a common thing that folks will get into where they need a setting, and they decided to create
a new GPO for that setting.
And it's fine if you're doing it a couple of times.
But if it becomes a practice where you have 100 GPOs each with one setting in them, then you probably
need to rethink that.
And I like to group settings by function or type, and especially as delegation requires.
So for example, I might put all of my security settings in a standalone GPO so that they can be delegated
to the security administrator in my organization.
Avoid the copy and paste phenomenon that I talked about in an earlier module.
So you need some settings that you have in another GPO.
Well, the handiest thing to do is to just copy and paste that existing GPO.
Problem is that oftentimes people won't go in and clean up the settings that they don't need from that
source GPO And so then you've got lots of redundant settings running around.
So I try to avoid.
If you're going to do copy and paste, make sure you're going to go in and clean up the settings that
you don't need out of that new GPO Group Policy Settings performance before Windows 8.1.
These three policy areas Group Policy Drive Mapping GP preferences drive mapping folder redirection
in software installation require a synchronized foreground refresh and they should be separate from
other policy areas in GPOs.
So keep these separate from let's say admin templates or security and you'll improve your performance.
And I'll talk a little bit more about this in a second.
Avoid that.
Always wait for the network at computer startup and user log on policy.
But I had mentioned earlier that sets every policy processing foreground cycle to synchronous.
If you don't really need this, then don't set it universally.
I know a lot of shops that set this universally and they're automatically inflicting their users with
a penalty and boot up and start in log on time and then finally always back up your GPOs.
We talked about GPO backups and how easy they were to do.
Always, always, always do this.
A lot of people don't get into the habit of this and get bitten by it when they make changes or have
to roll back GPO changes.
I want to talk now about kind of the design approach with the actual GPIO and how you group settings
in GPOs.
A bunch of years ago, I came up with this these definitions monolithic and functional GPOs, and I've
been using them ever since as a way of classifying the two different types of GPOs or monolithic or
GPOs that create that contain settings from a lot of different policy areas in a single GPO.
So you group software, installation settings, admin template, whatever in a single GPO, and that's
contrasted with functional GPOs, which are really where you have one or more settings from a single
policy area.
The example I just gave was security policy, all security policy in its own GPO and just security policy
in that GPO, and that would be an example of a functional GPO.
So which do you deploy?
Well, most environments are going to have a combination of both, which is perfectly reasonable.
It ends up being driven by factors like the delegation needs, the complexity, you know, certainly
monolithic.
GPOs tend to be more complex because you've got a lot more stuff going on in them, but they're great
for delegating to or you administrator, you make one GPO with all the settings that that all you administrator
needs and say you have rights over this GPO and no others.
Also, security mandates might drive this.
Do I need to delegate my security settings to the InfoSec team?
If so, then I might want to just have a separate GPO for just those settings.
And then, you know, each type is going to make sense in a certain situation.
There are some considerations around processing performance that might lead you to one versus the other.
And I, I give you the hint that it's the functional type that tends to perform better because of the
reason I mentioned in my previous list where if you have synchronous policy settings like folder redirection,
software installation or GP preferences, drive mappings in with let's say admin templates and a single
GPO.
Whenever you make a change to any of those areas, it will automatically trigger a synchronous foreground
refresh.
So having those synchronous areas in separate GPOs can be better for performance.
So a little bit more about functional GPOs really used to isolate the single setting or the group of
settings and you know, for example, account policy, perfect example of a functional GPO.
A lot of people use the default, the main policy just to do password policy for the domain and that's
a good approach.
But you can go overboard here.
There are some considerations around processing performance that might lead you to one versus the other.
And I, I give you the hint that it's the functional type that tends to perform better because of the
reason I mentioned in my previous list where if you have synchronous policy settings like folder redirection,
software installation or GP preferences, drive mappings in with let's say admin templates and a single
GPO.
Whenever you make a change to any of those areas, it will automatically trigger a synchronous foreground
refresh.
So having those synchronous areas in separate GPOs can be better for performance.
So a little bit more about functional GPOs really used to isolate the single setting or the group of
settings and you know, for example, account policy, perfect example of a functional GPO.
A lot of people use the default, the main policy just to do password policy for the domain and that's
a good approach.
But you can go overboard here.
Again, you don't want hundreds of GPOs with a single setting in them.
Think about grouping settings based on function or type.
If you're going to use the functional approach, have, let's say, all admin template settings for
the marketing folks in a single GPO monolithic GPOs ideal for delegating to administrators, you know,
or you administrators because you can create, like I said, a single GPO with all the settings they
need, delegate edit rights to that GPO and they're done.
And it has a tendency for those scenarios to keep those settings in a single, manageable delegated
place and it for them.
For those of you administrators, it kind of eases troubleshooting because it gives them the ability
to look in one place to find and fix potential problems.
And that's a good thing.