Enabling Lync/SfB Client to use proxy server for SIP traffic instead of trying direct connection

Update 2017/09/12 – Added SfB2016 MSI (16.0.4588.1001).

We had some reports that when trying to sign in to Skype for Business Online users were experiencing delays during the sign in process.

This behavior was related to environments were the Lync/SfB client is configured to use a Proxy Server to connect to the Skype for Business Online servers.

After researching the delay was occurring because the client was trying establish a direct connection and only after that connection timed out it would try to connect using the configured Proxy Server:

As a workaround we could configure the Firewalls to send RESET Packets and the Lync/SfB client won’t wait for the connection attempt to timeout.

Since the following client updates we can use a registry key to force the client to use proxy for all connections:

December 6, 2016, update for Skype for Business 2015 (Lync 2013) (KB3127976) (15.0.4885.1000)
https://support.microsoft.com/kb/3127976

Description of the security update for Skype for Business 2016: September 12, 2017 (16.0.4588.1001)
https://support.microsoft.com/kb/4011040/

Office 365 ProPlus/Office Professional Plus 2016 Click-to-Run

Version 1611 (Build 7571.2072) – December 6, 2016
https://technet.microsoft.com/en-us/library/mt592918.aspx

To configure Lync/SfB client to use a proxy server for SIP Traffic without attempting a direct connection we need to add the following registry key:

reg add HKCU\Software\Microsoft\UCCPlatform\Lync /v EnableDetectProxyForAllConnections /t REG_DWORD /d 1 /f

Note: This registry key is only available on a User Level, we cannot add it under HKEY_Local_Machine.

Lync/SfB Client tries to use proxy server instead of direct connection when using Proxy PAC on Windows 7

Update 2016/08/16 – This only happens on Windows 7, for Windows 8.1 and Windows 10 we don’t need to change the Proxy PAC file.

Recently we received some reports saying that Lync 2013 and Skype for Business 2015/2016 clients were trying to use a Proxy Server for lyncdiscover and lyncdiscoverinternal URLs when the Proxy was configured using a Proxy PAC script.

During the discovery process, the Lync/SfB client will check the Proxy PAC file with the following URLs:

http://lyncdiscoverinternal.gears.lab?sipuri=baird@gears.lab
https://lyncdiscoverinternal.gears.lab?sipuri=baird@gears.lab

http://lyncdiscover.gears.lab?sipuri=baird@gears.lab
https://lyncdiscover.gears.lab?sipuri=baird@gears.lab

For reference, here is a copy of my Proxy PAC file:

function FindProxyForURL(url, host) {

 /* Proxy all other hosts in gears.lab domain */
 if ((shExpMatch(host, "*.gears.lab"))) { return "DIRECT";}

 else { return "PROXY proxy.comm.lab:8080";}

}

We would expect that the following condition would cover the discovery URLs:

shExpMatch(host, “*.gears.lab”)

But it doesn’t, because the host variable will be:

lyncdiscover.gears.lab?sipuri=baird@gears.lab

Although the previous URL is valid it will cause issues in Windows 7.

We currently have two known workarounds:

1) Using the URL

This will match all the discovery URLs:

if ((shExpMatch(url, “http*://lyncdiscover*.gears.lab*”))) { return “DIRECT”;}

2) Using URL and Substring

This workaround requires that you check the length of each URL, but still it is also a valid alternative:

if (url.substring(0,29) == “http://lyncdiscover.gears.lab”) {return “DIRECT”;}
if (url.substring(0,30) == “https://lyncdiscover.gears.lab”) {return “DIRECT”;}
if (url.substring(0,37) == “http://lyncdiscoverinternal.gears.lab”) {return “DIRECT”;}
if (url.substring(0,38) == “https://lyncdiscoverinternal.gears.lab”) {return “DIRECT”;}