Exchange 2003 SP2's Direct Push Technology - 29 Aug 2006

Business users have come to relyon having access to email anywhere and anytime. ExchangeServer 2003 has long provided featuresto support mobile email users, including an Always Up-To-Date (AUTD)capability, which works in tandem withExchange ActiveSync (EAS) to automatically synchronize a wirelessmobile device to an Exchange user'smailbox data. New features in Exchange2003 Service Pack 2 (SP2) significantlyenhanced Exchange's mobility functionality, particularly in the areas ofsecurity and synchronization throughDirect Push technology. (For a look atanother new mobility feature inExchange 2003 SP2, see "Exchange2003 SP2's GAL Lookup Feature.") We'll explore how EAS, AUTD, andDirect Push technology work to pushemail from an Exchange server to amobile device while conserving band-width and minimizing wireless datacharges.

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

Other useful features in EAS includeoptions for filtering, truncation, smartreply, and forwarding. These featuresare all designed to save bandwidth forthe mobile device because they letyou allow only a certain amount ofemail to be downloaded (e.g., 3K, 5K,headers only). The smart reply andforwarding features prevent thedevice from having to download anentire message just to reply to it.Instead, you add your reply contenton the device, then as the mail passesthrough the email server, Exchangeadds the rest of the original messageto the reply, again saving bandwidth.EAS also allows attachment blockingwith the option to allow downloadingof attachments on request. (I recommend choosing this option because itavoids the problem of a large attachment swamping your connection.)

EAS Architecture
EAS's basic architecture hasn'tchanged much since Exchange 2000Server and Microsoft Mobile Information Server (MIS) 2002, which provided synchronization betweenExchange 2000 and devices running Pocket PC 2002. Figure 1 shows a typical EAS configuration. You can see that EAS uses thestandard Exchange infrastructurethat an organization has in place,which means that EAS can integrate easily with existing systems.EAS can use an existing firewall; toenable it to do so, you simply needopen either port 80 or, if you'reusing Secure Sockets Layer (SSL),which Microsoft recommends, port443. Also note the simplicity of theconfiguration, which requires noadditional components other thanthe mobile device.

Now let's look at how EAS worksunder the covers. When you initiate aconnection to the server from yourmobile device, the traffic from thedevice will arrive at your firewall. Aslong as you've set up port forwardingfor standard firewalls or, if you're usingInternet Security and AccelerationServer (ISA Server), the traffic will bepassed through to your front-endExchange server, creating a TCP connection. The device then talks to theMicrosoft IIS virtual directory Microsoft-Server-ActiveSync. The functionsof the Microsoft-Server-ActiveSyncdirectory are implemented by anInternet Server API (ISAPI) filter thatcontrols the connection. The user isthen authenticated, and Exchange initiates a query via the DSAccess serviceto find the user properties in ActiveDirectory (AD) and determinewhether the user is allowed to useEAS. If so, the front-end Exchangeserver locates the back-end Exchangeserver, which holds the user's mailbox.

At this point, EAS passes the connection to the back-end server, but insteadof passing the connection to theMicrosoft-Server-ActiveSync virtualdirectory on the back-end server,makes the connection to the Exchangevirtual directory on the back-endserver. You can see how in this processEAS uses the Microsoft Outlook WebAccess (OWA) architecture and WWWDistributed Authoring and Versioning(WebDAV) commands already inExchange to connect a mobile deviceto Exchange.

This redirection and use of OWAbrings up a couple of issues. First, forEAS to work you must set up authentication correctly, with basic authentication at the front-end Exchangeserver and Integrated Windows authentication on the back-end/Exchangevirtual directory. Second, because ofthe need for basic authentication onthe front-end server, SSL is highly recommended. To clarify, if you're passing traffic directly through yourfirewall to your front-end server, theSSL certificate should be installed onthe front-end server as a regular Webcertificate. If you're using ISA to publish EAS, you need to ensure that thecertificate is installed on the front-endserver as before but is also availableon the ISA server, so that it can beused during the Web listener setup.

The use of SSL to secure the connection from the mobile device to thefront-end server creates its own set ofconditions. First, you can use only certificates that specify the host name;wildcard certificates aren't supported.Most importantly, the device musttrust the SSL certificate's issuer, otherwise synchronization won't work.You'll need to either use a certificatefrom a trusted Certificate Authority(CA), such as CyberTrust, Entrust,thawte, or VeriSign, or you mustimport your own private CA's root certificate to every device. (For a full listof 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 simplychoose to use an already trusted CA.

How Direct Push Works
Before Exchange 2003 SP2, you hadtwo choices for synchronizing amobile device with a mailbox: Youcould manually configure EAS on themobile device to issue synchronization on a scheduled basis, or youcould use Exchange's AUTD technology. With AUTD, the Exchange serversends an email message to an SMTP-to-Short Message Service (SMS) gate-way, which then sends an SMSmessage to the device to tell it to initiate synchronization. The problemwith scheduled synchronizations isthat you can't schedule them for intervals of less than five minutes, whichmeans you won't always have the latest information on your device.Another problem is that, especially ifyour mobile operator is outside ofNorth America, you'll be charged eachtime a new session is established—which occurs each time new datatravels over the wire.

The idea behind AUTD is good, butthe technology hasn't worked well inreality, at least not in Europe wherefew mobile operators provide the necessary SMTP/SMS gateway that AUTDrequires. Microsoft IT became awareof this problem when it deployed Exchange 2003–based mobile messagingin the worldwide Microsoft organization, which prompted it to rectify theproblem in Exchange 2003 SP2's DirectPush technology. DirectPush (aka AUTDv2) is an IP-based synchronization technology and provides these benefits:

To use Direct Push, you need a devicethat supports Windows Mobile 5.0with the MSFP installed. (For a list ofWindows 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 isenabled by default in mobile devicesthat have the MSFP installed, mobiledevices that don't have the MSFP installed can still perform synchronizations by using either the manual orscheduled methods or via AUTD. Thiswill no longer be the case in ExchangeServer 2007, which will no longerinclude the original AUTD SMS-basedfunctionality, only DirectPush. Onceyou've upgraded to Exchange 2003SP2, a handy feature lets a device thatpreviously used the old AUTD syncautomatically switch over to usingDirect Push after the upgrade.

How exactly does Direct Push work? DirectPush maintains an HTTP Secure (HTTPS) connection between the Exchange server and the mobile device, a session that's kept alive by using heartbeats. In this way, the Exchange server can notify a mobile device whether or not a change has occurred in the device's associated mailbox; if a change occurs in the mailbox, the server can initiate synchronization. Since the device keeps an open session to the Exchange server, you might think the connection could become rather expensive. However, the device simply sits and waits for a response; it doesn't send or receive any data while it's in this pending state—so you won't incur data charges. Because the mobile device doesn't sync unless there's a change in the mailbox, as is the case with scheduled or manual syncs, the device uses less power—again saving on money as well as battery life. Additionally, any data synchronized between the mailbox and mobile devices is compressed by using GNU zip (gzip) compression.

Figure 2 shows the basic steps in Direct Push synchronization. First, the mobile device pings the server and goes through the EAS sync process as described earlier. (Note that the EAS Ping command is a completely new command that Microsoft created solely for Direct Push; it has nothing to do with the Internet Control Message Protocol—ICMP—Ping, so you don't need to worry that the Ping will blocked at a firewall.) At the end of the synchronization, the device sends an EAS Ping to the front-end Exchange server, which has a timeout value of 15 minutes, which keeps the connection open for 15 minutes after the final Ping. During the next 15-minute period, if nothing changes in the monitored mailbox folders, the Ping times out and the front-end server sends a request to the mobile device for another Ping. This Ping process continues until a change occurs in the monitored mailbox folders. The front- end server then uses the existing HTTPS connection to notify the device that a change has occurred. The device then initiates synchronization—but syncs only the folder where the item is and not the user's entire mailbox, which saves bandwidth and data charges.

A Closer Look at Ping
What does the Ping command look like? As the sample network trace in Figure 3 shows, when a mobile device establishes a new connection, the device tells the Exchange server which folders the device wants to be notified about along with the desired heart- beat interval, measured in seconds (shown by the Lifetime tag), during which it expects to hear from the server. EAS creates subscriptions to the back-end Exchange server by using the WebDAV SUBSCRIBE and UNSUBSCRIBE commands. As mentioned earlier, if no mail comes in to the Exchange server during the 15-minute period, the device pings the Exchange server again. Note that after the first Ping, subsequent Pings are a minimal size because no other information between the Ping tags is required. If the mobile device sends the Ping on an existing connection, no re-authentication is needed.

If during a Ping's timeout period a change occurs (i.e., new mail comes in), the back-end Exchange server notifies the front-end server of the change over UDP port 2883, and the front-end server informs the device that there's mail in a specific folder or folders. It's important, therefore, that UDP port 2883 remain open between the front- and back-end servers, although you can change the port number if necessary. The status code next to the tag in Figure 4 indicates success, failure, timeout, or other error conditions. If the folder hierarchy itself has changed, the server tells the device to initiate a sync by including the tags 0 in the list of changed folders. If no status is specified, the code is assumed to be 1—that is, no changes.

Firewalls and Direct Push
If you want to enable Direct Push on your Exchange network, you need to take into account certain considerations when setting up firewalls. In particular, you should set the timeout values on the path from the mobile device to the front-end server to be greater than the Ping interval value. If the timeout values are lower than the Ping interval value, the connection will be dropped and the device will have to reissue the Ping.

The steps involved in configuring a firewall to work with Direct Push depend on the type of firewall used in your organization. For information about how to configure Direct Push and the ISA Server 2004 firewall, see the Microsoft article "Enterprise firewall configuration for Exchange ActiveSync Direct Push Technology" (http://support.microsoft.com/?kbid =905013). This article also provides additional information that will help you assess the choices you might need to make when setting up other firewalls.

After the firewall is correctly configured, you should also adjust the timeout values for the IIS server on the default Web site's front-end server. I've found that a value between 15 and 30 minutes (900 to 1800 seconds) works well in small-to-midsized business (SMB) networks that use Direct Push.

Economical, Up-to-Date Access
Direct Push is the latest evolution of the AUTD technology that's been in Exchange 2003 since its release. As you've seen, Direct Push lets a mobile device continuously ping the Exchange server and automatically sync with the server only when new mail comes into the user's Exchange mailbox. DirectPush ensures that Windows Mobile 5.0–device users have similarly up-to-date access to mail, calendars, and contacts as they have in the office—at an economical cost.