Hybrid organizations that kept an on-premises Exchange server solely for recipient management can finally decommission that long-standing dependency. Microsoft has released a new capability that transfers the Source of Authority (SOA) for Exchange-specific attributes from on-premises Active Directory to Exchange Online. The centerpiece is a per-mailbox switch called IsExchangeCloudManaged, now generally available, which marks whether a directory-synchronized user’s Exchange attributes are managed in the cloud or on-premises. This one flag eliminates the need for the so-called “last Exchange server” that admins have been forced to maintain just to change email addresses, aliases, or hidden address list settings.

For over a decade, enterprises running hybrid Exchange have faced a frustrating paradox: their mailboxes live in Exchange Online, yet the smallest recipient change required a running on-premises Exchange server, because that’s where the directory objects were mastered. In 2022, Microsoft allowed them to shut down the server and use updated management tools on a domain-joined workstation, but that still demanded PowerShell expertise and lacked native cloud logging. The new model goes a step further—it shifts the authority over Exchange attributes into the cloud while keeping identity data (names, UPNs, departments) under on-prem AD control. The result is a cleaner split that lets admins use the Exchange admin center, Microsoft 365 admin center, or Exchange Online PowerShell for everyday tasks, with full audit trails and Role-Based Access Control (RBAC).

How the IsExchangeCloudManaged flag works

The IsExchangeCloudManaged property is a simple Boolean that you set on a mailbox in Exchange Online. By default, it’s false for synchronized users, meaning all Exchange-related attributes are still governed by on-premises AD. Flipping it to true changes that—a process Microsoft calls “transferring the Exchange attribute SOA.” Once a mailbox is cloud-managed, attributes such as proxyAddresses, CustomAttribute1-15, HiddenFromAddressListsEnabled, and dozens of other Exchange-specific properties become editable in the cloud and are no longer overwritten by the on-premises sync. Core identity attributes—displayName, givenName, sn, title, telephoneNumber, etc.—remain mastered on-premises and cannot be changed from the cloud.

The flag can be set individually, one mailbox at a time, giving organizations a gradual, test-driven migration path. Microsoft has also introduced a tenant-level setting that automatically marks all newly created mailboxes as cloud-managed, though this is not recommended while you still host any mailboxes on an on-premises Exchange server. The tenant-wide option is controlled via Set-OrganizationConfig -ExchangeAttributesCloudManagedByDefault, which changes the BlockExchangeProvisioningFromOnPremEnabled flag to True.

Accurate prerequisites: version numbers and roles

Admins need to verify two critical prerequisites before touching the feature. First, Microsoft Entra Connect Sync must be version 2.5.190.0 or higher. Older builds—including the 2.5.76.0 version sometimes incorrectly cited—will fail when they encounter mailboxes with a transferred SOA, attempting to push on-premises changes that are no longer authoritative. You can check your version in Control Panel or with (Get-ADSyncGlobalSettings).Parameters['Microsoft.Synchronize.ServerConfigurationVersion']. If you’re running an older build, upgrade following Microsoft’s documented process.

Second, access to set IsExchangeCloudManaged is controlled by Exchange RBAC. The parameter is available to holders of the built-in Organization Management or Recipient Management roles, as well as custom roles that include it. The Exchange Administrator role in Entra ID also enables it. Organizations should immediately scope this permission to a small, audited group and remove it from broad roles to prevent accidental or malicious SOA transfers.

Additionally, Microsoft now supports this feature via Entra Cloud Sync as an alternative or complement to Connect Sync. For Phase 2 writeback (detailed below), Cloud Sync is mandatory. The provisioning agent must be version 1.1.1107.0 or later.

Phased rollout: what’s live today, what’s coming

Microsoft is delivering the capability in two phases, and the current status differs from some early community reports.

  • Phase 1 (now Generally Available): Per-mailbox opt-in and the tenant-wide default for new mailboxes. All commercial tenants, including GCC High, DoD, and Gallatin, have this today. During this phase, mailboxes may be rolled back to on-premises management by setting the flag back to false. No writeback occurs yet; cloud edits to Exchange attributes are not automatically reflected in on-prem AD.
  • Phase 2 (Public Preview): Writeback of designated Exchange attributes to on-premises Active Directory via Entra Cloud Sync. This automatically synchronizes changes like proxyAddresses and extension attributes back to AD. The preview supports tenants with fewer than 200,000 cloud-managed mailboxes, with that limit increasing when the feature reaches general availability—currently targeted for the end of June 2026.

Phase 2 is the piece that prevents long-term attribute divergence. Until then, administrators must manage reconciliation manually if their on-prem systems need up-to-date mailbox attributes.

Practical steps to adopt, straight from the field

Based on both Microsoft’s official guidance and real-world admin experience, a safe adoption path looks like this:

  1. Verify your sync infrastructure: Ensure Entra Connect is at 2.5.190.0 or later. If you plan to use writeback, install and register the Cloud Sync agent (v1.1.1107.0+).
  2. Pilot small: Pick a handful of non-critical mailboxes and back up their current Exchange attribute values with Get-Mailbox and Get-User. This gives you a quick restore point.
  3. Transfer SOA: In Exchange Online PowerShell, run Set-Mailbox -Identity <User> -IsExchangeCloudManaged $true. Verify with Get-Mailbox -Identity <User> | Format-List Identity, IsExchangeCloudManaged.
  4. Test editing: Modify a low-risk attribute (e.g., CustomAttribute1) in the cloud and confirm it persists and is no longer overwritten by on-prem sync. Check that Entra Connect runs without errors.
  5. Update automation and RBAC: Adapt scripts that used on-prem cmdlets (like Set-RemoteMailbox) to call Exchange Online. Restrict IsExchangeCloudManaged permission to a dedicated admin group.
  6. Monitor and expand: Watch audit logs and Exchange Online change events for the first 90 days. Roll out to more mailboxes incrementally, not all at once.
  7. Prepare for writeback: Evaluate Entra Cloud Sync in a lab. Identify which attributes your apps read from AD and need to be written back. Build reconciliation runbooks for the interim before Phase 2 is GA.

For mailbox creation during the transition, the recommended flow is: create the on-prem AD user, let Entra Connect sync the identity, assign an Exchange Online license, and then set IsExchangeCloudManaged to $true. This avoids using the on-prem New-RemoteMailbox cmdlet and prepares for a future without an Exchange server.

Strengths, limitations, and operational risks

This is a targeted, pragmatic move, but it’s not a magic wand. Here’s what you need to weigh.

Strengths

  • Security and maintenance win: Decommissioning the last Exchange server removes a significant attack surface and ends patching, backup, and exposure headaches. It aligns with the industry drive to reduce on-prem footprint.
  • Cloud-native governance: Exchange Online’s audit trails, RBAC, and compliance integrations are far superior to the standalone tools that were the previous workaround. Changes are now part of your Microsoft 365 audit logs.
  • Incremental adoption: The per-mailbox control lets you test and iterate without a risky big-bang migration.

Limitations and risks

  • Attribute divergence until writeback: Right now, cloud edits are invisible to on-prem AD. If HR systems, legacy apps, or identity management tools depend on AD for Exchange attributes, you’ll have inconsistent data. Phase 2 promises automatic reconciliation, but until it’s GA, you’ll need manual processes.
  • Powerful parameter, weak default RBAC: IsExchangeCloudManaged can be abused if left in broad roles. A single rogue admin could shift SOA for thousands of mailboxes, disrupting mail flow or offboarding processes. Lock it down now.
  • Offboarding gotchas: Deleting a user still requires removing the on-prem AD account. If your HR-feeder scripts delete AD accounts assuming on-prem attribute governance, they might inadvertently remove cloud-managed mailboxes without proper handshake. Test the full lifecycle.
  • Tooling ripple effects: Any automation that previously modified Exchange attributes on-prem will break for cloud-managed mailboxes unless you rewrite it to target Exchange Online cmdlets. Audit your scripts and scheduled tasks.
  • Edge cases with mail-enabled groups: The feature targets user mailboxes (including shared, room, and equipment). Group SOA is handled separately and has its own limitations (e.g., no automatic transfer for nested groups). Plan group management in parallel if you aim for full AD minimization.
  • Sync version dependency: Failing to upgrade Entra Connect causes immediate failures once objects are SOA-transferred. This is a hard prerequisite, not optional.

Governance and security checklist

  • Create a strict change-management process for flipping IsExchangeCloudManaged. Require a ticket, a rollback plan, and attribute backups.
  • Restrict the parameter to a dedicated RBAC role with only the necessary admins. Remove it from Organization Management if possible.
  • Upgrade Entra Connect in a test environment first and validate sync for transferred accounts.
  • Start with a documented pilot phase and acceptance criteria (no breakage of mail flow, HR offboarding, or on-prem app dependencies).
  • Build operational runbooks for: transferring SOA, reverting SOA, rewriting automation, and monitoring audit logs.
  • Plan for writeback by evaluating Cloud Sync and deciding which attributes you’ll sync back. Prepare a reconciliation report template.

The bigger picture: object-level SOA and the road to AD minimization

Microsoft’s broader strategy is to provide granular, object-level SOA controls so companies can selectively move individual users, groups, and contacts to cloud management. Group SOA is already in public preview, and User and Contact SOA are on the roadmap. This aligns with a long-term architecture where on-prem AD becomes an identity provider only, while Exchange and other workloads are fully cloud-native. The IsExchangeCloudManaged feature is the first major piece of that puzzle for hybrid mail recipients.

For admins, the immediate homework is clear: get your Entra Connect version up to date, pilot the feature with a handful of mailboxes, tighten RBAC, and start rewriting scripts. The feature doesn’t eliminate the need for on-prem AD—identity still comes from there—but it finally breaks the awkward dependency on an Exchange server for everyday recipient management. That’s a change worth preparing for now.