In recent days, I’ve become aware of a couple of interesting “features” around Group Policy in Windows 8. Both were reported by other users and I confirmed their behavior on my own. The first issue, which I would categorize as a bug, is the following.
As you probably know, in the version of GPMC that ships with Windows 8/2012, there were some improvements made to the RSoP (Group Policy Results) reporting to help troubleshoot GP Processing problems. These improvements include the new Summary screen, as shown below.
This new screen gives hints as to problems that might be occurring in your GP environment. In some testing I was doing, I had been seeing GPOs report “AD/SYSVOL Mismatch” errors in my reports. I didn’t think much of it at the time, but then a fellow MVP reported the same thing from a user he had been talking to and it got me looking into it. It turns out that this message can be spurious under a certain set of circumstances. Namely, if a GPO is denied to a computer or user (usually because of security group filtering or WMI filtering) then that GPO seems to return this AD/SYSVOL mismatch error. I believe this has to do with where Microsoft is collecting GPO version information from for this report and the way that that information mucks with the version number of SYSVOL in particular on the target client. Namely, when a GPO is not accessible to the computer or user, the GP engine stores the SYSVOL version as hex FFFF, which translates to a decimal value of 65535. You can see the manifestation of this quirky behavior by looking in the Details tab of the GP Results report. If you expand the “Denied GPOs” section, you will likely see the GPO shown in the Summary tab with a SYSVOL version number of 65535, as shown below. This is how you know the “AD/SYSVOL Mismatch” error on the Summary page is not correct.
The second issue was just posted in our comments section today, in response to an earlier blog post I did about managing Group Policy in a Windows 8 world. The poster reported that he had a Wireless Security policy (Computer Configuration\Policies\Windows Settings\Security Settings\Wireless Network (802.11) Policies) that had been created from Windows 7. He edited that GPO on a Windows 8 box, then someone else tried to edit the same GPO from Windows 7, and got the following error:
So, basically editing that GPO from Windows 8 rendered it un-editable from Windows 7. While I’m not terribly surprised about this, I had not known about that particularly behavior. Once you start editing GPOs in the latest platform, it’s usually best practice to start using that platform for editing those GPOs going forward, but you always hope this stuff is mostly backward. Sometimes, it’s clearly not!