Group Policy Best Practices – Part 2 – Naming and Usage

A mistake I see constantly, is that GPOs are either too specific in what they do an what they apply to, or are so broad and encompassing that they are impossible to manage.

The GPO with too many settings  (WRONG)

A classic example is the generic GPO that contains a hundred different settings that someone at some point in time was a good baseline for all computers or users.  This will often be called “Base Workstation Settings” or “General Server Settings” or something similar, and everything gets thrown into it.  When you need to change these GPOs or troubleshoot them, it can be an absolute nightmare.

“What does the General Server Settings policy even do? How much documentation do I need to read to figure it out?”

The “too-specific” GPO  (WRONG)

These GPOs are the other extreme, where settings for specific users or computers are hard-coded into the GPO or are so specific that they can’t easily be re-used.  If you wanted the same settings to apply to more objects, it’s too hard to modify the original, and you end up creating a duplicate of the GPO that does the same thing, but to a different set of users or computers.  It’s messy, and again, too hard to support.

Eg: If you need Windows Firewall ports for SQL server to be opened, this is not the way to do it:

 

Single Purpose GPOs (RIGHT)

In this model, you create GPOs with a single, easily understandable purpose.  These GPOs can contain more than one setting, but they should serve a single functional goal.  In this way, GPOs can be re-used and applied to any OU at anytime, because it’s understood what its exact function is. And, by naming the GPOs with a description of what they do, means you can see at a glance exactly what’s being applied to each OU.

Does this mean you will have a lot of GPOs – yes, quite likely.  But now they’re more or less plug and play.  Easy to see what they do, and easy to disable a single function when troubleshooting (just disable the whole GPO).

This is pretty basic, but you get the idea at how much easier this is to administer:

 

With the above, if I decide that the Workstations should also have the same Desktop Background configuration as the RDS servers, it’s a 2-second task to link the existing generic GPO “Set Wallpaper (Corporate Logo)” to the Workstations OU.

Simple.

 

Naming Conventions

As I mentioned in Part 1, Group Policy settings are for computer objects OR user objects. And your GPOs function should be limited to one of those (and not try and do both).  Ie; when you open a GPO, there are two distinct sections, Computer Configuration, and User Configuration.

Settings in the Computer Configuration section will ONLY apply to computer objects (no matter how much you want them to apply to users).  Similarly, settings in the User Configuration section will ONLY apply to user objects.

“I applied that GPO to the Servers OU, but it doesn’t work”

I often see User Configuration settings in a GPO, and that GPO linked to an OU with computer objects only.  Those settings, regardless of who logs in, will have ZERO effect. So knowing if your GPO applies to users or computers is something that’s good to see at a glance, so you can instantly know where you should be linking which GPOs (so that they actually work)

 

My preferred naming convention is to prefix each GPO with either the letter “C” (for computer) or “U” for user.

Compare these two screenshots.  On the left, I wouldn’t know where to link the GPOs without drilling into them (too hard).  On the right, it’s obvious that if I want to add a shortcut for Chrome, I need to link that GPO to an OU with users, not computers.

 

 

And finding mistakes is easy:

 

Making GPO processing at logon faster, and preventing mistakes

While not a huge timesaver, there is a measurable difference to the logon speed for users if you disable the settings that don’t apply (in the cases where you accidentally link user settings to computer objects, and vice-versa).  A general best-practice that’s worth following as it only takes a second to do and prevents any problems should you accidently link the wrong GPO to the wrong OU.

On the Details tab of each GPO, you have the option to change the GPO status.

 

 

For Computer-setting GPOs, you should disable the User configuration settings.

For User-setting GPOs, you should disable the Computer configuration settings.

When you’re done, your GPOs should look something like this, where the “C” GPOs have user settings disabled, and the “U” GPOs have the computer setting disabled):

 

Leave a Reply

Your email address will not be published. Required fields are marked *