Exchange ActiveSync and Exchange 2003


Exchange ActiveSync enables you to synchronize data between your mobile device and Exchange Server 2003. E-mail, contacts, and calendar information (Personal Information Manager, or PIM, data) can all be synchronized. This feature was previously available through Mobile Information Server and was referred to as Microsoft Server ActiveSync. It is now integrated with Exchange Server 2003.

With Mobile Information Server, devices running Microsoft Windows Powered Pocket PC 2002, Microsoft Windows Powered Pocket PC 2002 Phone Edition, and Microsoft Windows Powered Smartphone had the Server ActiveSync client component installed and were supported.

With Exchange ActiveSync, devices that are running Pocket PC 2002, Pocket PC 2002 Phone Edition, and Smartphone are still supported. Additionally, Microsoft Windows Powered Pocket PC 2003 devices are supported. Pocket PC 2003 devices enable greater granularity in scheduling synchronization and also support the Always Up To Date functionality that is introduced in Exchange Server 2003.

Exchange ActiveSync is implemented in the following files:

  • Massync.dll   OMA Sync ISAPI extension DLL

  • Masperf.dll   OMA Sync Performance Counter DLL

  • MasPerf.ini   OMA Sync Performance Counter INI

  • Masperf.h   OMA Sync Performance Counter header

Exchange ActiveSync Protocol Architecture

The sync protocol is a request and response protocol built on a client and server communications model. It is built on the HTTP protocol, using the HTTP POST request and response mechanism and the HTTP OPTIONS command. The HTTP POST header specifies a protocol command and, if the command requires it, command data is sent in the HTTP POST body. The data is typically formatted as compressed Wireless Binary XML (WbXML), which makes efficient use of the constrained bandwidth of mobile clients.

The client initiates communication by posting a request. When the server receives the request, it parses the request and then sends an HTTP POST response that contains the requested data in its body.

The sync protocol requires a TCP/IP connection between the client and server. However, the underlying network layers are implementation-specific. Three common transport layers that support the protocol are GPRS, CDMA 1xRTT, and IEEE 802.11. The sync protocol requires that any transmission errors are handled by the networking software, and that the protocol messages sent between the client and server are complete and error-free.

The sync protocol is designed to enable any mobile client to efficiently synchronize PIM data with data stored on an Exchange server. To do this, the client uses the sync protocol to talk to the Exchange front-end server component, which provides the synchronization as the means to retrieve data from the Exchange store.

The following figure shows the functional components of the client and server communications model that is used by the sync protocol.

Exchange ActiveSync communication between client and server


The following steps occur for all commands that the client sends to the server:

  1. The client creates a request and sends it to the sync server as an HTTPS POST.

  2. The sync server processes the request, communicating with the Exchange back-end server to access the user's PIM data.

  3. The sync server creates a response and sends it to the client as an HTTPS POST response.

  4. The client processes the response and, if necessary, updates the local PIM data.

The following steps occur when the client sends a Sync command:

  1. The client identifies any changes made to local PIM data since the last sync.

  2. The client creates a Sync command containing these changes.

  3. The client sends the command to the sync server as an HTTPS POST.

  4. The sync server identifies changes made to data on the server since the last sync, communicating with the Exchange back-end server to access the user's data.

  5. The sync server resolves any conflicts between changes made to items on the client and on the server.

  6. The sync server creates a response containing server changes to be replicated on the client.

  7. The sync server sends the response as an HTTPS POST response.

  8. The client processes the response and updates the local PIM data.

Sync Protocol Versions and Device Support

Exchange ActiveSync requires that the client and the server use the same protocol version. Microsoft Mobile Information Server uses the ActiveSync Protocol v1.0 for Exchange ActiveSync. Exchange Server 2003 uses the new and improved ActiveSync protocol v2.0 for Exchange ActiveSync, but also supports ActiveSync protocol v1.0 for backward compatibility.

ActiveSync protocols supported by Mobile Information Server 2002 and Exchange Server 2003

Server Protocols Supported

Mobile Information Server 2002


Exchange Server 2003

1.0 and 2.0

The Pocket PC 2002 client uses ActiveSync protocol v1.0 for Exchange ActiveSync. It can be used against Mobile Information Server and Exchange Server 2003 using v1.0. The Pocket PC 2003 client supports v1.0 and v2.0 protocols. It can negotiate the protocol to be used.

Table 9.6   ActiveSync protocols supported by Pocket PC 2002 and Pocket PC 2003 devices

Device Protocols Supported

Pocket PC 2002


Pocket PC 2003

1.0 and 2.0

Therefore, Pocket PC 2002 and Pocket PC 2003 devices can be used against Mobile Information Server and Exchange 2003.

Sync Protocol Commands

With ActiveSync protocol v 1.0, a typical sync session includes the following commands:

  • GetHierarchy   This command is used to retrieve the entire hierarchy of folders.

  • **GetItemEstimate   **This command is used by the client to estimate the number of items that must be synchronized. The client passes a list of folders for which it wants an estimate. This estimate facilitates the progress bar display on the device.

  • Sync   This command is used to initiate a sync. The Sync command also has other commands embedded in it (such as Add and Change).

ActiveSync protocol version 2.0 adds support for two additional commands: Folder sync and AUTD (Always Up-To-Date):

  • Folder Sync   This command is used instead of the GetHierarchy command. The FolderSync command synchronizes the collection hierarchy just like individual folders are synchronized.

  • AUTD   This command enables the user to automatically synchronize the mobile device with the server as new items are received on the server. For more information, see the section "Up-to-Date Notifications" later in this topic.

Sync Command Format

Protocol commands are sent using the HTTP POST mechanism. Some simple commands are contained in the client request Unified Resource Identifier (URI), and more complex commands use the HTTP body to convey further information about the command.

A sync session is often made up multiple commands. In this case, the session will consist of multiple pairs of command requests and responses sent back and forth between the client and server.

There are three parts to a request:

  • URI   This part includes the server address and several parameters, including the command name.

  • HTTP Header   This part includes additional parameters that are used by the server and are transmitted in standard HTTP format.

  • HTTP Body   This part includes data required by the command. The format varies by command, and some commands have no body.


The following example shows a typical sync request URI:

POST /Microsoft-Server-ActiveSync?User=johndoe&

The parameters such as Cmd, User, and DeviceId are sent by the client with each request. The most important parameter is the Cmd parameter. The Cmd parameter indicates to the server what operation it must perform. In this example, the Sync argument passed in the Cmd parameter indicates to the server that a sync operation must be performed. Additional data is contained in the HTTP POST body.

HTTP Header

In addition to the URI, the client also sends some general information in the HTTP header. The following example shows the entire HTTP POST request header, together with the URI:

POST Microsoft-Server-ActiveSync?User=johndoe&
Accept-Language: en-us
MS-ASProtocolVersion: 2.0
Content-Type: application/

The server responds with some general information in the header. The following entry contains the HTTP POST response header:

HTTP/1.1 200 OK
Content-Length: 114
Date: Mon, 15 Mar 2004 11:07:44 GMT
Content-Type: application/
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Pragma: no-cache
MS-Server-ActiveSync: 2.0.3273.0


The request body contains data sent to the server. The type and format of the data varies by command. The most common format is XML, and the details depend on the command. Commands that send e-mail messages use RFC 822 format, instead of XML. Some commands do not require extra data. In that case, the body is empty.

The response body contains data returned from the server. As with the request body, the format varies by command. Typically, it is in WbXML format. When the body contains an e-mail attachment, the format depends on the type of the attachment file. Some commands do not use the body.

Protocol-Independent Multicast Data on the Mobile Device

Protocol-independent multicast data is stored in "collections," one for contacts, one for calendar, and one for each e-mail folder. The sync protocol supports syncing multiple e-mail folders. For each collection, the client software stores a SyncKey. The SyncKey contains 39 to 48 characters, 38 for the globally unique identifier (GUID), and one to ten for the incrementing number. The client also stores a CollectionId. The CollectionId is a string of around 40 characters for each folder that is a unique identifier for the folder.

The client sends the SyncKey to the server with each synchronization request. Each object that is synchronized—whether a message, contact, or calendar item—has a unique identifier assigned by the server. This ServerId is a 48-character string that is stored by the client. The identifier is used during synchronization to identify objects that are stored on both the client and server.

Exchange ActiveSync Profile

The synchronization state is stored in a hidden folder in the user's mailbox on the Exchange server. The synchronization state for e-mail, calendar, and contacts, and FolderSync is located in the Microsoft-Server-ActiveSync/PocketPC/DeviceId folder in the NON_IPM_SUBTREE of a user's mailbox. The Search folder containing the folder hierarchy is also stored here.

Up-to-Date Notification

Exchange ActiveSync is configured on the device to synchronize with the server at intervals, as frequently as every five minutes. However, ActiveSync does not provide up-to-date information about the device. The user can also incur additional charges because of the frequent sync sessions.

Up-to-Date Notification is a new feature in Exchange Server 2003 that enables the user to automatically synchronize a pocket PC 2003 or a Microsoft Windows Mobile 2003 device with the server when new items are received on the server. Up-to-date notification is a feature of Exchange ActiveSync that is installed with Exchange Server 2003.

An event is generated in a user's Exchange account when a new message arrives. This event causes a Short Message Service (SMS) notification to be sent to the user's device. The device synchronizes in the background. The user data is updated to the most current information, with no intervention on the part of the user.

The notification is sent as an SMS control message to the device. It is different from a regular SMS notification, because it does not appear as an SMS message in the Inbox. The SMS router and Exchange ActiveSync on the device process the notification. The notification itself does not carry any sensitive data.

Notifications can be sent from Exchange Server 2003 directly to the SMS address of the device, or through an aggregator (for example, a corporate service provider) configured by the Exchange administrator. For notifications to be sent to the SMS address of the device, the administrator must create an SMTP carrier in Exchange System Manager.


Organizations can choose to send notifications to devices through an aggregator. The only aggregator currently available is MSN Internet Access. To establish an aggregator, the organization must log on to a secure Web site using a Passport account and select the carriers it wants to use through MSN. The organization can then obtain credentials from MSN for secure notification delivery.

Next, the MSN carrier must be created in Active Directory. A separate file, is provided. The zip file contains CreateMSNCarrier.cmd and CarrierConfig.LDF, which are used to set up the MSN carrier.

After the MSN carrier is created in Active Directory, the administrator creates an SMTP connector for secure notification delivery to MSN, using the credentials received when a user signs up. When an administrator configures an SMTP carrier to send notifications directly to the SMS address of the device, the notification goes through the SMTP gateway at the mobile operator and then to the operator's SMS Center (SMS-C). Operator SMTP gateways are frequently associated with high message latencies and SMS delivery times are sometimes greater than an hour. This negates the advantages of up-to-date notifications and does not provide an up-to-date experience for the user.

There are also security issues with forwarding messages through an SMTP gateway operator. You can use an aggregator to connect through Transport Layer Security to Microsoft Mobile Services. This enables an enterprise to connect to one or more of the operators with which Microsoft Mobile Services has created up-to-date partnerships.