August 24, 2010 at 12:02 pm
Hi.
I'm having a weird problem with my failover cluster when trying to upgrade to SP3.
First the history of the cluster;
It was installed 18 months ago when the servers where in the domain DOMAIN1.
A few months ago the servers where moved to a new domain, DOMAIN2, using Active Directory Migration Tools.
When I try to install SP3 I first pause the remote node of the cluster, and then i start the SP3 installation. I do the test to check if my crendentials are approved, and select the MSSQL for upgrade to SP3. The installation starts, and after a minute or so, the installation starts the rollback.
From the error log i get this:
Product : Database Services (MSSQLSERVER)
Product Version (Previous): 3042
Product Version (Final) :
Status : Failure
Log File : C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Hotfix\SQL9_Hotfix_KB955706_sqlrun_sql.msp.log
Error Number : 29512
Error Description : MSP Error: 29512 SQL Server Setup was unable add user DOMAIN2\sql.admin to local group DOMAIN1\SQL Agent Admins.
And from the SQL9_Hotfix_KB955706_sqlrun_sql.msp.log file I get this:
Loaded DLL:
C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\sqlsval.dll
Version:
2005.90.4035.0
MSI (s) (58!30) [02:59:41:434]: PROPERTY CHANGE: Adding SqlClusterSec property. Its value is '0'.
MSI (s) (58!30) [02:59:41:450]: PROPERTY CHANGE: Adding SECURITYMODE property. Its value is 'SQL'.
MSI (s) (58!30) [02:59:41:450]: PROPERTY CHANGE: Adding SqlSecurityMode property. Its value is 'SQL'.
MSI (s) (58!30) [02:59:41:450]: PROPERTY CHANGE: Adding RestoreSqlDomain property. Its value is 'DOMAIN1\SQL Server Admins'.
MSI (s) (58!30) [02:59:41:450]: PROPERTY CHANGE: Adding RestoreAgtDomain property. Its value is 'DOMAIN1\SQL Agent Admins'.
MSI (s) (58!30) [02:59:41:450]: PROPERTY CHANGE: Adding RestoreFtsDomain property. Its value is 'DOMAIN1\FTS Admins'.
Anyone have an Idea of what to do with this problem? Is there any system tables with info about witch domain a MSSQL installation bellongs to? Or am I looking at a reinstallation of the cluster?
Regards
Tommy Rasmussen
August 24, 2010 at 10:19 pm
Why are you trying to pause the inactive node. from my understanding, the installation will need both nodes and will apply the SP on both of them. The first error you show does reflect it is trying to reach the second node, but failing to do so.
Unpause the inactive node and you should be able to proceed with the installation.
August 26, 2010 at 3:09 am
SP3 installation is done on Database level.
It first installes on the passive node then it goes to the active node for installation.
August 26, 2010 at 3:16 pm
Don't pause any nodes, install SP3 from the active node.
Incidentally what version are you upgrading from?
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
August 26, 2010 at 9:59 pm
First, as noted in earlier responses, don't pause an inactive node.
Next, looking at the error suggest an authentication error on some internally used groups. When installing SQL 2005 there are 3 or so (depending on what gets installed) local groups that are created for use by SQL, eg, SQLServer2005MSFTEUser, SQLServer2005SQLAgentUser, SQLServer2005MSSQLUser. SQL install does this when installing on a standalone machine. When first installed on a cluster, in order to be shared by the multiple nodes these must be domain level rather than at the local machine. Someone must have done this to have been successfully installed on a cluster in Domain1. When moving to a new domain, you may have to work out access, either by creating new groups or checking that the accounts in Domain1 are fully accessible to both node 1 and 2 of the cluster.
I haven't ever moved to a new domain, so I am not familiar with the difficulty of changing where those accounts authenticate from.
Sounds like time consuming fun. Good luck figuring it out.
August 31, 2010 at 11:22 am
***Solution***
Ok, so after about 10 hours of log reading, tinkering, and swearing I found a solution to this problem.
The main part of the fix is the group memberships in the SQL Agent Admin, SQL Server Admin and FTS Admins. All of the groups that the SP tried to update where in the DOMAIN1 domain (The former one). Even though the groups are SID migrated AND the cluster is set to use the DOMAIN2 groups.
The groups where set to global security groups. And when I tried to add a user from the DOMAIN2 domain, just like the SP tries to, the DOMAIN2 where not visible from the forrest view.
I changed the groups to Domain Local Security Groups, and Presto; The DOMAIN2 domain became available for selection.
After this part was fixed I returned to the install, witch failed again, and retried after the second node where started. This was paused by recomendation from about 20 articles I've googled the last week (thats why I paused it).
The SP install went along smoothly and I now have a cluster running SQL Server 2005 SP3 😀
Thanks for all the tips guys!
Regards
Tommy
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply