none
Win10 Build 1803 Clients -- Monthly Cumulative Update Not Offered (May 2018 -- KB4103721)

    Domanda

  • Our organization rolled Windows 10 Build 1803 (x64) out a few days ago via WSUS.  Workstations were originally running 1607 1709.  All went well!

    Now, for our first patch Tuesday since the deployment, we find that none of our Windows 10 clients are properly detecting as "needing" the Cumulative update released today for Windows 10 Build 1803 (KB4103721).  Yet, if we instruct each client to check with the Microsoft Update servers directly, they do detect, download, and install the update.

    I have tried stopping the Windows Update service on one of the clients, deleting the "SoftwareDistribution" folder, and re-detecting.  But this did not resolve the issue.

    Any other suggestions?  Anyone else experiencing this?

    Bri

    martedì 8 maggio 2018 20:56

Tutte le risposte

  • Similar issue here. Can't update KB4103721 from WSUS. Can update from Microsoft Update.
    martedì 8 maggio 2018 21:18
  • We also have the exact same problem. 1803 WSUS clients ignore the cumulative update as 'Not Applicable', but if we 'manually check online for updates from Microsoft Update' from each client machine, it detects, downloads, and installs the update.
    martedì 8 maggio 2018 21:24
  • It's perhaps worth noting that our 1803 clients are successfully downloading and installing the Microsoft Office security updates released today. So we know that the workstations are communicating effectively with the WSUS server. They just don't seem to recognize KB4103721 as one intended for them.

    martedì 8 maggio 2018 21:51
  • Our 1803 clients could get all Office updates installed through WSUS. Just not KB4103721.
    martedì 8 maggio 2018 21:56
  • Same problem here. My 1803 test box (which upgraded from 1709 to 1803 via WSUS last week) does not recognize the May 1803 Cumulative update or the May 1803 Flash update as applicable from WSUS.
    martedì 8 maggio 2018 22:00
  • Same problem here. 

    May Cumulative update for Win 10 1803 not detected as need when checking on WSUS, but detected and installed when checking against MS WU.

    Although Windows MSRT May 2018 update detected/reported to WSUS as needed.

    Also Win10 1803 boxes stopped automatically reporting their status to WSUS. Only after pressing "Check for update" manually several times their status is updated.


    • Modificato Frankas mercoledì 9 maggio 2018 04:50
    mercoledì 9 maggio 2018 04:28
  • Also Win10 1803 boxes stopped automatically reporting their status to WSUS. Only after pressing "Check for update" manually several times their status is updated.


    Regarding 1803 boxes not reporting to WSUS. . . that seems to be a separate issue.  Indeed, I noted the same behavior during prior Feature Updates via WSUS.

    In my experience, boxes that were updated via WSUS to Build 1803 do not check for updates or report back to the WSUS server until someone logs into the computer for the first time.  At which point, a quick click within the Windows Update UI and a "wuauclt /reportnow" works fine (with no need to do it several times).

    I have been meaning to make a separate thread about this before this issue with the Cumulative Update arose.

    mercoledì 9 maggio 2018 05:12
  • Same here! Office updates detected, 1803 CU for May not detected! (WSUS: 2012 R2)

    It's the same as we saw back with 1607, when it came out. It's so sad that Microsoft does not test with WSUS...

    ->People, upvote the first post of this thread, let Microsoft know!



    mercoledì 9 maggio 2018 06:31
  • Same in my Organisation with Windows 10 1709 (with KB4103727) and 1803 (with KB4103721)!
    No Windows 10 Client found the Cumulative Updates from May 2018.
    • Modificato EDV-RPD mercoledì 9 maggio 2018 07:07
    mercoledì 9 maggio 2018 06:36
  • Same Problem with Windows 10 1709 Clients (Build 16299.402 with https://support.microsoft.com/en-us/help/4093105) that should require May 8, 2018—KB4103727 (OS Build 16299.431) https://support.microsoft.com/en-us/help/4103727 Clients before 402 work.
    mercoledì 9 maggio 2018 06:40
  • Also see https://www.reddit.com/r/sysadmin/comments/8hzl82/1803_may_cumulative_update_wsus_fail_to_detect/
    mercoledì 9 maggio 2018 06:43
  • The Flash Updates seem to have the same Problem.
    Not installing on 1803 via WSUS.
    Haven't checked 1709 so far.

    mercoledì 9 maggio 2018 12:55
  • We are having the same problem here.  Our 1709 Pro machines are showing in WSUS for their 2018-05 cumulative, but for our 1607 LTSB machines WSUS isn't showing a cumulative.  I'm seeing it on the Windows catalog site and I can search for KB4103723 in WSUS and find it, but its not displaying.  It appears that I can approve it from the search, but not sure if I want to at least yet........

    Note:All the other updates appear to be showing for 1607, just not the cumulative.

    mercoledì 9 maggio 2018 12:59
  • Similar issue here.

    We Can't update KB4103721 (and any Windows updates) on our Win10 1803 from WSUS(2016).

    Only the Office 2013 Updates were offered and worked.



    • Modificato olivierdsm2 mercoledì 9 maggio 2018 14:10
    mercoledì 9 maggio 2018 14:02
  • "Me too" - Haven't seen any 1709 or 1803 cumulatives yet in WSUS running on Server 2016.  We DO have a GPO in place to block feature updates for 365 days to prevent random PCs from pulling down 1803 and breaking things...
    mercoledì 9 maggio 2018 14:40
  • Same here. The stations I pushed 1803 Feature Update to last week that installed it are checking in, but report KB4103721 as not applicable. It gives other May updates (MSRT, Office updates) but not KB4103721. If I check Windows Update directly or install the KC MSU file directly, it works fine. 
    mercoledì 9 maggio 2018 16:06
  • Same issue here, upvoted the thread. 
    mercoledì 9 maggio 2018 16:12
  • I have the same problem. Neither the cumulative update nor the Flash update will be shown for 1803 Clients when using WSUS.

    We already saw this issue when 1607 was rolled out. And again when 1703 was rolled out. Does Microsoft want to get users off WSUS?


    cu, Ingo

    mercoledì 9 maggio 2018 16:14
  • I too am seeing this.  1607, 1703, 1709 Enterprise versions all affected.  CU and FLASH Updates are not shown as required.  Seems like a lot of people are having this problems.  Lots of chatter on reddit and listervs... hopefully this will get resolved soon. 
    mercoledì 9 maggio 2018 16:26
  • Exactly the same situation. We have the problem for Windows 10 1803 and Windows 10 LTSB 2016. Both don't get the latest updates from WSUS.

    regards, Reisenhofer Andreas

    mercoledì 9 maggio 2018 17:35
  • I’m having the same problem in our environment:

     

    WSUS: 6.3.9600.18838 Windows Server 2012 R2

    Affect versions of 1709 Pro: 402 and 371

    Known Affected KBs with a status of “Not Applicable” in WSUS:

    ·         2018-05 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4103727)

    ·         2018-05 Update for Windows 10 Version 1709 for x64-based Systems (KB4131372)

    ·         2018-05 Security Update for Adobe Flash Player for Windows 10 Version 1709 for x64-based Systems (KB4103729)

    ·         Windows Malicious Software Removal Tool x64 – May (KB890830)

    NOTE: We have no x86 Windows 10 systems

    Office 2016 updates are getting applied and installed just fine

     

    We have no 1803 systems yet, therefore unable to test. Our few 1703 systems don’t appear to be affected, but there’s only one in my test group, therefore will need more to confirm.

     

    Previous to this we haven’t had issues with Windows 10 getting updates from our WSUS server.

     

    I was able to get these updates to install if I click “Check online for updates from Microsoft Update” without being upgraded to 1803 (our Group Policy settings might be prevent that for now). However this isn’t a solution with the number of systems we have compared to IT staff we have.

     

    I highly suspect there is a problem with the Prerequisite or Applicability Rules with the packages as imported through WSUS, because it doesn’t affect if Windows 10 systems which go directly to Microsoft for updates.

     

    As a nonprofit we can’t afford a support contact from Microsoft, therefore not sure where to go from here.


    • Modificato Scott Kraft mercoledì 9 maggio 2018 18:20
    mercoledì 9 maggio 2018 18:16
  • We were able to reproduce this on a variety of systems:

    1. System running 17134.1 (via ISO)
    2. System running 17134.5 (via ISO + Manual Patch)
    3. System running 17134.5 (System upgraded from 1709 using Microsoft Update) 
    4. System running 17134.1 (System Upgraded from 1709 using WSUS - but then not offered KB4103721)

    In all cases, other patches (Office 2013, Windows MRT, etc) are offered and installed.

    As stated in other posts - 'resetting the client-side WU' has no effect. 

    In addition, using Microsoft Update does offer and install KB4103721 resulting in 17134.48 

    IMO, KB4103721 WSUS detection is broken. Microsoft needs to re-issue the packaged for WSUS.

    Until then, we're going to hold off on any deployment of 17134.x since we want to make sure it gets security updates and deploying them manually is far from ideal.

    mercoledì 9 maggio 2018 19:29
  • The 1703 and 1607 2018-05 Cumulative Updates for Windows 10 and have been re-released.

    Re-sync your WSUS catalogues.  This may fix the problem.  
    giovedì 10 maggio 2018 00:03
  • Saw that this afternoon, but waiting for 1709 to be re-released...
    giovedì 10 maggio 2018 00:05
  • I can confirm that this has fixed the issue.  Systems are now checking in normally.
    giovedì 10 maggio 2018 00:14
  • I can confirm that this has fixed the issue.  Systems are now checking in normally.

    Let's hope that they re-release the updates for Build 1803 soon as well. 
    giovedì 10 maggio 2018 00:23
  • Same issue, waiting now for re-release of CU 2018-05 1803.

    New revision of CU 2018-05 1703 and CU 2018-05 1607 is visible in our WSUS.

    Our company Win10s PCs/NTBs have 1803 version already, no older builds.

    Download directly from WU is detecting and downloading without issues.

    giovedì 10 maggio 2018 04:26
  • here in Italy my 1709 X64 clients can not see the KB4103727 and the KB4103729 updates.

    I tried to import them manually into WSUS but nothing!

    Any other suggestions? 

    giovedì 10 maggio 2018 10:24
  • You may just have to wait a bit longer.  It could take time for MS to push the changes to the servers you are trying to pull from.  Importing the patches will not help... 
    giovedì 10 maggio 2018 11:29
  • Mine finally appeared for approval this morning.
    giovedì 10 maggio 2018 11:51
  • Looks like they might have resolved this issue. I came in to work this morning and the updates show as needed on the machines that should need them; and they have installed already on several.
    giovedì 10 maggio 2018 13:26
  • Those saying it's spontaneously fixed this morning. . . for which Windows 10 client build version?

    I have not yet seen an updated download to WSUS for KB4103721 (for build 1803) as of this morning so I suspect Build 1803 clients remain out of luck.

    -B

    P.S.  I used group policy to temporarily point all Win10 clients back to the MS Update servers.  So I won't know if they begin detecting the update from WSUS until I undo the work-around.  Hence the question. . . is it time to undo the work-around?  ;)

    giovedì 10 maggio 2018 15:15
  • In WSUS this morning I had to approve 2018-05 Security Update for Adobe Flash Player for Windows 10 Version 1803 for x64-based Systems (KB103729) and 2018-05 Cumulative Update for Windows 10 Version 1803 for x64-based Systems (KB4103721)
    giovedì 10 maggio 2018 15:24
  • Looks like they might have resolved this issue. I came in to work this morning and the updates show as needed on the machines that should need them; and they have installed already on several.

    Maybe I was premature on that. I have one WSUS where it appears resolved but another one at a different location where there is still some issue. On that one, the 4103721 shows as needed, approved and ready, but running WU at the client doesn't find it. This might resolve itself over time, who knows?
    giovedì 10 maggio 2018 15:40
  • In WSUS this morning I had to approve 2018-05 Security Update for Adobe Flash Player for Windows 10 Version 1803 for x64-based Systems (KB103729) and 2018-05 Cumulative Update for Windows 10 Version 1803 for x64-based Systems (KB4103721)

    Thank you for the additional details.  It made me curious enough to re-point my Win10 workstations (all 1803) to our WSUS server.  And I can now verify your findings.  Having tested a client that had already downloaded KB4103721 from Microsoft, it now reported to the WSUS server that the update is installed, and it trigged the need to the approve the Flash Player update (KB103729). . . which had not been installed directly from MS since this particular machine had been turned off over the last day or so.

    So, this does indeed appear to be getting sorted out.  It's intriguing though that no updated packages for the 1803 build of Windows 10 have been downloaded by the WSUS server.  I wonder by what mechanism this is being fixed. . . ?

    giovedì 10 maggio 2018 16:33
  • I believe it's fixed for 1607 1703.  1709 is definitely not fixed yet (hopefully soon) and I can't speak for 1803 since we don't have any clients on that build yet. 
    giovedì 10 maggio 2018 16:38
  • It is possible that the 1803's I'm seeing that installed the CU, did so thru the Dynamic update mechanism while they were installing the upgrade and are now showing as "installed" for the normal CU. To be honest, I haven't investigated it that deeply as I expect it will all sort itself out soon anyway.
    giovedì 10 maggio 2018 17:03
  • identical problem 1607,1703 now OK
    but 1803 was not corrected

    microsoft really needs to test these updates and WSUS deployment system correctly.
    it's really not good work.
    giovedì 10 maggio 2018 23:51
  • 99% of our 1803 Win10s took update already from WSUS during this night, 1% still not yet. Keep checking

    EDIT: All our PCs and NTBs which were online received CU already from WSUS without any problem. Will continue with offline pieces but I do not foresee any further issues. And CU 05-2018 1803 was not revised in my WSUS over the night.

    • Modificato eMKei venerdì 11 maggio 2018 03:20 additional stuff
    venerdì 11 maggio 2018 03:11
  • nothing has changed this morning for me.

    my PCs with version 1709 do not see updates as needed (KB4103727 and the KB4103729) although they are approved.

    venerdì 11 maggio 2018 07:41
  • I Confirm.

    1803 ist still not corrected.

    venerdì 11 maggio 2018 08:30
  • nothing has changed this morning for me.

    my PCs with version 1709 do not see updates as needed (KB4103727 and the KB4103729) although they are approved.

    Same for me on 1709 and WSUS 2012

    Please fix this MS

    venerdì 11 maggio 2018 12:07
  • Can anyone confirm that 1709 is still having issues?  
    venerdì 11 maggio 2018 13:48
  • I'm still having issues with both 1709 and 1803.  (I received revised updates for 1607 and 1703 Thursday, but nothing new for 1709 or 1803 as of the WSUS sync at 16:00UTC Friday)

    Edit:

    I've discovered that 1709 machines that now try to run an update scan for the first time since the patch was release DO detect KB4103727 as Required and are able to install the update.  However, once they've installed the update, they now show it as "Not Required" rather than "Installed".

    venerdì 11 maggio 2018 16:46
  • KB4103721 Update for 1803 is still not offered.

    I now stopped the 1803 Deployment into our company.

    lunedì 14 maggio 2018 08:27
  • i can confirm that i still having the issue with 1709 and with the 1803 may update.

    1803 receives only flash update.

    lunedì 14 maggio 2018 09:51
  • i can confirm that i still having the issue with 1709 and with the 1803 may update.

    1803 receives only flash update.

    I can confirm KB4103727 is not offered for Windows 10 - 1709 Clients.
    lunedì 14 maggio 2018 12:00
  • Our clients (1703, 1709) don´t receive any update from WSUS, even no flash player update.
    martedì 15 maggio 2018 06:07
  • Same problem here, the update KB4103721 is not listed as required in SCCM although we do have unpatched Windows Clients on 1803...
    martedì 15 maggio 2018 09:18
  • Via WSUS - although shown as approved and needed - Windows 10 1709 Clients (Build 16299.402 with https://support.microsoft.com/en-us/help/4093105) still don't receive May 8, 2018—KB4103727 (OS Build 16299.431) https://support.microsoft.com/en-us/help/4103727 .
    martedì 15 maggio 2018 10:39
  • Similar here, some of our Windows 10 1803 17134.1 clients don't recognize the offered KB4103721 which elevates Windows to build 17134.48. However some others do. Very weird and time consuming. WSUS was intended to automate and save time for patch management. Since weeks we are struggling with non reporting, non updating Windows 10 clients and waste expensive time for trying to solve this awkward partnership.
    martedì 15 maggio 2018 11:41
  • maybe it is not too bad that this update won't install:

    "Microsoft has added within the kb article for update KB4013721 a known issue. There is a warning, that an upgrade to systems with Intel SSDs may causing issues:

    When attempting to upgrade to the Window 10 April 2018 Update, select devices with Intel SSD 600p Series or Intel SSD Pro 6000p Series may repeatedly enter a UEFI screen after restart or stop working.

    Microsoft is working with OEM partners on a fix and has suspended the feature update to Windows 10 April Update on these machines."

    from https://support.microsoft.com/en-us/help/4103721/windows-10-update-kb4103721


    • Proposto come risposta olivierdsm2 giovedì 17 maggio 2018 07:25
    martedì 15 maggio 2018 12:54
  • This is what i am thinking as well. But an official information from Mirosoft would be nice...

    The Update has the same revision Number since 08/05.Rev 200 

    mercoledì 16 maggio 2018 06:53
  • OK, Thanks York Krueger for the Information.

    I looked at our Notebooks SSD and we have toshiba SSD's. It seems that there are problem too with this brand :

    "After upgrading to the Window 10 April 2018 Update, select devices with Toshiba XG4 Series, Toshiba XG5 Series, or Toshiba BG3 Series SSDs may exhibit lower battery life."

    They didn't mentioned that the KB was suspended for this hardware, but i suppose it is the case.

    I'll will notify when a Revision for 1803 comes...

    giovedì 17 maggio 2018 07:25
  • In my case KB4103721 also wasn't offered by WSUS but after few hours Microsoft reissue update. I must resync WSUS, download and reapply this CU again. Now 1803 clients see this update but when they try download and install fix from WSUS an error 0x80242006 occuring. Remedy for this issue is to install KB4103721 manually or stop wuauserv service, rename/delete SoftwareDistribution catalog and start service again. After this operation clients start dowanloading and installing update correctly. But what admin has to do, when he has over 500 worksation over head?
    giovedì 17 maggio 2018 12:01
  • I can confirm KB4103727 is not offered for Windows 10 - 1709 Clients.

    This remains ongoing for me.

    My WSUS server does auto sync 4 times daily - and still NONE of of my 1709 clients have been offered either KB4103727 (Cumulative) OR KB4103729 (Adobe Flash)

    B

    giovedì 17 maggio 2018 16:19
  • In my case KB4103721 also wasn't offered by WSUS but after few hours Microsoft reissue update. I must resync WSUS, download and reapply this CU again. Now 1803 clients see this update but when they try download and install fix from WSUS an error 0x80242006 occuring. Remedy for this issue is to install KB4103721 manually or stop wuauserv service, rename/delete SoftwareDistribution catalog and start service again. After this operation clients start dowanloading and installing update correctly. But what admin has to do, when he has over 500 worksation over head?

    I am also having the same issue with 500+ machines. MS needs to offer a solution rather then deleting/renaming the softwaredistrobution folder.

    giovedì 17 maggio 2018 18:04
  • Hello,

    today Microsoft released KB4100347. It was found by our WSUS at 3.06 AM. And guess what, my Workstation (Windows 10 1803 Build 17134.48) is not finding it by WSUS. It says it detects at 8.07 AM and all is good. What the F.... is wrong Microsoft. And no, my Workstation has no Intel or Toshiba SSDs. They are all from Samsung. And yes, my Intel Core i9 7940X is in the list of effected CPUs from here

    https://support.microsoft.com/de-de/help/4100347/intel-microcode-updates-for-windows-10-version-1803-and-windows-server

    Sorry for my mode of expression.

    Sven

    venerdì 18 maggio 2018 06:28
  • We have the exact same problem. 1803 Feature Update deployed without problems. Then I have approved the CU and Flash Update. Flash installed without any problems but the CU was not detected by any of our clients.

    I have then declined the update and left it over night and re-approved this morning.

    Now it gets detected, but the download fails with: 0x80242006

    Sorry Microsoft, this is unacceptable!

    venerdì 18 maggio 2018 08:00
  • We have the exact same problem. 1803 Feature Update deployed without problems. Then I have approved the CU and Flash Update. Flash installed without any problems but the CU was not detected by any of our clients.

    I have then declined the update and left it over night and re-approved this morning.

    Now it gets detected, but the download fails with: 0x80242006

    Sorry Microsoft, this is unacceptable!

    I did some more digging. It probably wasn't the waiting time over night, because at the same time I have enabled Express-Installation-Files as well. So now when I contact a server that has Express-Installation-Files enabled, I get the error code above. When I contact a server that has the Express Files disabled, the client doesn't detect anything.


    This is just stupid.

    venerdì 18 maggio 2018 08:25
  • Yep same problem here.

    My MDT setup (s) are broken because of KB4103721 on 1803.

    The Update is detected, but the client is not able to download it and the MDT TS is stopped with different error codes like 0x80242006.

    It is not possible at all to fix this issue in a MDT. You can only fix this, after a deployment, by completly reseting the softwaredistribution folder.

    Funny story, using the official WindowsUpdate and it works like charm.

    venerdì 18 maggio 2018 12:46
  • Yep same problem here.

    My MDT setup (s) are broken because of KB4103721 on 1803.

    The Update is detected, but the client is not able to download it and the MDT TS is stopped with different error codes like 0x80242006.

    It is not possible at all to fix this issue in a MDT. You can only fix this, after a deployment, by completly reseting the softwaredistribution folder.

    Funny story, using the official WindowsUpdate and it works like charm.

    I have now also deleted the SoftwareDistribution Folder and my Test-Client now downloaded and installed the update.

    net stop wuauserv

    net stop bits

    net stop cryptsvc

    net stop lanmanworkstation

    rd /s /q c:\Windows\SoftwareDistribution


    But for me, this is not a solution!

    venerdì 18 maggio 2018 13:19
  • Upon checking this morning - I see that my 1709 clients are detecting all the updates normally. Not exactly sure what was done to WSUS but something has suddenly corrected itself.

    I have not attempted to install anything yet - so who knows if any specific update will actually download and install without some bizarre error.

    I will try to install patches to a test machine later and report back.

    B


    sabato 19 maggio 2018 13:46
  • Same problem here - 2018-05 Cumulative Update for Windows 10 Version 1803 for x64-based Systems (KB4103721) fails to install with error 0x80242006. 1709 is still fine. Office updates install on 1803 without issue.

    Deleting the SoftwareDistribution folder on one of the machines has allowed it to install, but surely that can't be the solution?

    • Modificato warden976 lunedì 21 maggio 2018 10:46
    lunedì 21 maggio 2018 10:29
  • Same problem. Using SCCM, 1803 servicing released 30.4.2018. Client does not want anything. Never patched. Client reports itself as compliant, so "everything is ok" from a SCCM perspective. Also does not want Office 2016 patches for some reason...?

    MCSE Mobility 2018. Expert on SCCM, Windows 10 and MBAM.

    martedì 22 maggio 2018 07:43
  • 1709 works like a charm :)

    MCSE Mobility 2018. Expert on SCCM, Windows 10 and MBAM.

    martedì 22 maggio 2018 08:00
  • 1709 Upgraded to 1803 via WSUS, will also install the may cu.
    martedì 22 maggio 2018 15:12
  • 1709 Upgraded to 1803 via WSUS, will also install the may cu.

    I had the same suspicion, however checking the build numbers on the PCs that SCCM reports as patched, they are not patched.

    Patched release should be: OS Build 17134.48

    Reported release on my "patched PCs": OS Build 17134.1

    Super irritating. I guess we just have to continue making guesses about whats going on here and hope that MS unf***s this by next month.

    martedì 22 maggio 2018 15:22
  • Not for me!

    1709 patches via WSUS to 1803 > not retrieving the May CU - this is reproducable!

    In the log files I find this:

    9956  11524 Agent           Bundled update 84EDCCDA-AD15-4FEB-B544-8438B71AA372.200 is missing extended metadata
    9956  11524 Agent           Bundle contains no actionable children and thus is invalid
    9956  11524 Agent           Update {EB863932-A151-446C-8884-AB5ADD176F94}.200 is not a valid bundle. Not returning it

    If you google the GUID you end up here, which is the May CU:

    https://www.catalog.update.microsoft.com/ScopedViewInline.aspx?updateid=eb863932-a151-446c-8884-ab5add176f94

    What the hell does that mean? Is missing extended metadata?!

    martedì 22 maggio 2018 16:38
  • I'm seeing this in 1803, but also it turns out seeing it with 1709 - this is an OOTB Microsoft enterprise wim...

    Office updates etc install fine.

    mercoledì 23 maggio 2018 13:32
  • Hi, we are also seeing 1803 clients (post upgrade or new 1803 deployments from the MS ISO) will not grab May CU unless you rename the SoftwareDistribution folder to .old (with the Windows Update service stopped).

    This clearly points to an issue with the CU which WSUS has downloaded. IS MS even looking into this?

    mercoledì 23 maggio 2018 14:10
  • So, In plain English, what do we have to do??? Step by Step and I am sure a link to the correct download site will make it easier.
    giovedì 24 maggio 2018 03:21
  • So, In plain English, what do we have to do??? Step by Step and I am sure a link to the correct download site will make it easier.

    Once 1803 has been installed...

    1. Stop the Windows Update service on the target machine

    2. Rename C:\Windows\SoftwareDistribution directory to C:\Windows\SoftwareDistribution.old on the target machine

    3. Start the Windows Update service on the target machine

    4. Re-run Windows Update against WSUS on the target machine

    5. If the CU update fails, reboot the target machine and try again.

    Hope this helps. However, this is NOT a fix, more a workaround. MS need to fix the CU so it will install as normal via WSUS.


    • Modificato Xe Elite giovedì 24 maggio 2018 08:23 Missing info
    giovedì 24 maggio 2018 08:21
  • WSUS downloaded a new Cumulative Update for Build 1803 last night.  Here's hoping it is detected as needed and installed!

    2018-05 Cumulative Update for Windows 10 Version 1803 for x64-based Systems (KB4100403)

    giovedì 24 maggio 2018 13:22
  • KB4100403 detects and installs correctly on all of my Windows 1803 devices.  That includes devices that were stuck on 17134.1 and the ones that I had coerced into installing KB4103721 by deleting their SoftwareDistribution folders.

    Looking Good!

    giovedì 24 maggio 2018 14:15
  • The new update KB4100403 works on machines that previously had problems with KB4103721. Thanks Microsoft, finally!
    giovedì 24 maggio 2018 14:33
  • The new updates aren't making any difference for me in with windows updating in the MDT build process still for 1709 and 1803 - at the moment I'm trying to work round it by suspending the build, stopping WU and deleting C:\Windows\SoftwareDistribution, which is not ideal. Any update on a fix?
    giovedì 24 maggio 2018 14:34
  • It works for me too.

    KB4100403 detects and installs correctly on all of my Windows 1803 devices.  That includes devices that were stuck on 17134.1.

    The problem is now solved for us.

    venerdì 25 maggio 2018 08:52
  • Meanwhile our 1803 machines detect and install the KB4103721 update without any changes to clients or WSUS. This update lead to the local build 17134.48 and is detected from WSUS also as 17134.48.

    The current update KB4100403 however raises the local build to 17134.81 while WSUS still detects the machine as 17134.48. A bit of irritating but not crucial.

    The question remains what has happened to this obscure communication between WSUS and clients which resulted in significant extra work for all of us.


    venerdì 25 maggio 2018 09:24
  • Has anyone encountered the same issue (clients not detecting with WSUS) regarding the June 2018 Cumulative update for 1803 (KB4284835) ?
    giovedì 14 giugno 2018 20:52
  • Yes except on my test bed of 13 1803 PCs and laptop, about half are getting the update via SCCM management, the other are not.

    I'm trying to figure out what the differences are between the PCs.

    BTW my 1709 updates roll out as expected, with not special efforts needed, This shit is getting old.

    venerdì 15 giugno 2018 17:15
  • Has anyone encountered the same issue (clients not detecting with WSUS) regarding the June 2018 Cumulative update for 1803 (KB4284835) ?

    We have the same problem. Clients don`t detect June cumulative update form WSUS. If we click check from MS Update then we can install 2018-06 update

    lunedì 18 giugno 2018 08:37
  • Has anyone encountered the same issue (clients not detecting with WSUS) regarding the June 2018 Cumulative update for 1803 (KB4284835) ?

    We have the same problem. Clients don`t detect June cumulative update form WSUS. If we click check from MS Update then we can install 2018-06 update

    Sorry for previous comment. Now I`ve checked Windows version with winver command and I have OS Build 17134.112. It is strange because on previous Friday I`ve just made an upgrade from 1709 to 1803 via our WSUS..

    But in installed updates I have KB4284835

    lunedì 18 giugno 2018 08:48
  • Has anyone encountered the same issue (clients not detecting with WSUS) regarding the June 2018 Cumulative update for 1803 (KB4284835) ?

    We have the same problem. Clients don`t detect June cumulative update form WSUS. If we click check from MS Update then we can install 2018-06 update

    We have the same issues. We have upgrade from 1703 to 1803 and clients wont download any software updates. 

    Does anyone know whats going on? 

    Best Regards


    lunedì 18 giugno 2018 09:13
  • 1803, march 2018 release - still never updates itself. Same enviroment, 1709 updates work like a charm.


    MCSE Mobility 2018. Expert on SCCM, Windows 10 and MBAM.

    martedì 19 giugno 2018 13:29
  • 1803 June release KB4284835 not installing. Clients download it to ccmcache folder but never install. This seems to be ongoing since April when 1803 was released with each CU released up to June. PLEASE FIX IT!
    mercoledì 20 giugno 2018 23:00
  • Interesting part is, that 1803 does update its office or other small updates, it seems the problem is only with CU.

    MCSE Mobility 2018. Expert on SCCM, Windows 10 and MBAM.

    giovedì 21 giugno 2018 05:26
  • Yep, this is now even worse than May's situation.

    Some of my 1803 clients detected the June update and installed it just fine.

    Some of my 1803 clients show as needing the June update in the WSUS console but do not recognize that the update is available at the client.

    Some of my 1803 clients neither report to the WSUS console as needing it, nor do they install the update.  Which is the worst case scenario.  They remain unprotected, and I would normally remain unaware of the situation were I not aware of how untrustworthy WSUS has become recently.

    There is no rhyme or reason to any of this.  Microsoft really needs to take WSUS reliability more seriously.  This is a fundamental security issue that could have a devastating impact on entire enterprises.  Security updates not being deployed in a timely manner, along with spotty reporting that such an issue exists. . . that's sorta a big deal.

    --Bri

    giovedì 21 giugno 2018 15:30
  • Just to say we are seeing this issue with the June CU. Most of ours downloaded and installed 1803 fine, followed by the May update, but they are refusing to see the June CU, even though WSUS says they need it.  They download and install it fine from Microsoft direct.

    I assume there isn't a time delay between when it will install one CU and another?

    Deleting the Software Distribution folder etc isn't really the correct solution for this.

    venerdì 22 giugno 2018 14:19
  • Until WSUS is shown to be a reliable means of distributing critical security patches, I've been forced to disable the group policy setting that directs our clients to WSUS. At least this is possible without having to visit each workstation. My workstations are now happily downloading and installing updates direct from MS. . . but it would sure be nice to be able to trust WSUS again and have the management and reporting capabilities back.

    (I suppose it's possible to have the workstations still report to WSUS even if they download directly from MS. . . but at this point, I'm in "keep it simple" mode).

    --Bri

    venerdì 22 giugno 2018 15:30
  • Yes, there are still problems,

    • a very small number of 2016 Servers take to an hour or sometimes longer to update
    • new MDT 1803 clients will detect, but not successfully update to may/june CU
    • 1709->1803 upgraded clients will also, but not successfully update to may/june CU

    Fix is to still reset the local wsus client or update from Microsoft Online Update.

    domenica 24 giugno 2018 16:33
  • Just thinking, has anyone opened a MS case about this? I hope they are aware of it. Because, month after month.. nothing happends. Also, there is no solution to this problem, so I think that purposed answer should be unmarked.

    MCSE Mobility 2018. Expert on SCCM, Windows 10 and MBAM.

    domenica 24 giugno 2018 21:29
  • KB4338853 was released this morning.  Description says:  "This update makes stability improvements for the Windows 10, version 1803 servicing stack."

    Dare we hope that this might address these issues with cumulative updates?

    Edit:  There's also a new cumulative update for Win10 1803 (KB4284848)

    There's an "important" note on the KB4284848 page:  If you're going to install both of these, install the servicing stack update (KB4338853) first!

    • Modificato BriReyEDU martedì 26 giugno 2018 21:28
    martedì 26 giugno 2018 20:57
  • No change for me, WSUS Win10 install and update are still broken.
    mercoledì 27 giugno 2018 10:53
  • Gentlemen! I have 3 ideas...

    1. Download latest 1803 .iso from msd or vlcs with april or may update integrated. Will that resolve the problem?
    2. With WSUS or SCCM, pull latest CU from Microsoft Catalog (import updates function in WSUS) and see, if that update become required
    3. SCCM just released new hotfix in its concole. It suppose to help with express updates, but might fix this issue too.

    I didn´t try any above, just throwing ideas at you asap :)


    MCSE Mobility 2018. Expert on SCCM, Windows 10 and MBAM.

    • Proposto come risposta yannara mercoledì 27 giugno 2018 10:55
    mercoledì 27 giugno 2018 10:53
  • Installed the Servicing stack update (KB4338853) and Approved the new Cumulative KB4284848 for installation in SCCM.  Once I did that my 1803 clients started detecting and installing Cumulative update KB4284848.
    • Modificato nlamonski mercoledì 27 giugno 2018 13:15
    • Proposto come risposta yannara giovedì 28 giugno 2018 10:08
    mercoledì 27 giugno 2018 13:03
  • Installed KB4339794 on SCCM 1802, and after that I saw first time the 1802 machine pulling the CU.

    MCSE Mobility 2018. Expert on SCCM, Windows 10 and MBAM.

    • Proposto come risposta yannara giovedì 28 giugno 2018 10:08
    giovedì 28 giugno 2018 10:00
  • I've checked this on one of our PCs and it is now downloading the June CU from WSUS now.  I did have to manually import KB4284848 into WSUS though as it wasn't there automatically. 
    giovedì 28 giugno 2018 15:44
  • i have same problem, but my WSUS server can't get update feature update to win 10 1803.can anyone help me?
    • Modificato ha iz sabato 30 giugno 2018 03:06
    sabato 30 giugno 2018 03:05
  • Just thinking, has anyone opened a MS case about this? I hope they are aware of it. Because, month after month.. nothing happends. Also, there is no solution to this problem, so I think that purposed answer should be unmarked.

    MCSE Mobility 2018. Expert on SCCM, Windows 10 and MBAM.

    I just did, enough is enough I'd like a REPEATABLE resolution or notification that this is indeed a know bug.

    Will post up as I find out more

    lunedì 2 luglio 2018 20:07
  • After about 45 minutes of discovery, the tech ran these commands at the client, then my updates started showing up on a freshly imaged 1803 PC that would not get updates via SCCM. The magic incantations were:

    net stop wuauserv
    net stop bits
    net stop cryptsvc

    rename "C:\Windows\SoftwareDistribution" "C:\Windows\SoftwareDistribution.old"

    net start wuauserv
    net start bits
    net start cryptsvc

    Then From the client actions run (them all, I do what the heck you're there right?):

    Machine Policy Retrieval & Evaluation Cycle

    Software Updates Scan Cycle

    Viola! The latest updates showed up and installed as expected.

    I asked if this was a bug, he said no this is normal and happens for about 10% of deployments "all the time"  .... yeah not over here I said.

    He insisted this is not abnormal because the ending dates for my deployments were causing a queue backup.

    I pointed out I made the 1803 update deployments exactly the way I've been making my 1709, 1703, and earlier deployments and have never once had to do this.

    He insisted this is normal and that 10% of PCs will need to do this all the time.

    So I just said thanks for your help, I will try this out on the other PCs in my test group to see if this resolves my issues. 

    If it does great I'll make a script and roll it out to all the 1803 PCs one time after the feature update.

    I still think this is a bug.

    So that's what I got for one of my 2 "free" SA support case vouchers. I hope this actually is a viable fix, and that it works for you too.

     

    martedì 3 luglio 2018 13:31
  • I updated the script so it works now lol:

    net stop wuauserv
    net stop bits
    net stop cryptsvc

    CD C:\Windows\
    REN "SoftwareDistribution" "SoftwareDistribution.old"

    net start wuauserv
    net start bits
    net start cryptsvc

    rmdir /s /q .svn "C:\Windows\SoftwareDistribution.old"

    martedì 3 luglio 2018 13:53
  • I have been seeing this same issue in my organization with 1709 and 1803 on 500+ PCs. The specific issue I'm seeing is where the PC prompts with the 80242006 error when trying to download the cumulative update(s). All other updates download and install properly but the cumulative update(s) don't and this has been happening for several months now as others have posted.

    I have opened an official ticket with Microsoft through my organization but have been spinning my wheels with support reps trying to get them to realize this is an issue between local WSUS and communication to clients. They keep wanting to say that the resolution I and others have found, clearing the SoftwareDistribution folder, is the resolution. This is and will never be the resolution because this has to be done to a base build that was built from an ISO directly from our VL site in order to get the PC to start downloading updates. This is a step that should not need to be done on a brand new PC.

    Hoping to make some progress in the coming days but other WSUS config changes I've found and made haven't helped. Ticket is still open in the mean time.

    martedì 3 luglio 2018 21:58
  • So I narrowed down what the issue is, at least within my organization but it may be the same for others. The firewalls within my organization are pretty strict for traffic outward and inward. Without looking in-depth at the logs, I've determined that was is happening when I build a PC, custom image or base installation media, the PC checks for updates during the initial OOBE phase and checks against Microsoft. This is where the builds are getting in to a "locked" state for the cumulative updates because they tried to download the update from Microsoft, my firewall blocked the traffic but the SoftwareDistribution folder made note of the fact that it tried to download the update file.

    So I built a VM off the base ISO media but without a virtual NIC. Once I got the local account and things set up I brought up the naming and binding dialog then created a vNIC for the VM. After I named, bound and restarted the VM it had the GPOs that my organization sets for WSUS and the VM was able to successfully download and install ALL current 1709 updates from my local WSUS server.

    So again, without digging in to some logs and such, the issue appears to reveal itself when going through the initial OOBE steps as the PC is first coming up and Cortana says "Now we can go check for any updates". I'm going to play around with some WSUS settings as well as GPO/registry options when building my custom image and see if I can get things back to where they were before this started happening.

    So for those that are having this same issue. I'd recommend checking your firewall settings and logs to see where things might be getting flagged by your firewall. I'm certainly not putting it past M$ to be sending out bad dynamic update patches as well. We'll see what my testing reveals.

    giovedì 5 luglio 2018 22:39
  • II just got off a 3 hour session with my support guy.

    He did the rename folder trick and got one of the 3 1803 updates to install. then he checked the logs and it said the Adobe update wasn't needed on the test pc. I knew that wasn't the case so then I ran software updates against Microsoft servers and guess what came down, the Adobe update :-/

    SO then he and his counterparts ran some SQL queries, adjusted some deployment settings to no avail, then after some mad tinkering he got the Adobe update to run via SCCM as expected.

    I told him that this is not a solution and will get back to him after this months "Update Tuesday" next week.

    Hopefully the updates just work...

    venerdì 6 luglio 2018 18:20
  • I wanted to give a quick update on my testing. It rarely ever happens but the first time through with a couple WSUS registry tweaks/hacks to my custom image is now allowing newly built PCs to effectively bypass going to Microsoft for OOB ZDP updates.

    The two registry tweaks are listed below. I'll also be updating these entries in my WSUS GPOs to prevent the same issue from happening with PCs that are upgrading to newer Windows 10 "versions".

    Hope this helps anyone wanting to lock down their image building process from reaching out to Microsoft and keep update communication within your own network.

    [HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate]

    "DoNotConnectToWindowsUpdateInternetLocations"=dword:00000001

    "DisableDualScan"=dword:00000001

    lunedì 9 luglio 2018 15:25
  • Microsoft is releasing bad catalogs - This happened to us in Aug - 30 Aug to be exact right after a catalog sync none of our new builds was getting July or Aug updates (the base WIM was updated through June).  Having read related threads on this forum and reddit we decided to let MS release a corrected catalog and check back after the long weekend.  Came back to work on Tuesday and the issue persisted.  Tried everything listed here in this thread and nothing resolved.  End of the day Tuesday I submit a ticket with Support.  Support starts information gathering on Wednesday (5 Sep 2018).  We get a new catalog that afternoon and a couple of hours later ALL of our newly built systems start patching - Coincidence???? I think not - We changed NOTHING and immediately following a catalog sync things start working as expected again.

    MS needs to get their act together and re-engineer Windows Update and fix the broken catalog releases!


    giovedì 6 settembre 2018 12:51