none
Windows 10 Anniversary Update (1607)

    General discussion

  • Anyone can explain why Windows 10 1607 client can't download WSUS updates ?

    WSUS is install on Windows Server 2012 R2 Server.

    When a Windows 10 client detect a Windows 10 (1607 only) update on WSUS, client can't download every update ( Windows or other)

    If there are only Office update everything works good.

    Thursday, August 11, 2016 1:39 PM

All replies

  • No answer but you're not alone in this.

    Richard P

    Friday, August 12, 2016 2:07 AM
  • same problem.

    we are using wsus with sccm on server 2012 R2.

    clients (x64) can download update like office 16, defender, security, etc...

    but can't download windows 10 1607 .

    it is already downloaded on wsus  and also approved.

    Sunday, August 14, 2016 7:16 PM
  • Have you already installed the ESD Decryption hotfix for WSUS: KB3159706?

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

    • Edited by Marc_Graham Tuesday, August 16, 2016 12:58 PM
    Tuesday, August 16, 2016 12:56 PM
  • Yes, it's the same problem.

    This update is only for ESD files.

    Tuesday, August 16, 2016 2:59 PM
  • gotcha, I misread this as I was currently working with a client on a challenge around the servicing of W10_1607 and misread.  My apologies.
    Tuesday, August 16, 2016 3:09 PM
  • This morning, I put a new registry value :

    REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization" /v DODownloadMode /t REG_DWORD /d 100 /f

    It seems to be working since.

    It turned off the new functionality of Microsoft about peer to peer update.

    Anyone else can try to validate this solution ?

    Wednesday, August 17, 2016 5:25 AM
  • Hi! I am the facing the same behaviour, tried that last registry key (it was already set like this) and it did not work.

    The scenario is:

    Client side

    Windows 10 Enterprise Version 1607

    Server side

    Windows Server 2012 R2 with WSUS role (KB3095113 + KB3159706 with manual steps after the installation)

    I just approved KB3176929 and KB3176495 for Windows 10 Version 1607 on the WSUS side and once the client tries do download them, a list of services start crashing (Windows Update, Application Information, Background Intelligent Transfer Service, Computer Browser, Delivery Optimization, IKE and AuthIP IPsec Keying Modules, IP Helper, Server, Geolocation Service, User Profile Service, System Event Notification Service, Shell Hardware Detection, Themes, User Manager, Update Orchestrator Service for Windows Update, Windows Management Instrumentation and Windows Push Notifications System Service) and Windows Update application stucks on "Downloading updates".

    Also, after that the first time I try to open an application I get an error message window that shows "The stub received bad data".

    I also tried to dump Windows Update logs using "Get-WindowsUpdateLog" but I could not find anything 'strange' (and there are a lot of GUIDs inside it).

    Any help appreciated.

    Thanks!


    Update: this issue seems to only happen if there is an update for Windows 10 version 1607 but it does not happen if there are only Office suite updates (they are installing fine).
    Wednesday, August 17, 2016 2:12 PM
  • I also noticed that Windows displays in the Windows Update Control Panel: Your phone is up to date

    Very strange this Anniversary update.

    Wednesday, August 17, 2016 4:08 PM
  • Yes, it seems that WSUS and Windows Update are thoroughly broken. Since deploying 1607 to a group of users, I've been spending a lot of my time going and manually installing the latest CU every time one comes out, so that the rest of the updates can install.

    There are a couple of feedback items I started, some upvotes might help this issue get attention. Type "thoroughly broken" in the Feedback Hub search box.


    Wednesday, August 17, 2016 4:12 PM
  • I'm facing this error on Windows Server 2008 SP2 trying to download Windows 10 Anniversary Update:

    Event ID: 364

    Source: Windows Server Update Services

    Description: Content file download failed. Reason: File cert verification failure. Source File: /d/upgr/2016/08/14393.0.160715-1616.rs1_release_clientprofessionalvl_vol_x86fre_pt-br_837a219e8e88823c99dae4bf88debcc9812da76c.esd Destination File: D:\WSUS\WsusContent\6C\837A219E8E88823C99DAE4BF88DEBCC9812DA76C.esd.

    Tried all morning to retry download and it gives me the same. All other updates downloaded just fine.


    Wednesday, August 17, 2016 4:48 PM
  • I am getting the same error as Vandrey Trindade and having the same frustration and I am running WSUS on Windows Server 2012.  Any help would be much appreciated.
    • Edited by IAGoldWing Wednesday, August 17, 2016 5:27 PM
    Wednesday, August 17, 2016 5:15 PM
  • Vandrey, pretty sure your challenge has to do with the hotfix i mentioned previously:

    Update enables ESD decryption provision in WSUS in Windows Server 2012 and Windows Server 2012 R2

    it is also referenced in this post:

    WSUS fails to download Windows 10 upgrade files

    I guess the only question is in regards to your WSUS being on a 2008 SP2 box...is that the case? 

    Wednesday, August 17, 2016 5:30 PM
  • Yes... I'm also thinking about that... =/

    Yes, our WSUS runs under Windows Server 2008 SP2. Read on a Microsoft post that I won't be able to deploy Windows 10 Feature Upgrades on WSUS 3.0 SP2 or WSUS 4.0 not patched... Well, I'm updating my machine using the Windows10Upgrade28084.exe file and will try to catch the files downloaded to avoid wasting the download time again on other machines...

    This will be only one more thing to tell my boss so she can finally buy Windows Server 2012 R2 for me...

    Wednesday, August 17, 2016 5:39 PM
  • We had the same issues here but had already installed all the patches and WSUS is running on Server 2012 R2.

    Our clients were stuck downloading the 1607 update at 0%

    After a bit of searching I found that the .esd MIME type was missing from IIS. Do the following:

    under IIS Admin->WSUS Administration->Content-> Click on "Mime Types"-> Add

    File Mame Extention:  = .esd

    MIME type:     application/octet-stream

    This had all my clients downloading the update after a restart :)

    Thursday, August 18, 2016 7:25 AM
  • Great! Worked for me (I was missing the ESD MIME type).

    I suspected I had an IIS problem (I'm using the HTTP protocol, so no SSL) when the client logs showed no error (WSUS server showed an error event that clients are reporting errors for this particular update), I would manually enter the URL for a TXT file from the update into Firefox and it would come up, but the ESD file would do nothing. 

    Thursday, August 18, 2016 8:06 AM
  • I have already esd mime type and it doesn't work.

    As I know, Cumulative update is not esd file.

    Thursday, August 18, 2016 8:10 AM
  • Hi! The .ESD MIME type did not work for me :( (it was missing) but I am applying the cumulative, not the ESD one.

    Thursday, August 18, 2016 9:55 AM
  • I can confirm I have the problem also. The ESD would update, but now stuck at downloading "Cumulative Update for Windows 10 Version 1607 for x64-based Systems (KB3176495)"

    However, a reset of the client between updating to 1607 and then getting the Cumulative update helps.

    • Edited by Jason Curl Thursday, August 18, 2016 6:34 PM Gave an answer
    Thursday, August 18, 2016 2:06 PM
  • Installed the KB3159706 today and performed the manual steps. Still not working.

    Running SCCM and Windows 10 Servicing. 

    Do i need to delete the patch downloaded to WSUS/SCCM and redownload? I thats the case, HOW?

    Cant find any information on how to do that.

    //Andreas

    Thursday, August 18, 2016 2:13 PM
  • Yes I'm the same...

    Deleted the contents of C:\Windows\SoftwareDistribution and restarted and the update download after a while



    There must be a better fix...
    • Edited by Synastra Thursday, August 18, 2016 2:19 PM
    Thursday, August 18, 2016 2:18 PM
  • It's only when client detect a Windows cumulative update for Windows 10 1607.

    If you used DISM to install update manually, all others updates will download without problem.

    It seems to Microsoft is not aware about this problem !

    Thursday, August 18, 2016 6:25 PM
  • Maybe if all users who have the problem could add his vote !
    Thursday, August 18, 2016 6:26 PM
  • I also added the .MSU MIME type to get things working again
    Friday, August 19, 2016 1:46 PM
  • Try on a fresh install of Windows Server 2012 R2 and WSUS role, it's the same problem.

    Sunday, August 21, 2016 2:57 PM
  • KB3176934 and KB3176936 availables for Windows 10 1607.

    Maybe the fix !!?

    Tuesday, August 23, 2016 7:02 PM
  • KB3176934 and KB3176936 availables for Windows 10 1607.

    Maybe the fix !!?

    We will have to wait and see until the next CU.

    I have the exact same problem, systems that succesfully upgraded to 1607 using the new upgrade mechanism in WSUS now fail to get past 0% for any CU. Even though the actual files ARE downloaded into the softwaredistribution folder. I have this on all systems that have been upgraded this way. Indeed running something like windows update mini tool will download from the Microsoft servers but not from Wsus, which in my view points to a wsus problem. Any other updates seem to be working fine by the way

    Adding the MSU mine type as suggested doesn't work for me by the way.

    Oh and to add, I am sick and tired off this whole Windows Update charade, it's time they re-engineer the whole process as it quite clearly not works correctly. Every dam patch tuesday there are problems, mostly client problems. I don't get it, all it has to do is compare applicable updates, downloads them, installs them and report back. The reporting back can take up to 20 minutes, beats me why, clear evidence of a system that is overly convoluted and error prone.

    Last edit, one of my 1607 system hadn't yet started downloading from Wsus, so I was able to search for updates using Microsoft's own servers, and that system was able to get the CU updates, so I think this is a Wsus issue not a client issue.


    • Edited by sjaak327 Tuesday, August 23, 2016 10:10 PM
    Tuesday, August 23, 2016 9:47 PM
  • Same issue as everyone else.  Stuck downloading.  If you try/reboot/troubleshoot to clean settings, some machines manage to get the updates.  More often than not, stuck..

    Question for everyone.  how do you point your machines to the WSUS server.  Policy or registry setting?

    I am using a simple registry setting as not all machines are in the domain.  just want to make sure this is not part of the issue and see if there is a pattern.

    WSUS was working flawlessly for years until the botched WSUS update, and now this Anniversary update.

    Wednesday, August 24, 2016 4:51 AM
  • I use Policy to set WSUS settings.

    But the problem appears for the both solution.

    What surprise me, it's that Microsoft doesn't see this problem with a default WSUS Server installation and clean install of Windows 10 1607.

    This isn't a particular environment problem.

    Wednesday, August 24, 2016 5:09 AM
  • I use Policy to set WSUS settings.

    But the problem appears for the both solution.

    What surprise me, it's that Microsoft doesn't see this problem with a default WSUS Server installation and clean install of Windows 10 1607.

    This isn't a particular environment problem.

    Me too GPO.

    So are you saying that a clean wsus install (without the upgrade "esd" stuff) this problem doesn't occur, because I will then simply revert the whole services model until they resolve the issues.

    I will do some testing today at work, where I did enable the KB to offer this new upgrade stuff (you kind of had to see below), but have not yet selected the category for syncing. I have several 1607 systems already there, but don't think those have the same problem.

    I personally was pissed by the way they handled the KB whatever to enable this whole thing. It was listed as a normal update under windows update and botched the whole wsus server. I know, after manually doing the steps it would work again, but the point here is that this update should never have been delivered like this, it should have been a hotfix not an automated update. It botched the wsus server home and the wsus server that serves sccm at work..


    • Edited by sjaak327 Wednesday, August 24, 2016 7:12 AM
    Wednesday, August 24, 2016 7:07 AM
  • No, even with a clean install, the problem occur.

    I tried to install a new WSUS Server 2012 R2 to be sure there isn't a problem with my current WSUS.

    Wednesday, August 24, 2016 7:12 AM
  • No, even with a clean install, the problem occur.

    I tried to install a new WSUS Server 2012 R2 to be sure there isn't a problem with my current WSUS.

    Ok thanks, that will save me the trouble. Does anyone know if this also applies to Sccm ? I guess it will.

    Oh and did you apply the "esd" KB on that clean install  ?

    • Edited by sjaak327 Wednesday, August 24, 2016 7:20 AM
    Wednesday, August 24, 2016 7:20 AM
  • No because for me, Cumulative update is different than an upgrade.
    Wednesday, August 24, 2016 7:54 AM
  • No because for me, Cumulative update is different than an upgrade.

    Ok that's bad real bad.

    I think I will create a lab and open up a support case, this is a problem that needs resolving.

    I find it odd that those systems do work when using regular Microsoft update.

    Edit: I am running on a vm, and I see the exact same sympthoms as described by Jose Antonio Campillo

    A bunch of services are stopping, wuauserv is one of the them, it stopped two times, and when I manually restarted it, it stays but download does not progress.

    0xc0000409 is the exception code for wuauserv

    Later on some other processes also seem to quit, this is pretty bad.

    Beats me why this only happens when checked against a wsus server, not when you check for updates from Microsoft.

    Edit:

    Those services keep on failing after some time. It's really strange, allthough it seems to be stuck on downloading the updates do actually download:

    reportingevents:

    872111B2-CF3D-47F4-AF3F-66EE4C8FCF86} 2016-08-24 10:01:43:260+0200 1 162 [AGENT_DOWNLOAD_SUCCEEDED] 101 {0EC99EE9-2819-4B40-B74D-08BC453FB37A} 200 0 UpdateOrchestrator Success Content Download Download succeeded.
    {0DF433AE-04B7-458D-8DD2-1C35BC97366B} 2016-08-24 10:02:10:961+0200 1 162 [AGENT_DOWNLOAD_SUCCEEDED] 101 {54496A25-D94B-4A92-A5CB-623AA204ED4A} 202 0 UpdateOrchestrator Success Content Download Download succeeded.

    The first time the wuauserv failed was at 10:00:32, it restarted the service and managed to download the two applicable updates from the wsus server, but then at 10:02:32 it crashed again. It's now 10:23 nd the services (and other services) have been crashing for 5 times already.


    • Edited by sjaak327 Wednesday, August 24, 2016 8:25 AM
    Wednesday, August 24, 2016 7:58 AM
  • Hi!

    Yes, same here.
    Exactly the same problems, if I delete SoftwareDistribution and check online updates will download and install normally, but with WSUS they got stuck.

    This started to happen with 1607 update and I had problems with FIRST CU for it, I downloaded it via MS update on all of my machines.

    I have set delivery optimization from LAN to group and then to HTTP and even to bypass and same thing occured.

    The only way I could solve it is to redirect all clients to MS update location and ditch WSUS completeley.

    Shame...

    Wednesday, August 24, 2016 8:54 AM
  • Hi to all!

    None of those fresh KBs (KB3176934 and KB3176936) fix that issue with WSUS :(

    Regards

    Wednesday, August 24, 2016 10:40 AM
  • same behaviour at our site. WSUS 2012r2 VM (only installed it a few weeks ago as was running SCE2010 on a w2k8r2 box) its has the ESD fix as WSUS doesn't start properly without it. Have just taken delivery of 30 new boxes and am updating them to 1607, they came with 1511, I'm doing this as a fresh install using the media creation tool, NOT via WSUS as its quicker just to do a fresh install from a USB key.  Thought I was going mad as updates just display downloading 0%.  Windows update is a total mess in Windows 10, pre 10 was FAR better, lots more info client side which helped with troubleshooting, the ability to select what update you wanted to install from the client was also handy.  I've rolled out half of the new PC's and am going to stop until this is fixed, we've only got around 25 1607 boxes currently the other 220 are all win7.  So I can manually install fixes if needed for a while.

    Has anyone tried w2k16TP5 with WSUS and 1607?  If you've got a small estate it might be quicker just to install a w2k16 box when its released in a few weeks and migrate over to using that, that's what I'm considering.

    Wednesday, August 24, 2016 2:15 PM
  • I've also tried toggling the WUDO settings via GPO.  Previously it was set to HTTP only and I had sporadic success on some clients, downloading and installing updates. Others I had no joy.  After setting to Bypass, I still have no joy on the problematic clients.

    After installing the latest CU (KB3176934) manually via an offline package on one machine, I still cannot install KB3176936.

    Windows Update Services keep turning off.  Seeing weird errors in Event Logs.

    Microsoft needs to fire the "Good Idea Fairy" that developed the WU scheme used for Windows 10.  It is terrible, obviously half-baked.  We never had issues like this installing updates from WSUS prior to Windows 10.  The issue isn't the craptastic KB3159706 on the WSUS servers in question, that is a red herring.  The problem is the new Update schema.  Someone has obviously taken something for granted, or seriously overlooked something.  It could be as simple as, 1) Pay good money for good coders, 2.) Actual code review, 3.) Testing, 4.) Firing the Good Idea Fairy

    Is anyone from MS listening?  When are we going to get a fix for this?

    Wednesday, August 24, 2016 4:06 PM
  • totally agree with you, Windows 10 windows update really is a big step backwards especially for IT Pros, even down to having to mess with powershell just to be able to read the bleedy windowsupdate log file, that previously was plain txt.  WHO THOUGHT THAT WAS A GOOD IDEA!
    Wednesday, August 24, 2016 6:39 PM
  • The worst is when you have a Windows bug, you wait for an update, but here, how apply the update ?
    This is a very complicated situation
    Wednesday, August 24, 2016 6:48 PM
  • "The only way I could solve it is to redirect all clients to MS update location and ditch WSUS completely."

    That is probably what Microsoft wants. They obviously are in no big hurry to fix this.

    Wednesday, August 24, 2016 7:44 PM
  • Has anyone tried disabling TLS on the WSUS server IIS site and using HTTP on port 8530?
    Wednesday, August 24, 2016 7:49 PM
  • Yes, it's the same problem
    Wednesday, August 24, 2016 7:57 PM
  • same behaviour at our site. WSUS 2012r2 VM (only installed it a few weeks ago as was running SCE2010 on a w2k8r2 box) its has the ESD fix as WSUS doesn't start properly without it. Have just taken delivery of 30 new boxes and am updating them to 1607, they came with 1511, I'm doing this as a fresh install using the media creation tool, NOT via WSUS as its quicker just to do a fresh install from a USB key.  Thought I was going mad as updates just display downloading 0%.  Windows update is a total mess in Windows 10, pre 10 was FAR better, lots more info client side which helped with troubleshooting, the ability to select what update you wanted to install from the client was also handy.  I've rolled out half of the new PC's and am going to stop until this is fixed, we've only got around 25 1607 boxes currently the other 220 are all win7.  So I can manually install fixes if needed for a while.

    Has anyone tried w2k16TP5 with WSUS and 1607?  If you've got a small estate it might be quicker just to install a w2k16 box when its released in a few weeks and migrate over to using that, that's what I'm considering.

    I was planning on doing that, as updates from Ms are working on 1607 so I'm guessing they already use 2016 on their end.

    But.. I installed it on 1607 gen 2 and secure boot on, failed to go past secure boot after install, disabled it, still refused to boot, changed to gen 1 vm, but had other stuff to do, so will try tomorrow. I think it might indeed work on 2016.


    • Edited by sjaak327 Wednesday, August 24, 2016 9:02 PM
    Wednesday, August 24, 2016 9:02 PM
  • I see a little difference in IIS Type mime in Windows Server 2016 :

    esd file is application/vnd.ms-cab-compressed and not application/octet-stream

    ( it's the same than .cab)

    Anyone can try with old Windows Server, maybe it will fix the problem.

    I come back later to tell you if it works with Windows Server 2016.

    Thursday, August 25, 2016 10:42 AM
  • No, same problem for me with WSUS on Windows Server 2016.

    Stucks on downloading.

    Thursday, August 25, 2016 11:46 AM
  • hmmmmmm oh well that's that idea gone then!
    Thursday, August 25, 2016 1:06 PM
  • I have the same problem as well. Tried almost all the stuff you others tried but the only thing that resolved it is going to Microsoft Update instead. Annoying thing is you have to check once against the wsus in 1607 beforce the "Check online for updates" shows up, which it never does since WSUS hangs. This is a real mess! Clearing the registry or removing GPO settings and then restarting wuauserv to go to Microsoft Update instead.

    Has anyone started a supportcase and gotten some kind of response from Microsoft?

    Thursday, August 25, 2016 1:50 PM
  • I think someone said they had a case open.  Lots of people reporting the issue
    Thursday, August 25, 2016 2:18 PM
  • Don't hold your breath for a quick solution.  I've got a friend at a Fortune 500 company who's opened a case and so far he's getting nowhere with them.  He hasn't gotten past "What problem?" with them yet.

    Doesn't MS use WSUS?  Any amount of testing would have discovered this.

    Thursday, August 25, 2016 8:43 PM
  • Having the same issue after upgrading to 1607 from 1151. Tried everything mentioned in this post. We have two fully patched WSUS servers newly built and they are both having this issue.

    However I managed to get one of the test build clients updated but the other one stuck at 45%. Here's what I did

    *fresh 1607 build from ISO, joined domain and applied all GPOs as per usual

    *disabled "Updates from more than one place" feature on the client

    *enabled "Download express installation files" on the WSUS server which added 500G more updates.

    The one that's stuck at 45% is a upgrade from 1151. But it stuck at 0% before I enabled "Download express installation files" on the WSUS server. 

    I will test it a bit more and get back if I discover anything useful. 

     
    Friday, August 26, 2016 12:27 AM
  • Hi everyone, and apologies for the frustration you're experiencing.  This thread calls out several different symptoms, for each of which I'll provide guidance.  Note that Configuration Manager will exhibit the same symptoms as each of the scenarios below.

    1. WSUS 3.0 SP2 on WS08R2 SP1 (or unpatched WS12/R2) cannot download ESDs

    This is by design.  WSUS 3.2 cannot sync or distribute ESDs, and WS12/R2 can only do so if both KB3095113 and KB3159706 are installed on the machine, and all necessary post-install steps from KB3159706 have been followed.  As folks have noted, these post-install steps [and the general way that this update was released] caused unnecessary pain and confusion.  We'll choose a less disruptive strategy for future WSUS updates.

    2. Clients have upgraded to 1706 using Anniversary Update, but cannot get Cumulative Updates

    This is a bug in the Windows client that will be fixed in an upcoming cumulative update.  In the meantime, clients may experience some delay in getting the monthly content, but they will eventually download it.  The workaround here is to simply wait longer than usual, or to scan directly against Windows Update if you've waited several days and haven't seen any download success in that time.

    3. WSUS can sync/distribute feature updates (such as 1511), but cannot deploy the 1607 feature update

    This is a newly reported issue that we are currently investigating.  Again, the workaround is to pull the 1607 feature update from Windows Update instead of WSUS.  We understand why you might not want to pull such a large file from the Internet once for each of your clients, and are figuring this out as soon as we can.  We'll share further updates on the investigation as they become available.

    Friday, August 26, 2016 10:09 PM
    Moderator
  • Hello,

    I use Windows 10 Pro v1607 (german edition) for tests and Windows Server 2008 R2 with WSUS. The GPOs are from Windows Server 2008 R2/Windows 7 Pro and work with Windows 7 Pro and Windows 10 Pro v1511. Windows 10 Pro v1607 gets no Windows-Updates (Office Updates works).

    I turned off the internet for the computer on the firewall, but ping ist further posible, is this a problem for the  peer2peer logic for get the updates?

    https://blogs.technet.microsoft.com/mniehaus/2016/08/16/windows-10-delivery-optimization-and-wsus-take-2/

    https://blogs.technet.microsoft.com/mniehaus/2016/08/08/using-wsus-with-windows-10-1607/

    I set Delivery Optimization to Bypass with a local GPO. And I set a limit for BITS.

    I can see the status for my Windows 10 Pro computer in the wsus console, but the computer gets no update. "Updatestatus: Wir konnten keine Verbindung mit dem Updatedienst herstellen" (in english: We were unable to connect to the update service). No Windows Update in the WSUS-Console ask for realse the Update. I have to admin new Updates in WSUS and Updates for Windows 10 v1607 ca I found via search dialog.

    So, I installed Office 2007 Professional Plus and got the updates via WSUS. After that, I clicked on "update" and got the comunication error. No updates.

    Monday I will try install KB3176934 by hand and see what with the other update happen.

    Sorry for my english... I'm a nativ german speaker.

    cu


    • Edited by ITProFromGermany Saturday, August 27, 2016 7:45 AM Delivery Optimization to Bypass
    Saturday, August 27, 2016 7:41 AM
  • People behind a firewall only:

    If you want temporarly enable update via Windows Update, maybe you need, like me, to enable the Winhhtp proxy configuration in order to update Windows successfully:

    --> To show if there is already a proxy:

    netsh winhttp show proxy

    --> To set a proxy (without authorization: you need tu put an exception in Firewall to bypass credential)

    netsh winhttp set proxy ProxyIP:port

    Saturday, August 27, 2016 11:39 AM
  • Thanks for the update.  Just to clarify, I've been experiencing option 2... but it's not just cumulative updates that are failing, I also see "Update for Windows 10 Version 1607 for x64-based Systems (KB3176936)" fail where the client just sits at downloading (0%)...

    Also, the Windows Update service on the client crashes, I get some of the "The stub received bad data" errors when launching msc's, etc... so it's a fairly impactful bug.  Are you seeing those symptoms as well (I saw a couple people on here list those symptoms)?

    I'm on Win2016TP5, brand new install, only running WSUS on it, and my clients are fresh Windows 10 installs where the 1607 update was installed via my WSUS. 

    You mentioned that the clients will eventually download it, but if it keeps crashing the service I don't see how it's ever going to work... At this point I think I will need to unapprove the updates (I only had approved for my test group anyhow) and wait until some fixes come out. 

    The bigger question is, if it's an issue on the client side, then how will releasing a new cumulative update help, since the client will hang trying to update that as well?  Sounds like a patch might have to be manually applied (when available) before the automatic updates start working again.

    Craig

    Monday, August 29, 2016 4:37 PM
  • I'm also seeing the same symptoms as Jose Antonio Campillo, sjaak327, and xqxq. Windows 10 Pro 1607 client, WSUS on Server 2012. Windows Update finds Cumulative Update 3176394 and Update 3176936, but is stuck "Downloading updates 0%".

    And I'm also seeing numerous services terminating unexpectedly (Window Update, Windows Push Notifications System, Windows Insider, Windows Management Instrumentation, Update Orchestrator Service for Windows Update, Server, IP Helper, and a bunch of others) and the "The stub received bad data" the first time I try to run various things (e.g., mmc.exe and taskmgr.exe).

    I've tried manually downloading and installing the Cumulative 3176394, but that hasn't helped. I'll try installing 3176936 too.

    Monday, August 29, 2016 6:01 PM
  • I have an update to this....  I have been struggling with this for 3 days now.  The following is a work around to this Culms. not downloading from WSUS to 1607.

    Enable Deferred updates, but set both upgrade and update to 0. (Enabling Differed Updates will grey out the checkbox in the UI, setting the values to 0 means don't wait, install immediately.)

    Run a gpupdate /force on the client computer and restart.

    Check for updates. They will start downloading and installing just like they were supposed to.

    The one issue to this is that once the updates are installed, in WSUS they will report that they are 'not applicable' even though they are installed, cause ya know you watch'd them get installed.

    Or, you could just use Windows Updates services from the internet.

    Now we just have to sit back and wait for the 'fix' from MS.   Isn't it funny that we have to install what will probably be a culm. to get this fixed, when in fact culms. done install.   Good one MS, you are pretty funny.


    • Edited by DaBip Monday, August 29, 2016 7:07 PM
    Monday, August 29, 2016 7:05 PM
  • None of these solutions have worked for us.  In fact right now all windows 10 1607 build machines that try to download a cumulative updates from 2012 R2 WSUS hang on the download then after reboot are bricked with an error message.  At this point the machine is unusable and needs to be rebuilt.

    Yes you heard that right.  WSUS and Windows 10 1607 CUs are bricking my machines... What a disaster.  I can reproduce this consistently in our environment.  We are sticking with 1511 because we have no choice.  Those are downloading to clients properly from WSUS still.

    We have the new GPO set to bypass mode, we have the MIME types and all WSUS hotfixes installed including the post servicing steps.  We know what we are doing.  The software is just broken and MS has yet to comment on a solution.

    EDIT:  the error message that comes up on next boot after windows update tries to download a 1607 CU from WSUS is, "C:\windows\system32\config\systemprofile\desktop is unavailable.  If the location is on this PC, make sure the device or drive is connected or the disc is inserted, and then try again.  if the location is on a network make sure you're connected to the network or internente, and then try again.  If the location still can't be found, it might have been moved or deleted."   The user's taskbar, start menu are gone and many applications will not run or load.  New user profile does not fix the issue and also has the problem.  Bricked....


    • Edited by davidbwi Tuesday, August 30, 2016 11:33 AM
    Tuesday, August 30, 2016 11:30 AM
  • not seen this behaviour, we just have the hanging at 0% We only currently have around 25 1607 and I have now set the latest updates to unapproved so remaining clients don't try and download them. Total ba11s up
    Tuesday, August 30, 2016 12:13 PM
  • We also had to take the MSU ESD mime types out of IIS this morning that we put in yesterday during troubleshooting. It actually broke updates for build 1511 by putting those in.  Taking them out and restarting IIS fixed 1511.  1607 updates are still dead in the water.  Hang at 0% and then after 1 attempt at downloading and a reboot the operating system is bricked and needs to be rebuilt.  I am currently rebuilding 1607 systems back on 1511 this morning.  Thanks Microsoft.
    Tuesday, August 30, 2016 1:46 PM
  • None of these solutions have worked for us.  In fact right now all windows 10 1607 build machines that try to download a cumulative updates from 2012 R2 WSUS hang on the download then after reboot are bricked with an error message.  At this point the machine is unusable and needs to be rebuilt.

    Yes you heard that right.  WSUS and Windows 10 1607 CUs are bricking my machines... What a disaster.  I can reproduce this consistently in our environment.  We are sticking with 1511 because we have no choice.  Those are downloading to clients properly from WSUS still.

    We have the new GPO set to bypass mode, we have the MIME types and all WSUS hotfixes installed including the post servicing steps.  We know what we are doing.  The software is just broken and MS has yet to comment on a solution.

    EDIT:  the error message that comes up on next boot after windows update tries to download a 1607 CU from WSUS is, "C:\windows\system32\config\systemprofile\desktop is unavailable.  If the location is on this PC, make sure the device or drive is connected or the disc is inserted, and then try again.  if the location is on a network make sure you're connected to the network or internente, and then try again.  If the location still can't be found, it might have been moved or deleted."   The user's taskbar, start menu are gone and many applications will not run or load.  New user profile does not fix the issue and also has the problem.  Bricked....


    Now that you mention it, I did see that behavior once or twice where the profile wouldn't load.  However I was able to log out and log back in again and the profile loaded that time.  When it was happening I didn't realize I was having larger issues with WSUS yet, so I didn't associate the symptom with the Windows Updates until you mentioned it. 

    Now that I have unapproved the patches, I don't think we've had any of those issues again.  I will keep an eye out though.

    Craig

    Tuesday, August 30, 2016 4:55 PM
  • None of these solutions have worked for us.  In fact right now all windows 10 1607 build machines that try to download a cumulative updates from 2012 R2 WSUS hang on the download then after reboot are bricked with an error message.  At this point the machine is unusable and needs to be rebuilt.

    Yes you heard that right.  WSUS and Windows 10 1607 CUs are bricking my machines... What a disaster.  I can reproduce this consistently in our environment.  We are sticking with 1511 because we have no choice.  Those are downloading to clients properly from WSUS still.

    We have the new GPO set to bypass mode, we have the MIME types and all WSUS hotfixes installed including the post servicing steps.  We know what we are doing.  The software is just broken and MS has yet to comment on a solution.

    EDIT:  the error message that comes up on next boot after windows update tries to download a 1607 CU from WSUS is, "C:\windows\system32\config\systemprofile\desktop is unavailable.  If the location is on this PC, make sure the device or drive is connected or the disc is inserted, and then try again.  if the location is on a network make sure you're connected to the network or internente, and then try again.  If the location still can't be found, it might have been moved or deleted."   The user's taskbar, start menu are gone and many applications will not run or load.  New user profile does not fix the issue and also has the problem.  Bricked....


    Now that you mention it, I did see that behavior once or twice where the profile wouldn't load.  However I was able to log out and log back in again and the profile loaded that time.  When it was happening I didn't realize I was having larger issues with WSUS yet, so I didn't associate the symptom with the Windows Updates until you mentioned it. 

    Now that I have unapproved the patches, I don't think we've had any of those issues again.  I will keep an eye out though.

    Craig

    Don't dismiss it so quickly if you see it again. We found the machines were needing a rebuild.  New profiles would also experience this issue.  That is just not acceptable.
    • Edited by davidbwi Tuesday, August 30, 2016 5:31 PM
    Tuesday, August 30, 2016 5:27 PM
  • 3. WSUS can sync/distribute feature updates (such as 1511), but cannot deploy the 1607 feature update

    This is a newly reported issue that we are currently investigating.  Again, the workaround is to pull the 1607 feature update from Windows Update instead of WSUS.  We understand why you might not want to pull such a large file from the Internet once for each of your clients, and are figuring this out as soon as we can.  We'll share further updates on the investigation as they become available.

    Quick update on this one: we are unable to reproduce the upgrade to 1607 issue internally. Furthermore, anyone that has clarified their symptoms regarding their experience downloading from WSUS has [so far] revealed that their issues are happening after upgrade to 1607 has already succeeded.  If anyone has symptoms that match scenario #3, then please let us know; otherwise, we'll assume that only scenario #2 is an actual issue.

    To clarify, scenario #2 is a problem with the Windows Update client when it downloads from WSUS, and it affects all updates (not just cumulative).  Service crashes are expected when this occurs; however, because it is nondeterministic, the download should eventually succeed.  Alternatively, you can have your clients scan against Windows Update directly, or download and install directly from the Microsoft Update Catalog.  A fix is scheduled for September's Patch Tuesday (9/13).  Given the bootstrapping issue that some have mentioned, you may want to deploy the September cumulative update directly to expedite resolution.

    Tuesday, August 30, 2016 9:08 PM
    Moderator
  • @Steve, there are numerous posts and other threads where people are reporting WSUS (client) failure to detect applicability for upgrade/update to 1607.

    Are you seeing this symptom? Are you seeing this as part of issue#2 or issue#3 ?

    detection result of Not Applicable, is difficult to diagnose on Win10, since we are all used to relying upon WindowsUpdate.log from past experience. This log file is now all but useless on Win10.

    Some people have suggested that the Panther setup action & error logs can reveal why setup might be failing, but again this isn't much help if detection returns NotApplicable.

    Is there a missing pre-requisite? (don't know, have nowhere to look for that)
    Does it work if attempting via WU/MU? Yes, but can't figure out why...

    EDIT: I am not having this issue in my organisation. I am not deploying Win10 at this time. If I were deploying and if I were using WSUS to do that and if I were having this problem then I would be opening a support case.


    Don [doesn't work for MSFT, and they're probably glad about that ;]


    • Edited by DonPick Tuesday, August 30, 2016 9:45 PM
    Tuesday, August 30, 2016 9:43 PM
  • 3. WSUS can sync/distribute feature updates (such as 1511), but cannot deploy the 1607 feature update

    This is a newly reported issue that we are currently investigating.  Again, the workaround is to pull the 1607 feature update from Windows Update instead of WSUS.  We understand why you might not want to pull such a large file from the Internet once for each of your clients, and are figuring this out as soon as we can.  We'll share further updates on the investigation as they become available.

    Quick update on this one: we are unable to reproduce the upgrade to 1607 issue internally. Furthermore, anyone that has clarified their symptoms regarding their experience downloading from WSUS has [so far] revealed that their issues are happening after upgrade to 1607 has already succeeded.  If anyone has symptoms that match scenario #3, then please let us know; otherwise, we'll assume that only scenario #2 is an actual issue.

    To clarify, scenario #2 is a problem with the Windows Update client when it downloads from WSUS, and it affects all updates (not just cumulative).  Service crashes are expected when this occurs; however, because it is nondeterministic, the download should eventually succeed.  Alternatively, you can have your clients scan against Windows Update directly, or download and install directly from the Microsoft Update Catalog.  A fix is scheduled for September's Patch Tuesday (9/13).  Given the bootstrapping issue that some have mentioned, you may want to deploy the September cumulative update directly to expedite resolution.

    I definitely have the issue where by 1511 machines will not recognize that the 1607 feature update as "Not Applicable".

    Take a look at this thread where I detail the issue.

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/5293cd7e-7725-4514-9460-4461facef350/windows-10-anniversary-update-1607-not-applicable?forum=winserverwsus

    There have definitely been other people that have reported this issue on Technet forums and on spiceworks forums.


    Eric S.


    • Edited by Eric Suger Tuesday, August 30, 2016 9:59 PM Fix Grammar
    Tuesday, August 30, 2016 9:57 PM
  • 1. WSUS 3.0 SP2 on WS08R2 SP1 (or unpatched WS12/R2) cannot download ESDs

    This is by design.  WSUS 3.2 cannot sync or distribute ESDs, and WS12/R2 can only do so if both KB3095113 and KB3159706 are installed on the machine, and all necessary post-install steps from KB3159706 have been followed.  As folks have noted, these post-install steps [and the general way that this update was released] caused unnecessary pain and confusion.  We'll choose a less disruptive strategy for future WSUS updates.

    @Steve - what happens if we have followed the steps listed above and the machines are still broken?

    We have a WSUS 3.0 SP2 implementation on Server 2012 R2 and I patched it with both KB's listed above and followed the post-install steps (aside from SSL which we aren't using) and my Win 10 1607 clients are still hanging on installing updates. I'm trying to build a reference image through MDT and it hangs with it as well as regularly built clients connecting to WSUS.

    I've had to go back to 1507 for now until this issue is resolved. As it seems others are in the same boat as me it appears that you guys still have work to do to get this working. Not too happy as I've wasted a ton of hours researching and testing potential workarounds.

    Wednesday, August 31, 2016 6:36 AM
  • Same problem.

    Nothing written here  helped. Waiting for fix, thank you Microsoft...


    • Edited by Imused Wednesday, August 31, 2016 6:38 AM
    Wednesday, August 31, 2016 6:37 AM
  • If anyone has symptoms that match scenario #3, then please let us know; otherwise, we'll assume that only scenario #2 is an actual issue.

    @Steve: We've the same problem matching to #3. Take a look here:

    https://social.technet.microsoft.com/Forums/de-DE/fa75ffb7-cad9-4dc5-8aaa-656d92af7f3e/windows-10-1511-clients-fordern-upgrade-auf-1607-von-wsus-nicht-an?forum=win10itprogeneralDE


    Freundliche Grüße
    Sandro

    MCSA: Windows Server 2012 in spe ;)
    Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)

    XING: Zum Profil
    LinkedIn: Zum Profil
    Facebook: Zum Profil

    Wednesday, August 31, 2016 11:45 AM
  • 1. WSUS 3.0 SP2 on WS08R2 SP1 (or unpatched WS12/R2) cannot download ESDs

    This is by design.  WSUS 3.2 cannot sync or distribute ESDs, and WS12/R2 can only do so if both KB3095113 and KB3159706 are installed on the machine, and all necessary post-install steps from KB3159706 have been followed.  As folks have noted, these post-install steps [and the general way that this update was released] caused unnecessary pain and confusion.  We'll choose a less disruptive strategy for future WSUS updates.

    @Steve - what happens if we have followed the steps listed above and the machines are still broken?

    We have a WSUS 3.0 SP2 implementation on Server 2012 R2 and I patched it with both KB's listed above and followed the post-install steps (aside from SSL which we aren't using) and my Win 10 1607 clients are still hanging on installing updates. I'm trying to build a reference image through MDT and it hangs with it as well as regularly built clients connecting to WSUS.

    I've had to go back to 1507 for now until this issue is resolved. As it seems others are in the same boat as me it appears that you guys still have work to do to get this working. Not too happy as I've wasted a ton of hours researching and testing potential workarounds.

    Same here.  2012 R2 WSUS fully patched and updated properly can't service Windows 10 1607 clients.  From the sounds of this person's message above he says a fix will be out on September 13th.  It sounds like we will all need to install this fix in to our image that we deploy so that it can communicate with WSUS properly after deployment.  

    Wednesday, August 31, 2016 12:23 PM
  • 3. WSUS can sync/distribute feature updates (such as 1511), but cannot deploy the 1607 feature update

    This is a newly reported issue that we are currently investigating.  Again, the workaround is to pull the 1607 feature update from Windows Update instead of WSUS.  We understand why you might not want to pull such a large file from the Internet once for each of your clients, and are figuring this out as soon as we can.  We'll share further updates on the investigation as they become available.

    Quick update on this one: we are unable to reproduce the upgrade to 1607 issue internally. Furthermore, anyone that has clarified their symptoms regarding their experience downloading from WSUS has [so far] revealed that their issues are happening after upgrade to 1607 has already succeeded.  If anyone has symptoms that match scenario #3, then please let us know; otherwise, we'll assume that only scenario #2 is an actual issue.

    Hi Steve,

    My organization is currently experiencing this issue. The situation definitely exists in the wild.

    Thanks,

    Mike

    Wednesday, August 31, 2016 12:41 PM
  • I have this issue too. Have two testmachines with 1511 in a separate group in wsus with the 1607 update approved.

    The 1511 machines downloads and schedules an installation but it never happens, been waiting for it to upgrade for over a week. Got tired of waiting on one of my testmachines and chose update and restart on the "powerbutton" the upgrade finished fine. But I have discovered other issuses with network shares being inaccessible.

    Wednesday, August 31, 2016 1:27 PM
  • Mike,

    Have you installed the update described in this KB on your WSUS server?

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

    It is a prerequsite to deploy the Windows 10 Anniversary upgrade and all future upgrades.

    http://windowsitpro.com/windows-10/microsoft-finally-delivers-final-fix-wsus-kb3148812-windows-10-anniversary-requirement

    "Skipping this KB means not being able to distribute the Windows 10 Anniversary Update, or any subsequent feature update, via these platforms.  Note that Windows Server 2016 will have this functionality at RTM."


    • Edited by netadmin03 Wednesday, August 31, 2016 1:38 PM
    Wednesday, August 31, 2016 1:37 PM
  • Yes. I have followed all the steps set forth by everyone in this forum to install the two prerequisite updates from KB3095113 and KB3159706 and followed the necessary post installation steps. I am in exactly the same situation as other administrators that followed the same steps and still come up short.
    Wednesday, August 31, 2016 3:23 PM

  • 2. Clients have upgraded to 1706 using Anniversary Update, but cannot get Cumulative Updates

    This is a bug in the Windows client that will be fixed in an upcoming cumulative update.  In the meantime, clients may experience some delay in getting the monthly content, but they will eventually download it.  The workaround here is to simply wait longer than usual, or to scan directly against Windows Update if you've waited several days and haven't seen any download success in that time.


    This is not the case.  When our windows 10 1607 systems attempt to download a cumulative update the update does not download or gets stuck.  However on next boot the user gets this error when any user logs in and the profile is broken. We basically have to reimage the machine.  If we point the same exact image to windows update and bypass wsus they download fine and this error never appears and we never have to reimage.  We have reproduced this in our lab consistently.

    There is a bigger issue here as well and it is causing impact to 1607 systems.  All of our 1511 clients are downloading CU's just fine and we can even upgrade 1511 to 1607 with WSUS but after that the client is toast with the user profile issue after attempting to download a 1607 CU....

    EDIT:  the error message that comes up on next boot after windows update tries to download a 1607 CU from WSUS is, "C:\windows\system32\config\systemprofile\desktop is unavailable.  If the location is on this PC, make sure the device or drive is connected or the disc is inserted, and then try again.  if the location is on a network make sure you're connected to the network or internente, and then try again.  If the location still can't be found, it might have been moved or deleted."   The user's taskbar, start menu are gone and many applications will not run or load.  New user profile does not fix the issue and also has the problem.  Bricked....


    • Edited by davidbwi Wednesday, August 31, 2016 4:40 PM
    Wednesday, August 31, 2016 4:38 PM
  • Encountering issue #3 in our environment. We have done the steps in KB3095113 and KB3159706. I have performed a wsutil /reset. I have rebooted, swore at it, and nothing. Our server is a 2012 server all other updates are downloading fine.
    Wednesday, August 31, 2016 4:59 PM
  • CU for Win 7 V 1607 KB3176938 (v2) was re-released to WSUS today.

    No word as to whether it fixes the Windows Update issue... yet.

    Wednesday, August 31, 2016 5:24 PM
  • Mike and RWood,

    Sorry to hear you're still unable to deploy 1607 after patching. Maybe your issue is something specific in your environment?

    WSUS running on Server 2012 R2 here.

    For the record, I can deploy 1511 via WSUS after installing KB3095113. I can also deploy 1607 after installing KB3159706 and following the necessary post installation steps.

    I guess I'm one of the lucky ones. *ducks*

    Encountering issue #2 here. Cumulative updates will not deploy to our Windows 10 clients after upgrading to 1607.

    Wednesday, August 31, 2016 5:49 PM
  • Mike and RWood

    Did you approve and download the 1607 upgrade before or after installing KB3159706?

    I installed KB3159706 then approved and downloaded the 1607 upgrade. 

    Wednesday, August 31, 2016 5:54 PM
  • I approved it before and after installing KB3159706. I approved it before I installed KB3159706 then rebuilt my WSUS server from scratch. Then I installed KB3159706 then approved 1607.
    Wednesday, August 31, 2016 6:24 PM
  • I approved after.

    Wednesday, August 31, 2016 6:50 PM
  • @Steve

    about:
    "2. Clients have upgraded to 1706 using Anniversary Update, but cannot get Cumulative Updates
    This is a bug in the Windows client that will be fixed in an upcoming cumulative update"

    Is there any shedule when this patch should be available and will MS release a new Enterprise ISO which includes this patch than aready (cause also fresh installations are affected by this issue) ?



    Wednesday, August 31, 2016 6:53 PM
  • My 1511 Windows Enterprise clients can't install the 1607 feature update from WSUS running on Windows Server 2012R2. That is #3, right?

    EDIT: and yes, we have applied https://support.microsoft.com/en-us/kb/3159706 with the post-update tasks, and added .esd and .wsu to the mime types, but still the same error.

    • Edited by Bret Miller Wednesday, August 31, 2016 10:05 PM
    Wednesday, August 31, 2016 10:03 PM
  • Hi Steve, you state it's scheduled for 13/09, so the CU released today KB3176938 doesn't fix the problem? Could you when the fix is released please provide the link and update this thread. Thanks.

    PS. Could you please personally hit some heads together over there, these kind of issues just aren't acceptable, we're enterprise customers and we have to put up with such rubbish from MS when it comes to broken updates. Not good enough!

    Wednesday, August 31, 2016 10:42 PM
  • Hey Guys,

    I was also having this issue with MDT + WSUS, stuck downloading updates.. previously had KB3176929 injected to get around the issue.. but a week or two later.. same issue.. sits there never downloading:

    Today have imported the KB3176938 package..

    Now seems to be downloading:

    Task Sequence is proceeding past the Windows update stage.. all looks good... I'll let you know if it fails the post windows update task. I know its using a task sequence but this update seems to fix something :)

    PS. I hate updates.


    • Edited by iluciv Wednesday, August 31, 2016 11:55 PM
    Wednesday, August 31, 2016 11:15 PM
  • I'll patiently await for updates to flow through, although I'm not confident that somehow they will unless a patch for WSUS Server is released.

    In the meantime I have set all our clients to get updates from Microsoft directly via GPO.

    Computer Config > Admin Templates > Windows Components > Windows Updates > Specify intranet Microsoft update service location > Disabled.

    Once I have all clients updated, I'll set it back to WSUS and see what happens with Patch Tuesday updates.

    Thursday, September 1, 2016 5:34 AM
  • We are currently experiencing the issue where 1607 is stuck at 0 % on downloading cumulative updates. Plus we also had the first issue listed when upgrading our machines from the orignal win 10 to 1511 ....

    If you are having an issue with the 1607 FEATURE update for 1511 via WSUS we had this issue and we resolved it by

    * changing the WSUS server location in the GPO to the servers domain.local address from a wsus.ourwebdomain.co.uk (dns resolves it back to its private 10.x.x.x)

    * Clearing the "Host Name" from both the http and https port bindings in IIS.

    Also, make sure you SSL cert is valid by browsing to your WSUS server in IE,Edge, FF, Zeus and checking their are no errors reported with the cert.

    Thursday, September 1, 2016 7:24 AM
  • Hi Steve,

    We are experiencing issue 3 in our environment. Our 1511 clients are stuck at 0% downloading the 1607 update. All necessary KB's and post install steps were followed prior to the sync of 1607 to the WSUS server.

    Thanks.


    BradG87

    Thursday, September 1, 2016 12:48 PM
  • After installing  KB3176938  (via WU), I again have the 'Check online for updates from Microsoft Update' link back, which did not appear before this update was installed.

    I am interested to see if updates via WSUS are working again now. In that case the question remains how this update can be distributed to computers that are only looking at WSUS, and are all stuck at 0%...


    • Edited by xanderg Thursday, September 1, 2016 2:07 PM
    Thursday, September 1, 2016 2:07 PM
  • Someone else in a different forum / thread figured out the issue with #3.

    --------------------------------

    In my case, problem was in  group policy setting: Windows components - Store - Turn off the offer to update to the latest version of Windows.

    Proposed as answer by Anne He Microsoft contingent staff, Moderator 5 hours 30 minutes ago

    ---------------------------------


    Eric S.

    Thursday, September 1, 2016 2:47 PM
  • I checked this and made sure it was not configured or enabled and we don't have it set to ignore the latest version of Windows. I'm glad it is working for some people but it is not the case in my environment.
    Thursday, September 1, 2016 2:53 PM
  • No dice here either. Would be nice if it were the fix for us.
    Thursday, September 1, 2016 3:24 PM
  • No dice here either. Would be nice if it were the fix for us.

    I set "Windows components - Store - Turn off the offer to update to the latest version of Windows" to disabled in my domain GPO.   Local group policy had no affect.

    After setting this GPO, I followed these steps:

    1. Rebooted the Windows 10 1511 machines.

    2. Ran "GPUPDATE /FORCE"

    3. RAN "WUAUCLT /DETECTNOW /REPORTNOW".

    Afterwards within WSUS Console it showed the Windows 1607 for Enterprise en-us as applicable.


    Eric S.

    Thursday, September 1, 2016 3:32 PM
  • That did not fix my issue either. Actually, it made it worse in that the update didn't even show as available when i enabled that policy. With it not configured, the update shows up, it just gets stuck at 0% downloading.

    BradG87

    Thursday, September 1, 2016 5:41 PM
  • @Steve

    about:
    "2. Clients have upgraded to 1706 using Anniversary Update, but cannot get Cumulative Updates
    This is a bug in the Windows client that will be fixed in an upcoming cumulative update"

    Is there any shedule when this patch should be available and will MS release a new Enterprise ISO which includes this patch than aready (cause also fresh installations are affected by this issue) ?



    I'm in the same boat as Malty Timber and am interested in knowing when an update will be released to fix this issue?  The cumulative updates are what is causing the windows update client to get stuck at 0% downloading from a WSUS server.
    Thursday, September 1, 2016 6:04 PM
  • @Steve

    about:
    "2. Clients have upgraded to 1706 using Anniversary Update, but cannot get Cumulative Updates
    This is a bug in the Windows client that will be fixed in an upcoming cumulative update"

    Is there any shedule when this patch should be available and will MS release a new Enterprise ISO which includes this patch than aready (cause also fresh installations are affected by this issue) ?



    I'm in the same boat as Malty Timber and am interested in knowing when an update will be released to fix this issue?  The cumulative updates are what is causing the windows update client to get stuck at 0% downloading from a WSUS server.

    The MS guy above said September 13 CU.  We will have to slip this in our images.  Hopefully they release a new ISO for 1607 with a working update client.

    Thursday, September 1, 2016 8:03 PM
  • I missed it in the thread above but Steve Henry [MSFT] actually already answered this question:

    "To clarify, scenario #2 is a problem with the Windows Update client when it downloads from WSUS, and it affects all updates (not just cumulative).  Service crashes are expected when this occurs; however, because it is nondeterministic, the download should eventually succeed.  Alternatively, you can have your clients scan against Windows Update directly, or download and install directly from the Microsoft Update Catalog.  A fix is scheduled for September's Patch Tuesday (9/13).  Given the bootstrapping issue that some have mentioned, you may want to deploy the September cumulative update directly to expedite resolution."

    Thursday, September 1, 2016 8:10 PM
  • I have had success on two 1607 machines refusing to install cumulative updates on the domain via wsus by merging the following into the reg, then restarting windows update service, then going back into the windows update control panel and it should now have a lovely big install button for the 0% updates.

    I think the key "NextSqmReportTime"="2015-09-22 07:01:37" is missing which is causing it to crash..??

    Edit: make that 3 machines. You need to harass windows update a little in the control panel by switching between it and the Defender options but it seems to be pulling down and install updates fine.

    ===========================================================================

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update]
    "AcceleratedInstallRequired"=dword:00000001
    "AUOptions"=dword:00000004
    "ElevateNonAdmins"=dword:00000001
    "EnableFeaturedSoftware"=dword:00000001
    "IncludeRecommendedUpdates"=dword:00000001
    "IsOOBEInProgress"=dword:00000001
    "NextSqmReportTime"="2015-09-22 07:01:37"



    • Edited by Mark.A.B Friday, September 2, 2016 9:08 AM
    Friday, September 2, 2016 9:02 AM
  • I have had success on two 1607 machines refusing to install cumulative updates on the domain via wsus by merging the following into the reg, then restarting windows update service, then going back into the windows update control panel and it should now have a lovely big install button for the 0% updates.

    I think the key "NextSqmReportTime"="2015-09-22 07:01:37" is missing which is causing it to crash..??

    Edit: make that 3 machines. You need to harass windows update a little in the control panel by switching between it and the Defender options but it seems to be pulling down and install updates fine.

    ===========================================================================

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update]
    "AcceleratedInstallRequired"=dword:00000001
    "AUOptions"=dword:00000004
    "ElevateNonAdmins"=dword:00000001
    "EnableFeaturedSoftware"=dword:00000001
    "IncludeRecommendedUpdates"=dword:00000001
    "IsOOBEInProgress"=dword:00000001
    "NextSqmReportTime"="2015-09-22 07:01:37"


    I wouldn't recommend anyone try this and just wait for the fix on Sept 13.  people have enough problems with WSUS no need to hack it to pieces.  I doubt this is a solid fix.
    Friday, September 2, 2016 11:49 AM
  • Same issue here. This is a problem Microsoft needs to fix before releasing software.

    Microsoft must understand that we are running MS software to run a business. We can't be testing software for MS. They need to get their act right. Why should we pay?

    This type of low quality software is a shame. How many hours have admins all over the world wasted because Microsoft can't test their own software properly.

    Saturday, September 3, 2016 4:13 AM
  • Dear sjaak327,

    Here is a simple but tiresome process that will lay to rest problems with post Anniversary Update CU download 'going into coma' at 0%. I used to have the same problem too and had sleepless nights with worry and struggles till, by God's grace, I tried the process below  - and it performed the miracle just last night.

    With Internet Explorer, (the process is not compatible with Microsoft Edge) go to Microsoft website: Microsoft Update Catalog and download KB3176495, KB3176929, KB3176934, KB3176936, KB3176938 and KB3189031 update standalone packs. Please take note of the folder into which you download them because you have to install them manually hereafter.

    After the download, open the folder. Now, one after the other, install the updates which are suitable for your system (depending on whether you have x64 or x86). After double-clicking on each file, follow the prompt to install the update. Restart your pc each time you are prompted to do so. Remember, the updates must be installed one at a time - that's where patience and endurance are needed.

    When you are done with all the installation, you can now go to WSUS to check the Update History to see that each of the updates has successfully been installed. That may be the end of the download failure problem too.

    Cheers.

    Saturday, September 3, 2016 11:36 AM
  • I had the same. The issue is with KB3176934. Uninstall KB3176934 and re-install the previous CU. Then you can install KB3176934. Yes they're supposed to supersede but it is missing something.

    Sunday, September 4, 2016 12:51 PM
  • It will fail again on the next CU release.
    Sunday, September 4, 2016 12:57 PM
  • Same issue here. This is a problem Microsoft needs to fix before releasing software.

    Microsoft must understand that we are running MS software to run a business. We can't be testing software for MS. They need to get their act right. Why should we pay?

    This type of low quality software is a shame. How many hours have admins all over the world wasted because Microsoft can't test their own software properly.

    Agree 100%
    Tuesday, September 6, 2016 5:58 AM
  • These settings resolve my problems:

    1. Add .esd and .msu mime types to IIS server.

    2. Change DeliveryOptimization mode!

    REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization" /v DODownloadMode /t REG_DWORD /d 100 /f

    Wednesday, September 7, 2016 10:59 PM
  • GTerplan,

    Isn't there a group policy setting for DeliveryOptimization.  Which one would match your registry string? HTTP only?

    Wednesday, September 7, 2016 11:19 PM
  • Hi,

    is .msu added as application/octet-stream like .eds is ?

    The reg key, what mode does that set, http, bypass, internet, LAN, Simple or group

    The delivery model gpo is under, gpo, machine, policies, admin temp, windows comp, Delivery Op, download mode.

    Thursday, September 8, 2016 4:50 AM
  • Same situation. Windows 1607 cannot download updates from WSUS. I tried everything from this forum gpo/reg/etc... no effect
    Thursday, September 8, 2016 8:41 AM
  • Hmmm,

    adding of .msu and .esd types to IIS helps me. You must also restart IIS and WWW services on WSUS server.

    The reg key on clients I have set to HTTP only by GPO.

    Thursday, September 8, 2016 8:59 AM
  • You guys are clouding the issue.

    WSUS does not need .msu and .esd types added manually to IIS.  if you are doing these sorts of things then you don't have your WSUS on 2012 R2 and it is not fully up to date.  That is an entirely different issue.

    The issue is that 1607 clients cannot download CUs from a fully current 2012 R2 WSUS because of a bug in the windows update client that will be fixed on September 15th in the next CU for 1607.  

    Thursday, September 8, 2016 12:37 PM
  • We are encountering issue #3 in our environment. Our WSUS server is a 2012 server with all required patches /settings for Windows 10.  Clients can get the 1511 updates from the WSUS, but not the 1607 updates.  In the WSUS console the 1607 updates are there, but the WSUS is not showing any clients as needing these updates.
    Thursday, September 8, 2016 2:48 PM
  • Definitely having issue #3 trying to get a client to update from 1511 to 1607 from a 2012 R2 WSUS server with KB3159706 installed and the post install tasks completed. It downloads from the server, but still errors out with code 0xc1800118, Claiming that it still isn't decrypting the esd.
    • Edited by Dvigli1 Thursday, September 8, 2016 7:40 PM
    Thursday, September 8, 2016 7:34 PM
  • You guys are clouding the issue.

    WSUS does not need .msu and .esd types added manually to IIS.  if you are doing these sorts of things then you don't have your WSUS on 2012 R2 and it is not fully up to date.  That is an entirely different issue.

    The issue is that 1607 clients cannot download CUs from a fully current 2012 R2 WSUS because of a bug in the windows update client that will be fixed on September 15th in the next CU for 1607.  

    Actually they are not. We ran into issues upgrading from 10 -> 10 (November update) from WSUS because even though our WS 2012 was fully patched and had the specific update to allow this IIS was refusing to deliver esd files. We have also found that WSUS can get a bit flaky when mapping it to what it thinks is an external URL and not just using its domain.local address.
    Friday, September 9, 2016 8:21 AM
  • You guys are clouding the issue.

    WSUS does not need .msu and .esd types added manually to IIS.  if you are doing these sorts of things then you don't have your WSUS on 2012 R2 and it is not fully up to date.  That is an entirely different issue.

    The issue is that 1607 clients cannot download CUs from a fully current 2012 R2 WSUS because of a bug in the windows update client that will be fixed on September 15th in the next CU for 1607.  

    Actually they are not. We ran into issues upgrading from 10 -> 10 (November update) from WSUS because even though our WS 2012 was fully patched and had the specific update to allow this IIS was refusing to deliver esd files. We have also found that WSUS can get a bit flaky when mapping it to what it thinks is an external URL and not just using its domain.local address.
    In my experience it is because something was done out of order or post installation servicing steps were not followed correctly.  I am not saying your at fault because MS really made it difficult to properly set up WSUS with their recent fixes and patches that "require manual post servicing steps afterwards."  I am just saying every 2012 R2 WSUS Ihave built following the proper documented procedure functions fine other than being able to deliver CU's to 1607 clients which should be fixed next month.  Something must have gone awry along the way with your setup like mine did the first time.
    Friday, September 9, 2016 12:38 PM
  • All, The issue being reported and discussed in this thread in Build 1607's inability to install CU updates. It is not a discussion of improperly setup WSUS servers, or specific problems updating Build 1511 to 1607. Those are different issues and you need to start or participate in the correct thread. Yes, everyone here agrees all of these issues are due to Microsoft's own incompetence and inability to create, test, and fix updates to their own product, but please direct your discussion to the correct location
    Friday, September 9, 2016 3:23 PM
  • @Steve

    I have the same Issue 3 with SCCM 1607.


    MfG Hei_G

    Saturday, September 10, 2016 9:43 PM
  • Hi everyone, and apologies for the frustration you're experiencing.  This thread calls out several different symptoms, for each of which I'll provide guidance.  Note that Configuration Manager will exhibit the same symptoms as each of the scenarios below.

    1. WSUS 3.0 SP2 on WS08R2 SP1 (or unpatched WS12/R2) cannot download ESDs

    This is by design.  WSUS 3.2 cannot sync or distribute ESDs, and WS12/R2 can only do so if both KB3095113 and KB3159706 are installed on the machine, and all necessary post-install steps from KB3159706 have been followed.  As folks have noted, these post-install steps [and the general way that this update was released] caused unnecessary pain and confusion.  We'll choose a less disruptive strategy for future WSUS updates.

    2. Clients have upgraded to 1706 using Anniversary Update, but cannot get Cumulative Updates

    This is a bug in the Windows client that will be fixed in an upcoming cumulative update.  In the meantime, clients may experience some delay in getting the monthly content, but they will eventually download it.  The workaround here is to simply wait longer than usual, or to scan directly against Windows Update if you've waited several days and haven't seen any download success in that time.

    3. WSUS can sync/distribute feature updates (such as 1511), but cannot deploy the 1607 feature update

    This is a newly reported issue that we are currently investigating.  Again, the workaround is to pull the 1607 feature update from Windows Update instead of WSUS.  We understand why you might not want to pull such a large file from the Internet once for each of your clients, and are figuring this out as soon as we can.  We'll share further updates on the investigation as they become available.

    In relation to Point 3 above, I had this issue and eventually had to dig out Message Analyzer to figure out what on Earth was going on.

    In short, my environment:

    1. WSUS on Windows Server 2012 R2 client with the relevant hotfix and MIME type installed/configured.
    2. Windows 10 x64 Enterprise client on branch 1511.
    3. Error 0x80244019 was being thrown upon checking for updates.
    4. Host headers configured within IIS as WSUS co-exists with a few other static sites like our CRL publishing point.

    What I found from the network trace was that the HEAD request from BITS is incorrectly using the NetBIOS hostname, despite the Automatic Updates client and server both correctly using (or at least logging) the FQDN.

    Because of point 4 from my list, this was (correctly) resulting in a HTTP 404 error on the download as the host header obviously wasn't matching.

    As a workaround, I added the NetBIOS name as an additional HTTP header (we're not using HTTPS for client distribution, but this is clearly also going to be an issue for sites that are), but really, God alone knows who decided to have an Internet service (BITS) work off an NetBIOS name to begin with when it clearly should be using FQDN's.

    Cheers,
    Lain

    • Edited by Lain Robertson Monday, September 12, 2016 8:38 AM More formatting changes.
    Monday, September 12, 2016 8:34 AM
  • Regarding issue 2: Adding update KB3176936 (servicing stack) and the most recent CU KB3176938 to Windows manually (or offline with DISM/MDT) appears to resolve the issue with hanging downloads & installs of updates from a WSUS server. E.g. Silverlight and Flash updates now get downloaded as expected.

    The servicing stack update makes all the difference. Purely including the most recent CU is not sufficient.

    Monday, September 12, 2016 10:13 PM
  • Regarding issue 2: Adding update KB3176936 (servicing stack) and the most recent CU KB3176938 to Windows manually (or offline with DISM/MDT) appears to resolve the issue with hanging downloads & installs of updates from a WSUS server. E.g. Silverlight and Flash updates now get downloaded as expected.

    The servicing stack update makes all the difference. Purely including the most recent CU is not sufficient.

    No.  Silverlight and Flash were never impacted.  It was 1607 CUs that would hang and not download.  You will still have this problem until the new CU coming out this month for 1607.
    Tuesday, September 13, 2016 11:59 AM
  • Just thought I would mention that it might be worth waiting on the upgrading of 1511 as 1607 pretty much breaks WSUS completely after the upgrade. I have had to revert windows update away from WSUS for 1607 machines until this is fixed. I've left the majority of PC's on 1511 for this reason.
    Tuesday, September 13, 2016 1:17 PM
  • 3. WSUS can sync/distribute feature updates (such as 1511), but cannot deploy the 1607 feature update

    This is a newly reported issue that we are currently investigating.  Again, the workaround is to pull the 1607 feature update from Windows Update instead of WSUS.  We understand why you might not want to pull such a large file from the Internet once for each of your clients, and are figuring this out as soon as we can.  We'll share further updates on the investigation as they become available.

    Quick update on this one: we are unable to reproduce the upgrade to 1607 issue internally. Furthermore, anyone that has clarified their symptoms regarding their experience downloading from WSUS has [so far] revealed that their issues are happening after upgrade to 1607 has already succeeded.  If anyone has symptoms that match scenario #3, then please let us know; otherwise, we'll assume that only scenario #2 is an actual issue.

    To clarify, scenario #2 is a problem with the Windows Update client when it downloads from WSUS, and it affects all updates (not just cumulative).  Service crashes are expected when this occurs; however, because it is nondeterministic, the download should eventually succeed.  Alternatively, you can have your clients scan against Windows Update directly, or download and install directly from the Microsoft Update Catalog.  A fix is scheduled for September's Patch Tuesday (9/13).  Given the bootstrapping issue that some have mentioned, you may want to deploy the September cumulative update directly to expedite resolution.

    Hi Steve, today is 9/13... can you please update as to whether the fix was released today, and if so, which patch is it?  And what is the recommended way of applying it, as it seems like pushing it out through WSUS may not work?  And furthermore, do we have to wait until another CU is released before we will be able to verify if the fix worked?  Thanks,

    Craig

    Tuesday, September 13, 2016 1:50 PM
  • Hi Steve, today is 9/13... can you please update as to whether the fix was released today, and if so, which patch is it?  And what is the recommended way of applying it, as it seems like pushing it out through WSUS may not work?  And furthermore, do we have to wait until another CU is released before we will be able to verify if the fix worked?  Thanks,

    Craig

    What he said!
    • Edited by Turge Tuesday, September 13, 2016 3:29 PM
    Tuesday, September 13, 2016 3:29 PM
  • KB3189866 available.

    I don't see any reference at Windows Update inside release note :(

    Tuesday, September 13, 2016 5:24 PM
  • Latest CU is still crashing :/
    Tuesday, September 13, 2016 5:41 PM
  • scurro,

    I was going to test it right now. But since it failed for you, I will not.

    My scenario is: Windows Server 2008 SP2, WSUS 3.0 all patched. My machine, that I'm using to test updates is using Windows 10 version 1607 (14394.51).

    I didn't updated my Windows 10 to anniversary update using WSUS because on 2008 SP2 it can't distribute feature updates (ESD). So I updated my machine manually and now I'm trying to update it using WSUS to check if I can finally update other machines on my organization to it without problems.



    Tuesday, September 13, 2016 6:19 PM
  • I just tested it and it works.  I took a v1607 image with no updates installed, applied it to a test PC and then installed KB3189866 by hand.  After that I connected to the WSUS server. It downloaded and installed KB3176936 and KB3188128 which brings v1607 up to date.

    So the bug appears to be fixed but you have to apply the update by some other method besides WSUS.

    Tuesday, September 13, 2016 7:03 PM
  • I just tested it and it works.  I took a v1607 image with no updates installed, applied it to a test PC and then installed KB3189866 by hand.  After that I connected to the WSUS server. It downloaded and installed KB3176936 and KB3188128 which brings v1607 up to date.

    So the bug appears to be fixed but you have to apply the update by some other method besides WSUS.

    This was known that updates outside of WSUS would not crash.
    Tuesday, September 13, 2016 8:25 PM
  • I can confirm that KB3189866 will solve this problem (btw the CU of August patchday didn't work in our case)! Just include it as package into your deployment workbench (and take care that it will be used in the correct task sequence of cause...) and updates provided via WSUS will be installed properly again. Nothing more is necessary to be able to build a reference image for Windows 10 1607 if you have your infrastructure already on the newest patch level (especially no changes in the registry or IIS Settings - only the steps descriped in KB3159706 have to be done but this was already necessary before Win10 1607 was released!).

    Tuesday, September 13, 2016 8:46 PM
  • Ok thanks for your test scurro. Anyone else can confirm that ?
    Tuesday, September 13, 2016 8:49 PM
  • Looks good on the laptop I just deployed using MDT (I added it to be installed during deployment and it seemed to have no problems connecting to WSUS)

    Assuming this is the fix, does anybody know what would happen if I approved Windows 1607 on WSUS for install on clients?  Would I have to find some way of manually pushing the update to these computers?
    Tuesday, September 13, 2016 9:01 PM
  • I rolled this into our 1607 MDT image just like SimonL1986 and all other updates were downloaded from WSUS and installed successfully. I'd still prefer a proper 1677 ISO.

    There was no new 1607 "upgrade" released so I assume we'll still run into the same problems upgrading from 1511 unless we use an alternate method to deploy KB3189866 after the 1607 upgrade.



    • Edited by jkillebrew Tuesday, September 13, 2016 10:27 PM
    Tuesday, September 13, 2016 10:23 PM
  • Latest CU is still crashing :/

    Same.  Computers getting stuck at 45% on downloading KB3189866.  What's worse, all 1607 computers are ignoring their WSUS settings and TRYING TO DOWNLOAD ALL UPDATES DIRECT FROM MS SERVER.  Do you know what happens when you have 30+ workstations all hammering your internet connection simultaneously?  To compound the misery further, they never stop downloading, just get stuck at 45% and endlessly suck bandwidth.  Monitoring the stations, they will endlessly download gigs upon gigs of data into the softwaredistribution folder but never complete.  1607 desktops effectively DDOS'd our own network trying to download patches..  No other Windows versions, including 8.1 machines and 1511 Windows 10 boxes have this issue-- they all download from WSUS, not the internet, and they all patch correctly.  To deal with this problem and restore network functionality, we literally had to block the MS Update IP's at our firewall for all our workstations.

    This is absolutely ridiculous and MS needs to either issue a fix or a viable workaround.  Enterprise desktops ignoring WSUS settings and downloading ALL available updates via the internet is a HUGE problem.

     
    Tuesday, September 13, 2016 11:41 PM
  • yep I am seeing the same issue. Direct to Windows update servers and stuck at 97%
    Wednesday, September 14, 2016 7:39 AM
  • I manualy installed KB3189866 and it works. I can now download and install other updates from WSUS (Office/Flash...). No more crash for wuauserv
    Wednesday, September 14, 2016 8:05 AM
  • OK it has finally downloaded maybe just takes time.
    Wednesday, September 14, 2016 8:20 AM
  • The situation is still same. Manually installed KB3188966 and windows update still not working. Still tell me, that some update are not installed and doesn't allow me to check it online in MS Windows update.
    Wednesday, September 14, 2016 8:29 AM
  • Still experience Scenario #3, WSUS 2012 R2 is patched with latest updates (including KB3095113 and KB3159706) , MIME types added to IIS, 1607 Anniversary updates were removed and downloaded again to WUSS, client workstations may download them, but always get Error 0xc1800118 after that.

    Steve, is there any workaround?

    Wednesday, September 14, 2016 8:54 AM
  • $hotfixId= 'kb3189866'
    $id=Get-HotFix -id $hotfixId -ErrorAction SilentlyContinue | Select -ExpandProperty HotFixId
    if( $id -eq $hotfixId) {
    echo "already exist"
    }
    else{
    $SB={ Start-Process -FilePath 'c:\windows\system32\wusa.exe' -ArgumentList "\\dati\Software\kb_fixes\win10_1607\AMD64-all-windows10.0-kb3189866-x64.msu /quiet /norestart" -Wait -PassThru }
    Invoke-Command -ScriptBlock $SB
    }
    PS Script to install for 1607 via gpo startup, after next restart it installs. after than other updates also could install normaly.
    Wednesday, September 14, 2016 9:16 AM
  • Still experience Scenario #3, WSUS 2012 R2 is patched with latest updates (including KB3095113 and KB3159706) , MIME types added to IIS, 1607 Anniversary updates were removed and downloaded again to WUSS, client workstations may download them, but always get Error 0xc1800118 after that.

    Steve, is there any workaround?

    did you complete kb3159706 Manual steps required to complete the installation of this update
    Wednesday, September 14, 2016 9:18 AM
  • Still experience Scenario #3, WSUS 2012 R2 is patched with latest updates (including KB3095113 and KB3159706) , MIME types added to IIS, 1607 Anniversary updates were removed and downloaded again to WUSS, client workstations may download them, but always get Error 0xc1800118 after that.

    Steve, is there any workaround?

    did you complete kb3159706 Manual steps required to complete the installation of this update

    Yes, I did. Twice on different (test and prod) WSUS for sure :)

    Wednesday, September 14, 2016 10:10 AM
  • no problems for us, deployed the CU and updates now seems to be working, at last!
    Wednesday, September 14, 2016 12:00 PM
  • So, we are suppose to install manually the KB3189866 update to finally WSUS work again?

    I've tried now to allow the KB3176936 and my machine started giving problems.

    So I restarted Windows Update on my machine, cleaned and unapproved that update on WSUS along with the KB3189866 update.

    Using WSUS on a 2008 SP2 server, I already have to update to anniversary update manually. So I will have to apply this new one update manually too to be able to receive the other updates normally?


    Wednesday, September 14, 2016 12:12 PM
  • Still experience Scenario #3, WSUS 2012 R2 is patched with latest updates (including KB3095113 and KB3159706) , MIME types added to IIS, 1607 Anniversary updates were removed and downloaded again to WUSS, client workstations may download them, but always get Error 0xc1800118 after that.

    Steve, is there any workaround?

    did you complete kb3159706 Manual steps required to complete the installation of this update

    We are also still experiencing Issue #3. All KB's and post install steps have been done. Since Steve said they have not been able to reproduce this issue, I am willing to work with Microsoft if they want to look at our server to see what is going on. Steve?

    Thanks.


    BradG87

    Wednesday, September 14, 2016 12:59 PM
  • UPDATE - Today I still couldn't et my system to get the new cumulative update for 1607 so I manually installed it.  This may not be ideal: I wen to https://catalog.update.microsoft.com, installed the add-in, Searched for KB3189866, selected x64 version (add), view basket, Download (431.1 MB) - saved in Downloads then ran the update.  My system updated in about 5 minutes and needed a reboot.  Once back online I went back into windows updates on my system (managed by WSUS) and selected check for updates.  The other updates came in (Office, Flash, Malicious Software Removal Tool..) and installed with no issue.  Hopefully this is fixed, but I'll have to wait for the next 1607 update to be sure.
    Wednesday, September 14, 2016 3:58 PM
  • My Situation.  Currently running WSUS on Windows Server 2012 R2 and was having issues with Win 10 1607 clients.  I have applied both Server KBs and manual steps. I have also manually applied the September CU to two different test Win10 1607 machines but am still failing to communicate correctly with WSUS.

    After fully patching a Win10 machine via Microsoft Update, I enabled the "Do not connect to any Windows Update Internet locations" policy to ensure that the machine only communicates with WSUS.  I removed the Flash Player update as a test, and tried to check for updates.  However both machines fail with "There were some problems installing updates, but we'll try again later.  If you keep seeing this and want to search the web or contact support for information, this may help (0x8024500c)."  If I turn off that policy, the machine updates perfectly fine from Microsoft Update, even though I have an Intranet Server configured correctly.  My same policies work well on non-Win10 machines as well as Win10-1511 machines.

    On the WSUS side, the machines are able to report but no updates are ever shown as applicable, even though I know the machine needs the Flash update. 

    Is anyone else experiencing this issue or has previously encountered and resolved it?  I have deleting the computers from WSUS, deleted the susid reg keys on the client, resetauthorization on the clients, and even completely reinstalled WSUS and rebuilt the DB.  Does this not repro on Server 2016?  Tempted to update to the Technical Preview just to fix WSUS.

    Here is the log from the client.

    Thanks,
    Patrick

    2016/09/14 11:00:32.8557913 1012  6712  ComApi          IUpdateServiceManager::AddService2
    2016/09/14 11:00:32.8557923 1012  6712  ComApi          Service ID = {7971f918-a847-4430-9279-4a52d1efe18d}
    2016/09/14 11:00:32.8557929 1012  6712  ComApi          Allow pending registration = Yes; Allow online registration = Yes; Register service with AU = Yes
    2016/09/14 11:00:32.8557933 1012  6712  ComApi          Authorization cab path = NULL
    2016/09/14 11:00:32.8970347 1012  6712  ComApi          Added service, URL = https://fe2.update.microsoft.com/v6/
    2016/09/14 11:00:34.1185544 1012  6712  ComApi          * START *   Init Search ClientId = UpdateOrchestrator
    2016/09/14 11:00:34.1185637 1012  6712  ComApi          * START *   Search ClientId = UpdateOrchestrator
    1600/12/31 16:00:00.0000000 1012  2908                  Unknown( 147): GUID=fde1d6c9-915b-3206-4ef5-31d14b23d758 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  2908                  Unknown( 154): GUID=fde1d6c9-915b-3206-4ef5-31d14b23d758 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  2908                  Unknown( 155): GUID=fde1d6c9-915b-3206-4ef5-31d14b23d758 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  2908                  Unknown( 34): GUID=7b9bf239-47b9-3688-3a9e-14f09f262608 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  2908                  Unknown( 78): GUID=fde1d6c9-915b-3206-4ef5-31d14b23d758 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6712                  Unknown( 23): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6712                  Unknown( 122): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6712                  Unknown( 123): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    2016/09/14 11:00:34.9969953 1012  6712  ComApi          Search ClientId = UpdateOrchestrator
    1600/12/31 16:00:00.0000000 1012  6508                  Unknown( 122): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6504                  Unknown( 25): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6504                  Unknown( 207): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6504                  Unknown( 12): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6504                  Unknown( 13): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6504                  Unknown( 14): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6504                  Unknown( 15): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6504                  Unknown( 16): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6504                  Unknown( 19): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6504                  Unknown( 20): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6504                  Unknown( 213): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6504                  Unknown( 14): GUID=3905367d-5739-34f2-739b-cf9a482c3e56 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6504                  Unknown( 11): GUID=2fc03aa6-a1fa-3d0c-ba09-b8539ec28a26 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6504                  Unknown( 125): GUID=2fc03aa6-a1fa-3d0c-ba09-b8539ec28a26 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6504                  Unknown( 145): GUID=2fc03aa6-a1fa-3d0c-ba09-b8539ec28a26 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6504                  Unknown( 119): GUID=2fc03aa6-a1fa-3d0c-ba09-b8539ec28a26 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6504                  Unknown( 96): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    2016/09/14 11:00:35.9837557 1012  6504  WebServices     Auto proxy settings for this web service call.
    1600/12/31 16:00:00.0000000 1012  6504                  Unknown( 96): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6504                  Unknown( 49): GUID=2fc03aa6-a1fa-3d0c-ba09-b8539ec28a26 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6504                  Unknown( 57): GUID=2fc03aa6-a1fa-3d0c-ba09-b8539ec28a26 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6504                  Unknown( 96): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6504                  Unknown( 96): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6504                  Unknown( 194): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6504                  Unknown( 241): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    2016/09/14 11:00:36.0814586 1012  2732  ComApi          *RESUMED* Search ClientId = UpdateOrchestrator
    2016/09/14 11:00:36.0820281 1012  2732  ComApi          Updates found = 0
    2016/09/14 11:00:36.0820287 1012  2732  ComApi          * END *   Search ClientId = UpdateOrchestrator
    2016/09/14 11:00:36.0826819 1012  6712  ComApi          ISusInternal:: DisconnectCall failed, hr=8024000C
    2016/09/14 11:00:36.1603726 1012  6712  ComApi          * START *   Init Search ClientId = UpdateOrchestrator
    2016/09/14 11:00:36.1603755 1012  6712  ComApi          * START *   Search ClientId = UpdateOrchestrator
    1600/12/31 16:00:00.0000000 1012  6712                  Unknown( 23): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6712                  Unknown( 122): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6712                  Unknown( 123): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    2016/09/14 11:00:36.1625447 1012  6712  ComApi          Search ClientId = UpdateOrchestrator
    1600/12/31 16:00:00.0000000 1012  6508                  Unknown( 122): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6480                  Unknown( 25): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6480                  Unknown( 207): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6480                  Unknown( 12): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6480                  Unknown( 13): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6480                  Unknown( 14): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6480                  Unknown( 15): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6480                  Unknown( 16): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6480                  Unknown( 19): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6480                  Unknown( 20): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6480                  Unknown( 73): GUID=3905367d-5739-34f2-739b-cf9a482c3e56 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6480                  Unknown( 69): GUID=3905367d-5739-34f2-739b-cf9a482c3e56 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6480                  Unknown( 37): GUID=1a15fa80-1dce-3096-4a44-35487fe3664a (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6480                  Unknown( 73): GUID=3905367d-5739-34f2-739b-cf9a482c3e56 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6480                  Unknown( 69): GUID=3905367d-5739-34f2-739b-cf9a482c3e56 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6480                  Unknown( 14): GUID=c0a36c36-da93-33f3-edc6-bcaeaef60c9b (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6480                  Unknown( 11): GUID=c0a36c36-da93-33f3-edc6-bcaeaef60c9b (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6480                  Unknown( 240): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6480                  Unknown( 241): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    2016/09/14 11:00:36.1814828 1012  2732  ComApi          *RESUMED* Search ClientId = UpdateOrchestrator
    2016/09/14 11:00:36.1818165 1012  2732  ComApi          Updates found = 0
    2016/09/14 11:00:36.1818172 1012  2732  ComApi          Exit code = 0x00000000, Result code = 0x8024500C
    2016/09/14 11:00:36.1818175 1012  2732  ComApi          * END *   Search ClientId = UpdateOrchestrator
    2016/09/14 11:00:36.1820774 1012  6712  ComApi          ISusInternal:: DisconnectCall failed, hr=8024000C
    2016/09/14 11:01:15.5677583 8344  8364  ComApi          * START *   Init Search ClientId = Update;taskhostw
    2016/09/14 11:01:15.5677623 8344  8364  ComApi          * START *   Search ClientId = Update;taskhostw
    1600/12/31 16:00:00.0000000 1012  1464                  Unknown( 23): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  1464                  Unknown( 122): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  1464                  Unknown( 123): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6508                  Unknown( 122): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    2016/09/14 11:01:15.5734386 8344  8364  ComApi          Search ClientId = Update;taskhostw
    1600/12/31 16:00:00.0000000 1012  8460                  Unknown( 25): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8460                  Unknown( 207): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8460                  Unknown( 12): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8460                  Unknown( 13): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8460                  Unknown( 14): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8460                  Unknown( 15): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8460                  Unknown( 16): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8460                  Unknown( 209): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8460                  Unknown( 240): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8460                  Unknown( 241): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    2016/09/14 11:01:15.5894685 8344  8452  ComApi          *RESUMED* Search ClientId = Update;taskhostw
    2016/09/14 11:01:15.5910139 8344  8452  ComApi          Updates found = 0
    2016/09/14 11:01:15.5910149 8344  8452  ComApi          Exit code = 0x00000000, Result code = 0x80248014
    2016/09/14 11:01:15.5910156 8344  8452  ComApi          * END *   Search ClientId = Update;taskhostw
    2016/09/14 11:01:15.5922928 8344  8364  ComApi          ISusInternal:: DisconnectCall failed, hr=8024000C
    2016/09/14 11:01:15.5944319 8344  8364  ComApi          * START *   Init Search ClientId = Update;taskhostw
    2016/09/14 11:01:15.5944392 8344  8364  ComApi          * START *   Search ClientId = Update;taskhostw
    1600/12/31 16:00:00.0000000 1012  2732                  Unknown( 23): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  2732                  Unknown( 119): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  2732                  Unknown( 122): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  2732                  Unknown( 123): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    2016/09/14 11:01:15.5995619 8344  8364  ComApi          Search ClientId = Update;taskhostw
    1600/12/31 16:00:00.0000000 1012  6508                  Unknown( 122): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8492                  Unknown( 25): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8492                  Unknown( 207): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8492                  Unknown( 12): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8492                  Unknown( 13): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8492                  Unknown( 14): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8492                  Unknown( 15): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8492                  Unknown( 16): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8492                  Unknown( 20): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8492                  Unknown( 73): GUID=3905367d-5739-34f2-739b-cf9a482c3e56 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8492                  Unknown( 58): GUID=3905367d-5739-34f2-739b-cf9a482c3e56 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8492                  Unknown( 86): GUID=1a15fa80-1dce-3096-4a44-35487fe3664a (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8492                  Unknown( 209): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8492                  Unknown( 240): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8492                  Unknown( 241): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    2016/09/14 11:01:15.6171561 8344  8368  ComApi          * START *   Init Search ClientId = Update;taskhostw
    2016/09/14 11:01:15.6171601 8344  8368  ComApi          * START *   Search ClientId = Update;taskhostw
    2016/09/14 11:01:15.6176659 8344  8424  ComApi          * START *   Init Search ClientId = Update;taskhostw
    2016/09/14 11:01:15.6176683 8344  8424  ComApi          * START *   Search ClientId = Update;taskhostw
    1600/12/31 16:00:00.0000000 1012  2732                  Unknown( 23): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  2852                  Unknown( 23): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  2732                  Unknown( 120): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  2852                  Unknown( 120): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  2732                  Unknown( 122): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  2852                  Unknown( 122): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  2732                  Unknown( 123): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  2852                  Unknown( 123): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    2016/09/14 11:01:15.6202659 8344  8368  ComApi          Search ClientId = Update;taskhostw
    2016/09/14 11:01:15.6203457 8344  8424  ComApi          Search ClientId = Update;taskhostw
    1600/12/31 16:00:00.0000000 1012  6508                  Unknown( 122): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    2016/09/14 11:01:15.6255405 8344  8452  ComApi          *RESUMED* Search ClientId = Update;taskhostw
    2016/09/14 11:01:15.6259146 8344  8452  ComApi          Updates found = 0
    2016/09/14 11:01:15.6259156 8344  8452  ComApi          Exit code = 0x00000000, Result code = 0x80248014
    2016/09/14 11:01:15.6259163 8344  8452  ComApi          * END *   Search ClientId = Update;taskhostw
    1600/12/31 16:00:00.0000000 1012  8496                  Unknown( 25): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    2016/09/14 11:01:15.6269466 8344  8364  ComApi          ISusInternal:: DisconnectCall failed, hr=8024000C
    1600/12/31 16:00:00.0000000 1012  8496                  Unknown( 207): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8496                  Unknown( 12): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8496                  Unknown( 13): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8496                  Unknown( 14): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8496                  Unknown( 15): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8496                  Unknown( 16): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8496                  Unknown( 209): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8496                  Unknown( 240): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8496                  Unknown( 241): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6508                  Unknown( 122): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    2016/09/14 11:01:15.6436419 8344  8452  ComApi          *RESUMED* Search ClientId = Update;taskhostw
    2016/09/14 11:01:15.6440240 8344  8452  ComApi          Updates found = 0
    2016/09/14 11:01:15.6440250 8344  8452  ComApi          Exit code = 0x00000000, Result code = 0x80248014
    2016/09/14 11:01:15.6440253 8344  8452  ComApi          * END *   Search ClientId = Update;taskhostw
    2016/09/14 11:01:15.6452884 8344  8368  ComApi          ISusInternal:: DisconnectCall failed, hr=8024000C
    2016/09/14 11:01:15.6486077 8344  8368  ComApi          * START *   Init Search ClientId = Update;taskhostw
    2016/09/14 11:01:15.6486110 8344  8368  ComApi          * START *   Search ClientId = Update;taskhostw
    1600/12/31 16:00:00.0000000 1012  8504                  Unknown( 25): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  2852                  Unknown( 23): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  2852                  Unknown( 120): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  2852                  Unknown( 122): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  2852                  Unknown( 123): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    2016/09/14 11:01:15.6552583 8344  8368  ComApi          Search ClientId = Update;taskhostw
    1600/12/31 16:00:00.0000000 1012  8504                  Unknown( 207): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8504                  Unknown( 12): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8504                  Unknown( 13): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8504                  Unknown( 14): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8504                  Unknown( 15): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8504                  Unknown( 16): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8504                  Unknown( 209): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8504                  Unknown( 240): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8504                  Unknown( 241): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    2016/09/14 11:01:15.6796349 8344  8452  ComApi          *RESUMED* Search ClientId = Update;taskhostw
    1600/12/31 16:00:00.0000000 1012  6508                  Unknown( 122): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    2016/09/14 11:01:15.6800560 8344  8452  ComApi          Updates found = 0
    2016/09/14 11:01:15.6800570 8344  8452  ComApi          Exit code = 0x00000000, Result code = 0x80248014
    2016/09/14 11:01:15.6800573 8344  8452  ComApi          * END *   Search ClientId = Update;taskhostw
    2016/09/14 11:01:15.6811936 8344  8424  ComApi          ISusInternal:: DisconnectCall failed, hr=8024000C
    1600/12/31 16:00:00.0000000 1012  8552                  Unknown( 25): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    2016/09/14 11:01:15.6834598 8344  8424  ComApi          * START *   Init Search ClientId = Update;taskhostw
    2016/09/14 11:01:15.6834634 8344  8424  ComApi          * START *   Search ClientId = Update;taskhostw
    1600/12/31 16:00:00.0000000 1012  2852                  Unknown( 23): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  2852                  Unknown( 120): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  2852                  Unknown( 122): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  2852                  Unknown( 123): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    2016/09/14 11:01:15.6880438 8344  8424  ComApi          Search ClientId = Update;taskhostw
    1600/12/31 16:00:00.0000000 1012  8552                  Unknown( 207): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8552                  Unknown( 12): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8552                  Unknown( 13): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8552                  Unknown( 14): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8552                  Unknown( 15): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8552                  Unknown( 16): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8552                  Unknown( 20): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8552                  Unknown( 73): GUID=3905367d-5739-34f2-739b-cf9a482c3e56 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8552                  Unknown( 58): GUID=3905367d-5739-34f2-739b-cf9a482c3e56 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8552                  Unknown( 86): GUID=1a15fa80-1dce-3096-4a44-35487fe3664a (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8552                  Unknown( 209): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8552                  Unknown( 240): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8552                  Unknown( 241): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6508                  Unknown( 122): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8604                  Unknown( 25): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8604                  Unknown( 207): GUID=0defb9f2-be29-3d72-4390-6806b45a584c (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8604                  Unknown( 12): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8604                  Unknown( 13): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8604                  Unknown( 14): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  8604                  Unknown( 15): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).

     
    Wednesday, September 14, 2016 6:05 PM
  • So, I have KB3189866 installed on 19 PC's, update from WSUS working, but at the first time I must delete softwaredistribution folder. After that, update running but slowly than 1511. But the biggest problem is, that I'm unable to update Windows defender from WSUS? I was try it many times from many computer, without luck. The only way is use offline definition update.

     

    Wednesday, September 14, 2016 6:27 PM
  • Patrick:

    We have whats sounds to be a similar setup to you and are experiencing the 0x8024500c error.

    From what I'm seeing in the Windows Update logs 0x8024500C equates to "Unable to get SLS chunk". So my current theory is this is being caused by SLS failing somewhere in the pipe. 

    We block all web traffic at the firewall, with a proxy in place to selectively block/allow various sites, including blocking Windows Update, activation, etc. I'm currently messing around with exclusions to see what might be causing these failures.

    Wednesday, September 14, 2016 8:37 PM
  • Today I logged onto the WSUS Server and downloaded updates directly from Microsoft Updates and rebooted (luckily I can take a snapshot of my WSUS Server for just in case).  Once back online I verified the WSUS Set-up and discovered the UPGRADES (Options - Products and Classifications - Classifications tab) was not select so I selected and forced a sync.  I then checked two test systems with the Windows 10 Anniversary Update 1607 (that was installed manually) and forced a WSUS agent update.  The updates now appeared after selecting the check for updates, but it still stuck on downloading.  I rebooted the test systems then the updates started to download and install.  At least the clients and the WSUS are talking to each other.  Almost there...
    Wednesday, September 14, 2016 9:00 PM
  • Thanks for the reply, let me know what you find out. Either way, it seems like that group policy setting is broken on the latest version of Windows, since we should be able to enable it and still have WSUS work correctly. Disabling it redirects all clients to Microsoft Update instead of WSUS, and updates are downloaded over the internet and installed without my explicit approval (even though the Intranet location policy is enabled and working for clients running other versions of Windows).
    Wednesday, September 14, 2016 11:25 PM
  • We are about to deploy W10 with 1607 update using SCCM. On the test installations this WSUS issue occurred, but by manually including the KB3189866 update to the image and re-capturing it to OS image, the issue became fixed.
    Thursday, September 15, 2016 5:55 AM
  • But the biggest problem is, that I'm unable to update Windows defender from WSUS? I was try it many times from many computer, without luck. The only way is use offline definition update.

     

    This seems to be new, because the WindowsDefender definitions aren't longer part of WSUS.

    How longer I think: Windows 10 doesn't seems to designed for business :-(

    Thursday, September 15, 2016 1:31 PM
  • Why do think that Windows defender is not part part of the WSUS. I still can choose it in the Product and classification. This is screenshot from W2012R2 and in my test W2016 TP5 exist aswel?

    

    Thursday, September 15, 2016 2:02 PM
  • Are we sure that KB3189866 fixes the issue permanently? I have installed it and the updates work from WSUS, the only ones I have seen download and install are Office updates... but I'm curious, when the next Cumulative update is released, will be be back to square one with the Windows Update service crashing when trying to download the next Cumulative updates? How do we know if the issue is fixed unless we wait for another Cumulative update to be released? I didn't see any specific mention of it in the KB3189866 release notes and it is my understanding that this update contains all the previous Cumulative updates (correct me if I am wrong).

    Thursday, September 15, 2016 6:53 PM
  • Why do think that Windows defender is not part part of the WSUS. I still can choose it in the Product and classification. This is screenshot from W2012R2 and in my test W2016 TP5 exist aswel?

    

    You are right, sorry. But it's a good hint from you, because the product location has changed from "definition updates" to "windows".

    Thank you

    Friday, September 16, 2016 6:32 AM
  • You welcome, but this is not solve my problem. Today I must 19th time run mpam-fe.exe for Windows defender update. :-( 
    Friday, September 16, 2016 8:27 AM
  • I can also confirm that KB3189866 does resolve the issue where WSUS updates would get stuck and not come down during Windows 10 1607 build from MDT 2013 Update 2.

    Reading through countless replies from all contributors, I have concluded that following procedure should be done to resolve this problem:

    1. Remove all previously imported OS updates from your MDT.
    2. Import only KB3189866.
    3. Update your deployment share to recreate your ISO
    4. Build successfully.

    This was all that I needed to do and now when I build my Core Windows 10 x64 1607 Reference image, both Office and Windows OS updates come down and install without issues.

    Friday, September 16, 2016 1:17 PM
  • My Situation.  Currently running WSUS on Windows Server 2012 R2 and was having issues with Win 10 1607 clients.  I have applied both Server KBs and manual steps. I have also manually applied the September CU to two different test Win10 1607 machines but am still failing to communicate correctly with WSUS.

    After fully patching a Win10 machine via Microsoft Update, I enabled the "Do not connect to any Windows Update Internet locations" policy to ensure that the machine only communicates with WSUS.  I removed the Flash Player update as a test, and tried to check for updates.  However both machines fail with "There were some problems installing updates, but we'll try again later.  If you keep seeing this and want to search the web or contact support for information, this may help (0x8024500c)."  If I turn off that policy, the machine updates perfectly fine from Microsoft Update, even though I have an Intranet Server configured correctly.  My same policies work well on non-Win10 machines as well as Win10-1511 machines.

    On the WSUS side, the machines are able to report but no updates are ever shown as applicable, even though I know the machine needs the Flash update. 

    Is anyone else experiencing this issue or has previously encountered and resolved it?  I have deleting the computers from WSUS, deleted the susid reg keys on the client, resetauthorization on the clients, and even completely reinstalled WSUS and rebuilt the DB.  Does this not repro on Server 2016?  Tempted to update to the Technical Preview just to fix WSUS.

    Here is the log from the client.

    Thanks,
    Patrick

    2016/09/14 11:00:32.8557913 1012  6712  ComApi          IUpdateServiceManager::AddService2
    2016/09/14 11:00:32.8557923 1012  6712  ComApi          Service ID = {7971f918-a847-4430-9279-4a52d1efe18d}
    2016/09/14 11:00:32.8557929 1012  6712  ComApi          Allow pending registration = Yes; Allow online registration = Yes; Register service with AU = Yes
    2016/09/14 11:00:32.8557933 1012  6712  ComApi          Authorization cab path = NULL
    2016/09/14 11:00:32.8970347 1012  6712  ComApi          Added service, URL = https://fe2.update.microsoft.com/v6/
    2016/09/14 11:00:34.1185544 1012  6712  ComApi          * START *   Init Search ClientId = UpdateOrchestrator
    2016/09/14 11:00:34.1185637 1012  6712  ComApi          * START *   Search ClientId = UpdateOrchestrator
    1600/12/31 16:00:00.0000000 1012  2908                  Unknown( 147): GUID=fde1d6c9-915b-3206-4ef5-31d14b23d758 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  2908                  Unknown( 154): GUID=fde1d6c9-915b-3206-4ef5-31d14b23d758 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  2908                  Unknown( 155):

    <snipped for length>

    2016/09/14 11:00:36.0814586 1012  2732  ComApi          *RESUMED* Search ClientId = UpdateOrchestrator
    2016/09/14 11:00:36.0820281 1012  2732  ComApi          Updates found = 0
    2016/09/14 11:00:36.0820287 1012  2732  ComApi          * END *   Search ClientId = UpdateOrchestrator
    2016/09/14 11:00:36.0826819 1012  6712  ComApi          ISusInternal:: DisconnectCall failed, hr=8024000C
    2016/09/14 11:00:36.1603726 1012  6712  ComApi          * START *   Init Search ClientId = UpdateOrchestrator
    2016/09/14 11:00:36.1603755 1012  6712  ComApi          * START *   Search ClientId = UpdateOrchestrator
    1600/12/31 16:00:00.0000000 1012  6712                  Unknown( 23): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).
    1600/12/31 16:00:00.0000000 1012  6712                  Unknown( 122): GUID=44e91a30-0234-37f0-d2f9-777240b02428 (No Format Information found).

    <snip>

    1600/12/31 16:00:00.0000000 1012  6712                  Unknown( 123):
    2016/09/14 11:00:36.1814828 1012  2732  ComApi          *RESUMED* Search ClientId = UpdateOrchestrator
    2016/09/14 11:00:36.1818165 1012  2732  ComApi          Updates found = 0
    2016/09/14 11:00:36.1818172 1012  2732  ComApi          Exit code = 0x00000000, Result code = 0x8024500C
    2016/09/14 11:00:36.1818175 1012  2732  ComApi          * END *   Search ClientId = UpdateOrchestrator
    2016/09/14 11:00:36.1820774 1012  6712  ComApi          ISusInternal:: DisconnectCall failed, hr=8024000C
    2016/09/14 11:01:15.5677583 8344  8364  ComApi          * START *   Init Search ClientId = Update;taskhostw
    2016/09/14 11:01:15.5677623 8344  8364  ComApi          * START *   Search ClientId = Update;taskhostw
    1600/12/31 16:00:00.0000000 1012  1464                  Unknown( 23): GUID=6ec578f9-9c46-351d-5238-568542450649 (No Format Information found).

    <log notes repeat>

     

    We are having this exact same issue (and log results) as Patrick with our 1607 machines.

    they all have the correct info from our win update GPO in the registry, but seem to bypass our wsus server completely and are pulling directly from MS as soon as the updates were released..  we have the September CU installed and wsus server is fully patched as well..

    funny to see its thinking we were patching on 12/31/1600...


    Friday, September 16, 2016 4:06 PM
  • So I finally installed KB3189866 on my PC manually. Then searched for updates on WSUS and it found the KB3176936 and installed perfectly.

    Since I'm upgrading manually to anniversary update, it won't do much harm to install KB3189866 manually too.

    The strange thing is that on my two PC at home, KB3189866 hung at 45% download and kept for a long time... So I've downloaded it and installed normally.

    Strange things... hope that WSUS on 2008 SP2 works normally from now on.

    Friday, September 16, 2016 8:13 PM
  • So I finally installed KB3189866 on my PC manually. Then searched for updates on WSUS and it found the KB3176936 and installed perfectly.

    Since I'm upgrading manually to anniversary update, it won't do much harm to install KB3189866 manually too.

    Since this months patches came out my clients are updating to 10.0.14393.187 (KB3189866) through WSUS on 2012 R2.

    There were a handful of Windows 10 machines which were still stuck on 10.0.14393.105 (August Patch). Manually installing KB3189866 from Windows Update Catalog enabled them to fully update from WSUS. WUC requires Internet Explorer. You may need to add the site to Trusted Sites and enable Compatibility Mode also for download to succeed.

    Monday, September 19, 2016 6:11 AM
  • @Steve, there are numerous posts and other threads where people are reporting WSUS (client) failure to detect applicability for upgrade/update to 1607.

    Are you seeing this symptom? Are you seeing this as part of issue#2 or issue#3 ?

    Don, this should be resolved by now: we had some detection logic issues in the 1607 release.  If you're still seeing it, then please let me know what client platform/edition you're using, and whether it is set to Defer Upgrades.
    Tuesday, September 20, 2016 8:28 PM
    Moderator
  • Someone else in a different forum / thread figured out the issue with #3.

    --------------------------------

    In my case, problem was in  group policy setting: Windows components - Store - Turn off the offer to update to the latest version of Windows.

    Proposed as answer by Anne He Microsoft contingent staff, Moderator 5 hours 30 minutes ago

    ---------------------------------


    Eric S.


    Thanks for posting this.  We also updated the detection logic to ignore this Windows Store setting.  It should only apply to application--not system--updates.
    Tuesday, September 20, 2016 8:37 PM
    Moderator
  • Just some info that came to light this morning (In Summary checking Defer feature updates breaks wsus with 1607 - We unchecked it and everything works now)

    .. From our MS contact...

    As FYI, we are investigating an issue with the 1607 defer feature and quality updates policy... 

    It appears that if the new defer policy is set on 1607 devices then it overrides the preference for WSUS/SCCM as the source for updates and puts the device into a WUfB mode for all updates.  One of our TAP customers has therefore chosen to set the defer upgrades policy on 1511 but not on 1607 while we investigate - something you may want to consider on any 1607 devices where you want to manage security and quality updates.

    Tuesday, September 20, 2016 10:41 PM
  • For those seeing error 0xc1800118 because they synched Upgrades (feature updates) before applying KB3159706, and simply deleting the content did not repair the environment, we have published new guidance that details some additional steps required to reset your WSUS and affected clients: https://blogs.technet.microsoft.com/wsus/2016/09/21/resolving-error-0xc1800118/

    Thursday, September 22, 2016 1:23 AM
    Moderator
  • Just some info that came to light this morning (In Summary checking Defer feature updates breaks wsus with 1607 - We unchecked it and everything works now)

    .. From our MS contact...

    As FYI, we are investigating an issue with the 1607 defer feature and quality updates policy... 

    It appears that if the new defer policy is set on 1607 devices then it overrides the preference for WSUS/SCCM as the source for updates and puts the device into a WUfB mode for all updates.  One of our TAP customers has therefore chosen to set the defer upgrades policy on 1511 but not on 1607 while we investigate - something you may want to consider on any 1607 devices where you want to manage security and quality updates.

    Thank you for posting this!  I had both feature and quality policies set to be as fast as possible, but that indeed was causing WSUS to be bypassed completely.  Changing both of those back to 'Not Configured' and I no longer get the error I was receiving before.  Crossing my fingers that the next Cumulative update works through WSUS now.
    Thursday, September 22, 2016 4:51 AM
  • Just some info that came to light this morning (In Summary checking Defer feature updates breaks wsus with 1607 - We unchecked it and everything works now)

    .. From our MS contact...

    As FYI, we are investigating an issue with the 1607 defer feature and quality updates policy... 

    It appears that if the new defer policy is set on 1607 devices then it overrides the preference for WSUS/SCCM as the source for updates and puts the device into a WUfB mode for all updates.  One of our TAP customers has therefore chosen to set the defer upgrades policy on 1511 but not on 1607 while we investigate - something you may want to consider on any 1607 devices where you want to manage security and quality updates.

    I actually had to do the opposite to get CUs to work in 1607. I had to turn on deferred and I set it to 0.  Updates started working as they should. If I turn off deferred the hanging and service crashes happen.
    • Edited by DaBip Thursday, September 22, 2016 10:45 AM
    Thursday, September 22, 2016 10:31 AM
  • Just some info that came to light this morning (In Summary checking Defer feature updates breaks wsus with 1607 - We unchecked it and everything works now)

    .. From our MS contact...

    As FYI, we are investigating an issue with the 1607 defer feature and quality updates policy... 

    It appears that if the new defer policy is set on 1607 devices then it overrides the preference for WSUS/SCCM as the source for updates and puts the device into a WUfB mode for all updates.  One of our TAP customers has therefore chosen to set the defer upgrades policy on 1511 but not on 1607 while we investigate - something you may want to consider on any 1607 devices where you want to manage security and quality updates.

    Yes, there is a new feature in 1607 called Dual Scan that is intended to allow you to connect to Windows Update for Business and still get third-party/other updates from WSUS as needed.  This mode automatically goes into effect when WU for Business policy is enabled and the machine is configured to be managed by WSUS--we wanted to avoid creating a whole new policy for this scenario, so we used a combination of existing policies.

    The confusion came when folks were [reasonably] using the Defer Upgrades setting in a WSUS environment.  Running 1511, there is no impact; however, as soon as you upgrade to 1607 with these settings active, your machine begins scanning both WU and WSUS.

    In short, this is a known issue, and we'll be shipping a patch to the client to correct it.

    Thursday, September 22, 2016 10:35 PM
    Moderator
  • For those seeing error 0xc1800118 because they synched Upgrades (feature updates) before applying KB3159706, and simply deleting the content did not repair the environment, we have published new guidance that details some additional steps required to reset your WSUS and affected clients: https://blogs.technet.microsoft.com/wsus/2016/09/21/resolving-error-0xc1800118/


    Thank you so much, Steve, this KB - https://support.microsoft.com/en-us/kb/3194588 - has completely solved my issue.
    Friday, September 23, 2016 5:51 AM
  • For experience Scenario #3

    After patch/post, I added a line to the hosts file with IP, the short name and fqdn in the Windows client, that solved my problem. check dns and iis/bindings (i leave bindings as default).

    Friday, September 23, 2016 11:43 AM
  • I have been unable to complete the installation of the Anniversary update on a laptop and on a desktop. They both hung on reboot. Two attempts on the latptop, two attemps on desktop. The desktop attempt was stuck for 7 hours 50 minutes before I did two hard restarts to restore the old version. I have spent enough time on both of these, Microsoft. I don't want to have to do any workarounds. I just want and need you to give updates that actually work. Seriously. Poor Microsoft deployment adversely affects the productivity in many countries from people having to take hours and hours to try to update only to figure out that it is not working. This has been a serious disruption to my work time. Please get it fixed.
    Friday, September 23, 2016 2:33 PM
  • @Steve

    I'm experiencing Issue #3. Just for fun, I ran the query in KB3194588. The results are below:

    Changed database context to 'SUSDB'.
    TotalResults
    ------------
               0

    Next, I did this --> del %windir%\SoftwareDistribution\DataStore\*

    on the client PC, after stopping the service.

    The PC's download other updates like defender updates and cumulative updates to 1511. When trying to download the feature update to 1607, it just sets at 0% downloading.

    Any update on when this issue may be resolved?

    Thanks.


    BradG87

    Friday, September 23, 2016 2:40 PM
  • This sounded like the silver bullet solution to our problem at first, but I checked and we don't have any GPO's configured to defer updates.  Both feature/quality are set to "not configured".  Nevertheless, all our 1607 boxes endlessly pound our firewall trying to download updates, while being stuck at 45% and ignoring our WSUS server.  We've had to block access to IP 13.107.4.50 to prevent these machines from consuming all our bandwidth. 
    Friday, September 23, 2016 3:28 PM
  • I have same problem too, I don't want go to manually install the KB3189866 , Because there are a lot of clents and it's can't access internet, please help me to fix this.

    Thanks.

    Monday, September 26, 2016 9:34 AM
  • So then Microsoft, whats being done? Not a single client on my Domain will update via WSUS. Currently stuck trying to download a defender updates for September and can't. Its effected every update coming out of WSUS fo our Windows 10 clients.

    The only way around this that i have found is to remove all windows 10 clients from the WSUS GPO so they download and install direct from Windows Update.


    Monday, September 26, 2016 12:45 PM
  • Same problem here

    https://answers.microsoft.com/en-us/windows/forum/windows_10-performance/windows-10-1607-not-detectingupdate-via-wsus/ca20460b-60d6-47b5-a22e-8353ea5a2624

    No progress yet...


    Dimmy Shu

    Monday, September 26, 2016 4:01 PM
  • @Steve

    I'm experiencing Issue #3. Just for fun, I ran the query in KB3194588. The results are below:

    Changed database context to 'SUSDB'.
    TotalResults
    ------------
               0

    Next, I did this --> del %windir%\SoftwareDistribution\DataStore\*

    on the client PC, after stopping the service.

    The PC's download other updates like defender updates and cumulative updates to 1511. When trying to download the feature update to 1607, it just sets at 0% downloading.

    Any update on when this issue may be resolved?

    Thanks.


    BradG87


    Brad, I didn't see that you removed the upgrades (feature updates) you originally downloaded to your WSUS before patching.  Did you perform this step?  If you're savvy with SQL, then you can check the tbFiles table for the corresponding file digest and determine whether the IsEncrypted and IsSecure attributes are present.  If they are not, then the upgrade will not be deployed correctly.
    Monday, September 26, 2016 9:50 PM
    Moderator
  • This sounded like the silver bullet solution to our problem at first, but I checked and we don't have any GPO's configured to defer updates.  Both feature/quality are set to "not configured".  Nevertheless, all our 1607 boxes endlessly pound our firewall trying to download updates, while being stuck at 45% and ignoring our WSUS server.  We've had to block access to IP 13.107.4.50 to prevent these machines from consuming all our bandwidth. 

    You might have the underlying registry keys somehow being set.  As an experiment, try setting "not configured" to "disabled" instead, and confirm that your clients do still have the GPO pointing to a WSUS server.

    Additionally, there is a GPO that blocks non-WSUS access on the client side.  You might consider using that until you figure out the root cause, so that your firewalls can do less work there.

    Monday, September 26, 2016 9:53 PM
    Moderator
  • So then Microsoft, whats being done? Not a single client on my Domain will update via WSUS. Currently stuck trying to download a defender updates for September and can't. Its effected every update coming out of WSUS fo our Windows 10 clients.

    The only way around this that i have found is to remove all windows 10 clients from the WSUS GPO so they download and install direct from Windows Update.


    If you're talking about the "0% downloading from WSUS" issue, then we've shipped a patch to address this on the client.  Have you installed the September cumulative update on your Win10 clients?

    If you're asking about how to actually get this update without pointing to Windows Update, then you can manually download the package from Catalog and share it on a network to distribute to the rest of your clients.  We recommend this only if temporarily pointing to Windows Update is an issue for you.

    You shouldn't have to remove clients from the WSUS GPO--just modify it to disable the "Specify intranet URL..." policy, push that via gpupdate, get the package, and then switch the policy back.

    Monday, September 26, 2016 9:58 PM
    Moderator
  • Same problem here

    https://answers.microsoft.com/en-us/windows/forum/windows_10-performance/windows-10-1607-not-detectingupdate-via-wsus/ca20460b-60d6-47b5-a22e-8353ea5a2624

    No progress yet...


    Dimmy Shu


    This is unrelated to the 0xc1800118 or "0% download" errors reported by others.  Detection logic is not determined by WSUS, so this is likely either a publishing problem or a misconfiguration somewhere in the deployment chain or its endpoints.
    Monday, September 26, 2016 10:00 PM
    Moderator
  • I am having a related issue, can someone point to a thread where I might find a solution:  All of our Windows 10 clients are bypassing WSUS and downloading all of their content from the Internet.  All clients are reporting their status to WSUS but seem to be ignoring the intent of downloading updates from the local WSUS server.
    Tuesday, September 27, 2016 1:14 PM
  • @Steve

    Steve, thanks for the response. It is greatly appreciated. As you suggested, I have looked in the database and found the IsEncrypted and IsSecure attributes are set to 1 for the 1607 update. Is that what they should be? If so, what is our next step? My machines still set at 0% downloading.

    Thanks,

    Brad


    BradG87

    Tuesday, September 27, 2016 1:23 PM
  • Checked HKLM\software\policies\Microsoft\windows\windowsupdate and "deferupgrade" is set to 0.

    We tried the GPO option to block all access to MS update, but that just causes affected win 10 computers to throw a windows update error instead and breaks access to the MS Store-- it still ignores it's WSUS settings.


    Tuesday, September 27, 2016 6:59 PM
  • @Steve

    Steve, thanks for the response. It is greatly appreciated. As you suggested, I have looked in the database and found the IsEncrypted and IsSecure attributes are set to 1 for the 1607 update. Is that what they should be? If so, what is our next step? My machines still set at 0% downloading.

    Thanks,

    Brad


    BradG87

    Yes, both attributes should be set to 1 for the 1607 update.  Next step is to review your WU client logs and see whether any errors are reported during the download phase.  If so, then please post the excerpt containing that error--for everyone's sake, don't include the entire log, since that's too much to parse effectively.

    As a side question, is it all your machines that are stuck at 0%?  Some of them?  Only those running 1511?  Knowing the scope of affected platforms in your environment may be useful in pinpointing the root cause.

    Tuesday, September 27, 2016 9:25 PM
    Moderator
  • Checked HKLM\software\policies\Microsoft\windows\windowsupdate and "deferupgrade" is set to 0.

    We tried the GPO option to block all access to MS update, but that just causes affected win 10 computers to throw a windows update error instead and breaks access to the MS Store-- it still ignores it's WSUS settings.



    Do you have an OMADM provider in your environment?  What is the value of RequireDeferUpgrade?  And you've reconfirmed that your WSUS URL is present and valid, and that the policy is still enabled?
    Tuesday, September 27, 2016 9:29 PM
    Moderator
  • I am having a related issue, can someone point to a thread where I might find a solution:  All of our Windows 10 clients are bypassing WSUS and downloading all of their content from the Internet.  All clients are reporting their status to WSUS but seem to be ignoring the intent of downloading updates from the local WSUS server.

    Search for "Dual Scan" in this thread for an explanation as to what's happening here.
    Tuesday, September 27, 2016 9:30 PM
    Moderator
  • Steve,

    Very confused here. You mention that you patched the 0% issue. I am getting this will all our Windows 10 clients running 1607, all manually updated with the latest cumulative updates and service stacks. Client are all reporting to WSUS, locating the updates required but seemingly unable to download an install them.

    Today I have an issue with: 

    Security Update for Adobe Flash Player for Windows 10 Version 1607 for x64-based Systems (KB3188128)

    Reports failed to install and sits at 0%

    Thanks

    Craig


    • Edited by TowelsRus Wednesday, September 28, 2016 1:37 PM
    Wednesday, September 28, 2016 1:36 PM
  • @Steve

    I have not put all machines in the domain in the group to install the 1607 update but the ones that I have are experiencing the issue of stuck at 0% downloading. It is only machines running 1511 that are having the issue. They install other updates without issue. Below is the only information I have found in the client log that looks relevant. I don't see any errors in the client log.

    On the WSUS server, I see the following when I run a report on the Upgrade and looked at the failed status of a PC:

    WSUS:

    Feature update to Windows 10 Pro, version 1607, en-us, Retail
    Event reported at 9/23/2016 10:04 AM:
    (Unable to Find Resource:) ReportingEvent.Client.167; Parameters: Feature update to Windows 10 Pro, version 1607, en-us, Retail

    Client Log:


    BradG87


    • Edited by BradG87 Friday, September 30, 2016 2:43 PM Added Detail.
    Wednesday, September 28, 2016 5:07 PM
  • Ms just released KB3194496 https://support.microsoft.com/en-us/kb/3194496

    there seem to be remarks about Windows Update Agent and Windows Update for Business.

    • Improved reliability of the Windows Update Agent,...
    • Addressed additional issues with multimedia, Windows kernel,....Windows Update for Business..

    Lets hope this the one that fixes 1607 and WSUS. to be legit, we will have to wait till next month to be sure.

    Friday, September 30, 2016 7:57 PM
  • We use Airwatch, but only for mobile phones, not PC's.

    We have no "requiredeferupgrade" reg key, only deferupgrade=0 under the WindowsUpdate hive. 

    WSUS URL is correct, and these PC's DO download Windows Defender definitions from our WSUS server. 

    This issue only effects Windows 10, version 1607 PC's.  All other OS versions behave properly and download everything from WSUS

    This morning, despite these PC's being fully patches with all critical and recommended updates, they are still endlessly downloading something to the softwaredistribution folder from 13.107.4.50.  It is ALWAYS this IP address.

    Monday, October 3, 2016 3:57 PM
  • @Steve,

    I wiped my WSUS server and started over. I am still experiencing issue 3. My clients get stuck at 0% downloading the 1607 upgrade. I don't see any errors in the client logs. On the WSUS side, I am still getting unable to find resource, same as on the old server as shown in earlier posts.

    Is Microsoft working on this issue? Are we on our own?


    BradG87

    Wednesday, October 5, 2016 1:56 PM
  • Hi Brad,

    do the clients have the following key set?

    o HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate – DeferUpgrade

    Best regards,

    Andrei


    We could change the world, if God would give us the source code.

    Thursday, October 6, 2016 7:10 AM
  • Hi Brad,

    You need to tweak the Windows Update Delivery Optimization, you can manuel turn off the peer search under Advanced setting in the Windows Update GUI or by GPO.

    https://blogs.technet.microsoft.com/mniehaus/2016/08/16/windows-10-delivery-optimization-and-wsus-take-2/

    After you stopped the search for peers, then you your upgrade will start installing.


    • Edited by NIJO123 Thursday, October 6, 2016 12:00 PM misspell
    Thursday, October 6, 2016 8:08 AM
  • Hi,

    Thanks for the suggestion but they do not have that key set. Also, in group policy, it is not configured.

    Thanks,
    Brad


    BradG87

    Thursday, October 6, 2016 1:00 PM
  • NIJO123,

    Thanks for the suggestion but I have already tried several different settings for the delivery optimization and nothing has made a difference.

    Thanks,

    Brad


    BradG87

    Thursday, October 6, 2016 1:10 PM
  • I also have issue 3.  I've configured the deferred setting as well as the peer search.  I've disabled those policies - just to confirm, I probably just need to overwrite those policies to actually get peer search and deferred settings turned off on all my windows 10 machines correct?

    Edit:  Nevermind, looks like disabling is all I needed to do.  PCs are starting to show up that they need that upgrade.

    • Edited by bguy_1986 Thursday, October 6, 2016 5:21 PM update
    Thursday, October 6, 2016 4:52 PM
  • Bguy_1986,

    Is the update downloading and installing for you? The issue I have is it will not download. It sits at 0% downloading. Nothing I have tried has made a difference, including building a new WSUS server from scratch.


    BradG87

    Thursday, October 6, 2016 5:59 PM
  • Nope, now I have that same issue as you. Stuck at 0%.
    Thursday, October 6, 2016 8:20 PM
  • Brad,

    Have you tried this?

    http://windows-update-checker.com/FAQ/Windows%2010%201607%20upgrade%20fails%20via%20WSUS%20with%20error%20code%200x80244019.htm

    I'm going to give it a try tomorrow.  I'm trying to find an old link I had where they had you add both an .msu and .esd mime type to iis.  If I'm understanding things correctly, (and I'm probably not), one of the previous updates was supposed to do this for us.


    • Edited by bguy_1986 Friday, October 7, 2016 12:52 PM
    Thursday, October 6, 2016 8:32 PM
  • That seems like it fixed the problem!  Clients are now downloading the update!  Now I need to check and see what MDT is doing.

    EDIT:  I spoke too soon.  1607 downloads and installs, but updates afterwards won't download.  I've added .msu to IIS as I have read that it has fixed it on another thread.

    https://social-technetb-msft-us1.vtv.stillw.com/Forums/windows/en-US/9941646e-648d-49e2-97a4-088e5cc0d917/windows-10-1607-stuck-when-downloading-updates-from-wsus-in-mdt-windows-update-task-sequence?forum=win10itprosetup

    Why is this so hard?

    • Edited by bguy_1986 Friday, October 7, 2016 1:29 PM
    Friday, October 7, 2016 12:53 PM
  • That seems like it fixed the problem!  Clients are now downloading the update!  Now I need to check and see what MDT is doing.

    EDIT:  I spoke too soon.  1607 downloads and installs, but updates afterwards won't download.  I've added .msu to IIS as I have read that it has fixed it on another thread.

    https://social-technetb-msft-us1.vtv.stillw.com/Forums/windows/en-US/9941646e-648d-49e2-97a4-088e5cc0d917/windows-10-1607-stuck-when-downloading-updates-from-wsus-in-mdt-windows-update-task-sequence?forum=win10itprosetup

    Why is this so hard?

    It's hard because you (and BradG87) are actually running into the same symptom from two different root causes:

    1. On 1511, you're seeing 0% downloaded--this is NOT a known issue, though it appears that your earlier suggestion might have resolved this.  Only you can confirm.
    2. On 1607 (after successful upgrade), you're seeing 0% downloaded--this IS a known issue, and it is patched on the WU client with the September monthly update.

    From what I can tell from your post, you're actually making progress, even if it feels like you're not.  Remember that 1511 is having trouble with the content classified as Upgrades, while 1607 is having trouble with Updates and Security Updates.

    Saturday, October 8, 2016 1:19 AM
    Moderator
  • In SBS 2011, WSUS was not getting 1607, so I manually had the W10 clients check for updates direct from Microsoft, which worked for getting them updated. But then, non of the workstations were able to install further updates. I noticed that all of them were trying to get CU KB3189866. However, it no longer seems to be in the catalog, but searching Microsoft support lead me to the