One thing you have to love about Microsoft’s server technologies: Given an obvious enough problem, the company will usually create a pretty viable solution. One thing you don’t have to love as much: Sometimes, managing the solution can be as big a pain as managing the problem it solves. Case in point, Group Policy.
Organizations have long desired to keep their desktop computers under control, centrally specifying certain configuration settings. Microsoft’s first attempt to provide that control was pretty much a hack, enabling client computers (think Windows 95 timeframe) to download a set of registry settings from the domain controller they logged on to. Group Policy continued with the registry-based approach (since that’s where most Windows applications store their settings, not to mention the OS itself), but completely changed the way those settings were specified, delivered, and managed.
Today, any organization with Active Directory uses Group Policy objects (GPOs), even if they don’t realize it. GPOs provide the central configuration for domain controller policies, including password requirements, account lockout requirements, and so forth. Most organizations make extensive use of GPOs to configure everything from user profile settings (like redirecting home folders) to application settings.
Originally, Microsoft provided pretty bare-bones tools for managing GPOs, packing a GPO Editor into the native server toolset and providing access to GPOs via the Active Directory Users and Computers console. In the Windows Server 2003 R2 timeframe, Microsoft beefed up GPO management with a dedicated tool, the Group Policy Management Console, or GPMC. Providing more centralized, Group Policy-centric views of the directory, the GPMC also added the ability to back up and restore GPOs more easily. In Windows Server 2008 R2, Microsoft connected GPOs to Windows PowerShell, providing more capabilities for automating Group Policy management, including the ability to retrieve and set individual GPO settings from the command-line. Most admins still struggle through with those tools, missing out on some pretty critical functionality and capabilities.
Figure 1 – Group Policy Management Console
One major problem with the GPMC is that it’s an entirely online editor. In other words, once you make a change to a GPO within the editor, that change is live. Instantly. Without testing. More than a few administrators have been challenged by this. Less-informed admins will just wait until mid-day, when everybody’s logged on and their GPOs applied. Unfortunately, GPOs continue to refresh throughout the day, at a roughly hour-long interval, meaning a mid-day GPO edit could immediately impact users. Because that refresh interval includes a random factor, to prevent all users from hitting the domain controllers at once, changes will spread seemingly at random, making troubleshooting difficult and frustrating.
The solution is offline editing. You can’t get it easily with the native toolset, though. Some administrators will go so far as to build an isolated, virtualized version of their production environment, often cloning live machines as virtual machines (VMs), or restoring VMs from production-environment backups. That provides the “offline environment” needed to safely edit and test GPOs, but moving an edited GPO into production is still a manual, error-prone process. What would be better is to implement a true offline GPO cache, right in the production environment, and make edits to that. Ideally, all other aspects of GPO management – including RSoP testing, which we’ll hit next – could use that offline cache, enabling full offline testing and planning with easy migration of offline changes into the online, production environment.
One of the toughest parts of Group Policy management is planning and troubleshooting. Because an individual office worker can be affected by numerous GPOs directed both at users and at computers, it can be incredibly tricky to figure out the net policy that a user will be hit with. GPOs are layered onto computer and user portions of the registry; they don’t “conflict” with each other but instead simply follow a “last one in, wins” approach. You can spend hours trying to get a particular end configuration applied, thwarted by an overlooked GPO that’s being applied last and undoing whatever it is you’re trying to accomplish. That’s why Resultant Set of Policy, or RSoP, has become such an important planning and troubleshooting tool. The GPMC provides a good basic RSoP analyzer, essentially allowing you to pretend to be a user computer combination located anywhere in the directory, and then producing the end-result combination GPO that will be applied to that combination.
The native RSoP tools make it difficult to play “what if” scenarios, which is where RSoP should be a value planning and testing tool. For example, it would be great if you could specify a user and a computer, and then propose a change to their location within the directory – moving them to a different organizational unit (OU) without actually moving them. RSoP could then show you the new effective policy – or, even better, just the differences between the old effective policy and the one proposed by the OU move. Proposing other relevant changes, such as changes to group membership or site, would also be useful.
Figure 2 – Resultant Set of Policy
Again, the presence of an offline repository would be really helpful for this kind of troubleshooting, since you could spot potential problems, make an offline change, and then re-run the RSoP test to see if the problem was resolved. Once you fixed it, you could move the change into production.
The GPO admin’s most valuable tool? Gpupdate.exe, a command-line tool that you run on a client computer to re-load both the computer and user portions of the GPOs targeted at that user and computer. This is essentially how we test GPOs: Set up the GPO in the directory, scurry over to a client, and run Gpupdate. Once that’s done, you check whatever settings you think you put into the GPO – diving into Regedit if necessary to see the actual registry-based settings – and cross your fingers.
Frankly, it’s ridiculous. All of the technologies exist to make this testing process easier and less intrusive, not to mention less manual. For example, the GPO is already built from (mostly) a list of registry settings. Client registries are remotely accessible to administrators through the Remote Registry service (and other means, for that matter). Why not have a tool that can run alongside the GPMC that reads in the RSoP GPO settings, connects to a designated client computer, and compares that computer’s registry to what’s specified in the GPO? You’d be able to see immediately any differences from what you think you applied and what actually applied, all without having to sneaker-net over to the client computer and check.
Here’s the real feature the GPMC kind of has, but not really: Change control. Some organizations require administrators to make a backup of their GPOs before making any changes. That way, if an improper change is made, the GPO itself can be restored from backup, rolling back the change. That’s great – but why do I have to remember to do it? Why can’t the GPMC simply make a backup every time I edit a GPO, and provide me with a list of those backups?
Primarily because, to make auto-backups truly useful, you need another capability the GPMC lacks: Comparisons. I’d need to be able to compare the current GPO to any past version of it, and ideally to compare any two arbitrary GPOs I wanted. That would let me spot changes in a GPO – something auditors would love to be able to do, by the way – and roll back the correct version.
Given the new PowerShell cmdlets in Windows Server 2008 R2, you can sort of hack together a compare-two-GPOs script yourself, but it’s awkward and pretty time-consuming. Third-party tools tend to be better at it, and there are a few out there that are designed to compare GPOs automatically and produce a report of the differences, or deltas, between them.
I’ve written in the past about “missing capabilities for GPO management,” and suggested that third-party tools are a good way to gain those capabilities. Microsoft loves its Independent Software Vendors (ISVs), because they bring needed management capabilities and let Microsoft focus on the underlying functionality of the OS. After all, without that focus, we wouldn’t have GPOs at all, right?
But even if you’re not a fan of “outside” tools, you can still build some of these capabilities yourself. A virtual test environment gives you offline editing capabilities, albeit with a bit of hassle in migrating an editing GPO into production. Discipline (remembering to click “Backup” before editing a GPO) can give you a basic form of change control, and some intensive PowerShell scripting can let you compare GPOs and get a delta report. The native RSoP features, while not awesome, can do a good job of letting you plan, test, and troubleshoot GPOs. Skilled use of remote registry viewing can make testing and troubleshooting GPO application possible. The point is more about putting these practices into play in your environment, regardless about how you choose to implement them. With better GPO management, you’ll have a safer, more secure, more consistent environment for your users and servers.