Using Cloud sync to sync AD to existing Entra Accounts

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.

Well, it was a disaster. I setup up a filter and the sync process was creating a new account (due to roles). I then changed the filter and it deleted everything. I removed the configuration and restored the accounts.

I then removed the roles on my test account (mine), then setup the configuration again with the filter pointing a test OU again, and now it won't sync as it recognizes there is an existing Entra account with conflicting attributes.

UPN, SMTP are the same in Entra and in AD.