CDOEX Calendaring Differences Between Exchange 2003 and Exchange 2003 SP2

CDOEX Calendaring Differences Between Exchange 2003 and Exchange 2003 SP2

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

In versions of Exchange Server 2003 earlier than Exchange Server 2003 SP2, the actions taken by the Exchange server and Outlook 2003 in cached mode sometimes cause calendar items to be unexpectedly deleted. This occurs most often when a user uses multiple cached-mode e-mail clients to access a mailbox. Accepted meetings are sometimes deleted from the calendars of users running Outlook 2003 in cached mode on multiple computers, or users running a mixture of cached-mode Outlook 2003, Outlook Mobile, custom clients, or mobile devices using Exchange Server ActiveSync.

This problem occurs when the Exchange server and the client attempt to reconcile changes made to the locally stored copy of the initial meeting request. When multiple cached-mode clients are used to access a single mailbox, local copies of the content are stored on each client.

In versions of Exchange Server 2003 earlier than Exchange Server 2003 SP2, when a user accepts a calendar item, the item is copied into the user's Calendar folder, and then the original item is deleted from the Inbox folder. The Exchange server and the client use the Entry ID property to identify the item. If the meeting is accepted while another e-mail client is offline, the Exchange server retains the copy and delete operations so that the other clients can properly synchronize. When those other clients reconnect to the Exchange server and attempt to synchronize the user's mailbox on the device, the system first adds the item to the user's Calendar folder, and then deletes the item. However, because both the original request (stored in the locally cached Inbox folder) and the accepted calendar item (newly added to the locally cached Calendar folder) have the same Entry ID property, the Exchange server and the client delete both items. When the original client synchronizes again, it also deletes the item from the Calendar folder.

To solve this multiple-cache synchronization problem, Exchange Server 2003 SP2 now creates a new Entry ID value when the item is accepted, tentatively accepted, or declined. The new Entry ID value is assigned regardless of where the item is stored when the action is taken. Because all the items keep the same Calendar ID property, other actions taken on the item are properly synchronized by the other clients. The original meeting request does not receive a new Entry ID value. A new Entry ID value is only applied when the action sets the acceptance status of the item. Updates to other parts of the item do not generate a new Entry ID. For example, updates affecting only the message body or meeting location, but not the acceptance status, do not affect the Entry ID.

This change is included in the Exchange Server 2003 SP2 version of CDOEX, CDO 1.2.1, and the ExOLEDB provider. If your application uses another API to process meeting requests, be sure to thoroughly test your code to ensure that it properly handles or duplicates the new behavior. If your application does not provide the copied item with a different Entry ID value, you might experience the deletion of calendar items when cached-mode synchronization takes place.

If your application code uses the Entry ID from the original meeting request item to locate calendar items after they are processed, the application might be unable to locate that item in the Calendar folder, because the Entry ID is now different. When your application is running on Exchange Server 2003 SP2, the application code must use the Calendar ID property to locate the item, because processing the item does not change the Calendar ID.

If your application cannot be updated to locate calendar items by using the Calendar ID property, you can disable the new functionality by means of a registry entry. If the registry keys do not exist, the new behavior will be in effect.

The versions of CDOEX and Microsoft Office Outlook® Web Access that are installed by Exchange Server 2003 SP2 use a different pair of registry keys. If the registry keys do not exist the new behavior will be in effect.

The following server-side registry key is used by CDOEX and Outlook Web Access:

HKEY_LOCAL_MACHINE\Software\Microsoft\EXCDO\Parameters

The DWORD value name for CDOEX and Outlook Web Access is CDOCloneOnAccept. Setting this value to zero (0) disables the new behavior.

Send us your feedback about the Microsoft Exchange Server 2003 SDK.

This topic last updated: July 2006

Build: June 2007 (2007.618.1)

© 2003-2006 Microsoft Corporation. All rights reserved. Terms of use.