SCCM
WSUS App Pool Crashes with SCCM Syncronization
Reading Time: 3 minutesI’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: 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.
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.
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.
Thanks,
SCCM 2012 R2 Reinstall Fails – Configuration Manager Requires a Dedicated SQL Server Instance
Reading Time: < 1 minuteRecently I had to reinstall an SCCM 2012 R2 instance, and came across a strange error when I ran the Prerequisite Check.
Dedicated SQL Server instance: Configuration Manager requires a dedicated SQL Server instance to host the site database. You selected the SQL Server instance that site hosts the Configuration Manager database for another site. Select a different SQL Server instance for this new site to use, or resolve the conflict by uninstalling The Other excellant site or moving to a different database SQL Server instance.
After some research it turns out this (in my case anyways) is due to the SCCM uninstall process not properly completing. SCCM doesn’t need it’s own SQL instance, it just requires that you only have one SCCM instance per SQL instance. To make sure this is the case, the prerequisite checker looks for a few registry keys on the SQL server that the install is looking to use. To fix this error, delete the following keys from the SQL server.
[HKLM\SOFTWARE\Microsoft\SMS\Operations Management\Components\SMS_SITE_SQL_BACKUP_<SITESERVERNAME>]
[HKLM\SOFTWARE\Microsoft\SMS\SMS_SITE_SQL_BACKUP_<SITESERVERNAME>]
[HKLM\SOFTWARE\Microsoft\SMS\Components\ SMS_SITE_SQL_BACKUP_<SITESERVERNAME>]
After they are deleted, run the prerequisite checker again and viola!
I hope this makes your day at least a little bit easier.
Thanks,
SCCM 2012: WSUS Server version 2.0 SP2 or above is not installed or can not be contacted
Reading Time: 2 minutesThis week I had an issue where I needed to rebuild the WSUS server leveraged by my SCCM 2012 Software Update Point. After uninstalling/reinstalling WSUS from server roles, I downloaded and installed SP2 for WSUS 3.0 since that’s the requirement for SCCM 2012. At this point the normal train of thought would be “I met the requirements, all should be well!”. No. That’s not the case.
SMS_WSUS_CONFIGURATION_MANAGER status query was showing tons of errors including that of “WSUS Server version 2.0 SP2 or above is not installed or can not be contacted”, so were the other WSUS related status queries. Dig, dig, dig! This is the point where the logs come in handy.
Pop open WCM.log in CMTrace and the verbosity is a life saver!
You will notice that, just like with all other SCCM components if there is an issue it will try again every 60 minutes. In this case every 60 minutes it was the same 8 log entries. “Supported WSUS version not found”, but wait — one of the log entries tells you exactly what it’s looking for (wouldn’t that have been nice to know as a prereq?). WSUS 3.0 SP2 + KB2720211 + KB2734608. After these two KB hotfixes are installed, restart the SMS_WSUS_CONFIGURATION_MANAGER (or restart the machine) component and VOILA! Everything starts configuring and processing correctly. I’ll include a link to the two hotfixes below. Happy updating!
KB2720211 x64: http://www.microsoft.com/en-us/download/details.aspx?id=29999
KB2734608 x64: http://www.microsoft.com/en-us/download/details.aspx?id=30747
I hope I’ve made your day, at least a little bit easier.
Thanks!
SCCM Client Logs for Software Update Troubleshooting
Reading Time: < 1 minuteWe 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.
- UpdatesDeployment.log
- 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.
- UpdatesHandler.log
- Provides information about software update compliance scanning and about the download and installation of software updates on the client.
- ScanAgent.log
- Provides information about the scan requests for software updates, what tool is requested for the scan, the WSUS location, and so on.
- WUAHandler.log
- Provides information about when the Windows Update Agent on the client searches for software updates.
- UpdatesStore.log
- 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!
Thanks!