I struck an interesting one this afternoon. BIG thanks to my colleague Dan for the incredibly simple fix.
I’ve deployed an on-premises Lync 2013 for customer. Whilst ostensibly a “greenfield” installation, my initial publish of the Topology revealed there was already a Lync SCP in AD. I removed it easily enough with “Remove-CsConfigurationStoreLocation” and continued.
In the process of deploying Lync I also found there was evidence of an old OCS server – complete with users still homed to it. “Get-CsUser -OnOfficeCommunicationServer | Disable-CsUser” put paid to them – or so it seemed at the time.
A user URI is already being used by another valid user in the database. Resolve the conflict by using a URI that isn't already taken, or deleting one of the users from AD. URI: sip:<username>@contoso.com The DN of the user whose URI User Replicator tried to replicate is: CN=<User>,OU=Users,DC=contoso,DC=com This update came from domain: contoso.com The source of the replication is LocalRegistrarReplication. Cause: Typically caused by having multiple user or contact objects in AD with identical msRTCSIP-PrimaryUserAddress attribute values. Resolution: Use a URI that isn't already taken, or delete one of the offending users. You may use Dbanalyze to diagnose the problem. Log Name: Lync Server Source: LS User Replicator EventID: 30020
I dug out DBAnalyze (part of the Lync ResKit) and asked it what was going on, and surely enough, OCS reared its ugly head:
C:\Program Files\Microsoft Lync Server 2013\ResKit>DBAnalyze.exe /v /report:user /user:firstname.lastname@example.org /sqlserver:LyncFE.contoso.com\RTCLOCAL Snooper Version: 5.0.8308.0 Report created at 10/10/2013 2:54:03 PM on LyncFE.contoso.com. User : email@example.com ------------------------------------------------ Resource Id : 470 Database Type : Usc Db Registrar Pool : OldOcsFE.contoso.com Usc Pool : OldOcsFE.contoso.com GUID : da783a06-73fa-4c54-b6a0-98c75e811d93 SID : S-1-5-21-801303083-1687839967-1462166549-31732 Display Name : User Name Enabled : True OptionFlags : 0x100 RP ArchivingFlags : 0 ForwardingUrl : NULL
I could disable and enable my Lync users to my heart’s content, but it didn’t change anything. Lync was also adamant that there were no users remaining “-OnOfficeCommunicationServer”.
I noted that the SID reported by DBAnalyze was a different object to the active user account, and I then checked the SID in AD to see if they existed as a different name. No luck there either – an error every time. (Thank you PowerShell tips).
In the end the fix was as simple as issuing “Update-CsUserDatabase”.
After waiting a couple of minutes I repeated the DBAnalyze query and the output for each user was vastly different – now all full of Lyncy goodness.
So thanks again Dan. I was worried I was going to have to start hacking directly into SQL, and no-one wants to go doing that…