Yeah, this one's a pain. You're staring at Event ID 1146 or a cluster service that won't start, and the message just says the versions don't match. I've been there. But it's fixable, and usually faster than you think.
The Fix: Get All Nodes on the Same Build
The root cause is almost always that your cluster nodes are running different Windows Server versions or have different cumulative updates installed. The cluster service is picky—it won't talk to nodes on different builds.
Here's the step-by-step to sort it out. You'll need admin rights on every node.
- Check the current build on each node. Run this in PowerShell on every node:
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' | Select-Object ProductName, ReleaseId, CurrentBuildNumber, UBR
Write down the CurrentBuildNumber and UBR (Update Build Revision). They need to match across all nodes. For example, if one node shows 17763.5936 and another shows 17763.5820, that's your problem.
- Update the lower nodes. Install the latest cumulative update for Windows Server on every node that's behind. Use Windows Update or the Microsoft Update Catalog. You want the same patch level everywhere.
If you don't know which update to grab, compare the UBR numbers. The higher UBR means more recent patches. Match the laggards to the highest one.
- Reboot each node after the updates. This is non-negotiable—the cluster service won't pick up the new version until the machine restarts.
- Start the cluster service again. On the node that's failing, run:
Start-Service ClusSvc
Or use Failover Cluster Manager to bring the service up. If it starts without the error, you're done.
What If It Still Fails?
Sometimes the updates aren't enough. Had a client last month where one node was on Server 2019 and two were on Server 2016. No amount of patching fixes that—you can't mix major versions in a cluster. The only fix there is to either rebuild the 2016 nodes as 2019 (or vice versa) or, if you're migrating, do a rolling upgrade properly.
Check the OS version on each node with winver or the registry command above. If you see different ProductName values, you've got a bigger issue. In that case, plan a node replacement—don't try to force it.
Why This Worked
Windows Server failover clusters have a hard requirement: all nodes must run the exact same OS version and have the same updates. The cluster service uses a version handshake when nodes talk to each other. If the versions don't match, the handshake fails and you get this error. Microsoft introduced this to prevent weird behavior when nodes are on different code paths.
By aligning the builds, you're making the handshake succeed. Simple as that.
Less Common Variations
You might also see this error if you've got a mix of Windows Server 2019 and Windows Server 2022 in the same cluster. That's a no-go—major versions can't mix. The error code might pop up during cluster validation or when you try to add a new node.
Another variation: if you're running a Storage Spaces Direct (S2D) cluster, the same error can appear when the OS builds differ, even by one cumulative update. I saw that once where a node had a preview update that the others didn't. Rollback the preview update or install it everywhere.
Also, check if any node has a different servicing stack update (SSU). Those small updates can also throw the version comparison off. Always include SSUs when you're patching cluster nodes.
Prevention: Keep Your Nodes In Lockstep
The only way to avoid this going forward is to treat all cluster nodes as a single unit. When you patch, patch every node within the same maintenance window. Don't let one node lag by a week—that's asking for trouble.
Set up a scheduled task or use a management tool like System Center to push updates to all nodes simultaneously. And before you add any new node to the cluster, verify its build matches the existing ones. A quick PowerShell check takes 30 seconds and saves you a headache later.
I also tell my clients to disable Windows Update auto-install on cluster nodes. You want control over when updates go out, not a random reboot that takes a node offline mid-day. Use WSUS or Windows Update for Business to manage the rollout. That way, you can test updates on one node first, then push to the rest.
Remember: clusters are all about consistency. Keep them identical, and this error never comes back.