Apple provides some automated configuration of iPhones for the workplace through the use of configuration files, or profiles, that can be used to establish a number of typical configuration options. These could include requiring a passcode to access the phone, configuration of Exchange or IMAP/POP e-mail accounts, VPN configuration (for PPTP, L2TP and IPSec/Cisco VPNs), some configuration for access to Wi-Fi networks and the installation of certificates on the phone.
How the iPhone connects to a carrier's network using Access Point Name settings is also supported, although these settings should ideally be coordinated with your carrier if they're needed.
IPhone profiles are XML property list files that can be generated with either a Mac OS X application -- the iPhone Configuration Utility -- or a Web-based tool that can be installed on either a Mac or a Windows PC (examples of both are shown below).
While either tool can generate configuration files, the application interface also allows you to build a library of iPhones within your network -- complete with installed application and user information. And the Console viewer offers easy access to log files on the iPhone when it is connected to a computer, which is useful for troubleshooting problems and testing in-house applications. The application environment also allows for management and deployment of in-house applications.
There are two overall disappointments to Apple's implementation of configuration files for enterprise environments. First, the files are not pushed out over the air and automatically applied to iPhone clients. They must be sent to a client by e-mail or hosted on a Web server and loaded using the mobile Safari browser on the iPhone. This makes distribution a bit more cumbersome, both for the initial deployment and for later updates.
Second, users must choose to install profiles or updates (as shown below). You cannot enforce an updated profile. When an updated profile is received via e-mail or accessed via a Web server, users can choose whether to install the profile. Users can also delete profiles using the iPhone's Settings application, meaning there's no guarantee that profiles will be kept up to date -- or used at all.
Note: If you are hosting configuration files on a Web server other than Mac OS X Server 10.5.3 or higher, you will need to add support for the .mobileconfig extension MIME type of application/x-apple-aspen-config.
Similarly, with the exception of a passcode requirement, profiles don't do much to restrict iPhone features. There is, for example, no way to limit the installed applications users can access, and no way to restrict them to Wi-Fi networks specified in a profile (such as ones that are known to be secure). Profiles exist only to simplify the iPhone setup and enforce policies.
At least profiles can be digitally signed, thus ensuring that a user who gets a new or updated profile gets one that's legitimately issued by a company's IT staff. Profiles can be signed using certificates issued by a public certificate authority (such as VeriSign) or with a self-signed certificate, provided that you deploy a copy of the certificate to iPhones (which can be done using a profile).
Another note: Passcode policies can be enforced over the air using Exchange ActiveSync, which I'll cover in part 2 of this series. When both profiles and Exchange policies define passcode requirements, the strictest combination of the two is enforced by the iPhone.
One particularly useful feature is that a single iPhone can maintain multiple profiles. This allows you to configure and deploy different profiles for different functions. All iPhones will likely need the same series of certificates installed, for example, and that can be done with one profile. Only a specific group of users, however, may need VPN access configured, which can be done as a separate profile. This also allows you a bit more ease and flexibility in updating configurations, since you don't need to make changes to every existing profile and option.