What's Wrong with Group Policy?

Although Group Policy was introduced more than a decade ago, it’s still the main way numerous Windows shops configure, lock down, and secure their Windows servers and desktops. With such an important job on the line, you would think that Group Policy would have evolved the way Windows OSs have, but that simply hasn’t been the case. Group Policy’s infrastructure, core functionality, and core capabilities have seen only minor tweaks and bug fixes since its debut in Windows 2000. Although new features (e.g., Group Policy preferences) and additional policy areas (e.g., wired and wireless networking) have been added to Group Policy, what you knew about how Group Policy worked in Windows 2000 still largely applies today. So, it’s high time to write about the significant problems in Group Policy that have appeared over the years and how you can work around them.

Group Policy Replication Inconsistencies

Problem: The storage for Group Policy Object (GPO) settings is split between the Group Policy Container (GPC) in Active Directory (AD) and the Group Policy Template (GPT) in SYSVOL. When you make a change to a GPO, the Group Policy Editor (GPE) writes changes to one or both, depending on what is being written. Most settings are written only to the GPT, but there are exceptions. For example, the GPE writes wired and wireless networking settings only to the GPC and software installation settings to both the GPC and GPT.

When you change a GPO, the change has to replicate to all domain controllers (DCs) in the environment before clients can successfully process the change. But this replication happens using two different mechanisms—one for SYSVOL and one for AD. Up until Server 2008, the SYSVOL mechanism used the File Replication Service (FRS), which was fraught with problems and thus caused inconsistencies between the AD part and the SYSVOL part of the GPO. It was only with the release of Server 2008 and its support for DFS Replication (DFSR) for SYSVOL did this situation improve significantly. However, most shops haven’t yet migrated to DFSR for SYSVOL. This inconsistency in replication means that you can’t be sure that a client has the most up-to-date version of a GPO when the client is processing Group Policy from the local DC. This can result in some clients having the policy and others not, which is not helpful if you are relying on Group Policy for crucial security or desktop lockdown settings.

Workaround: If your AD infrastructure uses Server 2008 R2 or Server 2008, you should look into migrating your SYSVOL replicas to DFSR. Although the domain functional level needs to be set to Windows Server 2008 to take advantage of DFSR for SYSVOL, the reliability of GPO replication will greatly increase.

If you aren’t at a point where you can take advantage of DFSR for SYSVOL, I highly recommend that you have tools in place to help monitor GPO replication. The GPOTool.exe command-line utility (which is part of the Microsoft Windows Server 2003 Resource Kit) reports GPO replication inconsistencies, but frankly, it’s fairly limited and sometimes doesn’t work at all. For my own environment, I created a Windows PowerShell cmdlet that I can use to quickly check a given GPO across all my DCs. As Figure 1 shows, the Get-SDMGPOVersion cmdlet checks only the GPO version numbers in AD and SYSVOL—it doesn’t look at the actual file data between all SYSVOL replicas. However, version number inconsistencies can be a good warning sign that something is wrong. You can download the free Get-SDMGPOVersion cmdlet by visiting GPOGuy's "Free Tools Library."

Figure 1: Checking for GPO version number inconsistencies with the Get-SDMGPOVersion cmdlet

In addition, it’s an excellent idea to have some general FRS monitoring in place to let you know if your FRS infrastructure is on the fritz. Microsoft has a free tool named Ultrasound (bit.ly/gPYCzT) that serves this purpose well.

Client-Side Processing Doesn’t Fail Gracefully

Problem: If you’re familiar with Group Policy processing, you know that client machines (servers or workstations) are responsible for pulling policy settings from DCs on a periodic basis, at startup, or at logon). For that to happen successfully, two steps must take place:

In each step, the Group Policy engine’s robustness is limited. For example, if a client encounters a DC that has SYSVOL inconsistencies or if the DC fails to respond to requests for GPO-related information, the client’s engine simply gives up Group Policy processing. There’s no notion of the engine failing over to a different DC to try its tasks again, even though there’s redundancy built into AD.

In addition, if an individual client-side extension encounters an exception it can’t handle (e.g., corrupt settings within a given GPO) during its processing cycle, it will typically fail completely, which means that no other client-side extensions can run after it. So, a failure in one client-side extension usually brings down the entire Group Policy processing cycle. This lack of robustness makes it difficult to rely on Group Policy as a security configuration mechanism.

Workaround: The bad news is that there’s no hard and fast solution to getting around this particular problem. The good news is that it happens infrequently. The best strategy is to prevent these kinds of failures from impacting your environment by having a good monitoring system in place on client machines to detect failures in Group Policy processing. On Windows XP and Windows Server 2003 machines, this means looking for error events with a source of type Userenv in the application event log. On Windows 7, Server 2008 R2, and Server 2008 machines, this means monitoring the Group Policy operational log for failure events, as shown in Figure 2. By monitoring failed events on your clients, you might not be able to eliminate problems but you should be able to proactively spot and correct them.

Figure 2: Monitoring failed Group Policy processing events in the Group Policy operational log

Not All OS Configuration Features Are Supported

Problem: Given that Group Policy is the mechanism for configuring Windows OSs, you’d expect that you should be able to use it to configure pretty much everything related to Windows. Unfortunately, that isn’t the case. When Microsoft releases a new OS version, it does a pretty good job of adding policy settings to cover the new features, especially within Administrative Templates. But to say that every feature in Windows is configurable through Group Policy would be a gross overstatement. Many configuration tasks that you might want to perform with Group Policy aren’t currently supported. For example, you can’t use Group Policy to:

Workaround: If a particular configuration item doesn’t have its own Group Policy setting, you can leverage the freeform capabilities of Group Policy–based scripts to make changes to the item. Under Computer ConfigurationPoliciesWindows SettingsScripts, you have the ability to run startup and shutdown scripts on a computer. Similarly, under User ConfigurationPoliciesWindows SettingsScripts, you have the ability to run logon and logoff scripts for a user. So, if a configuration item is scriptable, you can make the changes using Group Policy–based scripts. For example, Netsh.exe is command-line tool that lets you make network stack changes. You can create a startup script that uses Netsh.exe to change a network stack’s configuration, then add that script to a GPO. Another example is creating a startup script that uses the command-line Ocsetup.exe utility to install a Windows feature, then adding that script to a GPO.

When using Group Policy–based scripts, you need to keep in mind the security context in which each type of script runs. Startup and shutdown scripts run in the context of the LocalSystem account, which is privileged enough to do most any kind of operation on a server or workstation. Conversely, logon and logoff scripts run in the context of the user, who is probably not privileged on his or her system. So, you would implement most computer-related configuration changes with startup scripts.

You also need to keep in mind that startup and logon scripts run only in the foreground. This means that startup scripts run only when the computer is rebooted and logon scripts run only when the user first logs on. If you need an installation to run in the background, regardless of machine or user state, you should consider using the Group Policy preferences’ Scheduled Tasks feature to create scheduled tasks that execute commands based on the time of day.

RSoP Shortcomings

Problem: As I mentioned previously, numerous Windows shops use Group Policy’s security configuration capability for the important task of securing their Windows servers and desktops. This is a must-have rather than a nice-to-have capability for many organizations, especially those with regulatory concerns. And related to those concerns is the need to audit whether the security configurations were successfully delivered and applied to the targeted systems (e.g., registry, file system, SAM database).

Group Policy provides the Resultant Set of Policy (RSoP) feature to report on policy processing. RSoP lets you check whether GPOs and settings were received by a given server, workstation, or user, as Figure 3 shows. However, using RSoP as a compliance and audit tool has its shortcomings:

Figure 3: Checking RSoP results

Workaround: There’s no quick fix for this problem, but there are several things you can do. If you’re using Microsoft System Center Configuration Manager (SCCM), you can use its Desired Configuration Management (DCM) feature to validate security settings across an enterprise. In addition, you can download Microsoft’s Security Compliance Manager (SCM) at tinyurl.com/SCM-Download. This free tool is designed to help you write a security baseline policy that you can export to a GPO backup or DCM baseline. This makes it easy to integrate the creation of security baselines into delivery through Group Policy and reporting through SCCM and DCM.

If you aren’t using SCCM, there are a couple of tools you can use to obtain some audit information. I created a free PowerShell cmdlet called the Group Policy Health Cmdlet, which you can download at SDM Software. This cmdlet lets you query remote systems by machine, organizational unit (OU), or domain. It returns information about what GPOs have been processed and whether there were any processing errors. (It doesn’t return any information about whether the policy settings were delivered to a machine.) As Figure 4 shows, the OverallStatus entry lets you quickly see whether a GPO was successfully processed (green) or not (red). It also provides details about the GPO processing on each targeted system.

Figure 4: Checking which GPOs have been successfully processed with the Group Policy Health Cmdlet

Another tool you can use is Microsoft’s free GPInventory.exe tool, which you can download at bit.ly/h5uOi7. Although this tool was designed for XP and Windows 2003, it collects basic Group Policy information, including some RSoP data, from multiple machines in an environment. It can help get you part of the way toward the goal of knowing the Group Policy status across your Windows systems.

Lack of Features Optimized for Servers

Problem: Group Policy was primarily designed as a desktop configuration management solution. Its use in server environments is common, but it lacks some key features that make it useful as a server-based solution. Chief among these is its lack of a deterministic delivery mechanism geared toward the special needs of servers. How many of you manage server environments in which it would be okay to tell your boss that the security configuration that you’re going to do tonight will happen “sometime within the next two hours or when I reboot the server”? Most server changes are subject to rigorous change controls and need to happen at a given time to prevent outages. Because Group Policy processing is a pull-based mechanism that happens in the background every 90 minutes or in the foreground on a machine reboot or user logon, it doesn’t lend itself to the precision typically required for server changes.

Another downside to using Group Policy to configure servers is that the types of configurations you typically want to make (outside of security configurations) generally aren’t supported out of the box (e.g., the lack of support for adding and removing server roles and features). Thus, you have to rely on scripting.

Finally, Group Policy’s inheritance feature (i.e., a given user or computer can be subject to a number of different GPOs linked to their AD hierarchy) is a useful feature for workstations but leads to complications with servers. When managing server configurations, you need to know in advance what settings are going to apply to a given server when you make a Group Policy change. The RSoP modeling feature can help provide this information, but the Group Policy toolset doesn’t include a good conflict-analysis tool that will tell you what settings will be affected when you implement a new setting. This ambiguity isn’t good for server environments.

Workaround: Each problem area I just pointed out requires a different workaround. To work around the missing deterministic delivery mechanism, you can use several different tools to make your Group Policy changes take effect within a particular timeframe. The first is Specops Software’s free Specops Gpupdate tool. This graphical tool essentially lets you run a GPUpdate command against a group of remote machines, effectively forcing them to update their policy at the moment you trigger it. You could use this after deploying a policy change to ensure that your servers get the update in a timely fashion.

If your configuration changes fit into the capabilities of Windows Scheduled Tasks, you could use the Group Policy preferences’ Scheduled Tasks feature to control when a configuration change is performed. You could also use the Group Policy preferences’ Item-Level Targeting feature to apply a time-bound policy setting so that the policy setting applies only if the time on the targeted system is within the specified range. However, your time window has to be wide enough to accommodate the normal 90-minute Group Policy refresh interval—otherwise you might miss it.

To work around unsupported server configurations, you can leverage Group Policy–based scripts, as I described in the “Not All OS Configurations Are Supported” section. The configuration item must be scriptable to use this workaround.

To work around inheritance challenges, the best advice I can give is to try to limit the number of GPOs that you deploy to server systems and segregate them by function. Ideally, you would deploy one GPO for all security changes, one GPO for all registry changes, and so on. You might not be able to reach this goal, but getting close helps minimize inheritance-related problems.

Creativity, Patience, and Workarounds

I’ve laid out a number of Group Policy problems that Microsoft isn’t likely to address any time soon. There are other problems as well. But all things being equal, Group Policy is still a pretty good solution for managing enterprise configuration on your Windows systems. Given enough creativity, patience, and the workarounds I described, you can build a pretty reliable Group Policy infrastructure. And although you might not be able to pass the most stringent audit using Group Policy tools alone, you should be able to accomplish many of your desktop and server lockdown tasks without resorting to much more expensive solutions.