How to reset mailbox folder permissions

A thread over at the TechNet forums got me thinking about what is the best (or at least a proper) way to “reset” folder level permissions, with the added challenge of doing it in bulk. Generally speaking, it’s a simple operation, at most you’d have some loop running Remove-MailboxFolderPermission on each entry. But, there are some intricacies, so let’s dig in.

First of all, if you simply want to “reset” the permissions on a given, “known” folder, the task is easy. Say we have the user JohnSmith and we want to remove any permissions on his Calendar folder. All we need to do in such scenario is run the following cmdlet:

Get-MailboxFolderPermission JohnSmith:\Calendar  | % { Remove-MailboxFolderPermission -Identity $_.Identity -User $_.User }

Right? Wrong. There are actually many issues with the one-liner above, starting from the fact that we are not using the proper User identifier. As we’ve discussed in other articles, the Get-MailboxFolderPermission cmdlet returns the reduced recipient object, and not a string value. Thus, a correct entry to use would look something like: $_.User.ADRecipient.ExchangeObjectId.Guid.

///UPDATE: As Microsoft has changed the output of the Get-MailboxFolderPermission cmdlet, the identifier will now look like: $_.User.RecipientPrincipal.Guid.Guid.

Next, we need to exclude the “default” permissions entries, as in the ones configured for the Default and Anonymous security principals. This part is easy to handle with a simple Where clause, and we can even use regex to address some other cases (more on this later). And, we might also want to avoid having to confirm the removal of each individual entry, so the updated cmdlet will look something like this:

Get-MailboxFolderPermission JohnSmith:\Calendar `
  | ? {$_.User -notmatch "^(Default|Anonymous)$"} `
  | % { Remove-MailboxFolderPermission -Identity $_.Identity -User $_.User.RecipientPrincipal.Guid.Guid -Confirm:$false }

From here, we can generalize this cmdlet to run against multiple mailboxes and achieve our dream of resetting the permissions in bulk. Something like this should do the trick:

Get-Mailbox -RecipientTypeDetails RoomMailbox `
  | % { Get-MailboxFolderPermission "$($_.PrimarySmtpAddress):\Calendar" } `
  | ? {$_.User -notmatch "^(Default|Anonymous)$"} `
  | % { Remove-MailboxFolderPermission -Identity $_.Identity -User $_.User.RecipientPrincipal.Guid.Guid -Confirm:$false }

Now that’s a loooong one-liner, but frankly we are still just getting started. There are many additional factors that we need to address, such as the actual folder names, as depending on the localization, the Calendar folder might be renamed to Kalender or whatnot. Then, what if we want to include all folders in the mailbox, not just Calendar? And there are things to consider when removing the permissions as well, such as dealing with orphaned entries, external permissions, published Calendars. Are you getting bored yet?

What started as a simple exercise will have to be turned into a full-blown script if we want to handle everything correctly. Which of course is true for most examples – there is no way to properly handle errors or account for throttling in one-liner solutions. I will have to leave the complete solution for another post, but here are some of the building blogs we need to put together:

  • Account for the type of User, and depending on it handle things accordingly. In other words, for each permission entry, look at the $entry.User.UserType.Value. Available values will include Internal, External and Unknown and all of these will have to be handled differently.
  • Utilize the Get-MailboxFolderStatistics cmdlet to get a list of the localized folder names and trim the list to only include folders you care about. There’s no point in adjusting permissions on Purges folder for example.
  • If you are using the above method to get the localized folder names across multiple mailboxes, you need to start to account for throttling!
  • Decide what you want to do with the Default (and Anonymous) permission level. The regex we used in the above example can be generalized to exclude other entries as well, if needed.
  • Put some logging or utilize the –WhatIf parameter to “preview” the result.

UPDATE: The full script is available here.

P. S. Things are so much easier with Mailbox permissions, as we discussed previously:

Remove-MailboxPermission JoshSmith -ResetDefault

15 thoughts on “How to reset mailbox folder permissions

  1. robert says:

    Hey Vasil ,

    We have an issue where a user had previously been granted access to an executives calendar, i removed the users access (she was not a delegate) but 7 hours later the same user still has access to the executives calendar, not his mailbox. But his calendar for sure.

    How might i figure that out?

    Get-MailboxFolderPermission does not show her account as having access to the executives mailbox or calendar.

    1. robert says:

      Contiuation from above cant edit post.

      we checked in OWA, Same issue. We rebuilt the users profile same issue (expected).


    2. Vasil Michev says:

      What about the Default service principal permissions? Or mailbox-level ones (Full access)?

  2. ChappyChap says:

    Crossing my fingers this post isn’t necroed!

    I’ve been searching quite a bit for something do to this and this by far looks the most simple. Unfortunately when I run it I get: “Cannot bind argument to parameter ‘User’ because it is null”

    I’m at a loss so throwing it out there to the old forum post gods…

    1. Vasil Michev says:

      Microsoft updated the output format for the Get-MailboxFolderPermission, which breaks the examples above. I’ve updated them.

      1. Bart says:

        Hi Vasil,

        Where did you post your updated version of this ?

        I am having an issue at our end. We’re currently running a Hybrid environment after recently migrating away from Lotus Notes.

        So we have a load of residual groups that are assigned permissions to user and shared and other mailboxes.

        It seems that I can’t find a surefire way of doing the removal of these groups because the applet thinks the ‘user’ does not exist

  3. Briana Lindquist says:

    Your post is exactly what I was looking for. But when I run the command to delete extra permissions on a particular folder for an end user, I get the error “Cannot bind argument to parameter ‘User’ because it is null”. I can list the permissions and see the extra one that exists, but it doesn’t seem to like the Remove-MailboxFolderPermission part of the script.

    Get-MailboxFolderPermission jsmith:\Inbox\Test `
    | ? {$_.User -notmatch “^(Default|Anonymous)$”} `
    | % { Remove-MailboxFolderPermission -Identity $_.Identity -User $_.User.ADRecipient.ExchangeObjectId.Guid -Confirm:$false }

    1. Dave M says:

      I know this is extremely late but I ran into the same issue.

      I was able to resolve this by substituting $_.User.DisplayName for $_.User.ADRecipient.ExchangeObjectId.Guidsubsituting

  4. Mitch Daugherty says:

    Let me start by saying thank you. Your information has really helped me out.

    I am using your code for the 3rd item you have posted. But, I am running into a problem that does not make any sense.
    If I run just this Get-MailboxFolderPermission “$($_.PrimarySmtpAddress):\Calendar”

    I receive this error:
    The specified mailbox “MY ACCOUNT”, “EXCHANGE SERVER INFO”, Does not exist. So it is telling me the account I use for all of my everyday O365/MSOL related work needs a mailbox? Can that be the real problem?


    1. Vasil Michev says:

      Those one-liners are easy to use, but have the nasty habit to fail in some situations. Did you try the script linked at the bottom of the article?

  5. Niklas says:

    Hi, I’m trying to solve a mysterious case where we have the same user appearing as both External and Internal, the Internal one has a matching ADRecipient value which can be resolved to an AD user. The External does not have any value for ADRecipient.

    PS] C:\Windows\system32>Get-MailboxFolderPermission\Calendar | where {$_.User -like “niklas*”} | select -ExpandProperty User

    UserType ADRecipient DisplayName
    ——– ———– ———–
    Internal Niklas Jumlin Niklas Jumlin

    The ADRecipient does have the SMTP-address so they shouldn’t be two different objects really.

    How can these be set and how does Exchange evaluate whether the user is External or Internal?

    1. Vasil Michev says:

      Is this for ExO or on-premises? In ExO, we can actually have duplicate email addresses, due to the way it handles Guest users.


Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.