In Part 1 of this series, I looked at the mechanisms available to IT staffers to activate, deploy and configure iPhones in business environments. But the biggest new business-oriented feature available on the iPhone, thanks to the iPhone 2.x firmware (included with the iPhone 3G and available for free to users of first-generation iPhones or for $9.95 for iPod Touch users), is the addition of ActiveSync for accessing Microsoft Exchange.
ActiveSync allows for automatic over-the-air push updates of new e-mails, calendar events and personal contacts to the iPhone (functionality that was already available to Windows Mobile, Palm and Symbian devices). ActiveSync also lets iPhone owners search a company's Global Address List (GAL) using the included Contacts application, and allows administrators to enforce some security policies on the iPhone, including the ability to remotely wipe the contents of a phone that is lost or stolen.
But getting iPhones to connect and sync with Exchange servers can be tricky. In this story, I'll provide tips for integrating and managing iPhones in an Exchange environment. (Part 3 of this series, which will be posted in the next month, will cover the options for developing and deploying in-house iPhone applications.)
How ActiveSync works
Unlike push services for BlackBerry devices, which rely on an intermediate server (RIM's BlackBerry Enterprise Server) that receives update notifications from an e-mail server and then provides push notification to remote devices, ActiveSync maintains a connection directly to an Exchange server. For those new to working with over-the-air syncing via direct push in Exchange, the following is a brief introduction. Understanding the basic concept can help in both planning and troubleshooting iPhone access to Exchange.
Direct push between an Exchange server and remote client devices relies on a persistent connection between the server and the device. When the device is powered on or configured, it sends an HTTP/HTTPS request (known as a ping request) to the server to establish the connection.
The ping request identifies the device and the user as well as the Exchange folders that the device will monitor. (The iPhone supports monitoring of Inbox, Calendar and Contacts, but unlike other devices that implement ActiveSync, it does not support monitoring of Tasks at this time.) Additionally, the request identifies a time limit for the connection -- also known as a heartbeat interval.
Upon receipt of the client request, the Exchange server monitors the specified folders until changes occur or until the heartbeat interval is reached. If the server detects changes to a folder being monitored (e.g., incoming e-mail or a new calendar item), it responds to the ping request by identifying the folder(s) that has been updated, which causes the client to issue a sync request for those folders (and thus update appropriately and alert the user if the update contains new e-mail).
If the server doesn't detect changes within the heartbeat interval, it responds to the ping request with an HTTP 200 OK message, which causes the client to generate a new ping request. A new ping request is also generated following a successful sync.
The heartbeat interval is dynamically determined by the client device, such as an iPhone or Windows Mobile phone. ActiveSync clients maintain a log of interactions with the server and choose intervals that allow for persistent connections with the longest possible network timeout (the time at which the mobile carrier and/or any network devices between the client and the server will drop the connection).
By using the longest possible heartbeat interval, the client can maintain persistent open connections (those which the client has initiated but the server has not yet responded to) between the client and server without requiring active use of the connection and thus conserving battery life on the device.
Understanding Exchange requirements
As anyone who has administered Exchange knows, there are a number of variables and options in determining the best configuration for an Exchange environment. Factors such as firewall and proxy server configurations, internal and external DNS, the optional use of front-end and back-end servers, the Active Directory forest and domain topologies, and the versions of Exchange and Windows Server used all impact the ultimate design of an Exchange environment.
Other major factors include the use of SSL, whether self-signed certificates or a certificate authority are used (and how they're implemented), which authentication options are used, and which virtual directories on the Exchange server are secured.
In many cases, the variations among unique Exchange environments don't have a huge impact on clients. However, the iPhone is not a particularly forgiving Exchange client, it seems. There are numerous threads on Apple's discussion forums about issues preventing successful communication or sync between the iPhone and Exchange servers. In some cases, administrators report problems trying to integrate iPhones even in environments that already include other ActiveSync mobile devices such as Windows Mobile phones.
Although some admins have pointed fingers at Apple, saying that the company has created a buggy implementation of ActiveSync, the problems in many cases appear to relate to overall network and Exchange environment configuration, or environments that don't meet the specific requirements that Apple has listed for the iPhone. Apple also seems to have designed its ActiveSync implementation to require rather strict adherence to Microsoft's guidelines for mobile device support. (Links to guidelines, documentation, and other resources from Microsoft and Apple are included at the end of this article.)
Unfortunately, Apple's documentation contains very limited details about those guidelines, which means a very solid understanding of and experience with Exchange and its support for mobile devices is a must. Before trying to add iPhones to your network, do your homework and ensure that your Exchange environment meets Apple's stated requirements as well as Microsoft's recommendations for supporting mobile devices via ActiveSync, particularly if you have not worked with mobile device support before. I've included some valuable resources, along with some advice to help avoid commonly reported problems, at the end of this article.
It is also important to ensure that your environment is running either Exchange 2003 SP2 or Exchange 2007 SP1 or newer. Apple has specifically listed these as requirements, and the iPhone will not function properly, if at all, with earlier versions.
If you are working with Exchange 2003, you will need to download and install the Exchange ActiveSync Mobile Administration Web Tool. The Mobile Administration Web Tool can be used with Exchange 2007 as well, though it's not required; Exchange 2007 has a built-in Exchange Management Console. You might opt to use the Mobile Administration Web Tool if you want to give nonadministrators (such as helpdesk staff) remote wipe or other administration capabilities without giving them full access to the Exchange Management Console.
Managing users' mobile access
From an administrator's perspective, managing access and policies for iPhone users is largely the same as managing access for any other mobile device. Exchange direct push and ActiveSync are enabled by default for all users, meaning that unless you have explicitly changed things, all iPhone users with existing accounts should be able to access their accounts without requiring per-user configuration. (If you rely on iPhone configuration profiles, you should also be able to deploy iPhones to users so that they only need to enter their Exchange username and password -- see Part 1 of this series for details.)
If you are running Exchange 2007, the iPhone also supports Exchange Autodiscovery based on a user's e-mail address.
As with other devices, you can adjust the organizationwide policies or user-specific policies to grant or deny mobile device access. Once a user has configured an iPhone with his Exchange account information and connected to Exchange, you will be able to use either the Exchange ActiveSync Mobile Administration Web Tool or the Exchange Management Console to view additional information about the device, including the last time the iPhone was synced with Exchange, the last time Exchange policies were updated on the iPhone, and the time of the last ping request. You can also use these tools to initiate a remote wipe of a lost or stolen device and view the status of a remote wipe request.
Configuring passcode policies
The only Exchange policies (other than allowing users to access their accounts from mobile devices) that you can enable for the iPhone via Exchange are passcode policies. You can require users to create a passcode that must be entered to unlock the iPhone, specify a minimum passcode length, require an alphanumeric passcode, and specify a period of inactivity after which the iPhone locks automatically.
Apple's iPhone configuration profiles include the same options plus some stricter ones, such as the number off passcode attempts before the iPhone must be resynced with iTunes to re-establish access. Passcode policies configured via Exchange are automatically pushed to the device over the air and enforced as long as the iPhone is associated with an Exchange account. (IPhone configuration profiles, on the other hand, must be e-mailed or hosted on a Web server, and users must choose to install them and can delete them at any time.) If both a configuration profile and Exchange passcode policy are in place on an iPhone, the strictest options will be enforced.
The ability to remotely wipe confidential data from a smart phone is one of the most important features in a business device. In the event that an iPhone associated with an Exchange account is lost or stolen, administrators can remotely wipe it from within the Exchange ActiveSync Mobile Administration Web Tool or the Exchange Management Console. If Outlook Web Access is enabled, as it is in most environments, users can also initiate a remote wipe of an iPhone using the mobile device management features available in Outlook Web Access. When a remote wipe command is issued, the iPhone will revert to an Apple-logo screen and remove all user data and settings. This includes user account information (both Exchange accounts and other e-mail accounts) and associated e-mails, contacts and calendar items. It also includes all media (music, photos and videos), applications and Web browser bookmarks.
Because a remote wipe of an entire iPhone may take considerable time and battery power, an iPhone may power down before completely erasing if its battery becomes depleted. If this happens, the iPhone will continue erasing data when (or if) it is connected to a power supply. Once an iPhone has been wiped, it will need to be activated in iTunes again before use. To ensure successful future use, you may need to remove any residual association between the phone and a user in Exchange if the phone is recovered and reactivated within your network.
Connecting the iPhone to Exchange
Associating an iPhone with an Exchange account is designed to be a relatively simple process. As indicated by Apple's instructions, users simply need to create a new e-mail account on the iPhone, select Exchange as the account type and enter their account information (e-mail address, server address, username and password, and an optional account description). You can also automatically configure either all or just the server-specific components of these settings using configuration profiles.
Apple does not take a firm stand on whether or not the username should be entered in domain\username format or with only the username (omitting the domain), but in most environments domain\username is required. Typically, this depends on the default domain option for an Exchange environment (as well as whether or not the environment exists in a multidomain network), but in some situations, the full domain name may be needed even if the default doesn't use it. It's wise to test with an iPhone before developing instructions for users or support staff.
The iPhone prefers connections that encrypt all communication using SSL. If it cannot establish an SSL connection to the server (or in some environments to a Windows ISA Server), it is designed to attempt to connect without using SSL. Ideally, you should configure an environment that requires SSL.
If you are using SSL, you will also need to ensure that any certificates used to sign communications are installed on the iPhone. The iPhone ships with root certificates for a number of common certificate authorities. If you use certificates signed by these authorities or certificates that build an effective chain of trust, you will not likely need to install additional certificates on the iPhone. If you choose to use self-signed certificates or are relying on certificates signed by a certificate authority other than one available via the installed root certificates, you can use a configuration profile to install the certificates on each iPhone that will access your environment.