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:
- The clients must successfully query AD to determine which GPOs apply to the current computer and/or user.
- Each client-side extension or policy area must successfully execute the logic to process the policy settings.