WSUS Not Downloading Updates: A Read-First Sync, Content Folder, BITS, Proxy, and TLS Triage

Helpdesk: "Patch Tuesday was Tuesday. It's Friday, and the WSUS console still says 47 updates are needing files. The Windows 11 cumulative update is approved for the Pilot group, and the pilot PCs sit at 'Downloading - 0%'. Last night's synchronization shows Failed, and the Synchronizations page doesn't say why. A forum thread says to stop WSUS, delete the WsusContent folder, run wsusutil reset, and reinstall the role if that doesn't work. Can we do that before tonight's change window?"

Not yet. "WSUS not downloading updates" is two pipelines that fail separately: synchronization brings the update metadata, and the content download brings the files. Each one has its own log lines and its own fixes. Microsoft's WSUS API documentation: "WSUS downloads the update files and required license agreements in parallel with synchronizing the update metadata." Deleting WsusContent throws away every file that did download and makes the server fetch it all again through the same broken path. Work through it as a chain: the console state and what changed → the server's view: last sync result, updates needing files, download progress → the update file settings → SoftwareDistribution.log and event 364 → the path to Microsoft Update or the upstream server: endpoint, ports, proxy, inspection → TLS 1.2 and ciphers → the content folder: space, ContentDir, permissions → BITS on the server → Windows 11 UUP MIME types and the client's download from Content → disconnected servers fed by export and import. Get-WsusServer, the WSUS administration API, SoftwareDistribution.log, Get-WinEvent, Test-NetConnection, Get-Acl, and Get-BitsTransfer are the sources for that chain. Reinstall the role behind a proxy that strips Range headers, and the new server stops at the same file.

If the files are on the server and the problem is that clients never show up, never scan, or never report, read WSUS Clients Not Reporting first. It covers client policy, the scan source, the client proxy, WsusPool, and duplicate SusClientId values, so this post doesn't repeat them. This post covers "the WSUS server won't synchronize, or it synchronizes but approved updates stay at 'needing files', downloads sit at 0, event 364 says content file download failed, or Windows 11 updates never finish, and you need a read-first path before you delete WsusContent, run wsusutil reset, or rebuild WSUS."

TL;DR

• Sync and download are separate. A sync can succeed while files fail, and the other way round. Read GetLastSynchronizationInfo() and GetStatus().UpdatesNeedingFilesCount before you pick a layer.
• The console may hide the sync error. Microsoft's known issue: "After installing KB5070881 or later updates, Windows Server Update Services (WSUS) does not display synchronization error details within its error reporting." Read SoftwareDistribution.log instead.
• Event 364 names the reason. "Content file download failed. Reason:" is followed by an HTTP status or a BITS message, and each one points at a different layer (Step 4).
• The endpoint is TLS 1.2 only. Microsoft: https://sws.update.microsoft.com "accepts only Transport Layer Security (TLS) 1.2 connections." A cipher policy with no common cipher breaks sync the same way.
• BITS needs Range headers. Microsoft: "If you're behind a proxy server or behind a firewall that removes this header, the file copy operation is unsuccessful." Fix the proxy or inspection rule first. Foreground BITS is the documented fallback.
• Windows 11 needs two MIME types. .msu and .wim at the IIS server level, from a current cumulative update or by hand. Microsoft: "Clients using Windows 11 version 22H2 might fail to install updates from WSUS if the server isn't updated."

Where in the chain did it break?

Step 1: Capture the symptom (read-only)

Write these on the ticket first:

Then branch on what you see:

Step 2: Read the server's own view (read-only)

Start on the WSUS server, in an elevated PowerShell session with the UpdateServices module. One object gives you the sync result, the needing-files count, and the download progress:

# Read-only. Local WSUS server (no parameters = this server)
$wsus = Get-WsusServer

# Read-only. The last synchronization: result, times, error, and per-update import errors
$sub  = $wsus.GetSubscription()
$sub.GetSynchronizationStatus()
$last = $sub.GetLastSynchronizationInfo()
$last | Select-Object Result, StartTime, EndTime, Error, ErrorText
$last.UpdateErrors | Select-Object UpdateId, ErrorText -First 20

# Read-only. How many updates still lack files, and the bytes behind them
$wsus.GetStatus().UpdatesNeedingFilesCount
$wsus.GetContentDownloadProgress()

How Microsoft defines what you just read:

Two traps in those reads. First, use GetStatus(), not GetUpdateStatus(), for the needing-files count. Microsoft on GetUpdateStatus: "This method updates only the UpdateCount, DeclinedUpdateCount, UpdatesWithClientErrorsCount, UpdatesNeededByComputersCount, and UpdatesUpToDateCount properties. All other properties will be 0 or empty." A Microsoft Q&A poster saw it "always 0 even when the GUI says otherwise" until switching to GetStatus(). Second, when files live on Microsoft Update, the progress number isn't about update files at all. Microsoft: "If HostBinariesOnMicrosoftUpdate is true, the return value represents the download progress of the end-user license agreements (EULAs)."

Why the console's error is blank. Microsoft lists it as a known issue on its Windows Server 2025 pages for the October 2025 WSUS security fix: "After installing KB5070881 or later updates, Windows Server Update Services (WSUS) does not display synchronization error details within its error reporting. This functionality is temporarily removed to address the Remote Code Execution Vulnerability, CVE-2025-59287." The same known issue still appears, with KB5070893, on Microsoft's August 11, 2026 Windows Server 2025 hotpatch page. We only checked Windows Server 2025 pages, and we haven't tested whether the API's ErrorText is affected. Don't roll back the security fix to get the error text back; read the log in Step 4.

A sync that never leaves 0%. Microsoft's sync troubleshooting: if a manual synchronization starts but stays at 0%, the WSUS service "is in a stopped state." Read the services:

# Read-only. WSUS service, IIS, and the WSUS app pool (service names are our note)
Get-Service -Name WsusService, W3SVC | Format-Table Name, Status, StartType
Import-Module WebAdministration
Get-WebAppPoolState -Name 'WsusPool'

If WsusPool is stopped, the clients-not-reporting post has Microsoft's 503 and private memory limit guidance.

Microsoft's health check: "run the following command on the WSUS server. Then review the Application log in Event Viewer for errors":

:: Read-only health check. Results go to the Application log
"%ProgramFiles%\Update Services\Tools\wsusutil.exe" checkhealth

Step 3: The update file settings (read-only)

Before you chase a download that isn't happening, check that the server is supposed to download anything. Microsoft: "Update files can be stored on your WSUS server or on Microsoft Update servers, depending on how you've configured your synchronization options." And: "If not, client computers will download approved updates directly from Microsoft Update."

# Read-only. Where updates come from, where files live, and what gets downloaded
$cfg = (Get-WsusServer).GetConfiguration()
$cfg | Select-Object SyncFromMicrosoftUpdate, UpstreamWsusServerName, UpstreamWsusServerPortNumber, UpstreamWsusServerUseSsl,
  IsReplicaServer, HostBinariesOnMicrosoftUpdate, DownloadUpdateBinariesAsNeeded, DownloadExpressPackages,
  AllUpdateLanguagesEnabled, LocalContentCachePath, UseProxy, ProxyName, ProxyServerPort, MUUrl

In the console: Options > Update Files and Languages, and Options > Update Source and Proxy Server. Microsoft's definitions:

Microsoft's rule for the two download properties: "To download only approved updates, set HostBinariesOnMicrosoftUpdate to false and IUpdateServerConfiguration.DownloadUpdateBinariesAsNeeded to true." And: "WSUS ignores the following property values if HostBinariesOnMicrosoftUpdate is true," which are the express and as-needed settings.

Microsoft: "By default, WSUS doesn't use express installation files." Turning them on to speed up a stuck download makes the download bigger (our reading).

Step 4: Read the logs: SoftwareDistribution.log and event 364 (read-only)

Microsoft points at one log for sync and import errors, on the WSUS server: %ProgramFiles%\Update Services\LogFiles\SoftwareDistribution.log. Its sync troubleshooting also shows the start lines to look for: "A manual synchronization was started." (EventId=382) and "A scheduled synchronization was started." (EventId=381). Content download failures show up there and in the Application log as event 364.

# Read-only. The last sync start, then errors after it (patterns from Microsoft's samples; the selection is ours)
$log = Join-Path $env:ProgramFiles 'Update Services\LogFiles\SoftwareDistribution.log'
Select-String -Path $log -Pattern 'EventId=38[12]' | Select-Object -Last 3
Select-String -Path $log -Pattern 'ProcessWebServiceProxyException|SoapException|WebException|EventId=364|SCHANNEL Protocol' |
  Select-Object -Last 40 | ForEach-Object Line

# Read-only. Event 364 in the Application log, last 7 days (provider name from Microsoft's KB 922330 sample)
Get-WinEvent -FilterHashtable @{
  LogName      = 'Application'
  ProviderName = 'Windows Server Update Services'
  Id           = 364
  StartTime    = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue | Select-Object TimeCreated, Message | Format-List

For EULA problems during sync, Microsoft's tip for the same log: "Look for .txt in the log to find relevant entries."

Map the text you find to a layer. Each row's text is quoted from the Microsoft page or Q&A thread named in it:

KB 922330's console symptom for the Range case: "A red X appears over the update." The approval-time message Q&A posters quote, "The files for this update have not yet been downloaded," only says the files aren't there yet. Event 364 says why (our reading).

Step 5: The path to Microsoft Update or the upstream server (read-only)

The endpoint. Microsoft's first check for sync or import problems is the endpoint in MUUrl (Step 3). https://sws.update.microsoft.com is the current one; https://fe2.update.microsoft.com "is decommissioned as a WSUS synchronization endpoint, and connections to it will fail." Microsoft: "Windows Server 2012 and later versions should be configured to use the https://sws.update.microsoft.com endpoint." The fix is in Step 11.

The firewall. Microsoft: "To get updates from Microsoft Update, the WSUS server uses ports 80 and 443 for the HTTP and HTTPS protocols." The topmost server needs outbound access to a list of Microsoft domains, including *.update.microsoft.com, *.windowsupdate.com, download.windowsupdate.com, download.microsoft.com, and *.delivery.mp.microsoft.com. Read the full list on Microsoft's Configure WSUS page. Microsoft is explicit about IP-based rules: "The IP addresses associated with these domains are constantly changing, so don't try to use IP address ranges instead." A downstream server only needs its upstream server: "By default, these ports are 8530 and 8531."

# Read-only. TCP reachability from the WSUS server (hosts from Microsoft's list; the selection is ours)
'sws.update.microsoft.com', 'download.windowsupdate.com' | ForEach-Object {
  Test-NetConnection -ComputerName $_ -Port 443 -WarningAction SilentlyContinue |
    Select-Object ComputerName, RemotePort, TcpTestSucceeded
}
Test-NetConnection -ComputerName download.windowsupdate.com -Port 80 -WarningAction SilentlyContinue |
  Select-Object ComputerName, RemotePort, TcpTestSucceeded

# Read-only. A downstream server: can it reach its upstream on both ports? (WSUS-HQ is an example)
foreach ($port in 8530, 8531) {
  Test-NetConnection -ComputerName WSUS-HQ.corp.contoso.com -Port $port -WarningAction SilentlyContinue |
    Select-Object ComputerName, RemotePort, TcpTestSucceeded
}

Test-NetConnection "Specifies the TCP port number on the remote computer," so it proves TCP, not TLS or a full download. Behind a mandatory proxy, a failed direct test is expected (our note).

The proxy. WSUS has its own proxy setting, separate from the browser's. Microsoft: "This setting will apply only when your WSUS server runs synchronizations. By default your WSUS server will try to connect directly to the upstream server or Microsoft Update." And: "Configure WSUS with the same port number that the proxy server is configured to use." Microsoft's sync walkthrough also describes the connection layer: "After a synchronization starts, the WSUS server attempts to make an HTTP connection through WinHTTP." So read the machine's WinHTTP proxy too:

:: Read-only. The system (WinHTTP) proxy on the WSUS server
netsh winhttp show proxy

Firewall content inspection. In an April 2026 Microsoft Q&A thread, a fresh WSUS on Windows Server 2022 stopped the 2026-02 and 2026-03 Windows 11 cumulative updates part-way, "with updates needing files: 1," while other updates downloaded fine. The poster's resolution: "Once I turned off content inspection for this server the update downloaded fully without issue." Microsoft's KB 922330 names one vendor case of the same kind: a SonicWALL device where the "Enable HTTP Byte-Range request with Gateway AV" setting isn't enabled. Beyond that case, treat inspection as a pattern to test (community report).

Step 6: TLS 1.2 and cipher suites (read-only)

Microsoft: https://sws.update.microsoft.com "accepts only Transport Layer Security (TLS) 1.2 connections. And some ciphers were disabled." Its Configuration Manager TLS guidance: "TLS 1.2 is supported by default for WSUS on all currently supported version of Windows Server." So on a current server, a TLS failure usually means something was changed: a cipher policy, an SCHANNEL hardening script, or .NET settings (our reading).

What WSUS logged at startup. Microsoft: "WSUS logs which SSL/TLS versions are enabled when it starts." Its sample lines after a WSUS service restart and iisreset:

SCHANNEL Protocol 'TLS 1.0' disabled
SCHANNEL Protocol 'TLS 1.1' disabled
SCHANNEL Protocols subkey for 'TLS 1.2' not found. Protocol is enabled

For Windows Server 2012 and 2012 R2 WSUS servers, Microsoft adds: "If you can't find these entries, it means the update that enables TLS 1.2 isn't installed." The Step 4 Select-String already searches for SCHANNEL Protocol.

.NET strong cryptography. Microsoft's fix for import and sync failures over TLS 1.2 starts with the .NET registry values. Read them before you set anything:

# Read-only. .NET TLS values Microsoft's TLS 1.2 guidance sets (missing = not set)
'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319',
'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319',
'HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727' | ForEach-Object {
  Get-ItemProperty -Path $_ -ErrorAction SilentlyContinue | Select-Object @{ n = 'Key'; e = { $_.PSPath -replace '^.*::' } }, SchUseStrongCrypto, SystemDefaultTlsVersions
}

Microsoft: "The SchUseStrongCrypto setting allows .NET to use TLS 1.1 and TLS 1.2. The SystemDefaultTlsVersions setting allows .NET to use the OS configuration."

Cipher suites set by policy. Microsoft's Issue 5 is a GPO-configured cipher order with nothing the endpoint accepts: "If the GPO is applied, and it doesn't specify one of these ciphers, communication with WU/MU fails." Its read:

:: Read-only. Then search the report for "SSL Cipher Suite Order"
gpresult /scope computer /h GPReport.html

Microsoft's list "As of August 2020" for Windows Server 2016 and later starts with TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256; read the full list on its page, because "This list will change over time because ciphers will gradually grow weaker as technology improves." Without a GPO, the local value is Functions under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002.

Step 7: The content folder: space, location, and permissions (read-only)

# Read-only. Where WSUS thinks its content is, and how much room is left
$setup = Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Update Services\Server\Setup'
$setup | Select-Object ContentDir, TargetDir
(Get-WsusServer).GetConfiguration().LocalContentCachePath
$drive = (Split-Path -Path $setup.ContentDir -Qualifier).TrimEnd(':')
Get-PSDrive -Name $drive | Select-Object Name, @{ n = 'FreeGB'; e = { [math]::Round($_.Free / 1GB, 1) } }, @{ n = 'UsedGB'; e = { [math]::Round($_.Used / 1GB, 1) } }

# Read-only. Who has rights on WsusContent (NETWORK SERVICE should have Full Control)
(Get-Acl -Path (Join-Path $setup.ContentDir 'WsusContent')).Access |
  Select-Object IdentityReference, FileSystemRights, AccessControlType, IsInherited

# Read-only. Does IIS serve Content from the same folder? (site name varies: 'WSUS Administration' or 'Default Web Site')
Import-Module WebAdministration
Get-WebVirtualDirectory -Site 'WSUS Administration' -Name 'Content' | Select-Object Path, PhysicalPath

Microsoft's reference for the registry: under HKLM\Software\Microsoft\Update Services\Server\Setup, ContentDir is "the location under which update binaries and end user license agreement files are stored," and ContentDir\WsusContent "contains the update files." The Content virtual directory lookup at the end is our way to compare the IIS path with ContentDir. Microsoft's reference lists Content as one of the virtual roots WSUS creates, with anonymous access.

Space. Microsoft: "At a minimum, WSUS requires 20 GB to store updates locally; however, we recommend at least 40 GB." For Windows 11 UUP: "the WSUS server downloads approximately 10 GB of content per Windows version and processor architecture for each version. For example, an additional 20 GB of content is downloaded for both x64 and arm64 for Windows 11, version 22H2." Express files, all languages, and feature updates (the Upgrades classification) all add to that.

Permissions. Microsoft's server settings reference: the WSUS content directory "must have Full Control permission granted to the NT Authority\Network Service account. This permission is set by WSUS server setup when it creates the directory, but it is possible that your security software might reset this." And: "Not having this permission set will also cause BITS downloads to fail." The same page says the root folder of the drive that holds WsusContent needs Read for the Users account or NETWORK SERVICE, a permission "that WSUS setup does not configure." That page dates from the WSUS 2.0/3.0 era, so treat its details as a checklist, not a current contract (our note).

Step 8: BITS on the server (read-only)

Microsoft: "WSUS uses the Background Intelligent Transfer Service (BITS) protocol for all its file transfer tasks. This includes downloads to client computers and server synchronizations." When the needing-files count is flat, look at the BITS jobs on the WSUS server:

# Read-only. All users' BITS jobs (needs admin). WSUS jobs aren't owned by your account
Get-BitsTransfer -AllUsers |
  Select-Object DisplayName, JobState, OwnerAccount, BytesTransferred, BytesTotal, ErrorDescription |
  Sort-Object JobState | Format-Table -AutoSize -Wrap

# Read-only. The BITS service itself
Get-Service -Name BITS | Select-Object Name, Status, StartType

-AllUsers matters. Microsoft: "By default, the cmdlet returns the jobs that are owned by the current user." The selected properties are ours. Which job names and owner WSUS uses, we haven't confirmed on a Microsoft page, so read the list rather than filter it.

Range requests and foreground mode. Microsoft's KB 922330 explains why some downloads fail behind a proxy or firewall: "When you copy a file by using BITS in background mode, the file is copied in multiple small parts. To perform this kind of copy operation, BITS uses the HTTP 1.1 Content-Range header." Then: "When BITS copies files in foreground mode, BITS doesn't use this header." Its first resolution is to fix the proxy: "Modify the proxy server settings to support HTTP 1.1 range requests. If you can't modify the proxy server in this manner, configure BITS to work in foreground mode." Microsoft's server settings reference describes the setting: "This internal setting specifies whether or not to use foreground priority for BITS downloads. The default is to use throttled downloads." Read it before you change it:

# Read-only. Current BITS priority for WSUS downloads (property form reported on Microsoft Q&A; see the note)
(Get-WsusServer).GetConfiguration().BitsDownloadPriorityForeground

KB 922330's own commands update tbConfigurationC in SUSDB with SQL for WSUS 2.0 and 3.0. Microsoft Q&A posters set the same value through the configuration object on current versions. Microsoft's property list for IUpdateServerConfiguration that we fetched doesn't show it, so treat the PowerShell form as community-documented (our note).

Step 9: Windows 11 UUP and the client's download (read-only)

UUP MIME types on the server. Windows 11 quality updates come as Unified Update Platform content on WSUS. Microsoft: "Install one of the following updates on the WSUS servers, or manually add the required MIME types for UUP to the WSUS server," with the 2023-02 cumulative update (or later) listed for Windows Server 2016, 2019, and 2022. The two types are .msu (application/octet-stream) and .wim (application/x-ms-wim). Microsoft: "Ensure you selected the server and not the site when adding the MIME types. The WSUS Administration site needs the MIME type entry to be inherited rather than local."

# Read-only. Server-level static content MIME map for the two UUP types (the PSPath form is ours)
Import-Module WebAdministration
Get-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter 'system.webServer/staticContent' -Name collection |
  Where-Object fileExtension -in '.msu', '.wim' | Select-Object fileExtension, mimeType

If someone added them by hand at the wrong level, you'll see Microsoft's documented error: "Cannot add duplicate collection entry of type 'mimeMap' with unique key attribute 'fileExtension' set to '.wim'". Microsoft: "These two MIME types should only be set to local at the server level."

How clients get the files. With local storage, clients download from the WSUS server's Content virtual directory over plain HTTP. Microsoft: one port "uses TLS/HTTPS to send update metadata," and "A second port uses HTTP to send update payloads." By default that's 8530; Content is on Microsoft's list of virtual roots that shouldn't require TLS. Payloads are still protected: "When an update is downloaded, the client software verifies the payload's digital signature and hash."

When the server has every file and clients still sit at 0%, the client side has its own documented causes:

Step 10: Disconnected (offline) WSUS servers (read-only)

Microsoft's Configure WSUS page describes the air-gapped design: one internet-connected WSUS server collects updates, they're "exported from the first server onto removable media, carried across the air gap, and imported into the second server." Export and import move metadata only. Microsoft's WSUSutil reference: "You cannot use this parameter to export update files, update approvals, or server settings." The files travel separately: Microsoft's Configuration Manager procedure copies "all files and folders" from the export server's WSUSContent folder to the disconnected server's WSUSContent folder, then runs wsusutil.exe export packagename logfile on one side and wsusutil.exe import packagename logfile on the other.

Microsoft's older disconnected-network guide adds the step that's easy to skip: "Make sure that the options for express installation files and update languages on the exporting server are compatible with the settings on the importing server."

In that Q&A thread, the MVP answer suggests running wsusutil reset on the online server, waiting, then exporting again and copying the whole WsusContent folder (community answer).

Common false starts (read these before you change anything)

Step 11: Change one layer, then prove it (only after the read)

Pick the one change Steps 1-10 point at. Save the current configuration first, so you can compare or put it back:

# Low-risk write. Save the WSUS configuration and setup key before any change (our habit)
New-Item -Path C:\Temp -ItemType Directory -Force | Out-Null
(Get-WsusServer).GetConfiguration() | Export-Clixml -Path C:\Temp\wsus-config-before.xml
reg export 'HKLM\SOFTWARE\Microsoft\Update Services\Server\Setup' C:\Temp\wsus-setup-before.reg /y

The endpoint (Step 5). Microsoft's script from KB 4482416, for WSUS on Windows Server 2012 and later. Microsoft: "Don't run the scripts on a WSUS server that's not the topmost server." The read lines come first in Microsoft's own version:

# Change, on the topmost WSUS server only. Microsoft's KB 4482416 script; close all WSUS consoles first
$server = Get-WsusServer
$config = $server.GetConfiguration()
# Check current settings before you change them
$config.MUUrl
$config.RedirectorChangeNumber
# Update the settings if MUUrl is https://fe2.update.microsoft.com/v6
$config.MUUrl = "https://sws.update.microsoft.com"
$config.RedirectorChangeNumber = 4002
$config.Save()
iisreset
Restart-Service *Wsus* -v

The upstream source (Step 3). Set-WsusServerSynchronization supports -WhatIf:

# Change. Dry-run first (WSUS-HQ is an example upstream; or use -SyncFromMU for Microsoft Update)
Set-WsusServerSynchronization -UssServerName 'WSUS-HQ.corp.contoso.com' -PortNumber 8531 -UseSsl -WhatIf

The proxy and firewall (Step 5). Set the proxy under Options > Update Source and Proxy Server > Proxy Server, with credentials if it needs them. For Range requests or content inspection, ask for an exception scoped to the WSUS server before you touch BITS, and test with one large update (our view).

TLS (Step 6). Microsoft's Resolution for issue 1: "Configure .NET Framework to use TLS 1.2 by using registry keys," then "Restart the server after you set the registry keys." The values, from Microsoft's TLS 1.2 guidance (repeat for WOW6432Node and v2.0.50727 as listed there):

# Change. Microsoft's .NET strong-crypto values, 64-bit v4 key shown. Dry-run first, then restart the server
$key = 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319'
Set-ItemProperty -Path $key -Name SchUseStrongCrypto -Value 1 -Type DWord -WhatIf
Set-ItemProperty -Path $key -Name SystemDefaultTlsVersions -Value 1 -Type DWord -WhatIf

For a cipher GPO, change the policy at its source to include one of Microsoft's listed ciphers; don't edit the local key under a GPO that will rewrite it (our reading).

BITS foreground mode (Step 8). Only after the proxy owner says Range requests can't be allowed. Our form, through the configuration object (community-documented, see Step 8), then Microsoft's documented restart of the Update Services service:

# Change. Foreground BITS for WSUS downloads. Read first, set, save, then restart WSUS (dry-run the restart)
$cfg = (Get-WsusServer).GetConfiguration()
$cfg.BitsDownloadPriorityForeground
$cfg.BitsDownloadPriorityForeground = $true
$cfg.Save()
Restart-Service -Name WsusService -WhatIf

Disk and location (Step 7). Free space first: decline what you don't need, then cleanup as maintenance. To move content, Microsoft's syntax is wsusutil.exe movecontent contentpath logfile [-skipcopy]; -skipcopy "enables you to change the location of local WSUS update storage without copying any files" (Microsoft's archived WSUS blog). Create the new folder first:

:: Change. Move content to E:\WSUS and log it (paths are examples). Run from %ProgramFiles%\Update Services\Tools
wsusutil.exe movecontent E:\WSUS E:\WSUS-move.log

Use -skipcopy only when the files are already at the new path (our reading).

Permissions (Step 7). Save the current ACL, then restore NETWORK SERVICE Full Control on WsusContent. (OI)(CI) makes it inherit to files and subfolders; F is full access:

# Low-risk write: save the ACL first. Then the change (D:\WSUS is an example ContentDir)
icacls 'D:\WSUS\WsusContent' /save C:\Temp\wsuscontent-acl.txt /t
icacls 'D:\WSUS\WsusContent' /grant 'NT AUTHORITY\NETWORK SERVICE:(OI)(CI)F'

UUP MIME types (Step 9). Install the current cumulative update on the WSUS server first. If you can't, add both types at the IIS server node; Microsoft's Windows IT Pro blog has the appcmd form:

# Change, server level. From Microsoft's Windows IT Pro blog; only if the read in Step 9 found them missing
& $Env:WinDir\system32\inetsrv\appcmd.exe set config /section:staticContent /+"[fileExtension='.msu',mimeType='application/octet-stream']"
& $Env:WinDir\system32\inetsrv\appcmd.exe set config /section:staticContent /+"[fileExtension='.wim',mimeType='application/x-ms-wim']"

Missing or corrupt files (Steps 4, 7). Once the path, disk, and permissions are right, Microsoft's tool for the content itself:

:: Change. Re-verifies content against the database and re-downloads what's missing or corrupt
"%ProgramFiles%\Update Services\Tools\wsusutil.exe" reset

Microsoft: "If update files are missing or have been corrupted, WSUS downloads the update files again." The API equivalent is ResetAndVerifyContentState(), which verifies "that all update files on the WSUS server are valid." Run one or the other once, then wait. For a disconnected server, match settings, re-copy WsusContent, and import a fresh package (Step 10).

Then prove it. Run one manual sync, then read the same values as Step 2:

# Read-only. Sync result, the needing-files count, bytes, and any new 364s since the change
$wsus = Get-WsusServer
$wsus.GetSubscription().GetLastSynchronizationInfo() | Select-Object Result, StartTime, EndTime, Error
$wsus.GetStatus().UpdatesNeedingFilesCount
$wsus.GetContentDownloadProgress()
Get-WinEvent -FilterHashtable @{ LogName = 'Application'; ProviderName = 'Windows Server Update Services'; Id = 364; StartTime = (Get-Date).AddHours(-2) } -ErrorAction SilentlyContinue |
  Select-Object TimeCreated, Message

Read the count again an hour later and the next morning; it should fall. Then check one pilot client: its download should move past 0%.

When a change is justified

FAQ

Why is WSUS not downloading updates?
Either synchronization is failing (no new metadata) or the content download is failing (metadata, no files). Read the last sync result and GetStatus().UpdatesNeedingFilesCount first. Then read SoftwareDistribution.log and event 364 for the exact reason: an old endpoint, TLS or ciphers, a proxy or firewall, a full or locked-down content folder, or BITS Range requests.

What does "updates needing files" mean in WSUS?
Updates that are approved, or set to download, whose files aren't all on the server yet. Microsoft defines the count as updates "that do not have all the required installation files." With deferred downloads on, unapproved updates don't count against you, because they're only downloaded "after it's approved."

How do I fix WSUS sync failed "The underlying connection was closed"?
It's usually TLS. Microsoft's sync endpoint accepts only TLS 1.2, and some ciphers were removed. Set the .NET SchUseStrongCrypto and SystemDefaultTlsVersions values, check for a cipher suite GPO, restart, and sync again. On a server that syncs through a proxy, check that the proxy isn't ending the connection.

Does wsusutil reset delete updates?
No. Microsoft: it verifies "that every update metadata row in the WSUS database corresponds to update files stored in the local update file storage location," and re-downloads files that are missing or corrupt. It can take a long time and doesn't fix a blocked network path, so fix the path first.

Why won't WSUS download Windows 11 updates?
Check the UUP requirements first: the .msu and .wim MIME types at the IIS server level (or a current cumulative update on the WSUS server) and enough disk for about 10 GB per Windows version and architecture. If downloads stop part-way at the same point, check firewall content inspection, which a 2026 Microsoft Q&A thread identified for Windows 11 cumulative updates.

Related posts

• WSUS Clients Not Reporting (the client half: policy, scan source, client proxy, IIS and WsusPool, and duplicate SusClientId values)
• Windows Update Rings for Intune Pilots (if WSUS's deprecation has you planning cloud-managed updates for some devices)
• Intune Feature Updates: Ring Deferral vs a Feature Updates Policy vs Windows Autopatch (which cloud tool owns feature updates once WSUS doesn't)

Free checklist

A WSUS server that looked healthy until a firewall inspection profile changed is a change nobody tested from where the files flow. So is a Conditional Access policy enforced before anyone read the report-only results. The free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:

👉 https://cashflow4375.gumroad.com/l/ujkqxb?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=wsus-not-downloading-updates

If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=wsus-not-downloading-updates

Admin Pack Studio; not affiliated with Microsoft. Steps 1-10 favor read-only checks: Get-WsusServer, GetSubscription() / GetLastSynchronizationInfo() / GetSynchronizationStatus(), GetStatus(), GetContentDownloadProgress(), GetConfiguration(), Get-Service, Get-WebAppPoolState, wsusutil checkhealth, Select-String on SoftwareDistribution.log, Get-WinEvent, Test-NetConnection, netsh winhttp show proxy, Get-ItemProperty, gpresult, Get-PSDrive, Get-Acl, Get-WebVirtualDirectory, Get-BitsTransfer -AllUsers, and Get-WebConfigurationProperty. Export-Clixml, reg export, and icacls /save write local files. The endpoint script, Set-WsusServerSynchronization, proxy settings, firewall exceptions, the .NET TLS values, cipher policy changes, BitsDownloadPriorityForeground, wsusutil movecontent, icacls /grant, MIME type changes, wsusutil reset, ResetAndVerifyContentState(), export/import, and service restarts are deliberate changes. Change one layer at a time, test with one update first, and check current Microsoft Learn for version-specific behavior.