Home > Lync > High CPU after Publishing Lync Topology

High CPU after Publishing Lync Topology

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
  1. soder
    August 26, 2014 at 9:53 am

    Did you open a ticket @ MS ? If they dont get bashed by all their possible Lync customers continuously, they never gonna fix this bug proactively.

    • August 26, 2014 at 9:58 am

      Yep, my clients have opened tickets on this issue. Also have communicated it back up via other channels as well.

  2. August 26, 2014 at 11:34 am

    We’ve had a ticket open since about January and have been working closely with Microsoft on this. We’ve provided captures and installed trial code for them, etc. It’s clearly not a trivial fix.

  3. Mike
    September 26, 2014 at 4:07 am

    Hi, just to add to this we have 16 Front Ends most of which are virtual. The two physical servers we have never exhibit the problem and one of the virtual servers also has never had the issue either – can’t figure out what is different about it!

  4. Nick
    September 29, 2014 at 11:08 pm

    We’ve had a ticket on this with MS since Halloween last year, and was escalated to the product group. We’ve offered up our production environment to as much scrutiny as they want in order to see if we could pin the problem down. Recently though we finally decommissioned the last of the 2010 components in one of our Central Sites, and since that point, the 2013 FEs in there don’t lock up anymore. We think that might have something to do with it, but it’ll be a few more weeks before we can get the last of the 2010 servers out of another Central site, and we’ll see if those 2013 FEs stop locking up as well…

  5. October 2, 2015 at 1:51 am
  1. September 25, 2014 at 8:09 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: