Exchange 2010 Calendar Repair Assistant Behaviour

After enabling the new Calendar Repair Assistant (CRA) in Exchange 2010, I got a complaint from a user saying items were being re-created on her calendar.

After some troubleshooting and a few tests, I realised that when a user accepts a meeting request and later on deletes it without sending an update, Exchange will put it back in the calendar. This is by design and as expected. According to Understanding Calendar Repair, one of the conflicts the CRA fixes is:

“An attendee accepted the organizer's meeting request or recurring meeting request, but the meeting isn't on the attendee's calendar.

The assistant checks the attendee's record in the mailbox database and finds that the attendee deleted the calendar item without sending a response. If the assistant can't determine that the meeting item was intentionally deleted by the attendee, the assistant creates the meeting request again. If the assistant determines that the attendee intentionally deleted the meeting request, no further action is taken.”

Note that is says “The assistant checks the attendee's record in the mailbox database and finds that the attendee deleted the calendar item without sending a response”. However, in all my tests, I deleted the appointments after accepting them, and Exchange always puts them back... So, not sure how it detects if the appointment was “intentionally deleted by the attendee”...


Update: Please check Part 2 regarding this issue!

After I deleted the appointment test03 – delete future recur meeting, Exchange put it back in my calendar the following day (I have CRA scheduled to run every night for all servers and users) and I received the following e-mail:

If we have a look at the CRA log for this instance:

<Meeting Subject="test03 - delete future recur meeting" MeetingType="Occurrence" StartTime="09/21/2011 15:00:00" EndTime="09/21/2011 15:30:00" Organizer="mizan.khan@parliament.uk">

      <InternetMessageId>&lt;63EB2801FB9F52428B3363279474E765A2FCF2@MMEM011.parliament.uk&gt;</InternetMessageId>

      <GlobalObjectId>040000008200E00074C5B7101A82E00807DB091520B3C92CAF77CC01000000000000000010000000547C7BEC0F87214789D7CF8FB5727D96</GlobalObjectId>

      <CleanGlobalObjectId>040000008200E00074C5B7101A82E0080000000020B3C92CAF77CC01000000000000000010000000547C7BEC0F87214789D7CF8FB5727D96</CleanGlobalObjectId>

      <OwnerAppointmentId>-189491237</OwnerAppointmentId>

      <Attendees>

        <Attendee EmailAddress="motan@parliament.uk">

          <ConsistencyChecks>

            <ConsistencyCheck Type="CanValidateOwnerCheck" Result="Passed">

              <Description>Checks whether the counterpart user can be validated or not.</Description>

            </ConsistencyCheck>

            <ConsistencyCheck Type="ValidateStoreObjectCheck" Result="Passed">

              <Description>Calls Validate() on the base calendar item.</Description>

            </ConsistencyCheck>

            <ConsistencyCheck Type="MeetingExistenceCheck" Result="Failed">

              <Description>Checkes whether the item can be found in the owner's calendar or not.</Description>

              <Inconsistencies>

                <Inconsistency Owner="Attendee" ShouldFix="True" Flag="MissingItem">

                  <Description>Could not find the matching meeting in attendee's calendar. Error: [21/09/2011 05:00:51(UTC)] FindMatchingItem: Could not find calendar item, exception = Microsoft.Exchange.Data.Storage.OccurrenceNotFoundException. </Description>

                </Inconsistency>

              </Inconsistencies>

            </ConsistencyCheck>

          </ConsistencyChecks>

          <RUMs>

            <RUM IsOccurrence="False" Type="Update" Sent="True" Time="09/21/2011 05:00:51">

              <Flags>

                <Flag>MissingItem</Flag>

              </Flags>

            </RUM>

          </RUMs>

        </Attendee>

      </Attendees>

</Meeting>

We can see all the tests CRA performs in between <ConsistencyChecks> and what it checks for (I have included some more that weren’t part of this check but that CRA normally checks as well):

• CanValidateOwnerCheck - Checks whether the counterpart user can be validated or not;
• ValidateStoreObjectCheck - Calls Validate() on the base calendar item;
• MeetingExistenceCheck - Checke whether the item can be found in the owner's calendar or not;
• MeetingCancellationCheck - Checks to make sure that the meeting cancellations statuses match;
• TimeZoneMatchCheck - Checks to make sure that the attendee has correct recurring time zone information with the organizer;
• MeetingPropertiesMatchCheck - Checks to make sure that the attendee has the correct critical properties for the meeting;
• RecurrenceBlobsConsistentCheck - Checks to make sure that the recurrence blobs are internally consistent;
• RecurrencesMatchCheck - Checks to make sure that the attendee has the correct recurrence pattern.

From the <Inconsistencies> section, we can see why Exchange put it back in my calendar:

<Inconsistency Owner="Attendee" ShouldFix="True" Flag="MissingItem">

    <Description>Could not find the matching meeting in attendee's calendar. Error: [21/09/2011 05:00:51(UTC)] FindMatchingItem: Could not find calendar item, exception = Microsoft.Exchange.Data.Storage.OccurrenceNotFoundException. </Description>

</Inconsistency>

Basically Exchange detected the meeting in the organizer’s calendar and that I had previously accepted it but it wasn’t in my calendar (because I deleted it without sending a notification)!

If, however, I had rejected it afterwards (or deleted and sent a notification) the organizer would have received a cancellation from me and Exchange wouldn’t check my calendar for that meeting.

To summarise, when a user receives an appointment and:

• rejects it – Exchange doesn’t put it back;
• accepts it, later on declines it - Exchange doesn’t put it back;
• accepts it, later on deletes it and sends an update - Exchange doesn’t put it back;
• accepts it, later on deletes it and doesn’t send an update - Exchange puts it back.

Update: Please check Part 2 regarding this last issue!

Hope this helps!