Windows Server 2025 HyperV cluster (2 node) Quorum issue

Hello Jure Purgar

The registry key is very useful and it has mainly fixed the issue. However there is 1 issue that remains

• Node 1 is powered off followed by Node 2, then Node 1 only is powered back on.

In the above scenario the cluster will not come back online and it is necessary to provide the following 2 commands

• Stop-Service ClusSvc -Force
• net start clussvc /forcequorum

Hello,

We had the same issue as described above. We are using cloud witness, so it seems the issue is present for any kind of witness in a 2-node cluster. If you reboot a node that is current owner of a core cluster resources (including witness) the quorum is lost and the cluster fails completely.

We were able to resolve the issue by using the fix described here: https://community.spiceworks.com/t/wsfc-quorum-failure/1243988 . We did not have to install the patch because apparently the fix is included in latest updates, but it seems it is still behind a feature flag. So, adding the bellow reg key resolved the issue for us. I'm not sure about other implications of this, so use at your own risk.

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides /v 2005146767 /t REG_DWORD /d 1 /f

Hi Chip Gehrke ,

Welcome to Microsoft Community.
You are hitting a known shutdown behavior in Windows Server 2025 that can cause quorum loss when the node owning the Disk Witness is gracefully shut down. 

Recommended Workaround:   
Before shutting down or rebooting the node that owns the Disk Witness, manually move the Cluster Group to the other node: 

Move-ClusterGroup "Cluster Group" -Node <OtherNode> 

Why this prevents the outage 

The Disk Witness is already online on the surviving node 

The surviving node retains a stable quorum vote 

No vote rebalancing happens during shutdown 

The cluster stays online even if one node goes down 

This step ensures the Disk Witness remains online on the surviving node, preserving quorum stability. By preventing vote rebalancing during the shutdown, the cluster stays online even if one node goes down. This approach is widely confirmed by other Windows Server 2025 users for Disk Witness configurations and helps avoid unexpected downtime during maintenance.

If you believe this information adds some value, please accept the answer so that your experience with the issue would help contribute to the whole community.

Best wishes!
Titus Bui.

Hi Chip Gehrke ,

Based on my experience handling similar cases, the RCA (Root Cause Analysis) is likely due to a shutdown timing gap during node drain. In Windows Server 2025, the draining node completes shutdown faster than the cluster can update quorum votes.

Breakdown of What happens:
1. Disk Witness briefly goes offline
When the owner node begins shutdown, the cluster tries to move the Disk Witness. While transitioning, the witness is Offline, so it temporarily loses its vote (Dynamic Witness behavior).

2. Shutdown/drain completes too quickly In WS2025, the drain completes in about 50–100 ms, which is faster than the cluster can:

• Bring the Disk Witness online on the other node
• Finish disk arbitration
• Recalculate quorum
• Reassign votes through dynamic quorum

3. Dynamic quorum has not finished updating During this short window:

• The witness vote is lost
• The draining node’s vote disappears as it shuts down
• The surviving node has not yet been assigned a new vote

Result:

➡ Zero valid quorum votes remain → the cluster loses quorum → cluster shuts down.

This is a known shutdown-timing problem in WS2025 and does not occur on WS2022.

If you believe this information adds some value, please accept the answer so that your experience with the issue would help contribute to the whole community.

Best wishes!
Titus Bui.

In a two-node Hyper-V cluster, if the disk quorum is not functioning as expected when restarting the owner node, it may be related to how quorum is configured in Windows Server 2025. In previous versions like Windows Server 2022, the quorum could automatically transfer to the other host if the owner node was restarted, but this behavior might change with the new version.

To ensure proper functioning, consider the following:

1. Quorum Configuration: Verify that the quorum configuration is set correctly. You can use the Set-ClusterQuorum cmdlet to configure the quorum options. Ensure that the disk witness is correctly set up and that both nodes are symmetrical in terms of resources.
2. Witness Configuration: If you haven't already, consider configuring a witness (disk or file share) to help maintain quorum during node failures or restarts. This can provide additional resilience.
3. Cluster Logs: Check the cluster logs for any error messages or warnings that might indicate why the quorum is not flipping as expected. This can provide insights into any underlying issues.
4. Documentation and Updates: Review the official Microsoft documentation for any updates or changes in behavior regarding quorum in Windows Server 2025. There may be specific considerations or new features that affect how quorum operates in this version.

If the issue persists, it may be beneficial to consult Microsoft's support or community forums for further assistance specific to Windows Server 2025.