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.

Roll forward to go-live and we have a few users complaining they can’t login. They’re getting an invalid credentials error, and I’m seeing Warning 30020 in the Event Logs:
 

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:user.name@contoso.com /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 : user.name@contoso.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…

G.