Fix ERROR_CLUSTER_JOIN_NOT_IN_PROGRESS (0x13BD)

This error means Windows tried to finalize a cluster join that no longer exists. The pending join was canceled, rebooted away, or already committed — so the engine has nothing to resume.

Quick answer

ERROR_CLUSTER_JOIN_NOT_IN_PROGRESS means the Cluster Service got a request to finalize a join, but there's no pending join on that node to finalize. You either rebooted between the start and finish of the join, the join already committed, or a previous attempt left the node half-configured. The fix is to clean the local cluster state with Clear-ClusterNode, then re-run Add-ClusterNode from a healthy node.

What's actually happening

A cluster join is a two-part transaction. The node first enters a pending state where it's registered with the cluster but hasn't been admitted to quorum. Then, once the cluster database is replicated and the node proves it can reach the other members, it flips to active. If anything interrupts that handoff — a reboot, a network blip during replication, someone killing the Cluster Service, an antivirus agent holding a file lock on %SystemRoot%\Cluster — the pending marker gets orphaned.

Later, when something calls the join-finalize API (this happens during Add-ClusterNode, during the SQL Server Always On setup wizard, or when a reboot triggers the cluster to resume a join), the engine looks for a pending join and finds nothing. That's when it throws 0x13BD.

I've seen this most often on Windows Server 2019 and 2022 when admins RDP into the new node, start the join, hit an error, reboot to "clear things up," then retry. The reboot is what kills it. The pending state lives in memory and a small registry cache — it doesn't survive a clean shutdown.

The fix, step by step

Stop trying to join from the broken node. All of the following commands run on a node that's already a healthy cluster member, not the one throwing 0x13BD. Open an elevated PowerShell on a working member.
Check what the cluster thinks of the node. It may already be listed but in a failed state.
```
Get-ClusterNode | Format-Table Name, State, NodeWeight, NodeInstanceID -AutoSize
```
If your target node shows up as Down or Joining, that's the stale record.
Evict it if it's listed.
```
Remove-ClusterNode -Name NODE02 -Force
```
Don't skip -Force. Without it, the command hangs waiting for the node to acknowledge, and a node in Joining state won't respond.
On the target node, wipe the local cluster state. This is the step people skip and then wonder why it still fails.
```
Stop-Service ClusSvc -Force
Clear-ClusterNode -Force
```
Clear-ClusterNode removes the local cluster database, the cluster registry hive, and the cached node ID. If it complains about the service running, stop it first as shown. On Server 2016+ it also clears the SMB witness cache.
Reboot the target node. Not strictly required, but I've had too many cases where a lingering clusdb file handle from a backup agent or Defender blocks the re-init. A reboot takes 90 seconds and saves an hour.
Verify DNS and firewall before you retry. The node needs to resolve every existing cluster member by name and reach TCP 3343 (RPC) plus the 49152–65535 dynamic range on each of them. If you've got a Windows Firewall GPO pushing a restrictive profile, whitelist the Failover Clusters rules first.
```
Test-NetConnection NODE01 -Port 3343
Resolve-DnsName NODE01
```
Rejoin from the healthy node.
```
Add-ClusterNode -Name NODE02 -Cluster CLUSTER01
```
Watch it this time. If it gets past the pending phase and into Joining, leave it alone. Do not RDP in, do not run Get-ClusterLog against it, do not touch the Cluster Service. Let it finish. A healthy join on a quiet network takes 30–90 seconds.

If that fails: alternative fixes

The cluster is on a different subnet and you forgot the OR dependency

Cross-subnet clusters need the new node to have a working route to the quorum witness and to at least one existing node on the same subnet as itself. If there isn't one, the join hangs and eventually the pending state times out, giving you 0x13BD on retry. Check quorum config:

Get-ClusterQuorum

If it's a file share witness and the node can't reach the share, that's your problem. Move the witness or fix the routing.

Antivirus is eating the cluster hive

Third-party endpoint agents — I'm looking at you, older CrowdStrike and Symantec builds — will lock %SystemRoot%\Cluster\CLUSDB during the join. The join starts, the DB write blocks, the service times out, and the pending marker dies. Add the standard Microsoft AV exclusions for Failover Clustering and try again. No amount of Clear-ClusterNode will fix this until you do.

The node was previously in a different cluster

This happens after a DR test or a rebuild. The node still has a cluster identity in AD (the CNO object) tied to the old cluster. Check AD for a stale computer object under the old cluster's OU, delete it, then run Clear-ClusterNode -Force again and rejoin.

You're on Storage Spaces Direct

S2D nodes can't be joined independently of the pool. If the node was ever in an S2D cluster, you have to fully decommission the storage stack first. Clear-ClusterNode alone won't do it. Use Reset-ClusterVMMonitoredState and clear the S2D pool metadata from the node before rejoining.

Prevention

Don't reboot a node that's mid-join. Ever. If Add-ClusterNode seems stuck, open a second PowerShell window on a healthy node and run Get-ClusterLog -Node NODE02 -TimeSpan 10 to see what it's waiting on. Nine times out of ten it's DNS, a firewall rule, or a witness it can't reach. Fix that, and the join completes on its own. Rebooting turns a 5-minute problem into an afternoon of clearing stale state.

Also, script the join from a management box — not from inside the node. If you never RDP into the target, you're never tempted to interfere with it.