Understanding Calendar Repair

  • Article

The Calendar Repair Assistant (CRA) is a configurable, time-based mailbox assistant that runs within the Microsoft Exchange Mailbox Assistants service on servers running Microsoft Exchange Server 2010 with the Mailbox server role installed. CRA automatically detects and corrects inconsistencies that occur for single and recurring meeting items for mailboxes homed on that Mailbox server so that recipients won't miss meeting announcements or have unreliable meeting information.

For more information about configuring CRA, see Managing Calendar Repair.

Conflict Detection and Correction

CRA uses the organizer copy as a master copy for all meeting items, and it assumes that the organizer's calendar item is the correct copy. CRA then compares the attendee's calendar item with the organizer's calendar item for inconsistencies. The only exception to this rule is when CRA compares the attendee and organizer response status. In that case, CRA assumes that the attendee's response status is the correct one, and updates the organizer's tracking information. CRA corrects inconsistencies by sending special repair update messages to the mailbox of either the attendee or the organizer.

CRA corrects inconsistencies on the server on which it runs. However, CRA will read from other Exchange 2010 Mailbox servers to compare the organizer's calendar item. CRA doesn't overwrite the recipient's calendar information; it merges the information so that no data is lost. In addition, the repair update messages are moved to the recipient's Deleted Items folder.

CRA detects and corrects the following issues:

  • Attendee's calendar item has the wrong time   The organizer and the attendees have different times or dates for the meeting. CRA changes the meeting time on the attendees' calendar items to the time that's on the organizer's calendar item.

  • Attendee's calendar item has the wrong location   The organizer and the attendees have different locations for the meeting. CRA corrects and merges the location information on the attendees' calendar items to the location that's on the organizer's calendar item.

  • Attendee's calendar item is missing   CRA detects that some attendees have responded to the organizer's meeting request with Accept or Tentative and the item is no longer on the attendee's calendar. CRA will re-create the meeting in the attendees' calendars with the response status on the organizer's calendar item.

  • Attendee's calendar item tracking status doesn't match the organizer's tracking status   CRA detects that attendees' response status for the meeting doesn't match the status on the organizer's calendar item. In this case, the organizer's tracking status is updated with the status on the attendee's calendar item.

  • Attendee isn't on the organizer's attendees list   CRA detects that attendees have the meeting on their calendars, but the organizer doesn't have those attendees listed in the attendee list. CRA adds the attendees to the organizer's list of attendees.

    Note

    CRA won't add the attendees to the organizer's list of attendees from meetings sent to large distribution groups with more than 200 members.

  • Attendee's recurring meeting doesn't match the organizer's recurring meeting   CRA detects that the attendee is on some of the organizer's recurring meetings and the attendee's recurrence pattern doesn't match the organizer's recurrence pattern. CRA replaces the attendee's recurrence pattern with the organizer's recurrence pattern.

  • Organizer or attendees have multiple calendar meetings that appear the same   CRA detects that the organizer or attendee has multiple meetings that have the same MAPI property identifier LIL_GLOBAL_OBJID. CRA compares all of the duplicates and performs the following steps to correct the inconsistency:

    1. CRA checks the sequence numbers of all of the duplicates. If one duplicate has the highest sequence number, that duplicate is kept, and the other meetings are deleted.
    2. If CRA couldn't determine which item to keep based upon the sequence number, it checks the OwnerCriticalChangeTime property. If one of the duplicates is the most recent copy, it keeps that duplicate item, and the other meeting items are deleted.
    3. If CRA couldn't determine which item to keep based upon the most recent copy, it checks the LastModifiedTime property. If one of the duplicates has the last modified time, CRA keeps that duplicate item, and the other meeting items are deleted.
    4. If CRA couldn't determine which item to keep based upon the last modified time, it keeps the first calendar item returned by the database when querying for duplicate meetings, and the other items are deleted.

  • Organizer's calendar item is missing   CRA detects that the attendee has a meeting on his or her calendar but the organizer doesn't have the meeting item any more. CRA marks the attendee's meeting as Cancelled and the attendee's free/busy status is now Free.

Calendar Repair Log

Every time CRA changes a calendar item on a user's mailbox, it writes to a log file. The output of the log file doesn't reveal personal data, such as the body of the message or attachments. The log only contains the minimum information to identify the meeting that was repaired and what repair actions happened to the meeting. One repair log is created for every mailbox each time CRA runs. By default, calendar repair logging is enabled.

The calendar repair log is configurable for a server and can be turned on or off for a server or user. For more information, see Managing Calendar Repair.

The default calendar repair log path is <Exchange Installation Path>\v14\Logging\Calendar Repair Assistant.

The log files are created with the following naming convention:

CRAYYYYMMDDHH-X.<alias>.log

  • CRA   CRA prefix
  • YYYY   Year
  • MM   Month
  • DD   Day
  • HH   Hour
  • X   Instance
  • Alias   Mailbox alias
  • Log   File extension

For example, consider the following repair log:

CRA2010041815-3.tony.log

That log name indicates that a repair was made on a mailbox with the alias Tony on April 18, 2010, at 15:00 (3:00 P.M.), and that the repair was the third one made within that hour.