WSUS Not Downloading Updates: Diagnose Content and Download Failures

WSUS sync succeeds. Updates appear in the console. You approve a cumulative update – and the wsus not downloading updates symptom appears: it sits at Not Downloaded, flips to Failed, or shows Downloading 0.00 MB of 612 MB indefinitely. The console opens, metadata sync completes, but the actual update binaries never land in WsusContent. This is a content-download failure, not a sync problem.

This guide covers wsus not downloading updates at the server level – the WSUS server acquiring files into its own local content store – from Microsoft Update or an upstream WSUS server. It does not cover clients downloading from WSUS, clients failing to report, or a metadata synchronization that is itself failing.

Do not begin by deleting WsusContent, clearing all BITS jobs, editing SUSDB, or running wsusutil reset. First capture the Event 364 reason, BITS error code, source URL, destination path, and BITS job owner. Destructive cleanup can remove the best evidence and multiply the recovery workload.

Before troubleshooting: confirm local content storage is enabled

Not every WSUS server stores update files locally. Check Options > Update Files and Languages > Update Files. If clients are configured to obtain approved files directly from Microsoft Update, an empty or minimally populated WsusContent folder is not by itself a fault. Also confirm how your server handles download timing – WSUS can be set to download files only after approval or to pre-download on sync.

Three scoping questions narrow the problem further:

• Do updates appear in the console at all? If the Updates list is empty or sync shows Failed, that is a metadata synchronization problem – see WSUS Sync Failed.
• Is the problem the server filling its own content store, or clients pulling from it? If clients show 0 KB downloads or are absent from the console while the server’s WsusContent store is populated, see WSUS Client Not Reporting. This article covers the WSUS server acquiring content from its configured upstream source: Microsoft Update or another WSUS server.
• Add the File Status column. In All Updates, right-click the column header and add File Status. This shows per-update whether files are Downloaded, Not Downloaded, or download-failed.

Metadata sync vs. update-file acquisition

WSUS handles update metadata and update binaries as separate stages of the update workflow.

Metadata synchronization. The WSUS server contacts Microsoft Update or an upstream WSUS server and writes update metadata, classifications, applicability rules, and configuration data to SUSDB. A top-level WSUS server uses Microsoft’s HTTPS synchronization endpoint for metadata.

Update-file acquisition. When local content storage is enabled, WSUS downloads the required update binaries into WsusContent. With deferred downloads enabled, this begins after an update is approved. BITS performs the file transfer. Microsoft requires the internet-connected WSUS server to reach the documented update domains on ports 80 and 443 because payload acquisition can use both HTTP and HTTPS endpoints. BITS is the service WSUS uses for server-side acquisition of update files. Client-side download behavior on modern Windows can also involve Delivery Optimization and is outside this article’s scope.

The useful distinction for diagnosing wsus not downloading updates: metadata synchronization and binary acquisition are separate stages with overlapping network dependencies. Metadata can synchronize successfully while content acquisition still fails because of BITS, local storage, permissions, proxy authentication, range handling, or content inspection.

Ordered diagnostic workflow

Step 1 – Capture Event 364 and SoftwareDistribution.log evidence

Read what WSUS is telling you before changing anything. Two sources matter:

SoftwareDistribution.log at %ProgramFiles%\Update Services\LogFiles\SoftwareDistribution.log. Search for ContentSyncAgent. On failure you will see ContentSyncAgent.JobError with an HTTP status and EventId=364.

Application Event Log, source Windows Server Update Services:

• Event 364 – “Content file download failed.” The reason string is the single most actionable piece of information. Common variants:
  • Reason: HTTP status 404 – the remote endpoint or intermediary returned file not found. Verify the exact source URL, upstream content availability, and whether the update revision is still valid. A 404 from a downstream IIS server may also indicate missing UUP MIME types (see Step 7). Treat name-resolution failures separately – those produce 0x80072ee7.
  • Reason: The requested resource requires user authentication – proxy authentication failure for a top-level server downloading from Microsoft, or IIS anonymous authentication on an upstream WSUS server’s Content virtual directory for a downstream server.
  • Reason: CRC verification failure – the received bytes did not pass WSUS integrity verification. Inspection gateways and proxy caches are common causes, but also rule out a stale partial file, local antivirus interference, storage corruption, and a transient source issue before assigning the root cause.
  • Reason: The server does not support the necessary HTTP protocol... BITS requires that the server support the Range protocol header – a proxy or inspection gateway is interfering with HTTP range requests (see Step 6).
  • Reason: Access is denied – NTFS permissions on the content root or WsusContent (see Step 3).
• Event 10032 – “The server is failing to download some updates.” Roll-up alarm. Drill into Event 364 entries for specifics.

Record the exact reason string. Event 364 may show HTTP failures as readable reason strings while BITS reports the corresponding HRESULT code.

Step 2 – Inspect BITS service and jobs

BITS handles the actual file transfers.

Verify the service is running. From an elevated prompt:

Note the required space after obj=. If the service account is misconfigured, correct it and restart before proceeding.

Inspect the jobs:

Read the key fields:

• OWNER – identifies the security context that owns the job. WSUS content jobs are commonly shown under NT AUTHORITY\NETWORK SERVICE, but verify the actual value rather than assuming it.
• STATE – TRANSIENT_ERROR means BITS is retrying; ERROR means the job requires intervention.
• ERROR FILE – shows the source URL and destination path. Test the source URL from the WSUS server to establish basic reachability for the machine.
• ERROR CODE – the machine-readable failure code.
• PROXY USAGE – shows the proxy mode used by that specific BITS job.

If the URL works in a browser but the BITS job fails, the URL is reachable for the signed-in user. That does not prove that the WSUS BITS job can use the same authentication, proxy route, range handling, or inspection policy.

On BITS queue management. WSUS limits concurrent content downloads, so a set of repeatedly failing jobs can make the remaining queue appear stalled. Do not clear the entire BITS queue simply because WSUS has transient errors. First record the failing job IDs and fix the underlying cause. Get-BitsTransfer -AllUsers | Remove-BitsTransfer cancels all BITS jobs on the server and deletes their underlying transfer state and temporary files – use it only when the queue itself is demonstrably corrupt or permanently wedged, not as a routine troubleshooting step. bitsadmin /reset /allusers has the same scope.

Step 3 – Check content-root and WsusContent permissions

If Event 364 says Access is denied or the BITS error code is 0x80070005, suspect NTFS permissions. Microsoft’s legacy WSUS server-verification reference still documents the ACLs required for BITS content downloads:

• The content root – the parent directory of WsusContent, such as D:\WSUS when the binary store is D:\WSUS\WsusContent – must be traversable/readable by NT AUTHORITY\NETWORK SERVICE.
• WsusContent itself must grant Full Control to NT AUTHORITY\NETWORK SERVICE. WSUS setup configures this, but security software can reset it.

Verify first before changing anything:

If the required ACEs are missing or wrong, grant them after confirming what is absent:

After changing permissions, restart the Update Services (WsusService) service and observe whether new BITS jobs succeed.

A note on the WsusPool application-pool identity: WSUS uses NetworkService as the default WsusPool identity. Changing it to ApplicationPoolIdentity requires additional ACL and SUSDB permissions to be granted manually. Leave it as NetworkService unless there is a specific documented reason to change it.

Step 4 – Check content-volume space and database-growth errors

Two distinct exhaustion failures present as server-side wsus not downloading updates conditions.

Content volume full – BITS 0x80070070. When the WsusContent volume runs out of space, BITS cannot write and downloads fail. Check free space on the content volume first. If genuinely undersized, general disk diagnosis belongs in Windows Server Storage Troubleshooting. Content reclamation is covered in WSUS Maintenance.

Database growth errors. Check the database engine version before assuming a specific size ceiling. SQL Server Express editions through SQL Server 2022 have a 10 GB per-database limit. SQL Server 2025 Express raises the relational database limit to 50 GB. WID is not subject to the SQL Server Express licensing ceiling, and Microsoft’s current WSUS deployment guidance does not document a specific WID database size limit.

If SUSDB cannot grow, SQL errors and WSUS bookkeeping failures can accompany content-download symptoms. Confirm the actual SQL edition and version and inspect database-growth errors in the Application event log rather than diagnosing from file size alone. Database maintenance and migration are covered in WSUS Maintenance.

Step 5 – Check the WSUS proxy and required upstream endpoints

WSUS stores its upstream proxy configuration in the WSUS server configuration, while BITS performs the file transfer under the job’s effective owner and proxy settings. A successful metadata synchronization or browser test does not prove that the BITS content job can authenticate through the same path. Compare:

• Options > Update Source and Proxy Server – WSUS configured proxy
• The failing BITS job’s OWNER
• The job’s PROXY USAGE
• The exact source host shown in ERROR FILE

Verify WSUS proxy settings in the console, or via PowerShell (anonymous proxy example – does not configure authenticated credentials or a separate SSL proxy):

After an OS upgrade, WSUS post-install operation, or proxy-account change, re-enter and verify the proxy credentials rather than assuming the stored secret is still valid.

Confirm that the Microsoft Update domains documented in Step 2: Configure WSUS are reachable on both ports 80 and 443 from the WSUS server.

Step 6 – Check range support, inspection, and integrity failures

BITS background transfers use HTTP range requests: the client sends a Range request header and expects a valid partial-content response, normally including Content-Range. A proxy or firewall that strips the request header, returns the full file incorrectly, or changes the response can cause 0x80200013 / BG_E_INSUFFICIENT_RANGE_SUPPORT.

Inspection gateways, AV proxies, and secure web gateways can interfere with range negotiation or alter cached response content. When Event 364 reports a CRC or hash verification failure, test the same payload without inspection and also rule out stale partial content, local antivirus interference, and storage errors before assigning the root cause.

The preferred fix is to configure the inspection gateway to pass Range, Content-Range, Content-Length, and HEAD behavior unchanged for Microsoft Update payload traffic and not rewrite the response body. Use the vendor’s current documentation for the exact inspection-bypass setting. The Microsoft-documented approach for SonicWall devices (KB 922330) is to enable HTTP Byte-Range request support in the Gateway AV configuration or add the WSUS server to the exclusion list. Create a bypass that preserves HTTP range behavior and does not rewrite the response body. Use the vendor’s current documentation for the exact setting.

For confirmed range-request problems where appliance bypass is not immediately possible, Microsoft documents a legacy WSUS database setting that forces BITS foreground priority. That procedure targets older WSUS 2.0/3.0 database layouts. Do not treat a direct SUSDB edit as a routine fix – use it only with a procedure verified against the installed WSUS version, a current backup, and an approved rollback plan.

Step 7 – Verify the configured local content path after a move

After moving the WsusContent folder to a different drive or path, the registry and the WSUS configuration must agree on the location:

If these disagree after a content move, WSUS writes to one location while searching for files in another. Microsoft advises managing WSUS through the console or API rather than by accessing its internal database schema directly.

Downstream WSUS only: check IIS Content delivery and UUP MIME types

If this server downloads files from an upstream WSUS server rather than from Microsoft Update, test the exact /Content/... source URL shown in Event 364 from the downstream server. On the upstream WSUS server, verify:

• The Content virtual directory points to the correct WsusContent path.
• Anonymous Authentication is enabled for the Content virtual directory.
• The upstream and downstream servers use compatible local-content storage settings.
• The upstream server has current WSUS-related cumulative updates installed.
• .wim and .msu MIME types required for on-premises UUP content are present at the IIS server level and inherited by the WSUS Administration site.

Missing UUP MIME mappings can cause HTTP 404 failures for Windows 11 and UUP payloads even when metadata synchronization and non-UUP content downloads succeed.

Error-code quick reference

Event 364 may show HTTP failures as readable reason strings while BITS reports the corresponding HRESULT.

wsusutil reset: purpose, prerequisites, and operational cost

wsusutil reset is frequently recommended as the first response to wsus not downloading updates. That order is backwards.

What it does. It checks whether every update-metadata row in SUSDB has corresponding local files and downloads files that are missing or fail integrity verification. It does not reset WSUS configuration, clear approvals, or wipe the database.

When it is appropriate:

• After fixing the underlying cause (permissions, proxy, firewall, disk) and wanting WSUS to retry failed or corrupt files.
• After restoring SUSDB from backup.
• After manually removing corrupt files from WsusContent.
• When an approval fails because the update has no Terms and Conditions files.

Prerequisites – confirm these before running it:

• WSUS is otherwise healthy: console connects, WsusService and BITS services run.
• The configured content source is reachable if files need to be re-downloaded.
• The outbound HTTP path and permissions are fixed – running reset while the underlying path is still broken just re-queues the same failures.
• You have confirmed free disk space and available bandwidth for the resulting downloads.

When to avoid it: if metadata sync is still failing (see WSUS Sync Failed), if the content volume is full, or if you have not yet identified the Event 364 reason. Reset is a recovery step after diagnosis, not a substitute for it.

Verify the repair

After applying a fix for wsus not downloading updates, confirm that server-side content downloads have recovered:

• File Status – the affected updates change to Downloaded.
• WsusContent – expected files appear and the content store grows while outstanding downloads complete.
• BITS jobs – the affected jobs no longer remain in TRANSIENT_ERROR or ERROR. A job may briefly enter TRANSFERRED before WSUS completes and removes it from the queue.
• SoftwareDistribution.log – new content-download entries complete without a following ContentSyncAgent.JobError.
• Application log – no new Event 364 or 10032 entries for the affected files.
• Exact file check – the destination file shown in the earlier failure exists and has a plausible non-zero size.

Prevention

• Allow Microsoft Update payload traffic without destructive inspection. A common recurring cause of wsus not downloading updates is a proxy or security gateway that breaks HTTP range handling or alters downloaded content.
• Monitor the WsusContent volume. Alert before free space becomes low enough to interrupt BITS writes.
• Run regular WSUS maintenance. Decline unneeded updates and perform cleanup so content and SUSDB growth remain controlled. See WSUS Maintenance.
• Patch WSUS servers that provide UUP content. Confirm the .wim and .msu MIME mappings are present when required.
• After an upgrade, content move, or post-install operation, verify the proxy credentials, ContentDir, LocalContentCachePath, IIS Content path, and NETWORK SERVICE ACLs. These checks are especially important after operations that change the WSUS role, content path, IIS configuration, or proxy credentials.
• Record Event 364 details. Preserve the reason string, source URL, destination path, error code, job owner, and proxy mode for future incidents.

FAQ

Why does browsing to the update URL work while BITS still fails?

A browser test runs in the signed-in user’s security and proxy context. The WSUS transfer is performed by BITS under the context recorded in the job’s OWNER field, with the proxy behavior shown in PROXY USAGE. Browser success proves that the URL is reachable for that user, but it does not prove that the WSUS BITS job can use the same credentials, proxy route, range handling, or inspection policy.

When wsus not downloading updates, should I delete WsusContent and run wsusutil reset?

Only after the underlying cause is fixed and you have confirmed free disk space and outbound reachability. Running reset with a broken proxy, blocked path, or full disk reproduces the original failure at scale. Running it without fixing permissions means the newly downloaded files inherit the same broken ACLs.

How long does wsusutil reset take?

It depends on how many files need re-downloading and how many are already present and valid. On a well-maintained server where only a few files are corrupt, it completes quickly. On a server with a large proportion of missing content, it can run for a full maintenance window or longer. Monitor SoftwareDistribution.log and the WsusContent folder size – there is no progress indicator.

BITS shows TRANSIENT_ERROR but updates still show Not Downloaded – is it still retrying?

Yes. TRANSIENT_ERROR means BITS is retrying the transfer according to its retry policy. Transient errors resolve when the underlying condition clears. If a job stays in TRANSIENT_ERROR without progressing after the fix is applied, cancel and let WSUS re-queue it.

Sync works but only some updates fail to download – where do I start?

Look at what the failing updates have in common: product family, classification, file size, or publishing date. A pattern usually points to a specific failure – a particular endpoint returning 404, a content type blocked by inspection, or a file type triggering a missing UUP MIME mapping. The File Status column with a filter on the relevant product or classification makes this investigation faster.

References

• Windows Server Update Services overview – Microsoft Learn
• Troubleshoot issues with WSUS client agents – Microsoft Learn
• Troubleshoot WSUS synchronization and import issues – Microsoft Learn
• Fail to download a file by using BITS – Microsoft Learn
• BITS return values – Microsoft Learn
• Get-BitsTransfer – Microsoft Learn
• Remove-BitsTransfer – Microsoft Learn
• Verifying WSUS Server Settings – Microsoft Learn
• Step 2: Configure WSUS – Microsoft Learn
• Plan Your WSUS Deployment – Microsoft Learn
• Managing WSUS from the command line – Microsoft Learn
• Editions and supported features of SQL Server 2025 – Microsoft Learn