extensionAttributeX syncing to Entra via Entra Connect "broken"

Question

extensionAttributeX syncing to Entra via Entra Connect "broken"

Joe Grover 646

We're a hybrid shop in the process of decommissioning the last on-prem Exchange server.

In preparation for this, I've done the following:

I've run Set-OrganizationConfig -ExchangeAttributesCloudManagedByDefault in the tenant.
I've run a script setting IsExchangeCloudManaged to $true on all existing mailboxes.
Our primary sync is via Entra Connect Sync, but I have Entra Cloud Sync installed on the same server to accommodate EXO attribute writeback to on-prem.

Things have been good since doing this, however there are two hiccups I'm having.

The first is that any AD objects that are NOT mail-enabled and were synced to Entra prior to the above changes do not get IsExchangeCloudManaged set to true if we decide to give them a license and create a mailbox for them in 365. Any newly synced objects work fine and as expected; it's only AD objects that were synced prior to the org change that aren't cloud managed if we provision a mailbox for them.
The second is we use extensionAttributes in on-prem AD objects for several things in 365. Since the change these attributes don't sync, even if specifically calling them out in the Entra Connect wizard.

For #1 we just have to get into PowerShell after their mailbox is created and set the IsExchangeCloudManaged value to $true, but I was wondering if there's anything we could do preemptively to prevent needing to do that. On one hand I could unsync and resync the accounts, but that would obviously clear their authentication methods and any 365-specific group memberships they may have, so not really an option.

For #2, I have a workaround (created an app that reads the attributes from AD and writes them to the 365 object) but I'd rather find out if it's possible to get these attributes syncing again; I spoke with a peer the other day and their shop uses these attributes as well and they do not have on-prem Exchange any longer. I didn't have a chance to ask if they're doing the same thing I did, or if their attributes are just syncing normally.

0 comments

1 answer

Your answer

Answer 1

Hello @Joe Grover ,

I hope you're doing well

The behavior you're seeing appears to align with how Exchange Attribute Source of Authority (SOA) transfer works rather than indicating a synchronization issue. According to Cloud-based management of Exchange attributes for Remote Mailboxes in hybrid environments, Exchange attribute SOA transfer only applies to Exchange Online mailboxes and is controlled by the mailbox-level property IsExchangeCloudManaged.

Issue #1 - Existing synced users don't automatically become cloud-managed

Set-OrganizationConfig -ExchangeAttributesCloudManagedByDefault enables cloud-managed Exchange attributes for future provisioning scenarios, but it does not appear to retroactively change previously synchronized objects. Existing synced users may still require Set-Mailbox ******@contoso.com -IsExchangeCloudManaged $true after mailbox creation. This is also consistent with the behavior described by an Microsoft MV author regarding IsExchangeCloudManaged and new mailbox provisioning.

For your reference: Understanding “IsCloudManaged” and “IsExchangeCloudManaged” Microsoft Most Valuable Professional

Because IsExchangeCloudManaged is a mailbox property, there is generally no mailbox object to update before the Exchange Online mailbox exists. For that reason, I would not recommend unsyncing and resyncing accounts just to achieve this.

Issue #2 - extensionAttribute1-15 no longer syncing from AD

This is likely related to the SOA transfer.

Microsoft documents that once Exchange attribute SOA is moved to the cloud, Exchange attributes such as CustomAttribute1-15 are managed in Exchange Online rather than on-premises Active Directory. The Exchange custom attributes correspond to the familiar AD extensionAttribute1-15 values.

As a result, selecting those attributes again in Entra Connect does not necessarily make AD authoritative for them once IsExchangeCloudManaged=True.

Since this behavior affects both mailbox provisioning and Exchange attribute synchronization after enabling IsExchangeCloudManaged, I would also recommend opening a support case with Microsoft Entra Support. ased on my experience, extensionAttribute synchronization issues can be complex and are often best investigated directly with the support team.

Online support requests can be created from several places in the Entra admin center:

From the Diagnose and solve problems page:

Screenshot of the Diagnose and solve problems page with the navigation menu highlighted.

From the left-hand navigation menu:

Screenshot of the new support request button in the left-hand navigation menu.

From the help icon, after following the help prompts:

Screenshot of the new support request button in the help icon.

Although the current documentation suggests this may be expected behavior following Exchange Attribute SOA transfer, I have not found explicit guidance covering existing synced users that receive a mailbox later or whether extensionAttribute1-15 should always stop syncing from AD after the SOA transition.

I hope this helps. If you need any further assistance, please feel free to leave a comment.