Deleted Delegates Still Receive Meeting Invites for Other Mailbox Users

I encountered two cases this week caused by the same bug. They began with different problem descriptions:

  1. When people in a team send meeting requests to a room mailbox their team regularly uses, they receive an NDR for a person who left the company some time ago and no longer has an account or mailbox
  2. A person who used to be the delegate/manager for a room mailbox continues to receive meeting requests for that room, even though they no longer appear in the delegates list

Note that this doesn’t only impact room mailboxes, it just happens that was the situation in both of my cases this week.

In both cases the same bug was the root cause.  When delegates are added to a mailbox an invisible rule is added to that mailbox to forward the meeting requests to the delegates. When they are later removed the rule continues to send them the meeting requests.

For example in this case Ana Williams has one delegate, Alan Reid, but a former delegate Alex Heyne is also still receiving a copy of the meeting requests, even though he does not appear in the delegates list.

Because the invisible rule is invisible :) it can’t be seen in Outlook.

Instead we need to open the mailbox using MFCMAPI to see the rule.

Update: a few people have let me know that they’ve had success fixing this issue by simply removing all existing delegates, then re-adding them. That seems to remove the invisible rule with the stale entry, and then it is re-added with just the intended delegates. Though that approach didn’t work for me in these cases, it would be the quickest win so is worth trying first before going further with MFCMAPI.

Download MFCMAPI here and extract the file onto a computer that also has Outlook installed (it will use the Outlook profile to logon to Exchange).

After launching MFCMAPI click the Session menu and choose Logon.

After logging on choose MDB, Open other mailboxes, then From GAL.

Choose the suspect mailbox from the GAL, in this case Ana Williams. Click OK at the “CreateStoreEntryID flags” dialog that appears.

Navigate the Root Container down to Top of Information Store and then Inbox. Right-click Inbox and choose Other tables and then Rules table.

Depending on the number of regular inbox rules the mailbox has you may see more than one entry. To locate the invisible rule that handles email forwarding for delegates look for the rule that has a blank “Rule Name“, and has a PR_RULE_PROVIDER value of “Schedule+ EMS Interface“.

Before proceeding to the next step be aware that this process removes the email forwarding for all delegates on the mailbox. So before you delete it make sure you’ve made a note of the delegates who are supposed to remain on the mailbox, as they will need to be re-added.

Right-click the rule and choose Delete.

The final step is to re-add any delegates to the mailbox that are still wanted.

When this is complete only those intended delegates will receive the meeting requests, and the deleted delegates should receive no more meeting requests, or in the case of the former staff member, no longer cause NDRs back to the meeting organizers.


  1. Pete says

    I have had the same problem, most of mine were due the the delegate no longer having an AD Account as they have been terminated.
    When the account is removed from AD there were still remnants of the deleted delegate account on the users mailbox.

    Usually if you add a delegate to the problem mailbox and then remove the same delegate it forces everything to sync back up removing that “Ghost” delegate that was left behind.

    • says

      I believe you, although in the case of example 2 in the above article the person was still around, but no amount of re-adding and re-removing them from the delegates list on the room mailbox would fix the issue.

      But your method is the quicker and easier win if it works, so worth trying first :)

  2. Chris Lawrence says

    I’ve run across this exact problem twice now, this fix would have saved sooo much time. We took the nuclear option: deleted the mailbox and reconstructed the contents.

    Didn’t help that the phantom bouncer was someone that left the org in unsavory circumstances.

  3. David Nicholls says

    The method of removing all delegates and then re-adding them does indeed work, so its definitely worth trying that as a first attempt at resolving those particular errors.

  4. Angel Biurrun says

    Hello Paul.

    I’m Sorry but I don’t know where I can make a question.

    I need to receive an email, when any of my administrations guys add or remove someone to an administration groups.
    How can I do it?

    Many thanks.

  5. Geni says

    What worked for me on this – FINALLY – was the /cleanrules switch. I documented the existing rules and delegates, then removed the delegates from Send As permissions in AD, then ran Outlook with /cleanrules. I then looked at the delegate permissions – and there were the two orphans, one of whom had been completely deleted from AD. I was able to remove them from delegate permissions. Then I closed Outlook, re-opened it, added the delegates back to Send As permissions in AD – and it automagically re-created them in delegate permissions, which is bizarre. But the person who had been receiving the meeting notices who shouldn’t have been stopped getting them, and people stopped getting NDRs for the person who no longer exists, so I’m happy.

  6. Dave says

    Hi Paul,

    This has been a thorn in my side for over a year! Thank you very much for the detailed walkthrough. It worked first time.

    Thanks again.

  7. Jim G says

    Excellent write up, Paul!

    I’m glad my persistent searching paid off and I found a REAL solution to this problem!

  8. Barry Koch says

    I am having an issue though with the 1038 build. As soon as I select a mailbox from GAL and open it, the application bombs out completely and I have to force terminate the program

  9. Missy McKinney says

    I am having this exact issue but on my mac. I’m running Outlook 2011 and had added a delegate from the exchange so that we could see each others calendars but instead I am getting all of his meeting invites and he isn’t seeing them at all. So we removed each other as delegates, but I am STILL getting his invites (though now I cannot respond).

    Any advice?


      • Missy McKinney says

        I tried downloading the file and it won’t run on my computer. Instead I get the error “You can’t open the application “mfcmapi.exe” because Microsoft Windows applications are not supported on OS X.”

        • says

          Ah okay. This is not something you fix from your computer as an end user, it is something the administrator of the Exchange server needs to fix. The MFCMapi tool has specific requirements for running it.

  10. Jason Hauck says


    I followed the instructions and was able to delete the ghost rule. In trying to add the delegate I want there back in, I can see them in the EMC dialog but nothing ever goes to them. What’s more is the ghost rule does not appear to be recreated. I have tried removing the newly-added delegate, saving, and re-adding, I have tried removing the “fwd all requests to delegates” checkbox, saving and re-adding, and removing all delegates AND the checkbox, saving and re-adding both, but no love.

    Any ideas? Am I being impatient? I’ve only waited about 30 minutes. On the bright side, in the interim, the room is answering requests like a champ. If I can get the delegate back in the loop I’m home free!


  11. Lars Bemelmans says

    Hi Paul,

    Excellent story! I had this situation twice and this solution saved me from tons of work.
    It’s an annoying bug and with this solution it’s fixed in a moment.
    Thank you for writing it down. I will save this page for future cases :)


  12. Skiman says

    Tried this suggestion in the article, did not work

    The fix for me was, File > Account Settings > Delegate Access and to delete all entries in there

    I googled this and noone suggested this fix, which was amazing, I found it in something totally unrelated

  13. ccpiper125 says

    This worked for me. I spent hours on this and kept digging deeper and deeper into Google searches.
    Finally found this post. Never had seen this application before–it works.

    Thank you for such detailed steps. I tried deleting all delegates first with no success.
    This worked perfectly and removed a VERY ANNOYING problem.

  14. Sbarrett says

    Just want to add my appreciation for the detailed fix, 3 day of googling before I came across this page – many thanks.

  15. Mattias says


    It worked like a charm to get rid of old delegates.
    But now after I have re-added the correct delegates, they receive no mails at all.
    I thought that the rule would be re-created when I added the delegates that I wanted.

    How can I re-create the rule?
    I have done this on a resource mailbox, on which I can’t log on with outlook directly and I have deleted / added delegates via EMC, it looks correct there but no mails are sent to delegates.

    • Mattias says

      I found that when I logged on to the resource with outlook, the old delegate options were still there.
      I deleted them and re-added them and the rule was back, I’m not sure Exchange will update this in the future now but at least now I know how I can solve it. :)

  16. Bob says

    This post was a life saver. One of my customer had the exact similar issue which I spend heaps of time to resolve it. But this solution helped me to fix it very quickly.

    Thanks for posting this.


Leave a Reply

Your email address will not be published. Required fields are marked *