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.
New Mobility Features in SP2
SP2's new features fall into four categories. First, Direct Push replaces the existing Exchange 2003 AUTD mechanism. Second, you get remote access to the Global Address List (GAL), so that you can search the GAL and obtain properties for individuals on the list. (This feature has no administrative component, so I won't discuss it further.) Third, you can enforce password policies for remote devices. This feature brings to mobile devices the same type of password-length and password-strength requirements we've had since Windows NT 3.1. Fourth, Remote Wipe lets you remotely erase data from a lost or stolen device.
Direct Push. The AUTD synchronization model has its uses, but given the prevalence of smarter devices (and always-on IP connectivity), the Exchange development team decided to take a different approach. Using HTTP—or, more precisely, HTTP Secure (HTTPS)—the device itself makes the initial request of the Exchange server. This request asks the Exchange server to signal any changes made to a specified set of folders ( typically, Inbox, Calendar, Contacts, and Tasks). At that point, the device can drop its connection because it has a long timeout interval (the default is 30 minutes) on the connection request; it's waiting for a response from the server, and the device radio doesn't need to be in transmit mode.
What happens next depends on whether any changes exist. If the timeout interval is reached without any changes, the device reissues the request. This process requires a brief use of the device radio, but it's a quick, low-power process. If changes have occurred, the Exchange server returns a response specifying which folders have changed. The device then makes a synchronization request for those folders. After the synchronization is finished, the device makes another change-notification request, and the radio goes back to sleep.
This approach is more efficient than that of the original AUTD model because the device has to transmit only when it requests synchronization updates. Therefore, the device radio can be in its low-power "listening" state most of the time. Because it uses HTTP instead of a custom protocol, it doesn't require any special attention at the firewall.
You don't have to do anything special to enable Direct Push—it's enabled by default. If you want to turn it off, you can do so from the Mobile Services Properties dialog box that Figure 1 shows.
Password-policy enforcement. Windows has long offered the ability to set policies that govern the length and character composition of passwords. Short or easily guessed passwords present a significant security risk, particularly because the computing power necessary to attempt repetitive brute-force attacks has become increasingly cheaper. SP2 lets you specify several password-policy characteristics through the Device Security Settings dialog box, which Figure 2 shows. (You access this dialog box through the Device Security button that Figure 1 shows.) The characteristics you can specify are as follows:
- Password-policy enforcement: If you choose to enforce policies (by selecting the Enforce password on device check box), you can use the Allow access to devices that do not fully support password settings check box to control whether non?MSFP-capable devices can access your servers.
- Minimum length for device passwords and whether those passwords must be alphanumeric: Your choice will probably depend on the form factor that most of your devices use. Entering long alphanumeric passwords on 10-key smart phone keypads can be a boring and error-prone endeavor.
- The length of time after which the device automatically locks itself.
- The number of failed logon attempts to the device (not to the Exchange server) after which the device will wipe itself.
- The interval by which policy settings are updated. By default, the device requests a policy update every 24 hours, but you can force an update.
When you first install SP2, no password policy is defined. I recommend that you set one, although you'll probably need to allow devices that don't support password-policy enforcement to connect until you have an all?Windows Mobile 5.0 deployment. In addition, be liberal with the number of attempts you permit before forcing a wipe so that you don't wipe out users' devices before they have a chance to get accustomed to the new policy.
Remote Wipe. Around the world, thousands of mobile devices and PDAs are lost every day. In 2004, the London Underground collected about 15,000 lost devices (compared with nearly 75,000 devices lost in London cabs during the first half of 2004!). Because EAS devices store both authentication credentials and mail, calendar, and contact data, losing one can expose a great deal of sensitive data to anyone who happens to pick it up. The MSFP's improved password policies are one good way to counter this threat, but the new Remote Wipe capability provides an even better way.
The Remote Wipe tool is implemented as a separate Web download. You install it on your Exchange server, whereupon the installer creates a new Microsoft IIS virtual directory named MobileAdmin. The Remote Wipe tool requires Secure Sockets Layer (SSL), so if you don't have a certificate (or if SSL isn't enabled), you'll have to enable it before you can use the tool. After you install the Remote Wipe tool, you'll be able to selectively send Wipe commands to individual devices.
You begin the wipe process by searching for a mobile device (i.e., entering a mailbox name). After that, you can select any device associated with that account and wipe it. There's a slight delay between the time you click the Wipe link and the time the wipe actually starts, during which the Wipe link becomes a Cancel Wipe link. If you're quick enough, you might be able to cancel the wipe, but you should assume that you won't be able to cancel the wipe once it begins.
The wipe actually happens when the Remote Wipe tool sets a wipeinitiated property on the specific device/ folder combination for which you've requested the wipe. The tool uses the standard WWW Distributed Authoring and Versioning (WebDAV) PROPPATCH method to set this property. When the device sees that this property has been changed (which it will, because the property change is treated as an update according to the Direct Push process I described earlier), the device first wipes itself and then sends back an acknowledgment that the wipe has been completed. If you don't see the acknowledgment, you know that the wipe didn't take place when it should have. More important, the server can keep track of the device's response and retry the wipe operation until it succeeds.
So Why Can't I Have It?
SP2's mobility features are compelling—or, at least, they would be if you could buy devices that take full advantage of them. Although many of the reviews and comments I've seen have laid the blame on Microsoft, the truth is that cellular providers have no incentive to provide updates such as the MSFP to existing customers. They would rather you buy a new device at full retail cost—an unfortunate reality of the telecommunications business.
In the meantime, we can't take full advantage of these improvements, which hurts because the security improvements are significant enough to warrant upgrading. The combination of MSFP and SP2 provides a greatly improved mobile-device access experience, and you should deploy them at the earliest possible opportunity if you need mobile access for your Exchange users.
Paul Robichaux ([email protected]) is a principal engineer for 3sharp, an MCSE, and an Exchange MVP. He is the author of several books, including The Exchange Server Cookbook (O'Reilly and Associates), and creator of the http://www.exchangefaq.org Web site.
