Choose the authoritative node before forced-quorum recovery

Source facts

Microsoft first directs administrators to investigate the quorum configuration and the reason the cluster lost sufficient votes. When healthy nodes or the witness cannot restore quorum, force-starting overrides the normal quorum configuration. After one node is force-started, Microsoft directs remaining nodes to start with quorum prevented so they join the running cluster instead of forming a competing instance. Microsoft Learn.

Applicability

Confirm which nodes and sites are reachable and who controls the recovery operation. Distinguish an ordinary unavailable witness from a situation requiring forced recovery. Use the documented procedure only after the responsible cluster administrator establishes the intended authoritative instance.

DSE recommendation

Prepare a recovery worksheet naming the selected node, unavailable components, data-state assessment, and personnel controlling the remaining nodes. Require a shared decision before executing force-start actions. Keep the planned sequence visible to every operator involved, and explicitly assign responsibility for preventing a second competing instance. Retain the original quorum observations and the reason ordinary restoration was not possible.

Verification

After the approved recovery sequence, verify cluster membership, workload ownership, and application data with the service owner. Confirm that returning nodes join the intended instance. Record every deviation and stop if competing ownership or unexplained state appears. Complete a follow-up review of the quorum failure rather than treating service startup as the entire recovery.

Official references

Microsoft Learn: Recover a failover cluster without quorum in Windows Server. Source reviewed September 8, 2026.