Change in naming convention of user’s Name parameter
Published Apr 13 2022 04:05 PM 235K Views

Update (4/12/23): This feature was enabled in our worldwide and 21Vianet clouds in November 2022. All tenants in these clouds will see the changes. Rollout to our GCCH and DoD clouds has been paused until further notice. Please follow this space for any other updates.

We want to inform you about a change that we are working on. This change will be rolled out in a phased manner. The following is a more updated and detailed explanation of changes being implemented.

The Name parameter associated with a recipient within a tenant in Exchange Online should be unique. However, while we sync objects from Azure Active Directory to Exchange Online, the way Name parameter (system metadata) is being computed in the backend currently led to some system conflicts impacting reliability. We realized that the current method is not the best way to compute this parameter. Hence, we want to move away from the status quo to a more robust way of generating the Name parameter which is through ExternalDirectoryObjectId (EDOID) that ensures uniqueness in the system. All the long-term reliability enhancements in the backend would be done in line with this change.

EDOID value is unique. We’ll use this GUID as Name instead of synchronizing the Name from on-premises (when in Hybrid environment) or using the alias (if Name is not specified) to compute the Name parameter in Exchange Online. With this change the DistinguishedName (DN) value will also get impacted. To better understand how this will impact objects in a tenant where directory synchronization is enabled, consider the following example:

With this new change, when creating a new Office 365 (remote) mailbox from on-premises Exchange Admin Center, the Name field will no longer synchronize to Exchange Online.

NamePropChange.jpg

Before changes are implemented:
DisplayName: Jeff Smith
Name: Jeff Smith
Alias: jsmith
DistinguishedName: CN= Jeff Smith,OU=(tenant).onmicrosoft.com, OU=Microsoft Exchange Hosted Organizations, DC=NAMP283A001, DC=PROD,DC=OUTLOOK, DC=COM
ExternalDirectoryObjectId: 12313c53-fff7-46d4-8b83-71fb317d1853

After changes are implemented:

DisplayName: Jeff Smith
Name: 12313c53-fff7-46d4-8b83-71fb317d1853
Alias: jsmith
DistinguishedName: CN= 12313c53-fff7-46d4-8b83-71fb317d1853, OU=(tenant).onmicrosoft.com, OU=Microsoft Exchange Hosted Organizations, DC=NAMP283A001, DC=PROD, DC=OUTLOOK, DC=COM 

In this example, both the Name and DistinguishedName are updated with the EDOID value.

Note: This would also mean that any subsequent CN value change in Exchange on-premises will not be reflected in the object’s Name property in Exchange Online.

Will this change not allow modification of the Name property?
As a temporary workaround, customers can still use Exchange PowerShell cmdlets (New-MailUser, New-Mailbox, Set-User, Set-MailUser, Set-Mailbox with -Name parameter) to update* the Name property in Exchange Online. Since the cmdlets ensure uniqueness, it would allow the operation to succeed only when the passed Name is unique in the tenant.
*Updates to Name parameter using the above-mentioned cmdlets will only work for users created in Exchange Online. These cmdlets won’t work for users who are part of a hybrid environment.

How will the change impact new and existing users?
The updated naming logic would take effect during creation of new recipient objects (mailbox, user, group, contact) when the change is coming from AAD. However, if the recipient object is mastered in Exchange Online or is directly created there, then the Name which is given during creation will be honored. Since Id/Identity in Exchange Online is a field derived from DistiguishedName it will also reflect EDOID values going forward. If you want to uniquely identify a recipient, you can still use the value of Identity for all practical purposes. However, if visual representation of something similar to Name is preferred, it is advised to take dependency on alias/DisplayName instead. Lastly, existing users won’t get impacted in any way; they will continue to reflect the same Name as was before the change was implemented.

Please note that since we will start using EDOID as Name in Exchange Online, we shall stop allowing changes in CN to reflect in Name property in Exchange Online for all users (both new and existing). 

We recommend that Administrators evaluate any scripts or other automation that may rely on the Name property and update them accordingly. Additionally, we also encourage Administrators to take dependency on DisplayName if GUID in Name parameter does not serve the purpose.

Exchange Online Team

200 Comments
Brass Contributor

We use PowerShell scripts to create Shared and Room mailboxes.
This command is executed on our Hybrid server, where the name (stripped from unwanted characters) is also used.


New-RemoteMailbox -Shared -Name $ResourceName -DisplayName $DisplayName -SamAccountName $SamAccountName -UserPrincipalName $UserPrincipalName -PrimarySmtpAddress $PrimarySmtpAddress -RemoteRoutingAddress $RemoteRoutingAddress -Alias $Alias -OnPremisesOrganizationalUnit $ResourcesOU -ErrorAction SilentlyContinue)

 

Will this be effected? Do we have to change our scripting?
The name attribute is only used during creation, isn't used anywhere else.

Microsoft

That script you provided should not conflict with this change. Anyways ADSync will not sync the -DisplayName -Name field from AD. It will use a GUID in Office 365.  

Exchange Online uses "DisplayName". Azure AD or active directory uses "Name" but this name is not populated on the GAL. I potentially forsee an issue when running scripts for specific object by -Name Attribute rather than UPN. 

Brass Contributor

@MSFrodo  - the DisplayName also won't be synchronized in a hybrid environment?  The article above only indicates that the Name field will not synchronize. Isn't the Displayname a key property for the GAL? Can you please clarify? Thx!

Brass Contributor

"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

 

Microsoft

@Rob_R YES! correct. I edited the comment. :facepalm: 

Bronze Contributor

Will you rename the "Name" field as well? As having field "Name" but containing EDOID sounds not so logical.

Not sure, but could there be companies which are using Name field as an address policies?

 

Was this really the only option to fix this? As after this there would be quite confuses mailboxes when old mailboxes have old name format, and then new mailboxes have something else. Or are you planning to rename old mailboxes as well, even those which are duplicates? What about other objects, will this impact to them as well, like MailUser, Contacts etc..?

Brass Contributor

Hi

Will you update Exchange commands to return useful data once Name becomes a non-readable string for end-user ?

Manager from Get-User, GrantSendOnBehalfTo from Get-Mailbox and many others.

We have many self-service tools exposed to users to do various reporting in Exchange Online, many of these tools take direct output from the Name attribute (so no other output is available)

Iron Contributor

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.

Iron Contributor

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

Brass Contributor

A notification arrived at the message center on 4/30/22.
The change deadline is 5/31/22.
This article was updated on 4/28/22.
When is the updated deadline?
After all, the deadline for changes is short. Also, I don't think you should assign an EDOID to the Name property.

Iron Contributor

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.

Brass Contributor

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.

Brass Contributor

So if a colleague marries (or divorces, for example) and her last names changes, or on account creation there is a spelling error that needs to be corrected, we need to get our Frontoffice team to make a change in the appropriate fields in the on premises environment and that is not the end of it, we need to get our Backoffice team to make those same changes in the Exchange Online environment (as our Frontoffice team does not have those permissions). Or am I missing something here?

Brass Contributor

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?

 

 

Copper Contributor

I would strongly urge the Exchange Team to reconsider this change as other have suggested. I'm of the opinion this is going to create more problems than it solves. Surely there is a better way to address this issue.

 

 

Copper Contributor

This is as worthless as a NFT

Copper Contributor

Does this affect Azure AD Connect or on prem Exchange only?

Copper Contributor

Will this change affect the users that are created in On-Site Active Directory and synchronized with Azure Active Directory via the Azure Active Directory Connector?

Copper Contributor

Will this cause problems for SAML applications? They pull in information from Azure AD and not Exchange Online. Can there be clarifications on this?

Iron Contributor

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.

 

Copper Contributor

This doesn't make any sense.  I've had 3 or 4 sync conflicts in 8+ years, all easily fixed.  This 'solution' will cost me at least a week of reviews.

Brass Contributor

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.

Iron Contributor

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.

Brass Contributor

Leave it to MS to use a common AD field that effects everything we set up code based into an ambiguous mess. Doesn't it make sense to make the unique field something that isn't mandatory to set up in programmatically creating AD Accounts but can be a property of the main account (like suggested above, ID for instance).  

 

Giving us a month to prepare without some kind of testing to see how our environment will be effected seems like a recipe for disaster. 

Copper Contributor

As I'm seeing others say - I don't understand why the problem is being "solved" in this way, and it's not clear when the updated deadline is even though the article mentions one. 
It seems that this change has the potential to disrupt some of the scripts that we use, and the from the article I do not understand what I need to do in order to get my scripts "ready" for this change. 

Does anyone have information on the updated deadline for this? 

Copper Contributor

Wow! Perfect example of MS teams working in a vacuum!

 

There is no information provided on how, or if, this affects scripted processes that sync on-prem AD with Azure AD.

We have custom automation that integrates with our ERP system and creates and updates on-prem AD accounts nightly, which then sync out to Azure AD. It's currently one-way.

 

Will the fact that we don't currently populate the corresponding AD property (ms-DS-ExternalDirectoryObjectID) create issues when we sync out to Azure AD?

 

Do we now need to pick this up when Exchange accounts are created and synch EDOID back to on-prem accounts?

Copper Contributor

This change doesn't make sense. Why would the DN and Name suddenly be changed to a random ID when it's always been the Name in on-premises AD?

Brass Contributor

I wouldn't call it "AD Sync" if it's going to write different values in the attributes in Azure. Come on Microsoft, this is ridiculous. This isn't going to fix much, but it is guaranteed to break a lot of things.

Iron Contributor

Because they want to pivot  in their current journey to accommodate the latest asks from stakeholders so they can close the loop" and synergize while leveraging blue sky opportunities being brought to the table by scalable vertical deep dives.

Copper Contributor

...instead of synchronizing the Name from on-premises...

...when creating a new Office 365 (remote) mailbox from on-premises...

If I read between the lines here, especially the reference to "sync objects from Azure Active Directory to Exchange Online", I'm guessing that this change is happening at that point?  So for cloud-only customers, it will mean when new accounts are created with a mailbox, they will have in Exchange Online:

 

ExternalDirectoryObjectId = AzureAD's ObjectID

Name = EDOID

DistinguishedName's CN = EDOID

 

And that afterwards, Name can be changed, but the CN component of the DN cannot?

 

Or is this being done in AzureADConnect somehow, and will have no impact on me?  You've tagged "Hybrid" specifically, and your examples are all hybrid, so maybe this means it won't affect me?

Copper Contributor

This seems a very half assed way of handling a minor issue. Why on earth are you targetting an attribute that is commonly used and has been so for years.

We sync around 65k staff and 350k students and make use of the name field and have done so for years, now you're saying we need to investigate and remediate your change in the space of a few weeks. This is ludicrous and puts a ridiculous amount of pressure on us.

A change this impactful should have a much longer lead time and advance notice.

Brass Contributor

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!

Brass Contributor

I hope Microsoft will reconsider this, as it seems poorly thought-out conceptually, and will only lead to massive confusion going forward.  Name should be some derivative of a human-friendly name, not an ugly number field.  Why not simply add (yet another) field to the EO record that we admins can gleefully ignore as it doesn't relate to our day-to-day work, instead of mucking about with a field that we may have built dependencies on in our scripting?  Yeah, great, I SOOOO look forward to trawling throught all my bits and bobs of scripts looking for spots where I've used Name and changing them to use something else.

Iron Contributor

I agree with so many comments on here, especially with @Kevin Marquette.  It would cause much less of an issue if MS would just create a new attribute and go that route versus renaming an existing (and often used) attribute.  We have dozens of onboarding, offboarding, maintenance, etc. scripts out there that run on a schedule, now we have to go through each one to make sure that they all continue working?  And then combine that with the fact that this change will only impact some (new) objects, not existing ones!  Which sound to me like we'll have to also come up with some new try/catch stuff to test whether an object is using the old Name attribute or the new EDOID attribute.

 

Copper Contributor

Like many others here we have many scripts that uses the name attribute. Since we have the same value for Name and Alias, would this still work:

 

Name Before : D34882

Alias Before: D34882

 

Name After: Cryptic GUID

Alias Ater: D34882

 

would this still work: Get-mailbox D34882 ?

Brass Contributor

the way Name parameter is being evaluated currently led to some conflicts.

 

Expect a landslide of support tickets coming your way Microsoft. You can't make a major change like this on such short notice without a better reason as to WHY it needs to be done. Years and years of work have been spent utilizing Name and you want to make us all jump through hoops to accommodate this for little to no explanation as to why it has to be done so quickly and why we must fix our own scripts when you were the ones that designed this parameter evaluation. 

Copper Contributor

Has there been an updated announcement on this change, yet @The_Exchange_Team?  If so, can a link be posted, please?

Brass Contributor

There are over40 underused extension attributes where this "new" ID can live.  To purposefully cause issue by using a common variable is like Russian Roulette - let's see how much destruction we can cause. 

Iron Contributor

It's MS, they should be able to just create a new attribute, right?

Microsoft

To create a mailbox, you must need: Alias, Email Address, Display Name. 

To create an object: (user) its required to have a username UPN, Name, "First Name", "Last Name."

To create an object: (invited user): Its required to have: Name, Email Address, First Name, Last Name. 

 

It would be nice to understand "how not syncing the "name" attribute and/or DN" could affect the scripts. 

Iron Contributor

You’re only asking about new user/object creation and to me, it looks like this change impacts more than just the new user/object creation cmdlets. The most significant impact for us is with what I call maintenance scripts, not necessarily new object creation scripts. That’s minor for us, we only have a few scripts for onboarding, and we could probably update/test those in a couple of hours.

 

We’re Exchange hybrid and AD hybrid, so we sync portions of our on-premises AD with Azure AD and keep an Exchange hybrid on-premises mostly for management and on-premises purposes (admin accounts, service accounts, SMTP, etc.), basically items that we don’t sync with Azure AD for security reasons. We do have AD-only objects, AD-synced objects, and cloud-only objects in play.

 

To your question about new object onboarding, we still do it old-school and follow old-school best practices for our users, resources, and shared mailboxes. We disable AAD sync (so that a new mailbox doesn’t get created in EOL before one is created locally and the attributes synced to Azure), then we create the new AD user with the needed attributes, assign a local mailbox and set some additional attributes locally, enable AAD sync then initiate a delta sync and then a New-MoveRequest to EOL (all scripted and initiated/fed from input coming in from HR/Recruiting via API’s).

 

So, where does an attribute like Name come in to play for us and where does this impact us the most? That thing called a pipeline and filtering. Numerous maintenance scripts that we’ve written over the years use the pipeline to filter objects based on the Name attribute (we use that because we have naming standards at the Enterprise level so in many cases, we can leverage our Naming syntaxes for filtering). Many of our automated scripts are 1,000’s of lines of PS code so I can’t post most of the code here or it would take up a lot of space, but we use the attribute Name all over the place.

 

Some brief examples, first start with a query against on-premises AD to retrieve some AD info into an array (often SearchBase is set to a specific OU, but this example is AD root, represented by a preset string $strADroot:

 

 

$arrAllADobjects = @(Get-ADObject -Filter * -SearchBase $strADroot -Properties objectCategory, UserPrincipalName, accountExpires, mail, proxyAddresses)

 

 

After some filtering and other stuff, run a For-Each loop against each object in the array to check the EOL mailbox for Legal Hold, forwarding and things like that:

 

 

(Get-Mailbox $_.Name) | ? {($_.LitigationHoldEnabled -eq $true)}

 

 

After this change, will the above still work for both the old Name attribute and the new EDOID when the array is created from objects queried from an on-premises AD?

 

Also, for example, if our company name was "ABC" and we prefaced all our shared mailboxes with the company name such as "ABC Human Resources", it sounds like the following will no longer work for newly created shared mailboxes after your change:

 

 

Get-Mailbox -ResultSize Unlimited | ? { $_.Name -like "ABC*"}

 

 

Will the above still work after your change?  Also, does this change impact other cmdlets like:

 

 

Get-MailboxPermission $_.Name

 


To me after reading the article, it appears that these things must all be updated in our scripts when MS makes this change and if it only impacts new objects and not existing objects, then we need to see how it works in action and be able to create pipeline filters based on both the (old) Name and (new) EDOID values (since this will only impact new objects and not existing ones). Otherwise, our PS filters won’t work properly, and we’ll have things like permissions being assigned to mailboxes that aren’t correct, etc. We’ll end up setting an attribute incorrectly based on bad pipeline filters and then the dynamic Azure AD groups won’t update their memberships properly, then licenses won’t be assigned correctly, etc.

 

And I’d have to find it, but yes, we also use DN’s in one or two places along with the AD attribute legacyExchangeDN, I just don’t remember which scripts use that ATM.

 

Can you ensure that this change won’t impact the PS pipeline filtering? That’s the largest concern for us and probably impacts most Enterprise-level customers in some way, so if you can guarantee that pipelines will still work as-is after this change, then for me, I’m all in for this change, otherwise:

 


@The_Exchange_Team wrote:

Will this change not allow modification of the Name property?
Customers can still use Exchange PowerShell cmdlets (New-MailUser, New-Mailbox, Set-User, Set-MailUser, Set-Mailbox with -Name parameter) to update the Name property in Exchange Online. Since the cmdlets ensure uniqueness, it would allow the operation to succeed only when the passed Name is unique in the tenant. 

If MS can’t guarantee that this change won’t impact us, I’m guessing the best and easiest approach for us (based on the above MS statement) would be just to write some more PS code to get all mailboxes with Names that are GUID’s using regex and then use Set-Mailbox to change the Name attribute in Azure/EOL back to what it is (or at least used to be) after MS assigns a GUID to the Name attribute. This whole thing may be an inconvenience to customers like us but at least doing that is easier to do in a few lines of PS code then to sift through dozens of scripts (many with 100’s or 1,000’s of lines of PS code in them) and replace all of the code that filters on the Name attribute.

 

Copper Contributor

This is ridiculuous, we manage more than 750+ automation script using git, and how you telling us we have to review all of our automation script? And to make it worse, we have to finish review it in the matter of weeks?

Brass Contributor

Is this still going to happen? There have been no updates or replies back to anyone that I can see. 

Microsoft

Its' postponed it looks the next update will be at the end of April.

I suggest testing scripts to collect data from local AD using "displayname" or UPN variables to be use for scripts against Exchange Online or AzureAD for Identity.  

Iron Contributor

As in a month ago?? or April 2023?
We need a little bit more transparency on this. - We have no idea whether we should start focusing our time on "fixing" our scripts, instead of working on already scheduled projects/tasks.

Iron Contributor

Agreed, is that April 2023 (since it is almost the end of May 2022)?

 

And displayName doesn't always work (displayName doesn't always match the Name attribute).  For us, Name is legal name, and we also allow our users to have a preferred first name (so displayName may also be comprised of a preferred first name), last name is always legal name.

 

Also, we use a few suffixes for our displayName attribute that is updated based on other AD attributes and manage via automated scripts (i.e., IC for independent consultant, etc.).

 

UPN will work in most cases but not all, there are exceptions.

 

Copper Contributor

Do we have any further developments or official documentation as to when this is going to be implemented, please?  I note there are previous references to a delay, but does anyone have a link to any formal MS confirmation of this or is it still "technically" planned to commence 31st May 2022?

Copper Contributor

According to Message ID: MC365786 this work is due to take place late May and expect to complete late July so it could be implemented any time between now and the end of July. this update was produced a month ago and there have been many comments above all with good points left unanswered by MS. the only update we've had mentioned an update on this matter being available at the end of April but that comment was made on the 20th of May (??)

 

will this affect new starter scripts and new mailbox creation such as:

New-ADUser -Name $Detailedname
 
will this variable now not work as it's 'First Name Last Name' not some random GUID? or will we still be able to populate AD with this information, but pulling it down from Exchange online will require knowing the new 'Name' GUID?
Copper Contributor

After this change is implemented, can I still use the following command;
Get-EXOCASMailbox -filter 'name -like "a*"'
The CASMailbox-command does not support Alias or SamAccountName. So as far as I know I can only use name.

Microsoft

@MBerton70 You can use 

Get-EXOCasMailbox -filter "DisplayName -like 'a*'"

The name is only visible in Azure and the CN on the attributes of the mailbox. 

 

 

Co-Authors
Version history
Last update:
‎Apr 12 2023 08:12 AM
Updated by: