Skype for Business: Cleanly Shutting Down Server (Invoke-CSComputerFailover and More)

It’s been over three years since I managed and deployed a Skype for Business/Lync system, and at my new job I was hired on as a be a network engineer, but I noted in a past life I received a MCSE in Skype for Business, so I could definitely be the backup for the primary SME (subject matter expert) in SfB. However, in a strange twist, the primary SME left — and you know what, there’s just not a lot of Skype for Business/Lync engineers out there, especially in a small labor market, so I stepped up to help the organization because I was the most qualified by a long-shot.

So I’m back doing some Skype for Business again.

Captain America Here We Go Again

I actually have always liked voice routing, so it’s fun to be doing some of this stuff again (although SfB is a pretty intense, integrative technology, so it’s not all Pop-Tarts and unicorns).

However, I was trying to get reacquainted with some commands for cleanly shutting down a Skype For Business server, and I just didn’t find a lot of good information out there, so I thought I might write something up “real quick”. This is somewhat basic info for SfB enterprise deployments, but it might be helpful.

Enough of the pretext, let’s get to the first command…


I’m starting with this command because it’s the most basic command you should already know, but plays a role for later in this post. Typically you’ll use the command to see how many connections are being used by a service, if a service is running, etc.

The command is straightforward: Get all or one of the SfB (or Communication Server, which is where the acronym CS comes from) Windows Services on the machine.


The command `Stop-CSWindowsService` is the most basic command you’ll use to stop all or one of the services on a SfB server. The command will execute stopping of services in the proper order of stopping SfB services, including any dependent services.

Typically you’ll be using this command on a ‘Standard’ deployment SfB server, or any non-front end server in an ‘Enterprise’ deployment such as mediation/edge servers (more info: standard vs enterprise deployment). However, there are probably rare situations in which you’ll stop just one service, so you’ll likely be stopping all of them.

If you’re doing this outside a maintenance window for some reason, I prefer to do the following: Stop-CSWindowsService -Graceful. The -Graceful is important here, because what it does is it puts the services into a paused state, preventing any new connections from happening and waiting on existing connections to disconnect. On mediation servers, whenever I’ve need to stop a server in a mediation pool, this is my preferred method so that I wait for the calls to end. However, it won’t stop until the call is done, so you might be waiting awhile.


For whatever reason, this command scared me at first, largely because of my ignorance of what it does. The official documentation on the command I don’t think does it justice, so here’s my attempt at it.

The command `Invoke-CSComputerFailover` will basically perform a Stop-CSWindowsService -Graceful operation, but it acts slightly different. The differences:

  1. It’s used on front end servers in an enterprise deployment (or at least I’ve never seen it documented or used on other SfB server pools). The command causes the front end server to be in a ‘failover’ state, making it unavailable to the rest of the front end pool.
  2. The command migrates data, routing groups, and more to the other front end servers.
  3. The command has a wait time of 1 hour per service, after which if the connections haven’t disconnected, it will force a disconnect. This default can be changed with the `-WaitTime` parameter.
  4. This command will make the server unavailable in the front end pool. After a reboot, or if for some reason you run Start-CSWindowsService, the server won’t be available until you run Invoke-CSComputerFailBack.

After working with it and using it several times, it’s not as scary as I thought. Just run it on one machine at a time lest you have some Windows Fabric issue due to quorum loss (or something to that effect).

Invoke-CSComputerFailover Hanging or Taking Awhile

Sometimes when you’re failing over a front end server, you get stuck waiting for some services to stop like this:

Status screen waiting for Invoke-CSComputerFailover to Progress

If you look at `Get-CSWindowsService`, you might actually find something like this:

Get-CSWindowsService Seeing Services With Hanging Connections

If you note the red and blue arrows, the services are left open, likely from a conference that has ended already, but is being left open for whatever reason. To speed up Invoke-CSComputerFailover, just open a separate elevated terminal and stop the services like this:

Stopping the stalled services with Stop-CSWindowsService in separate window

After which, `Invoke-CSComputerFailover` will continue on as expected.

Invoke-CSComputerFailover progressing

I originally tried out the idea on my own, but the following blog entry also helped me and explains it from a different perspective.

Skype for Business/Lync Server and Exchange UM: Errors with Event IDs 1079 & 1136

During a recent Skype for Business-Exchange 2013 deployment, I tried running all calls to a DID, then to an Exchange 2013 UM Auto Attendant. After some hiccups I had it working, but painfully, dialing by extension and transfers did not work from the Auto Attendant. After doing some investigating, the Skype server wasn’t giving me an errors, and my syslog from the Audiocodes gateway was indicating calls were transferring.

However, the Exchange server gave me two errors regarding unified messaging: 1079 and 1136.





I tried lots of solutions, tested my environment numerous times, but nothing was working. If you look these errors up when doing a Skype for Business server deployment, you’ll often see Microsoft KB 3069206 come titled, “Exchange UM Auto Attendant cannot transfer calls to a phone or extension number in Skype for Business Server 2015“. Looks great and promising…

…but I’ve already updated the server to the latest CU.

With more Google-fu, I found my solution: I needed to change my certificate for the Exchange server.

According to this TechNet thread, the certificate assigned to the UM services on the Exchange server needs to have it’s subject name be the same as the Exchange UM server’s name. I had used the same UCC-SAN cert for UM services that I set up for the Skype for Business Edge server, and added all the subject alternative names needed.

The fix: perform a new certificate request from the internal CA, apply the certificate to the UM services, then restart the UM services on the Exchange server..

After that, call transfers worked!

Hope this helps someone.


Skype for Business: “Prerequisite installation failed: MSSpeech_TTS_pt-BR_Heloisa”

While doing a Skype for Business deployment, I encountered this strange error that was preventing the S4B server components from installing: “Prerequisite installation failed: MSSpeech_TTS_pt-BR_Heloisa”.

The log file showed the following:


After doing some Googling, the consensus was to find the MSI file and replace it.

The file was located here: C:\ProgramData\Microsoft\Skype for Business Server\Deployment\cache\6.0.9319.0\setup\speech\pt-BR\

However, the question was where to get the speech files. I tried getting them from the ISO, but it appeared the files on the ISO were corrupted, so I had to get the files here:

Microsoft Speech Platform – Server Runtime Languages (Version 10.1)

I ended downloading what I needed, but subsequent MSI files were also having problems, so I ended up just replacing MSIs in the the directories “pt-BR” through “zh-TW” just to be safe.

The installation then continued successfully as expected.

Hope this helps someone.

Update (06/07/16): Had this problem again (forgot to replace ISO), and I found out that if you keep the S4B ISO mounted or DVD in the system, then S4B will re-download the bad packages from the ISO/DVD. Dismount or eject the media, then copy the MSI files.

Update 2 (09/20/16): You can also just re-download the ISO. Problem solved. 😀

How to Change Avatar in Lync 2013 with Exchange 2010

In the Lync 2010 world, everything was golden. Lync was pretty cool, and it integrated well with Exchange 2010. Then our senior admin upgraded the network to Lync 2013, and things changed.

Not a whole lot changed, but one thing changed that I kind of enjoyed doing: changing my avatar.

My glorious avatar!

The problem is that in Lync 2013, in order for users to change their pictures, the Exchange environment needs to be 2013, otherwise, users will end up with something like this:

Notice the 'Edit or Remove Picture' is greyed out.
Notice the ‘Edit or Remove Picture’ is greyed out.

After doing a bit of reading, it turns out you can still have pictures, but the administrator needs to upload the pictures and/or somehow pictures need to uploaded into Active Directory.

So what I did — others more well versed may come up with a different solution — is I created my image, saved it into a network share on the Exchange server, and then ran this command in an elevated prompt in the Exchange shell:

Import-RecipientDataProperty -Identity [email protected] -Picture -FileData ([Byte[]]$(Get-Content -Path "\\exchangeserver\photos\jimmyLync.jpg" -Encoding Byte -ReadCount 0))

Of course, with the appropriate changes to our environment.

Then I hopped over to the Lync server and in an elevated Lync shell, I ran




I don’t remember where I read those commands, but I did it because I read that Lync updates those items once every 24 hours, so I figured why not force it like doing a group policy refresh.

I did notice that the changes were being made to Exchange because Outlook changed my picture, but what gives with Lync? No answer was being found online, and I even removed the local Lync cache and still no luck.

Then I decided to try hiding my picture, clicking ok, then showing again (like in the image above). It appeared!

The only thing I can think is that was causing it not to work was that the cache wasn’t refreshing on the Lync server, so hiding and showing the image again somehow refreshes it.

Maybe. In any case, at least I can contribute this solution to the web.

TechNet Articles: