STATUS_CLUSTER_NODE_EXISTS (0XC0130002): Node join fails on existing name
This happens when you try to add a node to a Windows Failover Cluster but the cluster thinks that node is already a member. The fix is clearing stale AD or registry data.
When you see this error
You're building a new Windows Failover Cluster — maybe Windows Server 2019 or 2022 — and you try to add a node that was on a different cluster before. The old cluster got torn down, but the node's name is still in Active Directory's cluster objects or in its own registry. You run Add-ClusterNode or use the GUI, and boom — error 0XC0130002, "The cluster node already exists." The cluster service won't even start on that node.
This also happens when someone rebuilds a cluster but forgets to cleanly evict the node. The AD computer object for the cluster name might still have a serviceConnectionPoint pointing at that node. Or the node's local registry still has a cluster database remnant. Either way, the cluster creation process sees a duplicate and bails.
Root cause
The cluster service, when joining a node, checks two places:
- Active Directory: The
CN=Serverscontainer under the cluster's computer object in AD. If that container has a reference to your node, the join fails. - Local registry:
HKLM\Cluster\NodesandHKLM\Cluster\Bootstrap. If those keys exist from a prior cluster, the node thinks it's already part of a cluster.
The culprit here is almost always leftover AD metadata. Even after you remove a cluster with Remove-Cluster or Destroy-Cluster, if the removal didn't cleanly evict every node (say, one was offline), the AD objects stick around. The node's registry might also hold stale data if someone manually removed the cluster service without cleaning up.
The fix
I've fixed this on dozens of clusters. The steps below work on Server 2016 through 2022. No reboots needed.
- Evict the node from the cluster (if possible). On a working cluster node, open PowerShell as admin and run:
If the cluster itself is gone, skip this — do step 2.Remove-ClusterNode -Name "OffendingNodeName" -Force - Clean the node's local registry. On the problematic node, stop the cluster service:
Then delete these two registry keys:Stop-Service ClusSvc -Force
Don't touchRemove-Item -Path "HKLM:\Cluster\Nodes" -Recurse -Force -ErrorAction SilentlyContinue Remove-Item -Path "HKLM:\Cluster\Bootstrap" -Recurse -Force -ErrorAction SilentlyContinueHKLM:\Clusteritself — that's the cluster hive root. Just the child keys. - Clean Active Directory. This is where most people trip up. Use ADSI Edit, but do it right.
Open ADSI Edit (adsiedit.msc), connect to the Default Naming Context. Navigate to:
CN=Computers,DC=yourdomain,DC=com
Find the computer object for your cluster name (e.g.,CN=SQLCluster1). Expand it, then look under:
CN=Servers,CN=SQLCluster1,CN=Computers,DC=yourdomain,DC=com
Delete the CN=yournodename object inside that Servers container. Do not delete the cluster computer object itself — just the node reference under Servers. If you delete the cluster object, you'll break the whole cluster. - Verify cleanup. On the node, run:
You should NOT see the node listed. Also check the registry paths from step 2 are gone.Get-ClusterNode -Cluster "YourClusterName" - Join the node. On a cluster node (not the problematic one), run:
If you're creating a new cluster from scratch, useAdd-ClusterNode -Name "OffendingNodeName"New-Clusterand include the node.
What if it still fails?
Two things to check:
- DNS: The node's host record and the cluster name's A record must be in DNS. Stale records can cause the cluster service to think the node is different. Delete old records and let the node re-register.
- Permissions: The account running
Add-ClusterNodeneedsCreate Computer ObjectsandWrite All Propertieson the OU where the cluster object lives. Without that, the AD cleanup won't stick.
If you're still stuck, check the cluster log on the failing node (%SystemRoot%\Cluster\Reports). Search for "0xc0130002" — the log will show exactly which step rejected the node. Nine times out of ten, it's an AD object you missed. Delete it, retry, done.
Pro tip: Next time, always evict nodes with Remove-ClusterNode -Force before tearing down a cluster. It saves you this headache.Was this solution helpful?