Get-MailboxFolderPermission returns a value in User field that cannot identify object

Question

Get-MailboxFolderPermission returns a value in User field that cannot identify object

Volodymyr Dumchykov 20

The Get-MailboxFolderPermission cmdlet returns permission records containing a User field that represents the object to which the permission is assigned. However, the value returned in this field contains the object's display name.

Because display names are not guaranteed to be unique within an Exchange Online tenant, the User field cannot always uniquely identify the corresponding object. For example, multiple users may have the same display name, making it impossible to reliably determine which user a permission record refers to based on this value alone.

This can lead to ambiguity when processing mailbox folder permissions programmatically, especially when the object must be uniquely identified or correlated with an Entra ID or Exchange Online object.

0 comments

Answer accepted by question author

Vasil Michev 127.8K MVP Volunteer Moderator

Your assessment above is correct, but for Exchange Online, there is an easy solution - use the Get-EXOMailboxFolderPermission cmdlet instead. Here's a comparison between the output of the two cmdlets:

Get-MailboxFolderPermission shared:\Kalender | select -Skip 2 | select -ExpandProperty User
Gosho
Pesho

Get-EXOMailboxFolderPermission shared:\Kalender | select -Skip 2 | select -ExpandProperty User
DisplayName UserPrincipalName UserType
----------- ----------------- --------
Gosho       ******@michev.info Internal
Pesho       ******@michev.info Internal

As you can see, the latter returns a object instead of a string, and the object contains a proper identifier for the User in the form of UserPrincipalName.

Volodymyr Dumchykov 20 Reputation points

2026-08-20T14:11:35.5233333+00:00

Thank you Vasil!
ThStLearn 191 Reputation points

2026-08-21T14:02:44.4933333+00:00

@Vasil Michev
However, that statement cannot be correct. We have Azure Function PowerShell scripts running with PowerShell version 7.4 and EXO version 3.10.1. Until August 18, 2026, the Get-MailboxFolderPermission cmdlet still returned a User object with RecipientPrincipal as a property, on which we had based our code. The function ran for several weeks without any issues. Starting August 19, 2026, the User Property now returns only a string. From that point on, the code generated an error. All of our logs can confirm this. No changes have been made to the Azure Function in recent weeks, neither to the EXO module nor to the PowerShell version.
Volodymyr Dumchykov 20 Reputation points

2026-08-26T06:04:03.6066667+00:00

The odd thing is that the UserPrincipalName field contains the WindowsEmailAddress value of the referenced object. In most cases, these values are the same, but when they differ, the field contains WindowsEmailAddress rather than UserPrincipalName.

Looks like a bug
Vasil Michev 127.8K Reputation points MVP Volunteer Moderator

2026-08-26T06:16:17.9666667+00:00

They fixed the "original" Get-MailboxFolderPermission in the meantime, it now returns a recipient object which you can leverage.

There is no single property/field that can cover all scenarios, as folder permissions can include entries for groups, external/federated users, published calendars and so on.
ThStLearn 191 Reputation points

2026-09-07T09:10:41.0166667+00:00

Hi @Vasil Michev
Thanks for clarifying. It's a bit of a shame that there hasn't been any public information here or any official Git changes elsewhere.

1 additional answer

Your answer

Volodymyr Dumchykov 20 Reputation points

2026-08-20T14:11:35.5233333+00:00

Thank you Vasil!
ThStLearn 191 Reputation points

2026-08-21T14:02:44.4933333+00:00

@Vasil Michev
However, that statement cannot be correct. We have Azure Function PowerShell scripts running with PowerShell version 7.4 and EXO version 3.10.1. Until August 18, 2026, the Get-MailboxFolderPermission cmdlet still returned a User object with RecipientPrincipal as a property, on which we had based our code. The function ran for several weeks without any issues. Starting August 19, 2026, the User Property now returns only a string. From that point on, the code generated an error. All of our logs can confirm this. No changes have been made to the Azure Function in recent weeks, neither to the EXO module nor to the PowerShell version.
Volodymyr Dumchykov 20 Reputation points

2026-08-26T06:04:03.6066667+00:00

The odd thing is that the UserPrincipalName field contains the WindowsEmailAddress value of the referenced object. In most cases, these values are the same, but when they differ, the field contains WindowsEmailAddress rather than UserPrincipalName.

Looks like a bug
Vasil Michev 127.8K Reputation points MVP Volunteer Moderator

2026-08-26T06:16:17.9666667+00:00

They fixed the "original" Get-MailboxFolderPermission in the meantime, it now returns a recipient object which you can leverage.

There is no single property/field that can cover all scenarios, as folder permissions can include entries for groups, external/federated users, published calendars and so on.
ThStLearn 191 Reputation points

2026-09-07T09:10:41.0166667+00:00

Hi @Vasil Michev
Thanks for clarifying. It's a bit of a shame that there hasn't been any public information here or any official Git changes elsewhere.

Answer 1

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more