Group Policy Blog

Group Policy Tips, Tricks, and News from Darren Mar-Elia

A Couple of Good Windows 8 Issues Around Group Policy

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.

win8rsopissue

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.

sysvolmismatch

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:

wireless issue

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!

Darren

There are 11 comments .

Peter Lustig —

OK, I have the the problem decribes a sissue one in a domain. The policies a managed on a DC based on Win 2008R2 and I have mans GPols that will not be processed on a Wind 8.1 x64 workstation due to the problem.

So how can I handle it now? There are very simple rules, like ceonnecting network-share by a “net use”-script, but they will not work at the moment :(

Reply »
Daniel

Hi Darren,

I’ve come across a similar issue twice, and haven’t yet had time to try and replicate it.

If I modify a GPO using Windows 8 or 8.1 gpmc, it breaks the GPO for downlevel clients, including Windows 7. An example of this; I have a GPO that contains about 10 software installations. I removed one installation, and all of the software within that GPO uninstalled as it came “outside the scope of management” for some reason. I then edited that GPO in Server 2003 gpmc, and all of the software reinstalled itself on the machines in question. Highly strange.

Reply »
Susan Bradley —

“AD / SYSVOL version mismatch” message is displayed unexpectedly in the Group Policy Results report in Windows 8 or Windows Server 2012:
http://support.microsoft.com/kb/2866345
Came across that.

Reply »
Patrick

So far this hotfix was only available for Win 8.0 / Server 2012.
Since a couple of days this hotfix is also available for Win 8.1 / Server 2012 R2.
And it is also included in this update rollup:
http://support.microsoft.com/kb/2919394/en-us

Reply »
Patrick

One more issue to add:
If you define a GPP Item with an Item Level Targeting based on category “Operating System” such as “Windows 8″ or “Windows 8.1″ and later try to open that ILT with an older Version of GPEdit, you will receive an Unhandled Exception: “System.IndexOutOfRangeException”. There are different OS / ILT combinations which will raise this error.
OK, I understand that the older OS does not Support the newer ILT Options. But an unhandled exception is the worst way to treat this. At least MS could have used the same message as for the Wireless interoperability issue or something similar…

Moreover it is noticable that “Windows 8.1″ OS ILT is reflected as “WINBLUE” in the GPMC Report.

By the way, to overcome this limitation I’d recommend to use registry based ILT filters using the “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CurrentVersion” value instead of the built-in OS ILT.

Reply »

Share Your Thoughts!

Copyright ©2013 SDM Software, Inc.
Site design by Social Media Ninjas | Sitemap