You'll see error 0XC0130001 when a Windows Server Failover Cluster (WSFC) node tries to join a cluster or when you try to bring a cluster resource online, and the operation fails with "The cluster node is not valid." This usually happens after you've forcefully removed a node from the cluster, rebuilt the node's OS, or restored a cluster from backup where the node's GUID no longer matches what's in the cluster database.
For example, you've got a two-node cluster running SQL Server on Windows Server 2019. Node2 crashes hard, you reinstall the OS with the same name, try to add it back to the cluster, and bam — you get 0XC0000131. Or you run Get-ClusterNode and see a node listed as "Down" but you can't evict it because the cluster thinks the node ID is stale.
What's actually going on
Each cluster node has a unique GUID stored in the cluster database. That GUID is tied to the node's machine account and its installation. When you reinstall the OS or restore the node from a snapshot, the GUID changes. But the cluster database still holds the old GUID. So when the node tries to talk to the cluster, the cluster checks the node ID and says "I don't recognize this node — it's invalid."
The real fix is to remove the stale node entry from the cluster database, then re-add the node fresh. You don't need to rebuild the whole cluster unless the database is corrupted beyond repair.
Fix it in 6 steps
- Confirm which node is causing the problem. On an active node, open PowerShell as Administrator and run:
Look for a node that's "Down" or shows a state of "Not Joined". Note its name.Get-ClusterNode - Force remove the bad node from the cluster. On the active node, run:
ReplaceRemove-ClusterNode -Name OldNodeName -ForceOldNodeNamewith the actual node name. This drops the node entry from the cluster database. If the command fails with a "node not found" error, that means the entry is already gone, and you can skip to step 4. - Validate the removal. Run
Get-ClusterNodeagain. The node should no longer appear in the list. If it still shows up, you'll need to use the cluster utility: - If the node won't leave, use cluster.exe. Run:
This clears the node's local cluster registry hive. After that, restart the node you're trying to fix.cluster.exe node OldNodeName /forcecleanup - Re-add the node. On the node you want to add, open PowerShell as Administrator and run:
ReplaceAdd-ClusterNode -Name YourNodeName -Cluster YourClusterNameYourNodeNamewith the node's computer name andYourClusterNamewith the cluster's name. If the node has leftover cluster state from the old install, you might need to runcluster.exe /forcecleanuplocally first. - Verify the node is healthy. Back on the active node, run:
The re-added node should show "Up" and "Healthy".Get-ClusterNode | Format-Table Name, State, Status
After you re-add the node, you can bring any cluster resources online that were stuck. If you're running SQL Server FCI, you might need to run the SQL Server setup repair to update the cluster resource's dependencies.
Still failing? Check these three things
- Cluster service account permissions. The node's machine account must have "Create Computer Objects" permissions in Active Directory. If the cluster is running under a virtual account, you might need to pre-stage the machine account.
- Firewall rules. Ensure that the Windows Firewall rules for Failover Clustering are enabled on both nodes. Run
Get-NetFirewallRule -DisplayGroup 'Failover Clustering'to see if they're enabled. - DNS registration. The node's hostname must resolve to its IP address from all cluster nodes. Run
nslookup NodeNameand check that the returned IP matches the node's actual IP. If not, update DNS or the hosts file.
If you still get 0XC0000131 after all that, the cluster database might be corrupted. In that case, back up your cluster configuration, destroy the cluster on all nodes, and rebuild it. On a two-node cluster, that's faster than trying to piece together the old database.