Why Remove-MailboxFolderPermission fails if user specified in User property doesn't have any mailbox?

Question

Why Remove-MailboxFolderPermission fails if user specified in User property doesn't have any mailbox?

Volodymyr Dumchykov 56

ExoModuleVersion: 3.2.0

Problem: Remove-MailboxFolderPermission cannot remove permission if the user specified in User property doesn't have any Exchange Online mailbox. The cmdlet fails with the following error:

|Microsoft.Exchange.Management.StoreTasks.UserNotFoundInPermissionEntryException|There is no existing permission entry found for user:103ac2ac-42e3-4797-af94-bd13d4c69a9c.

Where '103ac2ac-42e3-4797-af94-bd13d4c69a9c' is the ID of the user that I specify in -User parameter.

If I specify the user's display name, then the cmdlet removes the permission correctly, but display name cannot be used because it is not unique and cannot identify the user correctly.

Kai Yao 37,786 Reputation points Moderator

2023-09-21T02:58:42.78+00:00

Hi @Volodymyr Dumchykov

Just checking in to see if above information was helpful.

Please let us know if you would like further assistance.
Henning Tranberg 0 Reputation points

2024-06-11T12:20:15.37+00:00

I have had a similar problem when trying to remove calendar permissions assigned to distribution groups. These permission entries have UserType "Unknown" and a null value in the RecipientPrincipal attribute. While DisplayName contains a value, RemoveMailboxFolderPermission throws a UserNotFoundInPermissionEntryException and refuses to touch the entry.

However, if I feed it with the entire user object from the permission record and add the -Force flag, the entry is removed anyway:

Remove-MailboxFolderPermission -Identity $CalendarId -user $Permission.user -Force

According to the documentation, the Force flag only suppresses warning messages, but it turns out to have an effect on the behaviour of the function as well. This flag is only available in Exchange Online, but I assume that is where most of us are at this stage.
David Hill 10 Reputation points

2025-05-29T16:40:38.9833333+00:00

I have encountered this and it always bugged me that I could never find an easy solution.. until I found it.. don't use username, use displayed name:

Example:

get-mailboxfolderpermission -identity jdoe:\calendar

Returns:

Calendar Jane Smith Reviewer

This works whether they have an account or not:

remove-MailboxFolderPermission -Identity jdoe:\Calendar -User "Jane Smith" -Confirm:$false

The key is using the Displayed name in quotations.

Answer accepted by question author

0 additional answers

Your answer

Kai Yao 37,786 Reputation points Moderator

2023-09-21T02:58:42.78+00:00

Hi @Volodymyr Dumchykov

Just checking in to see if above information was helpful.

Please let us know if you would like further assistance.
Henning Tranberg 0 Reputation points

2024-06-11T12:20:15.37+00:00

I have had a similar problem when trying to remove calendar permissions assigned to distribution groups. These permission entries have UserType "Unknown" and a null value in the RecipientPrincipal attribute. While DisplayName contains a value, RemoveMailboxFolderPermission throws a UserNotFoundInPermissionEntryException and refuses to touch the entry.

However, if I feed it with the entire user object from the permission record and add the -Force flag, the entry is removed anyway:

Remove-MailboxFolderPermission -Identity $CalendarId -user $Permission.user -Force

According to the documentation, the Force flag only suppresses warning messages, but it turns out to have an effect on the behaviour of the function as well. This flag is only available in Exchange Online, but I assume that is where most of us are at this stage.
David Hill 10 Reputation points

2025-05-29T16:40:38.9833333+00:00

I have encountered this and it always bugged me that I could never find an easy solution.. until I found it.. don't use username, use displayed name:

Example:

get-mailboxfolderpermission -identity jdoe:\calendar

Returns:

Calendar Jane Smith Reviewer

This works whether they have an account or not:

remove-MailboxFolderPermission -Identity jdoe:\Calendar -User "Jane Smith" -Confirm:$false

The key is using the Displayed name in quotations.

Answer 1

Vasil Michev 126.1K MVP Volunteer Moderator

Can you show us the output of Get-MailboxFolderPermission for that entry? In particular, the properties of the User object, for example:

Get-MailboxFolderPermission user:\calendar | Select -ExpandProperty User

If the UserType value returned therein does not show "Internal", Exchange has no knowledge of the corresponding security principal, and using the GUID value will result in an error similar to the above.

If you do see non-null RecipientPrincipal object returned, you can use identifiers therein to reference the user.

Volodymyr Dumchykov 56

Get-MailboxFolderPermission returns a record with UserType equals "Internal". RecipientPrincipal contains an object of type ADRecipientPrincipal with fields such as "LegacyExchangeDN", "Name", "Sid", "Guid":

Type                     : ADRecipientPrincipal
LegacyExchangeDN         : /o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=5238b76e068c40eab6b0b2fc927243d4-b623a6df-87
PrimarySmtpAddress       :
EmailAddresses           : {SIP:******@domain.com}
RecipientType            : User
RecipientTypeDetails     : User
Name                     : b623a6df-87d6-4aae-803a-74925215ea8f
DisplayName              : Test User2
IsValidSecurityPrincipal : False
IsConsumerMailbox        : False
IsGroup                  : False
Sid                      : S-1-5-21-563815680-3157599435-888286042-64499404
Guid                     : 243cb006-edae-4d17-b2e9-0854c2c21f73
Alias                    :
DirectoryRecipient       : Test User2
IndexString              : /o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=5238b76e068c40eab6b0b2fc927243d4-b623a6df-87

Remove-MailboxFolderPermission with indentifies from this object fails with a error like the following:

Write-ErrorMessage : |Microsoft.Exchange.Management.StoreTasks.UserNotFoundInPermissionEntryException|There is no existing permission entry found for user: /o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=5238b76e068c40eab6b0b2fc927243d4-b623a6df-87. At C:\Users\begemot\AppData\Local\Temp\tmpEXO_bjbcppbj.qkt\tmpEXO_bjbcppbj.qkt.psm1:1188 char:13 +             Write-ErrorMessage $ErrorObject +             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~     + CategoryInfo          : NotSpecified: (:) [Remove-MailboxFolderPermission], UserNotFoundInPermissionEntryException     + FullyQualifiedErrorId : [Server=BYAPR07MB5127,RequestId=cf47f0c4-553e-7429-cdb8-b6fe94cfa4d8,TimeStamp=Thu, 21 Sep 2023 07:54:20 GMT],Write-ErrorMessage

Only using the value of DisplayName field removes the permission, but again the DisplayName is not unique.

Vasil Michev 126.1K Reputation points MVP Volunteer Moderator

2023-09-21T08:39:41.9+00:00

RecipientTypeDetails : User

The above means that this user is not a valid recipient (i.e. not an object supported by ExO), thus the errors you are getting. I'm actually surprised that using display name works in your case.
Volodymyr Dumchykov 56 Reputation points

2023-09-21T11:58:58.6966667+00:00

The above means that this user is not a valid recipient (i.e. not an object supported by ExO), thus the errors you are getting

But it means that there is no way to remove such permissions. As for me it's normal scenario - Exchange Online license is revoked from a user account, but there are permissions granted for the user, and there is no way to remove the permissions.

I'm actually surprised that using display name works in your case.

Yes, its quite interesting :-)
Kai Yao 37,786 Reputation points Moderator

2023-09-22T06:36:19.7466667+00:00

Hi @Volodymyr Dumchykov

In this case to me you may need to re-assign EXO license to the user, remove the permission then remove the license.

Besides, if the user does not have an active license, in normal cases it is not possible for him to actually make use of the permission.
Olivier DELAPLACE 0 Reputation points

2023-09-22T09:53:40.8466667+00:00

i've got the same problem and i couldn't remove users that have been deleted, the UserType was "Unknown" with the command :

Rmove-MailboxFolderPermission - Identity user:\calendar -User username

i've got this error message : "+ CategoryInfo : NotSpecified: (:) [Remove-MailboxFolderPermission], UserNotFoundInPermissionEntryException"

the users I wanted to delete had "Editor" access rights.

I therefore deleted all users with "Editor" access rights with these commands :

$calendarIdentity = "User:\Calendar"

$editors = Get-MailboxFolderPermission -Identity $calendarIdentity | Where-Object {$_.AccessRights -eq "Editor"}

foreach ($editor in $editors) {

Remove-MailboxFolderPermission -Identity $calendarIdentity -User $editor.User -Confirm:$false

}

Users who could not be deleted are now deleted
Jeremy Bradshaw 66 Reputation points

2024-08-07T11:43:44.7033333+00:00

I just hit this issue in EXO where the User is UserType = Unknown, but where there is a live recipient in EXO that has the same displayName as that Unknown-type user. In this case, there's no resolution via PowerShell. Sort of a disgrace that a simple ACL needs to have been made so unmanageable.

DisplayNames should never be getting in the way of managing ACL's. I've been complaining about this error in the design for over 10 years publicly. They just don't get it, or don't care.

Share via

Why Remove-MailboxFolderPermission fails if user specified in User property doesn't have any mailbox?

0 additional answers

Your answer