Since the early days of iOS, Apple has always made it relatively easy to configure iOS devices to meet the needs of managed deployments in schools, businesses, and other mass-deployment situations. Heck, even the good old iPod Classic had a “museum mode” that could lock down the device to show specific notes on the screen while audio played.
Over the past few years, iOS deployment has become more ‘professionalised’ – which might be a euphemism for ‘complicated’. Honestly, all mass computer deployment is deeply complex when you get down to it. The best systems automate almost everything. iOS deployment, as it has developed in recent years, has tended to keep most of the moving parts close to the surface. These parts have been difficult or impossible to automate and easy to overlook or forget. That would be fine if most of these parts were optional, but they’re not.
The main parts of an iOS deployment are a Mobile Device Management server for configuring and tracking your devices, the Volume Purchase Program for bulk-buying apps from the App Store, and the user of the device having an Apple ID.
When Apple launched the Volume Purchase Program, they introduced the ability for administrators to assign apps to users’ Apple IDs, rather than to devices. This also introduced the requirement that every device have a single, identifiable user who has a working Apple ID.
This was quite a good idea in the early days of iOS in the enterprise. These were days when users were bringing their own iOS devices to work and businesses had to make apps available to them. It wasn’t such a good idea for more centrally-managed deployments where the use of the device was perhaps more task-oriented than user-oriented. Think: supermarket employee who picks up one of twenty available iPads to do stock control. It also wasn’t great for schools, where many users didn’t have Apple IDs and there were no tools for bulk creation of said accounts.
I would love to tell you that iOS 9 fixes all of these problems. Unfortunately, I can’t tell you that. What iOS 9 does is fix one problem while introducing another.
With iOS 9, Apple is removing the requirement to have an Apple ID active on each device, while keeping most of the benefits of the Volume Purchase Program such as over-the-air app installation and recall. However, this is very much one step forward and one step back.
When you have every device in the hands of a user with an Apple ID, however hard it was to get to that point, at least everyone has a working iCloud account to which the device can be backed up in case of disasters.
With the new Apple ID-free “device assignment” approach, there is no functioning Apple ID or iCloud account on the device. This means there is no possibility of over-the-air backup for the device. At this point, it’s unclear what sysadmins are supposed to do to back up device-assigned iPads. Apple’s brief advice at WWDC was that app developers should “store their data in the cloud”. Without a functioning Apple ID to access iCloud storage, the solution very much looks like “have a separate account for every app”. For schools, this is a nightmare scenario far, far worse than the pain of making Apple IDs for each student.
I don’t know. Maybe we just do without backups?
There are two other areas that are gaining some important improvements in iOS 9, and both relate to enhanced capabilities for Mobile Device Management (MDM) servers.
MDM servers do two things: they send commands to the device to either perform actions or configure itself in some way. iOS 9 brings enhancements to both.
In iOS 9 there are several new commands that an MDM server can send to an iOS device. Perhaps the most important one being a command to “update your operating system”. This is particularly useful in situations where having iOS devices brought back to base in order to update them is particularly difficult. There is also a command that is effectively “download the update now and install it later”.
This will be very useful for schools who have an OS X Caching Server set up. Admins could send the command to download the OS on the school network where it will be fast but request that the actual installation happen later to avoid taking the device out of use for a portion of the school day.
There are also new configuration options in iOS 9 to control such things as the device wallpaper, passcode modification and the device name. These will all be welcome in schools. The device name is what identifies a specific iPad when it’s participating in AirDrop. One fun game in our school has been to replace your device name with a range of…ahem…humorous emoji.
You might think it is strange to restrict the opportunity to change device passcodes but it’s quite common in schools – especially primary schools – for teachers to need access to pupils’ devices while they’re not there. If the student has changed their passcode from the assigned one, it requires an MDM admin to send a passcode reset command to the device (and hope the device is online) or wait for the student to return.
There are a range of other configuration enhancements that will be of more interest to enterprise. In particular there are now many more options for VPN configuration and control of pairing with Apple Watch.
Finally, Apple Configurator is receiving a massive overhaul. Apple Configurator is Apple’s Mac-based mass configuration tool for iOS devices that replaced the original iPhone Configuration Utility. Life with Apple Configurator 1.0 has been – how shall I put it – challenging at times.
With Apple Configurator 2.0, the monolithic nature of the app is no more. It’s modular and allows you to store “blueprints” – specific configurations that you can replay onto many devices. It should be a good upgrade for those who need it, but the Device Enrollment Program is increasingly replacing the need for Configurator in many centrally managed deployments where named individuals have and use the devices. Configurator will remain useful for shared deployments and generic kiosk-type iOS scenarios.
Overall, iOS 9 represents a step forward in iOS system administration – in certain deployment scenarios that were previously particularly difficult.