Editor’s Note: This story is excerpted from Computerworld. For more Mac coverage, visit Computerworld’s Macintosh Knowledge Center. Part one of this three-part series also appeared at Macworld.
In part one 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.
More on ActiveSync and the iPhone
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 three of this series 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 domainusername format or with only the username (omitting the domain), but in most environments domainusername 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.
Once an iPhone is associated with an Exchange account, users will be prompted to enter a passcode that conforms to any policies established in Exchange. They will also have the option of choosing which types of data to sync—Mail (Inbox), Calendar and/or Contacts. Once the iPhone has established a connection to Exchange, it should initiate a first sync (for performance issues, you may wish to have users establish their initial connection using Wi-Fi within your network). By default, the iPhone will sync only three days’ worth of Mail items, though this can be changed using the Settings application on each iPhone.
Note: An iPhone can be associated with and sync to only one Exchange account.
iPhone ActiveSync feature limitations
Although Apple has implemented a number of Exchange functions on the iPhone, it has not included all the features found in Outlook or on Windows Mobile devices. As mentioned earlier, the iPhone will sync a user’s Inbox, calendar items, and personal contacts using direct push and ActiveSync. It will not sync tasks created in Outlook, provide management of personal or public folders available in Outlook, support the opening of links to Microsoft SharePoint server sites, let users set out-of-office autoreplies, create meeting invitations using the Calendar application, or support flagging of messages (such as for later follow-up).
It is also worth noting that at this point, direct push notification and sync occur for new e-mails only if they are delivered to a user’s in-box. If users create filtering rules in Outlook that filter incoming mail into other mailboxes, the iPhone will not receive push notification of their delivery (though opening the mailbox in the iPhone’s Mail application will cause it to be synced manually) because only the in-box is monitored. As a result, users should either remove such rules or configure them to be run manually when they are at their computer.
As I mentioned earlier, the iPhone can be a rather picky device when it comes to getting it working with Exchange. The following is a list of common issues that prevent the iPhone from being able to reliably access or sync Exchange accounts. This isn’t a complete list of all known problems, but being aware of the most likely problems and their causes should help ensure a smoother iPhone implementation.
Certificates: One potential cause for problems with iPhone/Exchange access is certificate management and SSL. As noted earlier, the iPhone prefers SSL and will attempt to connect to Exchange using SSL during setup as well as when sending ping requests. Microsoft suggests using SSL for all mobile devices with Exchange (which relies largely on HTTP/HTTPs as a communications protocol) because it ensures that casual sniffing of packets will not easily identify ping or sync requests for Exchange.
If you are using SSL, however, it is important that the certificate being used to sign communications is either installed on the iPhone or is signed by a certificate authority trusted by the iPhone. If a certificate cannot be verified, users will receive alerts to that affect when attempting to configure access to an Exchange account and when accessing the account. The inability to verify a certificate may also lead to additional connection and sync problems. Although disabling the use of SSL might appear to be one solution, it raises serious security concerns, particularly if users are connecting via unsecured Wi-Fi networks (which there is no feasible way to prevent).
Internal and external DNS: One of the challenges that the iPhone presents is that it can connect to network resources using a variety of mechanisms: a carrier’s mobile network, a Wi-Fi network within your organization, or external Wi-Fi hot spots or home networks. Depending on how DNS and namespaces are implemented in your network, DNS lookups for the name of your Exchange server(s) may return different IP addresses when iPhone users are connected to an internal Wi-Fi network and when they attempt to connect from external Wi-Fi networks or via a carrier’s mobile network. (This doesn’t typically present a problem for mobile devices that rely solely on a carrier’s network, since they will rely on external DNS servers for lookups and thus always receive IP addresses.)
This can result in situations where users can interact with Exchange while at work but not at other times. To avoid this problem, you can either use a VPN configuration on the iPhone or ensure that the DNS records accessed from the iPhone routinely receive an external IP address for your Exchange server(s).This may require review of your Exchange configuration as well as your overall network planning and perimeter devices (firewalls, ISA servers, etc.).
Needed ports and front-end/back-end server configuration: Exchange communication requires configuration of appropriate ports for computers and devices that are outside your network. You should ensure that you have configured ports to allow traffic and to forward that traffic to the appropriate server(s). As an additional layer of security when configuring mobile device access, Microsoft recommends using Windows ISA Server and Exchange front-end and back-end servers (in which devices outside your network communicate only with the front-end server and not directly with the server that processes internal transactions). Refer to the Microsoft documentation listed at the end of this article for additional details on all of these configuration variables.
You will also need to verify that all network devices, such as routers, firewalls and other security appliances, that will process communication between your Exchange servers and iPhones outside your network are configured with timeout limitations that will not interfere with the heartbeat interval used for direct push. Using too-short timeouts for network communication devices could result in overall notification and sync failures for mobile devices, including the iPhone.
Forms-based authentication, SSL and single-server environments: Environments where Exchange is configured using a single server (as opposed to a front-end/back-end server configuration) can present their own challenges. As documented by Microsoft (along with details of the cause and potential resolutions), such environments will not properly support mobile device access if SSL is used to secure the related virtual directories used by Exchange and forms-based authentication is enabled.
Similarly, forms-based authentication can require additional configuration in any Exchange environment in relation to virtual directories, SSL and the use of a default domain. These issues can be resolved by implementing a front-end/back-end environment or by creating a secondary virtual directory for Exchange and adjusting the server’s Windows registry to point to it.
Virtual directory permissions: Exchange relies on virtual directories in IIS for several pieces of functionality, including the implementation of Outlook Web Access, Outlook Mobile Access (a variation of OWA intended for mobile browsers) and ActiveSync with mobile devices. Altering the permissions or security properties of these virtual directories can result in problems or failures for accessing Exchange services from the iPhone.
Case sensitivity in e-mail addresses: Typically, usernames in e-mail addresses are not case sensitive, but they are case sensitive when configuring an Exchange account on the iPhone. As a result, if the e-mail address entered as part of an Exchange account has case differences from the way the address is entered in the Exchange Global Address List, users will receive calendar events as if they were event invitations to which they need to respond. This can be avoided by ensuring that the GAL entry and the e-mail address entered on the iPhone match in their use of upper/lowercase lettering.
The iPhone 2.1 update and Exchange
Apple’s 2.1 firmware update for the iPhone—released on Sept. 12—included a wide range of bug fixes, security updates, and improvements for overall performance and reliability with 3G networks. It has also generated its own series of ActiveSync issues for some users. The problems seem to occur only on iPhones running the earlier iPhone 2.0.x firmware that were configured and able to successfully communicate with Exchange before the update.
More on iPhone 2.1
Following the update, some users reported being unable to access items on the Exchange server with a “connection to the server failed” error message being displayed when trying to access Exchange items stored on the server. Over-the-air syncing also may be affected. Detailed reports of problems can be found in a thread on Apple’s discussion forums.
While the problems appear to affect a number of users, it’s not universal and some of the posters to the forum reported no issues after the update. Although the exact cause isn’t clear from the information available so far, there do seem to be a couple of consistent points. First, problems seem to occur when an iPhone with an existing Exchange configuration is updated. Restoring rather than upgrading the firmware may be one way to avoid the problem.
Even some of those experiencing a problem have found that performing a restore operation and activating the restored phone as a new iPhone in iTunes—rather than restoring settings from a backup of the iPhone made prior to the restore—resolves problems completely. Note that this will require configuring the Exchange account on the iPhone again. Some users have also suggested that a full restore may not always be required and that simply resetting the iPhone can be effective. To reset the iPhone, power it off by holding the sleep button down until the Slide to Power Off display appears, then restart it.
Another tip noted by several users is that adjusting the use of the domain in a username for an Exchange account (adding it if it wasn’t there originally or removing it if was) may help resolve the situation. Why the update would have changed the iPhone’s behavior in this area compared to previous firmware versions isn’t clear, but multiple users have reported this as a workable solution.
The following are additional resources that you should review if you are planning to implement the iPhone in an Exchange environment or if you are trying to resolve problems with iPhone access to Exchange. Many of these resources are mobile device guidelines from Microsoft; also included are resources from Apple and relevant discussion threads from Apple’s iPhone in the Enterprise forums.
As I noted earlier, a full understanding of and experience with Exchange will go a long way toward making the integration of the iPhone as seamless as possible, and I strongly suggest reviewing all these resources before beginning such an integration. Smaller organizations or less-experienced Exchange administrators may also want to consider hiring a consultant who specializes in Exchange to ensure optimal configuration.
[Ryan Faas is a frequent Computerworld contributor specializing in Mac and multiplatform network issues.]