Wednesday, January 19, 2011

SQL Server 2008 Cluster Installation - First network name always fails

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
  • What user account are you running the cluster under? I wonder if it's credentials are causing issue with SQL.

    From Tatas
  • 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.

    From
  • 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.

  • I am having a very similar issue. And yes my installation account is domain admins and the rights for the sql service is domain account, thats all it needs, it doesnt need anything else (i.e. local admins) as the installation makes sure the account has the right policy rights etc. Interestingly after the installation has failed it is actually possible to start sql server outside of the cluster.Its the cluster aservce that is having problems starting the instance. In windows 2008 the cluster service doesnt use a domain account instead the concept of virtual named objects is used in AD. Interestingly when making the installtion as a default instance I didnt get a problem. It was only when I came to install a named instance i am having installtion problems. Registering SPN's etc should all be hnadled with the installtion process I dont believe anything manual needs to be dones. Have you made any progress?

  • 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.

  • I am also having same problem, I used domain account with admin privilage to install cluster, but never it creat virtual sql name, and always it failed in one or the other steps, I do not see any complete documentation for this. Anyone has any idea where I can find complete guide.

    From John

0 comments:

Post a Comment