Stay Better Connected with Exchange ActiveSync
Max Ciccotosto and Paul Limont
At a Glance:
- Using Exchange ActiveSync to streamline mobile messaging
- How Direct Push Technology works to keep mobile inboxes up to date
- Mobile compression and encryption technology in SP2
- Device password polices and remote wipe capabilities
Exchange Server 2003 Service Pack 2 (SP2) boasts a much improved feature set for devices that synchronize using the ActiveSync protocol. In this article, I’ll take a closer look at
the new mobility features you’ll find in SP2. I’ll also explain how SP2 will enhance your messaging environment to provide a better, more cost-effective approach to mobile messaging.
Exchange ActiveSync® (EAS) is an Exchange synchronization protocol designed for keeping your Exchange mailbox synchronized on a mobile device. It is optimized to deal with high-latency/low-bandwidth networks, and also with low-capacity clients that have limited amounts of memory, storage, and processing power. Under the covers, the Exchange ActiveSync protocol is based on HTTP, SSL, and XML, and is built around the following four guiding principles.
Part of Exchange You don’t need to install additional software or servers. Every Exchange Server 2003 installation can provide EAS capabilities. The EAS features do not require any additional licenses. The bottom line is that if you have Exchange Server 2003 installed, you have everything needed for mobile devices to connect and sync.
The Familiar Outlook Experience The consistency of the Outlook® experience across all the Exchange clients makes your users immediately productive. There is little user training required, which drastically reduces support costs.
No Desktop Software You can buy a EAS-compatible device (such as a Windows Mobile® smartphone), enter some basic configuration information, and start synchronizing with the server immediately. From the administrator’s perspective there is no extra software to install or support to provide on the desktop.
No Special Data Plan or Subscription When your user buys a new EAS-compatible device, he needs only a standard data plan to access Exchange e-mail. You can buy as much data access as needed, and ActiveSync functionality is available globally though standard data access phone service.
I recently used this capability during a trip to Italy. I have a data plan with a US-based GSM service. When I arrived in Italy, my brother gave me one of his GSM SIM cards and I was up and running. I didn’t even have to change my ActiveSync settings!
Direct Push Technology
Users want to receive new e-mails on their device as soon as they are received in their Exchange mailbox. The SMS-based up-to-date notifications solution originally provided with Exchange Server 2003 simply did not cut it for many users. SP2 provides a new approach, called Exchange Direct Push Technology, designed to deliver what end users have been asking for by supporting push messaging on any IP network.
Direct Push works for all of your mailbox data, including Inbox, Calendar, Contacts, and Tasks. In addition, Direct Push does not rely on SMS, instead leveraging a long-lived HTTPS connection between the device and the Exchange server. No special configuration is required on the client, and you can keep your standard data plan since the service is world-capable and requires no additional software or server installations. Conveniently, devices can detect the presence of Direct Push and automatically switch to the new functionality.
Administrators should keep a few things in mind. First, Direct Push Technology is enabled by default in SP2. (The settings for Exchange ActiveSync and Direct Push Technology are shown in Figure 1.) You do need to adjust the connection timeout of your firewall to ensure that Direct Push functionality works efficiently. With the goal of optimizing battery life, we recommend between 15 and 30 minutes.
Figure 1 ActiveSync and Direct Push Settings
To better understand this last requirement, let’s look at this technology in more detail. Direct Push requires a long-lived connection between the server and the client. No data is sent over this connection unless there is e-mail to be transmitted or the device needs to reestablish its connection with the server. This means that the maximum length of the connection is determined by the lowest network timeout in the path between the device and the server.
With good network coverage, the maximum timeout will be determined by the connection timeout enforced by firewalls that deal with Internet traffic to your Exchange front-end servers. If you keep the timeout very low, then you will force the device to reconnect several times, quickly draining its battery. As a general guideline, a timeout between 15 and 30 minutes should suffice.
Compression and 3DES
Compression is enabled for data that is sent from the Exchange Server to a device. This feature is similar to the functionality Outlook Web Access introduced in Exchange Server 2003, and provides comparable savings in terms of bytes over the wire. Testing has shown as much as a 50 percent reduction in traffic. The impact of compression is really twofold:
- You are reducing the bits sent over the wire.
- Users will see that the experience on the device is much improved as the data arrives faster. (You’ll even notice substantial improvement on the initial sync.)
The other over-the-air highlight has to do with SSL encryption. Exchange Server 2003 SP2 supports multiple encryption modes. By default, the server and the client will negotiate RC4, but the server can be configured to enforce 3DES encryption. Such encryption obviously needs to be supported on the device, but Windows® Mobile devices with the Messaging and Security Feature Pack (MSFP) have support for 3DES.
This is the feature that makes me think "how did I ever live without it?" From your Smartphone or Pocket PC device, you can now look up any user in your organization’s global address list (GAL).
The search query is a string which may denote different Active Directory® properties—like display name, office, alias, first name, and so on. The query string is then used on the server to do a prefix search on Ambiguous Name Resolution (ANR) indexable properties for all the mail-enabled objects on the Exchange server. The objects whose ANR indexable properties match the search query are returned as the response results.
The response provides a handful of properties: first name, last name, display name, office location, title, company, office phone, mobile phone, alias, and e-mail address. (This set of properties is not currently customizable.) The best way to look up a user is to use alias, display name, first name, or last name. But the number of results is limited to 100 items, so make sure that your queries are well-scoped!
There are no special requirements to enable this feature. In fact, GAL lookup is installed and enabled by default.
Device Password Policies
Many administrators want to know how they can enforce a PIN on the device. In the past, there wasn’t a solution built into Exchange (though there are third-party products that provide this capability). But Exchange Server 2003 SP2 now enables you to configure a central policy that requires all mobile device users to protect their device with a password in order to access the Exchange Server.
To specify security settings for mobile devices using Exchange System Manager, right-click Mobile Services and then click Properties. On the Mobile Services Properties dialog box, click the Device Security button. You’ll see the Device Security Settings dialog box shown in Figure 2. To enable password policy for devices, make sure the Enforce password on device option is checked.
Figure 2 Enabling Security Settings
Once you enable the policy, there are specific password attributes that you can configure including the length of the password (the default is four characters), usage of a character or symbol in the password, and how long the device needs be inactive before prompting for the password. You can also specify a refresh rate, which forces the device to verify and re-download the policies at regular intervals.
An additional setting, Wipe device after failed attempts, allows the administrator to delete all data on the device after the user enters the wrong password a specified number of times. The specific implementation of the wipe is left to the device. Windows Mobile phones will allow deleting all the information on the device, with the exception of the data on removable storage (like SD cards). At first, this may seem like a limitation, but it is not possible to store Exchange data on the removable storage, so you don’t have to worry about Exchange data being left on the removable card.
The last attribute of the security policy allows administrators to specify whether non-compliant devices can synchronize. Devices are considered non-compliant if they do not support the policy specified by the administrator; legacy devices represent the bulk of such cases. If you already have ActiveSync-capable devices deployed throughout your organization, you will need to enable this setting, otherwise none of your existing devices will be able to synchronize.
Another case of a non-compliant device is when a device does not support all the attributes specified in the password policy. For example, you could create a policy that requires an 8-digit password. Meanwhile, there may be a device that only supports a standard 4-digit PIN. As an administrator, you can decide whether to allow such a device to synchronize.
Last, but not least, SP2 provides an exception list for your policy. Users in this list are not prompted to accept the policy and can continue to synchronize without any issues.
Microsoft has introduced some essential mobility features in Exchange Server Service Pack 2. Direct Push Technology and GAL lookup will make the user experience much more productive when using a device to work away from the office (and away from Outlook). Meanwhile, safeguards like password policies and remote wipe capabilities will provide administrators with the security features required to protect the organization’s data.
Max Ciccotosto is a Lead Program Manager on the Exchange Server team at Microsoft, and is currently working on Exchange 12.
Paul Limont is a Program Manager on the Exchange Server team, working on mobility in Exchange Server 2003 SP2 and planning for Exchange 12.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited
The new features in SP2 will require an update to the software that is running on the client. Windows Mobile has announced that it will release a Messaging and Feature Pack for Windows Mobile 5, but specifics regarding availability are not yet published at the time of writing this article. However, more information can be found online at Windows Mobile 5.0 Messaging and Security Feature Pack