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.

This description explains how EAS synchronization works, but you might have noticed that it doesn't make any provision for AUTD synchronization. The goal of AUTD is to augment user-initiated synchronizations (including the scheduled synchronizations that the device's EAS implementation offers) with on-demand synchronizations that fire when new messages arrive in the user's mailbox. When AUTD is enabled for a user, and the Information Store (IS) delivers a new item to a folder that's on the user's synchronization list, an Exchange event sink fires a synchronization notification event. These events are batched according to an interval (calculated in milliseconds) that the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\OMA\BatchingTimer registry subkey sets. The BatchingTimer value can be set in three ways:

  • Setting the value to 0 causes EAS to send a notification message for every new incoming message. This setting will quickly drive up your Short Message Service (SMS) bill if you pay by the message, so be careful.
  • Setting the value to anything in the range of 0 to 900,000 milliseconds (15 minutes) causes EAS to use the default 15-minute notification interval.
  • Setting the value to anything over 900,000 causes EAS to use the actual value. Microsoft hasn't specified the upper limit of this value, so be careful.

When that interval expires, the EAS server sends an SMS text message to the device. However, this message is a special control message that isn't visible to normal SMS applications on the device. (Wireless carriers use other types of control messages to send signal and setup information to phones.) When the control message arrives, it triggers the device's EAS provider to wake up and initiate synchronization. (For a more complete description of AUTD, see the Microsoft Exchange Team Blog entry "What is the Exchange ActiveSync Up-to-date feature and how does it work?" at

Deploying EAS
Because EAS is included with Exchange 2003, not much deployment is required. You don't have to install any additional software, and EAS is enabled by default.

As Figure 2 shows, you enable EAS—as well as OMA and AUTD—in the Mobile Services Properties dialog box. To access this dialog box, expand your Exchange organization object's Global Settings node in Exchange System Manager (ESM), right-click the Mobile Services node, and choose Properties. The Enable user initiated synchronization check box controls whether EAS is enabled for the organization, whereas the Enable up-to-date notifications and Enable notifications to user specified SMTP addresses check boxes control whether AUTD is enabled and whether EAS can send AUTD messages directly to the user's device.

Although EAS is enabled by default, you can control whether it's available to individual users. Open a user's Properties dialog box in the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, and access the Exchange Features tab, which Figure 3 shows. By toggling the settings for User Initiated Synchronization and Up-to-date Notifications, you can govern whether individual users have access to these features.

If you're using one Exchange server and require SSL—either on its own or because you've enabled form-based authentication—you'll have a little extra work ahead of you. You'll have to create a new virtual directory for EAS that doesn't require SSL, then instruct EAS to use this virtual directory instead of the standard \Exchange directory. Although you might think this scenario introduces a security problem, it doesn't because you also add a restriction on the new directory so that it accepts traffic referred only from the local Exchange server's IP address, effectively blocking all outside access. To learn more about setting up this configuration for one server, see the Microsoft article "Exchange ActiveSync and Outlook Mobile Access errors occur when SSL or forms-based authentication is required for Exchange Server 2003" ( In brief, you'll use the Microsoft IIS management console to export the \Exchange virtual directory's settings to a file, create a new virtual directory based on those settings, then instruct the EAS ISAPI filter to use them by applying the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MasSync\Parameters\ExchangeVDir registry value.

Whether or not you have one Exchange server, you also have some extra work to do to set up AUTD. The first time an AUTD-capable device synchronizes with an Exchange 2003 server, the device should display a notification that asks the user whether he or she wants to enable AUTD. If the user answers yes, the device tells the Exchange server the information necessary to make AUTD work (e.g., flags on each folder to be monitored, information about the user's device) in the user's mailbox. The user also must know his or her SMS address (it's typically the mobile-device phone number combined with the carrier's domain name), and the mobile carrier must support automatic conversion of SMTP messages into SMS messages. Most major carriers—AT&T, Sprint, T-Mobile, and Verizon in the United States; Orange, Telstra, and T-Mobile worldwide—provide this support, but some don't. For a more complete guide to setting up AUTD on specific Windows Mobile devices, see Vanitha Prabhakaran's excellent article "How to Configure Always Up-To-Date Notifications" (

Considering Security
You need to keep several security considerations in mind if you implement EAS. First, because the device-to-EAS connection exposes the user's mailbox credentials, I strongly recommend that you use SSL all the time. However, you might sometimes need to temporarily disable it for troubleshooting. If you must do so, be sure to re-enable it as soon as possible.

Second, if you're using SSL, the source of your certificate can make a difference. Windows Mobile devices will attempt to check the authenticity of the certificate by checking their local certificate trust lists (CTLs). You can bypass this behavior with the DisableCertChk tool (included in the Exchange tool download at, or you can use the SPAddCert tool to install the Certificate Authority's (CA's) certificate on the device. For more information about the latter option, see the Microsoft article "How to add root certificates to Windows Mobile 2003 Smartphone and to Windows Mobile 2002 Smartphone" (

Third, make sure the firewall you have in front of the EAS server supports the WebDAV OPTIONS verb. Some firewalls block it, in which case EAS won't work. In particular, ISA Server 2000 doesn't support this verb unless you upgrade it to Service Pack 1 (SP1) and add the registry value PassOPTIONSToPublishedServer, as the Microsoft article "The ISA Server response to client options requests is limited to a predefined set" ( describes.

The Windows Mobile implementations of EAS provide error codes when things go wrong. (Sadly, the PalmOne Treo 650 reports only a few generic errors and has no device logging, making it a much more difficult device with which to troubleshoot.) A complete discussion of EAS troubleshooting would occupy an entire article in itself—for excellent information about this topic, see Jim Westmoreland's "TechNet Support WebCast: Troubleshooting Microsoft Exchange Server 2003 ActiveSync issues" (—but I can give you a few highlights to help you get started.

The most important foundation for troubleshooting is to understand the error codes you're getting. Microsoft hasn't published a comprehensive list of all potential error codes, but the EAS-troubleshooting Webcast transcript has some valuable nuggets of information. Here's some information about several common errors:

  • MIS_XX or SYNC_XX errors indicate a problem with the EAS server. For instance, SYNC_5 typically occurs because integrated authentication is disabled on the EAS virtual directory.
  • HTTP_XXX errors indicate communication problems between the device and the server. These errors can be pretty generic: For example, HTTP_401 means you have an authentication problem, but the error message doesn't display the actual problem. If you get these errors, check the IIS logs and your EAS server application event log. When I first tried to set up EAS, I got this error and, thanks to the event log, quickly determined that bad authentication settings on my front-end server were causing it. HTTP_403 means that the target account doesn't have permission to use EAS.
  • Internet_XX errors indicate communication problems with the device and the Internet. For example, INTERNET_7 means that the device can't resolve the DNS name you entered for the server, and INTERNET_45 and INTERNET_55 typically mean that the synchronization failed because the server certificate couldn't be validated.
  • ConnMgr_XX errors appear when the Connection Manager software (e.g., the client side of EAS) encounters an error. These errors are fairly rare.
  • Dev_XX errors are reported by the device. For example, the common DEV_1 error tells you that the device doesn't have enough free memory to complete the synchronization, and DEV_3 indicates that a timeout occurred during the synchronization.
  • Error codes that begin with 0x are Windows HResult error codes. You'll see these errors only if some kind of unexpected (and hence, uncaught) error occurs.

The first way to test whether EAS is working is to see whether you can reach the \Microsoft-Server-ActiveSync directory on your Exchange server. You should always get a 501 Not implemented message when you try to access this directory by using an HTTP GET request, regardless of the device you're using or the presence of SSL. To test whether EAS is working at all, try using a desktop machine inside your firewall to load that URL. If that works, try loading the URL on your device's Web browser. If you can't resolve it with SSL, try disabling SSL. If you still can't load it, you're probably experiencing some kind of name-resolution problem.

Next, check the EAS server's event logs. If you're having an authentication problem, the most obvious clue will be authentication-failure messages in the event log. If you're experiencing some other kind of problem, check the IIS logs to verify that the device requests are making it to the EAS server. If you have ISA Server or another firewall in place, it might be filtering some or all requests. In particular, remember that you can configure Microsoft's URLScan tool (which you can use to filter URL and WebDAV requests, as the Microsoft TechNet article "UrlScan Security Tool" at describes) to block the IF and PUT verbs that EAS uses, and that ISA Server might block the required OPTIONS verb.

Is EAS Right for You?
EAS is notable because it provides wireless access to calendar, contact, and message data without requiring the addition of any server-side software—all you need is Exchange 2003 and a compatible device. The current version of EAS doesn't provide as much functionality as the aforementioned BlackBerry or GoodLink solutions, but its entry cost is much lower and it provides sufficient functionality for many organizations. Because EAS offers a low-cost and fairly simple way to deploy wireless access for your users, it's well worth evaluating as you explore your wireless connectivity options.