SCCM 2012 SUP
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.
Alert: ConfigMgr Server Component Issue Source: ConfigMgr WSUS Synchronization Manager Last modified by: System Last modified time: 3/27/2017 4:14:02 AM Alert description: Component ConfigMgr WSUS Synchronization Manager - SCCMServer.domain.local (SMS_WSUS_SYNC_MANAGER) on server SCCMServer.domain.local is not working properly.
Application Error: Faulting application name: w3wp.exe, version: 7.5.7601.17514, time stamp: 0x4ce7afa2 Faulting module name: KERNELBASE.dll, version: 6.1.7601.17651, time stamp: 0x4e21213c Exception code: 0xe0434352 Fault offset: 0x000000000000cacd Faulting process id: 0x141c Faulting application start time: 0x01cd64a70072cec1 Faulting application path: c:\windows\system32\inetsrv\w3wp.exe Faulting module path: C:\Windows\system32\KERNELBASE.dll Report Id: 3e5d5bdc-d09a-11e1-a2f5-00155d2c1824
Log Name: SystemSource: Microsoft-Windows-WASEvent ID: 5074A 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.Log Name: Application Source: Windows Server Update Services Event ID: 12072The 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.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.
I hope this makes your day at least a little bit easier.
We all know SCCM can be your best friend, and your worst nightmare. Today I had to compile a list of client logs to check for a friend of mine, and thought I’d share. These should get you 95% of the way on your troubleshooting (from the client side anyways). Remember to always use CMTrace as your SCCM log viewer, it just makes your life easier.
All of these listed directly below, should be located in C:\Windows\CCM\logs on your client.
- Provides information about the deployment on the client, including software update activation, evaluation, and enforcement. Verbose logging shows additional information about the interaction with the client user interface.
- Provides information about software update compliance scanning and about the download and installation of software updates on the client.
- Provides information about the scan requests for software updates, what tool is requested for the scan, the WSUS location, and so on.
- Provides information about when the Windows Update Agent on the client searches for software updates.
- Provides information about the compliance status for the software updates that were assessed during the compliance scan cycle.
You can also reference C:\Windows\WindowsUpdate.log which is a windows native log and not to SCCM, but is updated with actions taken by SCCM in regards to updates.
I hope this has made your day, at least a little bit easier!