Preface: I know I’m kicking the GPO tires a lot lately, but that’s because I’m running into them quite a bit with a few of the customers I work with. For some reason, all of these involve way too many GPO’s for what is really required, and way too much tinkering within them to confuse and break things. Good for me, since I get paid to troubleshoot and fix those issues, but bad for the customer, since they’re the one paying. Anyhow, I will try to move on to other topics soon.
The Short List
- Name your GPO’s clearly and descriptively
- Group your GPO settings to suit functional OR organizational use, but not both
- Configure as little as possible when starting a new GPO
- Create as few GPOs as possible when starting a new AD environment
- Test. Test. Test. and Test some more!
Name your GPO’s Clearly and Descriptively
Nothing is worse that trying to sift through 1,000 GPO’s to find the one that contains a particular setting, than when they’re all named “GPO 12345 My Internet and Office stuff”. How about “Internet Explorer settings” or “Microsoft Office settings”? Don’t make it feel like using a set of those paper and plastic Cap’n Crunch decoder glasses.
Group GPO Settings by Function or Organization, but not Both
This one is actually tougher than it sounds. If your organization contains more than a few hundred computers and user accounts, you really should sit down and think this through carefully. Mock up your GPO names and comment on each as to what they will provide. Do this on paper or in a spreadsheet first. Then, in a test lab environment, use the GPO Modeling tools to try out your ideas and see how they work. Remember to leverage the awesome power of virtual machines and snapshots as much as possible too.
Configure as Little as Possible when Starting a New GPO
There seems to be a common tendency with regards to Group Policy that drives humans (okay, sys-admins) to get wide-eyed at all the options and start configuring them right away. Stop! Wait! An eye-lift is what the doctor ordered, so don’t jump right to Bruce Jenner at step 1. The most important rule to remember about Group Policy is this: It’s way easier to add what’s missing, than to undo what you’ve already done.
Create as Few GPO’s as Possible when Starting a New AD Environment
This kind of dovetails onto the previous tip, but it is equally important.
Test. Test. Test. and Test Some More!
NEVER. NEVER. NEVER. EVER EVER try out a new Group Policy or Group Policy setting change in a production environment. EVER. If you can afford to have an Active Directory environment in the first place, you can afford to build some sort of isolated test environment.
While it is possible to carve out testing areas within the OU structure of a production site, it’s not always going to help with things like Default Domain and Default Domain Controller policy changes. If the employer refuses to support a functional test environment, that employer is not someone you want to work for anyway.
Group Policy is amazingly powerful and adaptable to almost any need imaginable. But like any tool, it comes with a price. That price is complexity and unexpected impact. I tend to think of it like a blow torch and walking into a dry forest. Be careful where you aim that thing.
If you want to learn more about Group Policy, I strongly recommend getting the book “Group Policy: Fundamentals, Security, and the Managed Desktop” by Jeremy Moskowitz (Sybex, ISBN: 1118289404)