I thought I’d share a nugget of information that proved helpful when troubleshooting WSUS Windows Update issues. And this also serves as a reminder that sometimes you have to go back and read the manual.
I had a client machine that was configured properly to use my intranet WSUS server over SSL, and the WSUS server was also configured correctly (we’d been using this WSUS server for a long time). But, whenever I tried to install updates, I got the error code 80072EE2. A quick error lookup in CMTrace showed this means “The operation timed out, Source – WinHTTP.” Seemed like a network issue, but wasn’t the connection supposed to be SSL?
Then I looked at the machine’s WindowsUpdate.log (fortunately still a Win 8 machine, on Windows 10 you need to generate this log file following these instructions.) As the update session started, I could see an HTTPS destination to the client web service was accessed. Then as each file download was attempted, it switched to HTTP. That confused me. Why was my WSUS SSL environment switching over to HTTP? I verified the Windows Update intranet location was correct in the registry. Here’s some log snips:
It turned out, I had to read the fine print more closely on Technet’s Configure WSUS page here: https://technet.microsoft.com/en-us/library/hh852346(v=ws.11).aspx
The answer is toward the bottom under the heading Configure SSL on the WSUS server.
WSUS requires two ports for SSL: one port that uses HTTPS to send encrypted metadata, and one port that uses HTTP to send updates.
and …
You cannot configure the whole WSUS website to require SSL because all traffic to the WSUS site would have to be encrypted. WSUS encrypts update metadata only. If a computer attempts to retrieve update files on the HTTPS port, the transfer will fail.
So, this behavior is by design. HTTPS is used for encrypted metadata, and HTTP is used to download the binaries (the actual update files). Note that if you’re using System Center Configuration Manager to deploy updates in an SSL-configured infrastructure, port 8530 is not used to download updates. This is because content is downloaded from a distribution point as packages. Only port 8531 is used for WSUS metadata.
The problem I had was that an intervening firewall had port 8531 open but not 8530. I didn’t think I needed 8530. Whoops. When it was time to download the update files, it failed. I had the network team open up the port, and voila, it worked again.
I hope you find this helpful in your Windows Update troubleshooting endeavors.