Fix ERROR_CLUSTER_NODE_NOT_MEMBER (0X000013BC) fast

1. The node lost connectivity and got evicted

This is the most common reason I see for error 0X000013BC. The cluster heartbeats between nodes failed long enough that the cluster thought the node was dead. Once the node comes back, it can't rejoin because the other nodes already removed it.

Had a client last month whose entire print queue died because of this — a switch in their server room had a bad port, and the heartbeat traffic got dropped. The node sat there thinking it was fine, but the cluster already kicked it out.

How to fix it

• First, check the cluster logs on both the problem node and a healthy node. Run this on all nodes:

Get-ClusterLog -Node <NodeName> -TimeSpan 30

Look for messages like Node <X> lost quorum or Node <X> has been evicted. If you see that, the fix is straightforward: add the node back to the cluster.

• On a healthy node, run PowerShell as admin:

Add-ClusterNode -Name <ProblemNodeName>

This forces the node back in. If it fails, check if the node's cluster service is running. On the problem node, run:

Get-Service -Name ClusSvc | Start-Service

Then try Add-ClusterNode again. If it still fails, move to the next cause.

2. The node was cleanly removed and needs re-add

Sometimes an admin (or a rogue script) runs Remove-ClusterNode during maintenance and forgets to put it back. Or the node's config got corrupted during a reboot. The node shows up in Failover Cluster Manager but with a status of Not a Member.

How to fix it

You can't just start the service — the node's cluster database is stale. You need to re-add it properly.

• On the problem node, stop the cluster service and clear its local state:

Stop-Service ClusSvc
Remove-Item -Path "C:\Windows\Cluster" -Recurse -Force

Warning: This wipes the node's copy of the cluster database. It's safe to do because the other nodes hold the current state. But double-check the node isn't hosting critical roles — if it is, move them first.

• Now restart the cluster service:

Start-Service ClusSvc

The node will enter a Joining state for a few seconds, then become a member. If it doesn't, the quorum might be messed up — see next section.

3. Quorum configuration is broken

This one's trickier. If the cluster can't form a quorum, nodes that are up will show as members, but any node that tries to join gets error 0X000013BC. The cluster is technically running, but the quorum is in a weird state.

I've seen this happen after a power outage where only two out of three nodes came back. The surviving nodes form a cluster, but the third node can't join because the quorum witness (a file share or disk) isn't reachable from that node.

How to fix it

• Check the quorum configuration from a healthy node:

Get-ClusterQuorum

If the quorum type is NodeAndFileShareMajority, make sure the file share is accessible from the problem node. Open \\<FileServer>\<Share> in File Explorer on the problem node — if you can't browse to it, that's your issue.

• If the witness is a disk (Cluster Disk Witness), check that the disk is online in Disk Management on the problem node:

Get-Disk | Where-Object {$_.IsSystem -eq $false -and $_.OperationalStatus -eq 'Offline'}

If any are offline, bring them online:

Set-Disk -Number <DiskNumber> -IsOffline $false

Then try Add-ClusterNode again. If the quorum witness is on a SAN, check the SAN's zoning — the problem node might have lost its connection to the LUN.

Quick-reference summary table

If none of these work, check for firewall rules blocking the cluster network on private VLANs — the default cluster network uses UDP 3343 for heartbeats and TCP 445 for SMB if using a file share witness. Run Test-Cluster from any healthy node to see what fails.