Consolidating Group Policy Objects
-
@DustinB3403 said:
So this is a two fold question regarding GPO's.
First, does it hurt to have multiple distinct GPO's for specific purposes? (say 40 for arguments sake, I don't know how many we have specifically.)
I'm assuming that multiple small GPO's means more work for the servers and client pc's that receive these GPO's but want confirmation.Second, is there an automated way to compile the existing GPO's into 1 concise GPO?
From what I know, keeping each GPO to a single distinct purpose is considered best practice so you can more easily troubleshoot group policy conflicts/failures.
-
I am no GPO expert but I believe that @WingCreative is correct. Small, discrete GPOs when possible.
-
@WingCreative I thought the same thing but am now uncertain. It makes sense, for the simplicity of the argument. You create a discrete GPO for a specific purpose. If it doesn't work, then you go back and look into it.
My concern is if existing GPO's might conflict and cause all sorts of issues.
Not having any issues at the moment. But just thinking.
-
@DustinB3403 said:
@WingCreative I thought the same thing but am now uncertain. It makes sense, for the simplicity of the argument. You create a discrete GPO for a specific purpose. If it doesn't work, then you go back and look into it.
My concern is if existing GPO's might conflict and cause all sorts of issues.
Not having any issues at the moment. But just thinking.
Fair enough, I'm interested to know which way is more efficient for endpoints processing the policy as well!
To be honest, I'm mostly just parroting what I've seen people with higher spice levels than me say on SW - though our current environment has dozens of distinct GPOs and we haven't had any issues with it an occasional gpupdate /force couldn't fix.
-
@DustinB3403 Really careful documentation of GPO's is key.
Obligatory: when I started here they had hired my boss only a couple weeks prior and she was having issues with Adobe reader (of all things) on all our PC's. Tracked it down to a GPO forcing version (7?), which triggered an uninstall / reinstall & puked.
-
Documentation... hahahah..... Matt sidebar!!
-
Always separate your GPOs out in to specific functions/goals.
Disable the Computer or User configuration if you aren't using both on the GPO.
-
There is a performance hit with many GPOs, but I don't know what constitutes many. A recent conversation leads me to believe that 10-20 GPOs processed per object should be fine, but I don't know that.
-
Multiple GPO's is definitely the way to go.
Don't get too granular though, there's a fine line between neatly contained and OCD.
Remember that the closest GPO to the object is applied last. This means that the last GPO applied will override any other GPO attempting to apply settings to the same area. -
The key...if you're into functional GPO's (vs. monolithic) is having an effective and meaningful OU structure. Otherwise, half of your time will be creating security filters or specific targeting which can get very confusing very quickly.
The performance impact of processing GPO's in general is negligible, but it does depend on what that GPO is doing (i.e. deploying software in general or printers over slow links? Have a seat and grab a cup of coffee). I would be more concerned if you have slow links at your sites - if this is the case, you need to ensure that you have Sites and Services configured appropriately and a RODC at your remote site to facilitate speedy logins.
Being aware of GPO enforcement (which you should try to avoid) and LSDO ordering will help you tons.
There's really no right or wrong way to deploy GPO's as it is more about what you're doing with them, how they are deploying, and what you're deploying them to.
Personally, my preference is to break my GPO's out to functional objects - i.e. this one is for security, this one is for desktop preferences, this one is for drive mappings, etc.
