I encountered two cases this week caused by the same bug. They began with different problem descriptions:
- 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
- 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.
There is a non-mfcmapi way with exchange online at least, using powershell.
Get-MailboxFolderPermission :\calendar to list current settings
Remove-MailboxFolderPermission :\calendar -ResetDelegateUserCollection
This will clear the delegate rule, and re-check permissions on the calendar – so running the get permission cmdlet again should now show the ‘removed’ delegates again, which can now be properly removed.
Then, just reset the delegate flags on the users who should have it, and Bob – as they say – is your uncle.
This is 100% worked for me. Thank you very much.
19th April 2023
Hey man, thanks a ton for this article. This issue has been hounding me for a month and I found your article, found who the user was receiving delegate mail from, loaded up that person’s profile and slayed the invisible rule with MFCMAPI.
Much appreciated!
Worked for me even with the translation, only site I could see with the exact issue I was facing, many thanks.
Chrome is now reporting that link as malicious.
Hi Paul, came across this article and it seemed to be exactlyu this issue I was having. However I couldn’t get the rules table to open.
After many hours of trying many different things, I stumbled across this microsoft article that whilst not fully related talked about enabling two options in the settings of MFCMAPI
https://blogs.msdn.microsoft.com/hkong/2015/02/27/how-to-delete-corrupted-hidden-inbox-rules-from-a-mailbox-using-mfcmapi/
“Use the MDB_ONLINE flag when calling OpenMsgStore”
“Use the MAPI_NO_CACHE flag when calling OpenEntry”
In my scenario I have a hybrid setup, and the user receiving the unwanted notifications was on-premise and the main user was office365. Not sure if this what was causing my issue above.
Giving myself Full Access to the office365 mailbox, and setting the options above I was then able to open my mailbox, and then drill into the office365 user box, and follow your instructions to deleted the invisible delegation…
Which fixed my issue.
Thanks for the article, would have been stumbling around for a while.
Wonderful. Very helpful, thank You!
Just an FYI a way around this without using MFCMapi is to give yourself Full Access to the mailbox and then create an Outlook profile with the mailbox as the primary email address. Set your mail profile to prompt you to choose which one opens when you start Outlook.
Once you’ve done this you can run “Outlook.exe /cleanviews” and then it deletes all the mail rules including the hidden ones.
Obviously if there are legitimate rules export these before doing this, when you import them again it doesn’t import the broken hidden rule.
Great post, thanks a lot!
I have similar issue with A random forward of a meeting notice was sent out to random people. Alan ( A user) did not initiate it. We think there’s a bug somewhere…
From: Microsoft Outlook On Behalf Of Alan
Sent: Thursday, February 23, 2017 7:28 AM
To: Gerry, Peter
Subject: Meeting Forward Notification: PAT Completions Conference Call
When: Thursday, February 23, 2017 7:30 AM-8:30 AM (UTC-06:00) Central Time (US & Canada).
Where: Conf Room W701 and Teleconference 1.866.313.6879 Code 7876942824
Your meeting was forwarded
Alan has forwarded your meeting request to additional recipients.
Meeting
PAT Completions Conference Call
Meeting Time
Thursday, February 23, 2017 7:30 AM-8:30 AM.
Recipients
Mike, Bill
Greg, John
Please i need help getting this resolved
The Real Person!
The Real Person!
Someone has forwarded the email I guess. Look for inbox rules that might be the cause. Or do some message tracking log searches if you need to know where the emails originated from. If you think you have a bug, open a support case with Microsoft.
Appreciate your time and instructions on putting this article together.
Fixed the annoying issue.
I had a similar issue. One of our users opened the sharing properties of his Outlook calendar and manually gave his boss editor rights.
When he removed his boss from the security tab he still received meeting notifications even though the permission had been removed.
I was able to fix this by simply adding a delegate under Outlook for his boss and explicitly denying access to his calendar.
Restarted Outlook, removed the delegate again and everything seem to back to working order.
Simply The Best!
Thank You!
What is the powershell command to remove delegate permissions from an O365 mailbox on hybrid environment?
Hi Paul,
How about writing some content that is original instead of re-writing TechNet and everyone elses articles?
This was something that I had already published “ORIGINALLY” back in 2009.
http://clintboessen.blogspot.com.au/2009/09/exchange-2003-meeting-request-receiving.html
You simply re-wrote copying my article…
Not cool
Paul, once again you saved the day!
very much appreciated.
Paul:
Cheers, mate. You rocked this one. Had a delegate getting his supervisors meeting notifications. Tried the remove all trick, but it didn’t work. Tried powershell. This did the trick.
I have been trying to fix this for over a year, I deleted all the delegates and re entered them and bingo, FIXED! Thanks for the solution !!
Hi Guys
I have an issue :
Disable meeting forward notification ( not simply send it to deleted items)
Any idea ?
Or permanently delete them
Many thanks
Hey guys, I discovered a similar issue today and came across this excellent post.
When a meeting request is send to one of our users another user receives the meeting request while no delegates have been set.
When I deep dived into Exchange with the MFCMapi tool I noticed indeed the rule with the “blank” name as mentioned above.
On the client I used the “outlook /cleanrules” command and the rule disappeared after this.
After this, the meeting notice does not appear in the other users mailbox anymore so I figured the problem was solved.
There is however still one problem. While nobody receives the meeting request, Outlook still thinks the meeting request is delegated and displays the message “The meeting request has been sent to your delegate(s)”
The user cannot respond to the meeting request
Does anyone have a clue what is causing this and how it can be corrected?
Cheers, Remko
Hi Guys…. Sorry for posting this after a long time.
I migrated our exchange from 2010 to 2013 and I found that few resource room mailboxes where having this problem.
The meeting approval/ booking approval requests were still being sent to old delegates.
I used the MFCMapi to check if we have some rule on the user end and also tried to change the “auto accept setting” in booking configuration.
There was no rule set on the user side and neither the auto setting and changing the delegate option made any difference.
I finally check the attributes in AD for the room mailbox user account and found that the attribute “altRecipient” had the old delegate’s name.
I cleared this field and this worked for me.
All the Best….. Joe
Hi,
I have this exact same issue with our company PA. She was a delegate for all our meeting rooms. however she’s now handed this over, but still gets the email notifications, and users who bookt he meeting get an acceptance from her, on behalf of the room.
We’re running Office 365 hybrid, so I’m not sure if the MFCMAPI tool will work correctly, as the mailbox is in the cloud, not on premise. Unless it’s possible to connect to the cloud mailbox?
Thanks
Ben
Hi,
I seem to have a similar issue with one of my customers.
We have a security group (e.g. Group1) which is a delegate to accept/decline meeting invites sent to “Hot Desk” resources.
My customer was previous apart of Group1 but has since been removed.
Since being removed, my customer is still receiving “accept/decline” e-mails when user’s book the “Hot Desk” resources.
I assume there is a hidden rule somewhere which is causing this to occur.
I have tried removing the delegates from Group1, saving & closing, then re-adding the delegates but there has been no change.
I have also tried using the MFCMAPI tool but I don’t see any rules for the resources (Root Container > Top of Information Store > Inbox >Other Tables >Table Rules).
Any suggestions?
Cheers,
Matt
Hi,
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.
Cheers,
Bob
Pingback: how many different kinds of sports are there
Thank you sir it fixed my issue
Hello,
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.
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. 🙂
Just want to add my appreciation for the detailed fix, 3 day of googling before I came across this page – many thanks.
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.
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
I believe that based on the title of the article, it is assumed that the delegates have already been removed but the issue persists.
The Real Person!
The Real Person!
LOL, Jason you are correct 🙂
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.
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
Thanks for this info, it did work for me!
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
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!
The Real Person!
The Real Person!
My advice is to follow the advice in the article above.
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.”
The Real Person!
The Real Person!
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.
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
The Real Person!
The Real Person!
Build of MFC MAPI? Best thing would be to mention that to the developer.
Thanks man
Excellent write up, Paul!
I’m glad my persistent searching paid off and I found a REAL solution to this problem!
Thanks a lot Paul!! You saved me!!
Very nice article…
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.
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.
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.
The Real Person!
The Real Person!
You can ask questions in the forums.
https://www.practical365.com/forums
But I personally don’t happen to know the answer to your question.
Many Thanks Paul
Pingback: Tofa IT » Deleted Delegates Still Receive Meeting Invites for Other Mailbox Users
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.
Thanks Paul this saved me lots of time!
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.
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.
The Real Person!
The Real Person!
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 🙂
Thank you Paul and Pete!
Pete’s idea worked for us too.
(Re-add the Delegate on Calendar folder level and Remove it again.)