How to Configure Failover Clustering on Windows Server 2025

Windows Server 2025 Failover Clustering delivers high availability for critical workloads by automatically restarting services and virtual machines on healthy cluster nodes when a hardware or software failure occurs. Unlike load-balanced solutions that distribute traffic across servers, a failover cluster maintains a pool of nodes where roles (clustered services, Hyper-V VMs, file servers) run on one node at a time but can be migrated or failed over to another node within seconds. Windows Server 2025 introduces improvements to cluster-aware updating, storage bus caching for S2D clusters, and tighter integration with Azure Arc for hybrid monitoring. This guide walks through a complete Failover Cluster deployment, from feature installation through quorum configuration, shared storage setup, role creation, and live failover testing.

Prerequisites

A minimum of 2 nodes running Windows Server 2025 (Standard or Datacenter edition); Datacenter is required for unlimited Hyper-V guests
All nodes joined to the same Active Directory domain
Each node requires at least two network adapters: one for cluster heartbeat/management, one for client traffic
Shared storage accessible by all nodes: iSCSI LUN, Fibre Channel SAN, or S2D (local disks only for S2D)
DNS resolving correctly for all node names and the planned cluster name
An Active Directory account with permissions to create computer objects in the designated OU for the cluster name object (CNO)
For Cloud Witness quorum: Azure subscription and a Storage Account blob container

Step 1: Install the Failover Clustering Feature

Install the Failover Clustering feature on every node that will participate in the cluster. The -IncludeManagementTools parameter adds the Failover Cluster Manager console (cluadmin.msc), the FailoverClusters PowerShell module, and Cluster-Aware Updating tools. It is a best practice to install across all nodes simultaneously using PowerShell remoting.

# Install on all nodes simultaneously using remoting
$clusterNodes = @("Node1","Node2","Node3","Node4")

Invoke-Command -ComputerName $clusterNodes -ScriptBlock {
    Install-WindowsFeature -Name Failover-Clustering `
        -IncludeManagementTools -Restart:$false
}

# Verify feature installation on each node
Invoke-Command -ComputerName $clusterNodes -ScriptBlock {
    Get-WindowsFeature -Name Failover-Clustering | `
        Select-Object DisplayName, Installed, InstallState
}

# Import the FailoverClusters module on the management station
Import-Module FailoverClusters

Step 2: Run Cluster Validation Tests

Before creating the cluster, run the Cluster Validation Wizard using Test-Cluster. This generates a comprehensive HTML report covering network configuration, storage access, system configuration, and hardware compatibility. Microsoft only fully supports clusters where all required validation tests pass. Review any warnings or failures in the report before proceeding to production — do not dismiss hardware-related failures without investigation.

# Run full cluster validation — this may take 15-30 minutes
Test-Cluster -Node "Node1","Node2","Node3","Node4" `
    -Include "Inventory","Network","System Configuration","Storage"

# For S2D-specific validation, include the S2D tests
Test-Cluster -Node "Node1","Node2","Node3","Node4" `
    -Include "Storage Spaces Direct","Network","System Configuration"

# The validation report is saved automatically:
# C:WindowsclusterReportsValidation Report .htm
# Open it in a browser to review all test results

# Quick check — list any failed tests from the output
# (review the HTML report for full details on warnings and failures)

Step 3: Create the Failover Cluster

Once validation passes, create the cluster. Provide a cluster name (which becomes the Cluster Name Object in Active Directory), a static IP address for the cluster, and the list of nodes. The cluster name must not exceed 15 characters and must be unique in DNS. If your network uses DHCP only, omit -StaticAddress and the cluster will attempt to use DHCP or an administrative access point without an IP address on Windows Server 2019+ clusters.

# Create the failover cluster with a static IP address
New-Cluster -Name "PROD-Cluster01" `
    -Node "Node1","Node2","Node3","Node4" `
    -StaticAddress "10.10.1.100" `
    -NoStorage

# Verify the cluster was created and all nodes are online
Get-ClusterNode | Select-Object Name, State, Id

# Check cluster network configuration
Get-ClusterNetwork | Select-Object Name, State, Role, Address, AddressMask

# Verify the Cluster Name Object (CNO) in AD
Get-ADComputer -Filter { Name -eq "PROD-Cluster01" } | Select-Object Name, DistinguishedName

Step 4: Configure Cluster Networks

Properly segregating cluster network traffic is critical for reliability. Windows Server 2025 clustering uses multiple networks: one for client-facing traffic, one for cluster heartbeat, and optionally one for live migration and storage. Assign roles to each network to prevent heartbeat traffic from competing with VM guest traffic.

# View all cluster networks detected
Get-ClusterNetwork | Select-Object Name, State, Role, Address

# Cluster network roles:
# 0 = None (not used for clustering)
# 1 = Cluster only (heartbeat, internal cluster traffic)
# 3 = Cluster and Client (both heartbeat and client traffic)

# Set the heartbeat network to Cluster-only traffic
(Get-ClusterNetwork "Cluster Heartbeat").Role = 1

# Set the client-facing network to Cluster and Client
(Get-ClusterNetwork "Client Network").Role = 3

# Disable clustering on the storage/iSCSI network to prevent interference
(Get-ClusterNetwork "Storage Network").Role = 0

# Configure Live Migration to use the dedicated network
Set-VMHost -ComputerName "Node1","Node2","Node3","Node4" `
    -VirtualMachineMigrationNetwork "10.10.10.0/24"

Step 5: Configure Cluster Quorum

Quorum determines whether a cluster has sufficient votes to remain operational and serve workloads. With an even number of nodes, you must add a tiebreaker witness. Windows Server 2025 supports three witness types: Disk Witness (a small clustered disk), File Share Witness (an SMB share on a separate server), and Cloud Witness (an Azure Storage blob). Cloud Witness is recommended for geographically distributed clusters or when avoiding a single-location dependency.

# Option 1: Cloud Witness (recommended for most deployments)
Set-ClusterQuorum -CloudWitness `
    -AccountName "storaccclusterwitness" `
    -AccessKey "your-azure-storage-account-key-base64-here"

# Option 2: Disk Witness (for clusters with shared storage)
# First, find an available disk
Get-ClusterAvailableDisk | Select-Object Name, DiskId, Size

# Add a small disk (1 GB is sufficient) as the disk witness
$witnessDisk = Get-ClusterAvailableDisk | Where-Object { $_.Size -lt 5GB } | Select-Object -First 1
Set-ClusterQuorum -DiskWitness $witnessDisk

# Option 3: File Share Witness (separate server required)
Set-ClusterQuorum -FileShareWitness "\WitnessServerClusterWitness"

# Verify the current quorum configuration
Get-ClusterQuorum | Select-Object Cluster, QuorumType, QuorumResource

Step 6: Add Shared Storage to the Cluster

For traditional shared-storage clusters (non-S2D), add iSCSI LUNs or Fibre Channel disks to the cluster storage pool. All nodes must have access to the shared disks before they are added to the cluster.

# Discover and add all available cluster disks
Get-ClusterAvailableDisk | Add-ClusterDisk

# Verify disks are now cluster resources
Get-ClusterResource | Where-Object { $_.ResourceType -eq "Physical Disk" } | `
    Select-Object Name, State, OwnerNode

# Add a specific disk by name or disk ID
$disk = Get-ClusterAvailableDisk | Where-Object { $_.Name -eq "Cluster Disk 1" }
$disk | Add-ClusterDisk

# Move a disk to a Cluster Shared Volume for concurrent access by all nodes
Get-ClusterDisk "Cluster Disk 1" | Add-ClusterSharedVolume

# List all Cluster Shared Volumes
Get-ClusterSharedVolume | Select-Object Name, State, OwnerNode, SharedVolumeInfo

Step 7: Create Clustered Roles

Clustered roles are services or applications that run on one cluster node at a time and automatically restart on another node during a failure. Windows Server 2025 supports built-in clustered roles including Scale-Out File Server, Generic Service, Hyper-V virtual machines, and more.

# Create a Scale-Out File Server (SOFS) role for SMB 3 multi-channel access
Add-ClusterScaleOutFileServerRole -Name "SOFS-FileServer01"

# Create a standard File Server role (single-node access with failover)
Add-ClusterFileServerRole -Name "ClusteredFS01" `
    -StaticAddress "10.10.1.110" `
    -Storage "Cluster Disk 1"

# Add a clustered generic service (e.g., a custom Windows service)
Add-ClusterGenericServiceRole -ServiceName "MyAppService" `
    -Name "ClusteredAppService" `
    -StaticAddress "10.10.1.111"

# List all clustered roles and their current state
Get-ClusterGroup | Select-Object Name, State, OwnerNode, GroupType | `
    Sort-Object State

Step 8: Test Failover

After configuring the cluster, verify that roles fail over correctly and that shared storage and network resources are properly transferred to the new owner node. Testing failover before production use is mandatory — it validates the cluster configuration and exposes any issues with storage connectivity or application restart behaviour.

# Move a clustered role (live migration) to a specific node
Move-ClusterGroup -Name "ClusteredFS01" -Node "Node2"

# Verify it moved successfully
Get-ClusterGroup -Name "ClusteredFS01" | Select-Object Name, State, OwnerNode

# Simulate a node failure (drain the node first to safely move roles)
Suspend-ClusterNode -Name "Node1" -Drain -ForceDrain

# Verify all roles moved off Node1
Get-ClusterGroup | Where-Object { $_.OwnerNode -eq "Node1" }

# Bring the node back and restore cluster membership
Resume-ClusterNode -Name "Node1"

# Check node health after resume
Get-ClusterNode -Name "Node1" | Select-Object Name, State, DrainStatus

Step 9: Configure Cluster-Aware Updating

Cluster-Aware Updating (CAU) automates the process of applying Windows updates to cluster nodes while maintaining cluster availability. CAU drains each node one at a time, applies updates, restarts, resumes the node, and then moves to the next. This eliminates the downtime traditionally required for patching clustered servers.

# Scan the cluster for applicable updates without installing them
Invoke-CauScan -ClusterName "PROD-Cluster01" -Verbose

# Run a CAU update pass immediately (installs updates across all nodes)
Invoke-CauRun -ClusterName "PROD-Cluster01" `
    -MaxFailedNodes 1 `
    -MaxRetriesPerNode 3 `
    -RequireAllNodesOnline `
    -Force

# Configure a recurring CAU schedule (every 4 weeks on Wednesday at 2AM)
Add-CauClusterRole -ClusterName "PROD-Cluster01" `
    -DaysOfWeek Wednesday `
    -WeeksOfMonth 2 `
    -StartTime "02:00" `
    -EnableFirewallRules `
    -Force

# Verify CAU cluster role configuration
Get-CauClusterRole -ClusterName "PROD-Cluster01"

Step 10: Review the Cluster Validation Report and Monitor Health

Ongoing monitoring of cluster health prevents unexpected failures from becoming service outages. Windows Server 2025 provides rich telemetry through the Failover Cluster Manager, Windows Admin Center, and PowerShell health cmdlets.

# Check overall cluster health
Get-Cluster -Name "PROD-Cluster01" | Select-Object Name, QuorumType, SharedVolumesRoot

# Check all cluster resources and their state
Get-ClusterResource | Select-Object Name, State, ResourceType, OwnerGroup, OwnerNode

# View recent cluster events
Get-WinEvent -LogName "Microsoft-Windows-FailoverClustering/Operational" `
    -MaxEvents 50 | Where-Object { $_.Level -le 3 } | `
    Select-Object TimeCreated, Id, Message

# Check node health and uptime
Get-ClusterNode | ForEach-Object {
    $node = $_
    $uptime = Invoke-Command -ComputerName $node.Name -ScriptBlock {
        (Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime
    }
    [PSCustomObject]@{
        Node    = $node.Name
        State   = $node.State
        Uptime  = $uptime.ToString("d.hh:mm:ss")
    }
}

# Check for cluster storage issues
Get-ClusterSharedVolume | Select-Object Name, State, OwnerNode, `
    @{N="FreeSpaceGB";E={[math]::Round($_.SharedVolumeInfo.Partition.FreeSpace/1GB,1)}}

Conclusion

Windows Server 2025 Failover Clustering provides the high availability foundation required for mission-critical workloads including Hyper-V virtual machines, SQL Server, file servers, and custom applications. By following this guide, you have installed and validated the cluster, configured quorum with an appropriate witness, added shared storage, created clustered roles, and verified that automatic failover works correctly. For production environments, never deploy a cluster without first reviewing the full Cluster Validation Report and resolving all warnings — even seemingly minor configuration inconsistencies can cause split-brain scenarios during real failures. Implement CAU for automated patch management to maintain security without scheduling maintenance windows, and use Windows Admin Center alongside PowerShell monitoring to maintain visibility into cluster health, resource state, and storage utilisation across all nodes continuously.

Links

Newsletter

Contact