STATUS_CLUSTER_JOIN_IN_PROGRESS 0XC0130003 Fix

Cause #1: Stale cluster database entries from a previous failed join

This is what you'll run into 80% of the time. You tried to add a node to a Windows Failover Cluster, something went wrong — network hiccup, reboot in the middle of the join, or a previous cluster config left behind — and now the node sits there with STATUS_CLUSTER_JOIN_IN_PROGRESS. The error code itself, 0XC0130003, means the Cluster service is actively trying to complete the join process, but it can't because the cluster database on the existing nodes already has a stale entry for this node.

The real fix: You need to force the cluster to forget that node and let it re-join cleanly. Run this on any existing cluster node (not the stuck one):

Get-ClusterNode | Where-Object {$_.State -eq 'Joining'} | Remove-ClusterNode -Force

What's actually happening here is that Get-ClusterNode lists all nodes known to the cluster. The Joining state means the cluster database has a partially added entry — the node's name exists, but the join handshake never completed. Remove-ClusterNode -Force deletes that entry without requiring the node to be reachable. Without -Force, the cmdlet would try to contact the node first, which fails because it's stuck.

After that, on the stuck node itself, restart the Cluster service and retry the join:

Restart-Service ClusSvc
Add-Computer -NewName (your cluster name) -FailoverCluster

Works on Windows Server 2016, 2019, and 2022. I've seen this on Server 2012 R2 too, but that's ancient — upgrade already.

Cause #2: The node has an existing cluster configuration from a previous cluster

Maybe this server was part of a different cluster before, and someone didn't clean it up properly. The local cluster database on the node itself contains data from the old cluster, and the new cluster rejects it because the security tokens don't match. The symptom is the same: node shows Joining forever.

How to check: On the stuck node, open an admin PowerShell and run:

Get-ClusterNode

If it returns any nodes at all, or throws an error about an existing cluster, you've got a stale config. The Cluster service is loading that old database and can't reconcile it with the new cluster's join request.

The fix: Nuke the local cluster configuration entirely. This is nuclear — it removes every trace of the cluster from this node:

Stop-Service ClusSvc
Remove-Item -Path 'C:\Windows\Cluster\CLUSTER.DB' -Force
Restart-Service ClusSvc

Yes, you're deleting the cluster database file directly. CLUSTER.DB is an Extensible Storage Engine (ESE) database — that's the same engine Exchange and Active Directory use for their databases. The Cluster service recreates it on next start with a clean slate. After restart, try the join again.

One gotcha: If you have cluster disks (CSV or witness) with data on them, deleting the local DB on one node doesn't touch the shared storage. The data survives. But the cluster name and IP assignments are gone — you'll need to re-add them after the node joins.

Cause #3: Network timing or firewall blocking the join handshake

Less common, but happens when the cluster uses a specific subnet for cluster communication and the node can't reach the other nodes on that subnet during the join phase. The Cluster service on the new node starts the join, sends a request, but gets no response — so it waits forever. The error shows up because the local service thinks it's still in the process.

What to check: Verify connectivity on the cluster network (usually a dedicated heartbeat network). Run this on the stuck node:

Test-NetConnection <existing-node-ip> -Port 3343

Port 3343 is the Cluster Service RPC endpoint. If it's blocked by Windows Firewall or a physical firewall between subnets, the join hangs. Also check that the cluster network interface has the right metric — it should be lower than the public network so cluster traffic uses it. You can see this in Get-ClusterNetwork on an existing node.

The fix: Add a firewall rule if missing — on all nodes, not just the stuck one:

New-NetFirewallRule -DisplayName 'Cluster Join' -Direction Inbound -Protocol TCP -LocalPort 3343 -Action Allow

Also allow UDP ports 3343 and 445 for cluster heartbeat. Restart the Cluster service on the stuck node after fixing the firewall, then retry the join. If you're using a VLAN or separate subnet, make sure routing is set up so the stuck node can ARP for the other nodes on that VLAN — sometimes a missing static route is the culprit.

One more thing: if none of these work, check the Cluster event log (Applications and Services Logs > Microsoft > Windows > FailoverClustering > Operational). The exact reason the join failed is logged there — it'll say something like "Node failed to join because the cluster database has a conflicting entry" or "Join request timed out." That tells you which of these three causes is the real problem.

Quick-reference summary

Start with cause #1. It's the most common by far, and the fix takes ten seconds.