Recovering a partitioned cluster without reboot

Question

We recently had a brief network hiccup in our environment, and although connectivity between all nodes was restored, the failover cluster manager still shows the cluster in a Partitioned state. In practice, this means the nodes are reachable, but the cluster membership isn’t fully synchronized, leaving services at risk.

The challenge here is figuring out the proper recovery process to bring the cluster back into a healthy state without resorting to a full reboot of the nodes. We want to know the recommended steps to reestablish quorum and restore full membership, whether that involves running cluster validation commands, forcing node rejoin, or refreshing cluster service state.

So the question is: once the network issue is gone and all nodes are online, how do we safely clear the “Partitioned” flag and get the cluster back to normal operation without downtime from a reboot ?

Answer 1

Hello,

When a Windows Failover Cluster shows “Partitioned” after a transient network outage, it means the cluster service has not yet reconciled quorum and node membership even though connectivity is back. You do not need to reboot nodes to recover, but you do need to re‑synchronize cluster state. The first step is to check cluster health with Get-ClusterNode and Get-ClusterGroup in PowerShell. Nodes that are stuck in “Partitioned” will show as “Up” but not fully joined.

You can force rejoin by restarting the cluster service on the affected node with Restart-Service ClusSvc or by issuing Start-ClusterNode -Name <nodename> -Force. This clears the partition flag and re‑evaluates quorum. If multiple nodes are impacted, run Start-ClusterNode -Force on each until all are listed as “Up” and “Joined.” To confirm quorum, use Get-ClusterQuorum and ensure the witness and majority are consistent.

Cluster validation can be run with Test-Cluster to confirm there are no lingering network misconfigurations. If the partition state persists, check the cluster logs under %SystemRoot%\Cluster\Reports and look for event IDs 1135 and 1177 in the FailoverClustering log, which indicate node removal and re‑addition. These will tell you if the cluster service is still rejecting membership due to stale heartbeat data.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

Domic Vo.