MECM/SCCM Windows updates/Software Updates 0x8024401f

[Garacesh]

Right. I give up.

I've tried everything I can possibly think of, now I'm coming to you lot, arms outstretched, bowl in hand, "Please sir, I want some more..."

Try as I might, I just cannot get MECM to push out Windows Updates.

 

The server is a Windows Server 2019 Hyper-V machine, with the Web Server (IIS) and Windows Server Update Services roles, as well as the Background Intelligence Transfer Service (BITS) feature installed.

Whilst WSUS is installed, I haven't configured it in any way, in fact, I've just launched it to check, and been given the Before You Begin wizard, which I then cancelled out of.

The firewall on the server has inbound and outbound rules allowing :80, :443, :8530 and :8531 (both TCP and UDP because I couldn't get a solid answer on which one it is...) as those are the ports WSUS and IIS use.

The WsusPool Application Pool in IIS has had its Private Memory Limit increased to 4194000 to stop it falling over all the time.

The instance of MECM/the Site Server has the Software Update Point role, on the standard :8530 and :8531 ports, configured to obtain updates from Microsoft.

The server is set as the Site system server of the boundary group, and most devices in the Devices list are showing the correct Site Code and Boundary Group(s) (there's the occasional blank)

 

If I fire up the Configuration Manager Console, and go to Software Library / Software Updates / All Software Updates, the list is populated in all its green-arrow-y glory.

Some of them even say required!

But those that do only say Required: 1, Installed: 0, Percent compliant: 0, Downloaded: No, Is Deployed: Yes - I initially thought this 'Required' meant the update was assessed to be as matching one of the ADRs, but there's only 21 of these 'Required: 1' updates, so it's not that...)

Those that don't, say Required: 0, Installed: 0, Percent compliant: 0, Downloaded: No, Is Deployed: Yes

 

I have automatic deployment rules set up, let's take my "PC Windows 10 Updates" ADR.

Product: "Windows 10" OR "Windows 10, version 1903 and later" OR "Windows 10, version 1903 and later"*
Superseded: No
Update Classification: "Critical Updates" OR "Definition Updates" OR "Security Updates" OR "Update Rollups" OR "Updates"

* Yes, that's in the product list twice. I have no idea why.

Clicking 'Preview' nets me a lovely list of 134 updates, at the time of writing.

 

This ADR is deployed to my 'All end-user computers' device group, which currently has 339 devices in it. These devices are all W10 endpoints.

If I manually search for updates on one of those devices, Windows Update throws 0x8024401f, which a few different sources (such as this one) have said enabling Directory Browsing in IIS fixes, however that has borne no fruit for me.

Navigating to http://server.domain.local:8530/ in a web browser drops me into a root folder with directories App_Data and aspnet_client

Navigating to /Content throws error 403, which I'm told is correct.

Navigating to /selfupdate gets me a directory with 2 subdirectories AU and WSUS3; and 2 files, iuident.cab and wuident.cab. Random sampling indicates I am fully capable of browsing these directories and downloading all the files within.

 

On the MECM server, WCM.log has no errors, or at least, nothing immediately obvious. I can see the occasional "wait timed out after 0 minutes while waiting for at least one trigger event.", "Timed out..." but nothing is highlighted in red or yellow.

The same applies to WSUSCtrl.log, nothing highlighted, nothing immediately out of place.

On my test endpoint, the reg keys at HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate: WUServer and SUStatusServer are both the correct hostname and port of the MECM server. GPResult /Scope:Computer shows the winning policy to be Local Security Policy, so it's not a rogue GPO screwing with the WSUS GPO settings.

 

If I run Get-WindowsUpdateLog on a client, however, I do get a bunch o' red.

Agent: *FAILED* [8024043D] GetIsInventoryRequired
WebServices: *FAILED* [8024401F] Web Service Call
ProtocolTalker: *FAILED* [8024401F] GetConfig_WithRecovery failed
ProtocolTalker: *FAILED* [8024401F] RefreshConfig failed
ProtocolTalker: *FAILED* [8024401F] RefreshPTState failed
ProtocolTalker: *FAILED* [8024401F] Sync of Updates
ProtocolTalker: *FAILED* [8024401F] SyncServerUpdatesInternal failed
Agent: *FAILED* [2084401F] Syncronize

Unfortunately, none of these errors give any further information about the failure. The keen-eyed amongst you may, like I, notice that most of those error codes are the same as the error code searching for updates gives me. Unfortunately this seems to be hindering rather than helping.

 

And this is where I sit, completely stuck for anything else to check now, Google results not really listing anything conclusive.

I'm really hoping about six of you are gonna swan into the thread and go "Oh that?! Yeah that's easy, just change X" and it's dead simple and I can just move on to other stuff

Edited May 4, 2021 by Garacesh
Version 2903 doesn't exist

[Garacesh]

XML. Malformed. Bloody. XML.

 

---

 

Solution was found

The Web.config xml that the IIS post-install task creates?

Broken.

 

After all the technet posts, blogs by helpful indian blokes, folks helping me on Discord, and historical threads on EduGeek, I accidentally stumbled across the solution by going through permissions on the WSUS Administration IIS Site, and opening up IIS Authentication settings of ClientWebService

 

Line 180 of C:\Program Files\Update Services\WebServices\ClientWebService\Web.config reads:

Turns out IIS doesn't particularly like having that multipleSiteBindingsEnabled="true" in there twice.

 

Why is it in there twice? Not a clue. Did I modify it? Pretty sure I didn't. All I did was change 400 to 800 as everyone recommended.

 

So, yeah. Three weeks wasted on a bork'd default config.

If nothing else, I hope this thread helps someone else in the future!

Edited May 7, 2021 by Garacesh

[Linfit]

SCCM - it just works.

 

Except it never, ever does.

[Norphy]

Yeah, but it’s no worse than a lot of the alternatives and a damn sight better than the others.

 

At least it’s not RM.