Uniqueness violation. Property: SourceAnchor

I’ve run into this error in Azure AD Connect (DirSync), and I thought I’d share how I fixed it – as is often the case with sync errors, the solution is not always obvious and requires some digging!

To start us off, this is what the error looks like: attributes associated with this object have values that may already be associated with another object in your local directory services.

Since the error message helpfully points out the duplicate proxy addresses, that seems like a good place to start; however, clearing out the proxy addresses on prem (or changing it if you prefer) didn’t resolve the problem. Instead, it caused my error message to change from duplicate proxy addresses to duplicate UPN values!

Now, under normal circumstances, I’d just delete the synced object in Office 365, and let AAD Connect put things back together – however, in this situation, I was dealing with accounts that were already in production, and I needed to make sure I could match these accounts up with their on-prem counterparts without causing data loss. If you’re just setting things up, and you’ve got cloud accounts that were created by mistake, or even if they’re not in production yet, you can resolve these issues by deleting the offending cloud accounts, and resyncing from your Active Directory.

Looking back in Office 365/Azure AD, I can see my duplicate accounts – now to figure out which one is the rogue, and which one needs to be kept!

There is an excellent TechNet article that gives us a command we can use to generate the immutable ID on premise, like so:

ldifde -f export.txt -r “(Userprincipalname=*)” -l “objectGuid, userPrincipalName”

(hint: the objectGuid that is output by the command above is your ImmutableID in Office 365)

Using PowerShell, we can look for the account matching that Immutable ID, like so:

Confirmed that this is NOT the account that has a mailbox attached:

Checked again, just to be sure:

Tried changing Immutable ID to null – no problems there:

Set-MsolUser -UserPrincipalName account@domain.onmicrosoft.com -ImmutableId “$null”

The meeting rooms did not have an immutable ID, but adding one would give me the dreaded uniqueness violation error

Now that we know which account is which, go ahead and delete the duplicate account, and remove it from the Recycle Bin. Once the duplicate account is gone, I was able to update the Immutable ID on the production account, so that the DirSync could perform a hard match the next time it ran.

It’s possible that you might run into the issue reported here, and be unable to remove the object in Azure AD, due to it now being a lonely orphan – to get past this hurdle, you’ll need to disable DirSync on your tenant before you can clear out the objects.

Disable DirSync using the following command:

Set-MsolDirSyncEnabled -EnableDirSync $false

Note that you’ll need to wait a while (MS says up to 72 hours – it can happen quicker, but it can definitely take a while, so plan to do this in an outage window, or over the weekend, when you can expect little or no changes to be taking place in your AD).

You can check the progress in PowerShell, which always seems to be quicker than the admin portal, by using

the following commands:

(Get-MSOLCompanyInformation).DirectorySynchronizationEnabled

This one gives you a True or False – obviously we’re looking for it to be false before we proceed.

(Get-MSOLCompanyInformation).DirectorySynchronizationStatus

This command will either be PendingDisabled, Enabled, or Disabled. Once DirSync has been disabled, you should be able to delete the offending account, update your immutable ID on the account that you need to keep, and then turn DirSync back on again.

Once this was done, my accounts synced up again, and I was back in business… hope this helps!