Troubleshooting Windows Server Failover Cluster Issues: Quorum Loss, Heartbeat Failures, and Role Migration Errors

When a Windows Server failover cluster misbehaves, it usually fails in one of three ways. The cluster loses quorum and the Cluster service stops (Event ID 1177). A node gets dropped because heartbeats stopped arriving (Event ID 1135). Or a clustered role, like a VM or file server, refuses to move. These look alike at 2 a.m., but the causes differ, and the wrong fix can turn a recoverable outage into split-brain.

The safe order: diagnose read-only first. Restore the missing votes (nodes or witness) before you even think about forcing quorum. Treat heartbeat drops as a network problem first and leave cluster settings alone. This runbook follows that order, with a warning before every command that can make things worse.

Prerequisites

• Windows Server 2016, 2019, 2022, or 2025 with the Failover Clustering feature installed on every node. All nodes should run the same Windows Server version.
• A cluster that passed validation when it was built. Microsoft’s support policy for failover clusters requires a fully configured cluster to pass all required validation tests.
• Failover Cluster Manager (Server Manager > Tools > Failover Cluster Manager) and the FailoverClusters PowerShell module. Both install with Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools.
• An elevated PowerShell session on a cluster node, run as an account with cluster admin rights. In a domain, that’s usually a Domain Admin or a delegated cluster admin.
• Console or out-of-band access (iLO, iDRAC, IPMI, or hypervisor console) to each node. You’ll need it if the cluster network is the thing that’s broken.

Applies to: Windows Server 2016 through 2025 Failover Clustering. Checked against Microsoft Learn on November 4, 2026. Cmdlet output formats vary a bit between versions, so treat the sample outputs below as illustrative.

Windows Failover Cluster Quorum Loss Troubleshooting: Quick Reference

Use this table to triage before you scroll. Each row maps to a section below.

Symptom	Likely cause	First move (read-only)	Fix
Cluster service stopped on all nodes, Event ID 1177	Quorum lost: not enough node + witness votes	Get-ClusterQuorum, check which nodes and witness are reachable	Bring nodes or witness back; force quorum only as a last resort
Witness shows Offline/Failed, cluster still up	File share, disk, or cloud witness unreachable	Get-ClusterResource on the witness	Restore SMB path, disk, or Azure storage access
One node keeps dropping and rejoining, Event ID 1135	Missed heartbeats on the cluster network	Get-ClusterNetwork, NetworkProfile log, NIC counters	Fix NIC, switch, firewall (UDP 3343), or IPsec issues
Node won’t rejoin after repeated drops	Possible node quarantine (Windows Server 2016+)	Get-ClusterNode state	Fix root cause, then clear with Start-ClusterNode -ClearQuarantine
Cluster healthy but a VM or role won’t move	Owners, dependencies, or target-node storage/network	Get-ClusterOwnerNode, Get-ClusterResourceDependency	Fix owner list or dependency, then retry the move

Quick Diagnosis: Read-Only Checks First

The commands in this section are intended as diagnostic checks and are not expected to change cluster state in normal use. Run them first and save the output. You’ll want it for the post-incident review, and for Microsoft support if you escalate.

Step 1: Check node state

# Lists every node and its current membership state
Get-ClusterNode

Expected output on a healthy three-node cluster (columns vary by version):

Name    State Type
----    ----- ----
HV-01   Up    Node
HV-02   Up    Node
HV-03   Down  Node

Up means the node is an active member. Down means the Cluster service isn’t running there, or the node was removed from membership. Paused means an admin drained it on purpose. If the command fails with a “cluster not found” style error, the Cluster service probably isn’t running on any reachable node. Jump to the quorum section.

Step 2: Check role (group) state and ownership

# Shows each clustered role, which node owns it, and whether it's online
Get-ClusterGroup

Name               OwnerNode State
----               --------- -----
Available Storage  HV-01     Online
Cluster Group      HV-01     Online
FS-Finance         HV-02     Failed
VM-SQL01           HV-01     Online

Say a role is stuck in Failed or Pending while all nodes are Up. That points to a problem inside the role, and the cluster itself is probably fine. That split drives the rest of this runbook.

Step 3: Check the quorum configuration

# Shows the cluster name and which resource (if any) acts as the witness
Get-ClusterQuorum

Cluster  QuorumResource
-------  --------------
HVCLU01  File Share Witness

Write down the witness type. File share, disk, and cloud witnesses each fail for different reasons, covered below.

Step 4: Pull the event logs

Check two places on every node, including the ones still up:

• Windows Logs > System: Event ID 1177 (quorum lost) and Event ID 1135 (node removed from active membership) show up here.
• Applications and Services Logs > Microsoft > Windows > FailoverClustering > Operational: more detailed cluster events.

Event 1135 is logged on the surviving nodes, so start there. The node that dropped may still have related network and Cluster service events, so check its logs too.

Step 5: Generate the cluster log

The cluster log has far more detail than Event Viewer. Generate it for the incident window:

# -Destination copies each node's log to one folder on this machine
# -TimeSpan limits output to the last N minutes (here, 120)
Get-ClusterLog -Destination C:\ClusterLogs -TimeSpan 120

You’ll get one .log file per reachable node. Parameter names have been stable across recent releases, but run Get-Help Get-ClusterLog -Full on your build before you script it. Search the logs for the time of the 1135 or 1177 event. Then read the lines just before it.

Step 6: Run cluster validation (when the cluster is up)

Validation is the single most useful recurring check. In Failover Cluster Manager, select the cluster and look for a Validate Cluster (or similarly named) option.

Exact menu labels and navigation paths can vary by Windows Server version, so check your build if you don’t see this option where expected. In PowerShell:

# Runs inventory, network, and system configuration tests; skips storage
Test-Cluster -Ignore "Storage"

Warning: Depending on the tests you select and how storage is configured, storage validation can take clustered disks offline on a running cluster. During an incident, skip storage tests as shown above. Run the full suite only in a maintenance window, with roles moved or stopped as the wizard prompts.

When it finishes, click View Report. Look for yellow warnings and red failures under Network and System Configuration.

Common Issues and Solutions

Problem: Cluster Service Stopped (Event ID 1177, Quorum Lost)

Symptoms:

• Event ID 1177 in the System log
• The Cluster service is stopped on the remaining nodes and won’t stay running
• Failover Cluster Manager can’t connect to the cluster name
• Every clustered role is offline at once

Why it happens: Quorum is a vote. Each node gets a vote, and so does the witness if you have one. The cluster only runs while a majority of votes is online. When too many nodes fail at once, or the witness or the network paths between them, no group of nodes can claim a majority.

The Cluster service stops on purpose, so two halves of the cluster can’t both run the same workloads. That’s split-brain, and quorum exists to prevent it. See Microsoft’s Understanding cluster and pool quorum for the full vote math. It also covers how dynamic quorum and dynamic witness adjust votes as nodes leave.

Fix:

• Count your votes. From Step 1 and Step 3, work out how many nodes are powered on and whether the witness is reachable. In the static model, a 4-node cluster with a witness has 5 votes, and you need 3 reachable voting members. With dynamic quorum and dynamic witness (the default on current Windows Server), the cluster adjusts votes as members leave, so check the live values with Get-ClusterNode | Format-Table Name, State, NodeWeight, DynamicWeight and (Get-Cluster).WitnessDynamicWeight instead of relying on the fixed count.

• Fix the cheapest missing vote first. Usually that’s one of these:
  • A node that’s powered off, stuck in a reboot, or hung on updates
  • A witness that lost its SMB share, disk, or internet path (see the next section)
  • A switch or uplink that split the nodes into two groups that can’t see each other

• Start the Cluster service normally on a node once enough votes are back:

# Normal start — respects quorum. Safe to run.
Start-ClusterNode -Name HV-01

• Only if normal recovery is impossible, read the forced quorum section below before you do anything else. Microsoft’s recovery guidance is explicit: bringing nodes or the witness back to health is the preferred path.

Verify: Get-ClusterNode shows enough nodes Up, Get-ClusterGroup shows Cluster Group Online, and no new 1177 events appear.

Tip: Power events are the classic cause of whole-cluster quorum loss. If every node shares one power feed with no UPS, a brief outage drops them all at once. Then they race to come back with out-of-date views of each other.

Problem: Witness Is Offline (File Share vs. Cloud vs. Disk Witness)

Symptoms:

• The witness resource shows Failed or Offline under Cluster Core Resources in Failover Cluster Manager
• The cluster is still running, but losing one more node would cost you quorum
• Cluster events reference the witness resource failing to come online

Why it happens: The witness is just another vote. Each type depends on a different path:

Witness type	Depends on	Typical failure
File share witness	SMB access from every node to a share on another server	File server rebooted, share permissions changed, or the cluster computer account lost access
Disk witness	Shared storage visible to all nodes	SAN path, iSCSI session, or LUN masking problem
Cloud witness	Outbound internet access from the nodes to an Azure Storage account	Proxy or firewall change, expired or rotated storage key, DNS resolution failure

Microsoft’s docs list file share, disk, USB, and cloud as witness options. USB applies to specific cases, such as some workgroup clusters. Diagnose by testing each dependency directly.

Fix:

• Check the witness resource state:

# Shows the witness resource and its current state
Get-ClusterResource | Where-Object ResourceType -like "*Witness*"

• Test the dependency from each node:
  • File share witness: browse to the UNC path from every node. Microsoft documents the file share witness as an SMB share on a Windows Server file server, with specific permissions and dedicated-use requirements. If yours lives on a NAS or other SMB device, confirm it’s up, reachable on the cluster’s management network, and still meets those requirements.
  • Cloud witness: confirm the nodes can still reach the internet through any proxy or firewall. Check that the storage account still exists and its access keys are valid.
  • Disk witness: confirm the disk shows up in Disk Management or Get-Disk on the nodes, and that storage paths are healthy.

• Bring the witness online once the dependency is fixed:

# Replace "File Share Witness" with your actual witness resource name from Get-ClusterResource
Start-ClusterResource -Name "File Share Witness"

The exact resource name can vary by cluster configuration, so confirm it first with Get-ClusterResource rather than assuming it matches the example above.

• If the witness needs to move (new share, new storage account), right-click the cluster, choose More Actions > Configure Cluster Quorum Settings, and pick Select the quorum witness.

Verify: Get-ClusterQuorum lists the expected witness, and the witness resource shows Online.

Problem: Node Keeps Dropping Out (Event ID 1135, Heartbeat Failure)

Symptoms:

• Event ID 1135 on the surviving nodes says another node was removed from active failover cluster membership
• The affected node drops and rejoins on its own, sometimes several times a day
• VMs or roles fail over unexpectedly even though nothing crashed

Why it happens: Cluster nodes send each other UDP heartbeat packets over cluster-enabled networks. When a node misses too many in a row, its route is marked down. If no route survives, the node is removed from membership.

Microsoft’s troubleshooting article for removed nodes points almost entirely at the network: NICs, drivers, switches, firewalls, security software, and IPsec. It also notes that heartbeats use UDP port 3343.

Don’t disable IPv6 on cluster NICs as a quick “cleanup” step during troubleshooting. Cluster networking can depend on IPv6 being available, so removing it can introduce a new problem instead of fixing the one you have.

Fix:

• Confirm the firewall path. UDP 3343 must be allowed between all nodes. That includes any network security appliance between racks or sites.

• Check for network profile flapping. Open Applications and Services Logs > Microsoft > Windows > NetworkProfile > Operational. If a cluster NIC bounces between Domain and Public, a different Windows Firewall profile applies. That profile can block cluster traffic.

• Look for dropped packets. In Performance Monitor, add the counter Network Interface\Packets Received Discarded for each cluster NIC. A climbing value means the NIC or its driver is discarding traffic.

• Update NIC drivers and firmware on every node to matching versions. Mismatched drivers across nodes are worth ruling out, and validation flags them. If a specific NIC keeps failing after updates, replacing it can be faster than continuing to chase it.

• Rule out security software and IPsec. Antivirus or endpoint agents that inspect network traffic can delay heartbeats long enough to cause drops. So can IPsec policy refreshes. Check whether 1135 timestamps line up with policy refresh or scan schedules.

• Check the cluster networks themselves:

# Shows each cluster network, its role (cluster/client use), and state
Get-ClusterNetwork

# Shows each node's interface on each network and its state
Get-ClusterNetworkInterface

Any interface showing Failed or Unreachable is your lead.

Verify: No new 1135 events over at least one full business cycle, and the Packets Received Discarded counter stays flat.

Problem: Inspecting and (Carefully) Adjusting Heartbeat Thresholds

Symptoms:

• You’ve fixed obvious network faults, but brief, known latency spikes still drop nodes. Stretched clusters across sites are a common example.

Why it happens: The heartbeat timeout is delay × threshold. With the defaults below, a same-subnet node is marked down after roughly 5 seconds of silence.

Property	Default	Allowed range	What it controls
SameSubnetDelay	1000 ms	250–2000 ms	Time between heartbeats to same-subnet nodes
SameSubnetThreshold	5	3–10	Missed heartbeats before a same-subnet route is marked down
CrossSubnetDelay	1000 ms	250–4000 ms	Time between heartbeats to nodes on other subnets
CrossSubnetThreshold	5	3–10	Missed heartbeats before a cross-subnet route is marked down

Fix:

• Read the current values (read-only):

# Lists all heartbeat delay/threshold properties on the cluster object
Get-Cluster | Format-List *SubnetDelay, *SubnetThreshold

SameSubnetDelay      : 1000
CrossSubnetDelay     : 1000
SameSubnetThreshold  : 5
CrossSubnetThreshold : 5

The exact set of properties can vary by version. Some releases expose extra related properties. Compare what you see against the nodes-removed troubleshooting article.

• Change a value only after the network has been cleared:

# Raise the same-subnet threshold from 5 to 10 missed heartbeats
(Get-Cluster).SameSubnetThreshold = 10

Warning: Raising thresholds doesn’t fix anything. It makes the cluster slower to notice a node that really is dead, which delays failover. Microsoft treats this as a last resort. Record the original values so you can revert.

Verify: Re-run the Get-Cluster | Format-List command and confirm the new value. Keep watching for 1135 events.

Problem: Node Won’t Rejoin After Repeated Drops (Quarantine/Isolation)

Symptoms:

• A node that dropped several times in a short period doesn’t rejoin, even though it’s healthy now
• Get-ClusterNode shows an unusual state for that node instead of Up

Why it happens: Windows Server 2016 introduced node isolation and quarantine. A node that keeps leaving the cluster unexpectedly can be held out for a period, so it stops destabilizing the rest of the cluster. It’s a deliberate protection.

Fix:

• Fix the underlying cause first. It’s almost always the 1135 network issue above. Clearing quarantine on a node that’s still flapping just restarts the cycle.

• Identify the quarantined node. Get-ClusterNode shows it in a Down state, and the FailoverClustering Operational log records the quarantine event along with the node name and the reason it was isolated.

• Once the network or hardware fault behind the quarantine is actually fixed, clear it with the documented switch:

# Supported on Windows Server 2016 through 2025
Start-ClusterNode -Name HV-03 -ClearQuarantine

• Confirm the node rejoined and stayed up:

Get-ClusterNode -Name HV-03

Warning: Clear-ClusterNode is a different, destructive command that removes cluster configuration from a node. It is not a quarantine-clearing step and shouldn’t be used as a substitute for -ClearQuarantine. Confirm you’re running the right cmdlet before you act.

Verify: The node shows Up in Get-ClusterNode and stays up through at least one full business cycle without re-entering quarantine.

Problem: VM or Role Won’t Move, Even Though the Cluster Looks Healthy

Symptoms:

• All nodes are Up and quorum is fine, but a role fails to move or fails back to its original node
• Live migration fails partway through
• The role shows Failed or Pending in the Roles pane

Why it happens: Role moves fail for role-level reasons. Microsoft’s HA virtual machine troubleshooting guidance lists the usual suspects:

• The target node isn’t a possible owner of one of the role’s resources
• A resource dependency (disk, network name, IP address) is failing
• The target node can’t reach the role’s storage or network
• Inter-node firewall rules, an unreachable witness, lost quorum, or a corrupted cluster database (CLUSDB) are interfering

Fix:

• Check owners (read-only):

# Preferred owners for the role (group) — affects where it lands by default
Get-ClusterOwnerNode -Group "VM-SQL01"

# Possible owners for a specific resource (pipe the resource in, as in Microsoft's example)
Get-ClusterResource -Name "Virtual Machine VM-SQL01" | Get-ClusterOwnerNode

Microsoft’s Get-ClusterOwnerNode reference (Windows Server 2016 through 2025) describes the resource form as listing the nodes that can own that resource, and the group form as listing the role’s preferred owners in order. Check every resource in the role, not just the VM resource, because any of them can exclude the target node.

If the target node is missing from a resource’s possible owners, the move can’t succeed. Add it in PowerShell with Set-ClusterOwnerNode, listing every node that should be allowed:

# Replaces the possible-owner list for this resource
Get-ClusterResource -Name "Virtual Machine VM-SQL01" | Set-ClusterOwnerNode -Owners NODE1,NODE2,NODE3

Or in the GUI: right-click the resource, choose Properties, open the Advanced Policies tab, and check the node.

• Check dependencies:

# Shows what this resource depends on (e.g., a disk or CSV)
Get-ClusterResourceDependency -Resource "Virtual Machine VM-SQL01"

# Shows the state of every resource in the role
Get-ClusterGroup -Name "VM-SQL01" | Get-ClusterResource

Look for resources in Failed or Pending state, or required dependencies that aren’t Online. Some resources are offline by design, so compare against the role’s dependency chain (Get-ClusterResourceDependency) rather than treating every non-Online row as the blocker.

• Confirm target-node reachability. From the target node, make sure the role’s storage (CSV, SMB share, or LUN) is accessible. The virtual switch or client network must exist there with the same name as on the source node.

• Check the event logs on both source and target nodes for the time of the failed move.

• Retry the move. For VMs:

# Live migrates the VM role to HV-02; Live avoids downtime when it works
Move-ClusterVirtualMachineRole -Name "VM-SQL01" -Node HV-02 -MigrationType Live

For non-VM roles:

Move-ClusterGroup -Name "FS-Finance" -Node HV-02

In the GUI, right-click the role and choose Move > Select Node. See the Move-ClusterVirtualMachineRole reference for other migration types.

Verify: Get-ClusterGroup -Name "VM-SQL01" shows the new OwnerNode and Online state.

Hyper-V Replica failover between separate hosts or sites uses a different mechanism. Our Hyper-V Replica setup and failover guide covers it. DHCP failover between two DHCP servers isn’t a cluster role either, and our DHCP failover configuration and troubleshooting guide covers that one.

When Is It Safe to Force Quorum?

This is the most dangerous command in the runbook. Microsoft documents it in Recover a failover cluster without quorum. (You may see -FixQuorum in older notes. The documented parameter is -ForceQuorum.)

It’s appropriate only when all of these are true:

• You’ve confirmed the other nodes are really down. Unreachable from where you’re standing doesn’t count.
• You can’t restore enough nodes or the witness in an acceptable time
• The business impact of staying down outweighs the risk below

What goes wrong if you force it at the wrong time: Say the “missing” nodes are still running on the other side of a network split. Now you have two partitions that both think they own the workloads. That’s split-brain: two copies of a VM writing to the same storage, or two file servers claiming the same name. The configuration on the node you force can also override newer changes held elsewhere.

Warning: Destructive recovery command. Run this on one node only, after verifying the rest of the cluster is down. Don’t run it on nodes in both halves of a split.

# Overrides the quorum decision and starts the cluster on HV-01 only
Start-ClusterNode -Name HV-01 -ForceQuorum

In the GUI, the equivalent is Force Cluster Start in Failover Cluster Manager.

After the forced start, don’t bring the remaining nodes back with a plain Start-ClusterNode. Microsoft’s documented recovery procedure has you start each remaining node with quorum prevented, so it rejoins the cluster without trying to vote on quorum while the forced node is still the authoritative copy.

# Starts the node, but it won't count toward quorum until you tell it to
Start-ClusterNode -Name HV-02 -PreventQuorum

This syntax is supported on Windows Server 2016 through 2025. Run it on each remaining node, one at a time, confirming Up in Get-ClusterNode before moving to the next.

Once every node is up and you’ve fixed whatever caused the quorum loss (the dead node, the witness, the network split), the cluster can resume normal quorum operation. Stop the Cluster service cluster-wide and restart it, or reboot the nodes one at a time.

Either way, once the underlying issue is resolved, the nodes negotiate quorum normally again with no force or prevent switches involved. Confirm with Get-ClusterQuorum and Get-ClusterGroup that the cluster is healthy before you close the incident.

Error Messages Quick Reference

Event / message	Where logged	Meaning	Go to
Event ID 1177	System log, all nodes	Cluster lost quorum; Cluster service stopping	Quorum loss section
Event ID 1135	System log, surviving nodes	Another node was removed from active cluster membership	Heartbeat section
Witness resource Failed	Failover Cluster Manager, FailoverClustering Operational log	Witness dependency (share, disk, Azure) unreachable	Witness section
Role state Failed / Pending	Get-ClusterGroup, Roles pane	A resource in the role can’t come online on its owner	Role move section
NIC flips Domain ↔ Public	NetworkProfile Operational log	Firewall profile change can block cluster traffic	Heartbeat section

Platform-Specific Notes

Hyper-V clusters

VM roles add more failure points. Virtual switch names must match on every node, and the VM’s storage must be reachable from the target. If live migration fails but a quick or shutdown migration works, look at the migration network and the target’s resources first.

Workgroup (non-domain) clusters

Workgroup clusters have their own setup requirements and witness options. Microsoft covers them in Create a workgroup cluster. If a workgroup cluster loses quorum, check the witness type you chose there first.

Version differences

The cmdlet names used here work on Windows Server 2016 through 2025. Output columns and some cluster properties differ between versions. Confirm with Get-Help on your build before assuming the sample output matches.

Common Configuration Mistakes

• Even number of nodes with no witness. A 2-node or 4-node cluster without a witness is fragile. Configure a file share, disk, or cloud witness.
• Witness stored on the cluster itself. A file share witness hosted on a VM inside the same cluster fails along with the cluster. Put it on separate hardware, such as an independent Windows file server, or use a cloud witness.
• Raised heartbeat thresholds hiding a bad NIC. If someone set SameSubnetThreshold = 10 years ago, check whether the original network fault was ever fixed.
• Mismatched drivers and firmware across nodes. Validation often flags this as a warning. Don’t ignore it.
• One switch for everything. Running all cluster, storage, and client traffic through one switch creates a single point of failure. Two managed switches with redundant paths remove it.

Correct baseline check for owners, as a pattern:

# Every node that should be able to host the role appears here
Get-ClusterResource -Name "Virtual Machine VM-SQL01" | Get-ClusterOwnerNode

Getting Help

Collect this before you open a ticket or post to a forum:

• Get-ClusterLog -Destination C:\ClusterLogs -TimeSpan 120 output from all nodes
• System and FailoverClustering Operational event logs (export as .evtx)
• The most recent validation report. Failover Cluster Manager also keeps past reports, viewable from the cluster’s Actions pane.
• Output of Get-ClusterNode, Get-ClusterGroup, Get-ClusterQuorum, and Get-ClusterNetwork

Escalate to Microsoft support when you suspect CLUSDB corruption or when forced quorum didn’t restore service. Escalate too if 1135 events continue after the network has been cleared. Microsoft’s support policy expects a validated configuration, so a recent passing report will speed things up.

Useful references:

• Failover Clustering overview
• Nodes removed from active failover cluster membership
• HA virtual machine troubleshooting guidance

Prevention Tips

• Run validation on a schedule, and after every hardware, driver, or network change. Use non-storage tests during business hours and the full suite during maintenance windows.
• Monitor Event IDs 1135 and 1177 with whatever alerting you already use. A single 1135 after a known maintenance event may be benign; repeated or unexplained 1135s need investigation.
• Keep a witness on independent infrastructure with its own power and network path.
• Protect power. Put nodes, switches, and the witness host on a UPS so a short outage doesn’t take every vote down at once.
• Standardize NICs. Use the same NIC model, driver, and firmware on every node.
• Document baseline values for heartbeat properties, owner lists, and quorum config so you can spot drift fast.

Help & Answers

Frequently Asked Questions

4 questions

What does Event ID 1177 mean and what should I check first?

The cluster lost quorum and the Cluster service stopped. Check which nodes are powered on and whether the witness is reachable. Then restore the cheapest missing vote.

What does Event ID 1135 mean?

A surviving node removed another node from active membership after missed heartbeats. Treat it as a network problem first: UDP 3343, NIC drivers, firewall profiles, and IPsec or security software.

What’s the difference between a file share witness failing and a cloud witness failing?

A file share witness fails when nodes lose SMB access to the share. A cloud witness fails when nodes lose outbound access to the Azure Storage account or its keys change. The symptom looks the same in Failover Cluster Manager, but you’ll chase a different dependency for each.

Why won’t my VM move when the cluster is healthy?

Check possible owners, resource dependencies, and the target node’s access to storage and networks, in that order.

Didn't find your answer? Search our guides.

Search the site

Wrapping Up

Read before you write. Run Get-ClusterNode, Get-ClusterGroup, Get-ClusterQuorum, and the cluster log first. Sort the incident into quorum loss, heartbeat drops, or a role problem, then apply the narrowest fix.

Most “cluster” incidents turn out to be network or witness problems wearing a cluster costume. Keep -ForceQuorum in the glass case unless you’re sure the rest of the cluster is down.

Step	Action	Applies to
1	Read-only diagnostics + event logs	All incidents
2	Restore nodes or witness	Event ID 1177, witness Failed
3	Fix NIC/switch/firewall/IPsec	Event ID 1135
4	Check owners and dependencies	Role won’t move
5	Force quorum (one node, verified)	Last resort only
6	Re-run validation	After every fix

Last updated: November 4, 2026 | Applies to Windows Server Failover Clustering on Windows Server 2016, 2019, 2022, and 2025

Sources

• workgroup clusters
• Move-ClusterVirtualMachineRole reference
• Failover Clustering overview