Forum Discussion

tjcooper2's avatar
tjcooper2
Copper Contributor
Jul 09, 2026
Solved

Using Cloud sync to sync AD to existing Entra Accounts

I want to sync in premise AD accounts with existing Entra accounts. The email on both accounts is the same, and I added the Entra/o365 suffix to the domain and set the UPN to that suffix, making both...
Active Directory
Identity Management
microsoft 365
microsoft entra
  • Jamony's avatar
    Jamony
    Jul 10, 2026

    Hi, matching only by email address can unfortunately be unreliable.

    Before bringing the users into the Cloud Sync scope, I would compare the on-premises UPN, primary SMTP address, proxy addresses and existing Entra account. Also confirm that the cloud account is not already controlled by another synchronization engine.

    For a controlled migration, use the source anchor or onPremisesImmutableId to hard-match the existing Entra account instead of relying only on soft matching.

    I would start with two or three test users in a separate OU. If a duplicate account has already been created, pause synchronization for that user before deleting or changing anything, especially when a mailbox and licences are attached.

ali_z's avatar
ali_z
Copper Contributor
Jul 11, 2026

You're close. When a hard match SHOULD work but the object still won't link, it's almost always one of four things. Work it diagnostic-first:

1) Pull the actual error. Run Provision on demand against the one test user and read what it says:

  • Entra admin center > Entra ID > Entra Connect > Cloud sync
  • Under Configuration, select your config > left menu > Provision on demand
  • Paste the user's Distinguished Name > Provision

Success shows four green checks; a failure shows the step and error on the left. You're looking for InvalidSoftMatch vs InvalidHardMatch they point to opposite fixes. (Note: Cloud Sync has no manual delta sync, the scheduled cycle is only every 10–20 min, so this is the only way to test on the spot.)

2) ImmutableID must be Base64 of the anchor, not the raw GUID. This trips up almost everyone. Compare:

[System.Convert]::ToBase64String((Get-ADUser <sam>).ObjectGUID.ToByteArray()) 
Get-MgUser -UserId <upn> -Property OnPremisesImmutableId | Select OnPremisesImmutableId


Byte-for-byte or it won't hard match. Cloud Sync default anchor is ms-DS-ConsistencyGUID, but on a new forest it sometimes uses objectGUID if ConsistencyGUID is empty, base it on objectGUID.

3) Confirm the old duplicate is HARD-deleted, not soft-deleted. It sits in the recycle bin for 30 days still owning the UPN/proxyAddresses/anchor, which silently blocks the match:

Get-MgDirectoryDeletedItemAsUser | ? { $_.UserPrincipalName -like "*<name>*" } 
Remove-MgDirectoryDeletedItem -DirectoryObjectId <id>


4) The July 1, 2026 hard-match hardening could be the most likely issue in your case since Entra now auto-blocks a hard match when the target has onPremisesObjectIdentifier set or BlockCloudObjectTakeoverThroughHardMatchEnabled is on. Microsoft's documented trigger, object restored from the recycle bin, then re-added to scope trying to take over an object with the same sourceAnchor which matches your situation almost exactly. That shows as InvalidHardMatch; fix is to review the takeover-protection setting, not re-edit attributes.

Given you've cleared the roles, aligned the ID, and removed the duplicate, it's #3 or #4. Run Provision on demand and post the error code.