Fix cluster old version error 0x00001710

You're staring at Event ID 1135 or a validation report that says ERROR_CLUSTER_OLD_VERSION (0X00001710). This usually hits when you're trying to add a new node to an existing cluster, or you've patched half your cluster and rebooted the wrong one first. I saw this last month with a client who had a three-node Windows Server 2016 cluster and tried to sneak in a Windows Server 2022 node without a full upgrade. The cluster services refused to talk to each other, and the old nodes logged this exact hex error.

What's causing it

The cluster service uses a shared database (the quorum) that holds configuration data. Every node must be running a compatible version of the cluster service to process that data. When one node has a different build number—especially a major OS version—the database format or the RPC protocol changes. The old node sees the new node's version and throws ERROR_CLUSTER_OLD_VERSION because it can't parse the data. The reverse happens too: the new node sees the old node and complains its version is too old. You can't have a mixed-version cluster unless you're in a supported rolling upgrade scenario, and that requires specific versions (like 2016->2019 with a database schema upgrade).

The real trigger is almost always a mismatched OS build across nodes. This isn't a transient networking issue—it's a hard version check. The cluster service compares the dwClusterVersion from each node's registry under HKLM\Cluster\ClusterVersion. If they don't match, you get the error.

How to fix it

You have two choices: upgrade the old node to match the new one, or remove (evict) the old node from the cluster. I'll walk you through both, but if you're in a production environment, do not upgrade without a maintenance window. A rolling upgrade is the safest route.

Option 1: Upgrade the old node

Identify which node is the offender. Run this PowerShell on each node:
```
(Get-ClusterNode).NodeName, (Get-ItemProperty "HKLM:\Cluster\ClusterVersion").Version
```
The node with the lower version number is the one throwing 0X00001710.
If you're on Windows Server 2016 and the other nodes are 2019, you need to do a cluster OS rolling upgrade. You don't just install a feature pack—you upgrade the OS itself. Start with the node that holds the quorum vote.
Drain the role from the old node: Suspend-ClusterNode -Name -Drain. This moves workloads off safely.
Perform the in-place upgrade to the same OS version as the rest of the cluster. Use Setup.exe /auto upgrade /pkey from the ISO. This takes about 45 minutes per node.
After reboot, run Resume-ClusterNode -Name to bring it back. Then repeat for each old node.
Once all nodes are on the same version, update the cluster functional level: Update-ClusterFunctionalLevel. This is required for features like Storage Spaces Direct on the new OS.

Option 2: Evict the old node

If you don't need the old server anymore, or it's a retired test box that snuck into the cluster, just kick it out.

Run this on any remaining node that's working:
```
Remove-ClusterNode -Name 
```
If PowerShell fails (sometimes it does when quorum is unstable), use Failover Cluster Manager. Right-click the old node and choose Evict.
On the old node itself, uninstall the Failover Clustering feature: Remove-WindowsFeature -Name Failover-Clustering. Then reboot.
Verify the cluster health: Get-ClusterNode should show only the good nodes.

If it still fails

Sometimes the error persists because the cluster database itself is corrupted from the version mix. Check the cluster log for deeper clues:

Get-ClusterLog -Destination C:\Temp -Node *

Look for entries like [DB] Failed to read cluster database version or [RCM] HandleQuit: node 2 has incompatible version. If you see those, you might need to do a force quorum from the highest-versioned node. In the most extreme case—and I've only done this twice in 15 years—you have to destroy and recreate the cluster. Export the cluster roles first with Get-ClusterGroup | Export-ClusterXml. Then run Destroy-Cluster and rebuild the cluster from scratch using the same IP and name. Import the roles back. It's ugly, but it's the nuclear option.

One more thing: check that all nodes have the same cluster service pack level. I had a case where a 2019 node was missing KB5001342 while the others had it. After applying the update and rebooting, the error disappeared. Version mismatch can be as subtle as a cumulative update.