SQL-Active Directory Mismatch Prevents Skype4B User Login

User accounts. They seem like simple things, don’t they? Enter your email and a password, log onto Skype (or your laptop, Outlook, etc.) and start work.

But we know better. In reality, every user account has several moving parts behind it. Server names, Active Directory credentials, database entries…all interconnecting behind the scenes. Making your login process the usual 5-second time-to-get-going routine it is.

Until one of those parts breaks.

An SID Mismatch Lurking Between Database and Active Directory

The other day, our Skype for Business team assisted a customer who couldn’t login to their Skype account. The password was correct. The user account shows as valid in Skype’s Control Panel. Where’s the issue?

Since the user shows up in the Skype4B Control Panel, we went to the logs. Soon we found a telling error:

“Failed to authorize user credentials
User Token SID S-XXXXXX did not match DB SID S-XXXXXXX”

An SID mismatch. What would cause that?

In this case, the most likely reason was old Lync information.

User Replicator Issue in the Database, Maybe From In-Place Upgrade

A few weeks prior, we’d performed an In-Place Upgrade for this customer. Lync Server 2013 on-prem to Skype for Business 2015 on-prem. The upgrade itself went all right – a couple snags with Exchange, which we smoothed out.

However, it appears another error had surfaced. We checked our runbooks; no previous incidents like this. So we searched online. We came across this post from Mostafa, a Lync/Skype for Business consultant in Germany:

Lync/Skype for Business – LS User Replicator Event ID 30020 – The Lync Dude

We tried the PowerShell cmdlet indicated in the post: Update-CsUserDatabase

Sure enough, we got the same error message.

“Event ID 30020, source ‘LS User Replicator’
User URI is already being used by another valid user in the database…”

So what we had was a user account with some conflicting information between Active Directory and SQL Server. Residual information from Lync 2013 days, it appears, got stuck in the server database.

How? Not sure. Possibly a bug in the In-Place Upgrade. We made note to report it to Microsoft. But first, we needed to fix it!

The Solution – Modify SQL Database. Success, But There was a Snag

The blog post indicated a solution. Careful though – it involves directly modifying SQL databases. Chances of breaking the database, and your Skype4B right along with it, are significant. Make a FULL backup before trying this.

Disable and delete the user from your Skype for Business Control Panel. Note down the user’s SIP address.
Login to the Front End Server.
Start SQL Management Studio.
Connect to the RTCLOCAL Instance. (THIS is where it gets risky!)
Run the following query against the RTC database: Execute dbo.RtcDeleteResource ‘[the user’s SIP address]’
Restart the following services on the Front End:
- Master Replica Agent
- Replica Replicator Agent
Wait a few minutes.
Recreate the user account in Skype for Business Control Panel.
Wait a few more minutes for full replication.

We hit a snag though – the process didn’t work for us! Even after several tries.

So we called Microsoft Support. We shared the SQL solution. Shouldn’t this work, we asked? Yes, said the Support rep, it should. Let me try it.

We granted the Support rep access. He logged into SQL, tried the query…and it worked.

Everyone blinked at each other for a moment. The same process, the same database, and the same access permissions. Nobody could explain why it worked when the Microsoft Support rep did it, but not when we did. Even the Microsoft rep admitted he wasn’t sure why!

But, no matter how, the fact is that it did work. We recreated the user’s account, and there were no more login issues.

Editing SQL a Last Resort, But for an ID Mismatch Like This One, It Worked

Bit of a mystery, start to finish. We did report the initial issue to Microsoft, of course. The rep said they had a similar bug logged (possibly by Mostafa).

I’m documenting the experience, mysteries and all, for our fellow Skype4B pros. If you do encounter a user account which mysteriously refuses to log in, may this post help you fix it!

Have you encountered a user account issue that required editing SQL to fix? Please comment or email. I’m curious what other issues like this (if any) exist out there.