Mobile IT Guide to iPhone Deployment and Management with Apple's iOS 4
The iPhone and Apple's other iOS devices have long fallen short in meeting some of the needs and demands in the enterprise space. Reliance on iTunes, the inability to automatically push out policies and software updates over the air, limited security capabilities, and the requirement of Exchange ActiveSync for remote wipe of a lost or stolen device were all major concerns.
While Apple has steadily improved iOS as an enterprise citizen with each major update, iOS 4 is the first to really provide solid management capabilities.
Primarily by using a third-party management server. Although Apple created the framework for iOS device management that is built into iOS 4 through a new mobile device management (or MDM) service, the company worked with other firms that have a strong background in mobile device and/or computer management solutions to deliver a management console. The result is seven vendors providing solutions using Apple's new architecture. All of these can be used in conjunction with the existing capabilities provided by Exchange sync and Apple's own iPhone Configuration Utility.
Deployment and management challenges before iOS 4Before iOS 4, iOS device management was limited to a set of configuration profiles that had to be manually installed. These XML files could be installed by a technician while activating a user's iPhone directly from Apple's iPhone Configuration Utility (which is also used to create the profiles). It could also be done by a user or technician downloading the file(s) from a website or opening them as email attachments. A handful of additional configurations (largely dealing with device security policies) could be propagated to devices configured to access an organizations Exchange infrastructure.
Without a doubt, this process had some problems. For one thing, relying on users to install configuration profiles presented an issue as there was no way to force their installation other than having a technician install them (though with iOS 3, Apple made it possible to prevent their removal without a passcode). Likewise, there was no way to ensure users updated profiles after adjustments.
A similar problem affected application installation. While it was possible for companies to develop in-house applications, the process of distributing them was disjointed and required users to use iTunes.
It also required that appropriate provisioning files and the apps themselves to be distributed to every computer running iTunes. (Provisioning files are digitally signed files that identify the company's membership in Apple's enterprise developer program and thus provide the ability to install and use non-App Store apps.) And again, there was no way to ensure apps were installed or updated.
Another issue is that there was no central management console that administrators could use to get detailed information about the iPhones and other iOS devices that had been handed out to users beyond the very limited information available through Exchange. This created asset management issues in general as well as problems in tracking which configuration profiles, certificates, security measures, installed apps, and several phone-related settings (phone number, data roaming, carrier in use and settings, etc.) were on the devices.
Finally, even though remote wipe was supported using Exchange ActiveSync (either through Exchange itself or ActiveSync licensees --- including Google's GoogleSync feature for Apps Premier and Education customers), there were no options for simply resetting a device passcode if needed. Organizations without some form of ActiveSync environment lost even the remote wipe capability unless a user was signed up with Apple's Mobile Me.
Needless to say, all these factors were major concerns for many organizations, particularly larger environments where hundreds or thousands of devices might need to be rolled out, occasionally updated, and ideally managed in a secure and consistent manner.
Some third-party developers attempted to tackle these problems before Apple unveiled iOS 4. But the problem was that in order to provide all these features, solutions would need greater access to key iOS components that Apple has never made available to third-party developers.
Pushing out application updates or new versions of configuration profiles without user intervention, for example, would require the ability for the tasks to run or be started in the background (something Apple had expressly forbidden for any other developers until iOS 4 -- and even now the company puts tight limits on what developers can do in the background).
Understanding Apple's Mobile Device Management serviceIn tackling these challenges in iOS 4, Apple came up with a very interesting and workable solution. It created a service that would continuously run in the background on an iOS 4 device (the aforementioned MDM service). Apple leveraged its push notification service in MDM, giving the server the ability to receive notifications from a third-party server, though unlike notifications in other iOS components and apps, those notifications inform the iPhone of queries or updates to applications or configurations.
MDM allows a management server to query a managed device for 22 different conditions as well as issue commands for remote lock or wipe, to temporarily remove a passcode in case a user has forgotten it (if a passcode is required, the user will need to set a new passcode), and to update configuration and application provisioning profiles over the air without user interaction.
The query features that MDM offers include the following: unique device identifier, device name, iOS version, device model name and hardware version, serial number, overall and available storage capacity, IMEI number, the modem firmware version, SIM card ICCID, and MAC addresses for integrated Wi-Fi and Bluetooth.
It also includes carrier currently being used, the carrier specified by the current installed SIM card, the version of the carrier settings (APN) data, assigned phone number, whether or not data roaming is currently allowed, list of configuration profiles installed, list installed security certificates and expiry dates, list of enforced restrictions, hardware encryption capability, whether an unlock passcode is set, installed applications (with App identifier, name, version, and size), and a list of any application provisioning profiles with expiration dates.
Apple also simplified the initial configuration of devices. When a management server is used, an organization can provide a secure Web portal. When an iPhone user visits the portal, they are asked to authenticate with a user account (typically, this will be an account associated with a user account in an Active Directory or other LDAP directory).
Once authenticated, the iPhone will generate a certificate enrollment request using SCEP (Simple Certificate Enrollment Process), which will generate an identity certificate for the device. Once the device-specific identity certificate is used to establish a secure and authenticated connection, the user will see a configuration dialog that describes the privileges and restrictions to be assigned to the device. When the user agrees to the dialog, configuration and provisioning profiles will be automatically installed and the device will be available for queries and management by the management server.
While Apple has created the basis for iOS device management, the company relied on third-parties to provide the actual management server and environment. Although this adds a cost to organizations opting for a management solution, it actually provides some major advantages. It allows organizations to choose between different products with different requirements, interfaces, and features to meet their needs.
More importantly, it means that third-parties can leverage Apple's MDM service alongside similar features for other platforms, making it possible for an organization with a heterogeneous mix of mobile devices to use a single management console.
Putting everything together with the iPhone Configuration UtilityOne thing that's important to understand is that even though there are a number of different management options for the MDM service, much of the actual configuration options are still based around Apple's existing approach of configuration profiles (in addition to any Exchange policies). Therefore, Apple's iPhone Configuration Utility remains a key part of the ultimate management equation when crafting or updating profiles.
Once profiles are created, they can then be deployed using the MDM service and a third- party management server. The pre-iOS 4 options of deploying the profiles using a Web server to host the profiles, emailing them to a user, or connecting iPhones to directly to a Mac running the desktop application version of the iPhone Configuration Utility also remain in iOS 4.
Although a management server will be the better choice for deploying the profiles and any custom in-house apps over the air, using the iPhone Configuration Utility on Mac will offer a way to easily test profiles and in-house apps either on a single device managed by IT or a larger pilot group.
The iPhone configuration offers the ability to create a single profile with all management choices defined or to create a series of profiles with only one or two defined choices. The advantage to this approach is that it allows you to create ready-made profiles for any possible management options which can then be applied as needed based on the type of device or the job functions of the user. This works much in the same way the group policies can be combined in an Active Directory environment.
TAGS:iPhone, Apple, iOS 4, mobile management, mobile deployment