StarWind is a hyperconverged (HCI) vendor with focus on Enterprise ROBO, SMB & Edge

Windows Server 2016 Core configuration. Part 3: Failover Clustering

  • April 3, 2018
  • 8 min read
StarWind Solutions Architect. Alex has begun his journey as a hobbyist in the virtualization and storage sphere. He possesses extensive knowledge in networking, storage technologies, and virtualization.
StarWind Solutions Architect. Alex has begun his journey as a hobbyist in the virtualization and storage sphere. He possesses extensive knowledge in networking, storage technologies, and virtualization.

Looking back at the previous articles in our “How-to-Core basics”, we have managed to install the Core version of Windows Server 2016. As well, the required networks were set, and the storage for the virtual machines was created.

In the final part of the trilogy, I’ll cover the steps left to prepare the environment in order to make your production highly available and fault-tolerant.

Being short, last time, we were up to installing Windows Server Core version on a single server and adding the storage as an iSCSI target. Highly available and fault-tolerant storage requires another server to create the failover cluster. There’s not much difference between the required configuration and the steps we did previously.

Considering that the final solution must be redundant, you will need to use the local storage of both nodes and make the same steps we did to partition and initialize the storage, excluding the part of connecting the storage via iSCSI protocol.

One of the key aspects that will allow your production to migrate between the servers, is to place the data and virtual machines on a shared storage. For that purpose, we need to install Failover Clustering role on both servers and create a Cluster Shared Volume between them. This can be done in two ways.

The first one is to use Server Manager on your laptop, for example, and simply add both servers to the server list. The Failover Clustering role can be added with “Add Roles and Features” button located in Manage tab:

Adding the Failover Clustering role via Server Manager

The Failover Clustering feature

But we’re not going the GUI way, right? 😊 It can be added via PowerShell as well:

Install-WindowsFeature -Name-Failover-Clustering

Installing the Failover Clustering feature via PowerShell

Now, when we have the Failover Clustering role installed on both servers, it is recommended to join them into a domain. In order to do this, you will need a Domain Controller (DC) to be installed and configured. By the way, I’ve covered the general recommendations for creating a DC some time ago in one of my webinars, here it is: Useful tips for setting up Microsoft Active Directory Domain Controllers. In two words, you will need at least two DC set as virtual machines on the local storage of each server to achieve the DC redundancy. Setting one of them off-site will be even safer.

Another thing worth our attention is enabling Jumbo packets on the networks that will be used for the synchronization of data and iSCSI connections. You can do it using the next PowerShell command on each network:


Where “NAME” must be the same as your networks are named.

Enabling Jumbo packets on networks

Finally, we can create a shared storage between two servers. Let’s use VSAN from StarWind, as a good option. I’m not going to describe the whole StarWind installation guide in here, so let’s stick with “as short, as it can be in this case”.

After installing StarWind service on both servers, we need a laptop with StarWind Management Console installed on it. We created two devices, one of them will be used as a Quorum Witness drive in our Failover Cluster. Another one will be used as the Cluster Shared Volume for our production VMs. Both devices are replicated between the nodes.

Creating StarWind HA devices

Using the iSCSI initiator, we discovered the iSCSI IP addresses and connected the targets.

Connecting targets via iSCSI Initiator

With the commands listed in the first part (Windows Server 2016 Core configuration. Part 1) of this “trilogy”, we have managed to create partitions, initialize and format newly created devices. After that, we created a cluster with the functionality of Failover Cluster Manager, joined both nodes and added the storage device in the Failover Cluster Manager as a Cluster Shared Volume. Alongside, the Witness device was presented as a Quorum drive.

Adding StarWind HA device as Cluster Shared Volume

So, summarizing all that was written in this article and the previous parts of “How-to-Core basics”, we were successful in installing Microsoft Windows Server Core edition and adding all additional functionality that is required for creating a highly available and fault-tolerant shared storage.

Using the Core version of Windows Server helps you to decrease the overall license costs. Additionally, it will be a great choice for PowerShell gurus that don’t need that GUI in their servers.


Found Alex’s article helpful? Looking for a reliable, high-performance, and cost-effective shared storage solution for your production cluster?
Dmytro Malynka
Dmytro Malynka StarWind Virtual SAN Product Manager
We’ve got you covered! StarWind Virtual SAN (VSAN) is specifically designed to provide highly-available shared storage for Hyper-V, vSphere, and KVM clusters. With StarWind VSAN, simplicity is key: utilize the local disks of your hypervisor hosts and create shared HA storage for your VMs. Interested in learning more? Book a short StarWind VSAN demo now and see it in action!