Ahh the joy’s of lifting legacy AD accounts into Office365…
If you’re here, you have probably searched for the above error message when attempting to assign a “MCOEV” (“Microsoft Teams Phone Standard” at the time of writing) or maybe even some other license to a user via the MSOL PowerShell module and getting the error message “Uniqueness violation. Property: ProxyAddresses”
Or maybe you’re attempting this in the O365 Admin Center and getting an error message like this.
Well, I had it happen today, and if you’re just looking for the solution. Check your Directory Sync Errors in O365 and remove the duplicate account or attribute.
But, if like me, you want to know a little more. Read on
The Teams Voice User That Could(nt)
Recently as part of a migration of a customer of mine. I ran into a weird issue with our Pre-Migration Checks where a user was returning “Uniqueness violation. Property: ProxyAddresses” when attempting to assign the prerequisite licences.
Just in case there was something weird going on with my script. I tried to assign the licence again manually in PowerShell, and then in the Office365 Admin Center. But still, the error persisted.
I tried moving the user from Skype for Business to Teams to see if potentially that would solve the problem. Initially thinking it was SipProxyAddresses the error message referred to. But still, No Bueno.
Eventually, I went back to the Office365 Admin Center error message which suggested that the email address was being used by the account in question.
Just to be sure there weren’t any funny characters. I stuck both account names into Notepad++ and searched for them. Both UPNs matched exactly, so that error message wasn’t exactly helpful.
Moving onto a different tack. A quick “Get-CsOnlineUser” and I had all the users details. I could see that the user had been assigned an MCOProfessional licence, yet there was no MCOValidationError.
But what I could see is that their OnPremSipAddress and a few of the proxy addresses were from a different spelling of their name.
So my first troubleshooting step was to update their SIP address to match their UPN by running Set-CsUser on-prem and waiting for AADSync.
Once that was replicated, I tried again only to receive the same error.
Ghosts of the Past
When the Sip Address rename failed, I dug a little deeper into the customer’s AAD. What I found was we were attempting to assign a licence to a user that had a Sync Error. The uniqueness error message was talking about Exchange Proxy Addresses instead of the SIPProxy address attribute in Skype for Business.
Navigating to the customers AADSync errors in the Office 365 Admin Centre, I quickly found the offending user.
Search for the offending user and click on the search result
In this case, I saw there were two different accounts with differing source anchors, both of which come from On-Prem AD.
Checking on-prem AD… Sure enough, I find two accounts with the same name. Just different UPN Suffixes.
A quick jaunt into ADSIEdit later and again, Both accounts have a ProxyAttribute of [email protected]
Luckily one of the accounts was disabled. So the solution was as simple. Email the Identity team and ask them to remove the account, or the duplicate SMTPProxyAddress from the disabled account.
Then, boom. Licence assigned and user migrated successfully.
If you’re after more information about how AzureAD (and thus Teams) calculate proxy addresses. Check here