Microsoft has made Exchange attribute writeback for cloud-managed remote mailboxes generally available, giving hybrid Exchange organizations a supported way to edit selected recipient attributes in Exchange Online and synchronize those changes back into on-premises Active Directory. The practical gain is significant for companies trying to retire their final Exchange Server without breaking line-of-business applications that still read mailbox data from AD.
The Exchange Team’s August 3 announcement says the feature is available in Commercial, GCC High, DoD, and 21Vianet environments, with a supported ceiling of 600,000 cloud-managed mailboxes per tenant. Microsoft Learn documentation updated the same day confirms the GA status, the scale limit, and a key new addition: writeback of the Active Directory
This is not a replacement for directory synchronization. It is a narrower bridge for the awkward period in which Active Directory remains the identity authority, Exchange Online becomes the authority for Exchange recipient attributes, and on-premises software still expects to find those attributes in AD.
For years, an organization could move every user mailbox to Exchange Online yet still need an on-premises Exchange Server, or at least Exchange Management Tools, to make supported edits to directory-synchronized recipient attributes. The mailbox lived in Microsoft 365, but its Exchange configuration still originated in on-premises Active Directory.
Cloud-managed remote mailboxes changed that arrangement. Administrators can set
Until writeback, that model created an obvious operational split. A change to proxy addresses or custom attributes made in Exchange Online might be correct in the cloud, while a legacy HR integration, intranet directory, badge system, CRM connector, or provisioning script querying Active Directory could still see stale values. Microsoft Entra Cloud Sync now carries a defined set of Exchange changes back to AD.
Microsoft’s documentation is clear that writeback is optional. Organizations that do not have on-premises applications consuming these values can manage cloud-hosted mailboxes through Exchange Online without it. But for the larger hybrid shops this feature targets, “optional” is often theoretical: a stale
The GA release expands the writeback set to 24 attributes. It covers
The new mapping matters more than the small entry in an attribute table suggests. Exchange Online administrators change the mailbox’s Windows email address using the
The important limitation is that GA does not mean every Exchange property now flows back to Active Directory. Microsoft’s current attribute matrix identifies a much broader set of Exchange attributes that are editable in Exchange Online, while only the 24 designated properties are eligible for writeback. Settings such as mailbox forwarding, litigation hold, audit configuration, delegation, retention, moderation, and address-list visibility can be cloud-managed, but the documentation does not list them as writeback-enabled.
Administrators should therefore avoid treating writeback as a general-purpose replication engine. It is a deliberately constrained synchronization path, intended to preserve the specific Exchange values that on-premises systems are likely to need after Exchange attribute authority moves to the cloud.
That means an organization can be using the feature successfully, declare it “GA-ready,” and still have no writeback for its primary AD email attribute. The check is straightforward: open the Exchange Online attribute writeback configuration in the Microsoft Entra admin center and verify that the Microsoft Entra ID
Microsoft’s prescribed remediation is to select Restore default mappings if the mapping is absent. But its own documentation adds the warning missing from the announcement’s short action list: restoring defaults removes customized attribute mappings and scoping filters and restarts the synchronization job.
That is a material change-control concern. A tenant that narrowed writeback to an organizational unit, pilot population, or other defined scope during the preview should document the configuration before restoring defaults, then reapply every custom mapping and filter afterward. Treating the button as a harmless one-click upgrade could expand or alter a provisioning job in ways the administrator did not intend.
Microsoft also needs to clean up one lingering labeling inconsistency. Its GA documentation still instructs administrators to create an “EXO to AD attribute sync (Preview)” configuration in the Entra portal. The service capability is GA, as the announcement and documentation’s feature-availability section state, but the portal workflow retains the Preview label. That does not negate the release status; it does mean change managers should preserve the GA announcement and the updated Microsoft Learn guidance in their implementation record rather than relying on the portal wording alone.
The split is intentional, and it avoids requiring a wholesale migration from Entra Connect Sync merely to adopt cloud-side Exchange management. But it also means this is not a zero-infrastructure feature. Microsoft requires a Cloud Sync provisioning agent at version 1.1.1107.0 or later, registered and active in the Entra admin center. Entra Connect Sync must be version 2.5.190.0 or later for the cloud-managed mailbox model; older builds can attempt to push Exchange updates for mailboxes whose authority has already moved and fail.
Before changing authority, Microsoft recommends allowing an ordinary synchronization cycle plus 24 hours after the last on-premises Exchange attribute update. In a tenant where the sync interval is six hours, that is a 30-hour wait. The conservative timing is meant to prevent administrators from moving the authority boundary while a last AD-originated update is still working its way toward Exchange Online.
Testing should also be more deliberate than merely confirming that the Cloud Sync job is green. Microsoft’s documented verification path uses a controlled
The distinction between shutting down Exchange and uninstalling it still matters. Exchange Management Tools can remove the burden of running a server, but Microsoft says they retain dependencies on Exchange configuration containers and security groups. The newer cloud-management path is designed for organizations that want to remove those dependencies and actually uninstall Exchange.
Even then, the mailbox-only scope is easily overlooked.
The feature also does not eliminate Active Directory. A cloud-managed remote mailbox remains directory-synchronized, and deletion of the user still begins in on-premises AD. This is an Exchange attribute authority transfer, not a complete conversion of a hybrid identity object into a cloud-only user.
If an organization enables tenant-wide SOA while creating new Exchange recipients on-premises, Microsoft says the synchronized object can arrive in Entra ID as a regular identity with
That warning changes the order of operations. Administrators should first finish on-premises recipient creation and migration, validate individual cloud-managed mailboxes and writeback, deal with groups and contacts, confirm mail routing and Autodiscover, and only then consider the tenant-wide default. The GA writeback feature makes the end state more realistic for AD-dependent organizations, but it does not make a partially completed hybrid migration safe to shortcut.
For existing preview users, the immediate task is to inspect the
mail attribute.This is not a replacement for directory synchronization. It is a narrower bridge for the awkward period in which Active Directory remains the identity authority, Exchange Online becomes the authority for Exchange recipient attributes, and on-premises software still expects to find those attributes in AD.
The missing link in the last Exchange Server plan
For years, an organization could move every user mailbox to Exchange Online yet still need an on-premises Exchange Server, or at least Exchange Management Tools, to make supported edits to directory-synchronized recipient attributes. The mailbox lived in Microsoft 365, but its Exchange configuration still originated in on-premises Active Directory.Cloud-managed remote mailboxes changed that arrangement. Administrators can set
IsExchangeCloudManaged to $true on an eligible directory-synchronized mailbox, transferring the source of authority for its Exchange attributes to Exchange Online. Identity information such as names, departments, phone numbers, and the account itself remains synchronized from Active Directory; Exchange-specific properties can then be edited using Exchange Online PowerShell, the Exchange admin center, or Microsoft 365 admin center.Until writeback, that model created an obvious operational split. A change to proxy addresses or custom attributes made in Exchange Online might be correct in the cloud, while a legacy HR integration, intranet directory, badge system, CRM connector, or provisioning script querying Active Directory could still see stale values. Microsoft Entra Cloud Sync now carries a defined set of Exchange changes back to AD.
Microsoft’s documentation is clear that writeback is optional. Organizations that do not have on-premises applications consuming these values can manage cloud-hosted mailboxes through Exchange Online without it. But for the larger hybrid shops this feature targets, “optional” is often theoretical: a stale
proxyAddresses, mail, or extension attribute can still break a downstream process long after Exchange Server itself has stopped carrying mail.
mail writeback closes a practical gap
The GA release expands the writeback set to 24 attributes. It covers extensionAttribute1 through extensionAttribute15, the five msExchExtensionCustomAttribute fields, msExchRecipientDisplayType, msExchRecipientTypeDetails, proxyAddresses, and now mail.The new mapping matters more than the small entry in an attribute table suggests. Exchange Online administrators change the mailbox’s Windows email address using the
WindowsEmailAddress parameter, and Microsoft now writes that result to the corresponding on-premises AD mail attribute. Many older applications and LDAP-based directory lookups treat mail as the first or only address field they consult; they do not parse the multivalued proxyAddresses attribute to find the primary SMTP address.The important limitation is that GA does not mean every Exchange property now flows back to Active Directory. Microsoft’s current attribute matrix identifies a much broader set of Exchange attributes that are editable in Exchange Online, while only the 24 designated properties are eligible for writeback. Settings such as mailbox forwarding, litigation hold, audit configuration, delegation, retention, moderation, and address-list visibility can be cloud-managed, but the documentation does not list them as writeback-enabled.
Administrators should therefore avoid treating writeback as a general-purpose replication engine. It is a deliberately constrained synchronization path, intended to preserve the specific Exchange values that on-premises systems are likely to need after Exchange attribute authority moves to the cloud.
Public Preview tenants have a configuration trap
The most consequential operational detail is reserved for existing Public Preview deployments. Microsoft says configurations created on or after August 3, 2026 receive theMail-to-mail mapping by default. Configurations created before that date do not receive the new mapping automatically.That means an organization can be using the feature successfully, declare it “GA-ready,” and still have no writeback for its primary AD email attribute. The check is straightforward: open the Exchange Online attribute writeback configuration in the Microsoft Entra admin center and verify that the Microsoft Entra ID
Mail source maps directly to the Active Directory mail target.Microsoft’s prescribed remediation is to select Restore default mappings if the mapping is absent. But its own documentation adds the warning missing from the announcement’s short action list: restoring defaults removes customized attribute mappings and scoping filters and restarts the synchronization job.
That is a material change-control concern. A tenant that narrowed writeback to an organizational unit, pilot population, or other defined scope during the preview should document the configuration before restoring defaults, then reapply every custom mapping and filter afterward. Treating the button as a harmless one-click upgrade could expand or alter a provisioning job in ways the administrator did not intend.
Microsoft also needs to clean up one lingering labeling inconsistency. Its GA documentation still instructs administrators to create an “EXO to AD attribute sync (Preview)” configuration in the Entra portal. The service capability is GA, as the announcement and documentation’s feature-availability section state, but the portal workflow retains the Preview label. That does not negate the release status; it does mean change managers should preserve the GA announcement and the updated Microsoft Learn guidance in their implementation record rather than relying on the portal wording alone.
Cloud Sync runs alongside Entra Connect Sync
Microsoft is positioning the feature as additive for existing hybrid identity deployments. Entra Connect Sync continues to synchronize users and identity attributes from on-premises AD to Microsoft Entra ID. Microsoft Entra Cloud Sync handles the Exchange attribute writeback path in the other direction.The split is intentional, and it avoids requiring a wholesale migration from Entra Connect Sync merely to adopt cloud-side Exchange management. But it also means this is not a zero-infrastructure feature. Microsoft requires a Cloud Sync provisioning agent at version 1.1.1107.0 or later, registered and active in the Entra admin center. Entra Connect Sync must be version 2.5.190.0 or later for the cloud-managed mailbox model; older builds can attempt to push Exchange updates for mailboxes whose authority has already moved and fail.
Before changing authority, Microsoft recommends allowing an ordinary synchronization cycle plus 24 hours after the last on-premises Exchange attribute update. In a tenant where the sync interval is six hours, that is a 30-hour wait. The conservative timing is meant to prevent administrators from moving the authority boundary while a last AD-originated update is still working its way toward Exchange Online.
Testing should also be more deliberate than merely confirming that the Cloud Sync job is green. Microsoft’s documented verification path uses a controlled
CustomAttribute1 update in Exchange Online, waits roughly 20 minutes for the normal sync cycle or invokes provision-on-demand, and then checks the value through on-premises Exchange Management Shell. In production, the same validation should be done for the actual fields the organization depends on—particularly mail and proxyAddresses—and against any applications that consume them.Exchange Server removal remains a separate project
Writeback is an enabling component of the “last Exchange Server” retirement path, not the finish line. Microsoft’s separate decommissioning guidance requires all on-premises mailboxes and public folders to be migrated or removed, all directory-synchronized mailboxes to have their Exchange attribute authority transferred, and mail flow and Autodiscover to point at Exchange Online before uninstalling the last server.The distinction between shutting down Exchange and uninstalling it still matters. Exchange Management Tools can remove the burden of running a server, but Microsoft says they retain dependencies on Exchange configuration containers and security groups. The newer cloud-management path is designed for organizations that want to remove those dependencies and actually uninstall Exchange.
Even then, the mailbox-only scope is easily overlooked.
IsExchangeCloudManaged applies to user objects with Exchange Online mailboxes. It does not transfer management of mail-enabled distribution groups, mail-enabled security groups, or mail contacts. Organizations planning to remove their final Exchange Server must separately use Group Source of Authority transfer and Contact Source of Authority transfer for those object types if they expect to manage them from the cloud afterward.The feature also does not eliminate Active Directory. A cloud-managed remote mailbox remains directory-synchronized, and deletion of the user still begins in on-premises AD. This is an Exchange attribute authority transfer, not a complete conversion of a hybrid identity object into a cloud-only user.
Tenant-wide SOA can break mailbox provisioning if enabled early
Microsoft’s strongest warning concerns the tenant-wide Exchange attribute source-of-authority switch. It is intended for organizations that have completed mailbox migration and no longer create Exchange mailboxes, mail-enabled users, or remote mailboxes on-premises.If an organization enables tenant-wide SOA while creating new Exchange recipients on-premises, Microsoft says the synchronized object can arrive in Entra ID as a regular identity with
IsExchangeCloudManaged enabled rather than as the required Exchange Online MailUser. Mailbox onboarding and migration then cannot proceed. Disabling the tenant-wide setting stops the problem for future objects, but it does not automatically repair users already affected; Microsoft directs customers to stop provisioning and contact support.That warning changes the order of operations. Administrators should first finish on-premises recipient creation and migration, validate individual cloud-managed mailboxes and writeback, deal with groups and contacts, confirm mail routing and Autodiscover, and only then consider the tenant-wide default. The GA writeback feature makes the end state more realistic for AD-dependent organizations, but it does not make a partially completed hybrid migration safe to shortcut.
For existing preview users, the immediate task is to inspect the
Mail-to-mail mapping without wiping out custom Cloud Sync scope. For everyone else, the release provides a supported path to make Exchange Online the authoring plane for selected mailbox attributes while keeping the on-premises values that legacy systems still require—one of the last technical dependencies standing between a hybrid tenant and removal of its final Exchange Server.
References
- Primary source: Microsoft Exchange Team Blog
Published: Mon, 03 Aug 2026 12:58:46 GMT
Loading…
techcommunity.microsoft.com - Related coverage: learn.microsoft.com
Loading…
learn.microsoft.com - Related coverage: techcommunity.microsoft.com
Loading…
techcommunity.microsoft.com - Related coverage: learn.microsoft.com
Loading…
learn.microsoft.com