Fix Cluster Join Aborted Error 0X000013D2

When This Error Shows Up

You're in the middle of adding a new node to a Windows Failover Cluster — maybe Server 2016, 2019, or 2022 — and right as the join starts, it bombs with ERROR_CLUSTER_JOIN_ABORTED (0X000013D2). The error text says "The cluster join operation was aborted." This almost always pops up after a brief network interruption or when you've run the join command multiple times in quick succession. I've seen it most often when the target node is on a different subnet or the cluster communication port (TCP 3343) gets blocked for a second.

Root Cause in Plain English

The cluster service on the joining node starts the handshake with the existing cluster, but something cuts it short. The culprit here is almost always one of three things:

Stale cluster state on the joining node — it still thinks it was part of a cluster before
Network timeout — the cluster heartbeat missed a few packets, and the join window closed
Firewall rules that aren't persistent across reboots or got reset by a GPO

Don't bother with rebooting both nodes — that rare fixes it. The real fix is to clean the node's cluster config entirely, verify the network path, and rejoin with a clean state.

Step-by-Step Fix

Clear the stale cluster state on the joining node
Open PowerShell as Administrator. Run:
```
Get-ClusterNode -ErrorAction SilentlyContinue | Remove-ClusterNode -Force
Stop-Service ClusSvc
Clear-ClusterNode -Force
Start-Service ClusSvc
```
This wipes any leftover cluster database on the local machine. Without this, the old GUID will conflict and abort the new join.
Check the cluster network
On the existing cluster node (the one that's already running), run:
```
Get-ClusterNetwork | Select Name, State, Address
```
Make sure the network you're using for cluster communication shows State: Up. If it's down, fix the switch or NIC first. Also verify both nodes are on the same subnet for the cluster heartbeat — mixing VLANs without proper routing is a surefire way to get this error.
Validate firewall rules on both nodes
Cluster requires TCP 3343, UDP 3343, and ICMP (for heartbeat). Run this on the joining node:
```
netsh advfirewall firewall show rule name="Failover Clusters (TCP-In)" verbose
```
If that rule is missing, import it from a working node or re-enable the Failover Cluster firewall group. Don't rely on "allow all" — it masks other issues.
Join with validation
Now on the joining node, run:
```
Add-ClusterNode -Name NodeName -Cluster ClusterName -Force
```
The -Force flag is key here — it bypasses the "already part of a cluster" check we cleared in step 1. If it still fails, add -Verbose and look for where it hangs.
If it still fails — check the cluster log
On the joining node, grab the cluster log:
```
Get-ClusterLog -Destination C:\ClusterLogs -TimeSpan 10
```
Open that .log file and search for 0x000013d2 or aborted. You'll often see something like ERROR_CLUSTER_JOIN_ABORTED: Join aborted due to node not responding to NetFT heartbeat. That tells you the network is dropping packets between nodes — use Test-NetConnection on port 3343 to confirm.

What to Check If It Still Fails

If you've done all that and it still blows up, check these:

DNS registration — both nodes must register their cluster IP in DNS. Run ipconfig /registerdns on both.
Time sync — a drift of more than 5 minutes between nodes will cause the cluster service to refuse the join. Sync both to the same NTP server.
IPv6 — if you've disabled IPv6 on one node but not the other, the cluster communication can get confused. Either enable it on both or disable it on both.

I've had one case where the cause was a misconfigured VMQ (Virtual Machine Queues) on the physical NIC. Disabling VMQ on the host's network adapter fixed it. That's rare, but if you're running Hyper-V, knock that out early.