How to Configure Failover Clustering on Windows Server 2012 R2

November 19, 2025
Tutorials
Comment off

How to Configure Failover Clustering on Windows Server 2012 R2

Failover Clustering is a high-availability feature in Windows Server 2012 R2 that allows multiple servers (nodes) to work together to keep services and applications running if one or more nodes fail. When a clustered node becomes unavailable due to hardware failure, software crash, or planned maintenance, the cluster automatically moves workloads to surviving nodes with minimal disruption. Windows Server 2012 R2 includes significant improvements over previous versions, including support for up to 64 nodes, 8,000 virtual machines per cluster, enhanced cluster awareness, and CSV (Cluster Shared Volumes) improvements. Failover Clustering is the foundation for highly available Hyper-V, SQL Server, file services, and other workloads.

Prerequisites

You need at least two Windows Server 2012 R2 servers that are members of the same Active Directory domain. Each node must have identical network adapter configurations for cluster communication. Shared storage must be available to all cluster nodes — this can be iSCSI, Fibre Channel, SAS, or SMB 3.0 (for certain workloads). All nodes must pass the Validate a Cluster Configuration Wizard tests before the cluster is created. DNS must be functioning correctly for cluster name resolution. An IP address must be available for the cluster name, and administrative credentials on all nodes are required.

Step 1: Install Failover Clustering Feature

Install the Failover Clustering feature on all servers that will be cluster nodes:

Install-WindowsFeature Failover-Clustering -IncludeManagementTools

To install on remote nodes simultaneously:

$nodes = @("Node01", "Node02", "Node03")
$nodes | ForEach-Object {
    Invoke-Command -ComputerName $_ -ScriptBlock {
        Install-WindowsFeature Failover-Clustering -IncludeManagementTools
    }
}

Step 2: Configure Network Adapters

Before creating the cluster, configure network adapters for specific roles. Best practice requires at minimum one network for cluster communication (heartbeat) that is isolated from regular traffic:

# Rename adapters for clarity
Rename-NetAdapter -Name "Ethernet" -NewName "Public_LAN"
Rename-NetAdapter -Name "Ethernet 2" -NewName "Cluster_Heartbeat"
Rename-NetAdapter -Name "Ethernet 3" -NewName "iSCSI_Storage"

# Configure static IPs on each adapter
New-NetIPAddress -InterfaceAlias "Cluster_Heartbeat" -IPAddress "10.10.10.1" -PrefixLength 24
# (Disable gateway and DNS on heartbeat network)
Set-DnsClient -InterfaceAlias "Cluster_Heartbeat" -RegisterThisConnectionsAddress $false

Step 3: Configure Shared Storage

All cluster nodes must have access to the same shared storage. For iSCSI-based storage, connect each node to the iSCSI target and initialize the disks. Do not format the disks on individual nodes — let the cluster manage them.

# On each node, connect to the iSCSI target
Start-Service MSiSCSI
Set-Service MSiSCSI -StartupType Automatic
New-IscsiTargetPortal -TargetPortalAddress "192.168.100.10"
Connect-IscsiTarget -NodeAddress "iqn.1991-05.com.microsoft:storage-cluster-target" -IsPersistent $true

# Bring the disk online (on one node only initially)
Get-Disk | Where-Object {$_.OperationalStatus -eq "Offline"} | Set-Disk -IsOffline $false
Initialize-Disk -Number 1 -PartitionStyle GPT
New-Partition -DiskNumber 1 -UseMaximumSize -AssignDriveLetter
Format-Volume -DriveLetter Q -FileSystem NTFS -NewFileSystemLabel "QuorumDisk" -Confirm:$false

# Take it offline again — the cluster will bring it online
Set-Disk -Number 1 -IsOffline $true

Step 4: Validate the Cluster Configuration

Microsoft requires passing cluster validation tests before creating a supported cluster. Run the validation wizard against all potential cluster nodes:

Test-Cluster -Node "Node01", "Node02" -Include "System Configuration", "Network", "Storage", "Inventory"

Review the validation report carefully. Warnings may be acceptable for test environments, but all errors must be resolved before creating a production cluster. The report is saved to C:WindowsClusterReports.

Step 5: Create the Failover Cluster

Create the cluster using PowerShell. The cluster name and IP address will be used by clients to access cluster resources:

New-Cluster -Name "CLUSTER01" `
    -Node "Node01", "Node02" `
    -StaticAddress "192.168.1.100" `
    -NoStorage

The -NoStorage parameter creates the cluster without automatically adding storage. Storage will be added separately to maintain control over disk assignments. Verify the cluster was created:

Get-Cluster | Select-Object Name, Domain, WitnessDatabaseWriteTimeout

Get-ClusterNode | Select-Object Name, State, ID

Step 6: Configure Cluster Quorum

The quorum configuration determines how many nodes must agree before cluster operations proceed. For a two-node cluster, a disk or file share witness is required to break ties. Configure a disk witness using the quorum disk:

Set-ClusterQuorum -Cluster "CLUSTER01" -DiskWitness "Cluster Disk 1"

Alternatively, configure a file share witness for cloud or branch scenarios:

Set-ClusterQuorum -Cluster "CLUSTER01" -FileShareWitness "\DCServerClusterWitness"

For three or more nodes, use Node Majority (no witness needed in most cases):

Set-ClusterQuorum -Cluster "CLUSTER01" -NodeMajority

Step 7: Add Storage to the Cluster

Add the shared disks to the cluster’s Available Storage group:

Get-ClusterAvailableDisk | Add-ClusterDisk

Verify cluster disks are available:

Get-ClusterResource | Where-Object {$_.ResourceType -eq "Physical Disk"} | Select-Object Name, State, OwnerNode

Step 8: Enable Cluster Shared Volumes (CSV)

CSV allows multiple cluster nodes to simultaneously read and write to the same disk volume, which is essential for live migration of Hyper-V virtual machines:

Add-ClusterSharedVolume -Name "Cluster Disk 2"

Get-ClusterSharedVolume | Select-Object Name, State, SharedVolumeInfo

Step 9: Configure Cluster Networks

Configure which networks are used for cluster communication and client access:

Get-ClusterNetwork | Select-Object Name, Address, State, Role

# Set Heartbeat network to internal-only (cluster communications only)
(Get-ClusterNetwork -Name "Cluster Network 2").Role = 1  # ClusterOnly

# Set storage network to none (no cluster communication)
(Get-ClusterNetwork -Name "Cluster Network 3").Role = 0  # None

Step 10: Test Cluster Failover

Test the cluster by moving all cluster roles from one node to another:

Move-ClusterGroup -Name "Available Storage" -Node "Node02"

Get-ClusterNode | Select-Object Name, State
Get-ClusterResource | Select-Object Name, State, OwnerNode

Simulate a node failure by pausing a node:

Suspend-ClusterNode -Name "Node01" -Drain

# Verify resources failed over to Node02
Get-ClusterResource | Select-Object Name, State, OwnerNode

# Resume Node01
Resume-ClusterNode -Name "Node01" -Failback NoFailback

Summary

Failover Clustering on Windows Server 2012 R2 provides the foundation for building highly available workloads that survive individual node failures. From installing the feature and validating hardware compatibility, to configuring quorum, shared storage, and CSV volumes, each step contributes to a robust cluster architecture. Once the cluster is operational, workloads like Hyper-V virtual machines, file services, and SQL Server can be deployed as clustered roles that automatically fail over when problems occur.

Links

Newsletter

Contact