After installation of a new Windows 7 machine with the newest version of the Windows Update Agent installed, the Software Updates scan initiated from Configuration Manager would fail with the error 80072ee2 (which translates to Connection Timeout).
Check the Basics
WARNING: SendRequest failed with hr = 80072ee2. Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <>
WARNING: Send failed with hr = 80072ee2.
First, ensure all your settings are correctly applied to the computer:
- Confirm that your Software Update Point (SUP) is correctly registered in the registry:
Values WUServer and WUStatusServer should both match the correct URL and port of the WSUS web site (eg. http://server.fqdn:port).
- Verify that the client can connect to the WSUS web site by opening a browser and navigating to http://server.fqdn:port/SimpleAuthWebService/SimpleAuth.asmx (replacing server.fqdn with your server fully qualified domain name and replacing port with the port you have WSUS configured to operate on).
In my case, the client configuration was correct and it was successfully able to communicate with the WSUS server web site. The issue was the Application pool for WSUS running out of memory and recycling while the client was waiting for response from the server.
Check the event log of the server hosting the Software Update Point (and Windows Server Update Services).
Log Name: Application
Source: ASP.NET 2.0.50727.0
Event ID: 1309
Task Category: Web Event
Event code: 3001
Event message: The request has been aborted.
Exception type: HttpException
Exception message: Request timed out.
[code] Log Name: System
Event ID: 5117
Description includes: WsusPool [/code]
If you are encountering Event ID 1309 in the Application log at around the same time as event ID 5117 in the System log, you most likely need to increase the memory allocated to the WSUS Application Pool in IIS. To do that, follow the steps in http://blogs.technet.com/b/configurationmgr/archive/2015/03/23/configmgr-2012-support-tip-wsus-sync-fails-with-http-503-errors.aspx.
After increasing the memory, the new clients were successfully able to scan for and apply updates!
UPDATE 15th May 2017 – Increasing the Queue Length and Private Memory of the WSUSPool is not recommended on Microsoft Docs for Software Update Points – Capacity planning recommendations for software updates.
I can only assume that the existing client I tested was working because it required less information from the WSUS server web application, while the new client required an entire catalog.
The take away of this post: monitor your servers event logs!
Also make sure your clients have up to date Windows Update clients. See Windows 7 Stuck on Checking for Updates for more troubleshooting and solutions.