Article ID: 899919 - View products that this article applies to.
This article describes a change in how Microsoft Office Outlook 2003 Service Pack 2 (SP2) and later service packs, Microsoft Exchange Server 2003 Service Pack 2 (SP2), and later versions of Exchange Server and of Outlook handle meetings. This new design addresses disappearing-meeting scenarios that were introduced by Outlook 2003 in cached mode.
The new design does not have a visible effect on end-users. However, the new design can affect custom solutions that integrate with the calendar features in Outlook. This article describes the new design so that developers of custom solutions can update those solutions if it is required.
The new design works as follows. When a user accepts or tentatively accepts a meeting, either from a meeting request or from a calendar item, the existing calendar item is deleted from the calendar. Additionally, a duplicate of the calendar item is created for the deleted item. Therefore, the new calendar item has an Entry ID that differs from the Entry ID of the old calendar item.
Custom solutions may be adversely affected if they are designed in a way that presumes that an Entry ID for a calendar item remains consistent or changes only rarely.
By default, this new meeting acceptance behavior is enabled in Outlook 2003 SP2 and later. However, the behavior can be disabled or re-enabled by using the following registry data on the Outlook client:
Key: HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Options\CalendarNote Without this registry data, Outlook 2003 uses the default SP2 or later service pack behavior.
Values: 1 = revert to the pre-SP2 behavior; 0 = use the new SP2 behavior
In Outlook 2007, this registry key is available in the Office deployment tools. For more information, view the deployment documentation. To do this, visit the following Microsoft Web site:
Background on MAPI-based Entry IDsWhen Outlook saves an item in a folder, the item is assigned an Entry ID value by the store in which the item resides. Examples of stores are a Microsoft Exchange Server mailbox, the Exchange Server public folder store, and a personal folders (.pst) file.
Entry IDs are guaranteed to be unique within a store. However, Entry IDs can change under certain scenarios. These scenarios include when an item is moved to a different folder or to a different store. Entry IDs can also change when a user performs certain functions in Outlook. These functions include exporting and then reimporting data. The new approach to processing calendar items in Outlook 2003 SP2 and later service packs and in Exchange Server 2003 SP2 is another example of when an Entry ID can change.
For more information about Entry IDs, visit the following MSDN Web site:
http://msdn2.microsoft.com/en-us/library/ms531268.aspxThere are various APIs that support working with Entry IDs. These APIs include Extended MAPI, the CDO 1.21 object library, and the Outlook object library.
How this new design may affect solutionsSome solutions that integrate with Outlook keep track of Outlook data in an external database. Other solutions may use custom Outlook forms to store the Entry ID of one item as a field on another item to provide linking functionality. In these scenarios, you can use approaches such as the GetItemFromID method in the Outlook object library to directly access an item based on its Entry ID.
However, using an Entry ID to locate an item may become unreliable after SP2 or a later service pack is installed. Therefore, you have the following options:
Global Object IDThe Global Object ID is a MAPI property that Outlook uses to match meeting updates and responses with a particular meeting on the calendar. The Global Object ID is the same across all copies of the calendar item. In Microsoft Office Outlook 2003 Service Pack 1 (SP1) and earlier versions, the Global Object ID is generated when an organizer first sends a meeting request. Therefore, these earlier versions of Outlook do not generate a Global Object ID for unsent meetings or for appointments that have no recipients.
In Outlook 2003 SP2 or in later versions of Office, the Global Object ID is generated when a user first saves a calendar item, regardless of whether it is sent. Therefore, starting with Outlook 2003 SP2 or a later service pack, all appointments will have a Global Object ID, regardless of whether they are meetings to which other users have been invited.
To access the Global Object ID programmatically, use the following information.
The Outlook object library has not been updated to expose this property. The following samples are code samples that illustrate how to access the Global Object ID on an appointment item by using the CDO 1.21 object library or Extended MAPI (requires C++).
Specifics about the CDO 1.21 object libraryThe CDO 1.21 object library was updated to process appointments based on this new design. The design change is included in the server-side CDO.DLL that is included with Exchange Server 2003 SP2. The client-side version of CDO.DLL is installed by Outlook or by Microsoft Office. The first client-side version to include this change is the CDO.DLL that is installed by Microsoft Office 2003 SP2.
Specifics about the CDOEX object libraryThe CDOEX object library was updated to process new appointments based on this new design. CDOEX can be used only on an Exchange server. Additionally, the updated CDOEX.DLL is included in Exchange Server 2003 SP2.
Specifics about the Outlook object libraryThe Outlook object library provides the new functionality, starting with Office Outlook 2003 SP2 or later. This change is also included in later versions of Outlook.
Specifics about Extended MAPIAlthough you can access Entry IDs by using Extended MAPI, using Extended MAPI to work with appointments is not supported. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/266353/ )Outlook named properties are not supported by MAPI or CDO
Article ID: 899919 - Last Review: September 3, 2013 - Revision: 8.0