Troubleshooting a Failed Installation

Troubleshooting a clustered installation of SQL Server can be tricky because SQL Server rarely tells you clearly why it failed. If a failure occurs, you’ll typically see the error message Setup failed to perform required operations on the cluster nodes. After you click OK in the message window, the installation rolls back and removes all the SQL Server program files and data files from each of the clustered nodes.

The installation problem I encounter most often in a clustered environment is that the installation has difficulty copying the files from one node to another. When you get the preceding error message, don’t click OK right away. First, check in Windows Explorer to see whether all the SQL Server program files copied successfully to the second node. If you don’t see all the files in the target node, check the network setting for each network on each node to confirm that File and Printer Sharing for Microsoft Networks is enabled. File and printer sharing must be enabled for the files to transmit over the admin share, which is a private administrator share.

You can test whether communications between nodes is working by opening a Run prompt (Start, Run) on one node and trying to access the admin share of the other node. For example, if you’re installing the first instance of SQL Server on the C drive in SQL2KNODE1 from the main article’s example, try to access SQL2KNODE2 by typing \SQL2KNODE2C$ at a Run prompt on SQL2KNODE1. If you can’t access the target node, you need to figure out what’s preventing the communication. Possible causes you might explore include:

If a SQL Server installation fails, also consider removing all the SQL Server directories that the setup process might have left behind and try to install again after a reboot. Microsoft Windows Server 2003 provides elaborate logs that show what the clustering install procedure is doing and where it fails. This makes troubleshooting a clustered installation much easier. But no matter what OS you’re installing SQL Server on, always troubleshoot a clustering problem in order of the installation. For example, always troubleshoot hardware first, then the OS, the network setup, the Cluster service installation, and finally the SQL Server installation. You’ll find that SQL Server is rarely the problem.

A handy T-SQL function you can use for debugging clustered SQL Servers is fn_virtualservernodes(). You can use the query

SELECT * FROM ::FN_VIRTUALSERVERNODES()

to determine what nodes are possible owners of your SQL Server resource. For example, after installing both clusters, I should see SQL2KNODE1 and SQL2KNODE2 in this query’s results. You use this query after the installation to confirm that the SQL Server instance is performing as expected and all possible nodes can own the resource.