locked
Windows 10 clients not showing correct OS build after receiving updates RRS feed

  • Question

  • We are having continual issues with the Cumulative Updates applying properly to our client systems. We are using Windows 10 Pro 1909 with WSUS.  This has happened with the March, April, and June Cumulative updates so far, that we have noticed. 

    WSUS reports the version is correct, however, the actual PC shows the older version. The client PC Windows Update screen also shows a warning the client is out of date. We then have to uninstall the latest cumulative update and reinstall it to get it to show up properly on the client PC. 

    Example:
    PC Shows version 18363.778. PC windows update screen shows PC out of date.
    WSUS shows KB4567512 installed
    Programs and Features on the PC shows KB4567512 installed.
    Must uninstall KB4567512 and reinstall to get the version to show properly as 18363.904 and the windows update screen to show as up to date. 

    This is happening on probably 25-30% of our PC fleet (30-50 Desktops and Laptops). There is no correlation between hardware or driver versions that is causing this that we can see.  

    Another ill effect that we see occur in relation to this is that when some of the PC's reboot to apply the updates they BSOD for various reasons, the main being something along the lines of "no boot device found", or something to that effect.  When they reach this point the only way to recover is to re-image or to do a system reset.  We've tried system restores, but that causes even more issues and never fully resolves the issue.
    Friday, July 17, 2020 12:29 PM

All replies

  • Hi stevedub40,

    Thank you for posting on this forum.

    It seems to related to the Windows pro version. The Windows 10 1909 pro is the end of service on May 11, 2021. It is recommended to install feature updates to upgrade to the latest version. We may try to refer to the following picture to get the feature update by WSUS:




    Approve the feature updates for the Windows 10 1909 pro clients to upgrade to the latest version.

    Reference link:
    https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet

    Regards,
    Rita


    "WSUS" forum will be migrating to a new home on Microsoft Q&A!
    We invite you to post new questions in the "WSUS" forum's new home on Microsoft Q&A!
    For more information, please refer to the sticky post.

    Please remember to mark as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, July 20, 2020 6:14 AM
  • Hi Rita,

    Thank you for the reply.  So in our environment we typically wait a few months to push out the major Feature updates, so most systems will be a revision behind.  This is pretty common in most evironments, especially for how poorly Windows Updates have been going lately.

    The problem is not related to the Feature updates, but to the current Quality updates that are received each month.  I actually just had a fresh system exhibit this issue with the July MCU.  As mentioned, what happens is the updates installs, system is rebooted, then WSUS sees it as being up to date with the update installed (shown in the WSUS reports). 

    When on the client system, though, a lot of times we will see things like this (taken from a different system):

    But if you hit the "Check for updates" it does nothing.  You will also see that Windows think the update is installed:

    But when you look at the build number, it is still showing the old build:

    If left in this state we have found that when the computer reboots or installs the next Windows update we will get an Automatic Repair bootloop due to "Inaccessible_boot_device", which I promise is not a hardware issue.  Once in this state we either have to re-image or do a system reset. 

    The most difficult thing in this issue for us was that WSUS was reporting that the client was updated, but it does not show the full OS build, so we did not catch that until later on in troubleshooting.  Thankfully we were able to use PDQ Inventory to show us the full OS build on the problematic systems.  At least when we know ahead of time that a PC is not on the correct OS build we can fix it before it is a problem, but the problem from that is we have to manually do this every month, which is just absolutely ridiculous with an enterprise OS.

    Please let me know what would be needed to investigate this further.  I tried to paste the WindowsUpdateLog from one of the systems, but it looks like it is way too large to paste.  I could try to provide a download like, if it will let me do so.

    Thanks,
    Steve


    • Edited by stevedub40 Monday, July 20, 2020 5:51 PM
    Monday, July 20, 2020 5:49 PM
  • Hi stevedub40,
     
    Thanks for your response.
     
    It seems that the clients miss some important security and quality fixes. We may try to check online for updates from Microsoft Update to install these missing updates. 

    Let's see if this problem exists after installing the missing update for the client.
     
    Regards,
    Rita

    "WSUS" forum will be migrating to a new home on Microsoft Q&A!
    We invite you to post new questions in the "WSUS" forum's new home on Microsoft Q&A!
    For more information, please refer to the sticky post.

    Please remember to mark as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, July 21, 2020 5:43 AM
  • Hi Rita,

    We would like to avoid pulling updates from MS, as this will also pull Feature updates and drivers, which we like to have control of.  As I mentioned, this isn't a one off occurrence and has been happening randomly to systems for most of this year.  Also, what we notice when systems are in this state is that the next round of updates typically will cause a BSOD and then an Automatic Repair bootloop.  

    I also had this happen recently to a fresh system when it installed the July update.  For this one though it showed in the Update History that it was pending a reboot, even though it really wasn't.  I rebooted and it still showed the same pending status and no amount of forcing check-ins or reboots changed the status.  I had to actually uninstall the updates and reinstall to correct the issue.  Now while this would not be an issue for one off systems, it is becoming a nightmare for dozens of systems each month, especially with many people being remote due to COVID-19.  

    Is Windows 10 simply not suitable for WSUS updates any longer?  We have had so many issues over the years that have not been resolved.  A major one we had last year was that clients just simply stopped checking in for updates and none of the usoclient.exe commands would work to help kick off the updates.  We had to disable automatic updates for clients to check in on their own (go figure), which also gave us the ability to use usoclient.exe again.  

    If there is anything you can think that I can collect the next time one of our systems exhibits this behavior please let me know and I would be happy to provide it.  We are extremely exhausted with battling Windows updates, which is supposed to be an automatic process and should not require this much manual intervention.

    Thanks!
    Steve

    Thursday, July 23, 2020 1:04 PM
  •         

    Hi stevedub40,

    1. In order for me to research further, please help to provide a screenshot about version number about the Windows 10 1909 pro client on the WSUS console.

    Reference picture:


    2. Also, here are the ways to check OS build and version on the client for your reference. The WSUS console shows the client version. If you already know how to check the OS build and version on the client, please ignore the following information.

    The way to check the OS build on the client:
    Open run on the client and then enter "winver" command. Please refer the following picture:



    The way to check the version on the client:
    Following the path on the client and find wuaueng.dll file. And follow the below picture to check the version on the client.
    Path: C:\Windows\System32

    Reference picture:





    Thanks for your patience and cooperation.

    Regards,
    Rita


    "WSUS" forum will be migrating to a new home on Microsoft Q&A!
    We invite you to post new questions in the "WSUS" forum's new home on Microsoft Q&A!
    For more information, please refer to the sticky post.

    Please remember to mark as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, July 24, 2020 10:28 AM
  • Hi Rita,

    Thank you so much for looking into this for us.  I do have some systems in this state that I can probably leave untouched if there is anything you would like to look at or logs we can review.

    Thanks again!
    Steve

    Friday, July 24, 2020 4:15 PM
  • Hi stevedub40,
     
    Thanks for your response.
     
    I noticed that the KB4567512 is the C and D non-security updates. We could try to install the latest CU (KB4565483) to observe whether this issue exists or not. 
     
    Note that please try to install KB4565554(the latest SSU) before installing the KB4565483(the latest CU).
     
    Regards,
    Rita

    "WSUS" forum will be migrating to a new home on Microsoft Q&A!
    We invite you to post new questions in the "WSUS" forum's new home on Microsoft Q&A!
    For more information, please refer to the sticky post.

    Please remember to mark as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Sunday, July 26, 2020 7:44 AM
  • Hi Rita,

    I somehow totally missed this post by you, so my apologies.  Below are screenshots of an affected system.  I'll see if I can find one that is not showing "Pending Restart" in the update history to see if they are similar as well.

    Monday, July 27, 2020 1:46 PM
  • Hi stevedub40,
     
    Thanks for your response.
     
    In my opinion, the pending restart may be due to the need to restart after the client installs the updates. However, the client is at active hours. Please help to refer to the following picture to check for active hours on the client:
     


    I recommended to approve and install updates outside of the active hours.
     
    Regards,
    Rita

    "WSUS" forum will be migrating to a new home on Microsoft Q&A!
    We invite you to post new questions in the "WSUS" forum's new home on Microsoft Q&A!
    For more information, please refer to the sticky post.

    Please remember to mark as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, July 28, 2020 6:26 AM
  • Hi Rita,

    I think we may be digressing a bit on the issue.  I can 100% confidently say that the issue is not due to a pending reboot.  I have tried everything I could think of to clear the reboot flag and no amount of reboots, power cycles, or forced update check-ins will remedy the issue.  Also, I would say only about half actually say a reboot is pending, where there other half say it installed successfully.

    I think you might be on to something, though, with your previous post.  It looks like even though we are on 1909 our build still shows as 1903 in the wuaeng.dll details as well as in WSUS.  I did a little research and found that a lot of others were also seeing this behavior, but there did not seem to be a consistent answer if this is a major issue or not.  It seems like some people show the correct OS build after the 1909 feature update, but many are not.

    This would make sense as to why Windows updates gets confused and possibly why we get incorrect reporting on successful installations.  Could you please explore this further and let me know if there are any ways to correct this short of upgrading to 2004?

    Thanks,
    Steve

    Tuesday, July 28, 2020 3:27 PM
  • Hi Freya,

    Thank you kindly for the detailed response and sorry for my delay.  This looks to be for ConfgMgr, which we unfortunately do not have due to our size.  Right now we currently have WSUS for updates and we are using PDQ Inventory for our statistics.  Thankfully PDQ deploy pulls the OS build and version from somewhere else, so I know when systems are not updated properly.  

    After discussing further with management we are going to see about updating to 2004 to see if this helps with our problem.  I don't think I can take another month of reaching out to individuals and manually fixing this problem, lol.

    Thanks!
    Steve

    Friday, July 31, 2020 8:52 PM
  • Please note: The Windows Update Agent and the version of cumulative patch level are RARELY the same. The Windows Update Agent is updated through the Servicing Stack Updates (SSUs).

    Adam Marshall, MCSE: Security
    https://www.ajtek.ca
    Microsoft MVP - Windows and Devices for IT

    Sunday, August 2, 2020 4:52 AM
  • Hi Adam!

    A pleasure chatting with you again!  Is the wuaueng.dll for the Windows Update Agent?  Is this what you are referring to?  To me it just seems like poor design that WSUS bases it's info off of something that may or may not actually get updated.  PDQ and other inventory managers seem to be able to tell the correct OS version/build, why is WSUS not able to?

    I think the other frustrating part is that WSUS tells us that these systems are patched properly, but really they are not.  Another nice thing would be able to run some sort of repair, or even re-install the update to get it fixed so that it would only take one reboot to complete.  That would be something we can script or deploy in some way, preferably with WSUS.

    This month we are going to try the Feature upgrade to 2004 to see if this helps with our issue.  At least WSUS seems to track the correct version on the ones that have updated to 2004 (mine is one of these).

    Thanks again for all the replies and we will keep on digging until this is resolved (or switch to Linux, J/K :) )

    Thursday, August 6, 2020 4:00 PM
  • Any help would be highly appreciated as I'm also facing similar issue at my clients location.

    _______________________________

    Subbam Mahars, MCSE Certified

    Systems Engineer @ iBomma

    Thursday, August 6, 2020 6:55 PM
  • wuaueng.dll = Windows Update Automatic Update ENGine (I THINK that's what it stands for - that at least makes sense).

    Yes, it is the Windows Update Agent.

    As an alternative, WAM is able to rename all the operating systems so that you can easily find and sort your client list from within the WSUS GUI. It doesn't negate the fact that the patch-level version of the OS 10.0.[majorversion].[patch-level] isn't populated properly, but it gives you at least a better reference point than just numbers.


    Adam Marshall, MCSE: Security
    https://www.ajtek.ca
    Microsoft MVP - Windows and Devices for IT

    Friday, August 7, 2020 12:41 AM
  • I think the other frustrating part is that WSUS tells us that these systems are patched properly, but really they are not.

    The computer wouldn't report that it is up to date and not needing any updates unless it truly installed properly. The update sequence is transactional. If the update doesn't apply during reboot, the transaction is discarded and you're back to before. After boot, a report into WSUS in about 20-30 minutes after boot will give WSUS the error message, error codes, and report that the update failed to install. It will still 'need' the update.

    If the update is successful, the transaction is committed and about 20-30 minutes after boot, will report back to WSUS that the installation was successful, and that is when the update is removed from the 'needed' bucket in WSUS.


    Adam Marshall, MCSE: Security
    https://www.ajtek.ca
    Microsoft MVP - Windows and Devices for IT

    Friday, August 7, 2020 12:46 AM
  • Hi Adam,

    Thanks again for the reply.  I really wish what you stated was the case for us, but what we have found is that systems that do not show the correct build after patching will eventually start to BSOD and get stuck in an Automatic Repair boot loop.  WSUS will report that the system is fully patched and in good standing, but when we start to dig deeper that is not the case. 

    Since we figured out the issue I have noticed some that were showing builds as old as March even though WSUS says it is up to date.  Once it gets to this point is when the bad stuff starts to happen.  Also, a lot of the times Windows Update History will show that it is still "Pending Restart" even though the update is installed and multiple reboots have taken place.

    The method I used to correct this issue was to uninstall the latest CU (either with wusa.exe or control panel) and before rebooting I would then install the latest CU again and do the reboot.  For most systems this would fix the issue and get to the correct build without BSOD.  On a handful of systems I would have to run through this process twice, though.  The behavior is very strange as it was like the first process "cleared" whatever this issue was and then the second pass would actually update the system.  On a couple systems, though, they would either get rebooted before I could get to them or the update would get stuck uninstalling and then the dreaded issue would happen.

    Please let me know if you need any further details or if there is anything you can think of that we can try to prevent this issue from happening.

    Thanks!
    Steve

    Friday, August 7, 2020 12:32 PM
  • How are you determining they are not fully patched? What method are you using to figure that out?

    Are the computers actually reporting properly to WSUS in the first place? Delete all client systems from the WSUS MMC, run the client side script on each computer once (best to use a deployment tool over GPO for this)

    Let the computers re-identify with WSUS and report back in.

    https://www.ajtek.ca/wsus/client-machines-not-reporting-to-wsus-properly/


    Adam Marshall, MCSE: Security
    https://www.ajtek.ca
    Microsoft MVP - Windows and Devices for IT

    Saturday, August 8, 2020 12:02 AM