How to remove immutibleid from entra object

Question

I was a hybrid envrironment, trying to sync local AD accounts one at a time by only syncronizing a pilot OU. I move the user in the pilot OU, update the user@company to match the entra UPN, and the syncronizing. I was doing great until i made a mistake and the AD user I updated had a typo in the usr@company. when i syncd, it created a usr@company, with the immutibleid (GUID) of the AD user account. how am i supposed to undo the immutibleid from the bogus entra account and syncronize it with the correct licensed entra account?

The immutableId is attached to the user in entra that was created when i syncd the local AD account before i made the UPN match the licensed account in Entra (my mistake) . I want that immutableID to be on the licenses account, because it is the base64 of the GUID for the local AD account. Currently the licensed Entra account has no immutible ID or sync is false.

Answer 1

To move the on-premises ImmutableId (sourceAnchor) association from the wrong Entra user to the correct licensed Entra user, the incorrect synced object must be removed so that soft match can occur against the correct account, which currently has no ImmutableId.

Use this sequence:

1. Confirm which object currently holds the ImmutableId
   • The bogus Entra user (created when the typo UPN was synced) is the one that:
     • Shows as “synced from on-premises” (dirSyncEnabled = true).
     • Has immutableId populated (base64 of the on-prem GUID).
   • The correct licensed Entra user:
     • Is cloud-only (dirSyncEnabled = false).
     • Has no immutableId value.
2. Remove the bogus synced Entra user so it no longer owns that ImmutableId
   The supported way to free that ImmutableId is to remove the synced object, not to edit ImmutableId directly. a. In on-premises AD:
   • Move the corresponding AD account out of the sync scope (for example, out of the pilot OU) or delete/disable it if appropriate.
   b. Force a full sync so the deletion/export is processed:

      Start-ADSyncSyncCycle -PolicyType Initial
   

   c. Verify in Entra that the bogus user is removed.
   If the deletion does not flow and the object becomes orphaned, remove it manually using Microsoft Graph PowerShell:

      $user = Get-MgUser -Filter "userPrincipalName eq '******@company.com'"
      Remove-MgUser -UserId $user.id
   

   This ensures no Entra object remains with that ImmutableId or with the conflicting UPN.
3. Prepare the correct licensed Entra user for soft match
   For soft match to succeed:
   • The correct licensed Entra user must not have an immutableId (already true in this scenario).
   • Its UPN must be exactly the same as the on-premises UPN that will be synced (for example, ******@company.com).
4. Correct the on-premises AD user and bring it into scope
   On the on-premises AD user that represents the same person:
   • Fix the UPN so it exactly matches the licensed Entra user’s UPN.
   • Ensure this AD user is placed back into the pilot OU (or otherwise in the sync scope of Entra Connect).
5. Run sync again to trigger soft match and set ImmutableId on the correct account
   Run another sync cycle:

      Start-ADSyncSyncCycle -PolicyType Initial
   

   During this sync:
   • Entra Connect calculates the sourceAnchor from the on-prem attribute (typically msDS-ConsistencyGuid or objectGUID).
   • Because the correct licensed Entra user has no immutableId, Entra ID can perform a soft match using UPN.
   • The existing licensed Entra user is then linked to the on-prem account, and its immutableId is populated with the base64 value of the on-prem GUID.
6. Handle possible data-mismatch errors
   If any other object still exists with the same UPN or with an immutableId value, Entra may raise an InvalidSoftMatch or other data-mismatch error. In that case:
   • Remove or correct the duplicate object (usually another test/bogus account) so that:
     • Only the intended licensed Entra user has that UPN.
     • No other object has an immutableId that conflicts with the on-prem sourceAnchor.
   • Run sync again after fixing the duplicates.

Key point: ImmutableId is not meant to be edited or moved between existing Entra objects. The supported pattern is to remove the incorrect synced object so that, on the next sync, soft match can attach the on-premises sourceAnchor (ImmutableId) to the correct cloud user.

---

References:

• Understanding errors during Microsoft Entra synchronization
• Object deletions aren't synchronized to Microsoft Entra ID when using the Microsoft Entra ID Connect
• Microsoft Entra Connect FAQ
• Tutorial: Migrate Okta sync provisioning to Microsoft Entra Connect synchronization
• Plan and troubleshoot UserPrincipalName changes in Microsoft Entra ID
• Merge 2 Objects (1 from Azure cloud only tenant and 1 on-prem sync) for same user - Microsoft Q&A