Event ID 12042 and 13042: WSUS self-update and authentication services fail

Fix it now

Self-update does not follow WSUS onto its custom port. Microsoft’s requirement is explicit: WSUS Setup creates a virtual directory named Selfupdate under the web site running on port 80, and you must have a web site running on port 80 even when the WSUS site is on a custom port.

cscript "C:\program files\microsoft windows server update services\setup\InstallSelfupdateOnPort80.vbs"
iisreset

1. In IIS Manager, confirm a site is bound to port 80 and that it contains a Selfupdate virtual directory. If the default web site was removed or repurposed, that is the fault.
2. Test from a client over HTTP on port 80 rather than the WSUS port: requesting the iuident.cab path from the server should return a file rather than a 404.
3. Run the InstallSelfupdateOnPort80 script above, which is Microsoft’s documented way to put the self-update tree back.
4. Confirm anonymous access on the Default Web Site, the ClientWebService and the Selfupdate virtual directories, which is what clients need before they have authenticated anywhere.
5. Check the IIS logs under %windir%\system32\LogFiles\W3SVC1 to confirm the requests are arriving and what they are answered with.

If the 12000-series web service events are present too, and a browser gets 503, this is not a self-update problem: the application pool is down and taking everything with it. Fix that first.

If self-update requests are answered and clients are reporting again, you can stop here. The next section explains what the self-update tree is for and what breaks it.

Why it happens

Before a client can talk to WSUS properly it needs a compatible Windows Update agent, and self-update is the mechanism that lets it fetch one. Because the client is bootstrapping, that request does not go to the port the WSUS administration site listens on. Microsoft’s wording is direct: Setup creates a virtual directory named Selfupdate under the web site running on port 80, that directory holds the latest WSUS client, and for that reason you must have a web site running on port 80 even if the WSUS web site is on a custom port. The site on port 80 does not have to be dedicated to WSUS – it only has to exist.

The paths involved are fixed. Clients fetch an identification file from the root of the server and their agent from beneath the Selfupdate directory, organised by architecture, operating system and language. That is why the failure is so binary: either a site answers on port 80 with those paths present, or nothing about the client’s agent update can work regardless of how healthy WSUS itself is.

The event IDs in this family have no published message text, so they are best treated as pointers to the IIS configuration rather than as diagnoses. What is documented, and what actually settles this, is whether a site exists on port 80, whether the Selfupdate directory is under it, whether anonymous access is permitted, and what the IIS log records when a client asks.

Full reference

What lives where

Testing it the way a client does

1. From another machine, request the identification file over HTTP on port 80 of the WSUS server.
2. A file means the self-update tree is present. A 404 means the directory or the site is missing.
3. A 503 means the application pool is stopped, which is a different article’s problem.
4. An authentication prompt or a 401 means anonymous access has been removed from a directory that needs it.
5. Check %windir%\system32\LogFiles\W3SVC1 for the request you just made and read the status code IIS recorded.

That sequence is worth following in order, because each outcome sends you somewhere different and three of the four have nothing to do with self-update itself.

What the repair script does

InstallSelfupdateOnPort80.vbs lives in the setup folder of the Update Services installation directory and is Microsoft’s documented way to ensure the self-update tree is working. It is a much narrower action than re-running the whole WSUS post-installation configuration, which rewrites the IIS configuration for WSUS generally. Prefer the script where the problem is the self-update tree, and keep the post-installation step for cases where more of the IIS configuration is damaged – and note your current virtual directory paths, bindings and content location before running that, so you can confirm afterwards that nothing you depended on changed.

Anonymous access, and why hardening breaks this

Clients contact the self-update tree and the client web service before they have authenticated anywhere, which is why anonymous access on those directories is part of the documented configuration rather than an oversight. A hardening baseline applied at the site level and inherited downwards will remove it, and the symptom is a set of clients that stop updating with a healthy-looking server. Check inheritance as well as the directory’s own settings, because a setting applied at the parent looks correct everywhere except where it matters.

When the server is healthy and the clients are not

• Read last-contact times in the console rather than the computer list. The console shows the last state the server recorded, so a client that stopped talking looks fine until you check the timestamp.
• Confirm the update server and status server policy values agree with each other and with the port WSUS is on.
• Confirm the clients can reach the WSUS port as well as port 80; self-update and the client web service are different endpoints.
• Where only newly built machines fail, compare their policy against a working machine rather than against the documentation.

How much self-update still matters

Current Windows versions carry an update agent serviced through normal updates, so self-update matters far less than it once did. It is still worth fixing, because a broken Selfupdate directory usually means the IIS configuration for WSUS has been damaged more broadly – a site removed, a path orphaned by a move, or a baseline that removed anonymous access across the whole server. The self-update failure is the visible edge of that, and the rest of it will surface later.

Every code this article covers

Confirm the fix worked

1. A site is bound to port 80 on the WSUS server and contains a Selfupdate virtual directory.
2. Requesting the identification file over HTTP on port 80 from another machine returns a file, not a 404, 401 or 503.
3. The IIS log under %windir%\system32\LogFiles\W3SVC1 records those requests with a success status.
4. A test client’s last-contact time updates in the console after a forced detection cycle.
5. The WSUS console itself still connects, confirming you have not broken the administration site while fixing port 80.

Questions people ask about this