At the end of 2016 i had a chance to update our WSUS system. We’ve been using WSUS 3 version for almost 6 years on a rather old Windows Server 2008 platform. WSUS was installed as a separate service back then. And now we have used a new Windows Server 2012 R2 as a basis for it (of course, after the release of 2016 it can be considered as outdated already). WSUS 4 is now being deployed as a standard role (Server Role). All other requirements and features are selected and installed automatically. Although WSUS 4 itself both visually and in its functions hasn’t changed much. WSUS 4 deployment and configuration was a breeze and haven’t caused any problems, especially as it is so standartized and simplified in this case. But at the same time we have decided to launch a Windows 10 pilot (2 new PCs). So Windows 10 category and its updates have been enabled in our new WSUS system. And then the hell broke loose..
First of all, if you want to manage and deploy Windows 10 updates via WSUS, you have to provide a lot more storage space. Because one Cumulative update can take 1-1.5 GB 😯 Yes, i can’t wait for a time when MS will introduce their improved Windows 10 updates with a new Windows Update system, which should take less space (it should probably be revealed with the Creators Update in the Spring of 2017). The other thing to keep in mind – Feature Updates or Upgrades (how they are called in WSUS). These are not security or critical updates, but the new builds (just like SR1 – 1511 or Anniversary Update – 1607). WSUS 4 can’t normally deal with them without a few special hotfixes. So enabling this category without them can break your WSUS 4 system. We haven’t even tried this yet, as we are installing the newest build to this day – 1607. I might post about nuances of updating to the newer build via WSUS after the Creators Update arrives next year. But if you are installing WSUS 4, you can prepare for it in advance by installing those hotfixes and doing other required changes (more on this later).
Our problems have began just after enabling Windows 10 category and doing first synchronization of updates list. New installation of Windows 10 1607 couldn’t check for updates against WSUS and showed the 0x8024401C error (i already know this code by heart..) after a few minutes of checking. Moreover, our WSUS server was getting a 100% CPU load for at least ~5 more minutes. I will post all the steps of preparing WSUS 4 for deploying Windows 10 updates to avoid this error. But it won’t help to get rid of it completely. This error will still be there when a fresh installation of 1607 build is checking for updates on WSUS. So, Windows 10 has to be updated from the internet first (from Windows Update servers) and only then it can normally check for updates and get them from the WSUS. It is to be expected that this error will show up again in the future, when more updates accumulate. So we are already looking into WSUS replacement, like Intune or SCCM, especially when Intune can control various other parts of Windows 10, provide MDM features.
In order for WSUS to understand Windows 10 feature upgrades (maybe also other updates) one has to install those Windows Server 2012 R2 updates before synchronizing updates:
KB3159706 this one only distributed via Windows Update, so, before connecting the server to WSUS, you should go to Windows Update menu and check for updates, then go to Recommended section and install it from there. Then you should also make changes described in this article https://support.microsoft.com/en-us/kb/3159706 (they must be applied):
- Launch cmd via Run as Administrator and run this command:
“C:\Program Files\Update Services\Tools\wsusutil.exe” postinstall /servicing
Wait until it shows the „Post install has successfully completed“ message.
- Launch Server Manager > Add Roles and Features, on the Features screen expand the .NET Framework 4.5 Features > WCF Services – check HTTP Activation. Press Add Features > Next > Install. Close.
- Open services.msc – restart the WSUS Service.
- If you don’t use SSL with WSUS, you don’t have to apply the steps related to SSL.
Then the changes necessary to get rid of the above mentioned error are applied:
- Open the IIS Manager on the server, expand Sites, press on WSUS Administration site. Press on the Advanced Settings on the right. Expand Limits and in the field „Connection Time-out (seconds)“ instead of 180 put higher value, e.g. 320.
- In the Application Pools window press on the WsusPool, then go to Advances Settings > and in the Recycling section change Private Memory Limit (KB) to 0 (means unlimited size).
- Stop the IIS service (by pressing Stop in the IIS Manager, when you are on the SERVER (SERVER\administrator))
- Run Notepad via Run as administrator and edit C:\Program Files\Update Services\WebServices\ClientWebService\web.config file replacing:
<httpRuntime maxRequestLength=”4096″ />
<httpRuntime maxRequestLength=”204800″ executionTimeout=”7200″/>
Save the file overwriting the original (make sure it’s not of the txt extension, also, if you copy text from this site, make sure you paste it as a plain text without hidden formatting symbols or just type it in manually).
Start the IIS service.
In such way an already updated Windows 10 machine will be able to check for updates on WSUS. But a fresh installation of 1607 build will still show that error.
UPDATE: looks like MS has finally released a fix for the infamous 0x8024401C error. So one can first try installing it before tweaking the IIS settings. Prerequisites updates still apply though.
17 thoughts to “WSUS woes with Windows 10 [EN]”
Thanks very much for this post! I have just installed Windows Server 2016 with WSUS and was having a problem with some Windows 10 clients not being able to connect to the WSUS server. The logs showed lots of 0x8024401c errors. For 3 days I tried just about everything I could think of and many suggestions I found on Google and nothing helped. Then I found your post. After your suggested IIS changes and the web.config change, WSUS is now working as it should!
Would it be correct to assume that these time out problems are caused when a new WSUS installation tries to deal with the large number of updates found in initial scans? In my case it was about 71,000 items on the initial scan (with no filters set). If I had set filters before the first scan perhaps timeouts wouldn’t have been an issue?
Now that WSUS is working well, do you think I should try changing the IIS and web.config settings back to the default to reduce resources used by WSUS?
Again, thank you very much for posting this article!
Yeah, i’ve killed two weeks on this myself, so i figured it can be useful for someone. You are welcome 🙂
I do think these timeouts are caused by the large amount of items for a new Windows 10 client (or some bug in a fresh Windows 10 causing this). And also the fact that Windows 10 updates are huge compared to Windows 7, WS 2012, etc. I think WSUS is just not designed well for such scenarios. It was enough to kill WSUS by only enabling Windows 10 product in the settings and doing a first scan (not even approving any update). Once you start to check for updates in the client, WSUS goes nuts and the client gets that error.
If you are not going to enroll somewhat fresh Windows 10 clients, you can probably set those settings back. But i have left them like that. I think you might even need to bump them further in the future, once more updates accumulate. And i haven’t yet tried to deploy a feature update through WSUS (Creators Update is on its way).
I’d be very surprised if this issue is only affecting a few people. If you don’t mind, I’d like to put a link to your post on the WSUS mailing list to help it receive a wider distribution.
Sure, i don’t mind. Actually, this article is slowly getting the most popular by traffic here 🙂
Thank you very much for this post! This was driving me nuts when trying to figure out what’s wrong with WSUS (Server 2016). We use MDT to install new Windows 10 machines and randomly some computers doesn’t receive updates from WSUS. Showing error 0x8024401C. Seems that when installing only few computers at a time they receive updates ok but when there are more machines problems start.
For me i couldn’t even make to update one machine at a time. Maybe your server is just more powerful. Anyway, are you deploying 1607 version? There shouldn’t be such problems with 1703.
Many thanks for this been looking for a solution for the last few days
I had one problem when I copied the web.config line from your website it did not copy into Ansi mode correctly (weird speachmarks) which caused WSUS to stop working until I corrected the line
Thanks for the info, i will add a comment about copying this text.
Sadly, after all of the above, we are still having only mild success with our vanilla Server 2016 WSUS server. We see the same behaviour as you. As soon as either a Win 10 / Server 2016 machine performs a scan, the IIS Worker process on the WSUS server shoots up to 100% CPU usage and eventually, the client comes back with 0X8024401c. Any other client OS is absoluelty fine and will scan, download and install updates without any issues.
I haven’t tried Server 2016. What version of Win 10 are you using? Is it 1607 or 1703? With 1607 there is no other way as to first update it from the internet. Only then it should work with WSUS. I didn’t had to do anything with 1703. It updated right away, but my WSUS is already tweaked and i haven’t tried to reverse these changes, so i’m not sure if 1703 is not requiring them.
Before you connect server to your WSUS, try to install Servicing stack update (http://www.catalog.update.microsoft.com/Search.aspx?q=KB4013418). Maybe you’ll need run update detection repeatedly (2-3x), but it should work.
Same issue. In my case problems with wsuspool gone after unsuccessfull deinstall kb2919355 (changes rolled back after server reboot).
All my Windows 10 1607 and Server 2016 1607 had error 0x8024401c.
Some IIS Application Pool tuning tips didn’t help.
Adamj’s Clean-WSUS PowerShell 3 script running on WSUS Srv solved the problem: