locked
Has anyone else experienced Windows 10 build 1803 machines disappearing from WSUS after installing 2018-05 Cumulative update for Windows 10 version 1803 (KB4103721)? RRS feed

  • Question

  • We just started testing Windows 10 build 1803 by realeasing the feature update through WSUS. For us, all went well, and at first the WSUS updates being released were still being detected just fine, all seemed normal.

    This morning, after releasing 2018-05 Cumulative update for Windows 10 version 1803  for x64-based Systems (KB4103721) --we only run 64 bit machines now-- 13 of our 16 test machines show that they failed to install that update, and only 3 machines succeeded in installing the update and all 3 of those are now just gone from WSUS, and so far no explanation.

    3 of the 13 machines that failed to install this update appear to have installed all other updates ok, 2 other machines got all but 3 updates installed, and then 8 appear to be stuck with 16 updates being needed.

    Testing with the machines that actually succeeded in applying the cumulative update, running "usoclient.exe StartInteractiveScan" to force a connection and using netstat to look at connections shows that the machine is connecting to our WSUS server like expected. The event log viewer on the client hasn't revealed anything, and I haven't found anything on the WSUS server either.

    We are running WSUS on Windows Server 2016 build 1607, as a virtual machine on a HyperV host. (Not sure that makes any difference, but just in case.)

    This update does not appear to be removable - at least it doesn't show up in the list when selecting "uninstall updates", so that's not going to be a solution.

    Thought I'd warn others about this sooner rather than later.



    • Edited by twgage Friday, May 11, 2018 3:40 PM
    Friday, May 11, 2018 3:30 PM

All replies

  • Hi twgage, Windows 10 Cumulative Update KB4103721 maybe have some issues, some users also complained the problem. Please uninstall this update KB4103721 from your Windows 10, here is link for your reference,

    https://www.windowscentral.com/how-remove-update-kb4103721-windows-10-april-2018-update

    Then double check whether the 3 machines return to WSUS. If the 3 machines come back to WSUS, we will report this issue to Microsoft. If not, I will keep troubleshooting. Hope this could help you.


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

    Monday, May 14, 2018 7:18 AM
  • I may have spoken too soon on the "successful" installs - WSUS was showing a count of 3 as having succeeded, and that matched the number that disappeared from the WSUS lists of computers (when trying to report which three had succeeded, nothing would be displayed) I just used a list I had of machines we manually put in the test group and compared it to ones still being listed to determine the 3 that had succeeded, or WSUS somehow registered them as succeeding. But now...

    When on one of the machines locally, the update is not listed for removal, as I mentioned originally.

    Also, when I use the safe-mode boot as the "wusa" command to remove it, it just comes back with a message saying that that update is not installed.

    I've tried searching WSUS content for an MSU file that I might could use with WUSA, instead of trying the KB number, but I haven't come up with anything that I could use for that.

    We don't have the other option available on these machines (ie, there are no recovery points since that function is disabled by group policy here.)

    Do you know of an MSU file that could be used with WUSA to uninstall KB4103721, since the machine itself seems to not realize it has that update installed?

    --Note: I realize that we will probably just wind up "dumping" an image onto these machines, using one prior to build 1803. (It is now looking like all the 1803 build machines are having issues installing updates, so it is appearing more likely that 1803 is just not as stable at this point as what we need for production machines.)

    Anyway - thanks for the article, and thanks in advance if you do know of a stand-alone msu file that could help uninstall this update.

    Monday, May 14, 2018 10:07 PM
  • Might have duplicated IDs for those machines? This could happen if the machines were cloned and not done "clean" in the Microsoft sense.

    As far as I know, WSUS should sort this out after a while these days, but there is a chance that you are running into this issue.

    As you probably noticed, usoclient startscan is no longer working as expected in 1803 and now we have to use usoclient startinteractivescan to trigger WU client manually at any time.

    usoclient startscan seems to be working but only after a certain time passed, maybe when the scheduled task is due to run anyway.


    Tuesday, June 5, 2018 11:25 PM
  • No, these machines were not clones, they were deployed through SCCM originally, using SCCM's task-sequences, and the images were properly prepared using SCCM's image capture process, etc. So there should be no issue there. And actually they were fine on 1803 at first (or at least they weren't disappearing); it wasn't until the May cumulative update for 1803 that they disappeared from WSUS.

    And yes, I did notice that I am having to use 'startinteractivescan', although I didn't connect it to the 1803 update at the time - but that makes sense. I don't think I've see 'startscan' start working again, but then that may be a result of abandoning it once it stopped working. I'll give that a try again.

    Other notes on 1803 would include RSAT tools disappearing, and a normal re-install not working. I know there are some other issues as well at least for business machines, but can't recall them right now. Home version seems fine - seems like all the love in development now goes to the home version, at least up to the initial release.

    Perhaps most of it will be straightened out in 6 months, and then we can move everyone to it. Kind of interesting the way things have panned out - we used to have a target of having everyone on "one OS version" - which usually meant 2 versions. But with Win10 builds, if they're counted as different versions, I think we've wound up with 6 at the moment, as a result of the weird issues and instabilities in these versions when they are released.

    Maybe the QA process will improve over time.

    Wednesday, June 6, 2018 1:14 PM