High CPU after Publishing Lync Topology

August 26, 2014 3 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

August 28th COUCUG Meeting

August 12, 2014 Leave a comment

The August meeting is just over two weeks away! Come hear about Attendant Pro from Landis Computer and enter to win a Plantronics headset.

We’ll be kicking things off at 4pm and we’ll go til 6pm. Food and drink is being supplied by Matt Landis and Landis Computer.

You can RSVP and get more details at http://www.coucug.org. We hope to see you there!

Categories: Uncategorized

My thoughts on the Microsoft Unified Technology Event

July 22, 2014 Leave a comment

Yesterday, Microsoft announced that they are not doing the smaller, product centric events like Microsoft Exchange Conference (MEC) or LyncConf. They are switching to a Unified Technology Event which will be next May in Chicago. You can read the announcement here: http://blogs.office.com/2014/07/21/microsofts-unified-technology-event-for-enterprises/.

This news isn’t all that surprising, combining efforts has to be a great way to save money and more efficient from a planning standpoint.

I have to admit, I’m sad to see LyncConf go. I went to both years of it and thought it was fantastic. I hope the new event is as good and not just a re-invention of TechEd. A few reasons that I am disappointed the smaller conferences are going away:

First, when you went to the product specific conference, you had a common bond with everyone there from the get-go. You didn’t have to find out what they were there for, they were there for the same product you were.

Second, because the conference was smaller, you didn’t feel like such a small part in it. It’s easy to let yourself get lost in a large conference and not engage with other folks.

Third, the networking was awesome. The conference was small and intimate and it made it very easy to identify people you wanted to meet. A larger conference tends to drive people to cliques and can make it much more difficult to connect with others.

Things aren’t all bad though. Having several products at one conference is great for a general sysadmin who has to work with Lync, Exchange and Office365 everyday. That person might only have the ability to go to one conference and now can do so (just like before with TechEd). I view this more as a negative due to the fact that I am more specialized and I could have used an extra day at LyncConf to begin with, add-in interesting content from Exchange or O365 and I may have even more tough choices in which sessions to attend.

Also, as someone who works for a consulting firm, it will be tougher for us to send folks. With the separate conferences we could send two people to each and not take such a hit from them being gone. With the Unified event, we will probably only be able to send a small selection and then the rest miss out on the experience.

I hope Microsoft does a great job with the event and makes us all forget about the small, intimate conferences but at the end of the day, I feel like this just like your favorite band. It’s great to see them either way but the small club was a much better experience than the large arena.

Categories: Uncategorized

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 3 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:


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.


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:




Categories: Lync Tags:

Jabra Motion UC Battery Life Report

May 22, 2014 Leave a comment

Awhile back I was given a Jabra Motion UC headset to test and work with to review. You can read my initial thoughts here: http://phyler.wordpress.com/2014/02/05/jabra-motion-uc-initial-thoughts/

After using this now for a few months, I thought I would report on the battery life. Jabra released an update in mid-April that extends the battery life to 8 hours but I wasn’t seeing anywhere close to that so I contacted their support and we worked through it and found a few things.

I spend a majority of my day on the phone with clients. One day, I realized that the headset went dead after about 3.5 hours of talk time. After conversing with support, we tried turning off the Busy light on the headset. I continued to test and found very little impact.

It was when I was modifying the Busy light settings, that I noticed I could control the range of the headset. For those who didn’t read my initial post, the Motion UC has a range of 300ft. It’s incredible. I can walk anywhere in my home and leave my laptop in the basement and carry on a call. You can see the defaults for the headset in the Jabra Control Center.


I moved the slider from Normal to Low to see how it would impact range and battery life. What I found was that the range dropped pretty significantly (less than 60 feet) but the battery life was extended significantly. I was able to go almost all day with about 5-6 hours of talk time and 2 hours of standby time (just sat it on the desk off the charger). I believe that if I were to drop the range down to Very Low, I would get standard Bluetooth range (~30 feet) and the full 8 hours of talk time.

This all stated, I did bump it back to Normal now that I know as I really valued the ability to be on a call and head up stairs for a coffee refill while on mute. I’ve just learned that if I’m not on a call, the headset needs to be charging.

Categories: Uncategorized

May COUCUG Meeting

May 15, 2014 Leave a comment

The May meeting for the Colorado UC User Group is just around the corner on the 29th from 4-6pm. Come listen to Exchange MVP Jason Sherry (@jasonsherry) speak about Exchange Cross-forest migrations.

You can get more details and RSVP at http://www.coucug.org.

Categories: Uncategorized

Get every new post delivered to your Inbox.

Join 160 other followers