Change in naming convention of user’s Name parameter
Published Apr 13 2022 09:05 AM 201K 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

196 Comments
Iron Contributor

Can Microsoft provide us with a list of other widely accepted standards that they intend to arbitrarily break in the near future so that we can start planning for the next fiasco?

 

 

Copper Contributor

@MSFrodo  DisplayName is not the same thing as name. It is not unique.
We use this in a Powershell script for about 60K mailboxes. So this is not really a sollution for us.

Iron Contributor

MS - are our concerns even being addressed?  We've had very little response from MS regarding this change and the responses that we have received from MS have pretty much been dismissive of our concerns, at best.

 

I know that MS is ISO certified, so I know that MS has a change management process in place.  We are your customers, we are your stakeholders.  Are the concerns of your stakeholders being addressed and reviewed during the change process for this change?  If so, can you please provide some feedback on this change (status, implementation timeline, etc.)?  Based on the limited comments from MS, it sounds like you (MS) are going to implement this change no matter what our concerns or issues are.  At least tell us whether that is true so that we can stop wasting our time by posting our concerns on this thread, which mostly go unanswered by MS anyway.

 

Iron Contributor

@Daniel_B  the problem is, we're NOT their stakeholders, unless we also own Microsoft stock. Microsoft's stakeholders are their shareholders. Everything they do is oriented towards improving shareholder value. Customers are just a resource used for that purpose.

Iron Contributor

Am I correct though that this change is/has started being implemented?

 

For the past 10 days or so, my onboarding scripts have been having problems migrating hybrid mailboxes for new users from our on-premises Exchange to EOL using New-MoveRequest.  I've had to revert to using the EAC GUI to migrate mailboxes since this issue started occurring (and these same mailboxes are migrated successfully when using the EAC migration interface, but they can't be migrated any longer using New-MoveRequest).  Today, I decided to investigate a little further and look into this issue and this is the error that I get now for New-MoveRequest:

 

"The operation couldn't be performed because 'XYZ' matches multiple entries"

 

And I KNOW that there are not multiple entries for these NEW users/mailboxes, otherwise I wouldn't be able to migrate the mailboxes using the EOL EAC GUI

 

Microsoft

Please check your Message Center

https://go.microsoft.com/fwlink/p/?linkid=2070717

 

To open Message center:

You can also use the Microsoft 365 Admin app on your mobile device to view Message center, which is a great way to stay current with push notifications.

 

Updated June 1, 2022: Based on customer feedback, we have made the decision to provide additional time for organizations to prepare for the change. We have updated the rollout timeline below. Thank you for your feedback.  

We're making some changes to the way Name parameter is being set in Exchange Online. We will be making a change to utilize unique ExternalDirectoryObjectId (EDOID) in the place of Name parameter in Exchange Online only.

 

When this will happen:

We will begin rolling this out in late June (previously late May) and expect to complete late August (previously late July).

How this impacts your organization:

After this change administrators may no longer be able to see subsequent CN value change in Exchange on-premises to be reflected in the object’s Name property in Exchange Online.

The updated naming logic would take effect only during new user creation. Existing users won’t get impacted in any way.

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).

What you can do to prepare:

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

For additional details please refer Change in naming convention of user’s Name parameter.

Update 11/8/2022 ***NOTE*** 

cmdlets could be used for EXO only users, and there is no way to modify names of directory-synced users on the Exo side.

Iron Contributor

So basically, we have a few weeks. Yay.

 

Iron Contributor

The sad thing is that we could have been preparing for this the entire month of May, if Microsoft would have just been communicative.

I still don't entirely believe that this will still even go through as described. The only updates that MS has been providing, have been reschedules - and not even the correct dates! There's obvious backlash, yet no justification.

Microsoft, you can do better.

Brass Contributor

Simple question for Microsoft.

 

Why?

 

More direct, why repurpose a critical, established, base field instead of creating a new field?

 

This change offers me zero benefit and a slew of headaches.  This is like the 3rd delay based on customer feedback.  Clearly this is the wrong approach.

Copper Contributor

@MSFrodo That Message Center article and the above info seem to have taken out the emphasis on hybrid environments, so I'm going to presume this does impact cloud-only customers, and my Name and CN will become my Azure AD ObjectID (which is what my mailbox EDOID is now).  It also seems to say that after the change date, unless we take action beforehand, we're going to wind up with non-standard CNs?  e.g., existing CNs will use Name, but new ones will be using EDOID?  I presume if I want all my CNs to be standardized, I'd better change them to EDOID beforehand, and ensure new ones get created that way as well?

Copper Contributor

@MSFrodo 
As I understand it the change will happen. And this command will no longer work;
Get-EXOCASMailbox -filter 'name -like "a*"'
To be honest we use this in our MIM agent, but could be in a script as well.
It is not the only command that is run. We also run Get-RemoteMailbox with the same filter. And can then match the result together. Because we have more than 60 000 mailboxes we can't really run Get-EXOCASMailbox in an foreach against the result in the Get-RemoteMailbox. It take many more hours than run them separately. And your suggestion in using DisplayName is not possible because that is not unique.
If you started to support query for alias with Get-EXOCASMailbox that could be a solution. But as of now I can't really see that you give us any working option.

Iron Contributor

My best guess is that Microsoft is doing this because they simply don't know how to do it another way in the time frame they've been given. There's a roadmap for implementing features to keep the feature churn moving and maintain shareholder value. The actual usefulness of the features is completely irrelevant. What matters is that Microsoft is SEEN to be doing things and changes are SEEN to be happening because that's what makes the cloud services seem valuable to those who neither know nor care about actual system administration. 

 

Iron Contributor

@MSFrodo - I have to step back and ask "Who does this impact?"

 

I went and reread the article post and it looks like this may only impact Exchange on-premises systems that create remote EOL mailboxes(?):

 


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.

If we have AD on-premises and sync our AD objects using AAD Connect, will this change impact us?  I ask because I also read:

 


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. 

So, I ran a test to see if the above statement posted by MS was indeed true (test.user is synced from on-premises AD and mailbox migrated using New-MoveRequest):

 

 

$arrRenameEOLmailboxes = @(Get-Mailbox test.user)
$arrRenameEOLmailboxes | % { $objTemp = $_ ; Set-Mailbox -Identity $objTemp.ExternalDirectoryObjectId -Name $objTemp.ExternalDirectoryObjectId }

 

 

And I get the following expected error:

 

The operation on mailbox "Test User" failed because it's out of the current user's write scope.
The action 'Set-Mailbox', 'Name', can't be performed on the object '<ExternalDirectoryObjectId removed>' because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.

 

Of course, we get that error because we sync some of our on-premises AD objects to the MSOL DB and so we can't make this change in EOL as stated in the original MS article.  I am left to question whether or not this change to the Name attribute will impact objects synchronized from on-premises AD in the first place?  Does this change only impact cloud-only objects?

Steel Contributor

I am just here to echo others' concerns.  Recycling the Name field is bad design.  I think changing the CN to a GUID makes a lot of sense.  I've seen weird things during merger migrations as a result of name conflicts and a fully unique CN would stop that and be entirely invisible to the user and the admin.  Recycling the Name parameter is going to break decades worth of scripting examples and is going to lead to endless confusion.  Kevin Marquette's suggestion of deprecating the field is the most sensible solution if the Name field is no longer going to represent a name.  Admins should always get *very* *clear* *errors* when they are scripting.

Microsoft

@Daniel_B the change will impact anyone' scripts using local AD attributes "Name" or "DistinguishedName" attributes to apply changes or startup processes in Office 365. They would need to update scripts to locate UPN, SMTP, etc.

Brass Contributor

@MSFrodo This is madness and so arrogant from Microsoft to their customers.

Businesses have spend so many hours to create scripting because it's the only solution in many cases, forced by Microsoft.

Now you want all this businesses to review all their scripting and spend again a lot of hours (and prone to error) because you are so arrogant to change a very common attribute. 

Why not create a new one or reuse another, less common attribute?
Why Microsoft, why?

Copper Contributor

@MSFrodo please could you answer my question about creating new accounts using:

 

New-ADUser -Name $Detailedname
 
will this variable now not work as it's 'First Name Last Name' not a 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

Does this change also affect the fields Id and Identity?

 

 

Microsoft

KirstenMichelle As per the latest MC post the change shall start rolling out from June end. However, please be ensured that we shall try to answer all the queries before implementing the change. Further, as mentioned in the blog post 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. The change is scoped to Exchange Online only.

Microsoft

@Bernd_Diehm Can you please elaborate on these fields and if parameters for any specific cmdlet are being referred to here?

Microsoft

@thx1200 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 as per their choice. 

Iron Contributor

@SHUikeyNone of your replies actually answer the questions being posed.

 

I see no indication that anyone at Microsoft in a position of authority over this change is even aware of our concerns. My only reasonable assumption at this point is that whoever approved this change thinks it's no big deal, and doesn't understand why it's harmful and disruptive. MS reps who've posted here don't seem to have any understanding of why this is a concern to customers, or why such a dumb decision was made in the first place.

 

Microsoft knows they've got us locked into their ecosystem and simply switching away from Exchange Online isn't a viable option for most customers. The long-term picture is not good though, because this is just one example of the general disrespect for the customer that Microsoft has been displaying for years now.  Eventually, these obnoxious and arbitrary disruptive changes will add up to a big enough problem that they push people away.

 

 

Steel Contributor

@SHUikey - That doesn't address what has brought up again and again.  Whether you can "still do it" is irrelevant if suddenly existing scripting that's been in place for over a decade could break as a result of this unnecessary change.

Copper Contributor

@SHUikeyMost CmdLets like Get-ExoMailbox, Get-Mailbox, Get-Recipient return fields named Id and Identity. The value in this fields is the same as the one in the Name field. As it is currently the SamAccountName from the local AD we use this as Key to match and sync account data. E.g. licenses are assigned by groups membership. So there is a exchange online mailbox - but no on premise remote mailbox. Scripts daily get all exchange online recipients and check the exchange on premise status of the account and create the remote mailbox if needed and get some information from HCL Domino Servers to configure the mail account. The unique key on premise AD is the SamAccountName, in HCL Domino a field called LDAPID and in Exchange Online it uses Identity. So is there another field were the SamAccountName is stored and accessible through Exchange Online CmdLets?

Copper Contributor

We do not have automation scripts as others here, so I am not sure how this would affect our org.   We are on a hybrid environment, we create our mailboxes on-premmget everything synced up to azure and then migrate the mailbox online.

 

Can we still run get-mailbox or get-recipient commands (or others that require the use of name) using the users name like get-mailbox joe.schmoe, we dont have to know a users ExternalDirectoryObjectId in order to run cmdlets against these users, correct?

 

Copper Contributor

Hi @The_Exchange_Team@MSFrodo@SHUikey 

 

 

According to the MessageCenter post MC365786 that was last updated on Jun 28, 2022 it says "Action required by Sep 1, 2022",

Can't see that this change have arrived in my tenant yet. Is it postponed or what is the status?

 

Kind regards

 

Mikael

Brass Contributor

What is the status of this change?

I need to know whether to continue monitoring and investigating the impact of this change to us, or ignoring it until a new message center notification is published.

 

Cheers

James

Copper Contributor

@Eds1989 FYI - it appears the change has taken effect on our tenant - this was noticed yesterday 07/11/2022.

Brass Contributor

I see it took effect in our tenant, as well.  Looking back at new employee accounts created, it seems to have changed around mid-day on November 2, 2022.

 

This tracks with Microsoft's announcement at the top about rolling out between September and December.  

 

I still have not been able to determine whether it affects my scripts or not.  The one place it is likely to is a collection of PowerShell scripts and SQL procedures to store mailbox permission and folder permission relationships in SQL Server so I can produce a report of what needs to be cleaned up on termination.  That process is at (or occasionally over) the very edge of my Exchange-admin-stayed-at-a-Holiday-Inn-Express-last-night developer skills, with potential merge/join relationships between multiple fields because not every interface provides the same data about a user.  Setting the Identity field randomly between the on-prem Name value and the cloud GUID doesn't help that complexity at all.

 

 

Copper Contributor

@SHUikey As the change is now active: It is not only the NAME field. It is also Id and Identity returned by Powershell EXO CMDLets.

Brass Contributor

Also, the switch from a meaningful name to a GUID is seen in mailbox delegation (for newly created delegatees) in Exchange Online Admin Center and in EXO Get-RecipientPermission:

 

Identity Trustee AccessControlType AccessRights Inherited
-------- ------- ----------------- ------------ ---------
Alexander Ruiz NT AUTHORITY\SELF Allow {SendAs} False
Alexander Ruiz Marketing Allow {SendAs} False
Alexander Ruiz Sales Allow {SendAs} False
Alexander Ruiz 79252acd-e474-408f-b78c-533591f80c82 Allow {SendAs} False

Newly created groups are only shown with a GUID. This is going to be a nightmare to manage... 

Iron Contributor

@skrubJust don't bother managing it. That's what Microsoft does...

Remember when cloud services were going to simplify management and reduce costs?

 

 

Copper Contributor

@skrub also on many other places in EAC there is now only the GUID. Like for the groups in organization relationship, mailbox delegation, etc. And we have not seen all.

 

This change might be neccessary, but the execution is terrible.

 

Brass Contributor

Same in our tenant! :facepalm:

 

@skrub @Bernd_Diehm I think the main problem is that the "-Trustee" parameter in "Get-RecipientPermission" checks against the UPN; but there is no UPN for groups! So the attribute "Name" is displayed as trustee, which is now this GUID since the change. Possible solution: Microsoft should use the attribute "DisplayName" instead of "Name" allover EXO.

Brass Contributor

DisplayName is not guaranteed to be unique, so you might get unpredictable or multiple results from a search on DisplayName.  DisplayName is often the kind of field I would expect to search with a wildcard (contains, starts with, etc.) just because of the vagaries of how those are generated and updated.  

 

All of the fields that Get-RecipientPermission searches on for Identity or Trustee are fields that are unique.

For identity: 

  • Name
  • Alias
  • Distinguished name (DN)
  • Canonical DN
  • Email address
  • GUID

For Trustee:

  • Name
  • Alias
  • Distinguished name (DN)
  • Canonical DN
  • Domain\Username
  • Email address
  • GUID
  • LegacyExchangeDN
  • SamAccountName
  • User ID or user principal name (UPN)

 

Iron Contributor

Cryptic random strings as identifiers are fine when people don't have to read them, type them, or remember them.

Names are things people have to read, type, and remember. Using GUIDs as names is objectively stupid.

  

 

Copper Contributor

The rollout being paused until 2023 doesn't quite fit with what we're seeing: Accounts created since the 1st of November are being impacted by this change.

Copper Contributor

Good point @RobinMalik - not sure when that update notice was added to this forum - are MS now saying that they have stopped any further implementation 🤷‍!?

Brass Contributor

Hello!

 

Despite the articel mentions that the change is postponed until beginning of 2023, we're affected by this change since 01. November 2022.

 

Affected are not only "Name" Attribute, but also "Id" and "Identity".

 

And not only mailboxes, but security-enbled DistributionGroups as well.

 

In EAC (old an new one) only the EDOID is shown, not the DisplayName.
This makes things difficult, especially for support staff.

 

 

Could you please explain why this is rolled out right now?

 

It would be great if customers get switch to disable this new behaviour tenant-wide.

 

Brass Contributor

Is this really being implemented now without any prior notice or planning? This is messing up our scripting. Would be great if we could get some feedback from MS @The_Exchange_Team about what is happening and if this will be rolled back.

Steel Contributor

It's almost like everybody here warning MS to not do this because they had a good reason.  Now only with a partial roll-out, they have to delay it already.  SMH.

Brass Contributor

We are also seeing this change in production.

 

What provision has been made for Powershell cmdlet output and GUI updates for this change? For example, the get-mailboxfolderpermission cmdlet now lists the Identity as the GUID (guid changed in example) with no other properties to ID the user (see below).

 

Also in the GUI the 'Manage Email Forwarding' screen just lists the GUID.

 

A blog is not a good enough forum to notify about such a large change that breaks so much existing functionally.

 

 

 

PS C:\WINDOWS\system32> get-mailboxfolderpermission <a recently created mailbox> | fl


Identity : 4ef243f0-ae9e-4b8f-8578-55cccd1c9567d:\
FolderName : Top of Information Store
User : Default
AccessRights : {None}
SharingPermissionFlags :
IsValid : True
ObjectState : New

Identity : 4ef243f0-ae9e-4b8f-8578-55cccd1c9567d:\
FolderName : Top of Information Store
User : Anonymous
AccessRights : {None}
SharingPermissionFlags :
IsValid : True
ObjectState : New

 

 

 

 

 

Copper Contributor

What we have recently discovered that Office profile cards are affected as well. We have been using custom attribute (cn from on-prem AD) as described here. And while we had mailboxes in Exchange on-prem, everything was fine and it was showing value from local AD cn attribute. However, once we migrated our mailboxes to Exchange Online, users started seeing GUID instead of expected value on some profile cards. So we realized, that this "name" change is affecting the profile card as well, event though we could not find it documented anywhere. Nevertheless, we are considering switching to one of "ExtensionAttributeXX" attributes as a solution, it just will require some changes in our on-prem automation.

Microsoft

@MrPink99: I am from EAC team and we acknowledge that the change in naming convention of user’s name parameter has impacted some scenarios in EAC [GUI] as well and has made the object entries human unfriendly. Since the change has already been made at the back-end, EAC team is currently quick fixing the mailbox delegation scenario after which we will show both the GUID and human readable entry for the admins to see.  The team, in the near future will also fix similar issues (including manage email forwarding) happening in other parts of the EAC portal.

Brass Contributor

It's good to see reply from @AdityaMukund  that you are looking at impact on EAC and remediating that.
@The_Exchange_Team Are you reviewing Exchange Powershell cmdlets to improve output from those that return only name.
i.e. get-recipientpermission  (we're now having to pipe the trustees into get-recipient)
and 'ManagedBy' attribute returned from Get-DistributionGroup



Microsoft

Hi @KevinGodfrey Could you please share why the current workaround of piping is not helpful?

Iron Contributor

Thanks @AdityaMukund and I wish that I didn't have to say this, but it would have helped if @The_Exchange_Team would have listened to us when we all tried to stress the problems that this was going to create.  I now have multiple users who are seeing GUID's instead of (new hire) Names.  And they don't care that Microsoft caused the issue, they just want it fixed.

Iron Contributor

The frustrating thing about this situation is that Microsoft was repeatedly told this was going to cause problems, and blindly forged ahead anyway, ignoring all concerns. Now the exact scenario we predicted would happen has happened, and MS team seems to be surprised.

 

It's really frustrating to have your concerns disregarded, but what's even more frustrating is knowing that even after this nonsense, the same problem WILL happen again. Because Microsoft seems to be institutionally incapable of learning from mistakes.

 

Why is this so hard? Why is it such a challenge for Microsoft to consider the impact on customers of arbitrary random changes?

 

 

Brass Contributor

@SHUikey In response to your question about piping.  If we run get-recipientpermission and there are say 120 Trustees, if we then pipe the output into get-recipient to covert the Trustees names into something intelligible we have to wait for 120 instances of get-recipient to run.
Previously the output of get-recipientpermission was intelligible.  Now for some Trustees it is and for others we see ExternalDirectoryObjectId
OK I know that I could find out the ExternalDirectoryObjectId of the recipient I'm interested in checking and then use the -trustee switch of get-recipientpermission to check for that trustee.
It's just that you have made something that was simple so much more difficult, particularly for access control admins who are not experienced Exchange Administrators and who are less confident with powershell, piping etc.  I've had to create a custom function for our admins to use, whereas MS should be anticipating and providing this.

Brass Contributor

@The_Exchange_Team: pls, make the powershell module more "human friendly" asap. Of course, we need also IDs for unique identification but names for humans are still (very) important.

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