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

~ Dennis Donahoe | Senior Support Escalation Engineer

ToolsIf 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: 


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 on Facebook and Twitter:

clip_image001 clip_image002

System Center All Up:

Configuration Manager Support Team blog: 
Data Protection Manager Team blog: 
Orchestrator Support Team blog: 
Operations Manager Team blog: 
Service Manager Team blog: 
Virtual Machine Manager Team blog:

Microsoft Intune:
WSUS Support Team blog:
The RMS blog:
App-V Team blog:
MED-V Team blog:
Server App-V Team blog:
The Surface Team blog:
The Application Proxy blog:

The Forefront Endpoint Protection blog :
The Forefront Identity Manager blog :
The Forefront TMG blog:
The Forefront UAG blog:

Comments (1)
  1. Steinar Eriksen says:

    Very nice article! However I don’t think this applies to us but we will try the verbose logging next week.

    Our Linux admin complains on high resource use on the client. We are aiming for installation of the agent on approx. 150-200 servers for inventory purpose but are waiting for a solution on the high utilization. Now we have the agent on 2 servers running RHEL
    6 x64.

    Both Endpoint Protection and Software Updates are disabled in the client settings for Linux servers and we are running client 5.00.7958.1060 (this is the latest, right?). We don’t have any deployments to the servers.

    Some tips leading us in the right direction would really be appreciated!

Comments are closed.

Skip to main content