Cluster Rolling Upgrade from Windows Server 2012 R2 to Windows Server 2016

Posted by Boris Yurchenko on January 11, 2018
Share on Facebook0Share on Google+0Share on LinkedIn0Share on Reddit12Tweet about this on Twitter0
5/5 (1)

During its lifetime, any system reaches a point when it needs to be upgraded, either in terms of hardware or software. Today, I will talk about such changes, in particular, about upgrading Windows Failover Cluster nodes from Windows Server 2012 R2 to Windows Server 2016 with no production interruption. Thanks to Microsoft, we do have a Cluster Rolling Upgrade procedure at our fingertips, and I am going to get through it and confirm it works for virtualized disks as cluster shared volumes in Windows Failover Cluster. This procedure assumes rebuilding nodes with clean OS deployment one by one, while the production keeps running from the other cluster node.

To begin with, I have a 2-node Windows Failover Cluster with Windows Server 2012 R2 installed on the nodes. The cluster has got 2 CSVs along with the Quorum. The whole system is configured in a hyperconverged scenario.

Before making any further steps in terms of Cluster Rolling Upgrade, taking into account that in my case the cluster storage is provisioned by StarWind VSAN, I would like to mention that step #0 is checking that all disks are synchronized on all nodes. Without making sure that they are, the below actions can endanger the stability of the production environment.

After having checked the StarWind devices synchronization status, I proceed with the upgrade starting from node 1 with the following steps:

1. Drain roles from node 1 inside the Failover Cluster Manager.

Draining roles from a Windows Failover Cluster node

2. Evict node 1 from the cluster.

Evicting a Windows Failover Cluster node from cluster

3. Stop the StarWind VSAN service on node 1.

4. Back up the StarWind configuration file StarWind.cfg on node 1 (the default location: “C:\Program Files\StarWind Software\StarWind\StarWind.cfg”) to restore StarWind setup with less effort after OS reinstallation.

Default location of StarWind.cfg file

Note: Make sure that there are no StarWind devices located on the OS partition. Do not format partitions where StarWind devices are located.

5. Make a clean install of Windows Server 2016 on the system partition of node 1. Supply it with all required roles and features like Hyper-V, Multipath I/O, and Failover Clustering as well as correct network settings that have been previously used on Windows Server 2012 R2 on this node. For the guidance on how to configure this, refer to the configuration guide.

Minimum set of roles and features required for a Windows Failover Cluster node using StarWind VSAN as storage provider

6. Install StarWind VSAN. The above guide offers instructions on that as well. To keep the previous configuration consistency, make sure you install the same build of StarWind VSAN as used before.

7. Stop the StarWind VSAN service on node 1.

8. Swap the existing StarWind.cfg file with the one you have previously backed up from node 1.

9. Start the StarWind VSAN service and check whether all devices appear in the StarWind Management Console on node 1, and confirm there are no non-active devices on it. In my case, at this step, I had the fast sync process automatically initiated from node 2 to node 1.

StarWind Management Console with all HA devices synchronized

Note: If you do not have a valid backup for the StarWind.cfg file, just go to node 2 and recreate replicas to node 1 for all StarWind devices in the Replication Manager. To access it, right-click on each device and select the Replication Manager in the menu. After this is done, wait for the process of full synchronization to complete.

10. Connect targets in Microsoft iSCSI initiator on node 1 after the synchronization process is over. You can find the guidance on configuring iSCSI connections in the document mentioned in step 5.

11. In Disk Management, bring all StarWind-related disks online. They will show up as RAW but do not worry, as this is caused by the fact that they are clustered already.

StarWind disks in Disk Management snap-in before the node is joined back to the Windows Failover Cluster 12. On node 1 (important!), open Failover Cluster Manager, connect to your cluster and add node 1 to it. Do not try to perform this from node 2, which still runs on Windows Server 2012 R2, as the Failover Cluster Manager console will most likely keep failing when connecting to the hybrid-mode cluster (with node 1 on Windows 2016 and node 2 on Windows 2012 R2).

Joining a node to a Windows Failover Cluster

13. Perform steps 1-12 for node 2. Keep in mind step 0 😊

14. Once all cluster nodes are upgraded to Windows Server 2016, follow the Microsoft’s guide on how to upgrade the VMs and the cluster’s functional level. The following PowerShell cmdlet can be used for this purpose:


Hint: if you decide to check the functional level of the cluster containing only 2012 R2 nodes, the PowerShell command

will not even return the value. But whenever at least one 2016 node is added, this property will be available for monitoring.


At all stages of the Сluster Rolling Upgrade procedure, the production kept operating from the active cluster node, with StarWind VSAN properly serving the storage to the cluster. Thus, the Cluster Rolling Upgrade can be considered for the “live” upgrading of StarWind VSAN based environments where 24/7 availability is required.

Related materials:

Views All Time
Views Today

Please rate this

Return to all posts

Choosing proper V2V converter for smooth VM migration
5 useful tips to work with VMware vCenter Server Appliance 6.5
The following two tabs change content below.
Boris Yurchenko
Boris Yurchenko
Boris is a Tech Support Engineer at StarWind. He is keen on virtualization and adores playing around with Java and PowerShell.