A Genuine Step Forward – With Some Sharp Edges
If you manage a Microsoft hybrid environment, you are familiar with one of its more persistent frustrations: even after migrating all your mailboxes to Exchange Online, you still depend on an on-premises Exchange Server. Not because you actually need local mail infrastructure, but because it is the only official Microsoft software to safely edit email addresses, create synchronized mailboxes, and more. With Exchange on-premises, you’re basically running a humongous enterprise system to utilize a tiny management UI.
Microsoft’s answer to this has been a long time coming, and it arrived as a generally available feature in late 2025: the ability to transfer the Source of Authority (SOA) for Exchange attributes from on-premises Active Directory to Exchange Online, on a per-mailbox basis. The idea is straightforward: once you flip the switch for a given mailbox, you can manage its Exchange attributes directly in Exchange Online PowerShell or the Exchange Admin Center, without touching on-premises at all.
This is a meaningful step toward decommissioning that Last Exchange Server. As we started seeing the SOA switch picked up among our clients, we implemented support for the SOA switch in EasyEntra – and went deep on the feature in the process:
- how it works under the hood
- where the boundaries are, and
- where the documentation leaves things out.
This post shares what we found. The rough spots are real, but they are manageable with the right preparation.
Why This Feature Exists
The root problem is a design artifact of how Exchange Online and on-premises Active Directory have historically divided responsibility. In a hybrid deployment, Exchange Online hosts the actual mailboxes, but the canonical source of truth for Exchange-specific AD attributes – proxyAddresses, mailNickname, msExchHideFromAddressLists, extensionAttribute1-15, and many others – has always been on-premises AD. Changes must flow through on-premises Exchange Server cmdlets, which write to AD, which then synchronizes to Entra ID via Connect Sync or Cloud Sync, which finally propagates to Exchange Online.
The most sensitive of these is proxyAddresses. Managing this attribute carefully – not forgetting the case-sensitive “smtp:” prefix and avoiding duplicates – requires Exchange’s own validation logic (or a 3rd-party tool, like EasyEntra). Administrators who have tried to edit proxyAddresses directly in AD or ADSIEdit know the pain with hard-to-troubleshoot NDRs and unpredictable consequences. The on-premises Exchange Server acted as the gatekeeper for this logic.
With the SOA transfer feature, that gatekeeper responsibility moves to Exchange Online. Set-Mailbox and the Exchange Admin Center now apply the same validation and business logic, but against the cloud mailbox directly. The AD object for the synced user is effectively demoted to an identity container – name, UPN, department, and the like – while Exchange attributes are owned by the cloud.
The feature is being rolled out in two phases. Phase 1, which is now generally available, allows per-mailbox opt-in by setting the IsExchangeCloudManaged property to true. Phase 2, which is not yet available, will introduce automatic write-back of changed Exchange attributes to on-premises AD. More on why that distinction matters shortly.
Edge Cases Worth Understanding Before You Flip the Switch
The following sections each describe a specific behaviour or limitation that surfaced during our implementation work – things that are either underdocumented, counterintuitive, or operationally significant. None of them make the feature a bad idea, but they are worth knowing before you roll this out in production.
1. MailNickname Remains an Identity Attribute
When Microsoft drew the line between “identity attributes” (still managed on-premises) and “Exchange attributes” (now manageable in the cloud), mailNickname ended up on the identity side. This means the alias – the short name that can be used as an identifier to a mailbox, and typically forms part of the email address – continues to be managed through AD.
The catch: MailNickname determines the default SMTP address prefix in many provisioning workflows, and it is referenced by other Exchange processes. Leaving it in AD while moving proxyAddresses to the cloud creates a split-management situation for attributes that are closely related.
In practice, this means that even after enabling cloud management, an administrator who wants to change a user’s alias must still do so through on-premises AD. This is an awkward carve-out for a feature that is marketed as eliminating the need for on-premises Exchange management. Without Exchange on-premises, the alias remains buried in the user properties’ “Attribute Editor” tab (not available on search results!) in AD Users & Computers.
2. Write-Back Is a Phase 2 Feature – Configuration Drift Is Now
Phase 1 is a one-way gate. When you modify Exchange attributes in the cloud – changing EmailAddresses, setting CustomAttribute1, hiding a user from the address book – those changes exist only in Exchange Online. They do not flow back to on-premises AD. Your on-premises AD object retains whatever values it had at the time the SOA was switched, and they will never be updated by the cloud changes you make afterward.
Microsoft acknowledges this and has framed Phase 2, with its write-back capability, as the solution. But Phase 2 has no release date yet. Until it ships, you are accumulating configuration drift between AD and Exchange Online for every SOA-switched mailbox you modify. This means reporting tools that target Exchange attributes will yield different results when run against AD vs. Exchange Online.
Switching Back: The Backup Problem
This drift also has another practical consequence if you ever want to reverse course and switch SOA back to on-premises. Microsoft’s own documentation makes this explicit: before setting IsExchangeCloudManaged back to false, you must back up any cloud-side changes and manually restore them to AD. Otherwise, the next sync cycle will overwrite your Exchange Online mailbox properties with the stale on-premises values.
# Capture cloud-side state before switching back
Get-Mailbox -Identity user@contoso.com | Select-Object EmailAddresses, CustomAttribute*,HiddenFromAddressListsEnabled | Export-Csv backup.csv
# Switch SOA back
Set-Mailbox -Identity user@contoso.com -IsExchangeCloudManaged $false
# Then manually restore each attribute on-premises via Set-RemoteMailbox
This manual restore step is easy to overlook, and the consequences of forgetting it are immediate: the next Connect Sync cycle will silently overwrite everything. If you are considering this feature for a larger user population, a documented rollback procedure is not optional – it is essential.
Programmatic Changes: Double-Writing as a Mitigation Strategy
If your organization uses scripts or tooling to automate Exchange attribute updates, one mitigation strategy for the drift problem is to write changes to both Exchange Online and the corresponding on-premises AD object simultaneously. This keeps AD in sync manually, without waiting for Phase 2, and means that if you ever switch SOA back, AD already reflects the current state.
This requires maintaining both an Exchange Online PowerShell connection and an on-premises AD connection in your automation, which adds complexity. But it is a substantially more robust posture than letting drift accumulate.
The latest version of EasyEntra handles this automatically by updating both the Exchange Online Mailbox and the on-premises AD user for SOA-switched mailboxes.
3. What the SOA Switch Does – and What It Doesn’t
The SOA switch does one thing: it changes which system is authoritative for Exchange attributes on a given mailbox. Exchange Online stops accepting overrides from Entra Connect Sync for those attributes, and you can now modify them directly via EXO cmdlets.
What the switch does not do is consolidate your administrative surface. You still need to manage identity attributes – displayName, UPN, department, phone number, and the full list of identity-classified attributes – through on-premises AD. You still need Entra Connect Sync running and healthy. You still navigate between the Exchange Admin Center, Entra Portal, Microsoft 365 Admin Center, PowerShell, and your on-premises AD tooling, depending on what you need to change. The SOA switch removes one specific friction point (having to use on-premises Exchange cmdlets for Exchange attributes), but it does not give you a unified admin experience.
In short: the switch simplifies Exchange attribute management for cloud mailboxes. To eliminate the multi-console, multi-system reality of hybrid administration, you still need a third-party solution like EasyEntra.
For consolidated management across AD, admin portals, and PowerShell, you still need a 3rd party solution
4. Mail Users Are Not Supported
The IsExchangeCloudManaged property is only applicable to mailbox users – recipients with an Exchange Online mailbox whose IsDirSynced status is true. It cannot be applied to synchronized mail users (MailUser objects), which are synced directory objects that point to external mailboxes.
Mail users are common in hybrid scenarios: they include
- on-premises mailbox users as seen from Exchange Online
- users who have been offboarded but retained as mail-enabled contacts, and
- external users who need system access but have external contact information, and similar configurations.
These objects continue to require on-premises management via Set-MailUser and the on-premises Exchange tools.
For first-line support teams, this creates a support scenario that is tricky to document: whether a given user’s Exchange attributes are managed in the cloud or on-premises depends both on recipient type and on whether the SOA flag has been set. Without clear tooling to surface this distinction, it is easy for a support technician to apply the wrong cmdlet to the wrong object and either get a confusing error or, worse, make a change in the wrong system.
And there is another problem related to the missing IsExchangeCloudManaged property on MailUser objects…
5. Removing the Exchange Online License Wipes Alias and Email Addresses
This is perhaps the most operationally surprising edge case in the current Phase 1 implementation.
In a standard hybrid environment, if you remove the Exchange Online license from a synced mailbox user, the mailbox is disconnected and the user converts to a mail user. Crucially, the alias (mailNickname) and email addresses (proxyAddresses) are retained, because these are still present in on-premises AD. The user remains mail-enabled but converts from a Mailbox to a MailUser object.
With SOA switched to the cloud, the behavior changes. Because alias and email addresses are now cloud-managed, removing the Exchange Online license appears to wipe these attributes, according to our testing. The user effectively converts to a standard, non-mail-enabled account – no alias, no email addresses, not visible in the address book. But the IsExchangeCloudManaged setting remains in effect – and unreachable!
So you’re basically stuck with a non-mail-enabled user.
If you want to convert it to a mail-enabled user, you must re-assign an Exchange Online license to convert it to a mailbox user, switch the SOA back to on-premises, wait for sync to repopulate the Alias and EmailAddresses attributes, and then remove the Exchange Online license again.
Recovery procedure:
- Re-assign an Exchange Online license to convert the account back to a mailbox user.
- Switch the SOA back to on-premises (set IsExchangeCloudManaged to false).
- Wait for the Connect Sync cycle to repopulate the alias and email addresses from AD.
- Remove the Exchange Online license again to complete the conversion to mail user.
This is a four-step manual recovery for what is otherwise a routine offboarding operation. If your offboarding process involves license removal as part of a deprovisioning workflow, and you have SOA-switched mailboxes in scope, this edge case warrants explicit handling in your runbooks.
6. CustomAttributes, Propagation Delays, and Three Different Editing Surfaces
When you set a CustomAttribute on an SOA-switched mailbox via Set-Mailbox, the value is not written directly to Exchange Online. It goes to the underlying Entra ID user object first – as extensionAttribute, naturally, because that is what the attribute is called in the directory – and from there it synchronizes into Exchange Online. The practical consequence is a noticeable propagation delay, often 30 seconds or more, before Get-Mailbox reflects the new value. Automation or users that reads back a property shortly after writing it to verify success will frequently see the old value and may incorrectly treat the operation as a failure.
Set-Mailbox -Identity user@contoso.com -CustomAttribute1 'NewValue'
# Get-Mailbox may still return the old value for 30+ seconds
Get-Mailbox -Identity user@contoso.com | Select-Object CustomAttribute1The naming difference between extensionAttribute (AD/Entra ID) and customAttribute (Exchange Online) is a long-standing inconsistency that predates this feature. What the SOA switch does add, however, is a third administrative surface – and the three scenarios no longer behave the same way:
- Standard hybrid account (SOA on-premises): managed via AD, using on-premises Exchange cmdlets.
- Cloud-only Entra ID account: managed via either Set-MgUser (Entra ID) or Set-Mailbox (Exchange Online) – both work.
- Synced account with SOA switched to cloud: managed via Set-Mailbox only. Attempting to write directly to the Entra ID object via Graph API fails:
PS C:\> Set-MgUser -UserId 'geha@azure.skrubbeltrang.com' `
-OnPremisesExtensionAttributes @{extensionAttribute1='somevalue'}
Update-MgUser_UpdateExpanded: Unable to update the specified properties for
on-premises mastered Directory Sync objects or objects currently undergoing migration.The error is accurate from Entra ID’s perspective: the object is still directory-synced and on-premises mastered for identity attributes, so direct Graph writes are blocked. Exchange Online has its own write path for the SOA-switched Exchange attributes that bypasses this restriction – but that path is only accessible through Exchange cmdlets, not through the Graph API. Any tooling or integration that updates extensionAttributes via Microsoft Graph on cloud-only accounts will unexpectedly fail for SOA-switched users.
EasyEntra Is Already SOA-Aware
Managing hybrid users across multiple admin surfaces – AD, Entra ID, Exchange Online – is exactly the kind of complexity that EasyEntra is built to absorb. The latest version of EasyEntra is SOA switch aware: when modifying Exchange attributes for a synced mailbox user, EasyEntra detects whether the SOA has been transferred to the cloud and applies changes accordingly – writing to Exchange Online for switched mailboxes, and to on-premises AD for standard ones.
Going further, EasyEntra also writes SOA-switched attribute changes back to the corresponding AD object in parallel. This is the double-write mitigation strategy described earlier: EasyEntra keeps AD in sync with cloud state without waiting for Microsoft’s Phase 2 write-back feature to ship. If you later need to switch SOA back to on-premises, your AD already reflects current Exchange attribute values, and the next Connect Sync cycle will not overwrite anything meaningful.
The mailNickname limitation – the alias that remains an identity attribute even after the SOA switch – is another area where consolidation helps. EasyEntra manages mailNickname through the AD side of the hybrid pipeline, the same way it always has, so the split responsibility between AD and Exchange Online does not surface as a gap in the user interface.
If your organization is evaluating the Exchange attribute SOA switch, or has already started enabling it for some mailboxes, EasyEntra gives your first-line support team a single console that handles the routing and double-write logic for them – without requiring them to know which API surface is authoritative for which user.
Summary
The Exchange attribute SOA switch is a genuinely useful capability for organizations that want to start decommissioning their Last Exchange Server – and take a step closer to a cloud-only infrastructure. It solves a real problem – specifically the inability to manage proxyAddresses and related attributes from the cloud – and it does so with per-mailbox granularity, which means you can roll it out incrementally.
The edge cases are real but manageable with preparation:
- mailNickname stays on-premises, so alias management remains split.
- Write-back is not yet available; configuration drift is a genuine risk until Phase 2 ships.
- Switching SOA back to on-premises requires a manual backup-and-restore of cloud changes.
- Mail users (MailUser objects) are not supported and continue to require on-premises management.
- License removal on SOA-switched mailboxes wipes alias and email addresses, complicating standard offboarding workflows.
- Attribute changes propagate via Entra ID with a noticeable delay before they appear on the Exchange Online mailbox.
- extensionAttributes now have three different authoritative editing surfaces depending on object type and SOA state.
Further reading: Cloud-based management of Exchange attributes for Remote Mailboxes in hybrid environments
