- 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.
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 (http://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.
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
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
can see this table in MFCMapi:
And Bingo – there was the IPM.SCHEDULE.MEETING class association:
So, to remove the association in MFCMapi:
After doing this, the user was finally getting calendar meeting
invites delivered to their Inbox.
So in the end – we have a solution, other than recreating the mailbox, however no actual root cause.