Archive

Archive for the ‘Lync’ Category

Centralized Logging Service not working in Skype for Business

July 26, 2016 5 comments

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) [3]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.

Categories: Lync, UC

Hotfix for Lync for Mac 2011 14.0.10

February 25, 2015 Leave a comment

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.

http://support.microsoft.com/kb/3019983

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.

Categories: Lync Tags:

Lync Invoke-CsBackupServiceSync and No Central Management Services

September 9, 2014 Leave a comment

Working with larger Lync deployments, I have run into this a few times where we need to force the Backup Service using Invoke-CsBackupServiceSync and we get the message “No Central Management services were found for the pool you specified to backup.”

NoCentralMgmt

The first time I saw it, it made me pause but I noticed something, it wasn’t an error. Errors always display in red. I went back to Technet and read about the cmdlet.

By default, the Invoke-CsBackupServiceSync command will attempt to synchronize three types of data:

  • UserServices.PresenceFocus
  • ConfServices.DataConf
  • CentralMgmt.CMSMaster

The issue comes up when you run Invoke-CsBackupServiceSync against a pool that is not hosting the CMS. The default attempts to synchronize CentralMgmt.CMSMaster.

If you don’t want to see the extra message telling you there is no CMS in the pool you are running against, then you can run Invoke-CsBackupServiceSync with the “-BackupModule” option and specify only the UserServices.PresenceFocus and ConfServices.DataConf. Otherwise, you can know that this message is normal and you can keep on with your tasks.

Categories: Lync

High CPU after Publishing Lync Topology

August 26, 2014 7 comments

I have now experienced this issue at two different clients so I thought I would share how we are handling it in case others are experiencing it.

Background: After you publish a Lync topology where you add and/or delete and object, you see the CPU utilization spike to 100% across all of your front-ends.

This issue has been around awhile. Ken Lasko talked about it on his blog (http://ucken.blogspot.com/2014/01/high-processor-utilization-on-lync-2013.html) back in January of 2014. He had suggested simply restarting the AppPool’s on the CMS servers.

Recently, a co-worker and I decided to attempt Ken’s script but we found that it wasn’t helping us. Simply restarting the AppPool’s on the CMS servers wasn’t enough to bring down the CPU utilization on the other front-ends (we currently have 4 pools with 2 more on the way). Due to the number of Front-ends (12 currently), we really didn’t want to RDP into each of them so we utilized a script I had written to perform the IISRESET.  It goes out and finds all of the Lync Front-ends and then will perform the IISRESET.

NOTE: You must have remote management enabled for this script to work. Windows 2008 R2 does not have it enabled by default.

Here is the script:

<#
    Written by: Adam Ball
    Description: Looks up all the Front-ends in the Lync Topology and performs an IISRESET on them.
    Version 1.0
.#>
 
#Get all of the Pools with Web Servers in the environment
$pools = Get-CsService -WebServer | select PoolFqdn
 
#Get all computers from the pools running Web Services
$computers = @()
foreach ($i in $pools ){
    $computers += ( Get-CsPool $i .poolfqdn) . computers
    }
Write “IISReset will be performed on “ + $computers
 
#Reset IIS on all Web Servers
foreach ($i in $computers ){
    Write “Performing IISReset on “ + $i
    Invoke-Command -ComputerName $i -ScriptBlock {iisreset }
    } 
Categories: Lync

Lync and Site specific Simple URL’s

June 10, 2014 1 comment

We recently had a requirement when deploying a new Lync 2013 pool to give a Site/Region their own Simple URL’s. I knew this could be done and it’s always easier when doing it during the deployment but this was the first time I had ever had to do it when the site had been running for awhile on Lync 2010 and using the Global Simple URL’s.

Our requirement was to go from using the Global Simple URL (meet.company.com) to a Regional based one of meet-emea.company.com.

I went and double-checked Technet (as everyone should do) and also referenced an article by Justin Morris from awhile back that was specific to configuring site level Simple URL’s.

All of the info is great but it was lacking one thing, how to make sure that the old Simple URL would still work after we made the change. We did not want to have to have a flash cut where everyone had to go update their recurring meetings and the like.

In the Technet article for creating the new Simple URL is this tidbit:

SimpleUrlEntry Optional Collection of URLs for the specified component. For example, both https://meet.litwareinc.com and https://litwareinc.com/meet might be configured as URL entries for the Meet component. However, only one of those URLs can be (and must be) configured as the active URL.

Simple URL entries must be created by using the New-CsSimpleUrlEntry cmdlet.

It specifically states that you can define a “Collection of URLs for the specified component”. That’s the ticket! However, the Technet example didn’t show how to add multiple URLs. Here is what I found worked:

$urlEntry= New-CsSimpleUrlEntry -url "https://meet-emea.company.com"

$urlEntry1 = New-CsSimpleUrlEntry -url "https://meet.company.com"

$urlEntry2 = New-CsSimpleUrlEntry -url "https://dialin-emea.company.com

$simpleURLMeet = New-CsSimpleUrl -Component meet -domain company.com -ActiveUrl "https://meet-emea.company.com" -simpleurl $urlEntry,$urlEntry1

$simpleURLDialin = New-CsSimpleUrl -Component dialin -domain * -ActiveUrl "https://dialin-emea.company.com" -simpleurl $urlEntry2

Set-CsSimpleUrlConfiguration -Identity "site:MySite" -SimpleUrl @{Add=$simpleURLMeet,$simpleURLDialin}

After we had done all of this, we went and tested and everything appeared to work fine. We shall see if there are any issues from a users stand point that we we were unable to replicate using our test accounts.

Categories: Lync Tags:

Lync 2013 Trunks and EnableFastFailover

June 3, 2014 5 comments

This post was inspired by a troubleshooting session that happened just before the long Memorial Day Weekend here in the states. We had just moved our pilot users over to our Lync 2013 pool a day before when they started reporting issues calling certain numbers. What was interesting was not all calls were failing. Only international calls and a few mobiles were failing. National calls were working fine. Nothing changed call flow-wise so it had me a bit stumped.

To properly set the background, our calls were going from Lync to a Cisco voice gateway and then out an E1 to the carrier.  We tested a call from Lync 2010 and the call would succeed:

2010_Successful_Call

You can see at about 14 seconds into the call we get back our first 200 Ok. Next, here is a call from Lync 2013. User has all of the same voice policies, dial plan, routes, etc.

2013_Failed_Call

We dug our heels in and got the Cisco guy on the line and he watched what was being sent to the carrier and he didn’t see anything wrong but kept seeing Lync send a Cancel so the call would fail. What you don’t see in the above image is that we would start trying to hit the backup voice gateway which only becomes active if the first doesn’t work.

Well, it took longer than I would like to admit before we all noticed the call was failing at exactly 10 seconds everytime. Consistency like this is never coincidence. I started looking at the trunk configuration settings in Lync 2013 and lo and behold, I found this:

EnableFastFailoverTimer Optional Boolean When set to True, outbound calls that are not answered by the gateway within 10 seconds will be routed to the next available trunk; if there are no additional trunks then the call will automatically be dropped. In an organization with slow networks and gateway responses, that could potentially result in calls being dropped unnecessarily.

The default value is True.

We set the EnableFastFailoverTimer to False and our calls started to go through. It appears that this particular carrier was just taking a long time to setup International calls along with certain mobiles.

So, how did we set it? We used:

Set-CsTrunkConfiguration -Identity "our site specific trunk" -EnableFastFailoverTimer $false"

We could have also done it via the Lync Management Console by unchecking Enable outbound routing failover timer check box in the Trunk Configuration:

FastFailoverTimer

 

 

Categories: Lync Tags:

Reflections on Best of #Lync Conf Denver #COUCUG

April 25, 2014 Leave a comment

Yesterday, (April 24th), was the Best of Lync Conference Denver. As a leader of the Colorado Unified Communications User Group, I was involved in the planning, setup and execution of putting this event on. I wanted to take a moment to reflect on what we accomplished.

First, we had a goal of 40 attendees. We ended up with 48 or 49 plus the sponsors and leaders of the user group for a grand total of 58. We did this with about a months worth of planning and invitations. Based on the amount of effort that was put into just this, I have to say my admiration and and respect (which was already pretty big) for Jamie Start (@nomorephones) and his team has been exponentially magnified. I have no idea how they have pulled off the real LyncConf the past two years without going absolutely crazy. Seriously, that team must be amazing.

Second, we had a pretty major curve thrown at us in that we had to share the Microsoft Offices with the “Microsoft Day of Unity” folks. This means we had approximately another 60 people in the office sharing the already constrained Internet connection (I’ll get to why this is important in a minute). We had to coordinate different food stations and be good neighbors as our rooms were right next to each other.

Since we only ended up with one room that could hold more than 10-12 people, we made a last minute decision to trim some sessions down and deliver everything from the one room instead of breaking things up and having both a business and technical track. This proved to be a wise-decision because everyone was able to get info from all of the sessions.

Remember that whole having to share the Internet thing? Well, we were fortunate enough to be able to have Jeff Schertz (@jdscher) speak to us. He delivered his “Video – What are you doing on my network?” presentation that he gave at the LyncConf. We brought him in via a Lync meeting and used a Polycom LRS unit. The LRS was on the same network as 100+ other people doing nothing but best effort. Our voice quality with him was fantastic! Yes, video was choppy but we were able to hear him and see his presentation the entire time. Huge win and a great job by Jeff. I can’t say how much I appreciated him being able to speak to us. His community focus is awesome.

We had three sponsors (outside of Microsoft). Jabra (@We_are_Jabra), AudioCodes (@audiocodes) and Clarity Consulting (@claritycon) helped us out. Clarity and AudioCodes sponsored the breakfast and lunch meals and then Jabra gave away 4 devices. The help from Claire, Lindsey, and Rose was tremendous. They helped direct people and answer questions. I truly hope people were able to talk with them and see how each of them could help with a company’s UC rollout.

Lastly, I can’t say enough about the team that contributed to the success of the event. We had help from so many places. I really hope everyone who attended got a lot out of the event. I think we had some fantastic content and some outstanding presenters. I’m excited to be entering year 4 of the user group here in May and can’t wait to see what the future holds.

Thank you!

Categories: Lync Tags: