The SQL Server failover cluster instance 'instance name' was not correctly detected. The instance was discovered on the local node but it was not found to be active.


It was weekend and as usual I am in office with lots of patching scheduled this weekend and guess what, patching start failing with no. of unknown issues. Among them one of patching took by my colleague \ guide failed with below error in C:\Program Files\Microsoft SQL Server\100\Setup bootstrap\Log\Summary.txt .

 Error: "The SQL Server failover cluster instance 'instance name' was not correctly detected. The instance was discovered on the local node but it was not found to be active. To continue, confirm the state of the instance installed on all applicable nodes of the cluster and the state of the failover cluster resources"
 

/**************log file says******************************/
User Input Settings:
ACTION: Patch
ALLINSTANCES: False
CLUSTERPASSIVE: False
CONFIGURATIONFILE:
ENU: False
FARMACCOUNT: < empty>
FARMADMINPORT: 0
FARMPASSWORD: *****
HELP: False
INDICATEPROGRESS: False
INSTANCEID: < empty>
INSTANCENAME: < empty>
PASSPHRASE: *****
QUIET: False
QUIETSIMPLE: False
UIMODE: Normal
X86: False

/********************************************/

 
This was SQL server 2008 R2 SP1 and we have to patch same to SP2 CU2. We logged into passive node (P) and ran patch on Passive node (P)  ( Sql Server 2005 Vs 2008 patching ). All the resources were on node A (active) and every thing was up and visible from node (P) using cluadmin. 

Action: As my initial investigation I checked cluadmin and made sure all resources are visible in cluadmin from node (P). 
 
Mean time we refer these blogs and checked registry of passive node as well for user input settings from log file coming as false.

 

To our surprise we found none of these values are there in registry. As well we have use this SP2 setup earlier also so no chance of corrupt setup.

We also thought of trying failover from active to passive manually to check if everything is fine @ Node (P) or we might get some more details but idea was discouraged as this is very critical production server and even in maintenance window we were authorized for single failover.

The only thought we have in mind was definitely there is a issue in registry files so we plan to compare registry settings of both nodes.  And when DBA tried to login on active node we got our answer Ahha Permission issue. DBA login doesn’t have permission to RDP Active node. It was like half battle is done.

We tried different windoes nt login now which have access to active node and passive node both and re-run patching in passive node, Hurray patching runs smooth. Log file says Patching completed successfully and its time to jump on other patching issues.

Observation:

 1. For running patching the login should have permission to access registry of both nodes
 2. There is a possibility that registry inputs are different in 2 nodes (we need to analyze which one should be available in both nodes and which one not)

3 comments: