Fix ERROR_CLUSTER_MEMBERSHIP_INVALID_STATE (0x00001702) on Windows Server

First Thing: Check if the Cluster Service is Actually Running

Look, I've seen this error a bunch. And nine times out of ten, it's because the cluster service on the node is either stopped, stuck in a weird state, or starting and crashing in a loop. The error text says "incompatible with the current membership state," which is Microsoft's polite way of saying the node isn't part of the cluster right now.

So before you go digging through logs or messing with network settings, open Services.msc and check the Cluster Service. If it's not running, start it. If it's stuck on "starting" or "stopping," kill it with PowerShell and restart it.

Stop-Service -Name ClusSvc -Force
Start-Service -Name ClusSvc

If it still won't start, check the Windows Event Log under "/Applications and Services Logs/Microsoft/Windows/FailoverClustering/Operational". You'll often see an event ID 1135 or something about a lost quorum. Had a client last month whose entire print queue died because a node's disk controller driver failed after an update — the cluster service couldn't talk to the witness disk, so it refused to join.

Second Most Common Cause: Network Connectivity Issues Between Nodes

Cluster nodes are chatty. They need to talk to each other over at least one network, and if that network is flaky, you'll see this error. The node can't validate its membership because it can't ping the other nodes or the witness.

Check the cluster networks in Failover Cluster Manager. If a network shows as "Unreachable" or "No connectivity," you've found your problem. The fix is almost always a bad cable, a misconfigured switch port (try disabling spanning tree on the cluster VLAN), or a stale NIC driver.

Here's a quick test I run on both nodes simultaneously:

Test-Cluster -Node NodeName1, NodeName2

This validates network connectivity, storage, and quorum. If it reports that "Network connectivity" failed, look at the network report. I once spent two hours on a site only to find a junior admin had set the cluster heartbeat network to the same subnet as the management VLAN — the nodes kept stepping on each other's toes.

Also check the firewall. Port 3343 (TCP and UDP) is used for cluster heartbeats. If Windows Firewall or a third-party firewall is blocking that, the node will never stabilize its membership.

Third Cause: Corrupted Cluster Database or Node Offline State

Sometimes the node was formerly part of the cluster but got removed incorrectly. Or the cluster database (stored in the quorum) got corrupted. This is rarer but when it happens, it's a pain. You'll see the node listed in Cluster Manager with a state of "Down" or "Not Joined." The error 0x00001702 appears when you try to run any operation on that node.

If the node still has the cluster service running but shows as down, try evicting it and re-adding it. But only if you have another node in the cluster that's healthy. Here's the safe way to do that:

1. On a healthy node, open PowerShell as admin.
2. Run Get-ClusterNode to list nodes.
3. Evict the bad node: Remove-ClusterNode -Name BadNodeName
4. On the bad node, clear the cluster state: Get-ClusterResource | Where-Object {$_.State -eq 'Failed'} | Reset-ClusterResource
5. Add it back: Add-ClusterNode -Name BadNodeName

If you can't even evict it, you might need to force the cluster service to forget its membership. Stop the cluster service, delete the cluster database file (usually at C:\Windows\Cluster\CLUSDB), then reboot and rejoin the cluster. But be careful: that database stores local state — you'll lose cluster-specific registry data for that node.

Quick Reference