Microsoft Security | Microsoft Entra | Microsoft Entra ID
A cloud-based identity and access management service for securing user authentication and resource access
Autodiscover Error 500: Ghost ImmutableID mismatch between Entra Portal and Graph API after migration
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(124.80000000000001, 45%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMD%3C/text%3E%3C/svg%3E)
Muhammet Dilber
50
Reputation points
Hi everyone,
I’m struggling with a persistent issue regarding migrated users from Exchange On-Premise to Exchange Online.
The Problem:
- OWA and Outlook Mobile: Working perfectly.
Outlook Desktop: Fails during setup with Error 500: The email address can't be found.
Microsoft Connectivity Analyzer: Confirms the Error 500, even though the request reaches the correct Exchange Online backend.
The Technical Discrepancy: This is the most confusing part:
Entra ID Portal: Shows a value for On-premises immutable ID.
Microsoft Graph API (Get-MgUser): Returns the OnPremisesImmutableId attribute as NULL.
Microsoft Graph API (Update-MgUser): When I try to manually clear or set the value, I get a 400 BadRequest.
Legacy MSOnline: Connect-MsolService is forbidden (403), so I cannot use the old module to force clear the anchor.
Current State: The accounts are marked as "In Cloud," and Directory Sync has been disabled for a long time. It seems like a "ghost" attribute exists in the Portal's UI/Database that isn't accessible via Graph, causing Autodiscover V2 to fail.
Question: I've heard about a "Backend Force Clean / Re-provisioning" process that Microsoft Support can perform. Has anyone successfully triggered this or found a way to resolve this identity desync without a support ticket?Hi everyone,
I’m struggling with a persistent issue regarding migrated users from Exchange On-Premise to Exchange Online.
The Problem:
OWA and Outlook Mobile: Working perfectly.
Outlook Desktop: Fails during setup with Error 500: The email address can't be found.
Microsoft Connectivity Analyzer: Confirms the Error 500, even though the request reaches the correct Exchange Online backend.
The Technical Discrepancy: This is the most confusing part:
Entra ID Portal: Shows a value for On-premises immutable ID.
Microsoft Graph API (Get-MgUser): Returns the OnPremisesImmutableId attribute as NULL.
Microsoft Graph API (Update-MgUser): When I try to manually clear or set the value, I get a 400 BadRequest.
Legacy MSOnline: Connect-MsolService is forbidden (403), so I cannot use the old module to force clear the anchor.
Current State: The accounts are marked as "In Cloud," and Directory Sync has been disabled for a long time. It seems like a "ghost" attribute exists in the Portal's UI/Database that isn't accessible via Graph, causing Autodiscover V2 to fail.
Question: I've heard about a "Backend Force Clean / Re-provisioning" process that Microsoft Support can perform. Has anyone successfully triggered this or found a way to resolve this identity desync without a support ticket?
Microsoft Security | Microsoft Entra | Microsoft Entra ID
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(233.6, 85%, 32%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EVS%3C/text%3E%3C/svg%3E)
VEMULA SRISAI 13,900 Reputation points Microsoft External Staff Moderator2026-02-28T07:25:07.5266667+00:00 Hello Muhammet Dilber,
What you’re seeing is unfortunately a known backend desync scenario, and your analysis is already spot‑on.
When a user was originally directory‑synced and later converted to cloud‑only, Exchange Online and Entra don’t always release the internal source anchor mapping correctly. The Entra portal UI is showing a cached / legacy value, while Microsoft Graph correctly reports
OnPremisesImmutableId = null. That mismatch is enough to break Autodiscover V2, which Outlook Desktop relies on (OWA and mobile don’t).A few important clarifications:
- If
onPremisesSyncEnabledis false, Graph is authoritative — but it cannot touch hidden legacy identity rows. -
Update-MgUserreturning 400 is expected; Graph blocks manual changes to identity anchors once the object is considered cloud‑managed. - MSOnline (
Set-MsolUser -ImmutableId $null) is intentionally blocked now; even if accessible, it no longer fixes this state. - This is not an Exchange mailbox issue — it’s an identity provisioning artifact. Can this be fixed without Microsoft Support?
: No not once you’re in this state.
There is no supported self‑service or Graph‑based method to remove the “ghost” immutable anchor that lives in the backend identity store. Tools and APIs can only modify what Graph exposes, not the hidden linkage Exchange still evaluates during Autodiscover.
- If
Sign in to comment
Sign in to answer