Core component of SQL Server for storing, processing, and securing data
Perform these steps to restore cluster and database synchronization after the Windows Server 2025 patch:
- Validate the Windows Failover Cluster
- Open Failover Cluster Manager.
- Under Management, select Validate a Configuration.
- Run the validation tests and review the Validation Report for errors, especially in networking and storage.
- The report is saved under
%SystemRoot%\Cluster\Reports\Validation Report date and time.html. - Fix any issues reported (network, storage, or configuration) before proceeding.
- Check common cluster connectivity and disk issues
- If SQL Server cannot connect to the network after failover or node changes:
- Check event logs for adapter failures or DNS problems and verify the cluster nodes can reach domain controllers (ping tests, DNS resolution).
- Ensure SQL Server service account passwords are identical on all nodes by changing them via SQL Server Configuration Manager so all nodes stay consistent.
- If SQL Server cannot access cluster disks after the patch:
- Verify firmware and drivers are updated and consistent on all nodes.
- Confirm that drive letters for all cluster disks are identical on every node; mismatched drive letters will prevent proper failover and synchronization.
- If SQL Server cannot connect to the network after failover or node changes:
- Confirm FCI/AG configuration consistency
- For a failover cluster instance (FCI):
- Ensure all nodes still have identical OS version/patch level and SQL Server version/patch level and components after the patch.
- Confirm the WSFC resource group for the SQL FCI is online on one node and that shared storage is accessible from all nodes.
- For Always On AG on top of WSFC:
- Use the AG dashboard in SQL Server Management Studio to check replica states.
- If a replica is stuck in
SYNCHRONIZING, verify whether it is configured as synchronous or asynchronous; only synchronous replicas can reachSYNCHRONIZED.
- For a failover cluster instance (FCI):
- Recover from node or cluster failure if needed
- If one node is effectively unusable after the patch (for example, cannot rejoin the cluster):
- Let the SQL Server FCI or AG run on the healthy node.
- From the healthy node, use Failover Cluster Manager to evict the failed node from the cluster.
- Repair or rebuild the failed node (including OS and SQL Server), then add it back to the cluster and to the FCI/AG using SQL Server Setup.
- If one node is effectively unusable after the patch (for example, cannot rejoin the cluster):
- Address known synchronization and lease issues (if applicable)
- If using Always On Availability Groups and seeing repeated lease or synchronization failures after the patch:
- Review cluster and SQL logs for lease timeout or synchronization errors.
- Ensure antivirus or security tools are not scanning critical cluster and SQL paths (for example,
C:\Windows\Cluster, SQL data/log directories, and SQL binaries), as this can cause timeouts and lease expirations. - If lease timeouts are observed, consider temporarily increasing the AG lease timeout via the AG resource properties in Failover Cluster Manager, then revert once stability is confirmed.
- If using Always On Availability Groups and seeing repeated lease or synchronization failures after the patch:
- Apply relevant SQL Server cumulative updates
- If the environment matches known issues (for example, synchronization failures in specific SQL Server builds), install the latest cumulative update for the SQL Server version in use, as many synchronization and AG/FCI issues are fixed in CUs.
After these steps, re-check the AG dashboard and Failover Cluster Manager:
- All cluster resources should be online.
- Databases on secondary replicas should show
SYNCHRONIZED(for synchronous replicas) and data changes should be flowing from primary to secondary.
References:
- Failover cluster troubleshooting
- Always On failover cluster instances (SQL Server)
- Recover from failover cluster instance failure
- KB4527355 - FIX: Synchronized job may fail when the target servers start to synchronize the database in SQL Server
- KB4459900 - FIX: Synchronization fails when you stop primary replica and fail over a secondary replica to primary in Read-Scale AG in SQL Server 2017
- Connectivity Issue Between SQL Server Databases and Windows Failover Cluster - Microsoft Q&A
- SQL 2016 HA Group stuck in Synchronizing - Microsoft Q&A
- Steps for Rolling AG Upgrade with new VM's (2016 OS & SQL) - Microsoft Q&A
- TLS requirement for SQL Server - Microsoft Q&A
- KB5065426 Security update - SQL Server Failover cluster (AlwaysOn) problems - Microsoft Q&A