Albeit a minor change, this might affect some of your scripts, so you should be aware of it. Previously, the Get-MailboxFolderPermission cmdlet returned a ReducedRecipient object for the User property, and you could fetch a huge number of properties from it. Now, this has been changed, the User property returns a PermissionSecurityPrincipal object instead. Here’s an example:
C:\> Get-MailboxFolderPermission sharednew:\calendar -User vasil FolderName User AccessRights ---------- ---- ------------ Calendar Vasil Michev {Editor} C:\> (Get-MailboxFolderPermission sharednew:\calendar -User vasil).User UserType RecipientPrincipal DisplayName -------- ------------------ ----------- Internal /o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=bad62dd352f14380881fb5335891a21d-vasil Vasil Michev C:\> (Get-MailboxFolderPermission sharednew:\calendar -User vasil).User | gm TypeName: Deserialized.Microsoft.Exchange.Management.StoreTasks.MailboxFolderUserId
The list of properties returned by the PermissionSecurityPrincipal/RecipientPrincipal object is quite smaller compared to what we had previously (16 properties vs 400+), but it sufficient to provide you the important details about the recipient to which the permissions have been added, so that’s OK. Here’s an example on how it looks like for my own user:
Now, I mentioned above that this change might affect some of your scripts. Namely, if you were using the User property to display information about the recipient, you might notice that it is now being displayed “empty” in some cases. For example, if we look into a calendar that has been “published” or shared to external user, or we look into the folder permissions of any Office 365 Group:
The data is still there, it’s just not properly displayed when using the default output formatting. But you might run into a similar issue in your own scripts, so you need to update them accordingly. For example, some of my own scripts previously used the User.ADRecipient property, which no longer exists. Instead, you can use User.RecipientPrincipal now.
And since this change applies only to Exchange Online, the scripts might work funny against on-premises Exchange servers now. But they were never designed to run against on-premises installs anyway. You can find the updated scripts here and here.
Thanks for the info, very useful. How can I use this to retrieve a non-existant (UserType=Unknown) user which still have permissions on a calendar ?