SCCM SUP Crash

I’ve seen this a few times now, sometimes with standalone WSUS but mostly with SCCM running a software update point. Every time SCCM does an update synchronization – the app pool crashes. If it runs again it will typically complete, but it’s still rather annoying especially if you have the SCOM management pack for IIS and/or SCCM. You’ll see things like the following.

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)

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.

What it turns out to be is the WSUS App Pool has some “rapid-fail” settings on the application pool in IIS itself. They are being overrun with the overhead of the SCCM SUP sync and causing a pool recycle. It turns out, this is actually a pretty easy fix.

Launch IIS Manager on the server that hosts WSUS

Open Application Pools

Right click “WSUSPool”, then “Advanced Settings”

Change ‘Queue Length’ from the default 1,000 to 25,000. You will note this number is also the same as the maximum number of clients supported per SUP in an SCCM architecture.

Locate the “Private Memory Limit (KB). Default is set to “1843200” (~1.8GB) and a good practice I’ve found is to set it to “7843200” (~7.8GB). If for whatever reason you are still exceeding this limit you can set this to “0” denoting an unlimited amount.

Restart the “WSUSPOOL” app pool.

If you run a standalone WSUS instance, you can now go do a manual synchronization in the WSUS management console to test the change.

Or, if you have an SCCM instance leveraging WSUS you DO NOT DO ANYTHING IN THE WSUS CONSOLE (if you didn’t know). Go ahead and launch your SCCM console and do the sync from there.

These changes should have fixed your problems, and all should be running well! If not, I recommend you contact Microsoft (especially if you have a very large infrastructure) since there are a few more tweaks you can make in IIS.