Calendar invites are not delivering to inbox, but show up as tentative in calendar after migration from Exchange 2010 to Exchange 2013.
I work in on-premises support for Microsoft Exchange, and had a peculiar issue come up recently. To be honest, I've been wrestling with the idea of blogging about this or not, mostly because I don't have a root cause and I am unable to reproduce it. However, I decided I might as well share what I learned from this issue, and how to fix it, so that it may help others in the future.
Environment:
- Exchange 2010 SP3 RU6 migrating users to Exchange 2013 CU6 (Note it may affect other versions)
- A large number of Outlook for Mac users
Problem:
- User, who is only a Mac Outlook 2011 user, is migrated to Exchange 2013.
- After which, when a calendar meeting invite is received, the meeting is added to the calendar as tentative, but no message is received in the Inbox for the user to Accept/Decline/Tentatively accept it.
- The same behavior occurs whether or not OWA or Outlook for PC is used when receiving the calendar meeting invite.
- The same behavior occurs with meeting invites sent from any source.
- There were no commonalities between the affected mailboxes, other than they all used Mac Outlook 2011 prior to being migrated (Different target/destination DBs/Servers)
Workaround:
We discovered that recreating the user's mailbox resolved the issue. This, of course, is rather destructive, time consuming, and causes major interruptions for the end user.
So first, I thought - OK maybe this person previously used Outlook for Windows, and setup a Delegate, configuring calendar meeting requests to be sent to delegates only:
But, the customer was able to configure a Windows profile and confirmed, this was not set.
The second thing I suspected was CalendarProcessing (Get-CalendarProcessing <User> | fl):
https://technet.microsoft.com/en-us/library/dd298137(v=exchg.150).aspx
However, after inspecting the results, it was found that the user had the same settings as everyone else in the company, including unaffected users.
I then had the customer grab the EventHistory table for the affected mailbox. For more information on utilizing and accessing the EventHistory table for mailboxes and databases, a great read is here:
The EventHistory table essentially lets you see exactly what is changing (what events occur) within a mailbox or database. In this case, we wanted to trace what was happening to a calendar meeting invite when received by the mailbox, and whether something was deleting it, moving it, etc.
After capturing the EventHistory table, we were able to locate the invite, and it's ParentEntryId. According to the blog above, the ParentEntryId is the folder which the item is current in. Great!
We went into MFCMapi (https://mfcmapi.codeplex.com/), and were able to use the ParentEntryid to figure out where the messages were going!
So, it turned out, the messages were going to…the Schedule folder. Huh?
The Schedule folder is a folder within the mailbox, located on the root (so hidden from Outlook and other clients). It is typically a folder used for Free/Busy information - but is not intended to have mail delivered to it. Why were we delivering to this folder?
I then had the customer collect an Extra trace. For those of you who are unaware, an Extra trace is a tool support uses to see what the code is doing at a very high level. Think of it as - reading the comments in code - they give you an idea of what is happening, but not necessarily why.
But in this case, the Extra gave me gold. When the message was dropped off to the mailbox by Store Driver I could see the following:
"overridden by receive-folder table: True"
In my lab, and with other calendar meeting invites sent to unaffected users in the Customer's environment, I always saw:
"overridden by receive-folder table: False"
In the mailbox, there is a table, called the Receive Folder Table, which is exactly that - a table of message classes, and the folders that they should be delivered to. 3rd party software developers can tap into this, so that custom message types that a user doesn't need to see, can be delivered and picked up by their software (https://msdn.microsoft.com/en-us/library/office/cc815405.aspx). You can see this table in MFCMapi:
And Bingo - there was the IPM.SCHEDULE.MEETING class association:
So, to remove the association in MFCMapi:
Then:
After doing this, the user was finally getting calendar meeting invites delivered to their Inbox.
Unfortunately, the customer had no more mailboxes in Exchange 2010 to try and reproduce the issue - and I was unable to reproduce the issue in a lab environment no matter how many times I tried. A quick search found only one other reported incident, and they simply used a script to remove the association - No root cause was found in that case either.
So in the end - we have a solution, other than recreating the mailbox, however no actual root cause. All I know is that it appears to only occur to Mac Outlook 2011 users when migrating from Exchange 2010 to Exchange 2013. Hopefully this blog post will be useful to someone facing this issue in the future!
Thanks to Sainath Vijayaraghavan for reviewing this for me!
Comments
- Anonymous
October 02, 2015
Awesome! Had the exact same issue with a customers mailbox that was recently migrated to Exchange 2013. I disassociated the IPM.SCHEDULE.MEETING form from the Schedule folder and now meeting requests are appearing in her Inbox once again. This was exactly what I was looking for. - Anonymous
November 06, 2015
This is the exact thing we're facing... you mentioned above " A quick search found only one other reported incident, and they simply used a script to remove the association".... Do you have any reference or suggestions on where to begin with the script? we have 70k plus mailboxes and have been getting more and more reports of this. I'd like to run a script to check all of the mailboxes to be proactive in resolving this. - Anonymous
November 18, 2015
Excellent troubleshooting! This solved my issue as well.