I spent the last few days fighting with duplicate object errors for an Off365 Dirsync project. The project was to setup dirsync, and single sign-on with ADFS / STS for a customer. The trouble shooting documentation from Microsoft, while informative, did not seem to jive and make sense enough to help me formulate a solution to the problem. I tried a number of things, and ended up getting frustrated. Eventually the opportunity to ask coworker and fellow ExMVP, Ben Winzenz for help presented itself to me and I asked for help. Ben only needed to give me few words in the right direction then it all became clear.
Sadly – Not many screen shots // I figured the fix would be better documented then it was, and I did not take screen shots of error in action. Plus I’m too lazy to rebuild it all in a lab for screen shots. You only get what I did take the time to capture in the end.
Customer had 5 objects, a total of 10 errors in the Azure AD console (aad.portal.azure.com) and the same 10 errors in the Office 365 Admin Console (portal.office.com) – the Errors were “we detected a duplicate UserPrincipalName conflict” and “we detected a duplicate ProxyAddresses conflict” Looking at the objects in ADSI on onprem and in the admin console online there were no duplicate or mismatched values. From what I could see no values were present that would prevent the objects from being linked by dirsync.
What was present was an object manually created in cloud, and an object automaticly created by dirsync synced to the local AD account. Because there were two accounts with duplicate things dirsync could not link the objects how I expected the to be linked. I’m thinking what needs to happen is for one of the accounts to be deleted then Dirsync can come along and link things up properly.
My attempt that came closest to fixing the duplicate objects was move to the bad users into an OU onprem out of scope and run a delta sync. Dirsync removed the duplicate objects from the cloud after moving the users out of scope. I made sure the objects onprem and in cloud had enough similar attributes matching to sync. Even added a few more onprem like ProxyAdresses to make sure Dirsync would snyc objects.
Then I moved the users back into scope and ran a delta sync again. Sad face, the bad duplicate cloud objects came back. Why do you hate me dirsync? Did Les tell you to hate me?
The Fix after a helpful hint – recycling bin
The above steps were close to working, but missed key one part. The missing part Ben gave me with a few words. He said bla bla you need to purge from recycling bin bla bla other wise reanimate After reading Ben’s words, I instantly thought
- A. Zombies are awesome, reanimate!!, and
- B. DUH!! remove from recycling bin otherwise we restore the object vs. make a new one because that’s what most customers want / expect.
Basicly, what needs to happen is the falsely created duplicate object in MSOL / AzureAD needs to be deleted, then purged. After the purge Dirsync will come along and merge/ sync the onprem object with the correct MSOL object. below is an annotated copy of my powershell session where I did just that for one the duplicate objects in my error report.
## Connect to MSOL PS C:\Users\dakevinm\Desktop> Connect-MsolService ## search for the user you want to delete PS C:\Users\dakevinm\Desktop> Get-MsolUser -SearchString srempe UserPrincipalName DisplayName isLicensed ----------------- ----------- ---------- firstname.lastname@example.org Rempe, Shari False email@example.com Rempe, Shari True ## work out which one has been synced before by looking for immutableID. ## If ImmutableID = a blob of odd things then this object has been synced PS C:\Users\dakevinm\Desktop> Get-MsolUser -SearchString srempe | ft userp*,imm* UserPrincipalName ImmutableId ----------------- ----------- firstname.lastname@example.org gkpEkRL/ykafyN5ZWRImdg== email@example.com ## delete the synced user from MSOL, not in onprem, causing the sync error PS C:\Users\dakevinm\Desktop> Get-MsolUser -SearchString firstname.lastname@example.org | Remove-MsolUser Confirm- Continue with this operation? [Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): Y ## remove the deleted user from the recycling bin so we don't reanimate it later, create a zombie and break things again PS C:\Users\dakevinm\Desktop> Get-MsolUser -SearchString email@example.com | Remove-MsolUser -RemoveFromRecycleBin -force ## Kick off a fresh sync cycle to clean up the mess. PS C:\Users\dakevinm\Desktop> Start-ADSyncSyncCycle -PolicyType Delta ## Wait for a while, In my case I kicked off a few more deltas just to be sure ## took about 10-15 minutes for the accounts to sync up proper.
3 thoughts on “Duplicate UserPrincipalName conflict”
good post Kemi – ty
Yes, I did tell Dirsync to hate you 🤣