Forum Discussion
Entra Connect Sync duplicated UPN
- RVilhelmsenSep 16, 2024Copper ContributorI have no on-prem exchange. All mailboxes exist in M365.
- LainRobertsonSep 17, 2024Silver Contributor
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
- RVilhelmsenSep 17, 2024Copper ContributorThanks for the very good explanation. You are indeed right and will search for the GUI in Azure.