Fix ERROR_CLUSTER_NODE_ALREADY_MEMBER (0x000013C9) Fast

The 30-Second Fix: Check if the Node Is Actually Active

Before you dive into anything heavy, confirm the node you're trying to join isn't already registered elsewhere.

Run this from an elevated PowerShell on any cluster node:

Get-ClusterNode

If you see the node listed with State = Up or Down, then it's already a member. Had a client last month who panicked over this error on a Windows Server 2022 box, only to find the node was still listed from a previous rebuild. All they needed to do was run:

Remove-ClusterNode -Name [NodeName]

That evicts it clean. Then try re-joining from the node's own PowerShell with:

Add-Computer -NewName [NewName] # only if it was renamed
Restart-Computer
Add-ClusterNode -Cluster [ClusterName]

If the node isn't listed in Get-ClusterNode, move to the moderate fix.

The 5-Minute Fix: Force Clear Local Cluster State

This error often shows when a node was rebuilt or restored from an image without clearing its cluster state. The node thinks it still belongs, even though the cluster doesn't know it. I've seen this trip up Hyper-V clusters after a bare-metal restore.

On the problematic node, as Administrator:

1. Open an elevated CMD or PowerShell.
2. Stop the cluster service: Stop-Service clussvc
3. Delete the cluster database: Remove-Item -Path "C:\Windows\Cluster\cluster.db" -Force
4. Also clear any stale quorum config: Remove-Item -Path "C:\Windows\Cluster\\." -Force -Recurse
5. Set the service start type back to automatic: Set-Service clussvc -StartupType Automatic
6. Restart the server: Restart-Computer

After reboot, re-join the cluster:

Add-ClusterNode -Cluster [ClusterName]

This deletes all local cluster knowledge, forcing a fresh join. Works 90% of the time for 0x000013C9. If it still fails, move on.

The 15+ Minute Fix: Force Evict Using Cluster Quorum

Sometimes the cluster itself holds a stale reference to the node that won't clear via normal eviction. This is especially common in multi-node clusters with witness configurations. The trick: force the remaining nodes to form quorum, then evict the zombie node.

Steps:

1. On a surviving cluster node, check the cluster membership: Get-ClusterNode. Note the name of the problem node.
2. If the problem node is the only one holding the quorum vote (e.g., on a 2-node cluster without witness), you'll need to force quorum:

Stop-Service clussvc
Start-Service clussvc -ForceQuorum
Get-ClusterNode

3. Now evict the bad node: Remove-ClusterNode -Name [BadNodeName] -Force
4. After eviction, restart the cluster service normally: Stop-Service clussvc; Start-Service clussvc
5. On the problem node itself, run the 5-minute fix steps above (clear local cluster state) and reboot.
6. Finally, re-join the cluster from the rebooted node.

If the node stubbornly refuses to even get removed from the cluster, you can use the GUI in Failover Cluster Manager – right-click the node and select Evict. But I've found the PowerShell -Force switch is more reliable when the error is sticky.

Real-world tip: Last year I had a cluster running SQL Server 2019 on Windows Server 2016 where a node was rebuilt but the old node name was still in AD DNS. The cluster kept fighting the new node identity. Cleaning the DNS record for the old node name fixed the 0x000013C9 after the eviction. So check your DNS entries for the node name if the above doesn't work.

Prevention: Don't Rebuild Without Evicting First

The root cause here is almost always rebuilding or restoring a cluster node without evicting it from the cluster first. The cluster databases on both sides get out of sync. If you're planning to rebuild a node, always run Remove-ClusterNode before nuking the OS. Saves you this headache every time.

If you're in a hurry and can't evict before rebuild (e.g., node died hard), you now have the playbook. Start with the 30-second check, escalate as needed. You won't need to go past the 5-minute fix in 9 out of 10 cases.