0XC0130002

STATUS_CLUSTER_NODE_EXISTS (0XC0130002): Node join fails on existing name

Server & Cloud Intermediate 👁 0 views 📅 May 26, 2026

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=Servers container under the cluster's computer object in AD. If that container has a reference to your node, the join fails.
  • Local registry: HKLM\Cluster\Nodes and HKLM\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.

  1. Evict the node from the cluster (if possible). On a working cluster node, open PowerShell as admin and run:
    Remove-ClusterNode -Name "OffendingNodeName" -Force
    If the cluster itself is gone, skip this — do step 2.
  2. Clean the node's local registry. On the problematic node, stop the cluster service:
    Stop-Service ClusSvc -Force
    Then delete these two registry keys:
    Remove-Item -Path "HKLM:\Cluster\Nodes" -Recurse -Force -ErrorAction SilentlyContinue
    Remove-Item -Path "HKLM:\Cluster\Bootstrap" -Recurse -Force -ErrorAction SilentlyContinue
    Don't touch HKLM:\Cluster itself — that's the cluster hive root. Just the child keys.
  3. 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.
  4. Verify cleanup. On the node, run:
    Get-ClusterNode -Cluster "YourClusterName"
    You should NOT see the node listed. Also check the registry paths from step 2 are gone.
  5. Join the node. On a cluster node (not the problematic one), run:
    Add-ClusterNode -Name "OffendingNodeName"
    If you're creating a new cluster from scratch, use New-Cluster and 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-ClusterNode needs Create Computer Objects and Write All Properties on 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?