Cluster Node Stuck Joining? Fix 0X000013B1 Fast
This error means a node is stuck joining a cluster. It's usually a misconfigured network or a hung service. Here's what to check first.
Cause 1: DNS Resolution Problems
I've seen this more times than I can count. A client in Denver had a two-node cluster for their ERP system. The second node kept throwing 0X000013B1 when trying to join. Spent half a day checking firewalls, credentials, the whole nine yards. Turned out the node's DNS couldn't resolve the cluster name to its own IP address. Fixed it in five minutes.
The cluster name and node names must resolve to the correct IP addresses. If they don't, the join process hangs forever. Here's the quick check:
- Open Command Prompt as admin on the joining node.
- Run
nslookup <ClusterName>andnslookup <JoiningNodeName>. - Both should return the IP addresses you expect. If not, check your DNS records.
- Also check
ipconfig /allon the node to confirm DNS server is correct.
If DNS is wrong, update the A or AAAA record in your DNS server. Or, if you're in a pinch, add a static entry in the hosts file:
# Add this line to C:\Windows\System32\drivers\etc\hosts
192.168.1.10 YourClusterName.domain.com
That's a band-aid, not a fix. Get DNS right.
Cause 2: Firewall Blocking Cluster Ports
Another common one: the cluster uses a bunch of ports for node-to-node communication. If Windows Firewall or a third-party firewall blocks them, the join process stalls. Ports you need open:
- UDP 123 (NTP) – time sync
- UDP 137 (NetBIOS name resolution)
- TCP 135 (RPC)
- TCP 445 (SMB)
- UDP 3343 (Cluster Service)
- TCP 3343 (Cluster Service)
- TCP 5985 (WinRM)
- TCP 5986 (WinRM HTTPS)
- UDP 500-4500 (IPsec) – if you use it
To quickly test, temporarily disable the firewall on the joining node and try the join again. If it works, you know the firewall is the problem. Then narrow down which rule to adjust.
I had a small business client using a hardware firewall between their cluster nodes. They forgot to add a rule for UDP 3343. Node sat there for 20 minutes before timing out. Added the rule, join completed in under a minute.
Cause 3: Cluster Service Hung or Stale Join Attempt
Sometimes the node already has a leftover join request from a previous attempt. The cluster service might be stuck in a bad state. Here's the fix:
- Stop the cluster service on the joining node:
net stop clussvc - Check if there's a stale join: look in the cluster log (
C:\Windows\Cluster\ClusSvc.log) for repeated join attempts. - If the log shows it keeps retrying, remove the node from the cluster configuration:
On an active cluster node (not the stuck one), run PowerShell as admin:
Remove-ClusterNode -Name <StuckNodeName>
Then on the stuck node, clean up the cluster database:
cluster node <StuckNodeName> /forcecleanup
After that, restart the cluster service on the stuck node and try the join again. This clears out any half-baked state.
I've had to do this on Server 2012 R2 and 2016 clusters. Works every time.
Quick-Reference Summary Table
| Cause | Symptom | Fix |
|---|---|---|
| DNS resolution | Node can't find cluster name or its own IP | Update DNS records or hosts file |
| Firewall blocking ports | Join hangs indefinitely, no error beyond 0X000013B1 | Open UDP 3343, TCP 135, 445, and others |
| Stale cluster join state | Previous join failed, service keeps retrying | Remove node from cluster, force cleanup, re-add |
That's it. Start with DNS, then firewall, then the stale state. One of these will fix it 90% of the time.
Was this solution helpful?