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.
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.