Calendaring Changes in CDO 1.2.1
In versions of Microsoft Exchange Server 2003 earlier than Exchange Server 2003 Service Pack 2 (SP2), the actions taken by the computer that is running Exchange 2003 and Microsoft Office Outlook 2003 in cached mode sometimes cause calendar items to be unexpectedly deleted. This occurs most frequently when a user uses multiple cached-mode e-mail clients to access a mailbox. Accepted meetings are sometimes deleted from the calendars of users who are running Outlook 2003 in cached mode on multiple computers, or users who are running a combination of cached-mode Outlook 2003, Outlook Mobile, custom clients, or mobile devices that are using Exchange ActiveSync.
This problem occurs when the Exchange server and the client try to reconcile changes that were 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 2003 earlier than Exchange 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 keeps the copy and delete operations so that the other clients can correctly synchronize. When those other clients reconnect to the Exchange server and try 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 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 correctly 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 that affect only the message body or meeting location, but not the acceptance status, do not affect the Entry ID.
The uid Field specifies the Calendar ID property.
This change is included in the Exchange 2003 SP2 version of CDO 1.2.1. If your application uses another API to process meeting requests, make sure that you thoroughly test your code to ensure that it correctly 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 occurs.
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 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 using a registry entry. If the registry keys do not exist, the new behavior will be in effect.
The following registry key is used by the client-side version of CDO 1.2.1 that is installed by Outlook:
The value 0 enables the new behavior for CDO 1.2.1.