Event ID 1177 during patching in 2-node Windows Server 2025 cluster with FSW

Question

Event ID 1177 during patching in 2-node Windows Server 2025 cluster with FSW

RoBe 0

Hi all,

We are running SQL Server 2022 (16.0.4195) with AlwaysOn on a 2-node Failover Cluster on Windows Server 2025. The nodes are patched individually overnight using System Center, one node per night. The cluster uses a File Share Witness hosted on a third, external file server (not on either of the cluster nodes).

Here's the issue:

Every time one of the nodes is rebooted (e.g. during patching), the remaining node logs a critical Event ID 1177: "The Cluster service is shutting down because quorum was lost". This results in unnecessary alerts, even though the behavior seems to be transient and self-recovering. I assume that there will be a direct impact on the AG groups, but we have not yet entered any production databases.

We have verified the following:

QuorumArbitrationTimeMax is set to 90 seconds (same as our older clusters). The File Share Witness is healthy and reachable. Dynamic Quorum and Dynamic Witness are enabled.

Cluster Functional Level is 12 (default for WS 2025), whereas older clusters (WS 2019) use level 10 and do not exhibit this issue under the same conditions.

From the logs, it looks like the remaining node temporarily loses quorum right as the second node is shutting down.

This does not happen in any of our older environments, running Windows Server 2022 and older.

Questions:

Has anyone else experienced this behavior on WS 2025 clusters? Could the stricter quorum handling in Functional Level 12 be the cause? Any recommendations on how to prevent this (besides ignoring Event ID 1177)?

Thanks in advance for any insights!

1 answer

Your answer

Answer 1

Anonymous

Hi RoBe：

Thank you for contacting the Microsoft community!

Event 1177 indicates that your node has lost its voting rights, which may be related to the network connections witnessed by nodes to nodes and nodes to file sharing. We need to ensure the network status when you update one of the nodes.

At present, we have not received arbitration for the Server 2025 cluster and any changes to the Server 2022cluster or Server 2019 cluster. To alleviate your problem, we can consider adding a VM node instead of FSW for voting.

This will also give your cluster an odd number of votes and prevent brain splitting.

Best Regrads

Andrew

RoBe 0 Reputation points

2025-06-13T13:21:16.0466667+00:00

Hi Andrew, and thank you for your response!

Adding an additional node to the cluster is not an option we’re looking to pursue at this time. We were rather hoping that there might be some configuration setting we had overlooked that could explain the issue — but the values we’ve checked match those in our older, stable clusters.

After further investigation, we concluded that the issue only occurred when restarting one specific node, Node A. In those cases, the cluster core resource (i.e., the quorum) was not moved over to Node B, which in turn caused the Cluster Service on Node B to shut down as well. Once Node A came back online and quorum was restored, the Cluster Service on Node B also resumed.

Manual failover of the quorum between the nodes was possible at any time, but it did not happen automatically.

As a last resort, before considering a full reinstall, we attempted to evict Node B from the cluster, restart all involved servers, and then rejoin Node B to the cluster. After that, automatic failover of all resources started working correctly.

Our conclusion is that something likely went wrong during the initial installation or cluster configuration, which left things in a broken state.

Best regards, RoBe
Алексей Шевелёв 0 Reputation points

2025-07-09T09:32:50.7233333+00:00

I confirm that the same problem exists for 2025 and 2022 clusters, I have searched through the configs of both clusters and there are no differences, but the behavior of 2025 is currently unexplained.
Philipp-7753 0 Reputation points

2025-07-11T12:35:05.0966667+00:00

I can also confirm that we have the same issue on two SQL 2022 AG Clusters on Windows Server 2025 with a File Share Witness (FSW).

Share via

Event ID 1177 during patching in 2-node Windows Server 2025 cluster with FSW

1 answer

Your answer