Since ConfigMgr 2012 SP1 was released, we have been able to install a native client onto various flavours of Linux and UNIX. Managing the client is obviously quite different from the Windows version (there’s no UI for a start), but it wouldn’t be ConfigMgr without a decent log file 🙂
The log file for Linux/UNIX clients works slightly differently than the ConfigMgr logs files we’re used to in a couple of ways:
- By default, you can only read the log file from the system console – from the system’s graphical UI (assuming there is one), from Terminal or remotely via SSH;
- By default, the log file doesn’t truncate – it keeps growing indefinitely.
Now, as a ConfigMgr administrator, I’m very likely to have an administrative workstation with CMTrace for reading system logs – I don’t really want to have to connect to a remote system simply to read a log file. Apart from anything else, it’s an administrative practise which will never scale.
So what I want to set up is:
- Remote access to the ConfigMgr client log so that I can open it with CMTrace, and;
- Regular truncation and archiving of the log file.
Note: The client system I’m using for this blog post is running Ubuntu 14.04 LTS x64, so the commands I’ve used are pertinent for that particular OS. Other operating systems (especially other Ubuntu versions) should be very similar or identical, but you might need to double-check.
Also Note: I’m setting up this entire solution remotely via SSH. If your Linux/UNIX system has a graphical UI you could use that, but Linux/UNIX systems in production almost never have one, so it’s worth getting used to doing everything via command line.
Part 1 – Remote access to the client log
In order to remotely access the log folder on the Linux system, we need to install and configure Samba, then create a share which is accessible to specific authenticated users.
Your system might already have Samba installed. To check, run the following:
apt-cache policy samba
If Samba is not installed, then to install it run the following commands:
sudo apt-get update <– This gets the latest package information from the online repositories
sudo apt-get install samba <– This downloads the binaries for Samba and installs them
Next, we need to create a Samba password for our remote user. The user must exist as a local user on the system, but unfortunately the local password and the Samba password are two separate entities (even when they are exactly the same). To set a Samba password, run the following:
sudo smbpasswd -a <user> <– The <user> is the case-sensitive local username of the user (e.g. james)
Now we need to create a share for our Samba user to access remotely. Samba service and share configuration is stored in a configuration file, usually located at /etc/samba/smb.conf. To modify the configuration file, run the following:
sudo cp /etc/samba/smb.conf ~ <– This creates a copy of the smb.conf file (just in case!)
sudo nano /etc/samba/smb.conf <– This launches the text-based nano editor
Make the following additions to the configuration file:
oplocks = no
kernel oplocks = no
[configmgr_log] <– This section doesn’t exist – add it right at the bottom of the smb.conf file
path = /var/opt/microsoft
available = yes
valid users =
read only = yes
browseable = yes
public = yes
writable = no
csc policy = disable
Restart the Samba service to make the changes take effect by using:
sudo restart smbd
and check that the entries in smb.conf are correct by running:
Finally, browse to \\<servername>\configmgr_log from your Windows workstation. You should see the scxcm.log – open it in CMTrace and voila!
Part 2 – Managing the log file
Left unattended, the scxcm.log file will simply grow and grow. Not useful. And also not the general ConfigMgr experience on Windows.
Most Linux distros include a log management utility called logrotate – we can make use of it for scxcm.log. Logrotate should already be installed, use the following command to double-check:
apt-cache policy logrotate
If it’s not installed, use the following command to install it:
sudo apt-get install logrotate
As with Samba, logrotate’s functionality is handled by a configuration file, in this case /etc/logrotate.conf – to edit the file use the following command:
sudo nano /etc/logrotate.conf
Go to the very end of the file and enter the following lines:
Save the file and exit. The lines you’ve entered tell logrotate which log file to process (scxcm.log), the size at which the log file will be processed (2M), to create a copy of the original log file before emptying it (copytruncate), to append a date extension to the copy (dateext/dateyesterday) and to store all the copies in the original folder (noolddir).
You can manually trigger logrotate to process the modified configuration file by using:
sudo logrotate /etc/logrotate.conf
Take a look in the log folder and, assuming that the original log file was larger than 2M, you should see a new file called scxcm.log-<DATE>. Even though the extension has changed, you can still open the log file in CMTrace.
However, manual processing isn’t desireable – this is something we want to run automatically without user interaction. So, we can make use of the cron job scheduler.
If logrotate was already installed on your system, then there should also be an existing cron job for logrotate. To check this, run:
If there isn’t a logrotate entry, you can create a new one by running the following command:
sudo nano /etc/cron-daily/logrotate
and then enter the following bash script:
# Clean non existent log file entries from status file
test -e status || touch status
head -1 status > status.clean
sed ‘s/”//g’ status | while read logfile date
[ -e “$logfile” ] && echo “\”$logfile\” $date”
done >> status.clean
mv status.clean status
test -x /usr/sbin/logrotate || exit 0
Save the file and now logrotate will run every day as a cron task.
And that’s it! We can now remotely access the scxcm.log file, and the log will never get larger than 2M in size 🙂