# Place a failover-cluster witness outside the failure domain it must arbitrate > A quorum witness is a deciding vote, not a decorative cluster setting. Select cloud, disk, or file share from the topology; isolate its dependencies from the failures it must resolve; validate access from every node; and retest after cluster or site changes. - Canonical URL: https://update.dsesecurity.com/updates/failover-cluster-witness-failure-domain-design/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Gavin Stewart - Published: 2026-08-11T10:44:00+00:00 - Modified: 2026-08-11T15:18:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Guide - DSE priority: Important - Topics: Business Continuity, IT - Reading time: 3 minutes ## What you need to know A quorum witness is a deciding vote, not a decorative cluster setting. Select cloud, disk, or file share from the topology; isolate its dependencies from the failures it must resolve; validate access from every node; and retest after cluster or site changes. ## Potentially affected Windows Server failover clusters and Azure Local; cluster nodes and votes; cloud, disk, and file share witnesses; Azure Storage, SMB, Active Directory, networks, storage, credentials, monitoring, and multisite recovery designs. ## DSE recommendation Map simultaneous failure scenarios and votes, inspect the current quorum configuration, choose a supported witness outside correlated failure paths, validate it from every node, monitor its dependencies, and rerun cluster validation after material change. ## Article ## Source facts: the witness supplies a vote, not another workload copy Microsoft defines a [failover-cluster quorum witness](https://learn.microsoft.com/en-us/windows-server/failover-clustering/what-is-quorum-witness) as a component that participates in quorum voting. A running cluster needs more than half of its active votes. If it cannot maintain that majority, it stops cluster operations to avoid separate partitions acting as the active cluster and risking inconsistent or corrupt data. Windows Server supports cloud, disk, and file share witnesses. A cloud witness uses Azure Blob Storage for its arbitration blob. A disk witness uses shared storage accessible to the nodes and contains cluster configuration information, not application data. A file share witness uses an SMB share and maintains cluster information in a log file. Microsoft recommends a witness for Windows Server 2012 R2 and later; current clustering versions dynamically manage witness and node votes. The witness type must fit the topology. Microsoft’s deployment guidance requires a file share dedicated to one cluster and physically separate from the cluster nodes or sites where practical, including consideration of network, power, rack, and room. It warns that DFS and replicated storage technologies are not supported for a file share witness because partitions in space or time can permit nodes to operate independently and risk data loss. Dynamic quorum can adjust node votes as nodes fail or shut down sequentially, but Microsoft states that it does not let a cluster survive the simultaneous failure of most voting members. Microsoft recommends reviewing quorum after cluster creation, using Validate Quorum Configuration or Test-Cluster, and avoiding production changes unless the topology and requirement have been evaluated. ## DSE recommendation: design for the partition, then operate every dependency Start with the failures the service must survive, not with an assumed preference for cloud, disk, or file share. Draw node, site, network, power, storage, directory, internet, and Azure dependencies on one page and calculate which votes remain together in each credible event. - Capture the current state. Record nodes, sites, node votes and dynamic weights, quorum mode, witness type and location, resource name, network path, account or key ownership, monitoring, last validation, application owners, and the cluster’s approved failure assumptions. - Model simultaneous loss. Test the vote outcome for a node failure, site isolation, WAN failure, shared-storage outage, directory or DNS issue, loss of internet or Azure access, maintenance shutdown, and the witness host or credential becoming unavailable. Sequential shutdown behavior is not proof against a simultaneous partition. - Select an independent witness. Place the deciding vote where it remains reachable by the side intended to continue. Do not host a file share witness on a cluster node it is meant to arbitrate or behind the same single power, switching, storage, or site dependency without recording that limitation. - Implement the documented requirements. For cloud witness, control the supported Azure Storage account, HTTPS path, access key, rotation, cost and ownership. For disk witness, dedicate supported shared storage. For file share witness, dedicate an SMB 2-or-later share with the documented permissions and no user or application data. - Validate and observe. Run supported cluster validation, confirm witness access from every node, review cluster events, and alert on a failed witness or long-lived loss of access. Record the quorum state before and after maintenance rather than inferring it from application availability. - Retest after change. Recalculate and validate after adding or evicting nodes, changing sites or storage, replacing a witness, rotating credentials, altering firewalls or proxies, or sustaining a long witness failure. Exercise controlled failure scenarios with workload owners and a stop condition. Document what remained online, where the deciding vote was reachable, how the cluster reacted, and how normal topology was restored. The right witness is not the option that produces an odd number on a diagram; it is a maintained, supported vote that makes the intended partition win under the organization’s actual failure domains. ## Official references - Microsoft Learn, [What is a quorum witness?](https://learn.microsoft.com/en-us/windows-server/failover-clustering/what-is-quorum-witness), March 28, 2025. - Microsoft Learn, [Deploy a quorum witness](https://learn.microsoft.com/en-us/windows-server/failover-clustering/deploy-quorum-witness). ## Primary reference - Name: Microsoft Learn: What is a quorum witness - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/failover-clustering/what-is-quorum-witness - Source publication date: 2025-03-28 ## Citation and use Preferred citation: “Place a failover-cluster witness outside the failure domain it must arbitrate,” DSE Security, https://update.dsesecurity.com/updates/failover-cluster-witness-failure-domain-design/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.