How to Configure Failover Clustering on Windows Server 2012 R2

May 4, 2026
Tutorials
Comment off

How to Configure Failover Clustering on Windows Server 2012 R2

Failover Clustering provides high availability for workloads by allowing multiple servers to work together as a cluster. If one node fails, another node automatically takes over the running workloads (virtual machines, file shares, SQL Server instances, etc.) with minimal downtime. Windows Server 2012 R2 Failover Clustering includes significant improvements: dynamic quorum adjustment, tie-breaking votes for even-numbered clusters, shared virtual hard disks, virtual machine drain on shutdown, and improved cluster-aware updating.

This guide covers the end-to-end setup of a two-node failover cluster: preparing nodes, validating cluster prerequisites, creating the cluster, configuring shared storage, and adding a high-availability role.

Prerequisites

Two Windows Server 2012 R2 servers with identical hardware configuration (recommended).
Both servers joined to the same Active Directory domain.
At least two network adapters per node: one for client traffic, one for cluster heartbeat.
Shared storage accessible by both nodes (iSCSI, Fibre Channel, or SAS).
Domain Administrator account.
All Windows Updates installed on both nodes before clustering.

Step 1: Install the Failover Clustering Feature

# Install on NODE01
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

# Install on NODE02 (run from NODE01 using remote management, or run locally on NODE02)
Invoke-Command -ComputerName NODE02 -ScriptBlock {
    Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools
}

# Verify on both nodes
Get-WindowsFeature -Name Failover-Clustering | Select-Object Name, InstallState

Invoke-Command -ComputerName NODE02 -ScriptBlock {
    Get-WindowsFeature -Name Failover-Clustering | Select-Object Name, InstallState
}

Step 2: Validate the Cluster Configuration

Running the cluster validation wizard is mandatory before creating a production cluster. It tests networking, storage, system configuration, and Active Directory requirements. Do not skip this step — Microsoft support requires a passing validation report for production clusters.

# Run cluster validation and save the report
Test-Cluster `
    -Node "NODE01","NODE02" `
    -Include "Inventory","Network","Storage","System Configuration" `
    -ReportName "C:ClusterValidationClusterValidationReport"

# View the HTML report
Start-Process "C:ClusterValidationClusterValidationReport.htm"

# Check for warnings and errors in the output
# Common issues to fix before proceeding:
# - Network adapters in the same subnet on different segments
# - Storage not visible to all nodes
# - Mismatched drivers or firmware versions

Step 3: Create the Failover Cluster

# Create the cluster with a cluster name and IP address
# The cluster name becomes a computer account in Active Directory
New-Cluster `
    -Name "CLUSTER01" `
    -Node "NODE01","NODE02" `
    -StaticAddress "192.168.1.20" `
    -NoStorage

# Verify the cluster was created
Get-Cluster -Name CLUSTER01

# Check cluster nodes
Get-ClusterNode -Cluster CLUSTER01

# Verify the cluster is accessible
Test-NetConnection -ComputerName CLUSTER01 -Port 445

Step 4: Configure Quorum

Quorum determines which nodes have voting rights and prevents split-brain scenarios. For a two-node cluster, a disk witness or file share witness provides the tiebreaker vote.

# For a two-node cluster: configure a File Share Witness (good for stretched clusters)
# First create the share on a third server (not a cluster node)
New-Item -Path "C:ClusterWitnessCLUSTER01" -ItemType Directory
New-SmbShare -Name "CLUSTER01-Witness" -Path "C:ClusterWitnessCLUSTER01" `
    -FullAccess "CORPCLUSTER01$","CORPDomain Admins"

# Configure the cluster to use the file share witness
Set-ClusterQuorum -Cluster CLUSTER01 `
    -FileShareWitness "\WITNESS-SRVCLUSTER01-Witness"

# For a cluster with shared storage, use a disk witness instead
Set-ClusterQuorum -Cluster CLUSTER01 -DiskWitness "Cluster Disk 1"

# Check current quorum configuration
Get-ClusterQuorum -Cluster CLUSTER01

# Check quorum health
Get-Cluster CLUSTER01 | Select-Object QuorumType, QuorumResource

Step 5: Add and Configure Cluster Shared Storage

# Add available storage to the cluster
Get-ClusterAvailableDisk -Cluster CLUSTER01 | Add-ClusterDisk

# List cluster disks
Get-ClusterResource -Cluster CLUSTER01 | Where-Object { $_.ResourceType -eq "Physical Disk" }

# Rename cluster disks for clarity
Get-ClusterResource -Name "Cluster Disk 1" | 
    Set-ClusterResource -Name "DATA-VOL-01"

# Move a disk to a specific node for formatting
Move-ClusterResource -Name "DATA-VOL-01" -Node NODE01

# Format the disk and assign a drive letter (run on NODE01 after moving)
Get-Disk | Where-Object { $_.OperationalStatus -eq "Online" -and $_.PartitionStyle -eq "RAW" } |
    Initialize-Disk -PartitionStyle GPT -PassThru |
    New-Partition -DriveLetter E -UseMaximumSize |
    Format-Volume -FileSystem NTFS -NewFileSystemLabel "Data01" -Confirm:$false

Step 6: Add a Clustered File Server Role

# Add a Scale-Out File Server role for application data
Add-ClusterScaleOutFileServerRole -Cluster CLUSTER01 -Name "FILESVR-HA"

# Or add a General Use File Server role
Add-ClusterFileServerRole `
    -Cluster CLUSTER01 `
    -Name "FILESVR-HA" `
    -StaticAddress "192.168.1.25" `
    -Storage "DATA-VOL-01"

# Verify the role is online
Get-ClusterResource -Cluster CLUSTER01 | 
    Where-Object { $_.ResourceType -eq "File Server" }

# Create a highly available share on the cluster
New-SmbShare -Name "HAShare" -Path "E:SharesHAShare" `
    -ScopeName "FILESVR-HA" `
    -FullAccess "CORPDomain Admins" `
    -ChangeAccess "CORPDomain Users"

Step 7: Test Failover

# Check the current owner of all cluster roles
Get-ClusterGroup -Cluster CLUSTER01 | 
    Select-Object Name, State, OwnerNode

# Move a cluster group to the other node (graceful failover test)
Move-ClusterGroup -Name "FILESVR-HA" -Node NODE02 -Cluster CLUSTER01

# Verify it moved
Get-ClusterGroup -Name "FILESVR-HA" -Cluster CLUSTER01 | 
    Select-Object Name, State, OwnerNode

# Simulate a node failure (pause a node — drains roles first)
Suspend-ClusterNode -Name NODE01 -Drain -Cluster CLUSTER01

# Resume the node
Resume-ClusterNode -Name NODE01 -Cluster CLUSTER01

# View cluster event log
Get-EventLog -LogName "System" -Source "Microsoft-Windows-FailoverClustering*" -Newest 20

Summary

Failover Clustering on Windows Server 2012 R2 provides automated workload recovery when a server node fails or is taken offline for maintenance. The essential steps are: install the Failover Clustering feature on all nodes, run and pass the cluster validation wizard, create the cluster with a static IP and cluster name, configure an appropriate quorum model (file share witness for two-node clusters), add and format shared storage, and add clustered roles such as File Server or Hyper-V. Always test failover thoroughly in a maintenance window after initial setup — and regularly thereafter — to confirm that roles move cleanly between nodes and that shared storage is accessible from all nodes in all failure scenarios.

How to Configure Failover Clustering on Windows Server 2012 R2