Node Not Available (0X000013AC) on Windows Server Failover Cluster

You're managing a cluster and see 0X000013AC. It's annoying, but fixable.

This error typically hits when you try to change cluster group owner or run a PowerShell cmdlet like Move-ClusterGroup, and one node in the cluster has silently gone offline or stopped responding. The cluster service itself might be running, but that node can't participate in quorum or resource ownership.

The Direct Fix

Don't waste time rebooting everything. Here's what actually clears 0X000013AC:

1. Open Failover Cluster Manager on any available node.
2. Right-click the cluster name in the left pane → More Actions → Force Quorum.
3. Select the Node and Disk Majority option if you have a witness disk, or Node Majority if you don't.
4. Confirm the forced quorum. Then right-click the cluster name → More Actions → Submit Cluster Configuration.
5. If the problematic node still shows as unavailable, right-click it → Pause → Resume. That forces the cluster service to re-establish connectivity.

If that fails, you'll need to evict the node. Run this in PowerShell as admin on an active node:

Remove-ClusterNode -Name OfflineNodeName -Force

Then add it back after verifying its network and storage paths are clean.

Why Forcing Quorum Works

The cluster service uses quorum to decide which nodes are allowed to run resources. When a node goes silent, the cluster marks it as not available for operations that involve resource ownership changes. But the cluster's internal state sometimes hangs onto stale node references. Forcing quorum tells every node: recalculate who's alive right now. It clears the stale node reference, and the operation can proceed.

The reason step 3 (Node and Disk Majority) is key: if the witness disk is reachable but the node isn't, the cluster can still form quorum without that node. Without forcing quorum, the cluster might be stuck in a state where it thinks it needs that node's vote, but the node isn't responding — classic catch-22.

When the Fix Doesn't Stick

Sometimes the error returns because the root cause is a transient network drop or a storage path issue. Run this to check connectivity:

Test-Cluster -Node OfflineNodeName

If that shows Network connectivity or Storage connectivity failures, you've got a hardware or driver problem. Common real-world triggers:

• NIC teaming misconfiguration on one node (e.g., different MTU settings).
• iSCSI initiator losing path to the witness disk for 10 seconds.
• Windows Update reboot that didn't complete before the cluster service started.

Less Common Variations

If you see 0X000013AC during a live migration of a VM within a cluster, the issue might be the Hyper-V host's vmms.exe process hanging on the target node. In that case, restart the Hyper-V Virtual Machine Management service on the target node, then retry the migration. Don't force quorum — that's overkill for a single VM failure.

Another rare variant: the error appears when using Get-ClusterResource from a node that's in Isolated state (due to network partition). Check Get-ClusterNode | fl — if you see State: Isolated, you need to fix the network path between nodes, not the cluster quorum.

Prevention

Stop it from happening again:

• Set a cluster heartbeat timeout of at least 2000 ms (default is 1000 ms). Use:

  (Get-Cluster).HeartbeatTimeout = 2000

• Enable Cluster Logging at verbose level on all nodes: (Get-Cluster).LogLevel = 5. Then if it happens again, check %SystemRoot%\Cluster\Reports\Cluster.log for NodeNotAvailable entries — they'll show exactly which node dropped and why.
• Run Test-Cluster monthly to catch silent disk or network failures before they cause quorum issues.
• If you're on Windows Server 2019 or 2022, install the latest Cumulative Update — there was a bug in KB5008218 that caused phantom node availability issues on some hyper-converged clusters.