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
Windows Mobile 2005
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.
What's New in SP2
Exchange Server 2003 SP2 mobility enhancements improve the immediacy and quality of the end user experience and also improve the ability of IT pros to secure and manage their mobile device deployment.
Enhancements to the End User Experience
- New push e-mail experience with Direct Push Technology
- Global Address List (GAL) search
- Tasks synchronization
- Picture in contacts
Enhancements to Device Management and Protection
- Remotely enforce and manage corporate IT policy
- Remote, over-the-air wiping of data on the device
- Prevent unauthorized access with device timeout
- Support for certificate-based authentication
- Use S/MIME to sign and encrypt e-mail
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.
Remote wipe is a new feature that will enable Exchange administrators to force a device to delete its content remotely. This is handy when, for example, a user loses a device or a device is stolen. By wiping the device, you can ensure that nobody accesses personal or confidential data.
To initiate and monitor the remote wipe process, you can simply access a new ASP.NET-based administration Web page. This page allows you to view the list of devices for a particular user, send a wipe command for a given user, delete partnerships between devices and users, and cancel the wipe command issued for a particular device. Here, you can also review a transaction log that shows a list of all remote wipe-related actions. The log tracks the targeted user and device, the date and time when the activity took place, the SMTP address, and the action that was taken.
To use the tool for managing mobile accounts, the workflow goes something like this:
- When a user calls your help desk, check which devices are being used. The tool will report all the devices currently used by the user, as well as any devices that have been used in the past.
- Identify the device that has been reported missing and click the wipe action to initiate a remote wipe. If the device is connected using Direct Push Technology, the wipe process will be initiated immediately. Otherwise, it will be initiated the next time the device connects to the server.
- Wait a moment, then check the status of the device. If the remote wipe was successful, you will see the status change to "Remote Wipe was acknowledged" along with a timestamp indicating when the acknowledgment was received by the server.
If the device was connected using Direct Push Technology, the remote wipe should execute in five minutes or less. But, what if this does not happen? Keep in mind that to issue the remote wipe command, there needs to be connectivity between the device and the server. If the user forgot the device in, say, a basement with no network coverage, the remote wipe will not occur. The device is still protected by a password and local wipe, however. It is important to understand that after a remote wipe has been issued, the device will not be able to perform any operation other than to receive the remote wipe notification and report that it has been wiped.
This tool is planned to be available as a download from the "Tools for Exchange Server 2003 Web page". Make sure to read the documentation for important installation and configuration details.
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.
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.
Direct Push Technology FAQ
Here are answers to a few questions that are frequently asked about Direct Push Technology:
Q Does Direct Push Technology reduce the battery life on devices?
A If you are getting lots and lots of e-mail and constantly sending and receiving packets, yes. However, note that for much of the lifetime of a request for change notifications, your device is just waiting for a response. GPRS radios do not consume power unless they are actively transmitting. Further, the lifetime of a request for change notifications is chosen independently by each device and, in practice, these requests tend to live for upwards of 20 minutes if you’re not receiving any e-mail. The means by which the device chooses this lifetime is tuned to minimize bytes over the wire and to maximize battery life. Five-minute scheduled sync is more poorly behaved in this regard.
Q Won’t the always-on data connection result in massive data charges for users? How much data traffic does Direct Push Technology require?
A Direct Push Technology itself does not consume much bandwidth. The real bandwidth is consumed by the e-mails that you need to synchronize—the more e-mails you get the more data you will move down to the device.
Direct Push Technology is designed to minimize the impact on e-mail traffic. For example, the synchronization operations are targeted at only those folders that contain changes, so you’re not performing lots of empty syncs (as is the case with scheduled and manual syncs). And there are additional optimizations performed by both the server and the device.
Q Will the increased connection load affect my Exchange front-end servers?
A No. The immediate impact of Direct Push Technology is that you will see an increased number of open connections that the server must handle. In this case, more memory can help server performance. Given the memory improvements made to the operating system, you’re better off running Exchange Server on Windows Server 2003 SP1. Microsoft has been using Exchange Server 2003 SP2 for months with over 500 devices connecting using Direct Push Technology, and the impact has been minor.
Q Can I use SecurID with Direct Push?
A Yes, but this may result in a sub-optimal user experience. SecurID is supported by ActiveSync. However, for every synchronization request that goes to the server, you need to manually re-enter the unique SecurID key available at that time. This effectively prevents using Direct Push Technology or scheduled sync, since these features require the device to synchronize without user intervention.
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.