Fix ERROR_ALL_NODES_NOT_AVAILABLE (0X000013AD) Fast

What Triggers This Error

You're getting 0X000013AD when trying to manage a failover cluster — maybe moving a role, changing quorum, or running a PowerShell cmdlet. The cluster sees at least one node as unreachable or down, and won't let you proceed. I know that spinning cursor and “operation failed” message is frustrating. Let's get those nodes talking again.

Quick Fixes (Under 30 Seconds)

Start here. Sometimes the fix is silly-simple.

1. Check node visibility — Open Failover Cluster Manager. Look at the Nodes pane. Any node showing a red X or “Down”? If yes, that's your culprit. Try right-clicking it and selecting “Start” or “Resume”.
2. Run a quick ping — From a healthy cluster node, open Command Prompt and run ping -n 1 [other-node-IP]. If it times out or returns unreachable, you've got a network problem (jump to moderate fix).
3. Restart cluster service — On the node that's showing Down, run net stop clussvc && net start clussvc as Administrator. Wait 30 seconds, then refresh Failover Cluster Manager.

If the node comes back, you're done. If not, move on.

Moderate Fix (5 Minutes)

This tripped me up the first time too — the cluster service is running but the nodes can't agree on who's alive.

Step 1: Validate Node-to-Node Communication

1. On each node, open Windows Firewall with Advanced Security.
2. Make sure inbound rules for “Failover Cluster” (TCP 3343, UDP 3343) and “Cluster Service” are enabled. If you're using a custom port, check that too.
3. Check network adapters — if nodes are on different subnets, cluster communication might be blocked. Use ipconfig /all to verify IPs.

Step 2: Check Quorum Configuration

1. In Failover Cluster Manager, right-click your cluster > More Actions > Configure Cluster Quorum Settings.
2. Pick “Use default quorum configuration”. If that doesn't work, choose “Use quorum witness” and add a file share witness or cloud witness.
3. Apply the change. The cluster will recalculate quorum votes and may bring nodes back.

If the error persists after these, it's time for logs and hardware checks.

Advanced Fix (15+ Minutes)

You've done the quick stuff. Now we're hunting down the root cause. I've seen this error most often after a network partition or a node reboot gone wrong.

Step 1: Analyze Cluster Logs

1. On the node that's reported as unavailable, open Event Viewer > Applications and Services Logs > Microsoft > Windows > FailoverClustering > Operational.
2. Look for events with ID 1069 (cluster resource failure) or 1135 (cluster node lost communication). These tell you exactly which node dropped and why.
3. Also check the System log for network card resets or storage timeouts.

Step 2: Force Node Eviction and Rejoin

1. If a node is stuck in Down state and won't come back, you may need to evict it. From a healthy node, open PowerShell as Administrator and run:

   Get-ClusterNode [NodeName] | Remove-ClusterNode -Force

2. Wait for the eviction to complete, then physically restart the problematic node.
3. Once it boots, rejoin the cluster with:

   Add-ClusterNode -Name [NodeName] -Cluster [ClusterName]

4. Run Get-ClusterNode to confirm all nodes show “Up”.

Step 3: Validate Full Cluster Health

1. Run a validation report on the entire cluster: In Failover Cluster Manager > right-click cluster > Validate Cluster > Run All Tests. This can take 10+ minutes. It tests network, storage, and quorum.
2. Look for any red “Failed” results. The most common culprits: network latency over 500ms, mismatched time between nodes (check w32tm /query /status), or stale DNS records.
3. Fix any issues found, then try your original operation again.

Preventing This Next Time

Once you're back online, set up regular cluster health monitoring. Schedule a weekly validation report. Configure alerts for node status changes. And always — always — patch nodes one at a time with staggered reboots. A cluster where all nodes reboot together is a cluster that throws this error.

You're not alone in hitting this wall. I've seen 0X000013AD on Windows Server 2016 through 2022. It's common after a network reconfig or a misconfigured firewall rule. Stick with the quick fix first; you'll probably solve it there.