Managing Macs using System Center Configuration Manager – Part One

This post is about one of my favourite subjects, namely Configuration Manager, referred to hereafter as ConfigMgr . If you don’t care about the intricacies of desktop management, I suggest you look away now cos this ain’t gonna interest you!

Before I get too far into this post, I should mention that I’ve written about this subject before on my blog at EduGeek. The content here therefore isn’t that new but I’ve rewritten some if it and hopefully improved on it a little too. I will also say that all of this was tried almost two years ago now so chances are that things have changed a little with ConfigMgr 2012 R2. From what I understand though, most of what I’ve written here is still accurate.

Anyway, I spend a lot of time at work using ConfigMgr manage the computers on our Windows network. We use it to almost its full extent; we use it for software and update deployment, operating system deployment, for auditing software usage, for configuration of workstations using DCM and a fair bit more besides.

As well as having more than 1500 Windows PCs, laptops and servers, I also have around 80 Macs to manage as well. To put it mildly, they were a nuisance. They were essentially unmanaged; whenever an update or a piece of software came along, we had to go to each individual Mac and install it by hand. The remote administration tools that we were using (Apple Remote Desktop and Profile Manager) were woefully inadequate. ARD requires far too much interaction and hasn’t had any significant update since Leopard was released. Profile Manager does an OK job of pushing down settings but for software management, it assumes that the Macs are personal devices getting all of their software from the App Store. That’s not really good enough. We were desperate to find something better.

We had been using ConfigMgr to manage our Windows PCs for a couple of years by that point and we had recently upgraded to 2012 SP1 which featured Mac management for the first time. We figured that we may as well give it a go and see what it was like. This is what I found out.

First of all, ConfigMgr treats Mac clients as Mobile devices so this means that you have to set up an HTTPS infrastructure and install an enrolment point for your Macs to talk to. Your management point needs to talk HTTPs as do your distribution points. That also means that you need to allocate certificates to your PXE points and task sequence boot media if you want them to talk to the rest of your infrastructure.

Once you have all of this set up, you need to enrol your Macs. Bear in mind that I looked at this when ConfigMgr 2012 SP1 was the current version. I understand that the process has changed a little in 2012 R2.

First of all, you need to download the Mac Management Tools from here for 2012 SP1  and here for 2012 R2. This gets you an MSI file which you need to install on your Windows PC. That MSI file contains a DMG file which you need to copy to your Mac. In turn, that DMG file contains the installer for the Mac client, the utility for enrolling your Macs in ConfigMgr and an application repackager. You have to install the client first of all from an elevated terminal session. Once that’s installed, you need to run another command to enrol your Mac into ConfigMgr. Assuming that you get this right, it will download a certificate and you’re good to go. When I was setting up the Macs to use this, I found a very good blog post by James Bannan which goes into a lot more detail.

Once your Mac has been enrolled, you will want to start doing something useful with it. At the moment, the Microsoft client has the following abilities:

  1. You can deploy software
  2. You can install operating system updates using the software deployment mechanism
  3. You can check and change settings by using DCM to modify PLIST files
  4. You can check and change settings by using DCM and Bash scripts to return values and make changes
  5. The agent takes an inventory of the software and hardware installed on your Mac and uploads it to your management point.

Deployment of Software and Updates

Deploying software on the Macs is broadly similar to doing the same process on Windows computers; you need to add the software to ConfigMgr as an application, create a deployment type with some detection rules, distribute the software to a DP and deploy the software to an application. The one difference is that you need to repackage the software into a format that ConfigMgr understands. It has a specific format for Mac software called “cmmac”. This is essentially a refactored ZIP file with either a .app, a .pkg or a .mpkg with an XML file which has an inventory of the ZIP, installation instructions and some predefined detection rules. I don’t want to make this already long post any longer than it needs to be so I’ll link to Mr. Bannan’s blog again which has a very good rundown of the entire process.

Changing settings using PLIST files

This isn’t the simplest of processes but it is quite effective. The first step is to open the ConfigMgr console on your Windows PC and go to the Assets and Compliance workspace. From there, go to Overview then Compliance Settings then Configuration Items. Right click and click Create Configuration Item. This will bring up the following window:


This example is going to set a proxy server against a network interface so I have named it appropriately and given it a description. Make sure that you set the Configuration Item Type to Mac OS X. Press the Next button

os selection

The next box lets you target your setting to specific versions of OS X. This screenshot was taken nearly two years ago when Microsoft hadn’t got around to adding Mountain Lion support. The current version supports up to and including Mavericks but not Yosemite (yet). Choose a specific version or not depending on what you need and press Next.

create setting

You then need to tell ConfigMgr what PLIST file you’re editing and which key you want to change. You also need to tell it if the key is a string, a number, a boolean value etc. Once you’ve done that, change to the Compliance Rules tab

edit rule

You need to add a rule for each setting that you’re changing. The one in the example above is setting the network name of the HTTP proxy server for the Ethernet interface on the Mac. To complete this example, you’d also need to set one for the HTTPS proxy, the port number and any proxy exceptions. Make sure that the Remediate is checked on any rules that you create and finish the wizard.

Once your compliance rule is completed, you will need to create a DCM baseline or add it to an existing baseline and deploy that baseline to a collection. I’m not going to go through the process here as it’s largely identical to doing it for a Windows PC.

Changing settings using Bash Scripts

This is probably the more powerful way of using DCM as you’re not relying purely on PLIST files to make your changes. If you can detect and remediate the setting that you want to change by using Bash, you can use the script here. This could be a setting in an XML file, a config file somewhere, a PLIST etc. I’m sure you get the idea. The process for creating a compliant rule using a script is largely similar to creating one for a PLIST and even more similar to creating one for a Windows machine. When you get to the third window, choose Bash Script in the setting type instead of Preference File. You get the opportunity to input two scripts; one to detect the setting and one to change it.

System Inventory

Again, this works in the same manner as it does for Windows machines, albeit not quite as detailed. At the very least, you get a list of the hardware and software installed on the machine and the agent keeps track of any changes made. Asset Intelligence and Software Metering isn’t supported however.

What can’t it do?

  1. OSD
  2. Remote Control
  3. Asset Intelligence
  4. Antivirus monitoring (Although it will deploy SCEP for Mac happily enough)
  5. Software Metering
  6. Power Management (Not easily anyway)


So I’ve covered how it all works. The question that you may be asking now is “How well does it work?”. The answer two years ago was “It works OK… ish. Maybe”. I shall try to explain.

The whole thing feels very much like a v0.1 beta rather than proper release software. It’s functional up to a point but there are some very rough edges and the functionality is nowhere near as strong on the Mac (and presumably Linux too) is it is on a Windows PC.

For starters, you can only deploy applications to machines and not to users. You can’t have optional installs. There is no Software Center so you can’t easily see what software has been deployed and what software is supposed to be deployed. When the agent detects a deployment, it comes up with a sixty minute countdown, the length of which can’t (or couldn’t) be changed. You can tell the Mac to start deployment when you see the countdown but if you’re deploying (say) six pieces of software and you leave the Macs unattended, the countdown comes up, expires, installs the software then the next countdown comes up, expires, installs the software and so on. It can take hours for multiple deployments to finish if you’re not paying attention.

I also found that the detection of deployments was rather erratic too. Just like with Applications for Windows PCs, there are detection rules which ConfigMgr uses to determine whether a piece of software is installed on the Mac or not. The ConfigMgr client is supposed to use the detection rules to detect whether the Application is installed or not and skip installation of deployed applications if it detects that’s it’s already present. Unfortunately the detection process seemed rather erratic and our Macs had a habit of repeatedly trying to install software that was already there. The process then fails because the installer detects that the software is there already and throws an error. The process then restarts because ConfigMgr still thinks it’s not there. This tended to happen with more complex Applications which use PKG installers to deploy rather than Applications which copy .app files. I do have a theory as to why this happens but I noticed this about two years later. When you repackage the application using CMAppUtil, it automatically generates the detection rules for you. With PKG installers, it puts a lot in there. I think that maybe it puts too many in there so it’s looking for a load of settings it can’t detect despite the software being present. Unfortunately I haven’t managed to test the theory but it makes sense to me.

Another gotcha that I’ve found with the repackager is that sometimes, it gets the installation command wrong, especially when you run it on a Mac with more than one operating system installed on it. It sometimes gets the path to install to wrong, necessitating a change in your installation command line.

DCM works nicely but finding the PLIST files or the setting that you want to change via Bash can be troublesome. That said, it’s no worse than trawling through the registry or finding an obscure PowerShell command to do what you want on a Windows machine.

Rather mysteriously, Microsoft didn’t include a remote control agent with this. Considering that a VNC daemon is baked into all versions of OS X, this would be trivial to implement,

The real bugbear that my team and I had with the Microsoft client is that Microsoft were very slow to implement support for new versions of OS X. As I’m sure you know, Apple have been working on a yearly release model for major versions of OS X since they released Lion. Microsoft didn’t support Mountain Lion for six full months after Apple had released it on the App store. The delay for Mavericks support wasn’t much better and Yosemite isn’t supported at all right now. It wouldn’t be so bad if it were a case of “Oh, it’s not supported but it’ll probably work”. Unless there is explicit support for the OS X version in the client, it won’t.

So in conclusion, the Microsoft client is better than nothing but it’s not that good either. When my friend and colleague Robert wrote a brief piece about this subject on his blog, he got a message from the lovely people at Parallels telling him about a plugin they were writing for SCCM which also happens manage Macs. Stay tuned for Part Two of this article.


Part two of this article is now up. If you want to see how this story ends, please click here

Leave a Reply

%d bloggers like this: