Okay.
Just to underscore what I just talked about with respect to functional and monolithic GPOs, let's kind
of look at two GPOs that I've created to illustrate each.
So I've created a functional GPO called functional GPO, and you can see that it only contains per computer
security settings in it.
So this is an example of a GPO that can be easily delegated to a security group using delegation I can
control who can edit this GPO and it only contains a single policy area.
Now, by contrast, I've created this GPO called Monolithic GPO, and if you'll recall, from my definition,
monolithic GPOs mean GPOs that contain settings from lots of different areas in a single GPO.
So for example, I've got a log on script to find.
These are all per user settings in this case.
I've got some admin template settings to find.
I've got a GP preferences drive map to find and a registry set setting to find under GP preferences.
So a bunch of different in this case, four different policy areas are defined in this GPO, all for
the user.
And again, I could very easily use this too.
For example, if I wanted to delegate administration of a single GPIO to the sales admins.
I could link this GPO to the sales o you under the monolithic GPO here.
Just link it to the sales OYU and give delegation rights to the sales admins group to be the only group
that can edit this GPO and give them added rights, but don't give them the ability to change the permissions
on the GPO and so sales admins could then come in and edit this GPO to their heart's content.
They wouldn't be able to create any new GPOs at the sales OYU or link any new GPOs at the sales.
Oh you level.
But they would be able to edit the single monolithic GPO where all of their settings reside.
And so that's the whole purpose or the value of monolithic versus the functional GPO.
Now remember I mentioned that from a performance perspective, you probably don't want to group one
of those synchronous policy areas like GP preferences, drive mappings in with other policy areas.
In this case, W.H. wa was exactly what I've done.
It wouldn't be an issue on Windows 8.1 because drive mappings has been changed to run asynchronously
in Windows 8.1.
But in Windows seven, if if clients were processing this GPO, what you'd end up have happening is
every time you made a change to any setting area within this GPO, whether it be scripts, administrative
templates or registry, you would end up having the drive mapping extension trigger a synchronous foreground
refresh for the next log on so the user would end up waiting for that synchronous foreground refresh
and next log on just because this drive map setting is grouped in with all these other settings.
So again, it's a good idea to avoid doing that.
If you're in a Windows Seven world and you're trying to keep performance at a maximum and trying to
minimize the impact of group policy processing on user experience and log on.