Windows Update fails on filtered networks for three different reasons, and they need three different fixes. The device cannot resolve the update hostname, it resolves the name but cannot reach the endpoint, or it reaches the endpoint and rejects the TLS certificate. The Windows Update log tells you which one you're facing, so start there instead of rebuilding the update client.
The third case surprises most teams. Windows Update pins the certificates on its metadata connections, so any proxy or firewall doing TLS inspection replaces a certificate the client refuses to accept. Microsoft's guidance in the Windows Update security article is direct about it: TLS proxies must pass these connections through without interception.
This guide walks the diagnosis in order, then covers the firewall allow list, the TLS inspection exception, the WinHTTP proxy configuration, and the WSUS case where none of the internet rules apply.
Before you start
What you will learn
- You will learn how to tell whether Windows Update is failing at DNS resolution, at the network connection, or at TLS certificate validation, and how to fix each case in your firewall and proxy rules.
- A device that cannot reach Windows Update stops receiving security updates while still reporting as managed. Filtered networks are one of the most common causes, and the symptom looks like a broken client rather than a blocked connection.
Requirements
- You need local administrator rights on an affected Windows device to generate the update log and set the WinHTTP proxy, plus a way to change firewall and proxy rules yourself or through your network team.
- A supported Windows client or server behind a firewall, proxy, or VPN, with PowerShell available.
- Local administrator on the Windows device
- Firewall or proxy administrator (or a change request to the network team)
Good to know
- Diagnosis takes about 15 minutes. Firewall and proxy changes depend on your change process.
- Endpoint lists and error meanings come from Microsoft Learn and the Windows IT Pro Blog. Verify the endpoint list for your exact Windows version before you write firewall rules.
Quick answer
Generate the Windows Update log with Get-WindowsUpdateLog and read the error code. 0x8024402c means DNS resolution failed, 0x80240438 means the endpoint was unreachable, and 0x80245006 or 0x80240437 point at TLS certificate validation. Fix it by allowing the Windows Update FQDNs (wildcards included) on the firewall and proxy, and by excluding those hostnames from TLS inspection.
Firewall or proxy allow list > Windows Update FQDNs (*.update.microsoft.com, *.windowsupdate.com, *.delivery.mp.microsoft.com) > exclude from TLS/SSL inspectionGet-WindowsUpdateLog -LogPath "$env:TEMP\WindowsUpdate.log"Step-by-step tutorial
8 stepsGenerate the Windows Update log and find the failing operation
Get a readable log so you can see where the update connection breaks instead of guessing.
Open PowerShell as administrator on an affected device and run the command below. Get-WindowsUpdateLog converts the ETL trace files that Windows writes into a single readable log.
$output = "$env:TEMP\WindowsUpdate.log"
Get-WindowsUpdateLog -LogPath $output
Write-Host "Windows Update log written to $output"Open the resulting file and search for *FAILED* and for the word error. Work from the most recent scan backwards, and note the hexadecimal code attached to the first failure in the sequence. Later entries are often knock-on effects of that first one.
$output = "$env:TEMP\WindowsUpdate.log"
Get-WindowsUpdateLog -LogPath $output
Write-Host "Windows Update log written to $output"The conversion needs to reach the Microsoft symbol server on some builds. If it can't, the log still generates but function names may be missing, which is fine for reading error codes.
Match the error code to the layer that failed
Decide whether you're fixing DNS, a blocked connection, or certificate validation, because the three fixes are different.
Compare the code you found against the values Microsoft published in the Configuring firewall and proxies for smooth Windows updates post on the Windows IT Pro Blog, May 2026:
0x8024402cisWU_E_PT_WINHTTP_NAME_NOT_RESOLVED. The device couldn't resolve the update server name to an IP address, so your network may be blocking FQDN resolution.0x80240438isWU_E_PT_ENDPOINT_UNREACHABLE. The name resolved, but the device couldn't connect. A firewall or proxy is the usual cause.0x80245006isWU_E_REDIRECTOR_INVALID_RESPONSE, and0x80240437sits in the same family. Microsoft describes both as signs that the response or the server certificate didn't validate, which is what TLS inspection produces.
A DNS failure sends you to step 3 and step 6. A connection failure sends you to step 3 and step 5. A certificate failure sends you to step 4.
Two codes are not connectivity problems and need no firewall work. 0x248001 and 0x8024402d mean the service was shedding load, per Microsoft's Windows Update troubleshooting article. The device retries on its own.
Allow the Windows Update FQDNs, wildcards included
Give the update client a path to every hostname it uses, not just the one you noticed in the log.
Firewall or proxy console > URL/FQDN allow list > add Windows Update hostnamesAdd the documented Windows Update hostnames to your firewall and proxy allow list, keeping the wildcards intact. Microsoft's troubleshooting article lists this set as the example for Windows 10, version 2004:
*.prod.do.dsp.mp.microsoft.comover TLS 1.2emdl.ws.microsoft.comover HTTP*.dl.delivery.mp.microsoft.comover HTTP*.windowsupdate.comover HTTP*.delivery.mp.microsoft.comover HTTPS*.update.microsoft.comover TLS 1.2tsfe.trafficshaping.dsp.mp.microsoft.comover TLS 1.2
Match the protocol column exactly. Microsoft states the connection fails if you use HTTPS where HTTP is specified, or the reverse. Then check the Manage connection endpoints article for your own Windows version, because the set varies between releases.
Make sure your product treats *.update.microsoft.com as covering every subdomain, including sls.update.microsoft.com and deeper names. Some appliances match only one label.
Windows Update uses HTTPS on TCP 443 for metadata, HTTP on TCP 80 for content, and TCP 7680 for Delivery Optimization peer traffic on the local network. Blocking 7680 doesn't stop updates, it only stops peering.
Exempt the update endpoints from TLS inspection
Stop the inspecting device from replacing a certificate that Windows Update is pinned to.
Proxy or NGFW console > TLS/SSL inspection policy > bypass list > add Windows Update hostnamesOn the proxy or next-generation firewall, add the Windows Update hostnames from step 3 to the TLS/SSL inspection bypass list, then confirm the rule is evaluated before any broad inspection policy.
This isn't a preference. Windows Update's metadata connections are certificate-pinned: the client validates that the issuer is a genuine Windows Update certificate and drops the connection when it isn't. An inspecting proxy presents its own certificate, so the connection fails even though the network path is open.
After the change, generate a new log and look for the certificate-family codes again.
Content downloads are a separate case. Microsoft delivers update binaries over plain HTTP through CDNs on purpose, and validates them with digital signatures and file hashes after download, so seeing HTTP here is expected rather than a misconfiguration.
Configure the system-level proxy and allow HTTP RANGE requests
Make sure the update client itself sees the proxy, and that the proxy serves partial downloads.
Windows Update uses WinHTTP, not the user's browser settings. A proxy defined only at user level leaves the update client with no proxy at all, and connections fail. Set it at system level from an elevated prompt:
netsh winhttp show proxy
netsh winhttp set proxy ProxyServerName:PortNumberYou can also import an existing configuration with netsh winhttp import proxy source=ie.
Next, allow HTTP RANGE requests (RFC 7233) on the proxy for the download hostnames, which Microsoft lists as *.download.windowsupdate.com, *.dl.delivery.mp.microsoft.com, and *.delivery.mp.microsoft.com. Blocked RANGE requests show up as error 0x80d05001 (DO_E_HTTP_BLOCKSIZE_MISMATCH) or as high CPU during downloads.
netsh winhttp show proxy
netsh winhttp set proxy ProxyServerName:PortNumberReplace ProxyServerName:PortNumber with your own host and port. If you can't allow RANGE requests, delta patching stops working and devices download more content than they need.
Rule out the VPN and DNS path
Separate a client problem from a tunnel or resolver problem before you keep editing firewall rules.
If the device uses a VPN, test an update scan with the tunnel disconnected on a network you control. A VPN can restrict update traffic, redirect DNS lookups, or throttle large downloads, and the symptom is identical to a firewall block.
Then confirm resolution from the device itself:
Resolve-DnsName sls.update.microsoft.com
Resolve-DnsName fe3.delivery.mp.microsoft.comIf the name doesn't resolve, the problem is your resolver or a DNS filtering policy, not the firewall rule you just wrote. When updates work off the VPN and fail on it, take the endpoint list from step 3 to whoever runs the tunnel.
Resolve-DnsName sls.update.microsoft.com
Resolve-DnsName fe3.delivery.mp.microsoft.comDon't build firewall rules from the addresses you get back. Microsoft rebalances these endpoints, so today's IP is not tomorrow's.
Confirm where the device actually gets its updates
Avoid fixing internet rules for a device that was never meant to use them.
If your estate runs WSUS or Configuration Manager, the client talks to your internal server rather than to Microsoft's public endpoints, and none of the internet allow-list work applies to it. Confirm the configured source from PowerShell:
$MUSM = New-Object -ComObject "Microsoft.Update.ServiceManager"
$MUSM.ServicesRead the Name and OffersWindowsUpdates values. Windows Server Update Service with OffersWindowsUpdates: True means the device is pointed at WSUS. Windows Update or Microsoft Update means it goes to Microsoft directly.
For a WSUS client, check reachability of the WSUS server and port, the approvals on the server, and the TLS configuration between client and server instead.
$MUSM = New-Object -ComObject "Microsoft.Update.ServiceManager"
$MUSM.ServicesThe WSUS server itself still needs outbound access to Microsoft for catalog synchronization, even when clients don't. That sync runs over TLS and is verified by Microsoft certificate, so it also needs an inspection exception.
Retest and confirm the connection is clean
Prove the fix on the wire rather than on the settings page.
Settings > Windows Update > Check for updatesTrigger a scan from Settings > Windows Update > Check for updates, wait for it to finish, then regenerate the log with the command from step 1 and search for the codes from step 2.
One caution from Microsoft: the Windows Update protocol uses several connections and endpoints, so reaching one server successfully doesn't prove the whole exchange works. Judge success on the API result codes and the log, not on a single reachability test.
Repeat on a second device on the same network segment before you call the change done.
Keep the pre-change log. Comparing the two is the fastest way to show the network change is what fixed it.
How to Confirm Windows Update Is No Longer Blocked
A fixed device shows two things: a scan that completes end to end, and a Windows Update log with none of the connection error families still present. That second check matters because the client retries quietly, so a device can look healthy on the settings page while still failing part of the exchange.
Read the log in the order the failures happen. Name resolution comes first, then the connection to the endpoint, then the certificate check on the metadata exchange, then the content download. A code from an earlier layer makes everything after it meaningless, so fix in that order.
If downloads start but stall, look at the download path rather than the allow list. Blocksize errors point at RANGE requests on the proxy, and a stuck 0% download points at the Windows Defender Firewall service being disabled on the device.
- The scan finishes, updates download and install, and the regenerated log shows no 0x8024402c, 0x80240438, 0x80245006, or 0x80240437 entries.
- The scan still fails with the same code, which usually means the rule didn't match the hostname you expected: a wildcard treated as a single label, an inspection policy evaluated before the bypass, or a device using a different egress path than the one you changed.
- The device couldn't turn the update hostname into an IP address. Look at DNS filtering and FQDN resolution policy, not at the firewall rule.
- The name resolved but the connection didn't complete, which points at a firewall or proxy block on the path.
- The response from the redirector was invalid. On an inspecting network this commonly means the certificate wasn't what the client expected.
- The proxy isn't serving HTTP RANGE requests, so partial downloads fail. Allow RANGE on the download hostnames.
Troubleshooting
The allow list looks correct but the device still gets 0x80240438
Cause: The firewall or proxy matches only one subdomain level, so *.update.microsoft.com doesn't cover deeper names such as tas02.sls.update.microsoft.com.
Check how your product expands wildcards. Test resolution and connection to a deep hostname from the device, and add explicit entries for the subdomains that appear in your log if the wildcard doesn't recurse. Microsoft's guidance is that every subdomain under the wildcard FQDN has to be trusted.
Downloads sit at 0% and the log shows 0x800706D9
Cause: The Windows Defender Firewall service is disabled on the device, which breaks BITS transfers.
Open services.msc, find Windows Defender Firewall, and start it. Set it to start automatically. Microsoft doesn't support stopping the service behind Windows Firewall with Advanced Security, and this error is the usual consequence.
Downloads fail with 0x80d05001 or the CPU spikes while updating
Cause: The proxy isn't allowing HTTP RANGE requests, so the client can't fetch partial content.
Permit RANGE requests on the proxy for *.download.windowsupdate.com, *.dl.delivery.mp.microsoft.com, and *.delivery.mp.microsoft.com. If your proxy can't do it, expect full downloads instead of delta patching and plan the bandwidth accordingly.
Browsing to an update endpoint shows a certificate warning, so the endpoint looks broken
Cause: Windows Update servers are used by the update client only, and don't follow browser expectations such as publicly trusted PKI or certificate transparency.
Ignore the browser result and test with the update client instead. Microsoft documents this behaviour as expected in the Windows Update security article. Judge success from the Windows Update log, not from a browser tab.
The error is 0x8024402d or 0x248001 and appears intermittently
Cause: The Windows Update service was shedding load, which is a transient server-side condition rather than a network block.
Take no action on the firewall. The device retries the operation later on its own. Only investigate if the same codes persist across several days on many devices.
Only some devices fail, on the same subnet and the same policy
Cause: The working devices have a system-level WinHTTP proxy while the failing ones only have the user-level browser proxy.
Run netsh winhttp show proxy on both a working and a failing device and compare. Set the system proxy with netsh winhttp set proxy, or deploy it consistently across the fleet, then rescan.
Frequently asked questions
Can I just allow Microsoft's IP ranges instead of the hostnames?
No. Microsoft doesn't publish IP addresses or ranges for Windows Update exceptions, because the addresses change for reasons such as traffic load balancing. Build the rules on the documented DNS names.
Why does TLS inspection break Windows Update when it works for normal websites?
Windows Update metadata connections are certificate-pinned. The client checks that the issuer is a genuine Windows Update certificate, so an inspecting proxy that swaps in its own certificate causes the connection to fail.
Is it a problem that update files download over plain HTTP?
No. Microsoft delivers content over HTTP through CDNs by design, since a TLS session terminating at a CDN wouldn't prove Microsoft chain of custody. The downloaded files are validated with digital signatures and file hashes before installation.
Do WSUS clients need the same firewall exceptions?
No. WSUS clients get updates from your internal server rather than from Microsoft's public endpoints. The WSUS server itself still needs outbound access to synchronize its catalog with Microsoft.
Which ports does Windows Update use?
Metadata exchange uses HTTPS on TCP 443. Content download uses HTTP on TCP 80, and Delivery Optimization peer-to-peer traffic uses TCP 7680.
Does a successful connection test mean Windows Update will work?
Not on its own. Microsoft notes that the update protocol spans several connections and endpoints, so reaching one server proves little. Confirm with the API result codes or the Windows Update log.
