Dê uma olhada em Os convites da Agenda não estão sendo entregues na caixa de entrada, mas aparecem como tentativas no calendário após a migração do Exchange 2010 para o Exchange 2013 e algumas das etapas descritas aqui.
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.
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. 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.
So in the end – we have a solution, other than recreating the mailbox, however no actual root cause.
source