Fix ERROR_CLUSTER_NODE_EXISTS 0X000013B0 in Cluster Setup

When this error smacks you in the face

You're trying to add a second or third node to your Windows Failover Cluster — maybe on Server 2019 or 2022. The cluster validation passes, you click 'Add Node', and then boom: the wizard spits back ERROR_CLUSTER_NODE_EXISTS (0X000013B0). The server you're adding was part of this cluster before, but was removed improperly, or the cluster database still holds a ghost record of it.

I've seen this most often after a node was evicted using Remove-ClusterNode without the -Force flag, or when someone wiped a server and tried to rejoin it without cleaning the cluster's memory first.

Root cause in plain English

The cluster keeps a database of all nodes it has ever known, even after they're removed. 0X000013B0 means: 'That node name is already in my records, so I refuse to add it again.' It's a safety check — Windows doesn't want duplicate identities in the cluster quorum.

The fix is to tell the cluster to forget that node, then add the server fresh. But the normal 'Remove Node' option may already be grayed out, because the node isn't active. So you'll need the surgical approach.

The real fix: clean the node from the cluster database

Skip the GUI for this part — it'll only frustrate you. Open PowerShell as Administrator on the cluster's active node (the one already joined).

Identify the problem node
Run Get-ClusterNode. You'll see the node that's causing the error — likely with a state of 'Down' or 'Not a member'.
Evict the node forcefully
Run:
```
Remove-ClusterNode -Name "YourProblemNodeName" -Force
```
The -Force flag tells the cluster to remove everything — the database entry, the quorum vote, the whole record. Without it, the command often fails if the node isn't online.
Verify it's gone
Run Get-ClusterNode again. The problem node should no longer appear.
Clean up DNS and AD (if needed)
Sometimes the old computer account or DNS record lingers. On a Domain Controller, delete the computer object for that server (if it's a cluster-only account). Also flush the cluster's DNS cache with Clear-DnsServerCache on the DNS server if the node name is still resolving.
Add the node back
From the working node, run:
```
Add-ClusterNode -Name "YourProblemNodeName"
```
This should now work without the 0X000013B0.

What if the cluster itself is broken?

In rare cases, the cluster database is corrupted or won't let you evict the node. If Remove-ClusterNode -Force still throws errors, you can try:

Evict from the other nodes — Run the same command on a different active cluster node. Sometimes the failing node holds a lock.
Use the GUI as a last resort — Open Failover Cluster Manager, right-click the node, choose 'More Actions' -> 'Evict'. This does the same thing as -Force but via the UI.
Check cluster logs — Look in %SystemRoot%\Cluster\Reports for any detailed error messages that might point to a deeper permission issue.

If none of that works, you may need to rebuild the cluster entirely. But 95% of the time, a clean eviction and re-add solves it.

What to check if it still fails

Network name collision — Make sure the server's hostname isn't already in use by another device on the network. Try pinging the hostname and see if it resolves to an unexpected IP.
Stale cluster objects in AD — Look in Active Directory Users and Computers under the Computers container for a disabled computer account matching the node name. Delete it.
Windows Firewall rules — Ensure the cluster ports are open between nodes (defaults: UDP 3343, TCP 445, plus ICMP for validation).
Test the node's cluster service — On the problematic node, run Get-Service ClusSvc. If it's running, stop it with Stop-Service ClusSvc before adding the node.

I've seen this error trip up even seasoned sysadmins. But now you've got the playbook. Go get that node joined.