Control panels

Configuring Windows Server for high availability with failover clustering

Install the Failover Clustering feature, validate two nodes, create a cluster, set quorum and test a failover on Windows Server.

AdvancedWindows server5 min read

Windows Server failover clustering groups two or more servers so a workload keeps running when one node fails. This guide covers the first steps on a Windows VPS: installing the Failover Clustering feature, validating the nodes, creating the cluster, setting quorum and testing a failover.

Before you start

  • Two or more Windows VPS running Windows Server 2019, 2022 or 2025, joined to the same Active Directory domain (or the same workgroup for a lab).
  • A static IP address for the cluster name, on the same subnet as the nodes.
  • Shared storage for any real clustered role — an iSCSI LUN visible to every node. A single VPS has local disks only, so plan for a lab or a second machine acting as an iSCSI target.
  • Admin rights on each node. Connect over RDP to 203.0.113.10:3389.
  • PowerShell open as Administrator on each node.

Note: A production cluster needs more than one machine and shared storage, so treat a single VPS as a learning or single-node environment.

Plan the topology

Decide three things before you touch PowerShell:

  1. Nodes. Two is the minimum for a failover cluster. Three or more gives you more room to lose a node.
  2. Quorum. Quorum decides which side of a split stays online. With two nodes, add a file share witness on a third machine so a single node failure does not take the cluster down.
  3. Storage. Cluster disks must be visible to every node at the same time. iSCSI is the usual choice on virtual machines.

Give each node a clear name, for example RR-NODE1 and RR-NODE2, and keep them in the same subnet as the cluster IP.

Install the Failover Clustering feature

On every node, run:

PowerShell
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

Warning: The install can request a restart. Reboot each node during a maintenance window — see Windows Update on a VPS: patches and maintenance windows — and reconnect over RDP on port 3389 afterwards.

Confirm the feature is present:

PowerShell
Get-WindowsFeature -Name Failover-Clustering

You want Install State: Installed.

Validate the configuration

Validation runs a set of tests against the nodes and reports problems before you build anything. From one node:

PowerShell
Test-Cluster -Node RR-NODE1,RR-NODE2 -ReportName C:\cluster-report.htm

Open C:\cluster-report.htm in a browser. Read the warnings, not just the pass or fail line. Network and storage warnings are the ones that bite later.

Tip: If you are building a lab with no shared storage, add -Ignore Storage to skip the storage tests. The cluster will still form, but you cannot add a disk-based role.

Create the cluster

With validation clean, create the cluster and give it a static address:

PowerShell
New-Cluster -Name RR-CLUSTER -Node RR-NODE1,RR-NODE2 -StaticAddress 203.0.113.50 -NoStorage

-NoStorage is correct when you have not attached shared disks yet. Drop it once your iSCSI LUNs are online on both nodes.

Check the result:

PowerShell
Get-Cluster
Get-ClusterNode

Both nodes should show State: Up.

Set quorum

For a two-node cluster, a file share witness is the usual choice. Create a share on a third machine that both nodes can reach, then:

PowerShell
Set-ClusterQuorum -NodeAndFileShareWitness "\\fileserver\witness"

Verify:

PowerShell
Get-ClusterQuorum

Warning: If the witness share is unreachable and one node fails, the remaining node may not reach quorum and the cluster goes offline. Keep the witness on a machine that is not one of the cluster nodes.

Add a clustered role

A clustered role is the workload that moves between nodes. A file server is the simplest to test. Attach the shared disk to both nodes first, then:

PowerShell
Add-ClusterFileServerRole -Storage "Cluster Disk 1" -Name FS01 -StaticAddress 203.0.113.60

For other workloads — SQL Server, IIS, generic services — install the application on every node first, then add the role with the matching Add-Cluster*Role cmdlet. See Add or remove Windows roles and features for the base install.

Check it works

Move the role to the other node and watch it come back:

PowerShell
Get-ClusterGroup
Move-ClusterGroup -Name "FS01" -Node RR-NODE2
Get-ClusterGroup

The group should show OwnerNode: RR-NODE2 and State: Online. Connect to the role's IP or name from a client and confirm it still answers. Then move it back.

Also confirm the cluster itself is healthy:

PowerShell
Get-Cluster | Select-Object Name, QuorumType, QuorumResource

Troubleshooting

  • Validation fails on storage. Cause: the LUN is not presented to every node, or only one node can see it. Fix: check the iSCSI initiator on each node and confirm the target allows multiple sessions.
  • New-Cluster returns "An error occurred while creating the cluster". Cause: the cluster name or static IP is already in use, or the nodes sit in different subnets. Fix: pick a free IP in the same subnet and retry.
  • A node shows State: Down or is evicted. Cause: the node lost network to the rest of the cluster, or the witness is unreachable. Fix: check the witness share permissions and run Get-ClusterLog -Node RR-NODE1 -Destination C:\ to read the cluster log.
  • The role fails over but clients lose the connection. Cause: the application is not cluster-aware, or the client cached the old node. Fix: use a clustered role type that supports failover, and check DNS for the role name.

Next steps

Was this guide helpful?

Still stuck?

Ask MdmHost AI for a quick answer, or open a ticket and our team will take a look. We are here 24/7.

Ask MdmHost AIOpen a ticket

Related guides