I like to refer to Group Policy as insidious. Not because it’s bad! Actually, it’s quite the opposite: Group Policy provides such a useful and unmatched set of management capabilities that we all started using it almost as soon as it was available, and in many cases without putting any kind of management practices or capabilities in place first. Sure, today many companies have things like change control processes wrapped around Group Policy, but those processes often went into place after—sometimes long after—Group Policy was already a mission-critical part of the business.
While Microsoft has done a great job of enhancing Group Policy’s reach and scope with each new version of Windows, they haven’t focused on providing the business-class management tools we need to support best practices in managing and supporting Group Policy. That simply means that you’ll often need to look “outside the box” for tools that help provide and enforce those best practices. Here are five distinct capabilities you should add to your Group Policy tool belt:
Backup and Recovery
It should go without saying that you should be backing up your GPOs—but let’s say it anyway: You ought to be backing up your GPOs. Keep in mind that a normal Active Directory backup won’t grab your actual GPOs; it just grabs the links between the GPOs and the OUs, sites, and domains within Active Directory. The GPOs themselves live in separate files, and must be backed up independently.
There’s a bit more to a good backup and recovery plan than just backing up the GPO files. In general, I like to see solutions that can do so automatically, and that can break open the GPO files to analyze the individual settings within. I want to be able to compare backups of a GPO to another backup, or to the active version of the GPO (see more under “Comparison,” below) so that I can tell what’s changed. Before performing any kind of recovery, I always want to see a full report of exactly what I’m recovering, so that there aren’t any surprises.
For example, one time I ran into a problem where another administrator had improperly made a ton of changes to a GPO, and I needed to roll them back. I knew we’d pulled a backup of that particular GPO three or four days prior, so I pulled the backup and restored it. What I didn’t know is that another administrator had been tinkering with the GPO before the backup was made, so while I was undoing one set of unwanted changes, I was restoring another set. Cue gnashing of teeth and yelling at colleagues. The only solution was to stick with the backup—which was marginally less messed-up than where I’d started—and manually edit out all of the unwanted settings. Of course, it took us a few weeks to actually discover all of the unwanted settings, but that’s another story.
Restoring a GPO shouldn’t require you to take a domain controller offline or anything else impactful, so shy away from solutions and techniques that might require you to do so. And yes, the Group Policy Management Console (GPMC) can backup and restore GPOs, but it doesn’t do so automatically, so I don’t like to use it. Anything you have to remember to use, won’t get used when you need it most. As of Windows Server 2008 R2, you could also use a scheduled Windows PowerShell script to run GPO backups—and even to initiate a GPO restore. That’s fine, except for two things: First, it’s not a managed process. If it fails to run, you won’t know unless you check, which you’ll forget to do at some point. Second, it’s just a backup, without the additional capabilities for managing and comparing backups that you really ought to have in place.
Change Control Workflow
Saying that you have a change management process for GPOs is fine—but does everyone really follow it, all the time, every time they need to change a GPO? Possibly not. And, without the right tools in place, a manually-managed change control process is not only a pain in the neck, it’s incredibly error-prone. Administrator proposes a change—perhaps in an e-mail, or in a help desk ticket. Another administrator reviews the change and approves it, or whatever your process requires. First administrator implements the change - but sneaks in another one, or makes an error in implementing the change. Boom: Problems occur, and your change management “process” didn’t do a thing to stop them, which is supposed to be the whole point of the process!
No, the only way to properly manage change in Group Policy is to have a set of management tools that can be customized to enforce your desired process, while automating the error-prone bits. With the right tools, an administrator proposes changes by actually making them. The management software intercepts those changes before they’re applied to a live GPO, and runs them through your workflow. Other people review, approve, and so forth, and when the final approval is given the change is implemented automatically—so the change is exactly what was proposed, with no extra bits stuck in, and with no errors. Good tools may even let you schedule an approved change for implementation during a maintenance window, and a really good tool will provide one-click rollback to the previous version of the GPO in case it turns out you don’t like the change after all.
Version control is an implicit part of change management for me, but it’s not something you’ll find in every tool. Whether a tool achieves version control through some fancy database or by simply making and indexing GPO backups doesn’t matter. The point is that a change management tool must automate the process of maintaining versions of each approved GPO, and should make it easy to rollback to any previous version at any time.
Part of version control, of course, is being able to compare versions to see what’s changed between them. There are numerous uses for this, including auditing (which I’ll discuss in the next section).
It’s true that you can do this kind of comparison using the Group Policy PowerShell cmdlets in Windows Server 2008 R2, but it’s a bit complicated, and the results aren’t necessarily attractive or conducive to the management uses you’ll be employing. I prefer to use tools that can produce an easy-to-read report that lists all of the differences between any two GPOs. I want to be able to compare an active GPO, a backup, or a previous version of a GPO (which may in fact just be a backup file, which is fine). I might want to compare two live GPOs—such as in a merger situation, where I need to produce a new GPO that combines elements of two existing ones—and I might need to compare two GPOs from entirely different domains. There’s nothing inherently domain-specific about a GPO (keep in mind that it’s just a file, not actually stored in the directory), so a good tool should provide that kind of cross-domain capability.
This is my number one, must-have GPO feature - and one that very few companies actually think about at first. If you think about how GPOs are physically implemented, you’ll realize that there’s almost no auditing whatsoever on the GPO itself. Auditing occurs entirely within Active Directory, and only for the bits that are stored in the directory: GPO links. Change a setting in a GPO, however, and there’s no record of who made the change, what was changed, what things looked like before the change, and so on.
Yes, version control and comparisons are a great way to audit the changes made between two version of a GPO, but you still won’t find out who made a change or even necessarily when the change was made—you’ll just see the differences between the two.
There are two main reasons to want setting-level auditing in your environment: Security auditing and troubleshooting. Security auditing is probably the first reason that comes to most folks’ minds, because GPOs are increasingly being used to implement security-sensitive configuration settings. Want to make sure a server is communicating over a secure channel? Implement a GPO that provides an IPSec policy. Need to make sure user workstations automatically lock after a few minutes of inactivity? GPO. Need to display legally-mandated logon notices? GPO. Any rule or regulation that requires you to implement these configurations usually also requires you to audit any changes to the configuration, which means you need to dig into the GPOs and track who changes each setting.
The other reason, troubleshooting, is one you typically only think of when a GPO has broken something. Monday morning, everyone logs in fine. Tuesday, nobody can log in. What’s the first question you ask yourself? “What the heck changed?!?!” An audit log can provide you with the answer to that question: “Ah, somebody edited the domain-wide GPO!” Most problems come from change, and once you can identify what changed, you have a much better chance of quickly undoing it and getting everything working again.
A good GPO auditing solution should suit both needs, by collecting four important pieces of information:
- What setting was changed?
- When was it changed?
- Who changed it?
- What did the setting look like before it was changed?
GPO tools that provide automated version control - meaning they grab a backup copy of a GPO each time it changes - and comparison reports can often provide this level of auditing detail. Provided the tool can access information on who made the change, then it simply has to provide comparisons to show you what changed, what that setting looked like before the change, and when the change happened. With a good toolset, you might even be able to click on a “roll back” button for an individual change to have that setting revert to its previous state.
This is a capability that I’ve only come to appreciate in the past year or so, but it’s quickly becoming something I can’t live without.
Normally, when you’re editing a GPO, you’re working against the live file. A tool like the GPMC loads the GPO into memory, you edit it, and any change is automatically active. With a change management system in place, that change might be intercepted, compared, and put into an approval workflow, but ultimately you were working against the real GPO.
Tools exist, however, that provide a slightly different editing experience. They basically cache all of your live GPOs into an offline repository, which you can then work against. You often see this capability as part of a larger suite of features, meaning you can treat the offline GPOs just like real ones: Run comparisons, generate Resultant Set of Policy calculations, and so forth.
I used to achieve this the hard way: I actually kept a virtual machine (VM) running a copy of one of our domain controllers. The VM wasn’t connected to the main company network, so that DC was basically an offline, standalone copy. I would then edit GPOs on that machine, run all my tests and reports and stuff, and then copy the differences over to the production environment when I was satisfied. Keeping the VM in sync with the production environment was, as you might expect, a major hassle, but it provided me with a safe sandbox in which I could play with GPOs. Once I discovered tools that offered their own offline editing capabilities, I was sold.
In fact, I’ve seen some companies use offline editing capabilities as an ersatz, inexpensive adjunct to a change management process. Basically, they propose changes in the offline sandbox, have someone review and sign off on the changes, and then push the change from the sandbox into the production environment. Tremendously effective, although it’s not technically a software-enforced workflow (at least, not in the tools I’ve seen). When combined with version control capabilities, the effects are awesome: You edit a GPO offline (which in effect copies it to the sandbox repository and then opens it for editing). You compare it, run policy reports, or whatever. When you’re happy, you check it into a version-controlled repository, saving it to the live environment and retaining a copy of the previous version in the version control history. What’s not to love?
More Than Five?
Yes, there are actually some other capabilities you’ll probably need for solid GPO management, but it’s quite possible that you already have them. Solid Resultant Set of Policy (RSoP) reports, for example, are a must-have—but the native tools do an okay job of producing them, and many third-party tools exist that can provide better ones. Friendlier and more powerful third-party versions of the GPMC are popular, too, and I have several clients who already have them in place (one even developed their own). But the five capabilities I’ve discussed here are the ones I most often see missing, and they’re the ones that can provide the most positive impact to your day-to-day GPO management.