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.

About Paul Cunningham

Paul is a Microsoft Exchange Server MVP and publisher of Exchange Server Pro. He also holds several Microsoft certifications including for Exchange Server 2007, 2010 and 2013. Connect with Paul on Twitter and Google+.

Comments

  1. 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.

    • 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. Thanks Paul this saved me lots of time!

  4. 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.

  5. 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.
    Angel.

  6. 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.

  7. 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.

  8. sivaram_MSFT says:

    Very nice article…

  9. Thanks a lot Paul!! You saved me!!

  10. Excellent write up, Paul!

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

  11. error404 says:

    Thanks man

  12. 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

  13. 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?

    Thanks!

    • My advice is to follow the advice in the article above.

      • 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.”

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

  14. Jason Hauck says:

    Paul,

    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!

    Thanks,
    Jason

  15. Thanks for this info, it did work for me!

  16. 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 :)

    Thx,
    Lars

  17. I’ve had sucess using this PowerShell script: http://blogs.msdn.com/b/emeamsgdev/archive/2012/08/31/powershell-remove-invalid-delegates-from-mailboxes.aspx which was much easier than dealing with MFCMAPI.

  18. 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

  19. 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.

Leave a Comment

*

We are an Authorized DigiCert™ SSL Partner.