Outlook: Disabling Meeting Regeneration is not recommended as it may cause problems with your calendar

Source: Microsoft Support

RAPID PUBLISHING ARTICLES PROVIDE INFORMATION DIRECTLY FROM WITHIN THE MICROSOFT SUPPORT ORGANIZATION. THE INFORMATION CONTAINED HEREIN IS CREATED IN RESPONSE TO EMERGING OR UNIQUE TOPICS, OR IS INTENDED SUPPLEMENT OTHER KNOWLEDGE BASE INFORMATION.

Outlook 2003 Service Pack 2 (SP2), Exchange 2003 SP2, and Collaboration Data Objects (CDO) introduced a new architecture for the method Outlook, Exchange, and CDO use to save meetings on your calendar. This change in the architecture of the calendar feature was introduced to make calendaring more reliable when you respond to meetings from multiple clients (for example, when you and a delegate respond to the same meeting).

Under this new architecture, unexpected meeting deletions do not occur when one client accepts a meeting and another client deletes the same meeting (or meeting request). When the conflicting changes are eventually resolved by all clients and the Exchange server, the meeting acceptance wins the conflict and the meeting remains on your calendar.

This new architecture uses a process called Meeting Regeneration that works as follows:

• When you accept or tentatively accept a meeting, either from a meeting request or from a calendar item, the existing calendar item is silently 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.

This meeting regeneration process can be disabled on the Outlook client, on the Exchange server, or on a computer using a solution based on CDO. However, Microsoft does not recommend disabling the meeting regeneration process because:

• It is intended to improve calendar reliability in Outlook and Exchange.
• Without it, you increase the likelihood of meetings being inadvertently removed from your Calendar folder.
• Without it, you might break some 3rd party solutions that are were updated to work specifically with the meeting regeneration code.

The ability to disable meeting regeneration was originally documented to allow third-party vendors time to update their software to work with the new calendar architecture and that meeting regeneration would be enabled as quickly as possible. It was not documented as a permanent fix or workaround for issues caused by third party software.

Note Because Microsoft may remove the ability to disable meeting regeneration in future versions of Outlook, developers of third-party applications should not rely on the ability to disable meeting regeneration for their products to function properly.

Prior to the introduction of the meeting regeneration architecture, one of the most common deleted calendar item scenarios was when one or both of a manager/delegate pair are in cached mode and one of them is working offline. If the meeting invite is deleted offline (and consequently the tentative calendar item), then this deletion will override an acceptance by the delegate. Here are the steps you can take to see the original deletion process that spawned the new calendar deletion architecture.

1. Manager in cached mode, delegate in online or cached mode.
2. Delegate and manager are both configured to receive meeting invites for manager.
3. Manager is not currently connected.
4. Another user (meeting organizer) ser invites the manager to a meeting.
5. Delegate receives invite and opens the meeting.
6. Delegate closes invite without taking any action. At this point, the meeting is now tentative on the manager�s Calendar.
7. Manager now connects and synchronizes their mailbox. The manager now has the meeting invite in their Inbox and the tentative meeting on their Calendar.
8. Manager goes back offline and works with the data in the .ost file.
9. Manager deletes the invite from their Inbox. This action results in the meeting being deleted from the Calendar (still only in the .ost file because they are working offline now).
10. Delegate reopens the invite and accepts the meeting on behalf of the manager. The meeting is now in the manager�s server copy of the Calendar as Accepted.
11. Manager goes back online and synchronizes their mailbox.
    
    It is at this point that the deletion in the .ost file (step 9) takes precedence over the accepted meeting sitting in the Calendar folder on the server.
    
    When you are not utilizing the meeting regeneration architecture there are other scenarios, with and without a delegate, where this problem can occur, including the use of OWA. The key things to remember is that in this scenario (where meeting regeneration is disabled):
    • The meeting is in a tentative state in your mailbox.
    • You work offline and delete the invite from the Inbox which deletes the tentative meeting from the Calendar in the local .ost file.
    • You Accept or Tentatively Accept the meeting using a different client.
    • You then synchronize your .ost file with your mailbox.

When this occurs Exchange and Outlook resolve the difference by deleting the meeting.

For additional information on the meeting regeneration process, please see the following article in the Microsoft Knowledge Base.

899919 Developer information about the calendar changes in Outlook 2003 Service Pack 2, in Exchange Server 2003 Service Pack 2, and in later versions of Exchange Server and of Outlook

The above article is the original article written when this meeting regeneration architecture was first introduced in Outlook, Exchange Server and CDO.

MICROSOFT AND/OR ITS SUPPLIERS MAKE NO REPRESENTATIONS OR WARRANTIES ABOUT THE SUITABILITY, RELIABILITY OR ACCURACY OF THE INFORMATION CONTAINED IN THE DOCUMENTS AND RELATED GRAPHICS PUBLISHED ON THIS WEBSITE (THE �MATERIALS�) FOR ANY PURPOSE. THE MATERIALS MAY INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS AND MAY BE REVISED AT ANY TIME WITHOUT NOTICE.

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, MICROSOFT AND/OR ITS SUPPLIERS DISCLAIM AND EXCLUDE ALL REPRESENTATIONS, WARRANTIES, AND CONDITIONS WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING BUT NOT LIMITED TO REPRESENTATIONS, WARRANTIES, OR CONDITIONS OF TITLE, NON INFRINGEMENT, SATISFACTORY CONDITION OR QUALITY, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THE MATERIALS.