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.
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 <Status> 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 <Folder>0 <Folder> 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.
|
RESOURCES Exchange & Outlook Administrator Articles Microsoft Resources Windows Mobile 5.0 Messaging and Security Feature Pack "Enterprise firewall configuration for Exchange ActiveSync Direct Push Technology" Mobility in Exchange Server 2003 Web page New Mobility Features in Exchange Server 2003 SP2 Web page Step-by-Step Guide to Deploying Windows Mobile-based Devices with Microsoft Exchange Server 2003 SP2 TechNet Webcast: "Managing Windows Mobile-based Devices with the Messaging and Security Feature Pack" Microsoft Exchange Team Blog |
