Forum Discussion
EXO's "User" and "Trustee" properties returned from Get-Mailbox/RecipientPermission
The_Exchange_Team I have a situation where FullAccess and Send-As permission holder users have their PrimarySmtpAddress/UserPrincipalName value stored within various properties on multiple different user objects. For my example, consider the output from:
Get-MailboxPermission 'Mailbox123' | select -expand User
Get-RecipientPermission 'Mailbox123' | select -expand TrusteeThere will be a list of SMTP addresses. If I then supply these emails addresses to the -Identity parameter for Get-Recipient or Get-User, some of them come back with multiple objects. In my case I have some UserMailbox's which have corresponding MailUser's with ExternalEmailAddress set to the PrimarySmtpAddress of the mailbox. There's a somewhat-reasonable explanation for this arrangement which I'll spare you of. The point is, without know what this SMTP address on the User/Trustee output property is supposed to represent, it's impossible to consider these ACL entries as concrete.
I acknowledge, if it is the PrimarySmtpAddress or UserPrincipalName, there's no chance of ambiguity. So I assume it is one of these, however, I don't find it documented and so I'm asking here and hoping you'll tell me - which one is it?
Also, less important for me right now but I'll point out how Send on Behalf users are returned in EXO PowerShell within the GrantSendOnBehalfTo property is in the similar state, but the users/trustees are stored there as (I think) their Name/cn property. I understand EXO will eventually change all Name/cn's to match ExternalDirectoryObjectId, but it's not there yet and so GrantSendOnBehalfTo is again less than concrete. Any tips for this would also be appreciated. If it is that they are stored using their Name/cn, then I can work with this using -Filter (as is the same plan with User/Trustee main topic).
Thanks in advance.
PS. The way users are returned from Get-MailboxFolderPermission or Get-DistributionGroupMember - that is how all these things should be.
- It should be returning the UPN value. The problem is two-faced: when you pass the value to Get-Recipient or other cmdlets, it's not treated as UPN, but matched against any of the "identifiers" supported by the cmdlet. In turn, because Microsoft broke the uniqueness constraints for SMTP addresses with the introduction of the GuestMailUser object, you can have multiple objects sharing the same SMTP value.
You should be able to work around it by specifically filtering on UPN value (i.e. Get-Recipient -Filter {UserPrincipalName -eq "email address removed for privacy reasons"}) or by leveraging the -User parameter of the Get-MailboxPermission cmdlet.
+1 on your other points, some minor changes can greatly improve the admin experience... - Forgot to mention, the good old -ReadFromDomainController trick still works and will return the full ADUser object 🙂
Get-MailboxPermission shared -User huku -ReadFromDomainControllerThanks very much for this, Vasil! That trick is priceless to know. I use -ReadFromDomainController in on-prem all the time, generally to immediately confirm changes I just made when in a slow replication/large forest . I did not know about it's trickery status in EXO.
So that's Get-MailboxPermission and Get-RecipientPermission, Get-MailboxFolderPermission already good to go. Now just GrantSendOnBehalfTo.
Thanks again.##EDIT##: I've now tested the -ReadFromDomainController trick. To be honest, it's nice to know but I would otherwise call this completely ridiculous. When supplying ReadFromDomainController, the output of Get-MailboxPermission no longer returns ACE's, instead just an array of users in objects of type 'Deserialized.Microsoft.Exchange.Data.Directory.Recipient.ADUser'. It's nice and all, but this is A) undocumented, so very hard to rely on with any faith at all, and B) requires at least two passes with Get-MailboxPermission to get the concrete info. If there are more than 1 users with granted permissions, it's 1 + however many users = # of times to run the command. I know it's my own problem, but man I find this stresses me out. The effort to have done it this way should have been placed somewhere else to do it better and properly. I sound spoiled and thankless having said this stuff, and do feel a little bad, yet I will take the risk and call it what it is - unacceptable.
These kinds of shortcomings don't just exist in PowerShell land either, they also bleed over into the web UI, where admins of all experience levels may encounter them. We have lots of FullAccess/SendAs that has to be managed using PowerShell and with GUID-type properties for the -Identity / -User / -Trustee properties. Dang it I was happy, and now I'm said. Not very but a little.
##EDIT 2##: With Get-RecipientPermission -ReadFromDomainController, it actually returns the mailbox object itself, as many times as there are users who are granted permissions! As in, it's not even returning the users with the permissions granted, it's returning the mailbox that is granting out those permissions. Aye aye aye.....
- Yes, the trick only works "as expected" when you use the -User or -Trustee parameter, without them it just returns the same object over and over again. And definitely not something supported, so I'd use it with care.
For the duplicate entries you're seeing, can you confirm that one of the objects represents a GuestMailUser? I've seen it happen with other object types occasionally, but that's very rare.
