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 System.Net.HttpWebRequest.GetResponse()
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
Source: Microsoft-Windows-WAS
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.
Comments
Anonymous
September 08, 2015
Great blog post! We had the same issues with SCCM/WSUS, and your suggested settings has solved them! Thank you very much! :)Anonymous
April 11, 2016
Thanks for sharing ..was facing the same issueAnonymous
April 20, 2016
Thank you! I´ve searched so long for a solution!Anonymous
June 02, 2016
great post!solve my problem.Anonymous
June 02, 2016
Thanks for sharing i had the same issue !!Anonymous
August 02, 2016
Great Post!Thanks.Anonymous
August 03, 2016
I also had the same problem. Great Post.Now i have difficulties with my MP after installing a PKI to support mac devices. Any suggestions ?Anonymous
September 01, 2016
It's work! Very Thanks!Anonymous
September 01, 2016
This fixed my SCCM WSUS issues too, thanks for posting. :)Do we have any insight into the root cause of this issue?Anonymous
September 28, 2016
Thanks for this great post!!We had this same SCCM/WSUS issue and spent weeks uninstalling / reinstalling +++ until I found your solution.Anonymous
October 13, 2016
Thank you!!! I have been searching for this answer!Anonymous
October 18, 2016
Perfektní, vyřešil jsem v potíže se spuštěním WSUSAnonymous
October 19, 2016
Worked like a charm! Thanks so much!