Practical engineering guidance
Failover cluster witness choices, compared honestly
Quorum is a voting problem, and the witness is the vote that breaks ties. Each of the three options fails in a different way, and the right choice depends on what you expect to lose.
Series: Windows Server and Azure Local
A cluster stays online while it holds a majority of votes. That is the whole of quorum, and everything else is detail about who gets a vote and what happens when the votes are split evenly.
The witness exists because an even split is otherwise fatal. Two nodes, one vote each, one link between them — when the link fails, neither side has a majority, and both must stop rather than both continue. Both continuing is split-brain, and for a cluster with shared storage that means corruption.
The problem: why not just let the survivors continue
The instinct is that a node which can see its storage and its network should keep running. The reason it must not is that it cannot distinguish two situations:
- The other node has failed.
- The other node is fine and the link between us has failed.
In the second case, if both nodes continue, both write to the same volumes and the data is destroyed. Quorum is the mechanism that makes that impossible, at the cost of sometimes stopping a node that could have kept running.
Modern Windows Server clusters add dynamic quorum, which adjusts the votes as nodes leave so that a cluster can survive sequential failures down to a last surviving node, and dynamic witness, which adjusts whether the witness has a vote depending on whether the node count is odd or even. These make the behaviour considerably more forgiving than the static model — and they do not remove the need for a witness.
Configure a witness regardless of node count. The guidance is no longer “only for even numbers”, because dynamic quorum changes the effective count as nodes fail. A three-node cluster that loses a node becomes a two-node cluster with the same tie problem.
The three options
Disk witness
A small shared disk, visible to all nodes, holding a copy of the cluster database.
Where it fits. Traditional clusters with shared storage — a SAN-attached failover cluster. It is the strongest option in that context because it holds cluster configuration data as well as casting a vote, which helps recovery in some scenarios.
Where it does not. Storage Spaces Direct clusters, where it is not supported and not appropriate — there is no shared disk in the required sense. Stretched clusters across sites, where the disk sits in one site and therefore biases survival toward that site.
How it fails. The storage it lives on becomes a single point of failure for the witness. If the SAN is the thing that failed, the witness is gone at the moment you need it.
File share witness
An SMB file share on a server outside the cluster, holding a small witness file.
Where it fits. Clusters without shared storage, including Storage Spaces Direct. Multi-site clusters, where the share can be placed in a third site that does not fail with either of the two.
Where it does not. Anywhere the share would sit on a node of the cluster it witnesses — which is circular — or on infrastructure that fails with the cluster. Placing the witness share on a virtual machine running on the cluster it is witnessing is a mistake I have seen more than once, and it is entirely self-defeating.
How it fails. The file server fails, or the network path to it fails, or somebody decommissions it without knowing what it was for. The last of these is the most common, and it argues for naming the share so its purpose is obvious and recording the dependency somewhere a decommissioning process will find.
The third-site placement point deserves emphasis. For a two-site stretched cluster, a witness in either site means that losing that site loses both a node and the witness, and the surviving site may not hold a majority. A third location — which can be a small file server, or a cloud witness — is what makes a stretched cluster survive a site loss predictably.
Cloud witness
An Azure storage account used as the witness. The cluster writes a small blob and uses it as the tie-breaker.
Where it fits. Almost everywhere with internet connectivity, and particularly well for multi-site clusters and for branch clusters where there is no sensible third site. The cost is negligible — it is a tiny amount of storage and a small number of transactions.
Where it does not. Disconnected environments. Anywhere the security position genuinely prohibits outbound access to Azure storage.
How it fails. Internet connectivity fails, or the storage account key is rotated without updating the cluster, or somebody deletes the storage account during a subscription cleanup. The key rotation case is worth calling out because it is a routine security action that silently breaks the witness — the cluster keeps running and the witness is simply not there when needed.
Use a separate storage account for the witness, not one shared with workloads, so that its lifecycle and its keys are managed with awareness of what it is for. Locally redundant storage is sufficient and is the documented recommendation; the data is tiny and transient.
Comparing them
| Disk | File share | Cloud | |
|---|---|---|---|
| Shared storage required | Yes | No | No |
| Suitable for Storage Spaces Direct | No | Yes | Yes |
| Suitable for stretched clusters | Poorly | Yes, in a third site | Yes |
| Needs internet | No | No | Yes |
| Holds cluster database copy | Yes | No | No |
| Common silent failure | SAN failure | Server decommissioned | Key rotated or account deleted |
Implementation considerations
The witness needs to be independent of the failure you are protecting against. This is the single rule that decides most placements. Write down the failure you expect — a node, a rack, a site, a power domain — and confirm the witness survives it.
Validate the cluster before and after changes. Test-Cluster is the supported validation
and it checks quorum configuration among much else. Running it after a witness change takes
minutes and is the only way to confirm the configuration is supported rather than merely
accepted.
Check the current quorum state explicitly rather than assuming:
Get-ClusterQuorum
Get-ClusterNode | Select-Object Name, State, DynamicWeight, NodeWeight
Get-ClusterResource | Where-Object { $_.ResourceType -like '*Witness*' }DynamicWeight is worth reading. It tells you the vote each node currently holds under
dynamic quorum, which is frequently not what people assume after a node has been down.
Do not remove the witness to solve a problem. A cluster reporting a witness failure is telling you the witness is unavailable, which is information. Removing it makes the message go away and leaves the cluster less able to survive the next failure.
Record the witness dependency in whatever inventory your organisation actually uses for decommissioning decisions. The file share witness on a forgotten server is a recurring cause of clusters that fail at the second failure rather than the first.
Validation
The only real validation is a controlled failure test, performed before the cluster carries production load:
- Pause and drain a node, and confirm the workload moves and the cluster remains quorate.
- Simulate the loss of the witness — block access to it — and confirm the cluster continues with an even node count and reports the witness as failed.
- For a stretched cluster, simulate losing a site and confirm the surviving site holds quorum. This is the test that most often produces a surprise, and it is the one that most justifies the third-site witness.
Re-test after any change to the witness, the network or the site topology.
Verification and limits
Quorum voting, dynamic quorum and dynamic witness behaviour, the recommendation to configure a witness regardless of node count, disk witness non-support for Storage Spaces Direct, cloud witness storage account guidance and the role of a third-site witness in stretched clusters were checked against current Microsoft documentation on 20 September 2026.
No cluster was built or failed over for this article. Quorum changes affect whether a cluster
stays online: make them in a maintenance window, run Test-Cluster afterwards, and perform
failure testing before the cluster carries production workload. Quorum behaviour differs
between Windows Server versions, so confirm the specifics for your build.
References
Reader feedback
Was this article useful?
No ratings yet. Be the first to rate this article.