group policy best practice

[itgeek]

What's best to have hundreds of gp or less larger ones with multiple configurations in them? Its getting a bit messy? How can I search / tag gpo to make it more managable?

 

 

Thanks

[featured_spectre]

I found few larger gpo's served me better than several small ones. Reason being is that I can create larger ones to cover all needs.

[MatthewL]

I find less better.

 

We have a baseline computer and user one and work from there, i.e. if a department needs extra settings and it cannot be done on the baseline we then create an incremental one from there.

 

Keep as much of it in the one policy as you can because we found processing time when logging on was quicker. We run many branch sites without DC's so we ran into some problems and found that linking them into one policy made it quicker.

[Arthur]

You may find these links quite useful (particularly the second one)...

 

Group Policy Center » Best Practice: Active Directory Structure Guidelines - Part 1

Group Policy Center » Best Practice: Group Policy Design Guidelines - Part 2

Microsoft TechNet - Best Practices for Optimizing Group Policy Performance

[Richie1972]

As few as possible is the best way - less confusion and easier to manage. It's even better with Server 2008 and item level targetting.

I have one main computer and user policy, one policy for staff, one for students (both these just have a couple of items in that i caouldn't do so easily from the one policy, plus one for the servers. There may be a couple of other minor policies, but that's it.

[itgeek]

So for software deployment you my have 20 msi in 1 gp to deploy?

 

Thanks for the responce

[morganw]

Am I the only one who thinks that it's simpler to have more GPOs? I find it more straight forward to have GPO do a function, or group of functions, name the GPO after what it does prefixing them to differentiate between application settings, user settings, computer settings etc.

 

There might be an overhead on replication and GPO application but it means that it's easier to track changes via the modification dates, easier to find something when i've forgotten where I made the change, and if I were hit by a bus my replacement could look at the GPO names and structures and get an instant idea about how everything is actually setup.

[6Foot2]

Am I the only one who thinks that it's simpler to have more GPOs? I find it more straight forward to have GPO do a function, or group of functions, name the GPO after what it does prefixing them to differentiate between application settings, user settings, computer settings etc.

 

There might be an overhead on replication and GPO application but it means that it's easier to track changes via the modification dates, easier to find something when i've forgotten where I made the change, and if I were hit by a bus my replacement could look at the GPO names and structures and get an instant idea about how everything is actually setup.

 

You are not alone. This is pretty much how I manage our GPOs. Each GPO is named after its function. As you say it is easier to track changes [and track down problems] working with GPOs this way.

 

Or at least I think so.

[DrCheese]

aye, I have seperate GPOs for all software installations, that way it's easier to deploy software in small doses. This was useful when I recently deployed Adobe Reader X to just one area of the school and had a few errors reported to me that I hadn't seen during testing on our machines. It was easy to roll it back to the older version and the amount of users it affected was minimised.

[AngryTechnician]

aye, I have seperate GPOs for all software installations, that way it's easier to deploy software in small doses.

You can do this with a single GPO by editing the ACLs on individual bits of software inside the GPO and only allowing access to particular computer accounts/groups. That's the way we did software installation at my last school, and I did the same here until I switched to deploying through System Center. We had around 80 different MSIs in one GPO and it worked just fine for us.

 

I subscribe to the fewer GPOs theory. I split mine up so that user and computer settings are separate, and I then have a hierarchy of settings, e.g. 1 GPO with global settings that apply to all computers, then separate ones for settings that only apply to Servers and Workstations (or particular types of workstations).

[Little-Miss]

I've started Prefixing mine [software], [Power Settings] etc (I cant think of anymore lol my brain has turned to mush over xmas!)

[gshaw]

Ours were originally one big policy but some newer ones I've put separately plus the best practice for password policy GPOs etc.

 

As for software deployment I avoid GPOs for that and use SCCM

[featured_spectre]

Might have to do that for staff GPOs, prefix them so they are set up with configs and have several!