none
AD / SYSVOL Version Mismatch Alert after deploying MS16-072 / KB3159398

    Question

  • Prior to deploying MS16-072 / KB3159398 to our Win7 and Win8 systems, we reviewed all our GPOs and added Authenticated Users with read where it was removed for security filtered GPOs per the Microsoft guidance due to the user policy processing context changing from user based to computer based.

    We have now deployed KB3159398 to a few test win7 and win8 systems and after comparing before and after gpresult reports are seeing a different issue impacting the Windows 7 systems only, we are wondering if Microsoft is aware of this additional issue with the patch.

    After receiving the patch Win7 systems are showing an AD / SYSVOL Version Mismatch Alert with the SYSVOL version showing as 65535 for almost all computer policy as well as user policy GPOs. Win8 systems with the patch deployed are not showing issue and show no alerts, and they show the AD / SYSVOL version in sync as normal.


    When looking at the details for a specific GPO, the SYSVOL version now shows as SYSVOL (65535). Looking at other articles online, it appears this version that is displayed is likely not correct and may be due to the GPO being inaccessible to the computer or user (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).


    I am wondering is Microsoft is aware of this as another issue with patch KB3159398?

    I should clarify that the mismatch is showing for many GPOs that have always had Authenticated Users listed in Security Filtering (read and apply group policy), as well as for computer policy, so it isn't only showing for GPOs where Auth users was recently added.

    I do see other people reporting this exact issue here:

    https://community.spiceworks.com/topic/1678833-sysvol-version-not-showing-correctly-gpo-security-correct-after-kb3159398


    Wednesday, July 13, 2016 3:48 PM

All replies

  • I'm seeing this "issue" for more than 4 years now - but since it is merely an optical irritation rather than a real issue, you can

    a) safely ignore it on your own or

    b) open a case with MS support who will safely ignore it for you

    :-))

    (Remark: Win7 is already in extended support, so there will be no fix)


    Greetings/Grüße, Martin - https://mvp.microsoft.com/en-us/PublicProfile/5000017 Mal ein gutes Buch über GPOs lesen? - http://www.amazon.de/Windows-Server-2012--8-Gruppenrichtlinien/dp/3866456956 Good or bad GPOs? My blog - http://evilgpo.blogspot.com And if IT bothers me? Coke bottle design refreshment - http://sdrv.ms/14t35cq

    Wednesday, July 13, 2016 4:34 PM
  • Thanks for letting me know, that is very interesting you have been seeing it for years, we have never seen that issue so far on our Windows 7 systems. What is concerning me is that we are only seeing it as well as a lot of other people in that other thread after this specific patch is deployed. And because the cause of it displaying like that appears it could be permission related, I am worried the group policy changes in the patch may have causes the clients to not be able to fully ready the GPO which could cause some adverse impact.
    Wednesday, July 13, 2016 4:44 PM
  • > Thanks for letting me know, that is very interesting you have been
    > seeing it for years, we have never seen that issue so far on our Windows
    > 7 systems.
     
    I first saw it in Win8 (or was it 8.1?) for denied GPOs where the
    internal 0xFFFF made its way into the report. I opened a case for that,
    but since there was no business impact, it was not accepted. And since
    then I keep seeing it here and there.
     
    Apparently the underlying code change made its way into Win7 through
    MS16-072.
     
    Wednesday, July 13, 2016 4:55 PM
  • Just thinking then, if the report is going to show this mismatch permanently moving forward, is there anyway to determine if there is a actual mismatch? Also interesting that we aren't seeing it for our Windows 8 systems, only for our Windows 7 systems.

    I did a gpresult directly from a Win7 client and it showed the same mismatch as using GPMC from Win7/Win8 workstation. Interesting when you do it from a Win10 GPMC it shows the alert differently as "Inaccessible, Empty or Disabled" for all the GPOs 

    Wednesday, July 13, 2016 5:14 PM
  • Agree with Martin Binder on this.  This is cosmetic.  I've seen it too on a Windows 2008 R2 AD network with Windows 7 client machines (15,000+).  There's a small trick to make the AD/Sysvol version mis-match go away, and I picked this up from a Microsoft Field engineer when I spoke to him about it (around two years ago):  Make an innocuous "change" in any GPO.  For instance, flip something from "Not Configured" to "Enabled" or from "Enabled" to "Disabled".  Ok you're way out of the GP Editor window, then go right back and and reverse what you just did.  This has worked for me in the past, let me know if it works for you.

    Best Regards, Todd Heron | Active Directory Consultant


    • Edited by Todd Heron Thursday, July 14, 2016 12:04 AM Spelling typo fix
    Thursday, July 14, 2016 12:03 AM
  • I also have read and tried everything and still see the AD / SYSVOL Version Mismatch within both local and remote GPMC.

    I am at wits end


    RF


    • Edited by RUOK2 Friday, July 15, 2016 4:40 PM
    Friday, July 15, 2016 4:40 PM
  • Same here, I had tried from both Win 10 and Directly from the AD servers...

    The one difference is when I perform a RSOP on Win 1o system, I do not receive the SYSVIL mismatch errors, but when I perform a RSOP on a Win 2012 AD Server, it does show SYSVOL Mismatch.

    I am wondering if this could have something to do with me updating the ADMX files under the SYSVOL, or is it strictly due to the MS patch. As it started happening around the same time MS released the patch. And from all the reading I have performed about this, many others are experiencing the same issue, even with the MS patch applied.


    • Edited by RUOK2 Friday, July 15, 2016 4:47 PM
    Friday, July 15, 2016 4:41 PM
  • Hi,

    Thanks for your post.

    Are there any updates?

    If the replies have resolved your problem, please mark it as answer as it would be helpful to anyone who encounters the similar issue.

    Thank you.

    Best Regards,

    Jay


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, July 18, 2016 7:29 AM
    Moderator
  • Agree with Martin Binder on this.  This is cosmetic.  I've seen it too on a Windows 2008 R2 AD network with Windows 7 client machines (15,000+).  There's a small trick to make the AD/Sysvol version mis-match go away, and I picked this up from a Microsoft Field engineer when I spoke to him about it (around two years ago):  Make an innocuous "change" in any GPO.  For instance, flip something from "Not Configured" to "Enabled" or from "Enabled" to "Disabled".  Ok you're way out of the GP Editor window, then go right back and and reverse what you just did.  This has worked for me in the past, let me know if it works for you.

    Best Regards, Todd Heron | Active Directory Consultant


    I did try this and then waited and rebooted some clients and they are still seeing the same issue, so this did not seem to resolve it.
    Monday, July 18, 2016 2:40 PM
  • Hi,

    This issue occurs because one or more Group Policy Objects (GPOs) cannot be applied because of security filtering or Windows Management Instrumentation (WMI) filtering.

    More specifically, a Group Policy is filtered because the Group Policy reporting engine assumes that the GPOs that are related to the Group Policy use version 65535 of the Group Policy template. Therefore, when the assumed version value is compared with the current version value of the GPC that the GPO uses, a mismatch occurs. This mismatch is then reported in the Group Policy Results report.

    Here is hotfix to fix the problem.

    "AD / SYSVOL version mismatch" message is displayed unexpectedly in the Group Policy Results report in Windows

    https://support.microsoft.com/en-us/kb/2866345

    Best Regards,

    Jay


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    • Proposed as answer by Todd Heron Thursday, July 21, 2016 12:17 PM
    Thursday, July 21, 2016 7:00 AM
    Moderator
  • Jay,

    Thanks for the link to the hotfix, that would appear to resolve the issue when the SYSVOL version is showing as 65535 due to security filtering or WMI filtering for Windows 8 systems. That has been occurring all along for us when the GPO is security/wmi filtered from applying, however the main new issue here is that the mismatch alert is now appearing for GPO's which are not security/wmi filtered out, and that are actually applying to the system.

    Also this hotfix is for Server 2012 / Windows 8 systems, we are in fact only having the issue occur for Windows 7 systems, so this hotfix would not be applicable to the Windows 7 it seems.

    Everyone,

    I did open a premier case with Microsoft to get official clarification on this and they did confirm what Martin Binder indicated, that this is a cosmetic / false positive issue. They are now aware of reports of this issue occurring starting with the patch and they are going to update the known issues on the patch page so others will be made aware of this information.

    They did also confirm that requests to resolve this have been submitted to MS before but since Windows 7 is in extended support they will not be releasing a fix for it. They also confirmed that this hotfix Jay listed isn't for Windows 7 so it would not help in this case.

    • Proposed as answer by Todd Heron Tuesday, September 13, 2016 3:23 AM
    Thursday, July 21, 2016 2:53 PM
  • We managed to resolve the issue by enabling Group Policy Logging on all the clients:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics]
    "GPSvcDebugLevel"=dword:00030002

    We actually enabled to logging to try to trace the problem, but changing this setting allowed the GPOs to update.

    (We haven't tried the Hotfix listed, but will be interesting to see if it resolves the issues for all clients)

    Tuesday, August 02, 2016 9:06 AM
  • We have same issue with Group Policy Modelling / Group Policy Results.

    All working Policies have this AD /SYSVOL Version Mismatch.

    kb2866345 is installed, but it does not help. Maybe i need to reboot DC first.

    I see that it's cosmetic (GET-GPO -All works correct)

    DisplayName      : WSUS_Package_Publisher
    DomainName       : xxx.local
    Owner            : xxx\Domänen-Admins
    Id               : fe02b5cc-6bea-455f-b8ae-41e04df4d6b4
    GpoStatus        : AllSettingsEnabled
    Description      :
    CreationTime     : 26.03.2014 15:52:59
    ModificationTime : 08.08.2016 14:08:30
    UserVersion      : AD Version: 0, SysVol Version: 0
    ComputerVersion  : AD Version: 4, SysVol Version: 4
    WmiFilter        :

    BUT this warnings are just annoying and MISLEADING by troubleshooting.

    P.S. i do all tests on DC (Server 2012) and i hope it's not in extended support like Win7, so this glitch will be fixed soon.

    And frankly... MS could do it for Win7 too since it's definitely a bug and hundereds of tousands admins will spend millions of hours on such misleading BUG in DEBUG-Tool, lol


    • Edited by IT Admin Tuesday, August 09, 2016 10:46 AM
    Tuesday, August 09, 2016 10:42 AM
  • I too am seeing this issue.  My DC's are fully patched so the Hot Fix from back in 2014 referred to below is not the answer.  This appears to be something new — and very frustrating.  I've spent all day trying to figure-out what has happened here.

    Here is hotfix to fix the problem.

    "AD / SYSVOL version mismatch" message is displayed unexpectedly in the Group Policy Results report in Windows

    https://support.microsoft.com/en-us/kb/2866345

    Monday, September 12, 2016 6:55 PM
  • Bahahhahah!

    Consider it ignored!

    :)

    Tuesday, March 20, 2018 3:47 PM