5

I have a Windows Server 2016 running WSUS (WID Database). The nodes on my system are all Windows 10 Professional. They are configured through group policy to check the Server 2016 for updates. The nodes and server are not behind a proxy in anyway.

Based on the WSUS Console it shows all the nodes are checking in when I press "Check for Updates". When you look on the node it throws the following message:

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 informaiotn, this may help: (0x8024401c)

I have googled this error and I have found little information or none at all for this error. I have tried all of the suggestions I could find but nothing has resolved this issue. What I can make out of the last .ELT file when I open it with word is:

There was an error communicating with the endpoint at http://FQDN:8530/ClientWebService/client.asmx. There was an error receiving the HTTP reply. The operation did not complete within the time allotted.

When I do a Get-WindowsUpdateLog in PowerShell I just get a long list of updates it can't find. No actual communication information.

I can get to that link if I put it in to a browser and the firewall is not blocking WSUS. What am I missing? Can anyone supply me with any other information. I am also still learning how to actually read ELT files using the correct procedure.

EDIT 1: Attempting to run the Characters and WDK10 on the client to interpret the ELT files better.

EDIT 2: Running the tracefmt.exe tool gives me the following Error:

Cannot Open logfile for reading

This happens on everyone. I do see from TraceView from the SDK tool kit that all the events show system times and No Format Information found. Is it connected and not getting this data or is it just looking for all these updates?

JukEboX
  • 801
  • 3
  • 14
  • 39
  • 1
    If you are running version 1607 of Windows 10, and if none of the cumulative updates have been installed yet, you may be running into a problem with the Windows Update client. Try downloading and manually installing the January cumulative update on a test machine, see if that helps. (I say the January update rather than the latest one only so that there's still something for the Windows Update client to do, for testing purposes.) – Harry Johnston Feb 28 '17 at 20:44
  • Thanks @HarryJohnston I will give it a try. I also did some messing with the timeout. I will update the question. I am also waiting for my mainstream server to finish getting all the updates before I try another test with all the updates till today. – JukEboX Feb 28 '17 at 20:46
  • The other possible cause is if you've selected too many products and/or categories for synchronization to the WSUS server, or if you haven't declined enough of the updates you don't need. There are about 40,000 updates altogether if you select everything and I found that WSUS just can't cope with anywhere near that many. (As a lower bound, my WSUS server is working well at the moment, and it has about 5000 declined and 800 non-declined updates. Given your symptoms I'd guess that it is the number of non-declined updates that matters most, but that is just a guess.) – Harry Johnston Feb 28 '17 at 21:31
  • @HarryJohnston - on that point, be very careful with your configuration when/if you select Drivers. Likewise take care sync'ing from an upstream server (USS) to ensure it does not overwhelm the downstream capacity. – Matthew Wetmore Oct 19 '17 at 04:19
  • @MatthewWetmore, for what it's worth, although my WSUS server ground to a near halt after I added the Drivers category, it was OK once I declined all the ones that weren't detecting as needed. So it does seem that it is the number of non-declined updates that matters most. I found the Drivers category to be pretty useless though, a single machine would detect a dozen or more distinct but identical-looking drivers for the same device and there was no obvious indication which one to choose. – Harry Johnston Oct 20 '17 at 00:23
  • ... plus, there was no obvious relationship between the drivers WSUS detected as needed and the drivers Microsoft Update offered. In the end of I just declined the whole lot and turned the category back off. – Harry Johnston Oct 20 '17 at 00:24

4 Answers4

8

I made the following changes in the IIS Application Pool for the WSUS Page:

  • Queue Length: 25000 from 10000
  • Limit Interval (minutes): 15 from 5
  • "Service Unavailable" Response: TcpLevel from HttpLevel
  • Private Memory Limit (KB): 0 from 18342456

This allowed for a longer amount of time needed for Windows 10 to connect and check for updates, Reset the connections for all machines and allow for more memory for processing of updates which was a suggestion I found on a google search.

JukEboX
  • 801
  • 3
  • 14
  • 39
2

All my Windows 10 1607 and Server 2016 1607 had error 0x8024401c.

Some IIS Application Pool tuning tips didn't help.

Running Adamj's "Clean-WSUS" PowerShell 3 Script on the WSUS server solved the problem:

http://community.spiceworks.com/scripts/show/2998-adamj-clean-wsus

https://community.spiceworks.com/topic/1970827-wsus-on-server-2016-windows-10-1607-client-0x8024401c-error

Swisstone
  • 6,357
  • 7
  • 21
  • 32
Peter Feldhammer
  • 21
  • 1
  • That script's option to index the database resulted in an enormous improvement for my WSUS server, not just during client check-ins, but when using the management console. I strongly recommend taking that step for anyone with more than a few thousand updates in total on their server. On the other hand, the function to delete the driver updates seemed to mess up WSUS quite badly - I was getting synchronization errors and it also messed with the client "no status" counts. So while this script is very useful, some care needs to be taken. – Harry Johnston Aug 21 '18 at 22:01
1

Made the following changes in the IIS Application Pool for the WSUS Page:

  • Queue Length: 25000 from 10000
  • Limit Interval (minutes): 15 from 5
  • "Service Unavailable" Response: TcpLevel from HttpLevel
  • Private Memory Limit (KB): 0 from 18342456

August 28, 2017—KB4039396 (OS Build 14393.1670)

Improvements and fixes:

  • Addressed issue with WSUS update metadata processing that can cause some clients to time out with a 0x8024401c error.

  • Increase the ASP.NET timeout

  • Make a copy of \Program Files\Update Services\WebServices\ClientWebService\Web.Config.

  • Open \Program Files\Update Services\WebServices\ClientWebService\Web.Config.

  • Find the element “<httpRunTime”. It will look like this (in an unmodified web.config): <httpRuntime maxRequestLength="4096" />
  • Modify httpRunTime by adding an executionTimeout attribute: <httpRuntime maxRequestLength="4096" executionTimeout="3600" />
  • Save the web.config to a different location and copy the modified one into the directory.
  • From an elevated command prompt, run IISReset to restart IIS.
  • Monitoring WSUS Metadata Caching

One has to be really Patient after IISReset and force some clients to contact WSUS so that cache is rebuild. After cache size is stable it will work

alexander.polomodov
  • 1,060
  • 3
  • 10
  • 14
Sri Gokul Ravichandran
  • 11
  • 1
1

I had created a brand new Windows 2016 domain, added a couple of member servers, and made one of them a WSUS role, just to try it out. After configuring the GPOs and having one of the servers check for updates, WSUS consistently crashed with the 0x80244022 which I guess meant that the worker process had crashed and the service was unavailable. No matter how many times I tried, same result. I just had to change the private memory limit in the app pool recycling settings from 1800 MB to 4,096 MB, restarted the app pool, PROBLEM SOLVED! I then saw that a single Windows 2016 Server can use up to 2.5 GB of that app pool in its initial scan. So basically, Windows 2016 WSUS app pool defaults are obsolete and need to be updated.

AbeyMarquez
  • 129
  • 4