View RSS Feed

Norphy

Adventures in Macland... my experiences with ConfigMgr 2012 and Macs Part 1

Rating: 2 votes, 5.00 average.
by , 22nd March 2013 at 06:12 PM (31854 Views)
I've mentioned on the forums a few times that we're in the planning stages of implementing System Center Configuration Manager 2012 SP1. I'm now at the end of the planning stage and am moving towards implementation.

During the planning stages, we have been evaluating the Mac component of the product. My colleague @Roberto has written a little about it on his blog at It's Always My Problem. You should go read it. Go ahead, I'll wait.

Have you read it yet?

Really?

OK, I'll continue.

As Rob said in his blog, we have around 1500 Windows clients and 70-odd Macs. At the moment, they're essentially unmanaged. We can't easily push software, patches or policies to them. The Apple management components suck more than a super-Dyson and are essentially useless. At one point, we were looking at Dell KACE to manage our network which includes a very nice Mac management component but considering what it cost and that we get ConfigMgr virtually for free it didn't seem economical. So we went with ConfigMgr and waited for Microsoft to start supporting Macs.

Joy of joys, ConfigMgr 2012 SP1 introduced the Mac client. Over the last half term break, I decided to take a look at it and to attempt to get it working. This is what I found.

Microsoft are essentially treating non-Windows clients as mobile devices. This means that your ConfigMgr infrastructure has to support HTTPS across the board. Your management point needs a certificate, your DPs need a certificate, the ConfigMgr IIS site needs certificates and for OSD to use your newly certified MPs and DPs, your PXE points and task sequence media need certificates too.

To register the Macs with ConfigMgr, you need an MSI from Microsoft and install it on your PC. Inside that MSI there is a DMG which contains the client, the enrolment component and an application repackager. Copy that DMG to your Mac and mount it. You then have to install the client using the installer (ccmsetup) in an elevated (sudo) terminal session then enrol the mac using the enrolment component (CMEnrol), again using an elevated command prompt. Assuming you've configured your ConfigMgr correctly and allowed your Active Directory user to enrol mobile devices, it'll download a certificate and enrol your Mac in ConfigMgr. See this rather good blog post here for specifics

Once your Mac is enrolled, ConfigMgr will start inventorying it immediately. You'll then probably want to start doing something useful with it. At the moment, the Mac ConfigMgr client can deploy software, updates and settings.

Deploying a Mac app using ConfigMgr 2012 is much like deploying a Windows app. You have to use the new Application format to add it to ConfigMgr, not a old fashioned Package. You have to create the Application, create a deployment type, copy it to a DP and deploy the application to a collection.

The first complication that you'll come across is that you can't add standard DMG, APP or PKG to ConfigMgr. Instead you have repackage the app to Microsoft's own CMMAC format and use that to create the Application with. Doing this is simple enough, you need to use the repackaging application in the DMG file (called CMAppUtil) to do this. Once again, you need to use an elevated terminal session to do this although the reasons why elude me. See another rather good blog post here for more specific instructions.

To deploy settings is a little more complicated. The way that ConfigMgr does it is to modify PLIST files. The mechanism that it uses to deploy the settings is DCM. The procedure to do this is as follows:

Open the ConfigMgr client and go to Assets and Compliance, Overview, Compliance Settings, Configuration Items. Press Create Configuration Item.
blogs/norphy/attachments/17635-adventures-macland-my-experiences-configmgr-2012-macs-part-1-untitled.png
Give it a name and description if you wish and change the configuration type to Mac OS X. Assign it some categories to keep your sanity intact later on. Press Next.
blogs/norphy/attachments/17636-adventures-macland-my-experiences-configmgr-2012-macs-part-1-os-selection.png
If you're using more than one version of OS X, choose the version that you want it to apply to. At the moment, your choices are Snow Leopard and Lion
blogs/norphy/attachments/17638-adventures-macland-my-experiences-configmgr-2012-macs-part-1-create-setting.png
You now need to add a preference. Press the New button. Give it a name and description. Change the setting type to Mac OS X Preferences (A script is an option too)
In Application ID, type in the path and name of the PLIST file omitting the extension
In the data type box, put in whether the setting is a string, a number, true/false etc.
In the Key field, type in the name of the key. This is case sensitive. You'll need to research where the PLIST file and what the setting is yourself.
blogs/norphy/attachments/17637-adventures-macland-my-experiences-configmgr-2012-macs-part-1-edit-rule.png
Change to the Compliance Rules tab. Press the New button. Fill out the name and description. Put the value of what the setting needs to be in the value box. Make sure that the Remediate box is ticked and check the report box if you want to and press OK. Finish the wizard.

You then set a baseline (this is the same as doing it for a Windows machine; create it, choose which setting you want to deploy) and deploy it to a collection.

So how well does this all work? All things considered, it doesn't work badly at all. It's (mostly) functional at least. There are, however, some very rough edges. You can only deploy to machines, not to users. Installations have to be 'Required', optional installs won't work. There is no Mac equivalent to the Software Centre so you can't see what software needs to be installed. When the Mac agent detects a software deployment, it comes up with a countdown. The length of that countdown can't be changed and if the software requires a reboot, it can't be postponed. The most annoying thing that I've found with it is that when there are (say) five deployments for the thing to run and there's someone logged onto the machine, the machine will notify the user that there's an installation to be run, wait for an hour if there's no response, install the software, run the next advert, wait for another hour, install the software, wait for another hour etc, etc, etc. You get the idea. The example of five deployments above could take FIVE hours PLUS the amount of time required to install the software.

I have had problems with the deployments too. Sometimes the machine will kick off an installation and the progress bar will not move. The actual installation is taking place in the background and has frequently finished, there's just no indication of this. Eventually the installer times out and marks the deployment as failed despite actually succeeding. Then when the client calls back to the server and asks for a policy update, the server tells the client that it needs to install the software again and then it fails because its already there. This tends to happen most with larger PKG based installers, .APP files are generally OK.

Although deploying configuration items is relatively straight forward, it can be a bugger to find the appropriate PLIST file to change the setting that you want and if it's in a different location on different machines, it's nigh on impossible. It would be nice if Microsoft could work out a simpler method of doing this although quite how they'd do that eludes me. That all said, assuming that I've got the baseline right, a setting has never failed to deploy for me so it at least works well.

It's also a shame that Microsoft haven't included a remote control component with this either. Considering that a VNC daemon is baked into OS X, it would be trivial to implement.

The most glaring omission is that the client doesn't work with Mountain Lion. This isn't a "oh, it's not supported but it might work; try it at your own risk' situation, it just plain doesn't bloody work. The client installs but the enrolment fails. This is a real clanger. Mountain Lion was released in July. Even pretending for a second that Microsoft wouldn't have had access to pre-release code before then, System Center SP1 got released in December. Microsoft would have had four full months to add Mountain Lion support to the client before they released it. I'd truly love to know why they didn't.

So the Microsoft client is all well and good but considering we're not going to be using anything less than Mountain Lion next year it's useless to us. Microsoft have so far been completely silent on whether they're going to be supporting Mountain Lion in a forthcoming update so we're going to have to assume that they're not.

Enter Parallels, the very nice people who make the famous desktop virtualisation package for the Mac. An employee of theirs posted on @Roberto 's blog telling us that they have their own SCCM management agent for the Mac and offered to hook us up with an evaluation version. They told us it works with Mountain Lion. They told us it has a remote control component. They haven't told us how much it costs. We've taken them up on their offer and installed it. Is it any good? Find out in Part Two...

Comments

  1. JonWiswellII's Avatar
    Just thought you would like to know that the latest update (SP1 CU1) now supports Mountain Lion. It was released 4/1/2013.

    Download Microsoft System Center 2012 Service Pack 1 Configuration Manager - Clients for Additional Operating Systems from Official Microsoft Download Center

Trackbacks

Total Trackbacks 0
Trackback URL: