up vote 1 down vote favorite
share [g+] share [fb]

I'm testing failover clustering in Windows Server 2008 to host a SQL Server 2008 installation using this installation guide. My base cluster is installed and working properly, as well as clustering the DTC service. However, when it comes time to install SQL Server, my first attempt at installation always fails with the same message and seems to "taint" the network name.

For example, with my previous cluster attempt, I was installing SQL Server as VSQL. After approximately 15 attempts of installation and trying to resolve the errors, e.g. changing domain accounts for SQL, setting SPNs, etc., I typoed the network name as VQSL and the installation worked. Similarly on my current cluster, I tried installing with the SQL service named PROD-C1-DB and got the same errors as last time until I tried changing the name to anything else, e.g. PROD-C1-DB1, SQL, TEST, etc., at which point the install works. It will even install to VSQL now.

While testing, my install routine was:

  1. Run setup.exe from patched media, selecting appropriate options
  2. After the install fails, I'd chose "Remove node from a SQL Server failover cluster" and remove the single, failed, node
  3. Attempt to diagnose problem, inspect event logs, etc.
  4. Delete the computer account that was created for the SQL Service from Active Directory
  5. Delete the MSSQL10.MSSQLSERVER folder from the shared data drive

The error message I receive from the SQL Server installer is:

The following error has occurred: The cluster resource 'SQL Server' could not be brought online. Error: The group or resource is not in the correct state to perform the requested operation. (Exception from HRESULT: 0x8007139F)

Along with hundreds of the following errors in the Application event log:

[sqsrvres] checkODBCConnectError: sqlstate = 28000; native error = 4818; message = [Microsoft][SQL Server Native Client 10.0][SQL Server]Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.

System configuration notes:

  • Windows Server 2008 Enterprise Edition x64
  • SQL Server 2008 Enterprise Edition x64 using slipstreamed SP1+CU1 media
  • Dell PowerEdge servers
  • Fibre attached storage
link|improve this question
50% accept rate
You're not creating the SQL name manually before the install are you? – Sam Jul 9 '09 at 15:55
No. I let the cluster wizard take care of the base computer accounts and let the SQL Server installer create the SQL network name. The only change I made was to give the cluster computer account permission to add computers to AD. – boflynn Jul 9 '09 at 16:07
feedback

5 Answers

up vote 0 down vote

What user account are you running the cluster under? I wonder if it's credentials are causing issue with SQL.

link|improve this answer
feedback
up vote 0 down vote

While reading your installation routine, what struck me, was that you were removing just one node from the failed cluster installation. In my experience, if a clustered setup fails, it better to clean it up and start fresh. So when your first setup failed, and you removed the node and deleted the account and files, that left your clustered instance in an invalid state and caused problems for the next setup run. When you mistyped the virtual server name, you have started fresh and your setup succeeded.

link|improve this answer
feedback
up vote 0 down vote

You aren't installing as a domain admin and your account you are using to run SQL services has no rights except on the SQL server are you? At least this was my situation.

I found that delegating the ability to modify serviceprincipalnames on Computer objects in the Computers OU + granting Read/Write all attributes to the the service account by the service account resolves these problems with establishing the correct SPNs for cluster failover. This allows the SQL service account to dynamicly register and deregister SPNs as instances are taken off line and brought on line.

link|improve this answer
feedback
up vote 0 down vote

I am having a similar issue, I also start the instance outside the cluster manager, than I connect to the instance, add the sqlagent and the sqlserver service accounts to the sysadmin roles, and after that everthing works fine. Only I don't think from that moment I am using the services sid (like nt servcie\Mssql accounts anymore and I would like to use this functionality. So who knows why SQL server is not capable of mapping the windows SQL Server service service-accounts to the SQL service sid accounts? Thes service sid accounts are available (after installation) in the instance, and they have sysadmin rights, but it seems the mapping is not working.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.