Teams Voice with Direct Routing and NonUniqueOnPremLineURI

[jangliss]

I've been bashing my head for a week+ now on this.  With a customer (already opened an MS ticket, but they are running in circles), assigning phone numbers to users using `msRTCSIP-Line` field on-premises.  When the accounts sync, the numbers are getting rejected with NonUniqueOnPremLineURI and the full text:

<ErrorRecord>
<ErrorCode>NonUniqueOnPremLineURI</ErrorCode>
<ErrorDescription>The value of the MSRTCSIP-Line URI field in your local Active
Directory conflicts with another user. Lync Online features will work except for
Lync-to-phone calls. To resolve the conflict, correct the value in your local Active
Directory. After you correct the value, the value will be updated in your Office 365
directory during the next Active Directory synchronization. If the error persists,
please contact Microsoft support for assistance.</ErrorDescription>
</ErrorRecord>

If I do the following in an MS Teams PowerShell prompt:

Get-CsOnlineUser -Filter "onpremlineuri -eq 'tel:+11234567890'"

A single entry, the one I assigned the value to, is returned.

If I do the following in AD:

get-adobject -Properties userprincipalname,'msrtcsip-line' -LDAPFilter '(msrtcsip-line=tel:+11234567890)'

A single entry, the one I assigned the value to, is returned.  I purposely used `Get-ADObject` just in case something assigned it to a computer, or something stupid (not possible because that attribute only exists on users).

Anybody seen sync misbehave like this? I've even moved users outside the scope of sync to "clear" MS Teams, but still run into the same issues when moved back.

[#2]

@jangliss I would suggest running "Get-CsOnlineUser -Filter "lineuri -eq 'tel:+11234567890'" as this could also be not assigned against that variable. Looking forward to seeing what you get by running that command.

[#3]

@Eric Marsi 

I should have mentioned that, I did that command, and no records returned.  This is sort of expected because it couldn't assign the phone number to a user due to the duplicate number error.

[#4]

have you checked to see if the number was assigned to a resource account?

[#5]

@Eric MarsiYep, not assigned there either.  These are extension based numbers, so tel:+11234567890;ext=112233 and no resource accounts have those numbers assigned.  These are new phone numbers being assigned, originally the numbers were tel:+11234561000 through +11234569999.  Users having numbers moved to +11234567890;ext=<employee id>.  The prefix number was never used elsewhere.

That said, we have this error showing up on 3k other users, so it's not likely a real duplication issue, which is why I have a case open with Microsoft and their troubleshooting has been the same thing I'd already done.  We do have about 100 users that have the same prefix, with different ext= values that are syncing without issues. Comparison between those users and a handful of broken users shows no observable differences other than the values expected (guids, names, phone numbers, etc)