Following on from my previous post, performing an In Place upgrade, I thought I would put together an overview of the simplified pool update process.

The Skype for Business Server management experience has introduced some very useful commands and processes. Firstly, the In-Place upgrade process itself, which introduced you to the Smart Setup and the Start-CsPool command, all which on their own reduce the operational loads significantly!

In this post, I will walk you through the simplified process of performing maintenance on your Skype for Business Enterprise Edition Front End Servers.

Now to summarise the overall process, I will let these two images do all the talking, on the left is the Lync Server 2013 Patching Process, on the right the same for Skype for Business Server 2015

So pictures are all good and well, but what does the process actually look like?

Now at the moment, the RTM components have not had any Windows Updates released for them, so I will simulate the patching process and update this post as the first set of updates are released. Processes such as back end database updates will be included as soon as they are applicable.

I am going to be working with a Skype for Business Server 2015 Enterprise Edition Pool, containing three front end servers:

• Fe01.uccorey.local
• Fe02.uccorey.local
• Fe03.uccorey.local

The following steps will be performed on FE01.uccorey.local, once maintenance is complete on your first server and the pool is fully operational, the steps should be repeated for the remaining servers within your pool.

1. Run the Skype for Business Management Shell, running this with Administrator Privileges
   1. If you haven’t already done so, you may wish to Pin to Taskbar for ease of access

1. From the Management Shell, run the following command:

   Get-CsPoolFabricState –PoolFQDN <PoolFQDN>
   

    

2. The following output was returned when I entered the cmdlet against my pool (I have formatted it slightly to make it easier to read)

PS C:\Users\administrator.UCCOREY> Get-CsPoolFabricState -PoolFqdn uccorey.co.uk

Replica Instances for MCUFactory Service

Address: FE01.UCCOREY.LOCAL – Primary: 2 Secondary: 4

Address: FE02.UCCOREY.LOCAL – Primary: 2 Secondary: 4

Address: FE03.UCCOREY.LOCAL – Primary: 2 Secondary: 4

Local MCUFactory Service:

Missing Primary : 0

Missing Both Secondary : 0

Missing One Secondary : 0

No Missing Replicas : 6

Total Count : 6

Pool MCUFactory Server and Services Summary:

Fqdn: FE01.UCCOREY.LOCAL Primary: 2 Secondary: 4

Fqdn: FE02.UCCOREY.LOCAL Primary: 2 Secondary: 4

Fqdn: FE03.UCCOREY.LOCAL Primary: 2 Secondary: 4

Replica Instances for ConferenceDirectory Service

Address: FE01.UCCOREY.LOCAL – Primary: 0 Secondary: 1

Address: FE02.UCCOREY.LOCAL – Primary: 0 Secondary: 1

Address: FE03.UCCOREY.LOCAL – Primary: 1 Secondary: 0

Local ConferenceDirectory Service:

Missing Primary : 0

Missing Both Secondary : 0

Missing One Secondary : 0

No Missing Replicas : 1

Total Count : 1

Pool ConferenceDirectory Server and Services Summary:

Fqdn: FE01.UCCOREY.LOCAL Primary: 0 Secondary: 1

Fqdn: FE02.UCCOREY.LOCAL Primary: 0 Secondary: 1

Fqdn: FE03.UCCOREY.LOCAL Primary: 1 Secondary: 0

Replica Instances for Routing Service

Address: FE01.UCCOREY.LOCAL – Primary: 1 Secondary: 1

Address: FE02.UCCOREY.LOCAL – Primary: 0 Secondary: 2

Address: FE03.UCCOREY.LOCAL – Primary: 1 Secondary: 1

Local Routing Service:

Missing Primary : 0

Missing Both Secondary : 0

Missing One Secondary : 0

No Missing Replicas : 2

Total Count : 2

Pool Routing Server and Services Summary:

Fqdn: FE01.UCCOREY.LOCAL Primary: 1 Secondary: 1

Fqdn: FE02.UCCOREY.LOCAL Primary: 0 Secondary: 2

Fqdn: FE03.UCCOREY.LOCAL Primary: 1 Secondary: 1

Replica Instances for LYSS Service

Address: FE01.UCCOREY.LOCAL – Primary: 1 Secondary: 1

Address: FE02.UCCOREY.LOCAL – Primary: 0 Secondary: 2

Address: FE03.UCCOREY.LOCAL – Primary: 1 Secondary: 1

Local LYSS Service:

Missing Primary : 0

Missing Both Secondary : 0

Missing One Secondary : 0

No Missing Replicas : 2

Total Count : 2

Pool LYSS Server and Services Summary:

Fqdn: FE01.UCCOREY.LOCAL Primary: 1 Secondary: 1

Fqdn: FE02.UCCOREY.LOCAL Primary: 0 Secondary: 2

Fqdn: FE03.UCCOREY.LOCAL Primary: 1 Secondary: 1

Replica Instances for Fabric Service

Address: FE01.UCCOREY.LOCAL – Primary: 1 Secondary: 2

Address: FE02.UCCOREY.LOCAL – Primary: 0 Secondary: 3

Address: FE03.UCCOREY.LOCAL – Primary: 2 Secondary: 1

Local Fabric Service:

Missing Primary : 0

Missing Both Secondary : 0

Missing One Secondary : 0

No Missing Replicas : 3

Total Count : 3

Pool Fabric Server and Services Summary:

Fqdn: FE01.UCCOREY.LOCAL – Health: Ok Status: Up [Seed Node] Primary: 1 Secondary: 2

Fqdn: FE02.UCCOREY.LOCAL – Health: Ok Status: Up [Seed Node] Primary: 0 Secondary: 3

Fqdn: FE03.UCCOREY.LOCAL – Health: Ok Status: Up [Seed Node] Primary: 2 Secondary: 1

Pool All Server and Services Summary:

Fqdn: FE01.UCCOREY.LOCAL Primary: 4 Secondary: 7

Fqdn: FE02.UCCOREY.LOCAL Primary: 2 Secondary: 9

Fqdn: FE03.UCCOREY.LOCAL Primary: 5 Secondary: 6

Windows Fabric is a topic in itself and there is a lot of information being returned to us above. In a (very high level) summary, the fabric is responsible for replica instances of the services referred to above, those are;

• MCUFactory
• ConferenceDirectory
• RoutingService
• LYSS Service

The final Section, which I will call out again is the main area of concern which essentially summaries the above four services;

Pool Fabric Server and Services Summary:

Fqdn: FE01.UCCOREY.LOCAL – Health: Ok Status: Up [Seed Node] Primary: 1 Secondary: 2

Fqdn: FE02.UCCOREY.LOCAL – Health: Ok Status: Up [Seed Node] Primary: 0 Secondary: 3

Fqdn: FE03.UCCOREY.LOCAL – Health: Ok Status: Up [Seed Node] Primary: 2 Secondary: 1

As we can see, all three of my front end servers reporting as Health: Ok Status: Up so for me, I am now ready to move ahead.

If any of my servers were not up to date the suggested command is;

Reset-CsPoolRegistrarState -ResetType QuorumLossRecovery

This command will attempt to reload User Data from the backup store for any of the routing groups that are currently in a state of quorum loss. If any data is not written back to the databases, it could be lost when performing this type of reset

So back to the management shell on FE01.uccorey.local, I am ready to move on to the next step;

1. Invoke-CsComputerFailover –NoStop –ComputerName FE01.UCCOREY.local

Once completed, if you run the Get-CsWindowsService command, you will see the services are still running;

But if you run the Get-CsPoolFabricState command again, you will see we now have one disabled front end and all replica instances are now being serviced by my remaining front end nodes

So at this stage now, I am ready to complete my maintenance work on my Front End Server.

At the time of writing, there are no updates outstanding on my server so let’s assume I’ve upgraded to 64TB of RAM, 8x SSDs and quantum computing capable processors…..

So maintenance is now complete and I am ready to bring my FE01 back into service, to do this I will enter the following command;

Invoke-CsComputerFailBack –ComputerName FE01.uccorey.local

So intentionally being impatient, I wanted to show you an example message to expect when replica instances are not distributed correctly, as seen below FE01 does not currently have a replica instance for the Lync Storage Service;

Actually allowing the system time to bring itself up to a stable state (use v3 fabric!!!) results in the following;

So at this stage now, you are ready to complete the previous process on the next server within your pool.

The overall process time is significant reduced, the ability to simply take the FE out of service with one command is pretty epic J

As the first set of updates are released, keep an eye out for updates to this article to cover actually applying Skype4B Server updates as well as the associated back end database updates.

Hope this post helps you maintaining you environment!