0x80244017 and 0x80244024: WSUS rejects the client with 401 or 505

Fix it now

The 0x8024401x and 0x8024402x codes are HTTP statuses with a Windows wrapper round them. Microsoft publishes 0x80244017 as the equivalent of HTTP 401, the requested resource requires user authentication, and 0x80244024 as HTTP 505, the server does not support the HTTP protocol version used. The fix is in IIS and in the network path, not on the client.

netsh winhttp show proxy
netsh winhttp reset proxy
net stop wuauserv
net start wuauserv

1. Confirm which server the client talks to: read WUServer under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate, or run gpresult /h report.html.
2. From that client, open the client web service URL on the WSUS port in a browser. WSUS uses 8530 for HTTP and 8531 for HTTPS by default. You should get a service description page.
3. If you are prompted for credentials instead, anonymous authentication is off. On the WSUS server, open IIS Manager, select the WSUS Administration site, open Authentication and enable Anonymous Authentication.
4. If a proxy sits between client and server, take it out of the path or put the WSUS host in the bypass list, then rescan.
5. If the IIS log shows 405 against the client web service, check whether WebDAV Publishing is installed on that server. It handles verbs the client needs and can answer them with 405. Disable it for the WSUS site first, and remove the feature only if nothing else on the server uses it.

Anonymous authentication has to be checked at the site and on each virtual directory beneath it. A hardening baseline that disables it server-wide breaks WSUS every time it reapplies.

If a scan now completes, you are done. Below is the full code-to-status mapping and where the evidence lives on the server.

Why it happens

A WSUS client is an ordinary HTTP client. It posts SOAP requests to the client web service to register and pull metadata, reports to the reporting web service, and downloads binaries over BITS from the content path. Microsoft’s defaults give it two ports: 8531, which carries update metadata over TLS, and 8530, which carries the update payloads over HTTP. Every code in this family is an HTTP status the transport layer could not use, translated into a Windows error, which means the diagnosis is a web-server diagnosis rather than a Windows Update one.

That translation is the useful part. Once you know the status, the IIS logs on the WSUS server show you the exact request and its substatus, and the problem stops being an opaque hexadecimal string. 0x80244016 is 400, 0x80244017 is 401, 0x8024401A is 405 and 0x80244024 is 505. 0x80244023 is the odd one: Microsoft names it WU_E_PT_HTTP_STATUS_GATEWAY_TIMEOUT and glosses it as the request timing out waiting for a gateway, while printing the status in its own table as 503. Read it as a gateway or upstream timeout and look at whatever sits in front of the server.

The two headline codes have very different roots. A 401 almost always means anonymous authentication was disabled somewhere it should not have been, usually by a hardening baseline that was scoped too broadly. A 505 almost always means an intermediary is rewriting the request line: a proxy, a web application firewall, a load balancer or an inspection appliance. IIS itself speaks the HTTP versions the client uses, so WSUS rarely produces a 505 on its own.

Full reference

Code to HTTP status, as Microsoft publishes it

The 0x80244023 row is worth reading twice. Microsoft’s symbolic name says gateway timeout and its printed status says 503, which is normally service unavailable. Treat the code as an upstream timeout and confirm the actual status from the IIS log rather than from the code.

Default ports and paths

Where the evidence lives

Deleting the SusClientId values is a registry edit on a production machine. Export HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate first so you can put it back.

Moving to HTTPS without breaking the estate

Running the client connection over 8531 is worth doing, but the policy has to change at the same time. The WUServer value must use the https scheme and the matching port, and every client must trust the certificate chain. What you cannot do is require TLS across the whole WSUS website: Microsoft states that WSUS is designed to encrypt update metadata only, and its own guidance sets Require SSL on the individual web services rather than at the top of the WSUS Administration site, because content still moves over HTTP. An untrusted certificate produces different codes in the same family, so change one pilot group first and confirm the console shows them reporting before you move everybody.

Where WSUS itself stands

Before investing a weekend in tuning an ageing WSUS instance, it is worth knowing that Microsoft lists Windows Server Update Services among the features no longer in development, while stating that all existing capabilities and content continue to be available for current deployments. Nothing stops working, and there is no deadline attached, but it is a reasonable prompt to decide whether the estate should be moving towards a cloud-managed update service rather than being rebuilt around this one.

Checks that separate client from server

• Test from a client on the same subnet as WSUS with no proxy configured. Success there puts the fault in the path.
• Compare netsh winhttp show proxy and the WindowsUpdate policy key on a working and a failing machine.
• Read the current IIS log and confirm the POST to the client web service from that client returned 200.
• Check the last contact time in the WSUS console. A client that has never contacted the server at all is a different problem from one that is being refused.
• Confirm no second update mechanism is also configured on the device, since a client pointed at two places tends to report inconsistently.

Every code this article covers

Confirm the fix worked

1. From a previously failing client, the client web service URL returns a service description page with no credentials prompt.
2. A detection cycle completes and the WindowsUpdateClient operational log records a successful scan.
3. The WSUS console shows that client with a last contact time from the last few minutes.
4. The current IIS log shows the POST to the client web service from that client returning 200.

Questions people ask about this