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 (13)

  1. Jure Jereb says:

    Great blog post! We had the same issues with SCCM/WSUS, and your suggested settings has solved them! Thank you very much! 🙂

  2. George says:

    Thanks for sharing ..was facing the same issue

  3. beta says:

    Thank you! I´ve searched so long for a solution!

  4. Carlos says:

    great post!
    solve my problem.

  5. Juan Pablo Carrillo Vaccaris says:

    Thanks for sharing i had the same issue !!

  6. André Sousa says:

    Great Post!
    Thanks.

  7. John Barneveld says:

    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 ?

  8. Gustavo says:

    It's work! Very Thanks!

  9. Awal_RM says:

    This fixed my SCCM WSUS issues too, thanks for posting. 🙂

    Do we have any insight into the root cause of this issue?

  10. Morten Rognaldsen says:

    Thanks for this great post!!
    We had this same SCCM/WSUS issue and spent weeks uninstalling / reinstalling +++ until I found your solution.

  11. esert says:

    Thank you!!! I have been searching for this answer!

  12. Filip says:

    Perfektní, vyřešil jsem v potíže se spuštěním WSUS

  13. Pyro Fox says:

    Worked like a charm! Thanks so much!

Skip to main content