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!
Darren
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 🙁
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.
That is strange Daniel. I’ve not heard of that one but it sounds like something is seriously broken. If you get time to replicate it, please let me know what you find.
Darren
“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.
Cool. Thanks Susan!
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
Great info 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.
Hi there,
all my “2012 R2” installations have that issue:
pressing “F1” in gpedit while focusing any GP Preferences item (or using the “Help” button) brings up the quite useful Windows HELP with specific Information for the appropriate GPP topic.
This does not work for “2012 R2” – only an empty page is presented. But this does work for 2008 (R2) and non-R2 of 2012
Can anybody confirm that?
Thanks,
Patrick
Patrick-
I have confirmed that this is also an issue for me and have reported it to Microsoft.
Darren
Darren,
Have you heard anything back from your Microsoft channel regarding this issue?
At one point I was getting the Sysvol Mismatch error when running GPResults from my 8.1 workstation but I recall downloading a hotfix for it (perhaps the one above), and that issue went away, however I continue to have a strange issue.
Just about all my GPOs report Inaccessible, Empty or Disabled in the GPResults when running against a remote Win 7 client from my 8.1 workstation. If I run the GPResults from my 2008 R2 DC, everything reports fine.
Just ran across this post while searching so I figured I’d see if you heard anything yet.
Sorry for the delayed response Matthew. I am continuing to see issues with the SYSVOL mismatch error on Win8. I have not heard about that GPResults issue on Win 8.1. Is that using the command line version of GPResults or the GPMC version (or both)?
Darren
Just to confirm, i have the same issues where the results show “Inaccessible, Empty or Disabled ” i have tried with both the GPMC and gpresult.exe. I run the command / console from win8.1 client against a win7 client.
But when i run this against a win8 client i do not get these errors.
Thanks Alex. I have confirmed other Group Policy MVPs are also experiencing this but I have yet to see a good explanation or fix from Microsoft.
Darren
Thanks to Alex’ tweet, it looks like Microsoft has fixed this reporting issue in the August rollup: http://support.microsoft.com/kb/2976965
Darren
Hi,
It Looks like we are having the same Problem. Is there already a fix available?
On all our DCs the mentioned KBs are already installed.
Problem started after editing an existing GPO created in an older client version