sodcalculator

10 Tech How-To

WSUS 0x80072ee6 Error: Causes and Fixes

Guide 10-31495 · Updated · Step by step

The WSUS 0x80072ee6 error occurs when a Windows computer cannot connect to its WSUS (Windows Server Update Services) server, typically because of a TLS/SSL or proxy issue. The fix usually involves correcting the WinHTTP proxy settings or updating the TLS configuration on the client. This article explains what causes the error and walks through the most effective ways to resolve it.

What Does 0x80072ee6 Mean?

The hexadecimal code 0x80072ee6 is a Windows Update error that maps to ERROR_WINHTTP_CANNOT_CONNECT. In the context of WSUS, it means the Windows Update client on a workstation or server tried to reach the WSUS server (or Microsoft’s update servers) over HTTP/HTTPS and the connection failed. The failure can happen at any point in the network path: DNS resolution, TCP connection, TLS handshake, or proxy authentication.

This error is most common in environments where WSUS is configured with HTTPS, because the client must trust the WSUS server’s certificate and have the correct TLS protocol enabled. However, it also appears with plain HTTP WSUS setups when a proxy server is misconfigured or when the WSUS server is temporarily unavailable.

Common Causes of the WSUS 0x80072ee6 Error

Several distinct issues can produce this same error code. Identifying the root cause is the first step toward a permanent fix.

  • Proxy server misconfiguration – The WinHTTP proxy settings are wrong, or a proxy is required but not set. This is the most frequent cause, especially after a network change.
  • TLS/SSL protocol mismatch – WSUS servers running on Windows Server 2012 or older may only support TLS 1.0, while newer Windows clients have TLS 1.0 disabled by default. The handshake then fails.
  • Certificate problems – For HTTPS WSUS, the client may not trust the WSUS server’s certificate (e.g., it was signed by an internal CA that isn’t in the client’s Trusted Root store).
  • DNS or network connectivity – The client cannot resolve the WSUS server name, or a firewall blocks port 8530 (HTTP) or 8531 (HTTPS).
  • WSUS server is down or overloaded – The server may be rebooting, have a full database, or be unable to handle the request.
  • Windows Update service corruption – The Windows Update service (wuauserv) or its dependencies may be in a bad state.

Before You Start: Check the Basics

Before diving into advanced fixes, run through these quick checks. They take less than a minute and can save you a lot of time.

  1. Confirm the WSUS server is running and reachable from the client: ping wsus-server-name or Test-NetConnection wsus-server-name -Port 8530.
  2. Verify the client is actually configured to use WSUS. Open an elevated command prompt and run gpresult /r to see if the WSUS policy is applied.
  3. Check the Windows Update log for more details: C:\Windows\WindowsUpdate.log (on Windows 10 1809 and later, use Get-WindowsUpdateLog to convert it).
  4. Try a manual update scan: wuauclt /detectnow (older Windows) or UsoClient StartScan (Windows 10/11).

Fix 1: Correct the WinHTTP Proxy Settings

The Windows Update client uses WinHTTP, not WinINET (the proxy settings in Internet Explorer). So even if your browser works, WinHTTP may be misconfigured. To fix it:

  1. Open an elevated command prompt (Run as Administrator).
  2. To see the current proxy settings, run: netsh winhttp show proxy
  3. If you need to set a proxy, use: netsh winhttp set proxy proxy-server-name:port. For example, netsh winhttp set proxy myproxy:8080.
  4. If you don’t use a proxy, reset it to direct connection: netsh winhttp reset proxy
  5. Restart the Windows Update service: net stop wuauserv then net start wuauserv.

If the client is behind a proxy that requires authentication, you may need to set the proxy with credentials using the netsh winhttp set proxy command with the username= and password= parameters. However, storing credentials in WinHTTP is not recommended for security reasons; consider using a transparent proxy or WPAD instead.

Fix 2: Enable TLS 1.2 on the WSUS Server and Client

If your WSUS server runs on Windows Server 2012 or 2012 R2, it may only support TLS 1.0 by default. Modern Windows clients (Windows 10/11, Server 2016+) have TLS 1.0 disabled. The solution is to enable TLS 1.2 on the WSUS server.

  1. On the WSUS server, open Registry Editor (regedit).
  2. Navigate to HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2.
  3. If the key doesn’t exist, create it. Then create two subkeys: Client and Server.
  4. In each subkey, create a DWORD value named Enabled and set it to 1.
  5. Also create a DWORD named DisabledByDefault and set it to 0.
  6. Reboot the server.

On the client side, ensure TLS 1.2 is enabled (it is by default on Windows 10/11). You can check via Internet Options > Advanced > Security, or via registry under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp.

Fix 3: Verify the WSUS Certificate Trust (HTTPS Only)

If your WSUS uses HTTPS (port 8531), the client must trust the server’s certificate. If the certificate is issued by an internal CA, that CA’s root certificate must be in the client’s Trusted Root Certification Authorities store.

  1. On the client, open certmgr.msc.
  2. Expand Trusted Root Certification Authorities > Certificates.
  3. Look for your internal CA’s certificate. If it’s missing, import it from the CA’s certificate file or from the WSUS server.
  4. Also check that the WSUS server’s certificate is valid (not expired) and that the server name in the URL matches the certificate’s subject name.

If you’re not sure how to get the CA certificate, ask your network administrator. This is a common issue when WSUS is set up with a self-signed certificate or an internal CA that isn’t distributed via Group Policy.

Fix 4: Reset Windows Update Components

If the error persists, the Windows Update components on the client may be corrupted. A full reset can help.

  1. Open an elevated command prompt.
  2. Stop the relevant services: net stop wuauserv, net stop cryptSvc, net stop bits, net stop msiserver.
  3. Rename the SoftwareDistribution folder: ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
  4. Rename the Catroot2 folder: ren C:\Windows\System32\catroot2 catroot2.old
  5. Restart the services: net start wuauserv, net start cryptSvc, net start bits, net start msiserver.
  6. Try the update scan again.

This reset clears the update cache and forces the client to re-download the list of updates. It’s a safe procedure and won’t harm your system.

Frequently Asked Questions

Why does the error appear only on some computers?

If only a few computers show 0x80072ee6, the issue is likely client-specific: a misconfigured proxy, a missing certificate, or a local firewall blocking the WSUS port. Check those clients individually. If all clients are affected, the problem is on the WSUS server side (e.g., server down, TLS misconfiguration, or network-wide proxy change).

Can I ignore this error and use Microsoft Update directly?

If your organization uses WSUS for compliance or bandwidth reasons, ignoring the error means those computers won’t receive updates from WSUS. They may still get updates from Microsoft if the policy allows it, but that defeats the purpose of WSUS. It’s better to fix the connection.

Does the error affect Windows 10 and Windows 11 differently?

No, the error code is the same across Windows versions. However, the fix may differ slightly because newer Windows versions have TLS 1.0/1.1 disabled by default, so TLS misconfiguration is more likely on them. Also, the commands to trigger a scan differ (UsoClient StartScan vs wuauclt /detectnow).

What if the proxy is set correctly but the error persists?

Check if the proxy requires authentication. WinHTTP does not automatically use Windows credentials. You may need to set the proxy with a username and password using netsh winhttp set proxy. Also, verify that the proxy server itself allows traffic to the WSUS server or to Microsoft’s update endpoints.

Is it safe to reset the Windows Update components?

Yes, resetting Windows Update components is a standard troubleshooting step. It only clears cached update files and resets the update service state. It does not affect your personal files or installed programs. However, after the reset, the next scan may take longer because the client has to re-download the update catalog.

How do I check if the WSUS server is the problem?

On the WSUS server, open the WSUS console and check if it can connect to the database and to Microsoft Update. Also, look at the server’s event log for errors. You can also try to access the WSUS URL from a web browser on the client (e.g., http://wsus-server:8530) – if that fails, the server is unreachable.

Related

General steps for current mainstream versions; menus can differ by device and version. See the disclaimer or report an error.

More in this bed

The whole Tech How-To bed →