Forum Discussion
Entra Connect Sync duplicated UPN
Hi, Robert.
I'm assuming this is being reported within AAD Connect on the export cycle of the Azure AD tenant connector.
If so, then I'm also going to assume it's showing as an 'AttributeValueMustBeUnique' error.
If the above holds true, then the error is accurate and within the error is a "detail" button, which when clicked opens a new window with greater detail. Part of that detail is 'ObjectInConflictId' GUID.
This GUID is the objectId (or simply "id" if using Graph) of the existing Azure AD object (most likely a user object but doesn't have to be), and it's this explicit Azure AD object you should be checking for the conflict.
The Get-ADUser commands you've listed will not help diagnose Azure AD objects as those commands face the on-premise environment. Keeping in mind that the on-premise attributes are not written back to, then what exists on-premise does not necessarily reflect what's in Azure - which is even more true for proxyAddresses, which exists as something called a "shadow attribute".
Rather, if you're going to use PowerShell for checking Azure objects, you should be using the current commandlets from the Microsoft.Graph.* suite of modules (such as Get-MgUser for user objects).
It's also important to note that the Azure ID object in conflict does not have to originate from on-premise via AAD Connect. It could just as easily be an Azure-only object created/updated manually by an administrator (be that directly or via a script).
When checking the Azure AD object in conflict, you want to be checking all the name-based addressing attributes, such as:
- imAddresses;
- mail;
- proxyAddresses;
- userPrincipalName.
Cheers,
Lain
- Thanks for the very good explanation. You are indeed right and will search for the GUI in Azure.
- Found the error. The error message detail window was a bit misleading, i think.
Error message: Object With Conflicting Attribute.
It complained UPN was identical with "Object With Conflicting Attribute" and listed a user object with a identical UPN. So far, so good.
But it also listed a user object under "Existing Object" with a complete different UPN and GUID. I thought, it was this user object there was a conflict with, but indeed it was not.
The conflicting user object was under deleted users. As soon as i permanant deleted the deleted user object Azure Connect sync synced with success.
I don´t know why Connect Sync/Azure reports back a "Existing object" which has nothing to do with the sync errors.Deleted users are still included in the reporting since they can readily be restored during that soft-deletion phase.
Once they transition from soft-deleted to hard-deleted (a 30 day window), they literally no longer exist and any blocking conditions will automatically be resolved.
As you've discovered, if you manually hurry the transition from soft-delete to hard-delete along, you can resolve the conflict ahead of the default wait period.
Cheers,
Lain
