When I was working on the update for our Group Policy Health Reporter freeware tool recently, I noticed a very annoying “feature” that Microsoft seemed to introduce into Group Policy on Windows 7 and 2008-R2 systems. I’m pretty sure it started when they released the infamous MS16-072 patch that I blogged extensively about last year. Namely, any health check or Group Policy Results report that you perform against a Windows 7 or 2008-R2 system that returns the list of GPOs processed by that computer (or a user on that computer) will show a message telling you that a GPO SYSVOL mismatch has been reported, as shown here:

AD/SYSVOL Mismatch Error

This doesn’t happen on Windows 8.x machines that are fully patched (note that Microsoft did have a previous issue related to this on Windows 8.1 and Server 2012-R2 that was patched via this KB, but that is not this problem) or Windows 10 machines, so what gives?

Honestly, I’m not sure what changed with MS16-072 on Windows 7 machines that caused this. We know for a fact that Microsoft shifted the security context of per-user GP processing to run as the computer, but that doesn’t explain this issue. Clearly something broke in Resultant Set of Policy that we are not likely to see fixed. That said, what does this error mean exactly, and how can you tell if you have a legitimate SYSVOL replication error?

Making Sense of It

So, a couple of things to remember. First off, it’s been a long time since the GP client actually cared about the version of SYSVOL for a given GPO. The version information held in SYSVOL, which is stored in the GPT.ini file for a given GPO, is generally not referenced at all when the client determines if “something has changed”. Specifically, the client looks at the Group Policy Container (GPC), or AD part of the GPO, found under CN=<GUID of GPO>,CN=Policies,CN=System within your AD domain, to decide if the GPO has changed, and therefore needs to be processed. So even if the GPT version is off, the client won’t care. That said, it’s still useful to know if the SYSVOL part of a given GPO has replicated to every DC after a change. And the interesting thing is, this phenomenon of the client showing a version mismatch has nothing to do with what’s stored in SYSVOL. The version number stored in the GPT.ini file is not incorrect–and you can verify GPO up-to-dateness using the same tools we’ve always used, like GPOTool.exe, the GPO Replication Status screen in GPMC (starting in Windows 8.1) or my own GPO version PowerShell cmdlets (which admittedly are old and need to be updated!).  So then the question is, does it matter if the client is storing the wrong information? No, not really. If you are trying to determine the client’s up-to-dateness with respect to ensuring that a given client has processed the most recent version of a GPO, you can still get the GPO’s AD/GPC version number from the client, using a tool like our Health Reporter shown here:

The Group Policy Health Reporter showing GPC version information.

If the GPC version number for a given GPO at the client, is the same as it is in AD, then you are golden! You know that the client has processed the most recent version of the GPO. So, while this error message is annoying, it is not terribly important, and hopefully by the time Windows 7 fades into the sunset, we’ll have forgotten all about it!

Darren