none
1703 distributed, clients now cannot contact WSUS anymore

    Question

  • Hi

    I started distributing 1703 from our WSUS - worked fine with 1607 last year.
    Download seemed to work, 2 clients updated and now run 1703. However, on WSUS their last report is before the update and they seem not to be able to contact WSUS anymore and return various errors if I try manually.

    Running the option to check from MS Update downloaded new updates and seems to work.

    How do I fix this so that clients can connect to our WSUS?
    WSUS runs on a fully patched Server 2012 R2.

    Thanks
    McL


    • Edited by McLion Wednesday, April 19, 2017 7:00 AM
    Tuesday, April 18, 2017 4:01 PM

Answers

  • OK, fixed mine :-)

    I created a completely new SUSDB and Content store. That was the only way to start from scratch since remove and reinstall of WSUS did not work due to some known reasons MSFT screwed up. What caused W10 1703 not to update anymore .. I'll probably never know ... but it works now.

    Here's a guide how to do this: Recreating the SUSDB ..
    It takes quite some time (hours) for the first sync with the new DB .. be patient.

    Some things to keep in mind:
    - Before syncing the Upgrades Category to the new WSUS make sure to have KB3095113 and KB3159706 (including manual postinstall steps) installed and configured.
    - The new WSUS will not use SSL. If you have directed your clients to use SSL by GPO you need to reconfigure the webservice and WSUS for SSL as described here or they can not contact anymore - either change and propagate the GPO or (recommended) re-engage SSL on the server.

    Good luck.
    McL


    • Marked as answer by McLion Thursday, May 25, 2017 12:20 PM
    • Edited by McLion Monday, June 26, 2017 2:55 PM
    Thursday, May 25, 2017 12:20 PM

All replies

  • Hi McLion,

    According to your description, after the clients upgrade to windows 10 1703, it unable to update from the WSUS server any more.

    I tested in my lab, while in my lab, win10 1703 (which also upgrade via WSUS) didn't meet issue update from WSUS server after upgrading:

    Then, please check the windows update log on the Windows 10 1703, check if there are errors when checking updates from the WSUS server. Also enable the IIS log on the WSUS server, check if the WSUS site could receive the request from the clients.

    Best Regards,

    Anne


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

    Wednesday, April 19, 2017 6:30 AM
    Moderator
  • I uploaded a excerpt of a a log which contains a manually initiated run that ended with error 0x8024000d on the client.

    Please check the log here: https://drive.google.com/file/d/0B0-uHoXxE6ihRUMwLThYeXZKNm8/view?usp=sharing

    Thanks

    McL


    • Edited by McLion Wednesday, April 19, 2017 8:30 AM
    Wednesday, April 19, 2017 8:29 AM
  • Logs from server:

    New W10 1703 client (excerpt):

    2017-04-19 15:33:01 192.168.1.2 POST /SimpleAuthWebService/SimpleAuth.asmx - 8530 - 192.168.1.215 Windows-Update-Agent/10.0.10011.16384+Client-Protocol/1.58 - 200 0 0 257
    2017-04-19 15:33:11 192.168.1.2 POST /ClientWebService/client.asmx - 8530 - 192.168.1.215 Windows-Update-Agent/10.0.10011.16384+Client-Protocol/1.58 - 200 0 0 9185
    2017-04-19 15:33:12 192.168.1.2 POST /ClientWebService/client.asmx - 8530 - 192.168.1.215 Windows-Update-Agent/10.0.10011.16384+Client-Protocol/1.58 - 200 0 0 108
    2017-04-19 15:33:12 192.168.1.2 POST /ClientWebService/client.asmx - 8530 - 192.168.1.215 Windows-Update-Agent/10.0.10011.16384+Client-Protocol/1.58 - 200 0 0 30
    2017-04-19 15:33:14 192.168.1.2 POST /ClientWebService/client.asmx - 8530 - 192.168.1.215 Windows-Update-Agent/10.0.10011.16384+Client-Protocol/1.58 - 200 0 0 53
    2017-04-19 15:33:14 192.168.1.2 POST /ClientWebService/client.asmx - 8530 - 192.168.1.215 Windows-Update-Agent/10.0.10011.16384+Client-Protocol/1.58 - 200 0 0 237
    2017-04-19 15:34:10 192.168.1.2 POST /ClientWebService/client.asmx - 8530 - 192.168.1.215 Windows-Update-Agent/10.0.10011.16384+Client-Protocol/1.58 - 200 0 0 61
    2017-04-19 15:34:10 192.168.1.2 POST /ClientWebService/client.asmx - 8530 - 192.168.1.215 Windows-Update-Agent/10.0.10011.16384+Client-Protocol/1.58 - 200 0 0 13
    2017-04-19 15:34:12 192.168.1.2 POST /ClientWebService/client.asmx - 8530 - 192.168.1.215 Windows-Update-Agent/10.0.10011.16384+Client-Protocol/1.58 - 200 0 0 5
    2017-04-19 15:34:12 192.168.1.2 POST /ClientWebService/client.asmx - 8530 - 192.168.1.215 Windows-Update-Agent/10.0.10011.16384+Client-Protocol/1.58 - 200 0 0 4
    2017-04-19 15:38:34 fe80::71ed:5269:dcf:13ef%20 GET /selfupdate/iuident.cab - 8530 - fe80::71ed:5269:dcf:13ef%20 - - 200 0 0 3
    2017-04-19 15:38:34 fe80::71ed:5269:dcf:13ef%20 POST /reportingwebservice/reportingwebservice.asmx - 8530 - fe80::71ed:5269:dcf:13ef%20 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.42000) - 200 0 0 318
    2017-04-19 15:38:36 fe80::71ed:5269:dcf:13ef%20 POST /ApiRemoting30/WebService.asmx - 8530 NORFOLK\SERVER2$ fe80::71ed:5269:dcf:13ef%20 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.42000) - 200 0 0 1515
    2017-04-19 15:38:43 fe80::71ed:5269:dcf:13ef%20 POST /ServerSyncWebService/serversyncwebservice.asmx - 8530 - fe80::71ed:5269:dcf:13ef%20 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.42000) - 200 0 0 6735
    2017-04-19 15:38:43 fe80::71ed:5269:dcf:13ef%20 POST /ClientWebService/Client.asmx - 8530 - fe80::71ed:5269:dcf:13ef%20 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.42000) - 200 0 0 10
    2017-04-19 15:38:43 fe80::71ed:5269:dcf:13ef%20 POST /SimpleAuthWebService/SimpleAuth.asmx - 8530 - fe80::71ed:5269:dcf:13ef%20 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.42000) - 200 0 0 7
    2017-04-19 15:38:43 fe80::71ed:5269:dcf:13ef%20 POST /DssAuthWebService/DssAuthWebService.asmx - 8530 - fe80::71ed:5269:dcf:13ef%20 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.42000) - 200 0 0 205
    2017-04-19 15:38:43 fe80::71ed:5269:dcf:13ef%20 GET /Content/anonymousCheckFile.txt - 8530 - fe80::71ed:5269:dcf:13ef%20 - - 200 0 0 4
    2017-04-19 15:38:58 fe80::71ed:5269:dcf:13ef%20 POST /ReportingWebService/ReportingWebService.asmx - 8530 - fe80::71ed:5269:dcf:13ef%20 Windows-Update-Agent/7.9.9600.18628+Client-Protocol/1.21 - 200 0 0 252
    2017-04-19 15:42:00 192.168.1.2 POST /ReportingWebService/ReportingWebService.asmx - 8530 - 192.168.1.215 Windows-Update-Agent/10.0.10011.16384+Client-Protocol/1.58 - 200 0 0 44
    2017-04-19 15:48:43 fe80::71ed:5269:dcf:13ef%20 GET /selfupdate/iuident.cab - 8530 - fe80::71ed:5269:dcf:13ef%20 - - 200 0 0 1
    2017-04-19 15:48:43 fe80::71ed:5269:dcf:13ef%20 POST /reportingwebservice/reportingwebservice.asmx - 8530 - fe80::71ed:5269:dcf:13ef%20 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.42000) - 200 0 0 1
    2017-04-19 15:48:43 fe80::71ed:5269:dcf:13ef%20 POST /ApiRemoting30/WebService.asmx - 8530 NORFOLK\SERVER2$ fe80::71ed:5269:dcf:13ef%20 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.42000) - 200 0 0 2
    2017-04-19 15:48:43 fe80::71ed:5269:dcf:13ef%20 POST /ServerSyncWebService/serversyncwebservice.asmx - 8530 - fe80::71ed:5269:dcf:13ef%20 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.42000) - 200 0 0 2
    2017-04-19 15:48:43 fe80::71ed:5269:dcf:13ef%20 POST /ClientWebService/Client.asmx - 8530 - fe80::71ed:5269:dcf:13ef%20 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.42000) - 200 0 0 9
    2017-04-19 15:48:43 fe80::71ed:5269:dcf:13ef%20 POST /SimpleAuthWebService/SimpleAuth.asmx - 8530 - fe80::71ed:5269:dcf:13ef%20 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.42000) - 200 0 0 2
    2017-04-19 15:48:43 fe80::71ed:5269:dcf:13ef%20 POST /DssAuthWebService/DssAuthWebService.asmx - 8530 - fe80::71ed:5269:dcf:13ef%20 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.42000) - 200 0 0 1
    2017-04-19 15:48:43 fe80::71ed:5269:dcf:13ef%20 GET /Content/anonymousCheckFile.txt - 8530 - fe80::71ed:5269:dcf:13ef%20 - - 200 0 0 1
    2017-04-19 15:58:43 fe80::71ed:5269:dcf:13ef%20 GET /selfupdate/iuident.cab - 8530 - fe80::71ed:5269:dcf:13ef%20 - - 200 0 0 0
    2017-04-19 15:58:43 fe80::71ed:5269:dcf:13ef%20 POST /reportingwebservice/reportingwebservice.asmx - 8530 - fe80::71ed:5269:dcf:13ef%20 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.42000) - 200 0 0 2
    2017-04-19 15:58:43 fe80::71ed:5269:dcf:13ef%20 POST /ApiRemoting30/WebService.asmx - 8530 NORFOLK\SERVER2$ fe80::71ed:5269:dcf:13ef%20 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.42000) - 200 0 0 3
    2017-04-19 15:58:43 fe80::71ed:5269:dcf:13ef%20 POST /ServerSyncWebService/serversyncwebservice.asmx - 8530 - fe80::71ed:5269:dcf:13ef%20 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.42000) - 200 0 0 3
    2017-04-19 15:58:43 fe80::71ed:5269:dcf:13ef%20 POST /ClientWebService/Client.asmx - 8530 - fe80::71ed:5269:dcf:13ef%20 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.42000) - 200 0 0 2
    2017-04-19 15:58:43 fe80::71ed:5269:dcf:13ef%20 POST /SimpleAuthWebService/SimpleAuth.asmx - 8530 - fe80::71ed:5269:dcf:13ef%20 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.42000) - 200 0 0 3
    2017-04-19 15:58:43 fe80::71ed:5269:dcf:13ef%20 POST /DssAuthWebService/DssAuthWebService.asmx - 8530 - fe80::71ed:5269:dcf:13ef%20 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.42000) - 200 0 0 2
    2017-04-19 15:58:43 fe80::71ed:5269:dcf:13ef%20 GET /Content/anonymousCheckFile.txt - 8530 - fe80::71ed:5269:dcf:13ef%20 - - 200 0 0 0

    And this is how it looks when a W7 client successfully connects (excerpt):

    2017-04-20 05:05:05 192.168.1.2 HEAD /selfupdate/wuident.cab 1704200505 8530 - 192.168.1.175 Windows-Update-Agent - 200 0 0 61
    2017-04-20 05:05:05 192.168.1.2 HEAD /selfupdate/WSUS3/x64/Win7SP1/wsus3setup.cab 1704200505 8530 - 192.168.1.175 Windows-Update-Agent - 200 0 0 203
    2017-04-20 05:05:05 192.168.1.2 POST /SimpleAuthWebService/SimpleAuth.asmx - 8530 - 192.168.1.175 Windows-Update-Agent - 200 0 0 10
    2017-04-20 05:05:05 192.168.1.2 POST /ClientWebService/client.asmx - 8530 - 192.168.1.175 Windows-Update-Agent - 200 0 0 211
    2017-04-20 05:05:08 192.168.1.2 POST /ClientWebService/client.asmx - 8530 - 192.168.1.175 Windows-Update-Agent - 200 0 0 845
    2017-04-20 05:05:11 192.168.1.2 POST /ClientWebService/client.asmx - 8530 - 192.168.1.175 Windows-Update-Agent - 200 0 0 2202
    2017-04-20 05:05:13 192.168.1.2 POST /ClientWebService/client.asmx - 8530 - 192.168.1.175 Windows-Update-Agent - 200 0 0 84
    2017-04-20 05:05:13 192.168.1.2 POST /ClientWebService/client.asmx - 8530 - 192.168.1.175 Windows-Update-Agent - 200 0 0 224
    2017-04-20 05:05:36 192.168.1.2 POST /ClientWebService/client.asmx - 8530 - 192.168.1.175 Windows-Update-Agent - 200 0 0 14
    2017-04-20 05:05:36 192.168.1.2 POST /ClientWebService/client.asmx - 8530 - 192.168.1.175 Windows-Update-Agent - 200 0 0 30
    2017-04-20 05:05:36 192.168.1.2 HEAD /Content/78/08FF019BF5D8CF8D65347B4F4A0D76FE77436678.cab - 8530 - 192.168.1.175 Windows-Update-Agent - 200 0 0 19
    2017-04-20 05:05:36 192.168.1.2 HEAD /Content/78/08FF019BF5D8CF8D65347B4F4A0D76FE77436678.cab - 8530 - 192.168.1.175 Microsoft+BITS/7.5 - 200 0 0 33
    2017-04-20 05:05:36 192.168.1.2 POST /ClientWebService/client.asmx - 8530 - 192.168.1.175 Windows-Update-Agent - 200 0 0 215
    2017-04-20 05:05:36 192.168.1.2 HEAD /Content/6F/F46A1589C61418B3574CF22B8FB1954E54FFB36F.cab - 8530 - 192.168.1.175 Windows-Update-Agent - 200 0 0 232
    2017-04-20 05:05:41 192.168.1.2 GET /Content/78/08FF019BF5D8CF8D65347B4F4A0D76FE77436678.cab - 8530 - 192.168.1.175 Microsoft+BITS/7.5 - 206 0 0 2
    2017-04-20 05:05:45 192.168.1.2 GET /Content/78/08FF019BF5D8CF8D65347B4F4A0D76FE77436678.cab - 8530 - 192.168.1.175 Microsoft+BITS/7.5 - 206 0 0 1
    2017-04-20 05:05:47 192.168.1.2 GET /Content/78/08FF019BF5D8CF8D65347B4F4A0D76FE77436678.cab - 8530 - 192.168.1.175 Microsoft+BITS/7.5 - 206 0 0 2
    2017-04-20 05:05:48 192.168.1.2 GET /Content/78/08FF019BF5D8CF8D65347B4F4A0D76FE77436678.cab - 8530 - 192.168.1.175 Microsoft+BITS/7.5 - 206 0 0 1
    2017-04-20 05:05:49 192.168.1.2 GET /Content/78/08FF019BF5D8CF8D65347B4F4A0D76FE77436678.cab - 8530 - 192.168.1.175 Microsoft+BITS/7.5 - 206 0 0 2
    2017-04-20 05:05:50 192.168.1.2 GET /Content/78/08FF019BF5D8CF8D65347B4F4A0D76FE77436678.cab - 8530 - 192.168.1.175 Microsoft+BITS/7.5 - 206 0 0 4
    2017-04-20 05:05:52 192.168.1.2 GET /Content/78/08FF019BF5D8CF8D65347B4F4A0D76FE77436678.cab - 8530 - 192.168.1.175 Microsoft+BITS/7.5 - 206 0 0 716
    2017-04-20 05:05:52 192.168.1.2 GET /Content/78/08FF019BF5D8CF8D65347B4F4A0D76FE77436678.cab - 8530 - 192.168.1.175 Microsoft+BITS/7.5 - 206 0 0 217
    2017-04-20 05:05:53 192.168.1.2 GET /Content/78/08FF019BF5D8CF8D65347B4F4A0D76FE77436678.cab - 8530 - 192.168.1.175 Microsoft+BITS/7.5 - 206 0 0 14
    2017-04-20 05:05:53 192.168.1.2 HEAD /Content/78/08FF019BF5D8CF8D65347B4F4A0D76FE77436678.cab - 8530 - 192.168.1.175 Windows-Update-Agent - 200 0 0 1
    2017-04-20 05:05:53 192.168.1.2 HEAD /Content/78/08FF019BF5D8CF8D65347B4F4A0D76FE77436678.cab - 8530 - 192.168.1.175 Windows-Update-Agent - 200 0 0 42
    2017-04-20 05:05:53 192.168.1.2 GET /Content/6F/F46A1589C61418B3574CF22B8FB1954E54FFB36F.cab - 8530 - 192.168.1.175 Microsoft+BITS/7.5 - 206 0 0 50
    2017-04-20 05:05:54 192.168.1.2 HEAD /Content/6F/F46A1589C61418B3574CF22B8FB1954E54FFB36F.cab - 8530 - 192.168.1.175 Microsoft+BITS/7.5 - 200 0 0 233
    2017-04-20 05:05:54 192.168.1.2 GET /Content/6F/F46A1589C61418B3574CF22B8FB1954E54FFB36F.cab - 8530 - 192.168.1.175 Microsoft+BITS/7.5 - 206 0 0 51
    2017-04-20 05:05:56 192.168.1.2 GET /Content/6F/F46A1589C61418B3574CF22B8FB1954E54FFB36F.cab - 8530 - 192.168.1.175 Microsoft+BITS/7.5 - 206 0 0 373
    2017-04-20 05:05:56 192.168.1.2 GET /Content/6F/F46A1589C61418B3574CF22B8FB1954E54FFB36F.cab - 8530 - 192.168.1.175 Microsoft+BITS/7.5 - 206 0 0 308
    2017-04-20 05:05:59 192.168.1.2 GET /Content/6F/F46A1589C61418B3574CF22B8FB1954E54FFB36F.cab - 8530 - 192.168.1.175 Microsoft+BITS/7.5 - 206 0 0 779


    • Edited by McLion Thursday, April 20, 2017 2:25 PM
    Thursday, April 20, 2017 8:25 AM
  • A couple months ago, we found our Windows 10 boxes could no longer download updates from WSUS.  Out of the blue, it became necessary to set the "alternate download server" value in the Group Policy that specifies the WSUS server.  This "alternate" field only became available recently.  I think if you set it, you will find that your updates start working again.

    Computer Configuration\Policies\Administrative Templates\Windows Components\Windows Update\Specify intranet Microsoft update service location

    I set all three values (update service, statistics, and alternate) to the same value and things started working again.

    • Proposed as answer by BriReyEDU Friday, April 21, 2017 3:43 PM
    • Unproposed as answer by McLion Monday, May 15, 2017 2:01 PM
    • Proposed as answer by Damon B Wednesday, May 17, 2017 6:42 PM
    • Unproposed as answer by McLion Thursday, May 18, 2017 7:41 AM
    Thursday, April 20, 2017 4:40 PM
  • I don't have that option available. Do I need to update the GPO templates on the server?
    Thursday, April 20, 2017 4:48 PM
  • I don't have that option available. Do I need to update the GPO templates on the server?
    It shows up for me when I install Group Policy Management on a Windows 10 1607 build that is a member of the domain.  But otherwise, yes, I would assume that updating the templates is another way to go.  There's a certain way to do that though, so research it appropriately.  I don't think you can/should throw them around willy-nilly.  =P
    Thursday, April 20, 2017 5:03 PM
  • OK, got that option. I updated the templates on the server and now got it and also configured it.
    I double-checked on the clients and they get the reg entry.

    Still, all our W10 1703 clients can not contact WSUS anymore.

    I really need a fix for this mess MS created. Before W10, WSUS worked a treat for years and now it's absolutely unreliable in when updates are installed on W10 clients up to a total loss of it's functionality like now with W10 1703.
    Tuesday, April 25, 2017 8:02 AM
  • We had the same issue with WSUS on Windows Server 2016. We have updated Windows Server 2016 with the latest patches and we can now manage Windows 10 1703 clients. 


    MCSE, MCSA, MS, MCP, MCTS, System Engineer

    Tuesday, April 25, 2017 12:18 PM
  • There are no updates available for the Server 2012 R2 - fully patched by MU direct.
    Tuesday, April 25, 2017 12:26 PM
  • Would you mind posting your WindowsUpdate-GPO settings?
    Tuesday, April 25, 2017 12:27 PM
  • No special setting in GPO. I'm quite sure that this is related to the WSUS version.


    MCSE, MCSA, MS, MCP, MCTS, System Engineer

    Tuesday, April 25, 2017 5:17 PM
  • Thanks.
    Still at loss. Rebooted the server last night .. no change. It shows to be fully updated.
    So, I have no clue what to change/try next.

    Wednesday, April 26, 2017 2:30 PM
  • Will try to test with Windows Server 2012 R2 tomorrow. Will let you know how it goes.

    MCSE, MCSA, MS, MCP, MCTS, System Engineer

    Wednesday, April 26, 2017 9:00 PM
  • Thanks a lot for your help!
    Thursday, April 27, 2017 6:46 AM
  • I found that KB4013214, which seems to be needed for W10 1703, is not on my WSUS. Therefore none of the clients did have it before WSUS distributed W10 1703 to them. There seems to be a bug in the detection logic.

    I found a download fro this KB but I can not install it - dism returns error 87.

    There seem to be various threads with the same issue - would be nice if someone from MS could jump in here.


    • Edited by McLion Thursday, April 27, 2017 5:40 PM
    Thursday, April 27, 2017 5:40 PM
  • KB4013214 is a prerequisite for Windows 10 Creators Update. The update is not for WSUS itself.

    I'm still testing WSUS 2012 r2 and it looks like I'm experiencing the same issue. The Client is not reporting to WSUS. Will keep you posted.


    MCSE, MCSA, MS, MCP, MCTS, System Engineer

    Thursday, April 27, 2017 6:31 PM
  • Awesome - thanks.

    Just as info:
    I meant that KB4013214 has never been distributed to any client because it has never been synced to WSUS. I could also not manually add it from the catalog. So it either is not really needed when the creators update is distributed by WSUS or the detection logic is wrong and the creators upgrade should not have been distributed to the clients. However, if KB4013214 can not be added to WSUS and is needed for the upgrade, this would imply that the creators upgrade can not be successfully distributed by WSUS at all.

    I'm looking forward to your results.
    Thanks and all my best.

    Friday, April 28, 2017 7:36 AM
  • I'm looking forward to your update as well. We're having the same issue as McLion.
    Monday, May 1, 2017 8:24 PM
  • Hi

    Sorry for waiting, was a bit busy. I've managed to configured WSUS on Windows Server 2012 R2 to manage Windows 10 1703 clients. What I've done is installed KB3095113 and KB3159706 (manual steps required!). My current WSUS version is 6.3.9600.18324.

    Please check that you have installed both updates and done the manual steps noted in KB3159706 article.

    Run wuauclt.exe /reportnow in cmd on your Windows 10 client to force report to WSUS.

    Hope that help!


    MCSE, MCSA, MS, MCP, MCTS, System Engineer

    Tuesday, May 2, 2017 12:07 PM
  • I already installed these updates last year to be able to distribute W10 and 1607. I rechecked the manual steps and they were not completely done - I did it now.

    My WSUS shows version 6.3.9600.18228.

    However, so far the clients still do not report to WSUS.

    Tuesday, May 2, 2017 1:07 PM
  • Installing KB4013214 before the upgrade does not make any difference. Just verified this with another client with 1607 on which I manually installed KB4013214 before letting it upgrade to 1703 from WSUS.
    Tuesday, May 2, 2017 4:02 PM
  • Looks like you do not have the latest WSUS update. I've also installed KB4015550, can you check if it's installed on your WSUS Server?


    MCSE, MCSA, MS, MCP, MCTS, System Engineer

    Tuesday, May 2, 2017 4:57 PM
  • From the GUI I have 18228. If I look at the C:\Program Files\Update Services\WebServices\ClientWebService\WusServerVersion.xml it says 18324 ... that is the strange part.

    KB4015550 is installed and the server has been rebooted since.

    Tuesday, May 2, 2017 5:04 PM
  • Hi McLion,

    According to your description, after the clients upgrade to windows 10 1703, it unable to update from the WSUS server any more.

    I tested in my lab, while in my lab, win10 1703 (which also upgrade via WSUS) didn't meet issue update from WSUS server after upgrading:

    Then, please check the windows update log on the Windows 10 1703, check if there are errors when checking updates from the WSUS server. Also enable the IIS log on the WSUS server, check if the WSUS site could receive the request from the clients.

    Best Regards,

    Anne


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

    Hello Anne,

    Please be informed I have a WSUS server 2012 R2

    but my client don't install 1703, all of them getting 0xc1800118.

    how did you update your client?

    Wednesday, May 3, 2017 4:27 PM
  • Am 03.05.2017 schrieb Alex_0s:

    Please be informed I have a WSUS server 2012 R2

    What build your wsus have?

    but my client don't install 1703, all of them getting 0xc1800118.

    Try this solution:
    https://support.microsoft.com/en-us/help/3194588/-0xc1800118-error-when-you-push-windows-10-version-1607-by-using-wsus

    Winfried


    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    http://technet.microsoft.com/en-us/windowsserver/bb332157.aspx
    http://www.wsuswiki.com/Home

    Wednesday, May 3, 2017 8:59 PM
  • Hello,

    Thank you very much for your reply

    Version: 6.3.9600.18228

    Wednesday, May 3, 2017 9:52 PM
  • it seems there is not any SQL server installed on my WSUS

    How can I run the query in the instruction you recommended?

    is there anything wrong on my server? it seems it is working fine for other updates

    Wednesday, May 3, 2017 11:00 PM
  • I reinstalled KB3159706 over the weekend and rebooted the Server .. to no avail. The server still shows 18828 in the GUI but it should be on 18324 with 3159706 installed.

    Did someone ever look at the logs I posted and can explain the obvious difference. Someone from MS around here to help cleaning up the mess they are doing?


    • Edited by McLion Monday, May 8, 2017 11:16 AM
    Monday, May 8, 2017 11:15 AM
  • Bump ... hello MS ...
    Thursday, May 11, 2017 12:36 PM
  • Makes me feel better that I'm not the only one.  5 Clients upgraded to 1703 via SCCM.  No longer communicate to SCCM for Updates.  This includes Virus Def updates for Windows Defender as well.  
    Thursday, May 11, 2017 1:02 PM
  • Anybody else?

    Thursday, May 11, 2017 6:54 PM
  • Hi,we got the same issue at several customer sites, since there isn´t a accepted solution to this I´ll share my thoughts on this.

    Some of our customer´s are/were using Secunia CSI to deploy 3rd party updates through windows update, some others just use SCUP etc. Updates injected this way in the WSUS have the value 'Other' as the UpdateSource-Property , so they are easily to identify.

    The Windows update client on 1703 seems to have issues resolving the needed updates as soon as 3rd party updates are arriving.

    Anyway, I made a short PowerShell Script to remove 3rd party updates from WSUS, jsut run it on WSUS Server in an administrative PowerShell... Remove 3rd PArty updates


    • Edited by Kamil Kosek Friday, May 12, 2017 10:24 AM attached screenshot
    Friday, May 12, 2017 10:13 AM
  • Thanks for the script. Found 0 ... seems not to be the issue in our case.

    Friday, May 12, 2017 10:45 AM
  • I end up to upgrade my WSUS to 2016

    then there was bunch of errors (sorry I forgot the write them on my note book)

    First you need to update the driver of NIC.  Right click on the device on device manager and choose update does not work. try to find the driver and install it.

    You may need to reboot your computer and also you need to delete the content of "SoftwareDistribution"

    I have a batch file with the content below

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

    REG Delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v SusClientId  /f
    REG Delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v SusClientIdValidation  /f
    REG Add HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /v WUServer /t REG_SZ /d http://WSUS6:8530 /F

    REG Add HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /v WUStatusServer /t REG_SZ /d http://WSUS6 /F
      
    gpupdate
    net stop wuauserv /y
    net stop BITS /y
    rd C:\WINDOWS\SoftwareDistribution /s /Q
    del "c:\windows\windowsupdate.log"
    regsvr32 WUAPI.DLL /s
    regsvr32 WUAUENG.DLL /s
    regsvr32 WUAUENG1.DLL /s
    regsvr32 ATL.DLL /s
    regsvr32 WUCLTUI.DLL /s
    regsvr32 WUPS.DLL /s
    regsvr32 WUPS2.DLL /s
    regsvr32 WUWEB.DLL /s
    regsvr32 msxml3.dll /s
    net start wuauserv /y
    wuauclt.exe /DetectNow /ResetAuthorization /ReportNow /UpdateNow /ScanNow

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

    then try to update again.

    It worked for me. right now all of my Windows 10 clients are up to date. :-)

    • Proposed as answer by Alex_0s Friday, May 12, 2017 10:58 PM
    • Unproposed as answer by McLion Monday, May 15, 2017 2:01 PM
    Friday, May 12, 2017 10:53 PM
  • Yeah that's a basic Windows Update reset.  Tried this plenty of times.  Still no luck.
    Monday, May 15, 2017 1:47 PM
  • Where are the experts, MVP's and what not with a direct wire to MS support ?!?
    Tuesday, May 16, 2017 7:46 AM
  • Hi McLion,

    If you haven't installed the latest update for win10 1703, you may install it manually, check if it could help:

    https://support.microsoft.com/en-us/help/4018124/windows-10-update-history

    As a workaround, you may update from the Microsoft Update directly to keep your machines patched.

    And there's other customer open a case with MS, and seems no definitive solution now, if there are any news, we'll update the post as soon as possible. If you want to get better help, here is the link to open a case with MS;

    https://support.microsoft.com/en-us/gp/support-options-for-business

    Best Regards,

    Anne


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

    Tuesday, May 16, 2017 7:58 AM
    Moderator
  • I did update some of the machines manually from MS Update directly. There is no change in the situation even with the latest update. We can not run up to all clients and do this manually ... returning 20 years back to "clients management by sneakers", really ?!?

    There seem to be many that have the same issue. We have logs from clients and servers that should be analyzed by MS tech support because we have no clue what all the undocumented entries are. This should be possible by means of this forum with the help of MVP's, Mod's or whatever.

    I am Adobe ACP/MVP and Forum Moderator. As such we have a direct wire to Support, PM and Development - exactly for cases like this, to help customers, because customer satisfaction and having customers being able to use the Software they paid for has top notch priority.
    I have a hard time to believe that a setup alike is not available here with MS.
    • Edited by McLion Tuesday, May 16, 2017 8:29 AM
    Tuesday, May 16, 2017 8:19 AM
  • Thanks!  This worked for me.  None of my 1703 machines could get updates, but after updating my GPO admx files to the Creator's Edition (https://www.microsoft.com/en-us/download/details.aspx?id=55080), and specifying alternate server, they immediately started working...

    Note: I just dropped the whole PolicyDefinitions folder into my domain controller's SYSVOL\sysvol\domain.com\Policies folder...

    Wednesday, May 17, 2017 6:45 PM
  • I already tried this, and the GPO seems to propagated to the clients. Here's a print-screen of the setting on a W10 1703 client.

    Thursday, May 18, 2017 7:43 AM
  • Still having all W10 with creators update without updates while W7 works as usual.

    I now tried to debug from another client.
    I get the following:

    I can successfully download wuident.cab from http://server2:8530/selfupdate/wuident.cab
    So, thew server seems to run perfectly, otherwise the W7 clients would not update too.

    Anybody an idea why I get this error.

    The issue seems to be on the w10 client side.

    Monday, May 22, 2017 2:55 PM
  • Kamil are right... 1703 had had problems with Update Source Other.

    With 1703 and 3rd Party Updates i had error 0x8024000D

    With 1607 there was no problem, works.

    After remove my 3rd party Updates from WSUS 1703 updates works...

    i hope MS will fixed this. If not, bad...

    Tuesday, May 23, 2017 9:25 AM
  • Do you have 3rd party updates on WSUS or SCCM?
    Tuesday, May 23, 2017 9:28 AM
  • yes on WSUS i have some 3rd Party Updates. After remove, 1703 make the updates via WSUS
    Tuesday, May 23, 2017 10:50 AM
  • Are you using SSL or not?
    Tuesday, May 23, 2017 10:51 AM
  • last week have non-SSL, not works. Yesterday i change it to SSL, not works

    today i remove 3rd party, works with SSL

    Tuesday, May 23, 2017 11:09 AM
  • Can you please tell me which WSUS parts on the IIS you did set to SSL?

    Thanks

    Tuesday, May 23, 2017 11:13 AM
  • i have use this how-to (but its in german) https://www.wsus.de/ssl_kommunikation

    for english: http://www.vkernel.ro/blog/configure-wsus-to-use-ssl or https://technet.microsoft.com/en-us/library/bb633246.aspx

    Tuesday, May 23, 2017 11:23 AM
  • Deutsch ist perfekt ;-)

    .. Melde mich wieder - Danke

    Tuesday, May 23, 2017 11:26 AM
  • OK, successfully changed server to SSL and W7 clients and Server 2012 can connect and download updates.

    However, W10 1703 is still throwing me the same error and does not report to WSUS. I'm sure it can connect since it returned a different error when it could not reach WSUS halfway of the changes to SSL mode.

    Still at a loss ...

    Tuesday, May 23, 2017 12:33 PM
  • do you have also 3rd Party Updates on WSUS?
    Tuesday, May 23, 2017 1:05 PM
  • Nope - None!
    Tuesday, May 23, 2017 1:19 PM
  • Now I removed WSUS and I CANT REINSTALL IT ! because this da.. post install and the mmc crash every time!

    No, it's not the WSUS IIS page because I already deleted it. It may be the NET 4.5.1 update but that can't be removed

    MSFT ... you created such a mess !!!
    Tuesday, May 23, 2017 5:34 PM
  • I found some other having the same issue and it seems to need a reinstall of the Server to get WSUS on it once it has been updated with NET4.5.1 .... what a BS.

    I restored it from the Backup and WSUS is running again - got me a night shift because of this mess.

    During the WSUS reset and rebuild I found some interesting things:

    After I recovered from the backup I made a reset of the WSUS using WSUSutil. I did not backup and restore the WSUSContent. So, it took quite a while to download about 50GB to fill the store.
    During this time THE WIN10 1703 CLIENTS COULD SUCCESSFULLY CONNECT AND REPORT TO WSUS !
    Of course, they got the green check-mark because the server did not have any update for them ready. I also can see one of them I used to try correctly reporting one missing update (May Removal Tool).

    I thought that's it, and now it's all working.

    After WSUS completed it's download of the updates, Win10 1703 clients are back to the old behaviour - not reporting and showing an error only.
    So, basically they can connect but they don't like something else ... and I have no clue what that could be.

    Is there any way - except removing WSUS - to remove all data and updates and start from scratch?

    Wednesday, May 24, 2017 8:14 AM
  • I cannot figure this out either.  I have updated 10 computers to 1703.  Only 3 them will not report to WSUS.  The 3 computers are all the same Dell computer model.  Check for updates fails with error 0x8024000d.  These happen to be the same 3 computers I have had issues with for the last few months.  They have MS Office 2007 installed on them.  In the past, if I approved more than 1 Office 2007 update at a time, updates would fail and they would not report to WSUS.  In this case though, there are no Office 2007 updates waiting to be approved.
    Wednesday, May 24, 2017 12:51 PM
  • OK, fixed mine :-)

    I created a completely new SUSDB and Content store. That was the only way to start from scratch since remove and reinstall of WSUS did not work due to some known reasons MSFT screwed up. What caused W10 1703 not to update anymore .. I'll probably never know ... but it works now.

    Here's a guide how to do this: Recreating the SUSDB ..
    It takes quite some time (hours) for the first sync with the new DB .. be patient.

    Some things to keep in mind:
    - Before syncing the Upgrades Category to the new WSUS make sure to have KB3095113 and KB3159706 (including manual postinstall steps) installed and configured.
    - The new WSUS will not use SSL. If you have directed your clients to use SSL by GPO you need to reconfigure the webservice and WSUS for SSL as described here or they can not contact anymore - either change and propagate the GPO or (recommended) re-engage SSL on the server.

    Good luck.
    McL


    • Marked as answer by McLion Thursday, May 25, 2017 12:20 PM
    • Edited by McLion Monday, June 26, 2017 2:55 PM
    Thursday, May 25, 2017 12:20 PM
  • Thanks a lot for this post. But I think this could be only a workaround because I don't want to install a lot of instances and servers to fix this problem after an upgrade to build 1703.

    We use a MS Server 2012 R2 with SCCM and third party to update Flash, drivers etc. On this server is the WSUS and I get the same error like you after an upgrade to Build 1703.

    Wednesday, June 7, 2017 1:23 PM
  • Not sure what you mean ... install instances ... ?!?

    Du kannst auch in Deutsch schreiben ;-)

    Wednesday, June 7, 2017 1:35 PM
  • In diesem Fall ist es mal umgekehrt schwierig. Normalerweise gibt es in der IT Wörter auf englisch, die nicht ins Deutsche passen.

    Was ich meine: ich möchte nicht zig WSUS-Instanzen bzw. -Server aufsetzen, nur um Windows 10 Creators Update verteilen und installieren zu können.

    Monday, June 12, 2017 11:19 AM
  • Aber wieso denn überhaupt eine neue Instanz von WSUS?
    Wenn du das gemäss Anleitung machst gibt es genau wie vorher eine einzige WSUS Instanz.
    Ich sehe nicht wo denn hier eine neue Instanz generiert werden soll.


    • Edited by McLion Friday, June 16, 2017 3:32 PM
    Monday, June 12, 2017 11:39 AM
  • I was able to fix this by changing the following registry entry back to manual (3).

    We had disabled it to prevent staff from logging in using their Microsoft Accounts. I cannot believe this ended up being the issue!

    https://docs.microsoft.com/en-us/windows/configuration/manage-connections-from-windows-operating-system-components-to-microsoft-services

    11. Microsoft Account

    To prevent communication to the Microsoft Account cloud authentication service. Many apps and system components that depend on Microsoft Account authentication may lose functionality. Some of them could be in unexpected ways.+

    • Change the Start REG_DWORD registry setting in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\wlidsvc to a value of 4.

     

    I changed it back to the default value of 3 and now WSUS works fine with Windows 10 1703.






    • Proposed as answer by Squuiid Friday, June 16, 2017 12:20 PM
    • Edited by Squuiid Friday, June 16, 2017 12:24 PM
    Friday, June 16, 2017 12:16 PM
  • Any Update? Tried everything!

    -Made a brand new WSUS with Server 2016

    -use of newest PolicyDefinitions

    -WSUS with SSL

    -tried downloadmode bypass

    Every client with no internet access is still stuck at 0% downloading updates :(

    Wednesday, June 21, 2017 8:12 AM
  • The issue described and discussed in this thread is solved - clients with W10 1703 can not download any further updates from WSUS.
    See my post from May 25.
    Your issue seems to be a different one - ... 0% downloading ...

    Wednesday, June 21, 2017 8:39 AM
  • Windows 10 Update KB4022716 (OS Build 15063.447) finally fixed it for me.
    Sunday, July 2, 2017 10:12 AM
  • In our case (W2K8r2 WSUS 3.2, win10 1703 client with 0x8024000d error) it was Office File Validation Add-in.

    Disable Office Validation Add-In on WSUS - clients starts to report and receive updates. We enable OLDER version of OFV (101 revison, with license agreemen on WSUS). Works fine. 1703 client can receive updates and report to WSUS

    Sunday, July 30, 2017 9:34 AM