Resolving Exchange Online access control limit errors when adding user permissions to a mailbox

I was recently notified of an issue affecting a key business mailbox whereby no new users could be granted access. What made this particularly interesting was that the total number of users with mailbox permissions was circa 300 which is well below the Exchange Online enforced maximum limit of 500.

The error presented is as follows:

|System.InvalidOperationException|The mailbox %GUID% has reached the limit of maximum allowed access control entries of 500. Clean existing entries and rearrange them leveraging groups for assigning the same permissions to multiple users.

In this post I'll show you how to fix this issue so that you can add additional user permissions to the mailbox. As is normal for my posts, I’ll walk through the process of arriving at the final solution; if you’re just here for that, feel free to skip forward although I'd really recommend at least reading the key takeaway part as it'll help you understand what causes this!

Investigating: The basics

As usual, step 1, don’t expend too much energy, someone must have solved this already…

Googling leads to few suggestions, with the main accepted solution being to add users to a security group and then grant that access to the mailbox which then only counts as a single ACL (Access Control List) entry on the mailbox. While this will work, for anyone in the security group Exchange won’t map the mailbox to the Outlook sidebar for users, so if your users are frequently in the mailbox they’d have to keep opening the shared mailbox inbox folder up manually. Not a great user experience and this equally assumes you can remove enough existing users to stop the initial error occurring. Most importantly, it also doesn’t explain why we see this error even though there are less than 500 users with mailbox permissions.

Investigating: Digging deeper into the backend

With no silver bullets from the community I started investigating myself, with PowerShell being very useful to get a view into data that’s not surfaced in the UI.

We can use the Get-MailboxPermission cmdlet to see who has full access, which again matches the UI and shows less entries than the 500 limit, not much use.

However, looking deeper at the cmdlet documentation we can see there is a parameter called “IncludeSoftDeletedUserPermissions”.

When running the same command with the new parameter included, voila! Over 500 entries returned.

---

Key Takeaway

The key information to take from this is that when users are soft-deleted they retain their permissions on the mailbox and consume one of your 500 total user ACL quota. This situation will occur when you have mailboxes that are subject to retention policies, litigation hold or are inactive mailboxes that have yet to be deleted (e.g. within the 30 day recovery window). The latter group may contribute to your problem but will be fully deleted and therefore have their permissions removed once the data recovery window has elapsed.

---

Failing and Iterating

Now that we’ve identified the problem we just need to come up with a solution, it should be fairly straightforward right? We’ll just use the “Remove-MailboxPermission” cmdlet, supply the mail address of the soft-deleted user and take off the permissions but as you can see below we get an error that Exchange can’t find the object we’re referencing even though it exists.

Trying again with many of the common unique properties that you’d usually use to pinpoint a user: identity, alias, WindowsLiveID, GUID all of them return the same error so where next? Well looking back at our permissions data there’s one last promising field, UserSID.

Running the cmdlet to remove permissions, finally we have something that works. I have no idea why this is the only property we can use but I’ll take it!

Script solution logic

Now we can create a script that will, for a specified mailbox:

1. Pull a list of users with full access permissions

2. Pull a list of all users with full access permissions including those that are soft-deleted

3. Compare the two result sets to find the difference, therefore isolating the soft-deleted users

4. Conduct an additional check to verify that the users we are going to target are soft-deleted*

5. Loop through and remove permissions for the soft-deleted users using their SIDs

* I have found that when using the “IncludeSoftDeletedUserPermissions” parameter that this can return users that are not soft-deleted. Perhaps there is a bug in the way that it works but for safety in the code I have added an additional check to ensure that anyone we are going to remove permissions for is a soft-deleted user. In my case I had three mis-categorised users out of roughly 300 who would have had their permissions mistakenly removed if not for this additional check.

The Code

The script for this can be found below, points to note:

• It will dynamically determine the soft-deleted users and remove their permissions

• It creates an audit file in the current working directory of PowerShell

• You need to update the $mailboxName variable with your target mailbox

Once you've executed the script, providing your remaining total number of user permissions are less than 500, you can now add new users either via the Exchange Management UI or PowerShell.

Let me know in the comments or by liking the post if this has helped you out!