Fix cluster node not a member (0xC013000E) - sysadmin guide

Quick answer

Run Get-ClusterNode on a healthy node to confirm the node is evicted, then use Remove-ClusterNode and Add-ClusterNode to rejoin it. If that fails, clear the cluster database on the affected node and manually force join.

What's going on here

0xC013000E means Windows Failover Cluster kicked your node out. The node still thinks it's part of the cluster, but the cluster doesn't agree. The culprit is almost always a quorum hiccup — lost votes, split-brain recovery, or a node that went offline too long. I've seen this most often when someone power-cycles a node during a Windows Update reboot, and the cluster decides the node is dead. The node boots up, services start, but it gets the cold shoulder.

Don't bother rebuilding the cluster from scratch — that's overkill 95% of the time. The fix is straightforward: clean the node's cluster state and rejoin it cleanly.

Step-by-step fix

Check cluster node status from a healthy node. Log into any other cluster node that's still a member. Open PowerShell as Admin and run:
```
Get-ClusterNode | Format-Table Name, State
```
If the affected node shows as 'Down' or isn't listed at all, you're in the right place.
Evict the node from the cluster. From the same healthy node, run:
```
Remove-ClusterNode -Name "AffectedNodeName" -Force
```
This tells the cluster to forget the node. The -Force flag is necessary if the node shows as down.
Stop cluster services on the affected node. On the problem server, stop the cluster service:
```
Stop-Service ClusSvc
```
Also set it to disabled temporarily so it doesn't auto-start during cleanup:
```
Set-Service ClusSvc -StartupType Disabled
```
Clear the cluster database. The old cluster config is stored in the registry. Delete it:
```
Remove-Item -Path "HKLM:\Cluster" -Recurse -Force
```
Warning: This wipes ALL cluster info on this node. That's what you want. Back it up? No need — the database is replicated from the cluster quorum.

Re-enable and restart cluster service.

Set-Service ClusSvc -StartupType Automatic
Start-Service ClusSvc

Rejoin the node to the cluster. From the healthy node, add the affected node back:
```
Add-ClusterNode -Name "AffectedNodeName"
```
If it succeeds, run Get-ClusterNode to confirm it shows 'Up'.

Alternative fixes if the main one fails

Sometimes Add-ClusterNode throws an error like 'Access Denied' or 'Node already exists'. Here's what I do then.

Force join via cluster.exe (legacy but works)

On the affected node, run:

cluster.exe /force

Then from a healthy node:

cluster.exe "YourClusterName" /addnode:AffectedNodeName

This bypasses some ACL checks. Works on Server 2012 R2 and 2016.

Check quorum witness

If you can't rejoin, the cluster might have lost quorum. Check the witness:

Get-ClusterQuorum

If it's set to 'Node and File Share Majority' and the file share is unreachable, fix the share permissions or reselect a witness via Failover Cluster Manager. A cluster with no quorum won't accept new nodes.

Clear DNS and NetBIOS cache

Stale name resolution can trip up cluster communication. On all nodes, run:

ipconfig /flushdns
nbtstat -R

Then wait 30 seconds before retrying the join.

How to prevent this from happening again

Most of these evictions happen because someone rebooted a node without draining roles first. Set a strict maintenance policy: always move roles off a node before patching. Use Suspend-ClusterNode -Drain before any reboot. Also, never let a node stay offline longer than the cluster's 'node lost' timeout — default is 20 seconds for heartbeat. If you need longer maintenance windows, configure the cluster to allow it:

(Get-Cluster).CrossSubnetDelay = 1000
(Get-Cluster).CrossSubnetThreshold = 10

That gives you about 10 seconds instead of 2. Still short. For real maintenance, drain properly.

One last thing — check your cluster logs after a rejoin. Look for Event ID 1135 (lost connection) or 1146 (quorum issues). These tell you exactly why the node got evicted. Fix the root cause, not just the symptom.