I have a single user that doesn't seem to receive email notification when people make appointments with them through their outlook calendar.

Our email system is using an exchange 2013 backend with a 2012 outlook email client.

I have logged this user into a new computer and the problem still happens, this leads me to believe that the problem is something to do with his exchange profile.

Is there a setting in exchange that would disable this user from receiving emails with new calendar events?

| improve this question | | | | |
  • 2013. I have checked the windows event viewer and cannot see anything that would relate to this issue. This problem is only happening to this one user, all other users are fine. – Alex Walter Jul 14 '16 at 23:15
  • Ok. I expect it to function the same way as others in the organisation. Email sent to inbox asking for the user to accept or decline, during this time the event is shown in the correct spot as tentative. This user just has the event appear on the calendar as tentative - No email request. – Alex Walter Jul 15 '16 at 0:44
  • Now I have checked the mail box, It is half full. The Same problem occurs external and internal (email and calendar). This user is in the same OUs as everyone else and seems to have the same permissions on the exchange side. I have checked the auto accept feature and this is disabled. No bounce back is given upon appointment creation. The PC i got the user to log into had no problem with outlook with other users. – Alex Walter Jul 15 '16 at 0:47

Have a look at Calendar invites are not delivering to inbox, but show up as tentative in calendar after migration from Exchange 2010 to Exchange 2013 and some of the steps outlined there.


  • 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!

enter image description here

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?

enter image description here

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:

enter image description here

And Bingo – there was the IPM.SCHEDULE.MEETING class association:

enter image description here

So, to remove the association in MFCMapi:

enter image description here


enter image description here

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.


| improve this answer | | | | |

Although the topic is already a few years old, it was still actual for us, and I figured probably out an easier solution, which worked for a user in our Company.

A colleague didn't get the inviting emails anymore, too, although the appointments were written as suggestions into her calendar, but were not confirmed.

Since she had been on summer holiday a few months ago and a colleague of her had to access her mail account to activate the "Automatic Replies", she gave him the Password, but wasn't aware what the guy had done. From that point on she didn't get the appointment emails anymore. But unfortunately she recognized it just a few weeks after, so she couldn't tell either, who or what had caused the problem.

The thing was the following: her colleague has gone in Outlook under "File\Info\Account Settings\Delegate Access" and has entered the account of a practicant. Additionally he set the configuration "Deliver Meeting requests addressed to me and ..." in the Window below to "My delegates only".

So I just had to eliminate the delegate, press ok and the Mailbox returned back to its normal function.

enter image description here

| improve this answer | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.