I spent most of today enrolling devices in our new Profile Manager setup. As I have written before, Profile Manager is Lion's MDM server feature. How well does it work in practice?
The actual set-up of the server component was quite painless. You'll need certificates in place and a (free) certificate for the Apple Push Notification Service. The wonderful folks at AFP548.com have a video on the setup which I found useful.
Profile Manager is conceived primarily as a "self-service" portal for users rather than an administrator's dashboard. This leads to an arguable weakness of Profile Manager in the school setting, which is that enrolment has to be initiated on the device itself.
Yes, that means touching every single device. In principle, you might be able to get the older kids to do this themselves because Profile Manager lets you create placeholder records for devices that you expect to enrol in the future.
A placeholder consists of a temporary name for the record and a hardware identifier. I used the device serial number but UDID, IMEI and MEID are also acceptable. You can apparently bulk-upload placeholders, but I found this functionality to be broken in the 10.7.0 release build (11A511). I created a placeholder for each iPad by hand.
Having created placeholders, I then began the task of enrolling the devices. This is quite spectacularly tedious when you're enrolling them all yourself. The steps are as follows:
- On the device, log into Profile Manager as the device owner (i.e. the pupil whose device you're enrolling).
- Install the Trust Profile. This allows the verification of profiles signed with my self-signed certificate to proceed.
- Install the device enrolment profile.
I ran into a snag here: I had not port-mapped TCP port 1640 ('cert-responder') on my internet router. Everything worked perfectly until the enrolment stage when I got a "server could not be contacted" error. I only figured this out by portscanning my server and taking a guess at what looked likely to be involved in certificate enrolment - couldn't find it in the documentation anywhere!
Once the enrolment is complete, Profile Manager harvests a ton of useful information about the client device. All the device identifiers, the installed OS and apps, the restrictions that are in place and the time the device last checked in with the server.
Once enrolled, the user can log into the Profile Manager at any time and issue commands to remotely lock or wipe the device, as well as clearing the device passcode.
Snag 1: Control over Enrolment
There are several shortcomings for schools in the current version of Profile Manager. It's a 1.0 product - a good start - but I'm not going to pretend that everything's great.
Firstly, the fact that enrolment is always under the control of the user is problematic. I understand, in a corporation comprised of adults working together towards a common goal, that the user should generally be in control. School IT is a slightly more - shall we say - challenging environment.
At any time, a user can remove the MDM server's enrolment profile from their device. This removes all the profiles that were issued by that MDM server and removes the device from further administrator control.
Basically, any content restrictions you put in place can be removed at any time by the pupil. Not only that, but those restrictions can also be reapplied at any time. Imagine that a pupil could remove the restrictions at home and then reapply them during school hours. As it currently stands, it would be very hard for a sysadmin to know whether that was happening or not.
You would be able to know if a device had permanently disappeared from enrolment as Profile Manager's periodic requests for updated information about the device would fail and that shows in the control panel. You don't want to have to monitor this, though.
It's hard to overstate how much of a problem for schools this is. It's close to being a show-stopper for using Profile Manager as the basis of your device management system.
Snag 2: Groups
Like Workgroup Manager before it, Profile Manager lets you apply controls to a user, a device, a group of users or a group of devices.
I don't know if this is a bug or intended behaviour but, while Profile Server picks up the users and groups created in Open Directory, it does not populate the membership of those groups. Feels like a bug to me.
Snag 3: Bulk Creation
When I deployed the iPads last year, I used iPhone Configuration Utility. I divided the profiles into three: a base profile, a passcode profile (P1 kids don't have passcodes) and an individual profile that provided the user's email settings. Typing in Gmail settings for 115 users is pretty tedious, so I wrote an AppleScript to automate it. Takes about 3 seconds to run, when you feed it the right information.
Unfortunately, Profile Manager appears to have no way to do any kind of bulk creation of profiles. You can't even import a configuration profile created in iPhone Configuration Utility. This is probably not a problem when you're only adding the odd user at a time but it does make migration or initial adoption quite daunting.
How I'm Using Profile Manager
I'm rolling out Profile Manager slowly. Partly for caution but partly because of the legacy of a mistake I made last year. When I installed configuration profiles using iPhone Configuration Utility, I set most of them to "Never" be removable - the other options being "Always" or "With Authorization". Turns out "Never" really means never. I think you have to restore the device to get rid of them.
With that in mind, the pupils who have existing profile setups are keeping them. I've enrolled their devices in Profile Manager but I haven't used it for anything yet.
The new Primary 1 kids are getting a fully Profile Manager-controlled experience. This is possible because we don't disclose their password to them so I can enrol their devices under their accounts and they won't be able to remove them. I'm trusting that they won't find their way into Settings > General > Profiles and figure out how to remove the enrolment.
For kids joining the upper levels of the school this year, I'm enrolling their devices and doing a combination of things. The 'security'-related profile controls are deployed through iPhone Configuration Utility and require my authorisation to remove. That means WiFi, passcode policy and parental controls will always be in place. I'm then using Profile Manager to deploy these pupils' email setup.
Having discussed the issue of MDM policy with various friends and colleagues, the story I'm hearing is that you should use a "carrot and stick" approach to MDM: only provide something that the user wants or needs through MDM as an incentive for them to keep their devices enrolled. That something could be VPN access, a connection to LDAP or CalDAV or something that, without it, the user won't be able to get the job done. That's fine as far as it goes but, with the user having the ability to enroll and un-enroll at will, there's no stick. There's only a carrot.
Am I glad that Profile Manager exists? Absolutely. It's the only way our school is going to afford an MDM server and it's very easy to set up.
Is it ready to be the backbone of your configuration strategy? Absolutely not.
Does it require a radical overhaul to work for schools? No. The problem is philosophical rather than technical. With two changes - the ability to require an administrator password to un-enroll a device and to import profiles from iPCU - I would be almost completely happy with Profile Manager.
There's no point whining into the empty void of the internet. For my friends reading from Cupertino, here are the relevant bugs:
- "A setting to prevent un-enrolling a device from MDM" - rdar://9806432 (duped to rdar://9200177)
- "Profile Manager groups not populated from OD groups" - rdar://9950889
- "Add bulk-creation feature to Profile Manager" - rdar://9950871
- "Profile Manager "Import Placeholders" function broken" - rdar://9950870
- "[ER] Allow Profile Manager to capture device battery status" - rdar://9952911
- "[ER] Smart lists in Profile Manager" - rdar://9952916
- "[ER] Profile Manager-warn when creating a placeholder with existing Serial" - rdar://9953185