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:

1. On your WSUS Server, launch the IIS Manager
2. Open Application Pools
3. Right click 'WsusPool' and select 'Advanced Settings...'
4. To support the maximum SCCM Software Update Point clients, change 'Queue Length' from the default 1,000 to 25,000
   
5. 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
   
6. Change '"Service Unavailable" Response Type' from the default HttpLevel to TcpLevel
7. Change 'Failure Interval (minutes) from the default 5 to 30
8. Change 'Maximum Failures' from the default 5 to 60
   
9. Click 'OK' to save the App Pool changes
10. 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 issue

• Anonymous
  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 WSUS

• Anonymous
  October 19, 2016
  Worked like a charm! Thanks so much!