For testing purposes, I had to install a few Windows 7 and Windows 10 machines (with Office 2007, Office 2010 and Office 365 ProPlus) at a customer environment. It was a standard environment with a regular WSUS environment. In this customer environment there were approx. 5000 clients with Windows 7 (I know…) and Windows 10 all working fine with WSUS.
Several of my test machines had problems downloading updates from the WSUS environment, Windows Update returned the Code 80072F8F Windows Update encountered an unknown error as shown in the following screenshot:
Emptying the C:\Windows\SoftwareDistribution and restarting the Windows Update service did not help.
When using Google to search for this error a lot was returned (even recent issues which is the reason for my blogpost), but most of them were certificate related where the self-signed certificate on the WSUS server was expired. In my scenario this was not a problem since a valid 3rd party certificate was used on the WSUS server.
The WindowsUpdate.log in C:\Windows revealed more information. One thing I found was DownloadFileInternal failed for https://wsus.contoso.com:8531/selfupdate/wuident.cab: error 0x80072f8f.
When using a browser to navigate to this URL a got a certificate warning (which I did not expect btw) about verifying the certificate: This certificate cannot be verified up to a trusted certification authority as shown in the following screenshot:
From this point on it was easy, install the intermediate and root certificate in the certificate store of the workstation and Windows Update ran successfully – although it takes a very long time to deploy all updates, especially on Windows 7 with Office 2010 🙂
You might not expect a WSUS blog post on a site maintained by an Exchange consultant, but there are still customers using Exchange servers on-premises, and these need to be patched as well (and so are the clients of course).
After installing and a new WSUS server running on Windows 2016 I quickly ran into an annoying issue after configuring the WSUS server and downloading the updates. The console would no longer connect and generated a ‘Connection Error’ popup saying “An error occurred trying to connect the WSUS server. This error can happen for a number of reasons. Check connectivity with the server. Please contact your network administrator if the problem persists.”
When you click the copy error to clipboard button the following is copied:
The WSUS administration console was unable to connect to the WSUS Server via the remote API.
Verify that the Update Services service, IIS and SQL are running on the server. If the problem persists, try restarting IIS, SQL, and the Update Services Service.
The WSUS administration console has encountered an unexpected error. This may be a transient error; try restarting the administration console. If this error persists, Try removing the persisted preferences for the console by deleting the wsus file under %appdata%\Microsoft\MMC\.
If IISRESET was executed, it runs again for some time, but then the issue happens again. When looking at the IIS console when this error occurs it turns out that the WsusPool was stopped as can be seen in the following screenshot:
Starting the WsusPool solves the problem temporarily, but after some time it stops again. And again… and again…
It turns out to be a private memory issue in the WsusPool which seems to be depleted quickly. It is possible to assign more memory, but since I have no clue how much memory to assign I changed the setting to ‘0’ (1,843,200 KB is default) so the WsusPool can use anything it needs.
After changing the private memory limit for the WsusPool the error no longer occurs.