Use PowerShell to manage FullAccess permissions on mailboxes

Every now and then you’ll have a user who has FullAccess to umpteen mailboxes for whatever reason. Cross-forest mailbox migrations, for example. Over time you might lose track of what mailboxes they have access to or why and Outlook starts misbehaving. Shared mailboxes no longer automap in Outlook or they don’t update properly, etc. When you use PowerShell to add FullAccess to another mailbox, you might see this warning:

 

WARNING: Some delegates added may not show up automatically in Outlook. Outlook is limited to displaying only the first 32 entries (If a delegate user has an archive, the user counts as 2 entries).

 

Use these PowerShell tricks to untangle the mess.

Use PowerShell to remove FullAccess permissions from all Exchange 2010 mailboxes for one user or group.

Get a list of all mailboxes that one user or group has FullAccess to:

 

$OU = "domain.com/employees"
$DemotedUser = "First.Last"
$Permissions = (Get-Mailbox -Resultsize Unlimited | `
    Get-MailboxPermission | ?{($_.User -like "*$DemotedUser") `
    -and ($_.AccessRights -eq "FullAccess") -and `
    ($_.IsInherited -eq $False)})
$Permissions | FT Identity, User -AutoSize

 

Remove all FullAccess permissions to mailboxes for one user or group in a single OU by piping the results of the previous cmdlet to Remove-MailboxPermission:

 

$Permissions | Remove-MailboxPermission `
    -User $DemotedUser `
    -AccessRights FullAccess -Confirm:$False

 

On some mailboxes, you might encounter an error like this one:

 

WARNING: An inherited access control entry has been specified: [Rights: CreateChild, Delete, ReadControl, WriteDacl,
WriteOwner, ControlType: Allow] and was ignored on object “CN=End User Name,OU=Employees,DC=domain,DC=com”.

 

The mailbox probably has an explicit Deny permission on the mailbox in addition to an inherited permission. At some point, you probably granted this administrator an explicit FullAccess permission, but then when you removed it, Exchange did a little “thinking” in the background.

“Hmm…”, it thought. “This user is inheriting FullAccess permissions and has explicit FullAccess permissions. Removing the explicit permissions won’t have any effect unless I add a new explicit Deny entry.” And of course, the server didn’t tell you that this is what it was thinking. It just did it. I can’t tell you why it does it sometimes, but not others. I’m sure there’s a reason, but I haven’t seen what it is.

When you run Get-MailboxPermission (or $Permissions from the script above) you’ll see something like this:

 

Identity User AccessRights IsInherited Deny
——- —- ———— ———– —-
domain.com/Employe… DOMAIN\first.last {FullAccess} False True

 

You’ll have to add FullAccess permissions again via PowerShell (see below) and–at least in my testing–the explicit Deny will go away leaving only the inherited FullAccess entry.

 

$permissions | Add-MailboxPermission -User $demoteduser `
    -AccessRights FullAccess -Confirm:$false

 

Now if you run Get-MailboxPermission again, you should see this:

 

Identity User AccessRights IsInherited Deny
——- —- ———— ———– —-
domain.com/Employe… DOMAIN\first.last {FullAccess} True <True/False>

 

The last column could be True or False, depending.

 

Leave a Reply

Your email address will not be published.