Monday, October 10, 2011

Exchange 2010 Calendar Repair Assistant Behaviour (Part 2)


In my previous post Exchange 2010 Calendar Repair Assistant Behaviour I discussed some of the behaviour of the new Calendar Repair Assistant [CRA] functionality of Exchange 2010. Namely, I mentioned the following issue:

“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”...


What I forgot to mentioned is that this happened with Outlook 2007. When I tested the exact same scenario with Outlook 2010 and OWA 2010, this didn’t happen! Which means that the assistant does indeed check if the attendee deleted the appointment on purpose or not.   :)

So why does it work for Outlook 2010 and OWA 2010 but not for Outlook 2007? We all know Outlook 2010 has better integration with Exchange 2010, but I wanted to know. To try to find out why, I turned to MFCMapi and compared two appointments: one deleted in Outlook 2007 and one deleted in OWA 2010 (both without sending a notification to the organiser).

Besides some obvious differences in some properties such as subject, times, etc., here is the big difference (look at the value tags):


Outlook 2007
<property tag = "0x80630003" type = "PT_LONG">
      <ExactNames>0x80630003</ExactNames>
      <NamedPropGUID>{11000E07-B51B-40D6-AF21-CAA85EDAB1D0} = PSETID_CalendarAssistant</NamedPropGUID>
      <NamedPropName>id: 0x0015=21 = PidLidClientIntent, dispidClientIntent</NamedPropName>
      <Value>0</Value>
      <AltValue>0x0</AltValue>
</property>



OWA 2010
<property tag = "0x80630003" type = "PT_LONG">
      <ExactNames>0x80630003</ExactNames>
      <NamedPropGUID>{11000E07-B51B-40D6-AF21-CAA85EDAB1D0} = PSETID_CalendarAssistant</NamedPropGUID>
      <NamedPropName>id: 0x0015=21 = PidLidClientIntent, dispidClientIntent</NamedPropName>
      <Value>32</Value>
      <AltValue>0x20</AltValue>
</property>



The PidLidClientIntent property indicates what actions the user has taken on a Meeting object.

According to the MSDN website 2.2.2.4 PidLidClientIntentProperty a value of 0x20 (32 in decimal or 0010 0000 in binary) means that the ciDeletedWithNoResponse property is set which proves the user deleted the Meeting object with no response sent to the organiser.


So basically, OWA 2010 and Outlook 2010 set the PidLidClientIntent property correctly and, as such, the CRA knows that the user deleted the appointment on purpose and doesn’t put it back.
Because Outlook 2007 doesn’t set this property to 0x20, CRA doesn’t know the user deleted the appointment, thinks it’s missing for some other reason and puts it back in the calendar!

Now the question: is there or will there be an update to rectify this for Outlook 2007?


I’m running version 12.0.6550.5003 SP2 with the update KB2412171 to have access to my Exchange Archive.

For more information:

No comments:

Post a Comment