Posey's Tips & Tricks
Best Practices for Group Policy Management, Part 1
Group policies have been a core component of Windows Server and Active Directory for decades, and yet it never ceases to amaze me how many different philosophies there are with regard to group policies. In this series, I want to share with you some of the most useful group policy tips and tricks that I have learned over the years.
Keep Things Simple -- If You Can Over the years, I have read countless books and articles outlining methods for creating really complex group policy structures. I will be the first to admit that such architectures do indeed have their place. Even so, just because the Active Directory lends itself to building complex group policy structures, this does not necessarily mean that you need to overly complicate your group policy infrastructure.
Personally, I like to keep things simple. Simple group policies are far easier to troubleshoot and maintain than complex group policy structures. Having a single group policy (such as the Default Domain Policy) greatly simplifies the process of trying to figure out why a group policy setting was applied unexpectedly. Of course, the flip side to this is that if you only have a single group policy then that one group policy will be applied to everyone. That might be OK in a smaller organization, but it probably isn't going to be an option in a larger organization. Fortunately, even if you work for a large organization, there are some things that you can do to make group policy management easier.
Document Everything
The trick to preventing your group policy structure from becoming an unmanageable mess is to keep everything well organized. I will talk about some strategies for keeping things organized a little bit later on. Before I do though, my number one best practice with regard to organizing your group policies is to document everything.
Simply put, nobody should ever have to wonder what a particular group policy does or why that policy was created. An admin should be able to easily ascertain a group policy's purpose by using nothing more than the information found in the Group Policy Editor. Admittedly, this sounds like a lofty and possibly unattainable goal, but there are a couple of things that you can do to better document your group policies.
First, adopt a naming convention for every group policy that you create. Unfortunately, there is no such thing as a universal naming convention that will work for everyone, because every organization is set up differently. Even so, it shouldn't be too difficult to come up with a naming convention that works for your organization. Some organizations, for example, include the department name and the policy scope within the policy name (Marketing-Computers and Marketing-Users).
The good news is that you don't have to worry about getting the naming convention right on the first try. Whether your initial idea for a naming convention just isn't working or your organization's dysfunctional group policy structure has been in place for years, you can always rename a group policy. Just right click on the group policy and select the Rename command from the shortcut menu, as shown in Figure 1.
[Click on image for larger view.]
Figure 1. Microsoft allows you to rename your group policies.
Another thing that you can do to ensure that your group policies are well documented is to add comments to each group policy. To do so, right click on the group policy and select the Edit command from the shortcut menu shown in the figure above. This causes Windows to open the Group Policy Editor. The Editor displays the name of the group policy that you are editing at the top of the console tree (just above Computer Configuration). Right click on the policy name and then select the Properties command from the shortcut menu. When the policy's properties sheet opens, select the Comment tab. As you can see in Figure 2, this tab allows you to write comments about the selected policy.
[Click on image for larger view.]
Figure 2. You can add comments to a group policy.
This of course raises the question of what type of things you should add as comments. Again, the answer will be different for every organization. However, your comments might include things like when the policy was created, who created it, what the policy is to be used for and why. Although I have never encountered it in the real world, I have even heard stories of organizations using the Comment tab as a change log. When an administrator creates or modifies a policy setting, they document the change within the change log.
Now that I have spent a good bit of time talking about group policy documentation, I want to spend Part 2 of this series discussing some strategies for developing an effective group policy structure.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.