We have critical production cluster running Windows 2003 R2 SP2 x64.
We got same issues on one node and the operations team removed (and clean up) the node. Then tried to rejoin the node and failed.
We open a ticket with Microsoft Enterprise support and we reset cluster account and made several changes.
Last try to join the node generated the error 5893 The join operation failed because the cluster instance ID of the joining node does not match the cluster instance ID of the sponsor node
Anyone know how the cluster instance ID is generated on the new node, areas of registry/files to clean up before re-try to join the node or how to fix this issue?
Hi John. Thanks for your reply
I saw this KB before and review the HKEY_LOCAL_MACHINE\Cluster\ClusterInstanceID. The Key does not exist.
Do you any other place where the Cluster Instance ID is located?
The documents said "When a cluster node joins a Windows Server 2003-based cluster, the cluster node extracts the cluster instance ID from its local database"
Do you know where is the DB is located?
I'm curious about the following regkey
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Cluster Server]
Also there are several files on the Windows\Cluster folder. Should I delete (or rename) this folder before I try to add node to cluster?
- Edited by Guillermo Musumeci Monday, February 27, 2012 8:33 AM
Does HKLM\Cluster exist on the node? If not, is there a C:\Windows\Cluster\clusdb file present on the node that is failing to join?
If HKLM\Cluster does NOT exist, but C:\Windows\Cluster\clusdb does, delete the clusdb and clusdb.log files if they exist.
If HKLM\Cluster does exist, so will the clusdb files. If these exist without a ClusterInstanceID value, I'd try running a 'cluster node /force' command to see if that fixes the issue. If the force cleanup doesn't work, try just changing the ClusterInstallationState value to 0.
Both HKLM\Cluster and C:\Windows\Cluster\clusdb.* files does NOT exist on node
I think our options are changing the ClusterInstallationState value to 0, rebuild node and recreate cluster.
Last option is not recomended because is a very critical cluster and the maintenance window is too small.