Troubleshoot Failover Cluster Quorum and Witness Failures

Admin

October 11, 2026

13 min read

Quorum lets a Windows failover cluster determine which membership can keep running. A witness failure reduces resilience but does not always stop the cluster immediately. This guide investigates Windows Server 2019, 2022, and 2025 clusters by connecting node votes, witness state, network access, and the failure timeline.

Record Membership and Current Vote Assignments

Quorum Model

Record current node state, configured NodeWeight, current DynamicWeight, quorum configuration, and witness vote. Dynamic quorum can adapt votes as membership changes, and dynamic witness adjusts whether the witness contributes a vote. These features do not guarantee survival of arbitrary simultaneous failures. Evaluate the actual sequence of outages. For Storage Spaces Direct, cluster quorum and storage-pool quorum are separate concerns; a running cluster does not prove storage is available.

Import-Module FailoverClusters
$cluster = 'CLUSTER01'
Get-Cluster -Name $cluster |
  Select-Object Name, DynamicQuorum, WitnessDynamicWeight
Get-ClusterNode -Cluster $cluster |
  Select-Object Name, State, NodeWeight, DynamicWeight
Get-ClusterQuorum -Cluster $cluster | Format-List *

Separate a Witness Failure from a Workload Failure

Resource State

Inspect the core cluster group, witness resource, application groups, and resource owners. A failed witness with healthy application groups is a resilience incident; a failed application resource may have an independent dependency problem. Capture the witness type and its private parameters. A disk witness, file share witness, and cloud witness depend on different paths, so choose the matching branch below.

Get-ClusterGroup -Cluster $cluster |
  Select-Object Name, State, OwnerNode
Get-ClusterResource -Cluster $cluster |
  Select-Object Name, ResourceType, State, OwnerGroup, OwnerNode
$witness = (Get-ClusterQuorum -Cluster $cluster).QuorumResource
if ($witness) { $witness | Get-ClusterParameter }

Collect a Bounded Cluster Log and Node Events

Timeline

Generate logs covering the incident interval, then correlate node eviction, witness arbitration, resource failures, and network events. Use local-time logs only with explicit timezone information; align timestamps with network and storage telemetry. Generate logs from all reachable nodes, not only the current owner. Protect exported logs because they can reveal infrastructure names and paths.

$logDirectory = 'C:\ClusterEvidence\Incident01'
New-Item -ItemType Directory -Path $logDirectory -Force | Out-Null
Get-ClusterLog -Cluster $cluster -TimeSpan 30 -UseLocalTime `
  -Destination $logDirectory
foreach ($node in 'CL01', 'CL02') {
  Get-WinEvent -ComputerName $node -FilterHashtable @{
    LogName = 'System'
    ProviderName = 'Microsoft-Windows-FailoverClustering'
    StartTime = (Get-Date).AddMinutes(-30)
  } -MaxEvents 100 | Select-Object MachineName, TimeCreated, Id, Message
}

SMB Witness

For a domain-joined file share witness, check name resolution, SMB reachability, and both share/NTFS permissions for the cluster name object (CNO). The witness owner should grant the specific CNO computer account the required Full Control on the dedicated share and directory, following Microsoft’s deployment procedure. An administrator opening the share does not prove that the cluster identity can use it. Keep the witness in an independent failure domain, without a dependency on this cluster’s own services. Do not use a DFS-replicated share as a substitute for a dedicated witness.

# Run through authorized remoting on each node.
Invoke-Command -ComputerName CL01, CL02 -ScriptBlock {
  Resolve-DnsName WIT01.contoso.com
  Test-NetConnection WIT01.contoso.com -Port 445
}

# On WIT01: review both permission layers.
Get-SmbShareAccess -Name CLUSTER01Witness
Get-Acl -LiteralPath 'D:\Witnesses\CLUSTER01' | Format-List

❯ What to Verify

Every node can reach the witness host.
The intended cluster identity has the required share and NTFS permissions.
Successful administrator access is recorded as a separate test.

Check Cloud or Disk Witness Dependencies

Other Witness Types

For a cloud witness, verify the configured storage account, endpoint, authentication configuration, DNS, and outbound HTTPS from every node. A TCP 443 result proves a connection path, not successful witness authentication. For a disk witness, inspect the named cluster disk and storage/fabric events; do not initialize, format, or bring it online outside cluster control. Follow the storage design if the fault coincides with lost SAN paths.

# Cloud-witness example: use your configured endpoint, not this sample name.
Invoke-Command -ComputerName CL01, CL02 -ScriptBlock {
  Resolve-DnsName exampleaccount.blob.core.windows.net
  Test-NetConnection exampleaccount.blob.core.windows.net -Port 443
}

# Disk-witness inventory, when that is your configured witness type:
Get-ClusterResource -Cluster $cluster |
  Where-Object ResourceType -eq 'Physical Disk' |
  Select-Object Name, State, OwnerNode

Select the Quorum Validation Test Explicitly

Validation Scope

List the tests available on the installed server release and choose the quorum configuration test by its reported name. The example below uses the English test name; adapt it to the installed list. Review the report’s warnings as well as failures. A validation report describes the tested configuration and time, so it cannot guarantee future connectivity during a site outage.

Test-Cluster -Node CL01, CL02 -List
# After reviewing the listed test name and approved scope:
Test-Cluster -Node CL01, CL02 -Include 'Validate Quorum Configuration'

Repair or Replace the Confirmed Witness Dependency

Approved Change

Repair DNS, network policy, storage availability, or the witness permissions first. If the witness must move, provision a dedicated replacement, verify node access and CNO permissions, and record the previous quorum configuration before applying the change. The example changes a domain-joined file share witness; non-domain witnesses and cloud witnesses have different identity requirements. Do not change node votes to conceal an unavailable witness.

Get-ClusterQuorum -Cluster $cluster | Format-List *
# Approved example only: replacement share must already be provisioned.
Set-ClusterQuorum -Cluster $cluster `
  -FileShareWitness '\\WIT02.contoso.com\CLUSTER01Witness'
Get-ClusterQuorum -Cluster $cluster | Format-List *

Verify Resilience Without Causing Another Failure

Closeout

Recheck membership, effective votes, witness state, and application groups. Rerun the scoped validation after a witness change. Test planned node/site failure scenarios in a separate maintenance exercise with explicit success criteria; do not pull live network paths merely to demonstrate recovery. Add monitoring for witness loss, unexpected node evictions, and shared dependencies, and document the intended membership for a future full outage.

Get-ClusterNode -Cluster $cluster |
  Select-Object Name, State, NodeWeight, DynamicWeight
Get-ClusterQuorum -Cluster $cluster | Format-List *
$witness = (Get-ClusterQuorum -Cluster $cluster).QuorumResource
if ($witness) { $witness | Select-Object Name, State, OwnerNode }
Get-ClusterGroup -Cluster $cluster | Select-Object Name, State, OwnerNode