Event ID 1570, 1135

Storage Cluster Quorum Loss – Fixing the 3 Most Common Causes

Hardware – Hard Drives Intermediate 👁 8 views 📅 Jun 14, 2026

Quorum loss brings your cluster down. Most times it's a bad disk witness, a timeout, or a network split. Here's how to get back up fast.

1. Bad Disk Witness – The Most Common Culprit

Nine times out of ten, quorum loss hits because the disk witness goes offline. I had a client last month whose entire Hyper-V cluster died because the SAN LUN mapped to the witness just disappeared. The cluster service logged Event ID 1570: no quorum.

The fix: Check the witness disk first. On any node, open Failover Cluster Manager, right-click the cluster name, go to More Actions > Configure Cluster Quorum Settings. If the disk witness shows as "Online (Failed)" or missing, you've found it.

Run this PowerShell to confirm:

Get-ClusterQuorum

If the witness is a disk and shows as unavailable, try bringing it online manually from Disk Management. But don't waste time here – if the disk is truly dead (controller failure, bad LUN mapping), you need to switch to a file share witness or remove the witness temporarily.

Quick workaround: Force quorum on one node with this command (run on the node you trust):

Start-ClusterNode -ForceQuorum

Then change the quorum to a file share witness right after. On a small cluster (2 nodes), a file share witness on a NAS works fine. Don't bother with a third node just for quorum – that's overkill.

2. Network Timeouts – The Silent Killer

Second most common: node-to-node heartbeats drop because of network congestion, bad switches, or misconfigured VLANs. The cluster evicts a node, you lose quorum. Event ID 1135 shows up with the classic: “The Cluster service on node X failed to respond to a notification.”

I've seen this on clusters using a single network for both heartbeat and storage traffic. That's a design failure. The fix here is two parts:

Part A – Tweak the heartbeat timeout

Open Registry on each node:

HKLM\System\CurrentControlSet\Services\ClusSvc\Parameters

Look for SameSubnetThreshold (default 5). Increase it to 10. This gives the cluster more missed heartbeats before it kicks a node. Also set CrossSubnetThreshold to 10 if you have multi-subnet nodes.

Restart the cluster service on each node after:

Stop-Service clussvc -Force; Start-Service clussvc

Part B – Fix the network

You can't tune your way out of a bad switch. Run cluster validation test:

Test-Cluster -Node Node1,Node2

Look for warnings on network connectivity. If you see packet loss above 1%, replace the switch or at least dedicate a separate VLAN for heartbeat traffic. I've had clients avoid a full SAN upgrade just by isolating heartbeat on its own subnet.

3. Node Split – When the Cluster Can't Decide

Last scenario: Both nodes are up, they can see the witness, but they can't agree on who owns it. Usually happens after a misconfigured NIC teaming (yes, I've fixed two of those this year alone). The cluster enters a split-brain state, both nodes claim ownership, and the service stops.

You'll see Event ID 1135 from both nodes referencing each other. The witness disk shows as online on both, but the cluster fails to form.

The fix: First, stop both nodes' cluster services:

Stop-Service clussvc

Then on the node you want to win, start the cluster with quorum forced:

Start-ClusterNode -ForceQuorum

On the other node, just start normally:

Start-ClusterNode

That forced the cluster to form on Node1, and Node2 will join after. Once both are up, run validation to find the NIC teaming issue:

Test-Cluster -Node Node1,Node2 -Ignore Network

Actually, don't ignore the network – run it full. Look for the report on NIC teaming modes. Switch from Switch Independent to Switch Dependent if you can. If you're stuck with cheap switches, disable teaming entirely and use a single NIC per heartbeat network. It's ugly but stable.

One more thing: After split-brain, always check the cluster databases are in sync. Run this on both nodes:

Get-ClusterResource | Format-Table Name, State, OwnerNode

If resources show different owners, you've got corruption. Restore from the last good backup.

Quick-Reference Summary Table

CauseEvent IDFix
Bad disk witness1570Move to file share witness or force quorum on one node
Network timeouts1135Increase heartbeat threshold in registry, fix switch or VLAN
Node split (split-brain)1135 (both sides)Force quorum on one node, fix NIC teaming, restore DB if corrupt

These three fixes cover about 80% of quorum loss calls I get. Start with the witness, then check the network, then deal with split-brain. Don't overthink it.

Was this solution helpful?