User receiving appointments acceptances from a shared mailbox calendar without having access

Brass Contributor

Hello everyone,

 

We have a user who was once a member of a shared mailbox. He had full access to this mailbox and its calendar. Lately he has been removed because he doesn't need access to the shared mailbox any longer. If I check the mailboxpermission and the mailboxfolderpermission with PowerShell, his name doesn't appear on the users' list. However, he is receiving all the appointments' acceptances from that shared mailbox's calendar on his personal mailbox. It's quite annoying for him, as these confirmation messages can be 20-30 every day. I am not sure where to look to avoid this, he shouldn't receive any email from that shared mailbox. 

Could you please advise on this matter?

Many thanks in advance for your help!

 

Francesco   

13 Replies
He's probably still listed as delegate, check via Get-CalendarProcessing and Get-MailboxFolderPermission on the Calendar folder.

Hi @Vasil Michev

 

Many thanks for your reply.

I have already checked the MailboxFolderPermission on the Calendar folder and this person doesn't appear in the list (there are only the Default and the Anonymous users).
I tried with the

Get-CalendarProcessing -Identity <sharedmailboxname> | Format-List

 but couldn't find any information about delegates. I noticed that there is a property called "ResourceDelegates", but if I run

(Get-CalendarProcessing -Identity <sharedmailboxname>).ResourceDelegates

I don't get any results.

I also tried the new switch parameter "ResetDelegateUserCollection"

Remove-MailboxFolderPermission -Identity "<sharedmailboxname>:\Calendar" -ResetDelegateUserCollection

but it didn't work, the user is still receiving the appointments acceptances.

It looks like his name is hidden somewhere but I can't find it. I checked also the Exchange Online Admin Center but to no avail.

Any other ideas?

Many thanks

 

Francesco

Run a message trace against one of the invites, then look at the message trace details, they should give you a clue as to what's happening: https://docs.microsoft.com/en-us/Exchange/monitoring/trace-an-email-message/message-trace-modern-eac
In an ideal situation, if the user is not added as a delegate to the shared mailbox he/she should not be receiving the updates.

If the user is still receiving the updates this could be because of a corrupt rule. I will recommend you to first take a backup of all the rules and list of delegates.

Using MFCMAPI Go to >> Root Container >> Top of Information Store >> Inbox.
Right click “Inbox” > “Open Tables” > "Open Rules Table" and check for any rules with blank name where the value of PR_RULE_PROVIDER is "SCHEDULE+ EMS Interface" and delete it

Once done, send a test invite to the shared mailbox and check if the impacted user is still receiving a notification. Let me know if it works

Hi @Vasil Michev,

 

I run the message trace against one of the invites (extended report), a csv file has been generated but I am not sure how to "read" all those information. I have a list of events, should I focus on the "deliver" event? I have many fields in the report, I have copied just a few below (removing IDs). Is there something in particular that I should check (server_hostname, connector_id, internal_message_id, reference, message_info, custom_data)? I also run the "Get-InboxRule" on the mailbox to check if there were some rules set, but I don't get any results. 

Many thanks in advance

 

source_contextsourceevent_idrecipient_statustotal_bytes
 RESOLVERRECIPIENTINFOUserMailbox.Forwardable.Resolver.CreateRecipientItems.4026782
<number>;2021-10-08T13:27:38.234Z;10SMTPRECEIVE 26782
 MAILBOXRULERECEIVETo25625
<number>;2021-10-08T13:34:35.617Z;ClientSubmitTime:2021-10-08T13:34:25.000ZSTOREDRIVERDELIVER 34820
Mailbox Rules AgentAGENTSUBMIT 25625
CatContentConversionAGENTAGENTINFO 28685

 

Hi @surajbudhani,

 

Thank you for your suggestion. I never used MFCMAPI, do I need to have full access to this mailbox to check the "rules table"?

Is this something you can check also with Powershell?

I will have a look at that and get back to you.

Many thanks!

Francesco 

@fstorer 

You wont be able to check this using PowerShell. You will have to configure the shared mailbox in Outlook online mode with full access permission and use MFCMAPI to check this. I have shared the download link in the previous reply.

On MFCMAPI >> Click on Tools >> Options >> Make sure the following two options are checked

Screenshot 2021-10-11 162257.jpg

 

After that:
On MFCMAPI Click on Session >> Login >> Select the profile >>Double Click on the Profile >> Root Container >> Top of Information Store >> Inbox.
Right click “Inbox” > “Open Tables” > "Open Rules Table" and check for any rules with blank name where the value of PR_RULE_PROVIDER is "SCHEDULE+ EMS Interface" and delete it

Once done, send a test invite to the shared mailbox and check if the impacted user is still receiving a notification. Let me know if it works.

@surajbudhani 

 

So I need to create a different profile in outlook just for the shared mailbox and also assign a password in order to access it? 

Hello,

 

Just a quick post to inform the community that I was able to fix my issue thanks to a very helpful article by Gareth Gudger. When you search the web for this issue, you find a lot of articles pointing to MFCMAPI but all you need is just PowerShell ;)

The delegate hidden rule redirecting to the user has now been cleaned up. 

I hope this can help other people with the same issue.

Thank you @Gareth Gudger, you made my day! 

 

THANK YOU SO MUCH FOR THIS! IT TOOK ME A MONTH FINDING A SOLUTION AND WORTH IT! THANK YOU!

Could you identify the specific powershell command you used to resolve this? We have the exact problem with our CIO's mailbox and he woukd certainly appreciate a resolution. Thank you!

Never mind, I neglected to access the link you provided.

 

It sounded like this would help to resolve our issue, but none of the provided tests provided a resolution.

@Janasrs 

Check for hidden inbox rules

https://supertekboy.com/2021/07/21/former-calendar-delegate-still-receives-meeting-notifications/

 

Get-InboxRule -Mailbox email address removed for privacy reasons -IncludeHidden

 

Get-InboxRule -Mailbox email address removed for privacy reasons -IncludeHidden -Identity 1538451201245271021 | Format-List

 

Get-InboxRule -Mailbox email address removed for privacy reasons -IncludeHidden -Identity 1538451201245271021 | Remove-InboxRule