Event ID 364 and 10032: WSUS cannot download update content to the server

Fix it now

Metadata and content travel separately, which is why the console fills with updates that never reach a client. The catalogue arrived; the files did not. Work out first whether the transfer never completed or whether the file arrived and failed verification, because those are two different faults.

netsh winhttp show proxy
Get-Service WsusService

1. Read the failing event and note whether it reports a failure to fetch the file or a failure to verify it once fetched. That single detail decides which half of this page you need.
2. Check the proxy WSUS is configured to use, in the console under Options and then Update Source and Proxy Server, and the machine-level proxy in the output above.
3. Confirm the content volume has free space and the content directory exists at the path WSUS is configured to use.
4. If files arrive and fail verification, look at whether a proxy is inspecting and re-signing HTTPS between the server and Microsoft, and have the update endpoints excluded from inspection.
5. If the server holds the files and clients still cannot fetch them, the fault is in IIS: check the MIME types on the content virtual directory.

Approvals are not the problem here, and neither is the catalogue. Both look correct throughout, which is exactly why this failure goes unnoticed until an audit asks why nothing has patched.

If new files appear in the content directory and a test client installs an approved update end to end, you can stop here. The next section explains where the pipeline breaks.

Why it happens

There are two journeys and they fail independently. Metadata synchronises from the upstream source and fills your console with updates. Content is fetched separately, as files, and written into the WSUS content directory, from which clients pull them over HTTP. A console full of approved updates tells you the first journey worked and says nothing at all about the second.

Each file is checked after it arrives. If what landed does not match what the metadata says it should be, WSUS rejects it rather than serve a payload it cannot vouch for. That is a verification failure, and it is a different problem from a transfer that never completed. A proxy performing TLS inspection, a captive portal returning a login page instead of a file, and an antivirus product leaving a partially written file all produce it.

None of the event IDs in this family has published message text, so read the event body for the file name and the reason rather than looking the number up. The two facts worth acting on are which stage failed – transfer or verification – and whether the content directory is usable at all.

Full reference

Transfer failure or verification failure

The MIME map problem, in detail

This one is worth knowing precisely because the error message points away from the cause. WSUS added MIME types to support newer update packaging, and a server where an administrator previously added those types by hand ends up with them defined twice. IIS then refuses to load the configuration with a message naming the duplicate entry and the file extension.

The documented fix is to find where the type is set with an entry type of local – which may be at the WSUS Administration site level or on a web service rather than at the server level, where it belongs – open the web.config in that location, and insert a removal immediately above the mapping:

<configuration>
  <system.webServer>
    <staticContent>
      <remove fileExtension=".wim" />
      <mimeMap fileExtension=".wim" mimeType="application/x-ms-wim" />
      <remove fileExtension=".msu" />
      <mimeMap fileExtension=".msu" mimeType="application/octect-stream" />
    </staticContent>
  </system.webServer>
</configuration>

Type the MIME string exactly as it appears above. It is not a typo you should correct: it is what the documented configuration contains, and changing it produces a mapping that does not match.

Keeping the content store small enough to manage

When only some updates fail

Two patterns explain most of it. Size: very large payloads are more exposed to proxy timeouts, to transient connection loss and to running out of space part way through, so they fail while everything smaller succeeds. And type: a file whose extension has no MIME mapping fails consistently for clients while every other file is served, which looks like a per-update problem and is a per-extension one.

Confirming both halves of the path

1. Force a download and confirm new files appear in the content directory.
2. Request one of those files directly over HTTP from a client and confirm it is served rather than returning an error.
3. Approve one small update to a test client and let it install end to end.
4. Check the console’s last-contact and status columns for that client afterwards, which proves reporting works as well as delivery.

Doing all four matters because each proves a different link. A server that downloads perfectly and cannot serve, and a server that serves everything it has but downloads nothing, produce the same complaint from the same people.

Every code this article covers

Confirm the fix worked

1. New content files appear in the WSUS content directory after forcing a download.
2. A full synchronisation and download cycle passes with no new download failure events.
3. Requesting one content file directly over HTTP from a client returns the file.
4. A test client installs an approved update end to end, proving both halves of the path.
5. That client’s status is visible in the console afterwards, proving reporting as well as delivery.

Questions people ask about this