ConfigMgr Support Tip: Troubleshooting high CPU utilization on UNIX and Linux clients

~ Dennis Donahoe | Senior Support Escalation Engineer

If you have UNIX or Linux clients in your environment and use System Center 2012 Configuration Manager (ConfigMgr 2012 or ConfigMgr 2012 R2) to manage those clients, here’s a tip in case you run into a problem where those clients experience high CPU utilization. It’s not a common problem or one we see very often, however if you do see it then here’s something that might help you get it resolved fairly quickly.

First of all, be aware that there are separate releases of Cumulative Updates for the Configuration Manager 2012 Client for UNIX/Linux as these are totally separate from the regular Configuration Manager 2012 Cumulative Updates. Several of the aforementioned Cumulative Updates for UNIX/Linux clients include fixes for 100% CPU utilization issues therefore the first step should always be to make sure your clients are up to date.

Once you’ve ensured that all clients are all up to date, the next step is to obtain a verbose log from an affected client. To enable verbose logging, modify /opt/microsoft/configmgr/etc/scxcm.conf and change all instances of INFO to TRACE. Once this is done, recreate the problem and then examine the scxcm.log file using CMTrace.exe.

NOTE When you enable verbose (TRACE) logging there will be a significant amount of data captured in the scxcm.log file. Be sure to monitor the size of this file and disable verbose logging when troubleshooting is complete. To disable verbose logging, change all instances of TRACE to INFO in /opt/microsoft/configmgr/etc/scxcm.conf.

Look for lines in the log file with different values after "SUM" which indicates software updates. Unless you are deploying Endpoint definitions to these clients, there is normally no reason for these to be sent to UNIX clients unless they somehow ended up in a collection that had software updates deployed to it. Below are some examples. Note that each entry in the log is very large so the SUM info is within a line that can be several pages long in CMTrace:

Site_3FA8DA6A-C0C5-417E-B465-B254E4000579/SUM_ee0a56fa-19aa-40f7-8986-90d5a620c448
Site_3FA8DA6A-C0C5-417E-B465-B254E4000579/SUM_4d9fa338-6348-411c-881c-3cdb8b0ded26
Site_3FA8DA6A-C0C5-417E-B465-B254E4000579/SUM_32521295-226b-4a8c-b88c-5732b895ba5

If you see such entries and they are not expected, open the Configuration Manager console and go to Assets and Compliance–> Devices, then right-click on a problem machine and select Deployments, specifically looking for DCM or Software Updates or Definitions. Remove any deployments. Next, right-click on the same client and select Client Settings–> Resultant Client Settings. Everything will be grayed out (greyed out) since you cannot change these settings, however look at the Endpoint and Software Updates section and verify they are set to No. When complete, see if the problem is resolved. If so, there is likely an issue with that deployment that will need additional troubleshooting.

If you did not see a deployment, identify a GUID from the log (e.g. ee0a56fa-19aa-40f7-8986-90d5a620c448). Open the Configuration Manager console and go to Software Library–> All Software Updates, right-click on the title bar and check Update Unique ID. It will show the GUIDs for all updates. Paste that GUID into search and see what update it relates to. Try removing that update to see if it resolves the issue.

If none of these suggestions fix the problem, go into SQL Management Studio and run the following query, substituting a client NetBIOS name for ClientMachineName. Do this for a working and non-working machine so you can see what, if any, collections the failing machines are in that working machines are not.

select v_FullCollectionMembership.CollectionID As 'Collection ID', v_Collection.Name As 'Collection Name', v_R_System.Name0 As 'Machine Name' from v_FullCollectionMembership
JOIN v_R_System on v_FullCollectionMembership.ResourceID = v_R_System.ResourceID
JOIN v_Collection on v_FullCollectionMembership.CollectionID = v_Collection.CollectionID
Where v_R_System.Name0='ClientMachineName'

If you are able to find any discrepancies, remove one of the failing machines from any collections that a working machine is not in to see if that resolves the issue. If it does, look at what is being deployed to the failing collection.

If feasible, it may be easiest to simply remove the problem clients from all collections that working machines were not in, and if necessary, remove and reinstall the clients. In many cases this will resolve the issue.

Dennis Donahoe | Senior Support Escalation Engineer| Microsoft GBS Management and Security Division

Get the latest System Center news onFacebookandTwitter: