Are you going to VMworld? Do you work with Skype for Business? Are you planning a deployment of Skype for Business that you want to virtualize? Are all your first choice sessions full?
If you answered “Yes” to any of these questions, you should register for VIRT7620: Successfully Virtualize and Operate your Microsoft Skype for Business Infrastructure on the VMware vSphere Platform.
I will be speaking alongside VMware IT on how they deployed Skype for Business and the best practices that were implemented. We will highlight why latency, IOPs and other resources are important to Skype for Business and other Real Time Protocol products.
We will also talk through what happens to a virtual machine when you vMotion it from one host to another and how that would impact Skype for Business.
I hope you will join us to hear all about Skype for Business and virtualization!
I haven’t written a new post in a while as I have not been doing as many deployments lately. I have been focused more on evangelism and speaking with different organizations that are thinking about deploying Skype for Business.
That said, recently I had the opportunity to get back in to the game and start a deployment for a large organization. We were experiencing some issues that necessitated us to do some logging on the Front-end servers. I turned to my favorite tool for this, the CLSLogger which takes advantage of the Centralized Logging Service (CLS).
I would start up CLSLogger and when I attempted to start the scenario, I would get an error like this:
WARNING: Failed on 1 agents Agent - mediation1.domain.com, Reason - Error code - 20000, Message - Unknown error - Error calling agent mediation1.domain.com; Could not connect to net.tcp://mediation1.domain.com:50001/. The connection attempt lasted for a time span of 00:00:02.0228175. TCP error code 10061: No connection could be made because the target machine actively refused it 10.0.0.40:50001. . Please refer CLS logs for details.
When I went to the server and did a netstat, I saw that CLS was not actively listening. I should have seen the system listening on ports 50001-50003.
PS C:\Windows\system32> netstat -an | findstr 5000* UDP 0.0.0.0:500 *:* UDP 0.0.0.0:4500 *:* UDP [::]:500 *:* UDP [::]:4500 *:*
I went round and round with this and ultimately had to open a case with Microsoft on it. After doing some traces and pulling the ETL logs, the Microsoft Engineer got back with and asked how we had generated the certificate. He was seeing the following message in the ETL log (which us mere mortals don’t have the ability to read and the real reason I’m writing this blog article):
29 TL_ERROR(TF_COMPONENT) 14CC.1728::06/08/2016-16:53:00.193.00000010 (CLSAgent,CommandProcessor.Initialize:commandprocessor.cs(247))Exception - [System.ArgumentException: It is likely that certificate 'CN=mediation.domain.com, OU=IT, O=Domain, C=US' may not have a private key that is capable of key exchange or the process may not have access rights for the private key. Please see inner exception for detail. ---> System.Security.Cryptography.CryptographicException: Invalid provider type specified.
We then looked at the certificates installed on the machine by running “certutil -store my”. (I’ve purposfully deleted identifying information and highlighted in red the Provider which is the key piece of information.)
PS C:\Windows\system32> certutil -store my my "Personal" ================ Certificate 0 ================ Serial Number: 5xxxxxx Issuer: NotBefore: 4/15/2016 11:29 AM NotAfter: 4/15/2019 11:59 AM Subject: CN=, OU=IT, O=Domain, C=US Non-root Certificate Cert Hash(sha1): 39 2d..... Key Container = le-360ab342 Unique container name: 5d26bec417ed43b7840b7bf82c2fb363 Provider = Microsoft Software Key Storage Provider Encryption test passed CertUtil: -store command completed successfully.
When we talked to the group that generated the certificate, we found that they used their own template instead of the Wizard in Skype for Business. While you certainly don’t have to use the Wizard, Skype for Business definitely has some requirements on the certs that will work with it. As an example, going to a key length longer that 256 usually doesn’t work out too well. In this case, the Provider was what was wrong.
I then turned to the Digicert Utility, one of our other favorite tools to generate the Certificate Request (CSR). This then utilized the correct Provider which is the Microsoft RSA SChannel Cryptographic Provider. After we issued the new cert and assigned it, we restarted the servers and checked the certs.
PS C:\Windows\system32> certutil -store my my "Personal" ================ Certificate 0 ================ Serial Number: 5xxxxxx Issuer: NotBefore: 6/9/2016 12:02 PM NotAfter: 6/9/2019 12:32 PM Subject: CN=, OU=IT, O=Domain, C=US Non-root Certificate Cert Hash(sha1): 3c e2.... Key Container = 70C232.... Unique container name: 9ed77.... Provider = Microsoft RSA SChannel Cryptographic Provider Encryption test passed
We also started seeing CLS listening as expected:
PS C:\Windows\system32> netstat -an | findstr 5000* TCP 0.0.0.0:50001 0.0.0.0:0 LISTENING TCP 0.0.0.0:50002 0.0.0.0:0 LISTENING TCP 0.0.0.0:50003 0.0.0.0:0 LISTENING TCP [::]:50001 [::]:0 LISTENING TCP [::]:50002 [::]:0 LISTENING TCP [::]:50003 [::]:0 LISTENING UDP 0.0.0.0:500 *:* UDP 0.0.0.0:4500 *:* UDP [::]:500 *:* UDP [::]:4500 *:*
I hope this helps someone else who might end up in this situation.
While reading through the In-place Upgrade docs, I spied this little nugget:
Be sure to uninstall LRS Admin tool for Lync Server 2013 before running In-Place Upgrade. The LRS Admin Tool for Lync Server 2013 cannot coexist with Skype for Business Server 2015. After running In-Place Upgrade install the new LRS Admin tool, see Microsoft Lync Room System Administrative Web Portal for Skype for Business Server 2015
I haven’t tested this but the fact that they say to Uninstall the Lync Server 2013 LRS Admin Portal was the big catch. Make sure you read all of the docs a few times before you start the upgrade process.
Ran into this and felt like until the documentation is updated, I should call this out. On this Technet article, it shows you how to configure port ranges for Edge Servers in Lync Server 2013. In the hopeful case that this page is updated, here is a static image:
The issue with this article is that it appears to tie the port ranges for the Edge server to QoS which is not the case. You need to read the article very carefully. The first sentence in it tells you that you do not need to configure separate port ranges for Audio/Video/Application Sharing on the Edge. It then goes on to tell you how to change the port ranges to match up with what you may have set for your front-end servers.
The problem with this is that you are changing the ports that the Edge will/can communicate on. If you are following Microsoft’s firewall guidance on ports, you should be allowing the 50,000-59,999 port range (TCP and UDP) outbound. If you follow this example, you would need to allow the range 40,803-65,533 (TCP and UDP) outbound.
The article claims you might do this to make administration easier but I will claim just the opposite. Based on what most Lync admins know and what Microsoft states are the default ports, without some really good documentation and knowledge transfer, you are probably setting up a future admin to fail.
If you are wondering what happens when you set this like this but only allow the 50k port range outbound from the Edge servers, here is your answer. When an outside user attempts to call a user who is inside or join a conference, the client will send an Invite that contains SDP candidates. Those candidates will have ports associated with them based on the configuration. The external client will attempt to connect on ports outside of the 50k range that is being allowed on the firewall (i.e. 40,080-49,999 or 60,000-65,533). These connections will fail and the call will fail to establish. On a conference call, this can be seen as the user connecting and disconnecting from the conference several times in just a few seconds.
Many kudos to @tompacyk for helping me see what was happening here.
The most dangerous words that come from my mouth are usually “I’ve been thinking.” When I think, my thoughts go everywhere. Most of the time they go to good places but when things get serious, when big decisions are on the line, my thoughts usually betray me. They go to the dark places of my mind. Fear creeps in and takes over.
I recently had a moment like this. It took a bit to recognize it but once I did, I knew that I had to refocus my thoughts. What I found was hope. We hope for things to come, things we don’t yet have. By focusing on hope, it becomes easier to see good outcomes. Hope for a better a situation, a better future. Hope.
This is a hotfix that you can apply to your Mac if you are running 14.0.10. From the folks I have helped deploy this to, it makes a significant improvement.
The funny part about this is that the hotfix comes as a .exe file which is not native to Mac’s. In order to extract it, open a command window and use the Unzip command, i.e. “unzip hotfix.exe”.
One of the first things I noticed that was fixed in this is that screen shares are much faster and smoother. A co-worker reported to me that he sees less crashes with the Mac for Lync client.
The fact that this is a hotfix instead of just a patch makes it so you have to install it manually. In my opinion, every Mac for Lync user should install this.
If you are in the Denver, CO area on Thursday (10/30), you should come join us at the October Colorado UC User Group (COUCUG) meeting. We have a great line up of speakers! Topics are Lync with Office 365 UM and Lync Contact Center.
We have a ton of give aways from our sponsors too! We will be giving away a tablet, Jabra headsets and more!
Please visit http://www.coucug.org to learn more and to RSVP.