Change in naming convention of user’s Name parameter

The_Exchange_Team Brevity.. not my strong suite but gonna toss in my two cents. I submitted a ticket a bit ago related to this change. as you can probably see from this thread, a lot of people are upset, and this is continuing to impact people. I, like many, found out about the change in December.

The short is, there needs to be some consistency in how things are displayed/return across the Exchange realm, and my ticket is really just the start of that conversation. Tons of other folks are reporting those concerns here in a variety of ways. I'm just going to add my 2 cents.

Example:

Get-MailboxPermission uses the 'user' property to return what SP is given some permissions on a mailbox. At least for us ( we have a pretty standard AD connect setup), it seems to report back the 'displayname' of a user, which in Azure AD is just reported as the 'name'.

Get-MailboxRecipient returns EDOID for newly created/synced objects. 

Prior to this change, I think these both were just the same on prem 'name' property. Get-RecipientPermission (used to determine send-as) uses the trustee property to determine if a SP has send-as permissions on a recipient. It reports back the EDOID now as that is the 'name' on newly created things. 

(We have an application that would report back on a single line if a group or user had full access, and send as permissions, which was a common setup for certain styles of accounts we have).

However, I was reading here: EXO's "User" and "Trustee" properties returned from Get-Mailbox/RecipientPermission - Microsoft Community Hub that it 'should' return a UPN, which I've not found to be the case for our environment. Additionally, there's a trick that mentions using the ReadFromDomainController, but this has only returned the user tied to the mailbox (with additional properties) and not necessarily the users/groups we are looking at which have those permissions. Maybe I'm misunderstanding that thread but

Get-RecipientPermission -Identity $Identity -Trustee $ObjectIDTrustee -ReadFromDomainController

returns the user object of $identity for me. Likewise,

Get-MailboxPermission -Identity $Identity -User $ObjectIDUser -ReadFromDomainController

also returns the user object of $identity for me, not the SP that has been given permission on the mailbox.  I may have to run these tomorrow with a fresh brain as it's been a long day :).

Maybe I'm just off the mark here, but it just feels like it's all over the place. Is there any particular reason why these two cmdlets (and others that deal with really, returning ACE/ACL style objects) don't return values that might be more consistent for ease of use? I know some folks here aren't liking ObjectIDs, but I'd be perfectly ok with an ObjectID being returned on these two commands. Sure, I'll need to do an additional command to get more friendly info, but I'm ok with that. Even better, return a more rich object (or property) that includes more than an object ID so its immediately useful.  I know changing things is really hard and to not break things is even harder, but I think MS can do better here. When we run cmdlets like Get-MailboxPermission, and Get-RecipientPermission, we want to be able to identify the unique object it's that has the access. Right now, this is actually possible with Get-RecipientPermission, but not with Get-MailboxPermission (at least in our environment). Also somewhat interesting that both of those cmdlets return a SID that I'm not sure I know where it comes from (UserSID/TrusteeSIDString). This value is not from on prem and it's not the same Security Identifier reported in graph either. Sometimes, there's a need to query these and resolve the actual 'identity' or SP this is referring too and having things mean different things everywhere makes this incredibly challenging for PowerShell Developers.

To me, it seems like for each 'user' or 'group' (or SP) that is given a permission, it might be better to return a property that is more consistent and is a hash table with multiple bits of info. At the very least, aligning these property names and referencing the EODID/ObjectID value would be great. For others, it might be better to expand upon that, and return that hash table that maybe includes other values, so they can be used immediately without an additional call to Graph. Also simply aligning the names (MailboxPermission uses User and RecipientPermission uses Trustee) would be good. Consistency is going to help end users, developers, and admins a lot here when returning similar types of objects with commands. This is one of the reasons the AD module on prem works so well for a lot of things, because it was definitely built with consistency in mind. I'm happy to talk more about it with anyone who's willing to listen at MS -people build apps and processes around these things.