Exchange 2003 SP2's Direct Push Technology

Business users have come to rely on having access to email anywhere and anytime. Exchange Server 2003 has long provided features to support mobile email users, including an Always Up-To-Date (AUTD) capability, which works in tandem with Exchange ActiveSync (EAS) to automatically synchronize a wireless mobile device to an Exchange user's mailbox data. New features in Exchange 2003 Service Pack 2 (SP2) significantly enhanced Exchange's mobility functionality, particularly in the areas of security and synchronization through Direct Push technology. (For a look at another new mobility feature in Exchange 2003 SP2, see "Exchange 2003 SP2's GAL Lookup Feature.") We'll explore how EAS, AUTD, and Direct Push technology work to push email from an Exchange server to a mobile device while conserving band- width and minimizing wireless data charges.

EAS: The Basis for Direct Push
EAS has been part of Exchange 2003 since the original Exchange 2003 release to manufacturing (RTM). EAS is a synchronization protocol based on HTTP and XML that's optimized to deal with high-latency and low-bandwidth networks as well as low-capacity clients (i.e., clients that have low memory, storage, and CPU). Among the benefits of EAS are that it works with the four main data types (contacts, tasks, email, calendar; is built into Exchange; doesn't require software installed on the desktop PC; and provides a familiar setup process through Exchange System Manager (ESM).

Other useful features in EAS include options for filtering, truncation, smart reply, and forwarding. These features are all designed to save bandwidth for the mobile device because they let you allow only a certain amount of email to be downloaded (e.g., 3K, 5K, headers only). The smart reply and forwarding features prevent the device from having to download an entire message just to reply to it. Instead, you add your reply content on the device, then as the mail passes through the email server, Exchange adds the rest of the original message to the reply, again saving bandwidth. EAS also allows attachment blocking with the option to allow downloading of attachments on request. (I recommend choosing this option because it avoids the problem of a large attachment swamping your connection.)

EAS Architecture
EAS's basic architecture hasn't changed much since Exchange 2000 Server and Microsoft Mobile Information Server (MIS) 2002, which provided synchronization between Exchange 2000 and devices running Pocket PC 2002. Figure 1 shows a typical EAS configuration. You can see that EAS uses the standard Exchange infrastructure that an organization has in place, which means that EAS can integrate easily with existing systems. EAS can use an existing firewall; to enable it to do so, you simply need open either port 80 or, if you're using Secure Sockets Layer (SSL), which Microsoft recommends, port 443. Also note the simplicity of the configuration, which requires no additional components other than the mobile device.

Now let's look at how EAS works under the covers. When you initiate a connection to the server from your mobile device, the traffic from the device will arrive at your firewall. As long as you've set up port forwarding for standard firewalls or, if you're using Internet Security and Acceleration Server (ISA Server), the traffic will be passed through to your front-end Exchange server, creating a TCP connection. The device then talks to the Microsoft IIS virtual directory Microsoft-Server-ActiveSync. The functions of the Microsoft-Server-ActiveSync directory are implemented by an Internet Server API (ISAPI) filter that controls the connection. The user is then authenticated, and Exchange initiates a query via the DSAccess service to find the user properties in Active Directory (AD) and determine whether the user is allowed to use EAS. If so, the front-end Exchange server locates the back-end Exchange server, which holds the user's mailbox.

At this point, EAS passes the connection to the back-end server, but instead of passing the connection to the Microsoft-Server-ActiveSync virtual directory on the back-end server, makes the connection to the Exchange virtual directory on the back-end server. You can see how in this process EAS uses the Microsoft Outlook Web Access (OWA) architecture and WWW Distributed Authoring and Versioning (WebDAV) commands already in Exchange to connect a mobile device to Exchange.

This redirection and use of OWA brings up a couple of issues. First, for EAS to work you must set up authentication correctly, with basic authentication at the front-end Exchange server and Integrated Windows authentication on the back-end/Exchange virtual directory. Second, because of the need for basic authentication on the front-end server, SSL is highly recommended. To clarify, if you're passing traffic directly through your firewall to your front-end server, the SSL certificate should be installed on the front-end server as a regular Web certificate. If you're using ISA to publish EAS, you need to ensure that the certificate is installed on the front-end server as before but is also available on the ISA server, so that it can be used during the Web listener setup.

The use of SSL to secure the connection from the mobile device to the front-end server creates its own set of conditions. First, you can use only certificates that specify the host name; wildcard certificates aren't supported. Most importantly, the device must trust the SSL certificate's issuer, otherwise synchronization won't work. You'll need to either use a certificate from a trusted Certificate Authority (CA), such as CyberTrust, Entrust, thawte, or VeriSign, or you must import your own private CA's root certificate to every device. (For a full list of root CAs trusted by Window Mobile 5.0 devices using the Windows Mobile 5.0 Messaging and Security Feature Pack—MSFP—see the table at https://partner.microsoft.com/global/partner/40027352.) Should you choose to use your own CA, getting a root certificate onto a device can be problematic, since networks often lock devices at the application level to prevent software from being installed. Prior to the release of the MSFP, you could add a root certificate to a device. But with the MSFP, doing so has become almost impossible, unless your mobile service provider provides a signed application to do this for you, such as Orange in the UK. In the end, this limitation might influence your device purchase, or you might simply choose to use an already trusted CA.

How Direct Push Works
Before Exchange 2003 SP2, you had two choices for synchronizing a mobile device with a mailbox: You could manually configure EAS on the mobile device to issue synchronization on a scheduled basis, or you could use Exchange's AUTD technology. With AUTD, the Exchange server sends an email message to an SMTP-to-Short Message Service (SMS) gate- way, which then sends an SMS message to the device to tell it to initiate synchronization. The problem with scheduled synchronizations is that you can't schedule them for intervals of less than five minutes, which means you won't always have the latest information on your device. Another problem is that, especially if your mobile operator is outside of North America, you'll be charged each time a new session is established—which occurs each time new data travels over the wire.

The idea behind AUTD is good, but the technology hasn't worked well in reality, at least not in Europe where few mobile operators provide the necessary SMTP/SMS gateway that AUTD requires. Microsoft IT became aware of this problem when it deployed Exchange 2003–based mobile messaging in the worldwide Microsoft organization, which prompted it to rectify the problem in Exchange 2003 SP2's Direct Push technology. DirectPush (aka AUTD v2) is an IP-based synchronization technology and provides these benefits:

• A standard data plan is the only subscription you need to synchronize with Exchange (which must work globally).
• You don't need to deploy additional infrastructure in your Exchange environment.
• Direct Push doesn't require SMS notification.
• You don't need to perform any special configuration on a mobile device to use Direct Push.

To use Direct Push, you need a device that supports Windows Mobile 5.0 with the MSFP installed. (For a list of Windows Mobile 5.0–enabled devices, see Jason Langridge's blog at http://blogs.msdn.com/jasonlan/default.aspx.) It's important to note that, although the DirectPush feature is enabled by default in mobile devices that have the MSFP installed, mobile devices that don't have the MSFP installed can still perform synchronizations by using either the manual or scheduled methods or via AUTD. This will no longer be the case in Exchange Server 2007, which will no longer include the original AUTD SMS-based functionality, only DirectPush. Once you've upgraded to Exchange 2003 SP2, a handy feature lets a device that previously used the old AUTD sync automatically switch over to using Direct Push after the upgrade.