Having trouble connecting to Windows Update? If your devices experience difficulties getting updates, you’re likely just one step away from the solution. The key is in the configuration of your network endpoints for firewalls and proxies. This post provides actionable guidance on how to identify the cause of the issue and remedy the situation.
The Windows Update service makes use of Internet hosted services to widely distribute updates to Windows devices. Windows devices connect to Windows Update services to check for various updates, including monthly security and non-security updates, driver and .NET Framework updates, machine learning (ML) model updates, and more.
Typically, a Windows Update scan occurs automatically or when triggered manually by the user. Once started, the process scans for updates, downloads, and installs them. However, some network configurations obscure this process, leading to errors or the inability to update a device. Luckily, there are measures you can take to avoid this.
Security is paramount for Windows Update. Its whole purpose is to help keep your devices protected and productive. Therefore, there are multiple protections to ensure that your device connects to authentic Windows Update services. However, there’s one specific networking security consideration we’ll focus on: Transport Layer Security (TLS).
You probably know TLS (sometimes referred to by an older protocol known as SSL) as the https:// element you type into your browser. This moniker instructs your browser to connect to a web server using HTTP over a TLS connection. Doing so helps ensure the following between your device and a web server:
When Windows interacts with the Windows Update service, it performs all of these checks. Additionally, it double-checks that the server isn’t only trusted, but it’s what it claims to be. This is done by verifying that the server’s TLS certificate is chained up to a specific certificate authority (CA). Windows refers to this as a Windows Update trust anchor.
If the TLS certificate isn’t issued by an actual Windows Update trust anchor, Windows won’t trust that the server is a genuine Windows Update server and immediately disconnects. That’s good news until you accidentally lock yourself out of accessing trustworthy Windows Update services.
Some networking environments implement special firewalls or proxies that intercept TLS connections. They typically perform TLS inspection, validating that the request to a server is legitimate and adheres to an organization’s security and other policies. This is how some firewalls and proxies might block access to forbidden content.
When TLS inspection occurs in this way, the firewall or proxy server generates its very own certificate. Even though it is generated by the firewall or proxy, it appears to be legitimate (containing SAN entries for the URL’s fully qualified domain name) and is trusted by the client’s browser. Typically, this involves generating a TLS certificate to match the requested URL and signing it by the organization deploying these firewall/proxy services. Since the client device is a member of the organization, it inherently trusts these certificates signed by the same organization.
When this occurs, the Windows Update client detects that the TLS certificate issuer isn’t a genuine Windows Update issuer. By design, the client only trusts certificates issued by the Windows Update service. This feature of “pinning” solely to TLS certificates issued by the Windows Update service protects the distribution and delivery channels from man-in-the-middle (MITM) attacks. Again, this is good news for your security posture, except when exceptions are needed.
Some virtual private network (VPN) providers block access or DNS lookups to prevent overloading the VPN network with high-volume traffic downloads. That’s another potential cause of blocked access for Windows devices. If you’re experiencing Windows Update issues over a VPN connection, contact your VPN provider.
If you’re an avid PowerShell administrator, you might be forcing Windows Update to scan using scripts that call into the Windows Update public API. In this case, these calls might return one of the error codes listed below and add an entry for the error to the Windows Update log. If this happens, remediation steps are the same as if you found them in the Windows Update log.
Note: The Windows Update protocol is complex and consists of multiple different connections and endpoints. Simply connecting to one of the Windows Update servers doesn’t tell the bigger picture of end-to-end protocol success. Rely on API result codes and/or the Windows Update log to determine success.
If your Windows device is not receiving Windows updates as you expect, check if your connections are being blocked. Whether the source of the issue is a proxy server, firewall, or VPN, you can use the following steps to troubleshoot and move forward.
The first thing to check is the Windows Update audit log. Generate it from PowerShell, running the Get-WindowsUpdateLogs command:
$output = "$env:TEMPWindowsUpdate.log"
Get-WindowsUpdateLog -LogPath $output
Write-Host "Windows Update log written to $output"
Once you have the log file, look for any of the following error codes:
If your log shows any of these error codes, work with your IT team to help ensure that firewalls and proxies are properly allowing Windows Update connections. In some cases, VPNs may be blocking FQDN resolutions or connections to the Windows Update service. If you’re using a VPN, check with the VPN provider.
To ensure that Windows devices can properly access genuine Windows Update services, firewalls and proxies need to allow those connections to pass through uninterrupted. That is to say, without generating and using its own TLS certificate.
To do this, proxies and firewalls need to create “pass through” exceptions for these Windows Update connections. This is typically done by allow-listing specific Windows-Update-related DNS host names. There are several of these qualified DNS names (FQDN) that you need to accommodate. You can learn more about the FQDNs requiring these exceptions in the Windows Update sections of the following:
Note that for the FQDNs related to Windows Update, the * wildcard is recursive. For security and scalability purposes, host and DNS subdomain names might need to periodically change.
For example, here’s a recommended DNS host name:
*.update.microsoft.com
It represents all of the following hosts and subdomains:
This means that you should trust all the DNS hosts and subdomains related to wildcard FQDN for the connection to work properly. Check if these subdomains are missing. In many cases, it should only take you a few minutes to update your proxy and firewall configurations to include them.
Do you use Windows Server Update Services (WSUS) in your networks? In this environment, instead of connecting to the Windows Update service directly, Windows devices connect to an IT-managed WSUS server. If you’re a server administrator, you orchestrate which updates are available on the WSUS server for your devices to update. And since these devices don’t need to traverse a proxy or firewall for a genuine Windows Update server, the FQDN exceptions aren’t necessary.
You can require TLS connections between your devices and the WSUS server. Additionally, you have the option to certificate-pin the WSUS server to your TLS certificates, much like you do with Windows Update. To use this option, you might need to make proper proxy or firewall exceptions for any device connecting to your TLS, certificate-pinned WSUS server. To learn more about WSUS certificate pinning, see:
Difficulties keeping Windows devices up to date with the latest updates might have to do with the embedded network security design. Windows Update doesn’t trust servers that don’t have TLS certificates issued by an actual Windows Update trust anchor. Your firewalls and proxies might block access to the trustworthy and necessary Windows Update service if your configuration is either intercepting TLS connections or isn’t passing TLS requests through for the necessary DNS subdomains. The good news is that there’s normally an easy fix for Windows Update connection issues. Essentially, make sure to trust FQDN subdomains of the recommended DNS subdomains.
Here are some resources to help you learn even more:
Continue the conversation. Find best practices. Bookmark the Windows Tech Community. Looking for support? Visit Windows on Microsoft Q&A.
Mit der „Low-Latency-Profile“-Funktion will Microsoft unter Windows 11 den Start von Apps beschleunigen, indem das Betriebssystem kurzzeitig die CPU hochtaktet. In sozialen Netzwerken wurde der Performance-Boost kontrovers diskutiert. Prominente Microsoft-Entwickler wehren sich nun gegen den „Cheating“-Vorwurf.
© 2026 Made by BlackRabbitZ.
