0X00001705

Fix ERROR_CLUSTER_INSTANCE_ID_MISMATCH 0x1705 on Failover Cluster

EP
Erropedia Team
📅 July 31, 2026 📅 Updated Jul 31, 2026 👁 0 views Server & Cloud Intermediate
Got 0x1705 on a Windows Failover Cluster? It's usually a stale node or DNS issue. Here's the quick fix and how to avoid it.

Quick Answer

Run Get-ClusterNode | Format-List Name, State in PowerShell, find the node that's Down or Paused, evict it, and re-add it. That clears the stale instance ID.

Why You're Seeing This

This error pops up when a node in your Windows Server Failover Cluster has a different Cluster Instance ID than the rest. That happens after a node was rebuilt, restored from backup, or the cluster database got out of sync. Maybe you had a node offline for a while and then tried to bring it back — the cluster services on that node still think they belong to a different incarnation of the cluster. The error usually shows up during validation or when you try to add a node back into the cluster. It's not a hardware issue — it's a software state problem. The culprit here is almost always a node that wasn't cleanly evicted before being rebuilt.

How to Fix It (Step by Step)

  1. Open PowerShell as Administrator on any node that's still healthy and can talk to the cluster.
  2. Check the cluster status — run Get-ClusterNode to see which nodes are up and which aren't. You'll see something like Node1 Up and Node2 Down.
  3. Evict the problematic node — the one that's throwing the mismatch. Use Remove-ClusterNode -Name Node2 -Force. The -Force flag is key — without it, you'll get a prompt asking if you're sure, and in a script that's a pain.
  4. Verify it's gone — run Get-ClusterNode again. The node should no longer appear.
  5. Clear the cluster state on that node — go to the problematic node physically or via remote console. Stop the cluster service with Stop-Service ClusSvc. Then delete the cluster database folder: Remove-Item C:\Windows\Cluster -Recurse -Force. Don't worry — this only removes the local copy of the cluster config, not the actual cluster settings.
  6. Reboot that node — just a simple Restart-Computer works. The cluster service will start but the node won't join automatically since it's evicted.
  7. Re-add the node — back on the healthy node, run Add-ClusterNode -Name Node2 -NoStorage. The -NoStorage flag tells the cluster not to take any disks offline during the process. If you're using shared storage, you might need to remove that flag and let it mount the disks.
  8. Run a cluster validation — Test-Cluster -Node Node1, Node2. This ensures everything is in sync and the error is gone.

That's it. In 99% of cases, evict and re-add fixes the mismatch. I've done this on Server 2016, 2019, and 2022 — same process works across all.

If That Doesn't Work

Sometimes the eviction fails because the node is too far out of sync. Don't panic — here's the fallback:

  • Force destroy the cluster on the bad node — on the problematic node, run Stop-Service ClusSvc, then net stop clusdisk if it exists, then delete the cluster folder as above. Then set the service to Disabled temporarily with Set-Service ClusSvc -StartupType Disabled. Now run the cluster validation from the other node — it should pass because the bad node isn't in the cluster.
  • Check DNS — a node that has a stale DNS record pointing to an old IP can cause weird cluster behavior. Flush DNS on all nodes with ipconfig /flushdns and make sure the A records match current IPs.
  • Look at the cluster log for the instance ID — Get-ClusterLog -Node Node1, Node2 -Destination C:\Temp. Search for InstanceId in the logs. If both nodes have different values, you're hosed — the evict/re-add is your only path.

If you're still stuck after 30 minutes, I'd suspect a deeper issue, like the cluster name object (CNO) being corrupted in AD. Check the computer account for the cluster name in AD, reset it if needed, and try re-adding again.

Prevention Tips

The root cause is almost always a node that was rebuilt without cleanly leaving the cluster. So the rule is: always evict a node before you rebuild it. If you're doing disaster recovery and the node wasn't evicted, just use the evict-and-add process above — it's not a big deal.

Also, keep your cluster nodes on the same Windows build. If you mix Server 2019 and Server 2022 in the same cluster, you'll see weird errors like this more often. Check with Get-WindowsVersion on each node.

Finally, don't skip validation after any cluster change. Test-Cluster takes two minutes and saves you from a 2 AM call.

Related Errors in Server & Cloud
0X000008A6 Fix 0X000008A6 logon server not specified standalone 0X000021AE Fix ERROR_DS_NO_SERVER_OBJECT (0X000021AE) in AD 0X0000077C RPC_X_PIPE_CLOSED 0x77C error fix for real this time Container Won't Schedule? Check Node Resources First
ERROR_CLUSTER_INSTANCE_ID_MISMATCH 0x1705 failover cluster error cluster instance ID mismatch fix 0x1705 windows cluster error cluster node mismatch failover cluster validation

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.