Windows Server 2012 R2 WSUS Issue: Clients cause the WSUS App Pool to become unresponsive with HTTP 503
Something interesting that I recently uncovered while implementing WSUS with Windows Server 2012 R2 as Software Update Points in Configuration Manager. The WSUS App Pool by default has relatively low Rapid-Fail Protection thresholds. These thresholds were causing the WSUS Web Service to eventually lock-out with HTTP 503.
The errors are associated with these events:
Log Name: Application
Source: Windows Server Update Services
Event ID: 12072
The WSUS content directory is not accessible.
System.Net.WebException: The remote server returned an error: (503) Server Unavailable.
at Microsoft.UpdateServices.Internal.HealthMonitoring.HmtWebServices.CheckContentDirWebAccess(EventLoggingType type, HealthEventLogger logger)
Log Name: Application
Source: SMS Server
Event ID: 7000
On 8/13/2015 3:22:40 AM, component SMS_WSUS_CONTROL_MANAGER on computer WSUS.fqdn reported: WSUS Control Manager failed to configure proxy settings on WSUS Server "WSUS.fqdn".
Possible cause: WSUS Server version 3.0 SP2 or above is not installed or cannot be contacted.
Solution: Verify that the WSUS Server version 3.0 SP2 or greater is installed. Verify that the IIS ports configured in the site are same as those configured on the WSUS IIS website.You can receive failure because proxy is set but proxy name is not specified or proxy server port is invalid.
Log Name: System
Event ID: 5074
A worker process with process id of '%1' serving application pool '%2' has requested a recycle because the worker process reached its allowed processing time limit.
Increasing the thresholds from default was necessary to maintain the service. Here's what I found to work in a customers production environment:
- On your WSUS Server, launch the IIS Manager
- Open Application Pools
- Right click 'WsusPool' and select 'Advanced Settings...'
- To support the maximum SCCM Software Update Point clients, change 'Queue Length' from the default 1,000 to 25,000
- If your server is NUMA aware, change 'Maximum Worker Processes' from the default 1 to 0. If you don't know if your server is NUMA aware, leave this value default
- Change '"Service Unavailable" Response Type' from the default HttpLevel to TcpLevel
- Change 'Failure Interval (minutes) from the default 5 to 30
- Change 'Maximum Failures' from the default 5 to 60
- Click 'OK' to save the App Pool changes
- From an administrative command prompt, type IISRESET
Your clients should now be able to check-in to the Software Update Point / WSUS service.