ConfigMgr 2012 SP1 and UNIX/Linux Clients - Part 2: General Operations and Inventory
So finally I got around to writing up part two of this three part series on managing UNIX and Linux clients with Configuration Manager 2012 SP1, which is going to cover general client operations and inventory.
So first things first, as we’re talking UNIX and Linux management it’s important to recognise that much of the administration of these servers is done via remote command line, and for that reason we don’t supply any sort of client GUI like we do in the Windows world. This means that if you want to interact with the UNIX/Linux client you are going to need to do so via terminal / SSH.
Let’s get logging…
Before we kick off some typical client operations let have a look at where the client log files are located so you can watch how the client interacts with the system when you run commands.
/var/opt/microsoft/scxcm.log – This log file records both installation (think ccmsetup.log in the Windows equivalent world) and operational information (almost everything in %windir%\CCM\Logs). If you’re troubleshooting UNIX/Linux client operations then you are going to become familiar with this log file.
/opt/microsoft/nanowbem/scxcmprovider.log – This is the CIM service log file (nanowbem.bin) which captures the CIM service operations. While useful for troubleshooting purposes, you shouldn’t find yourself venturing in here too much.
By default the logging level for both log files are only going to parse error messages, which for the provider log file is probably enough, however you might find yourself needing more verbose information if you’re troubleshooting client operations with scxcm.log. The following log levels are supported;
• ERROR: Indicates problems that require attention.
• WARNING: Indicates possible problems for the client operations.
• INFO: More detailed logging that indicates the status of various events on the client.
• TRACE: Verbose logging that is typically used to diagnose problems. [NOTE This trace level is only supported for scxcm.log]
(Ref; https://technet.microsoft.com/en-us/library/hh427342.aspx#BKMK_LogFilesforLnU)
To turn it up we need to edit the config file /opt/microsoft/configmgr/etc/scxcm.conf
If you open the config file with vi (or whatever your favourite text editor is ?) you’ll see its pretty simple;
FILE (
PATH: /var/opt/microsoft/scxcm.log
MODULE: ERROR
MODULE: scx.client ERROR
)
To change the logging level just change all instances of the MODULE tag to your desired level. So for example to turn on maximum logging your scxcm.conf file would look like the following;
FILE (
PATH: /var/opt/microsoft/scxcm.log
MODULE: TRACE
MODULE: scx.client TRACE
)
Just remember that when you turn verbose (TRACE) logging on, there’s going to be a lot of data captured in the scxcm.log file (especially when you consider how many log files we have in the Windows client world, compared to just one here that captures everything including installation). As we don’t perform any automatic log truncation it’s really important to make sure these logs file are maintained as part of your standard log rotation process.
The config file also gives you the option to set the log file path by setting the PATH tag. Additionally, just for the record right now there is no supported method of parsing log messages to syslog.
Where’s my machine policy refresh action?
Now we’ve got logging turned up, let’s get onto managing the client. If you are familiar with ConfigMgr then you are familiar with the Machine Policy Refresh action on clients. To perform this from the UNIX/Linux client, execute the following command;
/opt/microsoft/configmgr/bin/ccmexec -rs policy
If you tail the scxcm.log file (tail –f /var/opt/microsoft/scxcm.log) you’ll see the same order of actions that you are used to with the Windows client, i.e. policy agent contacting the MP and downloading the policy, then policy evaluator coming to life and evaluating the policy.
In part 3 of this series, when walking through software distribution we will actually step through the log file and see how things compare to a Windows client.
Hardware Inventory
Hardware inventory (including installed software) is supported by the Configuration Manager 2012 SP1 client for UNIX and Linux. As already covered, we deploy the nanowbem CIM server along with the client to give WMI like functionality on your Linux/UNIX system. This means we can use the same inventory tables as Windows clients and all classes/properties are mapped to windows equivalents (e.g. Win32_ComputerSystem = SCXCM_ComputerSystem).
In terms of functionality nothing is really different from the Windows client world;
- The inventory collection cycle is defined using client settings
- You can view inventory data for UNIX/Linux clients using Resource Explorer or SQL Reporting
- You can turn classes and properties on and off using client settings
- Both full and delta inventory scans are performed
To trigger an inventory scan from a client run the following command;
/opt/microsoft/configmgr/bin/ccmexec -rs hinv
If you look at the scxcm.log you will see the inventory agent kick into life and start querying the local CIM “database”.
What’s different is how we actually store inventory data on the UNIX/Linux client. In the Windows world we are typically querying WMI for inventory data, whereas the UNIX/Linux client stores its inventory data in a series of XML files. You can view the default classes by directory listing /opt/microsoft/configmgr/root/cimv. If you were tailing the log file when you ran your machine policy refresh you may have noticed the references to these folders.
If we take a look at Win32_ComputerSystem.xml using less for example (do not modify these files), you can see all the properties we are capturing from our local system. The xml files list all available properties for a particular class, but only properties containing a value are returned back to the database.
If you want to view inventory data on the client locally, you can use the nwcli utility to query the “WMI database”. For example, to view the SCXCM_ComputerSystem class I could run the following from a terminal;
/opt/microsoft/nanowbem/bin/nwcli ei root/cimv2 SCXCM_ComputerSystem
(ei = enumerate instances, followed by namespace, followed by class)
Which would produce the following output;
instance of SCXCM_ComputerSystem
{
Caption=suse11rtm
Description=AT/AT COMPATIBLE
[Key] Name=suse11rtm
[Key] CreationClassName=SCXCM_ComputerSystem
WakeUpType=6
AutomaticResetCapability=false
CurrentTimeZone=60
ResetCount=-1
ResetLimit=-1
DNSHostName=suse11rtm
Domain=
Manufacturer=Microsoft Corporation
Model=Virtual Machine
SystemType=x64
BootOptionOnLimit=1
BootOptionOnWatchDog=1
ChassisBootupState=3
PowerSupplyState=3
ThermalState=1
NumberOfProcessors=1
NumberOfLogicalProcessors=1
TotalPhysicalMemory=1969881088
}
If you are interested in capturing custom data, I will talk about extending inventory in another blog post coming soon.
Client Setting Considerations
Before closing out I just wanted to call out something I recommend to my customers currently managing, or looking to manage, UNIX and Linux clients with Configuration Manager 2012 SP1 – Client Settings!
Consider creating a separate set of Client Settings for your UNIX and Linux clients, with attention on the following;
- No user policy is processed by the UNIX/Linux client so you can turn this setting off
- Power Management policies are not supported so you can turn these off
- Software Metering is not supported and so can be turned off
- If you extend inventory you can be sure that you are only targeting the correct systems with the new classes (and you may even have distribution specific classes and so may want to have distribution specific client settings!)
So that brings me to the end of Part 2, covering operations and inventory. Part 3 will cover Software Distribution and will look at what options are supported and how to trace software distribution through the log files!