Speeding up Invoke-CsComputerFailover

As of Skype for Business server 2015 there is a new cmdlet for the update process if you are running a 3+ server pool, named Invoke-CsComputerFailover, which differs from previous versions. This cmdlet makes sure all services are drained before they are stopped, much like the older cmdlet Stop-CsWindowsService -Graceful. But where the Stop-cmdlet actually would time out if a service would’t drain, say an ongoing conference was hosted on the server, the new cmdlet will keep on forever (or at least an hour, by default).

But what if you are on a clock, maybe a maintenance window closing in?

Before you continue reading I must emphasize that this is by no means something validated or supported by Microsoft, but I have never experienced any problems with it myself.

Updates for S4B server come through the Windows Update service or as a standalone executable (SkypeServerUpdaterInstaller.exe). I prefer the latter because some updates that are listed as optional under Windows Updates may break  your S4B server environment if they are not installed (see an example of such).

Before running the updates you need to remove the server from being an active part of your Enterprise pool. If you have a pool of 3 or more servers the cmdlet is
Invoke-CsComputerFailover

When you run this cmdlet you will experience that it might run forever before completed. That’s probably why you have the -WaitTime parameter to say how long you accept waiting before the cmdlet terminate.

During the wait time, open a separate Management Shell window or run the following cmdlet from another server in the pool with the -ComputerName parameter.

PS C:\Users\skypeadmin> Get-CsWindowsService

Status   Name            ActivityLevel
——   —-            ————-
Running  RTCSRV          Incoming Requests per Second=0,Messages in Server=0…
Running  RTCCAA          Concurrent Calls=0
Running  RTCCAS          Concurrent Conferences=0
Running  RTCRGS          Current Active Calls=0
Running  RTCPDPCORE      Active Client Connections=0,Active Edge Connections=0
Running  RTCCPS          Total Parked Calls=0
Running  RTCATS          Current Active Calls=0
Running  RTCIMMCU        Active Conferences=1,Connected Users=0
Running  RTCDATAMCU      Active Conferences=0
Running  RTCAVMCU        Number of Conferences=0,Number of Users=0
Running  RTCASMCU        Active Conferences=1,Connected Users=0
Running  RTCMEDSRV       Current Outbound Calls=0,Current Inbound Calls=0,Cu…
(output abbreviated for simplicity)

You will notice that it may be “empty instances” of a conference that is delaying the cmdlet from finishing. If you, like me, do not have the patience to wait for this to complete then simply run the Stop-CsWindowsService cmdlet (make sure to use the -ComputerName parameter if you do it from another computer in the pool!).

By now your initial cmdlet will have finished it’s work and you can go about your update process.

After you are done updating (and perhaps rebooting) make sure to run the Invoke-CsComputerFailback cmdlet to put the server back in active duty.

I always run the Get-CsPoolFabricState cmdlet afterwards to make sure all services have their primary and replicas in place, especially if I am about to go on updating another server in the pool. Often there will be “missing” replicas, but these are fixed (or replicated, so to speak) by Windows Fabric automatically after some minutes. I have seen this both after letting the cmdlet finish “gracefully” or when forcing it, so I don’t really think it is related to the forceful Stop-cmdlet. Anyway, I always make sure there are no warnings before moving on.

Advertisement