Posted on

Lync 2010 with WildCard Certificates

Lync 2010, is a terrific piece of software that allows for simple, effective collaboration for all sizes of businesses. Unfortunately,the architecture of the application is kludged together in a half baked form. What this also means that is that the Lync team decided to support “SAN” or “UCC” certificates so they can secure multiple domains with one certificate. However, they neglected to support wildcard certificates completely. This has been somewhat resolved with the latest Cumulative Update 6 (CU6), but still a nightmare to get going.

Even with this blog post, you may find it a nightmare to get it to work. Here are the steps that worked for me. This is for a 3 server setup, two front ends, and one edge.

1) Get a good wildcard cert. The EssentialSSL Wildcard from Comodo worked for me. The PositiveSSL did NOT.

2) Get the thumbprint of the SSL.

3) Install the certificate on all the machines. Make sure its in the My Computer sectionof the Certificate Manager

4) Open the Lync Powershell.

5) For the front end pools, enter the following command
Set-CSCertificate -Type Default,WebServicesInternal,WebServicesExternal -Thumbprint <thumbprint> -Verbose -Confirm:$false -Report c:\temp\test.html

6) For the edge pools, enter the following command
Set-CSCertificate -Type AccessEdgeExternal,DataEdgeExternal,AudioVideoAuthentication -Thumbprint <thumbprint> -Verbose -Confirm:$false -Report "c:\temp\test.html"

7) On all machines, create the reg dword key
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"Sendtrustedissuerlist"=dword:00000000

Reboot. Check your event logs to see if it took. When I used the PositiveSSL Wildcard, it did not work -the system simply didn’t trust it. The EssentialSSL worked fine.

Posted on

Lync 2010 Hanging up after call connected

Hello, a quick post. Over the past few weeks, I noticed that Lync calls were hanging up on me for no apparent reason. After it hung up on me with a client that needed help right away, I got frustrated and tried to figure out what the problem was.

After looking around, I found the issue to be multiple ip’s on my workstation that were un-routable. I had added static IP’s to my workstation to configure some routers and switches, and didn’t remove them after I was done.

Apparently, Lync tries the other IP’s if they think its going to work better – in the process, it hangs up the call when it tries to connect to one of the non routable ip’s.

So, if you have having an issue with Lync which causes a call to connect, and then get disconnected after 5-10 seconds – look at your ip configuration.

Possibly related to Call Admission Control and Media Bypass.

Posted on

Lync Application Sharing and Software Firewalls

Quick post on a discovery I made. I setup a complete infrastructure on an Hyper-V host for a customer (co-located at a datacenter), and one of the components of this infrastructure was Lync 2010. Lync is a phenomenal piece of software that allows for full collaboration for an enterprise without using third party services.

After the complete setup, we noticed that external users were not getting a great experience using desktop sharing / application sharing features from within Lync. Upon further investigation, it turned out the firewall was getting slammed (a virtual instance of pfSense on the hyper-v host). It appears that Lync floods the servers with as much udp traffic as configured to allow, and this causes a problem for the pfSense install which uses emulated network cards. My theory is that the software interrupts that are getting triggered for the emulated network card eats up all the cpu time on the guest OS giving it little time to do the routing/natting it needs to accomplish.

We solved this by using a very simple Linux firewall, although I could have easily just moved the pfSense install to a real machine and would have accomplished the same result. I also wonder if using a CentOS based firewall on the Hyper-V host would have solved the problem since it is supported using Hyper-V’s synthetic nics.