Share via

AD Connect - User object missing from AAD Connector Space, mobile number not syncing to Entra ID

Frederik Winther Christensen 20 Reputation points
2026-04-15T14:21:46.03+00:00

We have an on-premises AD synced user where the mobile phone number is not updating in Entra ID despite being correct in on-premises AD.

Environment:

Azure AD Connect (AD Sync) on-premises

On-premises AD connector: ad.contoso.com

AAD connector: contoso.onmicrosoft.com - AAD

Problem:

The mobile number in Entra ID shows an incorrect value, but the correct value exists in on-premises AD.

Investigation performed:

✅ Correct mobile value confirmed in on-premises AD

✅ Value is present in the AD Connector Space with correct value

✅ Value flows correctly into the Metaverse via rule "In from AD - User Common from Exchange"

✅ Outbound sync rules for mobile attribute are correctly configured

✅ OnPremisesSyncEnabled = True and last sync timestamp is current

✅ No export errors exist for this user on the AAD connector

❌ User object does not appear in the AAD Connector Space despite being a synced user

❌ Mobile number cannot be manually overwritten via Graph API — error returned: "Unable to update the specified properties for on-premises mastered Directory Sync objects"

Key finding:

The user object is completely absent from the AAD Connector Space, which means the correct mobile value never gets exported to Entra ID. No export errors exist for this specific user to indicate why the object is not being projected.

Question:

Why would a specific user object be missing from the AAD Connector Space despite being an on-premises synced user with OnPremisesSyncEnabled = True? And how can we force it to be re-projected so the mobile number syncs correctly?

Microsoft Security | Microsoft Entra | Microsoft Entra ID

Answer accepted by question author

Shubham Sharma 16,550 Reputation points Microsoft External Staff Moderator
2026-04-23T12:01:03.7733333+00:00

Frederik Winther Christensen

Thank you for your reply.

At this point, this is no longer a projection or filtering issue. It’s a cloud‑side “sticky” mobilePhone value problem (DirSyncOverrides) that Microsoft explicitly documents for the mobile / otherMobile attributes.

Below is the authoritative Microsoft‑backed explanation and resolution, mapped exactly to your findings.

Why AD Connect thinks everything is “in sync” when Entra ID is not

MobilePhone and AlternateMobilePhones are special attributes that historically could be edited directly in Entra ID even for synced users.

When that happened, Entra ID silently protected the cloud value, and later ignored updates coming from on‑premises AD, even though:

• The object exists in the AAD Connector Space

• The Metaverse shows the correct value

• No export errors are logged

• Delta and Full syncs show “no changes”

Microsoft refers to this behavior as DirSyncOverrides.

When it’s in effect, the export succeeds but Entra ID refuses to apply the update — without generating an error.

This exactly matches your situation:

Correct value in AD

Correct value in AD CS → MV → AAD CS

No export or provisioning errors

Entra ID still shows an old value

Sync engine reports Changes = none

For your reference:

How to use the BypassDirSyncOverridesEnabled feature of a Microsoft Entra tenant

https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-bypassdirsyncoverrides

Why Full Import / Delta Sync does nothing

Microsoft explicitly states:

“The synchronization engine may report a successful export even when Entra ID does not accept the update for MobilePhone due to DirSyncOverrides.”

So:

Full Import

Full Sync

Export

Entra ID silently ignores the change

This is by design and cannot be fixed by forcing sync cycles alone

Below is the supported way to force Entra ID to accept the on‑prem value

Step 1: Prove the mismatch

On the AAD Connect server, run:

Install-Module ADSyncTools -Force

Compare-ADSyncToolsDirSyncOverrides

This is Microsoft‑recommended to detect mobile mismatches even when sync reports healthy. Affected users will show EqualValues = False.

https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-bypassdirsyncoverrides

Step 2: Enable tenant‑wide override reset

Microsoft requires enabling the tenant feature:

Connect-MgGraph -Scopes "OnPremDirectorySynchronization.ReadWrite.All"

$sync = Get-MgDirectoryOnPremiseSynchronization

$sync.Features.BypassDirSyncOverridesEnabled = $true

Update-MgDirectoryOnPremiseSynchronization `

  -OnPremisesDirectorySynchronizationId $sync.Id `

  -Features $sync.Features

What this does

  • Clears cloud‑protected mobile values
  • Forces Entra ID to trust on‑prem AD as source of authority again
  • Allows future AD updates to overwrite cloud values

Step 3: Run one sync cycle

Start-ADSyncSyncCycle -PolicyType Delta

A full sync is not required once overrides are cleared.

https://activedirectorypro.com/force-sync-azure-ad-connect-using-powershell/

Why removing the connector link or reprovisioning didn’t help

Microsoft explains that DirSyncOverrides are stored in Entra ID, not in:

AD Connector Space

Metaverse

Sync rules

SourceAnchor logic

So:

Removing connector links

Full imports

Rule inspection

Re‑projection

None of these can override a cloud‑protected mobile value.

Was this answer helpful?

2 people found this answer helpful.
0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-04-15T14:22:19.4966667+00:00

    The object is missing from the Microsoft Entra (AAD) connector space because it is being filtered or blocked before it can be projected from the metaverse into the AAD connector space, even though it is present and correct in the AD connector space and metaverse. When an object never appears in the AAD connector space, no export can occur, so the mobile attribute in Entra ID never updates.

    From the provided context, there are two main categories of causes to check and corresponding actions to re‑project the object so the mobile number can sync.

    1. Verify the object is not filtered before reaching the metaverse

    You already confirmed:

    • The object is present in the AD connector space with the correct mobile value.
    • The object is present in the metaverse and the mobile attribute flows correctly via the inbound rule.

    If an object is in the AD connector space but not in the metaverse, a scoping filter in an inbound rule would be the cause. In your case, the object is already in the metaverse, so this specific issue does not apply. For completeness, the standard check is:

    • In Synchronization Service Manager, use Metaverse Search to confirm the object exists.
    • If it did not exist, you would inspect inbound synchronization rules and their Scoping filter to see which attribute is blocking projection from AD CS to MV, as described in the metaverse troubleshooting section.

    Since the object is in the metaverse, the blocking is happening on the outbound side (MV → AAD CS).

    1. Check for conditions that prevent projection to the AAD connector space

    When an object is in the metaverse but missing from the AAD connector space, typical causes include:

    • Outbound scoping filters or join rules that exclude this object.
    • Attribute transformations that null out key attributes required for projection (for example, sourceAnchor) so the object is filtered.
    • Special handling for certain Exchange attributes such as msExchRecipientTypeDetails that can cause the engine to wait for another object or set sourceAnchor to NULL.

    The context describes a specific case where a user object is filtered because sourceAnchor is set to NULL based on msExchRecipientTypeDetails:

    • There is an inbound rule for sourceAnchor:
      • If msExchRecipientTypeDetails = 2 (linked mailbox), the rule sets sourceAnchor to NULL.
      • If sourceAnchor is NULL, the user is filtered and not provisioned.
    • This behavior is intended for account–resource forest topologies where AAD Connect waits for the master account from the account forest to join with the resource object.

    If this user has msExchRecipientTypeDetails = 2 but is not actually part of an account–resource forest scenario, the result is:

    • The user appears in the AD connector space and metaverse.
    • sourceAnchor is NULL in the metaverse for this object.
    • The user is filtered and never projected to the AAD connector space.
    • No export errors appear for this user, because the object never reaches the AAD connector space.

    This matches your symptom: a synced user (OnPremisesSyncEnabled = True in Entra ID) whose current metaverse instance is not being exported to AAD because the object is filtered at the connector level, so the mobile attribute never updates.

    1. How to force the object to be re‑projected so mobile syncs

    Use the supported workaround from the context to ensure the object is no longer filtered and can be projected into the AAD connector space:

    1. Check msExchRecipientTypeDetails and sourceAnchor in the metaverse
      • In Synchronization Service Manager, open the metaverse object for this user.
      • Confirm whether msExchRecipientTypeDetails is present and whether its value is 2.
      • Check the sourceAnchor attribute. If it is NULL, the rule described in the context is filtering the object.
    2. If using an account–resource forest topology
      • Ensure the master user account in the account forest is synchronized first.
      • Once the master account is synced and joined, AAD Connect can create the final cloud connector for the user and project it to the AAD connector space.
    3. If not using an account–resource forest topology (single forest or no linked mailbox design)
      • Change msExchRecipientTypeDetails on the on‑premises user from 2 to a value that is not filtered (for example, 1 or another valid value for a normal mailbox/user that is not in the filter list).
      • This prevents the rule from setting sourceAnchor to NULL.
    4. Trigger a full sync to re‑evaluate the object
      • After correcting msExchRecipientTypeDetails, run the following sequence on the AAD Connect server:
        • Import from AD.
        • Full synchronization.
        • Export to AAD.
      • During this cycle, the object should:
        • Remain in the AD connector space.
        • Be present in the metaverse with a non‑NULL sourceAnchor.
        • Be projected into the AAD connector space.
        • Have the correct mobile value exported to Entra ID.

    Once the object exists in the AAD connector space and is no longer filtered, the mobile attribute will flow from on‑premises AD → AD connector space → metaverse → AAD connector space → Entra ID, and the mobile number in Entra ID will update. Manual overwrite via Graph will still be blocked for on‑premises mastered objects, but it will no longer be necessary because the sync pipeline will be functioning correctly.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.