Change in naming convention of user’s Name parameter

Why are you not just adding a `EDOID` or an `ID` property? By reusing the Name field in this way, it will be really hard to tell what code has been updated or not. 

I would much prefer that the Name field become read-only and eventually removed than reuse it for the EDOID. This will give very clear errors when used incorrectly. There are going to be lots of random admin scripts that break because of this. Even if we update everything, there are years of online examples and documentation that will be out of date.

Please get a Principal Engineer review on this from someone outside the team implementing this approach. And take into consideration the long term confusion this will create for customers.

This is a real problem.  Per multiple vendor recommendations (including Microsoft), we use Name field in External Applications/SAML.  Name field should contain name.  Recycling fields is flat file database era nonsense.  If a new field is needed, create one.  This is extensible architecture.  I suspect they wanted to change CN and a lot of internal coding linked CN and Name.  Instead of fixing the code, pass the problem off to the customer.

Where do we vote to stop this?

May I please endorse Kevin Marquette's comment - I feel very strongly that re-using an existing field that people are already using/relying on is just crazy - create a new field to use for this!

Kevin Marquette MVP
‎Apr 30 2022 02:02 PM
Why are you not just adding a `EDOID` or an `ID` property? By reusing the Name field in this way, it will be really hard to tell what code has been updated or not.

I would much prefer that the Name field become read-only and eventually removed than reuse it for the EDOID. This will give very clear errors when used incorrectly. There are going to be lots of random admin scripts that break because of this. Even if we update everything, there are years of online examples and documentation that will be out of date.

Kevin Marquette I can only like your comment once but I sincerely hope Microsoft considers your suggestion as a viable alternative.

This is a low-quality workaround for a problem caused by a previous low-quality workaround. Fix this the right way, don't arbitrarily repurpose data fields with existing meanings. This is like deciding to store email addresses in the middle name field. It's DUMB.

"We recommend that Administrators evaluate any scripts or other automation that may rely on the Name property and update them accordingly."

• April 2022 - Don't you think its too short of a notice
• Does it impact other objects like MailUsers, Distribution Groups, MailContacts , etc.
• Almost all cmdlets have 'Name' as the default output, and useful for a quick check without much of typing currently

        Get-Recipient "A A"
        Name RecipientType
        ---- -------------
        A A UserMailbox

        get-mailbox "A A"

        Name Alias Database ProhibitSendQuota ExternalDirectoryObjectId
        ---- ----- -------- ----------------- -------------------------
        A A A.A xxxPR01DG189-db020 1.979 GB (2,125,4... xxxxx..

• Many outputs like SendOnBehalf, and Manager fields, doesn't even store full details, relies solely on this
• Existing data vs. new data having mixed up values will cause lot of disruptions
• Any options for opt out, for companies having a robust system and doesn't get into this sync error often

A change this significant, and unintuitive, warrants some explanation as to the reasoning behind it I think.  It stands to reason that if Azure AD Connect is synchronizing values from on-prem and they are unique there, then they would be unique in the cloud as well.  Are you just trying to cut down on compute time for replication, or is there some kind of failure occurring regularly because the directory object is being renamed/moved with a change in CN?

Am I really going to start seeing that GUID twice in the output of Get-Mailbox, which by default shows Name and ExternalDirectoryObjectId?  Could it have something else included instead (like DisplayName)?

Given that Name/CN is the output of some cmdlets (some already mentioned by others, and AcceptMessagesOnlyFrom comes to my mind from get-mailbox), it makes it very difficult (or at least inefficient, increasing the number of calls to the cloud to resolve EDOID to Alias, etc.) to locate an on-prem user from EXO PowerShell output since EDOID isn't written locally.

Hopefully the goofy mismatch between old and new accounts won't be visible to end-users (I don't believe it would be).  But once Name goes read-only, I hope there aren't any Exchange admins out there who are divorced from an abusive spouse and just can't get rid of that remaining reference on their own account.

Why would a NAME field need to be unique? Why was that logic built into Exchange Online, and why are you still enforcing it? The actual fix would be to not require NAME to be unique.

Even two or three months notice is not enough time to identify everywhere this change can break functionality.

Please reconsider this change!

You want to change a common attribute like 'Name' into a Guid? It makes no sense.

And you will create a mess because you write: "Existing users won’t get impacted in any way". 
So we will end up in a mess with existing account a decent name and new accounts with Guid?
Why not use any of the your other unique fields of a mailbox you already have?
Like:
ExchangeGuid
SamAccountName
ExternalDirectoryObjectId
LegacyExchangeDN
ExchangeObjectId
Guid

You'll harm no one that way!
Again: Please reconsider this change!