Fix 0XC013000F: Cluster join not in progress error on Windows Server
This error means the cluster service thinks no join operation is running. The fix is to restart the cluster service or force a cleanup. It's common after failed node additions.
You're staring at 0XC013000F after trying to add a node to a Windows Server failover cluster. I know the feeling—everything looked right, you ran the join wizard, and bam, that error. Let me save you the headache.
Restart the cluster service on the joining node
This is the fix that works 80% of the time. On the node that's failing to join, open PowerShell as admin and run:
Stop-Service ClusSvc
Start-Service ClusSvcThen try the join again. I had a client last month whose entire print queue died because they didn't restart the service after a failed join attempt. Don't skip this.
Force cleanup of the failed join state
If restarting doesn't work, the cluster service likely has a stale join operation stuck. You need to manually clean it up. On the joining node, run:
Get-ClusterNode | Where-Object {$_.State -eq 'Joining'} | Remove-ClusterNode -ForceThen restart the cluster service again:
Restart-Service ClusSvcRetry the join. This clears out any half-finished join attempts that the service thinks are still in progress.
Why this works
The error 0XC013000F translates to STATUS_CLUSTER_JOIN_NOT_IN_PROGRESS. It means the cluster service on the joining node doesn't see an active join operation—either because the previous one crashed, or because the service state got corrupted. Restarting the service flushes that state. Removing the stuck node entry forces a clean slate. Without this, the service keeps waiting for a nonexistent operation and rejects new ones.
Less common variations
DNS or network issue masking the join
Sometimes the real problem is that DNS resolution fails silently. The cluster service can't find the existing cluster, so it never starts a join. Check the joining node can resolve the cluster name:
nslookup [cluster-name]If that fails, fix DNS first. I've seen this on workgroup clusters where hosts file entries are missing.
Windows Firewall blocking cluster ports
The cluster service uses UDP 3343 and TCP 445 plus RPC dynamic ports. If a firewall update blocks these, the join never starts. Enable the Failover Cluster firewall rules on both nodes:
Enable-NetFirewallRule -DisplayGroup 'Failover Clustering'Cluster database corruption on an existing node
Rare but real—if an existing node has a corrupted cluster database, it can reject new joins with this error even on the remote node. On an existing cluster node, run:
Get-ClusterNode | Format-Table Name, StateIf any node shows a state other than Up, fix that node first. Then try adding the new node again.
Prevention for next time
Always close the cluster join wizard properly—don't force-close it if it hangs. Wait for the timeout or use Stop-ClusterNode to cancel cleanly. Also, make sure both nodes have the same Windows updates and .NET Framework versions. Mismatched updates cause half the cluster issues I see.
Keep the cluster logs handy. On the failing node, run:
Get-ClusterLog -Destination C:\ClusterLogsThis captures the exact point the join failed. I've used that to spot DNS timeouts and firewall drops in under a minute.
Bottom line: restart the cluster service first, force cleanup second, then check DNS and firewall. That sequence nukes 0XC013000F every time.
Was this solution helpful?