Group Policy is a tremendously powerful tool for managing and controlling your Windows environments. Unfortunately, when many of us venture into Group Policy Management, we have a particular task in mind and don’t put much thought into it beyond “How do I make it work?”
Making it work is often pretty straightforward. So much so that it can be pretty easy to get into trouble. Having seen a few Group Policy infrastructures recently that seem to have resulted from “just making it work” I thought I would take a moment to encourage you to put a little time into how you implement Group Policy Objects.
Often, the fastest path to implementing a new setting is to alter the Default Domain Policy, but once you start down that path you’ll probably continue to make changes in that Group Policy Object (GPO). Yes, it’ll probably work, but designing GPOs in this way undermines the hierarchical application and functionality of Group Policy, as well as applying settings to users and devices that do not require those settings.
Here are the principles I try to follow when utilizing Group Policy:
- Create a GPO for each setting (or group of similar settings)
- Link GPOs as far down the OU structure as possible, given which AD objects need to receive the policy
- Target GPOs to appropriate groups or devices using Security Filtering and WMI Filters
- Use a descriptive and standard name format. GPO names are purely there for us humans, so don’t feel that you need to be frugal with characters. I’ll start with a general description like “Config”, “Drive Map”, “Printer”, or “Security” to group and categorize the GPO. Then, separated by hyphens further subcategories as necessary, and then a helpful description. Here are a couple examples:
- Security – Workstation – Windows Firewall
- Config – Server – Windows Update
- Drive Map – Workstation – Shared Drive
Hopefully, using these guidelines will help you create a robust, problem-free, and easily managed Group Policy infrastructure.
Shane Skriletz, PEI
