sync-generic-failure -->"Current Object $$$ is trying to connect to MV object id $$$ which is already connected to at least one other object"
Had an interesting one this week.
A single on-premises AD Object's properties were not syncing to AAD. Hard to not believe the issue is related to a recent AAD Connect Upgrade I completed. Searching the AAD Connect Metaverse on the new Connect server and cannot find the object! Turns out, this object hadn't synced to the cloud in months. I go back to original AAD Connect server in Staging Mode, find the operation in the Sync Manager with the error, and in the Stack Trace I see:
"InnerException=> Source Anchor was Changed"
In previous versions of AAD Connect (DirSync and AAD Connect v 1.1.486.0 and older), the on-premise ObjectGUID was used as the "Source Anchor" to uniquely identify an object as being the same object on-premises and in Azure AD. In AAD, this attribute is called the ImmutableID. In newer versions, the AD attribute ms-DS-ConsistencyGuid is facilitated for use as a Source Anchor. This is used to do a Hard Match with the objects.
Other findings...
I export ADDS properties (Ldifde command) and examine the file for the account in question and find mismatch between ObjectGUID and Ms-DS-ConsistencyGUID. Actually, I converted the ObjectGUID from Base64 to type String and the ImmutableID in the Ms-DS-ConsistencyGUID attribute was for a different user (what?!)!
After staring and clicking for hours.... FIXED! (Thank you MS Community)
As my one good friend facetiously states when faced with the "fun" IT issues, "I love my job". Those ones that make you realize you're about to learn something....
The Stack Trace on the old server assisted because this account did happen to sync once when the on-premises account was first created, but that was the last time.
So the object did exist in the AAD Connect Metaverse on the old server and this is where I can see the SourceAnchor was changed message (still trying to answer how this happened only impacted one user). In researching this ms-DS-ConsistencyGUID, I discover that, despite the word "Immutable", this field is actually writable. And in ADDS, the ms-DS-ConsistencyGuid attribute's value is HEX. So we must convert the type String ImmutableID (we converted earlier from Base64encoded to String earlier) and replace the incorrect value currently present for this attribute.
Recommended by LinkedIn
First, I move the Object from it's current syncing OU in Active Directory to an OU that does not sync and run a Delta Sync on the AAD Connect server. You should see the an Export operation to the Azure AD Connector Space showing "Deletes" and the object in question should appear.
Once the sync completes, proceed to updating the mS-DS-ConsistencyGuid in ADDS Attribute Editor (highlight the white text box and "ctrl + V" to paste the HEX value and click "OK" and then "Apply".
After making the change to the ADDS object, I move it back to it's original OU, and then run another Delta sync on the AAD Connect Server:
Start-ADSyncSyncCycle -PolicyType Delta
Success! I can see the Connector Operation showing an "Adds" and the problematic AD Object is finally syncing to Azure AD! The object in Azure AD is also now showing today's date for the last time it was synced and all of the properties that were changed in ADDS on-premises are now showing up in in AAD. I still have some things to figure out to understand what happened to this account in the first place.
Awesome. Glad to help. Good old days working with these legends Cesar Hara and Victor Santana 😁
Glad this article helped you resolve the issue and appreciate you taking the time to write about it! 👍👍👍