wsus clients stuck at downloading updates 0 percent for days

TL;DR

Clients stuck at 0 percent download against WSUS are usually waiting on the server, not broken themselves: the WSUS content download for those updates has not finished, the content folder or its permissions are wrong, or IIS cannot serve the files. Check the WSUS server content state for the exact updates first, confirm the server finished downloading them from Microsoft, and verify clients can fetch a content file. Only rebuild client caches once server content is proven good.

wsus clients stuck at downloading updates 0 percent for days

Use this when

• Multiple WSUS clients show downloading at 0 percent for the same updates for more than a day.
• The WSUS console shows those updates with files still downloading or failed on the server.
• Clients detect and approve correctly; only the download phase never moves.

Not for this skill when

• One client is stuck while others download the same update fine. Clear that client BITS job and cache.
• Clients fail detection against WSUS entirely. That is a scan or server health problem, not content download.

Steps

1. Pin down the exact content: note the KB numbers clients are stuck on, then in the WSUS console check each update file status and the server overall download status. If WSUS itself has not finished downloading the payload from Microsoft, every client will wait at 0 percent no matter what you do to them. Verify: you know whether WSUS holds complete payloads for the stuck updates or is itself still downloading
2. If server downloads are stalled, fix the server path to Microsoft: check the WSUS server proxy settings, free space on the content volume, and the BITS service on the server, which WSUS uses to fetch content. Restart a wedged server download by re-running synchronization after those checks. Verify: the server completes downloading the update payloads, shown by file status turning to downloaded in the console
3. Verify the content store on disk: confirm the WSUS content folder exists where the registry and console expect it, has room, and that its permissions let the IIS worker and network service read the files. A moved or permission-changed content folder after storage work is a classic silent cause. Verify: the content folder path, space, and read permissions are confirmed, and the expected payload files are physically present
4. Prove serving works with one test client: pick a stuck client, clear only its download state by restarting BITS and the update service, force a download, and watch both the client log and, if needed, the IIS log on WSUS for the content request and its HTTP result. A 200 in the IIS log plus client progress closes the server question. Verify: the test client download moves past 0 percent and the IIS log shows successful content responses
5. Roll out the confirmed fix: clients recover on their own once server content flows, so monitor the stuck count over the next day rather than touching every client. For the few still stuck after content is proven, rebuild their local download cache individually. Verify: the fleet stuck count falls steadily, and only individually broken clients remain for local cache repair

Why it happens

WSUS is a two-stage pipeline: the server first downloads update payloads from Microsoft into its content store, then clients download from the server. Client progress measures the second stage, but it cannot begin if the first stage never completed, and the client UI does not distinguish waiting for the server from a local fault. Server content stalls come from proxy changes, a full content volume, or a wedged server-side transfer, while serving stalls come from IIS or content folder permissions after storage changes. Checking the pipeline in order, server content then serving then client, prevents the common waste of rebuilding hundreds of healthy client caches.

Variants and edge cases

Stuck at 0 percent after WSUS content folder was moved

Moving content without using the WSUS move content tool breaks the recorded paths. Use the supported move procedure or restore the original path so metadata and files agree.

New updates download, old stuck ones never move

The old updates may be superseded or their files declined. Decline and replace them with the current cumulative update rather than reviving stale content.

Stuck at 0 percent only for clients at one site

A downstream WSUS or a site distribution problem is likely. Compare that site server content state with the upstream before touching its clients.

Compatibility: Applies to WSUS on Windows Server 2016 and later, standalone or as a Configuration Manager software update point.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstjHpbKy82SI2phynVg3G2Q