Making Exchange ActiveSync Work

More and more users are realizing the benefits of mobile email access, as evidenced by the popularity of wireless messaging devices such as Research In Motion (RIM) BlackBerry handhelds, Windows Mobile smart phones, and Pocket PCs. Though the number of these devices that are deployed remains relatively small, Microsoft clearly expects the number to rise significantly: In 2002, the company decided to integrate the functionality of its Mobile Information Server (MIS) product—code-named Airstream—into Exchange Server 2003. When it was released, Exchange 2003 almost instantly became the most widely deployed mobile messaging–capable solution, though many sites aren't yet using the mobility features.

Obviously, mobility-enabled email is important to Microsoft. Not only has the company included the Exchange ActiveSync (EAS) engine in Exchange 2003, Microsoft has also taken the unusual step of licensing its EAS AirSync protocol to companies whose products compete directly with the Windows Mobile OS—while at the same time working with selected partners, such as Good Technology and Intellisync, whose solutions complement Exchange's built-in mobile messaging functionality. In that light, I'd like to talk about what EAS is, what it can and can't do, and how it can help you offer mobile messaging functionality to your users.

What Is EAS?
For quite a while, mobile devices have been able to access email via the familiar POP and IMAP access protocols. You might say that Exchange has supported mobile-device access since Exchange Server 5.0. However, users are increasingly demanding features that IMAP and POP don't necessarily deliver. Users expect synchronization (so that data is visible on both the mobile device and the "normal" mail client); access to email, calendar, and contact data; and complete fidelity of folder contents and data between devices. In addition, the BlackBerry line of handhelds and Good Technology's GoodLink server/handheld combination have conditioned users to expect that their device will always be up-to-date, without the need to schedule manual synchronizations.

EAS delivers on all these expectations. Although I use the term EAS interchangeably for several Exchange components and features, the term most properly describes the synchronization engine that implements the AirSync protocol. The EAS engine and mobile device work together to perform data discovery and synchronization. The mobile device must always initiate the synchronization, although you can enable Exchange's Always-Up-to-Date (AUTD) feature to automatically trigger synchronizations when new mail arrives.

You can use EAS with a variety of devices:

• Windows Mobile 2002 devices (including devices running Microsoft Pocket PC 2002 and Smartphone 2002) use AirSync 1.0.
• Pocket PC 2003 and Smartphone 2003 devices support AirSync 2.0. This version is required for AUTD support.
• The PalmOne Treo 650 supports AirSync 2.0, although its implementation varies somewhat from the Windows Mobile implementation.
• Microsoft and Motorola have announced that the Linux-based Motorola a720 phone will support EAS, although it isn't yet available as of this writing.

Don't confuse EAS with Outlook Mobile Access (OMA); EAS actually synchronizes data to your handheld device, whereas OMA (like Outlook Web Access—OWA) lets you view messages and the Global Address List (GAL) without actually copying any persistent data to your handheld device.

How Does EAS Work?
The setup that Figure 1 shows illustrates how a mobile device uses EAS to communicate with Exchange 2003. For this example, I've chosen to show separate front-end and back-end servers and a Microsoft Internet Security and Acceleration (ISA) Server 2004 firewall, although none of these things are required for using EAS.

When the mobile device makes a request, it posts the request to the \Microsoft-Server-ActiveSync virtual directory. This directory is backed by an Internet Server API (ISAPI) filter—massync.dll—that implements the AirSync protocol. If you use a protocol analyzer to monitor the communications between the device and the server, you'll see that AirSync commands and data pass back and forth as XML nodes, the contents and structure of which aren't documented—and, frankly, aren't very interesting for our purposes.

Each user who has EAS enabled will have three hidden folders in his or her mailbox: CalendarSyncFile for calendar synchronization, ContactSyncFile for contact synchronization, and a folder named after the mailbox globally unique identifier (GUID) for mail synchronization. These folders reside in the NON_IPM_SUBTREE portion of the mailbox, so they won't be visible to conventional Messaging API (MAPI) clients.

When the device connects, it must go through a fairly lengthy synchronization process, each step of which can fail in a variety of interesting ways:

1. The device performs a DNS lookup to find the EAS server. If the user specifies the wrong name, or if the wireless provider's DNS implementation is down, this step will fail.
2. The client makes an initial Secure Sockets Layer (SSL) connection to the EAS server. Depending on the client, this procedure might require checking the validity of the server's SSL certificate, which in turn might require some deployment magic that I'll discuss in the next section.
3. After the SSL connection is established, the device sends the user's credentials to the EAS server, which uses them to authenticate to the Global Catalog (GC) server. This process uses Basic authentication, which you must enable for the EAS directory. If authentication succeeds, the EAS server locates the mailbox server that holds the user's mailbox.
4. The EAS server attempts to use integrated Windows authentication to authenticate to the user's mailbox server. This process is similar to what happens when an OWA or Entourage client uses WWW Distributed Authoring and Versioning (WebDAV) to access the mailbox: EAS is making DAV requests against the Exchange DAV layer.
5. The device sends queued mail, calendar, and contact items, including replies and forwards.
6. The device requests the folder hierarchy, adding any new folders to the synchronization list.
7. The device requests a list of changed items in the first folder, thereby causing EAS to use DAV to retrieve the user's synchronization state file. EAS uses the information in this file to identify items in the folder that have changed since the most recent synchronization.
8. The device requests the changed items, with a maximum of 100 changes per request. The device keeps requesting changes until it receives all the changes identified in Step 7.
9. After all the changes in a folder are synchronized, the device requests changes for the next folder in the sync list, repeating Steps 7 and 8 for each folder that contains changes.
10. After all changes have been synchronized, the device requests any new attachments. Doing so ensures that item changes go to the device first, before potentially large attachments take up bandwidth.