A big advantage that Exchange Server 2003 offers over previous versions—to say nothing of competing products—is its integrated support for wireless and mobile users. And with the release of Exchange 2003 Service Pack 2 (SP2), Microsoft has significantly added to the Exchange mobility feature set.
Mobile is a tough word to define in regards to the messaging realm, because it can variably and accurately describe the executive communicating with a handheld device, the Exchange administrator managing with a laptop, and the repair technician using Microsoft Outlook Web Access (OWA) from an Internet kiosk. Exchange solutions provide access to all three classes of user, but in this article, I focus on the SP2 features that provide improved access to wireless devices such as PDAs and smart phones running Windows Mobile. To that end, I describe what's new in SP2, how the new features work, and how you can best use them to your advantage.
Setting the Stage
Exchange 2003 shipped with two kinds of integrated wireless-device support: Outlook Mobile Access (OMA) and Exchange ActiveSync (EAS). These two protocols are actually quite different, and it's important to understand the differences between them because all the cool new features in SP2 involve EAS.
OMA. OMA provides online Inbox access, as well as access to a limited set of other folders. It doesn't support offline access; you can use it only when you have a connection to the server. Therefore, its usefulness to truly mobile users is limited. On the other hand, OMA supports a broad range of devices—from basic Wireless Application Protocol (WAP)?enabled cell phones to Pocket PCs, smart phones, and PalmOS devices. Because OMA is a lightweight client, it works well on low-end devices, but there are a lot of things it can't do.
EAS. Unlike OMA, EAS is a high-fidelity protocol that—with an appropriate client—gives you much of the functionality you're used to in Outlook. Microsoft originally shipped Mobile Information Server for Exchange 2000, then refined its protocol, renamed it EAS, and included it as part of Exchange 2003.
EAS requires that you have a client component that understands the protocol and caches mail locally. On Windows Mobile 2003 and 5.0 devices, that client component is Pocket Outlook; on the Palm Treo 650, it's VersaMail; and on other devices that support EAS, it's whatever the device vendor decides to ship as a mail client. (Interestingly, DataViz is shipping a very usable EAS client called RoadSync that runs on a wide variety of Palm, Symbian, and Java-based devices. I use it frequently on my Treo and find it a great alternative to Palm's in-device client.) The missing piece was the ability to access all your email on the device whenever you turn it on, much as Research in Motion (RIM) BlackBerry or Good Technology users are accustomed to.
Always-Up-to-Date... Or Is It?
As part of the Exchange 2003 rollout, Microsoft included a feature known as Always-Up-to-Date (AUTD). The idea behind AUTD is simple: When a mailbox is configured to use AUTD, new mail triggers a notification. The notification process—actually implemented as an event sink—keeps track of the globally unique identifier (GUID) for each mailbox that has AUTD notification configured and batches notifications. When the batch timer expires, Exchange sends one notification to the device as a Short Message Service (SMS) control message. The device receives the SMS notification, wakes up if it's asleep, and "phones home" to pick up the new mail.
By default, the batch timer uses a 15-minute interval, but that might not work for your particular installation. To control how often the batch timer fires (and thus how often Exchange sends notifications), navigate to the HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\Exchange\OMA subkey (create this subkey if it doesn't exist), and create a value called BatchingTimer (of type REG_DWORD). Possible values, in milliseconds, are as follows:
- 0: Instead of batching, Exchange sends notifications as each message arrives. I don't recommend this value because every notification generates an SMS message to your device, often resulting in cost overhead, unless you have an unlimited SMS plan from your mobile provider.
- A value less than 900000: A value of 900000 corresponds to the number of milliseconds in 15 minutes, which is the default interval. A value less than that number causes the interval to remain at 15 minutes.
- A value greater than 900000: Any value greater than 900000 will be recognized as the actual value. For example, a value of 3600000 sets the batching timer to 1 hour.
However, AUTD's basic shortcoming is that it depends on SMS message transport, which isn't always reliable. Also, mail arriving in batches isn't exactly ideal for most users. SP2 solves these problems with its newly introduced Direct Push scheme, as I describe in a moment.
Required Infrastructure
Before you go through the relatively simple process of deploying SP2, understand that to take full advantage of the new features, you need a device that supports them—that is, a device that includes Windows Mobile 5.0 or the Messaging and Security Feature Pack (MSFP). The MSFP implements SP2's Direct Push and Remote Wipe enhancements for the device.
As of late 2005, no one is actually selling devices that include the MSFP, although several manufacturers are selling Windows Mobile 5.0 devices that you could—in theory, at least— upgrade to the MSFP. Regrettably, upgrades are at the discretion of the device manufacturer or cellular provider (not Microsoft), so there's no guarantee that any device you buy today will support the MSFP in the future. This predicament is bound to slow adoption of the MSFP's features, which is a shame.