microsoft lync stopped working windows 10

The client will fill the username with the SIP address (and also the ServerUsername key). If the user sip address doesn’t match the Active Directory, doesn’t matter if the user put the wrong or right password. If both keys don’t match, it will popup the password prompt for the user. If both keys match, the client will use the Windows domain user credentials to sign-in (and no one complains about it anymore).ģ. At startup if the registry key ServerSipUri has an address, the client will query the active directory for the user’s SIP address and write it on the WindowsAccountSipUri.Ģ. “Goggle-fu” didn’t help too much (if MS is reading this: why KB only refers to issues fixed/new but rarely mentions changes on behavior? why a “security update” includes new features?), and after an overnight of tests here’s how the new updates changed the client logon process:ġ.

The bottom one WindowsAccountSipUri came quickly to my attention. KB3114351 and KB3114502 changed the Client Sign-in algorithm and some particular deployment scenarios were not tested (check ‘affected scenarios’ below).īy using an issue-free client connected on the internal LAN (this is important later), when the client starts six new (there are more) registry key appear:

The main clue that something is wrong is when you see the username filled with SIP address (picture on the right) and you know that is not the correct user’s AD login and the user was never asked before for credentials because the client should use the Windows domain logon credentials. So… after you applied the KB3114351 -security update for Lync 2013 (Skype for Business): December 8, 2015- or the KB3114502 – January 12, 2016, update for Lync 2013 (Skype for Business) some (if not all) of your users will start complaining that the SfB Client is asking for credentials at startup.

It’s ‘reverse engineering’ time, install/remove updates and work for MSFT for free… again.

Microsoft lync stopped working windows 10