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:

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:

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_MACHINESOFTWAREMicrosoftExchangeOMABatchingTimer registry subkey sets. The BatchingTimer value can be set in three ways:

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 http://blogs.msdn.com/exchange/archive/2004/04/26/120520.aspx.)

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" (http://support.microsoft.com/?kbid=817379). 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_MACHINESYSTEMCurrentControlSetServicesMasSyncParametersExchangeVDir 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" (http://www.microsoft.com/technet/prodtechnol/exchange/2003/autd.mspx).

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 http://www.microsoft.com/downloads/details.aspx?familyid=e0f616c6-8fa4-4768-a3ed-cc09aef7b60a&displaylang=en), 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" (http://support.microsoft.com/?kbid=841060).

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" (http://support.microsoft.com/?kbid=304340) describes.

Troubleshooting
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" (http://support.microsoft.com/?kbid=836024)—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:

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 http://www.microsoft.com/technet/security/tools/urlscan.mspx 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.