Tuesday, September 8, 2026

Moving Exchange Attribute Source of Authority (SOA) from On-Premises AD to Entra ID: A Hands-On Walkthrough

Standard

 

The Problem Most Hybrid Tenants Still Have

If you run a hybrid Exchange setup, you probably know this pain. Mailboxes live in Exchange Online, but every attribute change still has to go through on premises Active Directory first. That server you keep meaning to retire (the Last Exchange Server) stays around just so you can edit a custom attribute or update a proxy address.

Microsoft now lets you skip that. You can transfer the Source of Authority for Exchange attributes to the cloud, while identity attributes like name and UPN stay owned by on prem AD. Once a mailbox is cloud managed, you edit its Exchange attributes directly in Exchange Online, and if you set it up, those changes write back down to AD automatically.

I tested this recently, and a few things weren't obvious from the docs alone. Here's what I learned.

Stay tuned for my next blog post, where I’ll also cover group SOA and User SOA changes to Entra ID.

There are a few writeback options as well. If your servers are still tied to on premises AD, you might wonder why writeback even matters. Most companies now rely heavily on Entra ID, yet many of their servers are still attached to on prem AD and need to authenticate those same users and groups. By changing the SOA to Entra ID, you can still keep the relevant data up to date on premises as well. That makes Entra ID much easier to manage, and it's also a safer approach from a security standpoint.

With the current sync model, it only flows one way (even password writeback follows this path): AD to Entra ID. What we're doing here is the reverse, syncing back from Entra ID to AD. In this article Sync Exchange Attribute EXO to Onprem AD. 



 The Two Moving Parts

There's a mailbox property called IsExchangeCloudManaged. This is the real switch. Set it to true, and Exchange Online stops accepting attribute updates from on prem for that mailbox.

There are also two scoping attributes, CloudMastered and BlockExchangeAttributesOnPremisesSync. You don't set these directly. Cloud Sync calculates them from IsExchangeCloudManaged and the object's sync state. The default scoping rule needs both CloudMastered false and BlockExchangeAttributesOnPremisesSync true. Get the mailbox property right and these fall into place on their own.

What You Need First

  • Entra Connect Sync 2.5.190.0 or newer, if you're still running classic Connect alongside Cloud Sync
  • Cloud Sync provisioning agent 1.1.1107.0 or newer, showing Active under Agents
  • Hybrid Identity Administrator, or Global Administrator rights
  • No on prem Exchange server required for the PowerShell steps. Everything here runs through Exchange Online PowerShell. Useful if, like me, your access is AD only with no Exchange Management Shell.
My environment uses Entra Cloud Sync. The steps outlined below apply specifically to Cloud Sync provisioning.

Setting Up Writeback

In the Entra admin center, go to Entra Connect > Cloud Sync > New configuration > EXO to AD attribute sync. Confirm the agent matches your domain and create it, then hit Start provisioning.


Two tabs matter most:

Attribute mapping controls which Exchange properties flow back to AD.

Scoping filters shows the default rule plus anything custom you add. Custom clauses use OR against the default, so they widen scope, they don't replace it.

Transferring a Test Mailbox

Connect to Exchange Online PowerShell:

Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -UserPrincipalName admin@yourdomain.com

One thing to watch for. If your browser has a cached sign in for a different account, the popup can quietly use that identity instead of prompting fresh, and you'll get an error saying the account chosen doesn't match. Use an incognito window and pick "use another account" if that happens. Then confirm the session actually connected before doing anything else:

Get-ConnectionInformation

If that's empty, none of the Exchange Online cmdlets will work, including Set-OrganizationConfig. It'll just say the cmdlet isn't recognized, which looks like a missing module but is really a failed connection.

Check the mailbox exists, then flip the switch:

Get-Mailbox -Identity SyncTest01
Set-Mailbox -Identity SyncTest01 -IsExchangeCloudManaged $true

Testing With Provision on Demand





This is where most of the real troubleshooting happens. A single "skipped, not in scope" result can hide more than one cause. My test returned three flags at once: IsActive false, Assigned to the application false, IsInProvisioningScope true.

It's tempting to chase the wrong one. Here's what each actually tells you:

IsInProvisioningScope true means the object already passes the scoping filter. If your scoping attributes look off in the Import step, don't assume that's the problem if this already reads true.

Assigned to the application false is the one that actually blocks things. If your app is set to sync only assigned users and groups, you need to add the user under Users and groups on that Enterprise Application. Scoping filters alone won't cover this.

IsActive false can lag behind what the portal shows under account status. Don't assume it's fixed just because Entra ID shows Enabled. Check attribute mapping to see what source attribute actually feeds it.

Fix one thing at a time and re run the test. It's easy to blame the wrong flag when three of them show up together.

Note - ensure the user has an active license assigned.

Should You Turn This On Tenant Wide

There's a shortcut that makes cloud managed the default for every new mailbox:

Set-OrganizationConfig -ExchangeAttributesCloudManagedByDefault

Don't reach for this early. Microsoft only supports it once every on prem mailbox has already moved to Exchange Online. Turn it on too soon and any recipient still created on prem gets synced up as a plain user with no Exchange attributes at all. No mailbox gets provisioned, onboarding breaks, and there's no easy way back without Microsoft Support. Stick to flipping the switch per mailbox until your last Exchange server is actually going away.


0 comments:

Post a Comment