ObjectGuid, SamAccountName, and DistinguishedName. The Exchange Team disclosed the evaluation in an August 27 post asking customers to document where those values appear in scripts, provisioning systems, reports, applications, and operational runbooks.There is no announced retirement date, replacement contract, or migration plan. Microsoft says it has made no decision and that the request for survey responses is intended to establish how much breakage a reduction in supported identifiers could cause. Still, the request is a useful warning for Exchange administrators: code that treats old Active Directory-shaped attributes as permanent Exchange Online interface contracts deserves an inventory now, while there is still time to influence the decision.
Microsoft’s notice is narrowly scoped to the Exchange Online directory. It does not announce a change to Windows Server Active Directory, Exchange Server, or the underlying on-premises attributes that hybrid organizations synchronize. That boundary matters, but it does not eliminate risk for hybrid automation: many operational scripts begin with an AD identifier, then pass it to Exchange Online PowerShell to find or modify the corresponding recipient.
No independent outlet had reported additional implementation details or a timetable as of August 28. The substance of the story remains Microsoft’s survey, rather than a committed deprecation.
The Three Identifiers Carry Different Kinds of Risk
DistinguishedName is the easiest property to recognize in legacy administration code. A value such as CN=Jane Doe,OU=Users,DC=contoso,DC=com identifies both an object and its place in an Active Directory hierarchy. It is useful for on-premises lookups, but it is also inherently tied to the directory structure. Move a user between organizational units, rename the object, or change the directory naming layout, and the distinguished name can change.
SamAccountName has a different legacy. It is the familiar short logon name behind forms such as CONTOSO\jdoe, and it remains common in help-desk tools, HR-driven account processes, and scripts written when Windows domain credentials were the primary user identity. It is readable and convenient, but it is a poor universal key for a cloud service because it carries domain assumptions and can collide across separate on-premises forests or organizational boundaries.
ObjectGuid sounds like the safer choice because GUIDs are designed to be unique. In traditional Active Directory, Microsoft’s own Windows documentation describes the object GUID as stable even when an object’s distinguished name changes. But Exchange Online is no longer simply an exposed copy of an on-premises LDAP directory. A script can encounter several GUID-like values—an Active Directory object GUID, an Exchange GUID, a mailbox GUID, and an Entra directory object ID—and treating them as interchangeable is already a source of fragile automation.
The practical takeaway is that organizations should not answer Microsoft’s survey with only “we use GUIDs.” They should document which GUID is stored, which system creates it, which Exchange cmdlet or API consumes it, and whether the value must survive a mailbox move, a user rename, a tenant-side restore, or a hybrid identity change.
Microsoft Already Points Administrators Toward Cloud-Native Keys
The current documentation for Get-EXORecipient illustrates the direction of travel. Microsoft lists several values that can resolve a recipient through the -Identity parameter, including distinguished name and SamAccountName, but recommends a user ID or UPN, or a GUID, for best performance. That flexibility is precisely what the Exchange Team is now reassessing.
For application integrations, Microsoft Graph exposes the Entra user id as the user object’s unique identifier. Microsoft’s Entra guidance specifically tells developers to use the user object ID as an immutable identifier rather than a UPN or email address. UPNs and primary SMTP addresses remain practical lookup values for people and operators, but they are business-facing attributes that can change during name changes, tenant consolidations, rebrands, and domain migrations.
Exchange Online also exposes ExternalDirectoryObjectId in supported mailbox administration interfaces. Microsoft’s Exchange mailbox endpoint documentation defines it as the Microsoft Entra ID object GUID for the mailbox. That makes it a particularly important property to audit: it may be the cloud-native identifier already available in Exchange tooling, but it is not automatically a drop-in replacement for every use of ObjectGuid.
Administrators should also resist a tempting but dangerous shortcut: replacing every identifier in a script with a UPN. A UPN is readable and easy to test interactively, yet it is mutable. Microsoft’s own Entra documentation warns developers against using UPNs or email addresses as immutable application identifiers. A rename that should be routine can otherwise turn into failed offboarding, missed mailbox permissions, or an integration that silently creates a duplicate record.
Hybrid Environments Need to Separate Two Identity Planes
Microsoft explicitly says the survey does not signal changes to on-premises Active Directory or Exchange Server. Organizations should take that statement at face value: an AD objectGUID, sAMAccountName, or distinguished name can continue to be appropriate inside the on-premises directory and its management tooling.
The complication begins at the handoff to Exchange Online. A hybrid script might locate an employee in Active Directory by SamAccountName, retrieve the AD object GUID, and then use one of those values to target Get-EXORecipient, Set-Mailbox, group membership tasks, or reporting exports. If Exchange Online later narrows its accepted identifiers, the AD lookup may keep working while the Exchange Online operation fails.
That is why the right remediation target is not necessarily the entire script. It is the boundary where an on-premises identifier becomes an Exchange Online identity selector. Teams should identify those boundaries and determine whether they can query Exchange Online or Microsoft Graph using a supported cloud directory ID, then retain a deliberate mapping to the on-premises account where hybrid processes need one.
Do not change Entra Connect source-anchor design, rewrite onPremisesImmutableId, or alter Active Directory synchronization rules because of this survey. Microsoft has not proposed any such change. The immediate work is discovery and documentation, not a directory migration.
What to Inventory Before Responding
The Exchange Team’s survey is aimed at customers, partners, and solution providers because third-party dependencies are likely to be the difficult part. A clean PowerShell script can be revised quickly. A provisioning product, ITSM connector, identity governance workflow, archived CSV export, or vendor-hosted application may have an identifier hard-coded far beyond an Exchange administrator’s direct reach.
Start by searching repositories, automation accounts, scheduled tasks, Azure Automation runbooks, CI/CD variables, reporting queries, and exported configuration for the exact property names. Include casing variants such as objectGUID, sAMAccountName, distinguishedName, DistinguishedName, and fields that store DOMAIN\username rather than naming SamAccountName directly.
For every result, record the operational consequence rather than merely counting occurrences:
- Identify whether the value is used to find an Exchange recipient, join records between systems, grant permissions, provision a mailbox, or produce a report.
- Record whether the workflow runs against Exchange Online PowerShell, Microsoft Graph, the Exchange admin center, a REST endpoint, or a third-party product.
- Determine whether the identifier is only displayed to an administrator or is required as a programmatic input that can stop a job.
- Capture the cloud-native values already available for the same object, including Entra object ID,
ExternalDirectoryObjectId, UPN, primary SMTP address, and Exchange GUID where relevant. - Test whether the workflow remains correct after a user rename, SMTP address change, organizational-unit move, or domain suffix change.
The last point is where many inventories become meaningful. An identifier can resolve successfully in today’s tenant and still be the wrong key for a process that must track a person across organizational change. Conversely, an old identifier might be indispensable to a narrow vendor integration with no supported alternative. Microsoft’s survey is seeking precisely those cases.
The Survey Is the Window to Ask for a Real Migration Contract
Microsoft’s post asks what alternatives, notice periods, and migration help customers would need. Administrators should be specific. “Please do not remove this property” is less useful than identifying the cmdlet, workflow, object types, scale, and recovery requirements involved.
A productive response would ask Microsoft to publish an affected-command matrix, identify whether the properties would disappear from output, stop resolving through identity parameters, become blank for new objects, or be removed only from particular APIs. Those are materially different changes. It should also request a long overlap period, tenant-level detection or reporting, and an officially supported mapping between deprecated values and the recommended replacements.
The key unanswered question is whether Microsoft intends to reduce only lookup aliases or to alter the properties returned by Exchange Online recipient objects. The first case breaks calls that pass a legacy identity to a cmdlet. The second can break inventory pipelines, data warehouses, and applications that persist Exchange output. Microsoft has provided no answer yet.
For now, Exchange Online administrators should treat the August 27 survey as an early architectural signal, not an emergency. Inventory where ObjectGuid, SamAccountName, and DistinguishedName cross into Exchange Online; preserve evidence of workflows that lack a safe alternative; and use that evidence in Microsoft’s survey before the service design is settled.