Asked by:
Windows 10 1703 and WSUS

Question
-
I upgraded my PC from Windows 10 1607 to Windows 10 1703. I applied the latest CU to it but I'm getting this error message when trying to get updates from my WSUS server. Has anyone else run into this? My build number is 15063.138. WSUS is version 6.3.9600.18057 on Server 2012 R2 VM.
Thursday, April 13, 2017 2:51 PM
All replies
-
error message 0x8024000D
https://support.microsoft.com/en-us/help/938205/windows-update-error-code-list
0x8024000D WU_E_XML_MISSINGDATA Windows Update Agent could not find required information in the update's XML data.
I think you are going to need a better clue than this. See if WindowsUpdate.log gives you any more detail about this. Use PowerShell Get-WindowsUpdateLog to generate it.
Also, I imagine that there is another forum better than General for looking for help about updates related to WSUS but don't know exactly what they might be...
I think I got 2 out of 3 for this. Right forum, right diagnostic but wrong code. ; )
Robert Aldwinckle
---Thursday, April 13, 2017 8:27 PM -
Thanks, I looked at the log and found only these...
2017/04/14 09:19:47.3852111 5576 14172 ComApi [0]15C8.375C::04/14/2017-09:19:47.385 [comapi]ISusInternal:: DisconnectCall failed, hr=8024000C
2017/04/14 09:19:47.3863976 5576 14172 ComApi [0]15C8.375C::04/14/2017-09:19:47.386 [comapi]ISusInternal:: DisconnectCall failed, hr=8024000CAddFlightObjects failed: Error 0x80070002
- Proposed as answer by Yic LvMicrosoft contingent staff Friday, April 19, 2019 2:30 AM
- Unproposed as answer by Yic LvMicrosoft contingent staff Friday, April 19, 2019 2:30 AM
Friday, April 14, 2017 1:41 PM -
I also ran the Windows Update Troubleshoot tool within Windows 10 and it keeps telling me that I have pending updates...despite hitting Apply this Fix. If I rerun the tool, it will display the same message
Friday, April 14, 2017 1:58 PM -
AddFlightObjects failed: Error 0x80070002
Robert Aldwinckle
---Friday, April 14, 2017 6:21 PM -
i would open the command prompt as an administrator then run SFC
and see what that tells you frist
Friday, April 14, 2017 7:51 PM -
Hello,
I am also encountering this issue when deploying 1703 from WSUS. SFC returns no issues. Same behavior from Windows Update Troubleshooter. Finds errors and supposedly corrects but then will re detect the errors on a subsequent scan.
Thursday, April 20, 2017 2:41 PM -
Windows Update Troubleshooter. Finds errors and supposedly corrects but then will re detect the errors on a subsequent scan.
I saw a report today that emulating manually what the troubleshooter does (is supposed to do) was successful. You can monitor what the troubleshooter does (or doesn't achieve) by ProcMon. Filter with Operation Is Process Exit (and check the Return code in Details).
C.f.
https://answers.microsoft.com/message/be0d32cd-4f38-4a79-84e9-8a9b929b223d
Robert Aldwinckle
---Thursday, April 20, 2017 4:58 PM -
Hello,
I am also encountering this issue when deploying 1703 from WSUS. SFC returns no issues. Same behavior from Windows Update Troubleshooter. Finds errors and supposedly corrects but then will re detect the errors on a subsequent scan.
Have the same issue after using upgrade Task Sequence to 1703 with SCCM. No updates will install... the logs continually point to error 0x8024000d. No issues with any other OS (Win7, Win10 1607). I'm done beating my head against the desk for this and will wait for MS to address. Thursday, April 20, 2017 9:07 PM -
Has anyone tried doing a clean install instead of an upgrade? To see if the issue persists? Kinda throwing stuff around.Friday, April 21, 2017 2:06 PM
-
i would open the command prompt as an administrator then run SFC
and see what that tells you frist
Friday, April 21, 2017 2:16 PM -
I am seeing the same on all clients that have been upgraded to 1703 from WSUS. They are not able to check in to WSUS anymore.
Monday, April 24, 2017 12:02 PM -
I just did a clean install and the same error occurred.Monday, April 24, 2017 5:46 PM
-
What is that showing? I see one trace involving IPv6 and another involving IPv4?BTW someone else a while ago had to use WindowsUpdate.log at a high verbose level to solve a WSUS problem somehow...
Oh. You had a WU log too... Maybe you need to make yours verbose too. <eg>
Hmm... Instead of concluding that 0x8024000D was the problem I think the seminal error was
0x80240042 WU_E_UNKNOWN_SERVICE The update service is no longer registered with AU.
or this
http://joshpoley.blogspot.ca/2011/09/hresults-facilitywindowsupdate.html
(BING search for
+0x80245004 WSUS
)WU_E_REDIRECTOR_UNKNOWN_SERVICE - 0x80245004 - (20484)
The service ID is not supported in the service environment.But it looks as if that one cascaded from the first.
FWIW I think the WSUS forum is likely to be able to give more informed comment about your traces at whatever level you manage to make them have.
Otherwise it looks as if there are a plethora of diagnostics available to help solve problems with WSUS.
(BING search for
diagnostics WSUS site:technet.microsoft.com WIKI
)Good luck
Robert Aldwinckle
---Monday, April 24, 2017 7:09 PM -
I'm having this problem too... Has anyone opened a case?Thursday, April 27, 2017 5:11 PM
-
for what its worth... had same issue with 1703 and WSUS clients. Decided to upgraded PC's manually using https://www.microsoft.com/en-us/software-download/windows10
after that all pc's are responding to WSUS server again and behaving again
Friday, April 28, 2017 5:21 AM -
Could you re-apply the manual upgrade to a PC already upgraded by WSUS before and that already has 1703?Friday, April 28, 2017 7:44 AM
-
Yep I have the same issue. WSUS running on Server 2016 with all patches installed. Group Policy central store updated with 1703 policy definitions. Alternate Server specified in Group Policy in the intranet Microsoft update service location as well.
I have 35 machines with Win10 1703 deployed via WSUS and they can now no longer contact the WSUS server with error 0x8024000d.
Friday, April 28, 2017 3:55 PM -
Welcome to the club :-)Friday, April 28, 2017 4:23 PM
-
I had the same issue. Upgraded 5 clients to 1703 and they stopped communicating with WSUS on Windows Server 2012. After several days of unsuccessful troubleshooting, I stood up a new Windows Server 2016 WSUS server and now all 5 clients are working again. I did a fresh install of WSUS and re-downloaded all of the updates. I didn't want to transfer the previous WSUS configuration to the new server in case there was something wrong with it. I just updated my GPO and let all of the clients check in with the new server.Monday, May 1, 2017 3:01 PM
-
Hi,
i.m having the same problem and have opened a case @ MS
https://social.technet.microsoft.com/Forums/windows/en-US/449152df-d267-4bfa-ad51-74239fdf1d65/windows-10-1703-ent-x64-wsus-issue?forum=win10itprosetup
Monday, May 1, 2017 7:49 PM -
Hey guys,
Looks like I fixed it here. In my case, it seemed to be an issue with Dell Updates I had imported via SCUP. I had imported a bunch of updates metadata-only, and it looked like one of them was causing issues with 1703. Once I pruned my Dell updates to the list of updates I know I needed to deploy, my 1703 boxes started working.
Hope this helps...
Monday, May 1, 2017 9:51 PM -
For us our WSUS server is a brand new 2016 server and we still have this issue. The workstations experiencing the Update error are Surface Pro3 and 4 devices and we don't use SCUP.Tuesday, May 2, 2017 2:16 PM
-
We don't have any manually imported/added updates ... still waiting for MS to come up with a solution.
- Edited by McLion Tuesday, May 2, 2017 2:41 PM
Tuesday, May 2, 2017 2:40 PM -
I believe the problem is somewhere on the WSUS server side. From my previous post, I'm not saying that upgrading to WSUS on 2016 was the absolute fix, but just bringing up a fresh WSUS server in general may fix the problem although downloading all of the updates again takes time. I didn't do anything special to the PC's that had stopped checking in, but they didn't have any trouble with the new WSUS instance. FWIW, I never tried to delete the broken Windows 10 machines from the original WSUS console, but wonder if that may work, too.Tuesday, May 2, 2017 3:18 PM
-
I posted WU logs to compare in the other thread linked above. From what I can see the calls involve something like an additional client protocol that maybe the server does not understand ... how would I know since MS never documents anything.
- Edited by McLion Tuesday, May 2, 2017 3:36 PM
Tuesday, May 2, 2017 3:35 PM -
From what I can see the calls involve something like an additional client protocol that maybe the server does not understand
Did you see my interpretation of them above? Looks to me more like a configuration problem. Also I would agree that the default logging appears insufficient to diagnose the details. FWIW here is a link to the thread where verbose logging for solving an unspecified problem with WSUS was mentioned
<quote>
Finally got this working by playing with the Level value in the Trace. Setting it to 9 was sufficient to get the level of detail I needed to find my WSUS problem.
</quote>
Robert Aldwinckle
---Tuesday, May 2, 2017 6:04 PM -
I'll share my experience in the event that it might help someone else.
I was experiencing the same issue with Win 10 1703 clients not communicating with WSUS (via SCCM CB).
I was able to resolve the issue by looking closer at WSUS itself, and cleaning it up. In my case, SCUP had previously been used and thus there was a lot of 3rd party (Dell, Adobe, etc) update metadata in my WSUS database. I first followed the instructions here (http://scif.codeplex.com/wikipage?title=%20Deleting%20WSUS%20Updates&ProjectName=scif) and followed Step 1 to list and then delete the 3rd party categories and update data. I did not have to do Step 2: "unwedging clients".
After these steps were complete, I noticed that my Win10 1703 workstation automatically received a couple of missing updates that it failed to detect before (a software update group deployment was still assigned to my workstation)
At this point I'm thinking everything is working again.. However...
I was not able to synchronize WSUS via SCCM, as I was getting errors related to "Subscription contains categories unknown to WSUS". It was still referring to a Category Product for Adobe Flash Player.
The first step was I had to remove the 3rd party categories from SCCM in the Software Update Point "Products"
I attempted a WSUS synchronization via SCCM again, but still received errors regarding the Category Product for Adobe Flash Player
At this point I had to follow the instructions here (https://social.technet.microsoft.com/Forums/en-US/890d05f7-facc-4cc8-afc0-1a5bcb1a1232/failed-to-set-subscriptions-on-the-wsus-server-error2147467259unspecified-error?forum=configmanagersecurity) to remove the CategoryInstanceName for Adobe Flash Player.
After all of this, WSUS synchronization was successful, SCCM Software Update Point was happy again, and my Win10 1703 workstations now can talk to and receive updates via SCCM.
Way too much work for an issue that seems to be only related to Win10 1703 clients. I suspect Microsoft will be forced to address the issue as this was way outside of WSUS maintenance than I think most administrators would need to do to support this OS upgrade.
- Proposed as answer by CRAtech Monday, June 5, 2017 10:55 PM
Tuesday, May 2, 2017 7:35 PM -
Got me over 14000 lines of log !?! ... and no clue of where the bug lies !
Some errors:
[sls]Failed to get the ETAG value with error 80072f76; ignoring...[agent] fail to parse extended info with error 0x8024000d
[agent]Failed to get extended update infos, hr=0x8024000d.
[agent]Failed to get missing extended info with error 0x8024000dAny idea?
A difference in the server log between a W10 1703 and an older one is the bold below:
POST /ClientWebService/client.asmx - 8530 - 192.168.1.215 Windows-Update-Agent/10.0.10011.16384+Client-Protocol/1.58 - 200 0 0 0
POST /ClientWebService/client.asmx - 8530 - 192.168.1.192 Windows-Update-Agent - 200 0 0 280Monday, May 8, 2017 11:58 AM -
Hi,
i.m having the same problem and have opened a case @ MS
https://social.technet.microsoft.com/Forums/windows/en-US/449152df-d267-4bfa-ad51-74239fdf1d65/windows-10-1703-ent-x64-wsus-issue?forum=win10itprosetup
Monday, May 8, 2017 12:18 PM -
Got me over 14000 lines of log !?! ... and no clue of where the bug lies !
Robert Aldwinckle
---Monday, May 8, 2017 3:23 PM -
I do not have any issue finding the error lines. However, doing this will not help a bit since there is absolutely no help/description available what they mean - and no one from MS seems to be willing to help. I posted complete logs from clients and server quite some time agon in an other thread - no none from MS (or whoever) seems to be able to read these and get some interpretation of the error.
So many companies seem to struggle with the very same issue and MS simply does not care!
Monday, May 8, 2017 4:04 PM -
no none from MS (or whoever) seems to be able to read these and get some interpretation of the error.
Robert Aldwinckle
---Monday, May 8, 2017 5:19 PM -
no none from MS (or whoever) seems to be able to read these and get some interpretation of the error.
See above? I guessed that your 0x8024000D is not the significant symptom.
Robert Aldwinckle
---That doesn't really help in solving the issue.
Even if I look at all the errors, without any documentation or help I simply have no clue what else to try.
[sls]Failed to get the ETAG value with error 80072f76; ignoring...
Before the first error entry are 13915 lines without error showing that it downloaded some stuff from WSUS and is compairing .. or whatever.
[sls]Content Type for Response: text/xml; charset=utf-8
[sls]GetResponse succeeded. The file was downloaded.
[sls]Validating response for service 3DA21691-E39D-4DA6-8A4B-B43877BCB1B7 ...
[sls]SLS Response is Error response type. Attempting to extract the HRESULT in the payload...
[sls]Succeeded in extracting the HRESULT from the payload => 0x80240042
[metadataintegrity] failed: hr = 0x80245004
[metadataintegrity]GetFragmentSigningConfig failed with 0x80245004. Using default enforcement mode: Audit.
[metadataintegrity] failed: hr = 0x80245004
[metadataintegrity]Policy-driven service enabled. Using Ignore Policy.
[agent] fail to parse extended info with error 0x8024000d
[agent]Failed to get extended update infos, hr=0x8024000d.
[agent]Failed to get missing extended info with error 0x8024000d
[agent]WU client calls back to search call {F68142F8-5519-423F-8B8A-6ADFD07D79B4} with code Call failed and error 0x8024000d
[agent]WU client calls back to search call {F68142F8-5519-423F-8B8A-6ADFD07D79B4} with code Call failed and error 0x8024000d
[agent]No more callback needed for call {F68142F8-5519-423F-8B8A-6ADFD07D79B4}
[agent]Deregistered thread 8092 <NULL>; currently at normal background priority
[comapi]*RESUMED* Search ClientId = UpdateOrchestrator, ServiceId = 3DA21691-E39D-4DA6-8A4B-B43877BCB1B7 (cV = luy26jLYW0KONs+P.0.1.0.0)
[ausettings]Setting AU approval type to e_auApprovalTypePreDownloadNotify since Orchestrator is active
[comapi]Exit code = 0x00000000, Result code = 0x8024000D (cV = luy26jLYW0KONs+P.0.1.0.0)
[comapi]* END * Search ClientId = UpdateOrchestrator, Updates found = 0, ServiceId = 3DA21691-E39D-4DA6-8A4B-B43877BCB1B7 (cV = luy26jLYW0KONs+P.0.1.0.0)
[comapi]completion event signalled
[comapi]Retrieved OnCompleted callback from GIT (cookie=513)
[comapi]Operation failed due to earlier error, hr=8024000D
[comapi]Failed to process completed federation member search, hr=0x8024000D, code=6 (cV = luy26jLYW0KONs+P.0.1.0)
[comapi]* END * All federated searches have completed. Jobs = 1, Succeeded = 0, ClientId = UpdateOrchestrator (cV = luy26jLYW0KONs+P.0.1.0)
[comapi]completion event signalled
[comapi]Retrieved OnCompleted callback from GIT (cookie=512)
[comapi]Operation failed due to earlier error, hr=8024000D
[comapi]Unable to complete asynchronous search. (hr=8024000D)
[reporting]REPORT EVENT: {C3ABC35A-5C18-4328-851E-59FE3A98D87D} 2017-05-08 13:40:24:595+0200 1 148 [AGENT_DETECTION_FAILED] 101 {00000000-0000-0000-0000-000000000000} 0 8024000d UpdateOrchestrator Failure Software Synchronization Windows Update Client failed to detect with error 0x8024000d.
Tuesday, May 9, 2017 2:39 PM -
no none from MS (or whoever) seems to be able to read these and get some interpretation of the error.
See above? I guessed that your 0x8024000D is not the significant symptom.
Robert Aldwinckle
---That doesn't really help in solving the issue.
Even if I look at all the errors, without any documentation or help I simply have no clue what else to try.
Before the first error entry are 13915 lines without error showing that it downloaded some stuff from WSUS and is compairing .. or whatever.Any suggestions highly appreciated.
Tuesday, May 9, 2017 2:50 PM -
[sls]SLS Response is Error response type. Attempting to extract the HRESULT in the payload...
[sls]Succeeded in extracting the HRESULT from the payload => 0x80240042 .
0x80240042? Deja vu.
- WU_E_UNKNOWN_SERVICE
- 0x80240042
The update service is no longer registered with automatic updates.
Ask where there are more people who know WSUS? Not here in W10ITProGeneral. It still looks like a configuration problem to me.
Robert Aldwinckle
---Tuesday, May 9, 2017 6:11 PM -
I agree that it could possibly be a configuration problem, but what? I have 600 Win7 and Win8 PCs and 130 odd servers that all work perfectly with my WSUS installation. After the OS upgrade to 1703 my Win10 workstations are the only ones that have a problem. I can't seem to find a problem with my group policy or WSUS server after going through documentation for deployment.Tuesday, May 9, 2017 6:18 PM
-
I agree that it could possibly be a configuration problem, but what?
How about checking the WSUS logs for why that 80240042 was issued?
Or what about this one which followed/derived from it
<extract>
[metadataintegrity]GetFragmentSigningConfig failed with 0x80245004. Using default enforcement mode: Audit.
[metadataintegrity] failed: hr = 0x80245004
[metadataintegrity]Policy-driven service enabled. Using Ignore Policy.</extract>
Perhaps a different "policy" would put the symptom back into the "other court"?
Robert Aldwinckle
---- Proposed as answer by Mike-Pt Thursday, June 29, 2017 3:42 PM
Tuesday, May 9, 2017 8:45 PM -
Sorry what does that even mean?
Tuesday, May 9, 2017 8:51 PM -
I did ... I also posted a link here (a few posts ago) to the thread in WSUS forum ... to no avail :-(Wednesday, May 10, 2017 8:07 AM
-
I did ... I also posted a link here (a few posts ago) to the thread in WSUS forum ... to no avail :-(
Looks like you are getting some help there but if you would like some more guesses here's a nice complete reference that my suggested search found
(BING search for
diagnostics WSUS site:technet.microsoft.com WIKI
)It's RSS so don't try to open it in Edge.
Robert Aldwinckle
---Wednesday, May 10, 2017 12:54 PM -
Immediately after deploying update 1703 to some test machines, I got the same annoying error. A fresh new 1703 installation also did not the trick.
At this time, our WSUS was a 2012 R2 machine with a central database on a dedicated SQL server (before this, it has also been a 2008 R2 server, and before this, who knows?). I decided to set up a 2016 server and migrated the WSUS to this new server. Did this resolve the issue? No!
To get rid of the problem (all our newly deployed machines should be 1703 and not 1607) my second attempt was to build a brand new WSUS server and start from beginning with a new database. What do you think? Yes, the issue is now gone! However, I do not have to tell you how much time this has consumed … and will consume the next days … thank you very much Microsoft L
Marc
Monday, May 15, 2017 6:53 AM -
Seriously, it can't be that we need to setup a new server because of MS screwing up!
I neither have the money nor time nor what not to fix what MS broke!
Monday, May 15, 2017 8:20 AM -
Same issue here. WSUS on 08 R2, brand new deployment... Doesn't work.Monday, May 15, 2017 3:03 PM
-
Yeah this can't be the answer. My WSUS resides on my SCCM server. I cannot rebuild that.Monday, May 15, 2017 9:48 PM
-
This solved it for us!
First set all "published metadata only" to expire in SCUP then follow this guide https://patchmypc.net/scupcatalog/documentation/CleaningUpExpiredUpdates.pdf
- Edited by GleSax Wednesday, May 17, 2017 12:18 PM
Wednesday, May 17, 2017 12:00 PM -
I was able to fix it by doing the following:
Updated my GPO admx files to the Creator's Edition (https://www.microsoft.com/en-us/download/details.aspx?id=55080), and specified my WSUS server as alternate server (Policies\Administrative Templates\Windows Components\Windows Update\Specify intranet Microsoft update service location), then after forcing gpupdate to 1703 computers, it 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:49 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:11 AM -
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.
Can the root-cause be that no one of you use SSL? McLion your Screenshots are showing your still on http.
Keep in mind, Microsoft recommending using SSL for WSUS since years.Tuesday, May 23, 2017 7:42 AM -
I'm going to try this and set the W10Computers group to https://SERVER2:8530
However, connection seems to work. Look at my latest post here: My Thread
Tuesday, May 23, 2017 7:48 AM -
I just tried this - to no avail. It returns a different error 0x80240437 but still no connection to WSUS.
Edit: my SSL config was wrong, so I did not really test this.
Can someone who is able to successfully update 1703 clients confirm whether they use SSL or not?
- Edited by McLion Tuesday, May 23, 2017 9:26 AM
Tuesday, May 23, 2017 9:02 AM -
Look at my latest post here: My Thread
There you are showing 0x80190194 (not in text). To get some meaning for that it may help to go decimal...
0x19 = 25 0x0194 = 404
https://msdn.microsoft.com/en-us/library/cc231198.aspx?f=255&MSPPError=-2147217396
FACILITY_HTTP
25
The source of the error code is HTTP support.
Of course HTTP response code 404 is well known. So, this looks like an arcane way of saying that something was "Not found" when using HTTP.
(BING search for
0x801901f4 windows 10 wsus site:technet.microsoft.com
)Looks like a solution was found recently (last post in that thread) involving web.config? (No mention of that in this thread so far. I don't know if that is what you were comparing above.)
HTH
Robert Aldwinckle
---Tuesday, May 23, 2017 3:23 PM -
Thanks for that.
However, what ever I try, it just does not work. Something must be broke within W10 1703 because even after I switched everything to SSL, W7 and Server2012R2 are still working perfect with WSUS.
I think I'm going to remove and reinstall WSUS ... maybe this helps.
Tuesday, May 23, 2017 4:12 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:33 PM -
Now I removed WSUS and I CANT REINSTALL IT ! because this da.. post install and the mmc crash every time!
Could it be a permissions problem? (E.g. an abort due to that which is made to look like a crash.) Use ProcMon to find out what is happening in any case.
In case it helps here is an example of another enterprise user's tactic for dealing with security/obscurity
Robert Aldwinckle
---Tuesday, May 23, 2017 6:55 PM -
Thanks for trying to help. 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 a gain - got me a night shift because of this mess.
During the WSUS reset and rebuild I found some interesting things ... please follow up in the thread I originally created for this: My Thread
Wednesday, May 24, 2017 8:03 AM -
Hello all,
I had the exact same problem with 1703 and found out that it is caused by our SCCM OSD Task sequence. The SCCM OSD Task "Install Software Updates" was used in our OSD sequence (which worked perfectly on 1607). This "Install Software Updates" destroy's the whole updatestore in Windows 10 1703 and is not repairable (At least not with stopping all services and deleting all windows update files and reseting all reg keys.
Please let me know if you have encountered the same issue with the SCCM OSD and 1703 (Currently i just disabled those tasks and everything works well).
We are currently on SCCM CB 1702
Its me its me its me its still me
Wednesday, May 24, 2017 4:59 PM -
Read my last post here to see the solution for my issue.Thursday, May 25, 2017 12:22 PM
-
Read my last post here to see the solution for my issue.
That's what i told you some days ago ... you have to rebuild your WSUS database and it will work again. But this can not be a solution ...Marc
Thursday, May 25, 2017 5:09 PM -
You're right ... we should not call this a 'solution'.
What I first tried was to remove and reinstall WSUS (instead of only rebuilding the database), which apparently does not work and forces you to reinstall the entire server if you don't have a backup from where you can add WSUS back in - IMHO, that's an unacceptable no-go from MS.
Friday, May 26, 2017 6:47 AM -
Anyone had any success fixing this without database rebuilding yet?Monday, June 5, 2017 12:45 PM
-
Anyone had any success fixing this without database rebuilding yet?
The error details aren't the same, but are the conclusions in this thread relevant?
Monday, June 5, 2017 1:15 PM -
Not for me. My Registry entries are all already at 10 HEX (16 decimal).Monday, June 5, 2017 1:50 PM
-
Mine are already at 10 Hex tooMonday, June 5, 2017 2:43 PM
-
I have the same issue here as everybody else... purging SCUP and WSUS of all the ADOBE updates (as well as VNC) and the systems began 'seeing' WSUS again properly.
SCUP first freaked-out because there were 'un-expired' up dates which needed processing, so did that, deleted the Adobe catalog, the went and did the first half of this post... listings the categories in STEP 1 from that link and then deleting the category's (adobe / vnc) via their ID.
waited a few minutes, ran updates on a problem system, and it started working again.
thanks for the help!
edit:
on a side note, any system NOT linked to our domain and therefore WSUS worked without a hitch (ie personal laptops that i take care of in-house)
- Edited by CRAtech Monday, June 5, 2017 11:04 PM
Monday, June 5, 2017 11:02 PM -
I did the same with Adobe in SCUP, but didn't fix it.
Might have to try it with Dell too, but then got to reimport it again and Dell are terrible for circular references that break WSUS.
Wednesday, June 7, 2017 3:25 PM -
1. Close the Setting app.
2. Run Services.msc.
3. Stop 'Windows Update' service.
4. Open explorer and nav to C:\Windows\SoftwareDistribution\
5. Delete everything in the 'SoftwareDistribution' folder.
6. Restart 'Windows Update' service.
7. Open the setting app and retry windows updates.
* The Windows Update Database might have been hosed... Works most of the time, and its harmless everything is rebuilt.
- Edited by Zenithtwc Thursday, June 8, 2017 4:07 AM
Thursday, June 8, 2017 4:07 AM -
Tried the SoftwareDistribution deletion multiple times, but doesn't work.Thursday, June 8, 2017 7:47 AM
-
I read this thread for some days, because I have the same problem with some Win 10 Clients after upgrading to 1703.
Yesterday I saw my solution as I it was necessary to uopgrade one of those clients to office 10.
In our company the most workstations still using office 2007 - the migration is planned but not done.
Only a hand full of clients using office 10 or office 2013.
So after the upgrade to office 10 this client suddenly starts to download the windows updates again.
So today I did a test with a second laptop wit office 2007. First the laptop was cancelling searching updates from wsus error 0x8024000d.
This time I uninstalled the office 2007 from that device and did a reboot.
After the machine cames up, new updates from wsus immediately were available.
So in my case I'm sure the office 2007 installations on the client are the reason why wsus updates are not working
Hope I could help someone.....
- Edited by Bl0ckS1z3 Friday, June 9, 2017 8:57 AM
Friday, June 9, 2017 8:55 AM -
I bit the bullet and expired all my SCUP Dell applications and drivers so checking for updates works again.
Now I can't republish any of them because SCUP says they are "on the update server and is expired, no publish actions are possible.".
So do I have to wait 7 days for SCCM to remove all trace of them before I can publish them again?
Friday, June 9, 2017 4:32 PM -
My situation is different, as our SCCM infrastructure doesn't yet support 1607 or 1703, so I have to go directly to Microsoft for Windows 10 updates.
On one machine (a single-socket Xeon workstation upgraded from 1607 using the Windows 10 Upgrade Assistant), I had to hit "Apply this fix" twice, then it applied the fixes (service registration missing or corrupt, database errors, component repairs, check for pending updates), and left the "Troubleshooting has completed" window open.
I went back over to Windows Update, and it was already downloading updates.
On another machine (a sixth-gen Core m7 laptop also upgraded from 1607 using the Windows 10 Upgrade Assistant) I ran the troubleshooter and got the same messages (minus the service registration issue), and hit "Apply this fix" twice. I manually kicked off another Windows Update, and got the same 0x8024000D error.
I rebooted the laptop, and ran Windows Update again. After several minutes of checking for updates, it started downloading updates. After update installation and restarting, another check of WU generated the same 0x8024000D error. I ran the troubleshooter again, rebooted, and went back to WU for another check, and got 0x8024000D again. After a reboot it tells me that the system is up to date, though.
IMHO, Windows Update on 1703 is a little flaky or buggy, unless you're on a home network and automatic updates is turned on (I'm not seeing any WU issues with 1703 machines at home).
Be patient and persistent, and run the troubleshooter.
- Edited by dukeisduke Thursday, June 15, 2017 4:59 PM typos
Thursday, June 15, 2017 4:58 PM -
Any luck on solving this?Monday, June 19, 2017 10:12 PM
-
I'm using SCUP as well. How to you find which updates are Published Metadata Only please?
Brad Terhune
Tuesday, June 20, 2017 1:32 PM -
I have SBS2011 with WSUS ver.3.2.7600.226
clients are Win10 1703, joined to a SBS domain.
exactly the same issue. Proposed solution by Zenithtwc did not work.
rebooting, running the troubleshooter - does not help. WU event log simply says "Unable", no details.
please advise,
thanks!
Monday, June 26, 2017 2:45 PM -
Read my post from May 25 here.Monday, June 26, 2017 2:54 PM
-
FYI, this issue has been fixed by the following update:
June 27, 2017—KB4022716 (OS Build 15063.447)
https://support.microsoft.com/en-in/help/4022716/windows-10-update-kb4022716You may not immediately see the fix in the Microsoft Update Catalog, but it should be there soon. The following is a related search query:
http://www.catalog.update.microsoft.com/Search.aspx?q=KB4022716
Although the article does not specifically mention the 0x8024000d scan error, the update includes a version Wuaueng.dll (10.0.15063.447) that contains the fix.
The same fix will be included in the July 2017 updates for Win10, which will be available on "Patch Tuesday" 7/11/2017.
Tuesday, June 27, 2017 10:27 PM -
So if we deploy the creators update via WSUS and the PC is unable to get updates from WSUS afterwards how are we supposed to push the 4022716 patch? Will there be a new build of Windows made available that has this fix builtin?
Rob
Friday, June 30, 2017 6:16 PM -
you would have to download it and apply it manually or thru GPU.Friday, June 30, 2017 7:30 PM
-
This appears to fix the problem, but installing the 705MB update takes quite some time. We need the Windows Update Engine package to be made available as a standalone fix via the Trusted Installer.
Testing shows replacing just that one .dll will get updates working, and in fact makes KB4022716 an update offered. In order to be a proper solution, it needs to come from Microsoft via the Trusted Installer.
It would be much easier to deploy, no reboot required.
- Edited by dmvalent Saturday, July 1, 2017 12:25 AM
Friday, June 30, 2017 11:53 PM -
This appears to fix the problem, but installing the 705MB update takes quite some time. We need the Windows Update Engine package to be made available as a standalone fix via the Trusted Installer.
Testing shows replacing just that one .dll will get updates working, and in fact makes KB4022716 an update offered. In order to be a proper solution, it needs to come from Microsoft via the Trusted Installer.
It would be much easier to deploy, no reboot required.
Monday, July 3, 2017 4:02 PM -
when you turn off Realtime Protection in Defender and set this reg keys, it will work:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"DoNotConnectToWindowsUpdateInternetLocations"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization]
"DODownloadMode"=dword:00000064
Tuesday, July 4, 2017 9:34 AM -
Still doesn't work for us. We didn't have the 0x8024000d error. The update agent just hangs at 0% when the client has no internet connection. We never get any error code. Seems the fix is not for this error :(Wednesday, July 5, 2017 12:10 PM
-
We never get any error code.
Where all have you looked for one? Tried ProcMon?
Robert Aldwinckle
---Wednesday, July 5, 2017 7:50 PM -
We never get any error code.
Where all have you looked for one? Tried ProcMon?
Robert Aldwinckle
---WSUS log, eventlog,...
Also monitored task manager and used procmon, but no load from cpu, ram or network for windows update at all. Seems to hang in a timeout until the client gets internet access and is able to telephone home to microsoft...
Thursday, July 6, 2017 9:38 AM -
Seems to hang in a timeout until the client gets internet access and is able to telephone home to microsoft...
That sounds like there is an interferer which is not getting out of the way. Someone was speculating that MS may be trying to handle WU like a VPN either as a means of emphasizing the interference or as a possible workaround for existing symptoms... naturally I can't find what I read using such vague search terms. I'll try to remember to update this if I stumble over it again.
In any case one diagnostic that the cumulative update provides regarding this is its FilterList.log.
Robert Aldwinckle
---Thursday, July 6, 2017 12:18 PM -
Finally i was able to find the reason why this is happening!
You should not configure any defer or pause policys for feature or quality updates since they are only for standalone devices and windows update for business and not for managed clients with wsus.
More information about this:
https://blogs.technet.microsoft.com/windowsserver/2017/01/09/why-wsus-and-sccm-managed-clients-are-reaching-out-to-microsoft-online/Friday, July 14, 2017 7:31 AM -
This worked for me on a 1703 client that wouldn't even check for updates, or install them.
First, the machine had a Realtek PCIe GBE Family Driver that I updated to the latest version from Realtek's website: http://www.realtek.com/downloads/downloadsView.aspx?Langid=1&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false
Second, I set the Alternate Download Location in the WSUS GPO settings to the same as the primary.
Third, I ran this script on the client PC.
reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v SusClientId /f
reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v SusClientIdValidation /f
net stop wuauserv /y
net stop BITS /y
net stop DoSvc /y
net stop appidsvc /y
net stop cryptsvc /y
REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization" /v DODownloadMode /t REG_DWORD /d 3 /f
rd C:\WINDOWS\SoftwareDistribution /s /Q
ren %systemroot%\system32\catroot2 catroot2.bak
del "c:\windows\windowsupdate.log"
del "%ALLUSERSPROFILE%\Application Data\Microsoft\Network\Downloader\qmgr*.dat"
sc.exe sdset bits D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)
sc.exe sdset wuauserv D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)
cd /d %windir%\system32
regsvr32.exe atl.dll /s
regsvr32.exe urlmon.dll /s
regsvr32.exe mshtml.dll /s
regsvr32.exe shdocvw.dll /s
regsvr32.exe browseui.dll /s
regsvr32.exe jscript.dll /s
regsvr32.exe vbscript.dll /s
regsvr32.exe scrrun.dll /s
regsvr32.exe msxml.dll /s
regsvr32.exe msxml3.dll /s
regsvr32.exe msxml6.dll /s
regsvr32.exe actxprxy.dll /s
regsvr32.exe softpub.dll /s
regsvr32.exe wintrust.dll /s
regsvr32.exe dssenh.dll /s
regsvr32.exe rsaenh.dll /s
regsvr32.exe gpkcsp.dll /s
regsvr32.exe sccbase.dll /s
regsvr32.exe slbcsp.dll /s
regsvr32.exe cryptdlg.dll /s
regsvr32.exe oleaut32.dll /s
regsvr32.exe ole32.dll /s
regsvr32.exe shell32.dll /s
regsvr32.exe initpki.dll /s
regsvr32.exe wuapi.dll /s
regsvr32.exe wuaueng.dll /s
regsvr32.exe wuaueng1.dll /s
regsvr32.exe wucltui.dll /s
regsvr32.exe wups.dll /s
regsvr32.exe wups2.dll /s
regsvr32.exe wuweb.dll /s
regsvr32.exe qmgr.dll /s
regsvr32.exe qmgrprxy.dll /s
regsvr32.exe wucltux.dll /s
regsvr32.exe muweb.dll /s
regsvr32.exe wuwebv.dll /s
net start wuauserv /y
net start DoSvc /y
net start appidsvc /y
net start cryptsvc /y
bitsadmin.exe /reset /allusers
wuauclt.exe /resetauthorization /detectnow
wuauclt.exe /reportnowGood luck! This stuff sucks.
Thursday, July 20, 2017 12:23 PM -
Nope. Not a fix for me.Thursday, July 20, 2017 3:29 PM
-
I had this issue in 1607 and it turned out the computer was going into "Dual Scan" mode... which enabled windows update for business, introduced in 1607. Choosing a combination of the correct GP's as seen in the comments of the page linked below solved the problem. Now I'm testing 1703 and have the issue again, and it looks like the computer is again stuck in dual scan mode.
These commands in powershell will show you what type of Windows Update service you're currently using.
$MUSM = New-Object -ComObject "Microsoft.Update.ServiceManager"
$MUSM.Services
The below page (in the comments section) details the settings for 1607 that get you out of dual scan mode. Now I just need a solution for 1703, because it appears that MS has changed something again....
https://blogs.technet.microsoft.com/wsus/2017/05/05/demystifying-dual-scan/
- Edited by Bingly Friday, July 21, 2017 5:54 PM Typo fixed
Friday, July 21, 2017 5:50 PM -
Hi -
Monitoring this thread as I also have the same issue with new PC installation on Win10 1703 not being able to scan against WSUS. Our new machines are deployed via a SCCM task sequence and I have tried the above suggested idea of disabling "Install Software Updates" - however my finished machine was still unable to check for updates :( First scan against WSUS returns error 0x8024000d.
Monday, July 31, 2017 10:33 AM -
Hi all,
Just adding my two cents here. I have the exact same issue - new Win10 1703 machines unable to check for updates against my WSUS servers with the same error 0x824000d.
Today I have deployed 2 fresh machines (via SCCM) and with a "Vanilla" copy of Windows 10 1703 (no updates) and both machines are unable to check for updates.
I have found that manually downloading and installing the July cumulative update KB4025342 and rebooting, they are now scanning against WSUS without error.
DMValent suggested installing KB4022716 is fixing the issue for him, but this update is replaced by the July cumulative update and appears to have the same result. So thanks DMValent. I am not sure what the July update has changed which is working for us, but lets hope something in this update is a proper fix.Any comments welcome.
Monday, July 31, 2017 10:57 AM -
We have resolved this issue in our environment. Make sure you have done the recommended changes for this issue in 1607, you'll find them in the comments of this blog post. (https://blogs.technet.microsoft.com/wsus/2017/05/05/demystifying-dual-scan/)
For 1703 there are some additional items that need to be changed to keep you out of "dual scan" mode which keeps your machines connecting to the WSUS server. Oddly, these settings get reset any time a user goes into the "Advanced" area of Windows update. For this reason, a group policy to delete the below keys may be the best option as they will get checked/deleted at login and regular GP intervals.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings
"BranchReadinessLevel"=dword
"DeferFeatureUpdatesPeriodInDays"=dword
"DeferQualityUpdatesPeriodInDays"=dword
"ExcludeWUDriversInQualityUpdate"=dwordThis solved it for us, who knows what fresh hell they will introduce in the fall that we will have to figure out again.
Monday, July 31, 2017 2:38 PM -
See here:
There is a lot of confusion in this thread between fresh installs, and upgrades, and at least in my case there is a big difference depending on how your settings are being applied for Windows Update.
-Matt
There's no place like 127.0.0.1
- Proposed as answer by Matt5150 Tuesday, August 8, 2017 4:03 PM
Tuesday, August 8, 2017 4:02 PM -
Hi All!
I overcame this issue updating Symantec Endpoint Protection client to version 14.0.2349.0100. As soon as I did this, the installation of Windows 10 1703 through Windows Update worked like a charm.
Tuesday, October 3, 2017 2:27 PM -
This fixed the issue for me. Thanks!Sunday, December 3, 2017 3:50 PM