sccm updates stuck at downloading 0 percent

Not specified by the original author.

TL;DR

A deployment pinned at 0 percent is a content transfer that started and stalled: check ContentTransferManager.log and DataTransferService.log for the job state, confirm the client can reach the DP over HTTP or HTTPS, look for BITS errors, and check that the Network Access Account or PKI certificate path is valid.

sccm updates stuck at downloading 0 percent

Use this when

• Software Center shows updates downloading at 0 percent indefinitely.
• Other deployments with applications download fine, or also stall, on the same client.
• The stall affects clients at one site or on VPN.

Not for this skill when

• The deployment deadline has not arrived and the client is correctly waiting. Check the deployment schedule first.
• The client is in a maintenance window blackout. The stall is policy, not transfer failure.

Steps

1. Read ContentTransferManager.log and DataTransferService.log and note the job ID and its last state or error. Verify: a concrete transfer error or a suspended state is recorded
2. Check the BITS service is running and list jobs with bitsadmin or Get-BitsTransfer for a suspended or error state. Verify: the job state matches the ConfigMgr logs
3. From the client, browse to the DP content URL shown in the logs. Verify: the DP responds without certificate or 401 errors
4. If the job is suspended by BITS policy or a metered connection setting, clear that condition and resume the job. Verify: bytes transferred begin increasing in the DTS log
5. Restart the SMS Agent Host service if the transfer subsystem is wedged, then re-evaluate the deployment. Verify: a new transfer job is created and progresses past 0 percent

Variant phrasings

sccm updates stuck downloading 0 percent bits

The BITS root-cause phrasing.

software center downloading 0 percent forever

The user-symptom phrasing.

content transfer manager job suspended fix

The log-based phrasing.

Compatibility: Compatibility: Configuration Manager current branch, BITS-based content transfer on Windows 10 and 11 clients.

Why it happens

Software Center shows the deployment state, not the transfer detail. Underneath, Content Transfer Manager creates a BITS job against a specific DP URL. BITS can suspend for policy, network cost, or errors, and the deployment layer simply waits, so the UI sits at 0 percent while the real story is in the transfer logs and the BITS job state.

Edge cases / pitfalls

• A client clock that is wrong breaks DP certificate validation and stalls HTTPS transfers; check time sync on stubborn cases.
• Peer cache and Delivery Optimization change where bytes come from; the logs still name the actual source chosen.
• Deleting the CCM cache mid-transfer makes the stall permanent until the deployment re-evaluates; avoid it as a first move.

Provenance

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

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

Thread query: sccm updates stuck at downloading 0 percent

TL;DR: A deployment pinned at 0 percent is a content transfer that started and stalled: check ContentTransferManager.log and DataTransferService.log for the job state, confirm the client can reach the DP over HTTP or HTTPS, look for BITS errors, and check that the Network Access Account or PKI certificate path is valid.

Not specified by the original author.

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

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

Thread query: 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.

Not specified by the original author.

TL;DR

A machine stuck at 100 percent has usually finished downloading and is wedged in the staging step, often on a corrupt SoftwareDistribution cache entry or a hung TrustedInstaller. Confirm there is no real activity in Task Manager, restart the Windows Update and BITS services, clear the download cache if it persists, and retry.

windows update stuck at 100 percent preparing to install

Use this when

• Settings shows Preparing to install 100 percent for over two hours.
• The update never offers a restart even though it says 100 percent.
• The same state survives a normal reboot.

Not for this skill when

• Progress is at 90 to 99 percent and still creeping up. Leave it alone; large cumulative updates stage slowly.
• The machine is mid-install after a restart with a percentage on a black screen. Never interrupt that phase.

Steps

1. Check Task Manager for TiWorker.exe and the Windows Update service activity for 10 minutes. Verify: CPU and disk use stay near zero, confirming a wedge rather than work
2. Restart the Windows Update, BITS, and Cryptographic Services from an elevated prompt with net stop and net start. Verify: all three services report running again
3. Retry the check for updates. Verify: the update moves past staging to a restart prompt, or restarts the download cleanly
4. If it wedges again at the same point, stop the services, rename the SoftwareDistribution and catroot2 folders, restart the services, and re-download. Verify: a fresh download begins and the old cache folders are recreated
5. Install and restart when prompted. Verify: Update history records the KB as installed

Variant phrasings

windows update preparing to install stuck

The message-first phrasing without the percentage.

windows update downloading 100 percent stuck hours

The download-side variant of the same wedge.

update stuck at 100 percent no restart prompt

The symptom phrasing focused on the missing restart offer.

Compatibility: Compatibility: Windows 10 and 11, and Server with the desktop experience; service names as shown.

Why it happens

The percentage shown in Settings covers download and staging, and the last step involves the component store committing staged packages. A damaged cache entry, a pending operation from an earlier failed update, or a hung installer worker can leave the UI at 100 percent while nothing is actually running, which is why confirming zero activity matters before resetting anything.

Edge cases / pitfalls

• Renaming SoftwareDistribution clears update history in the Settings view; export the history first if you need it for compliance.
• On metered or very slow links a large .NET or cumulative payload can legitimately sit near the end for a long time; check activity, not the clock alone.
• If the wedge returns for every update, run DISM restore health; the cache is a symptom and the store is the cause.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_kuoUqiH-IIsz99PeZqiH1A

Resolved from the public thread: https://vectle.com/posts/pst_kuoUqiH-IIsz99PeZqiH1A

Thread query: windows update stuck at 100 percent preparing to install

TL;DR: A machine stuck at 100 percent has usually finished downloading and is wedged in the staging step, often on a corrupt SoftwareDistribution cache entry or a hung TrustedInstaller. Confirm there is no real activity in Task Manager, restart the Windows Update and BITS services, clear the download cache if it persists, and retry.