Here’s a quick checklist before you install an instance of SQL Server on a failover cluster; or any service pack or hotfix for an instance. Following this list should eliminate 90% of the most common causes of setup failure.
Please note that this checklist does not cover all the ‘normal’ requirements for installation of a SQL Server failover cluster instance. For that you may refer to this excellent white paper on the subject. I also recommend that you view my colleague Uttam Parui’s webcast as well prior to attempting any installations on Windows Server 2008. He covers many issues specific to Windows 2008 as well.
Common points for all SQL 200x versions
| Checklist item |
Description |
| 1. Name resolution |
Verify network name resolution of physical nodes using machine name and FQDN (fully qualified DNS name) using PING |
| |
Verify network name resolution of SQL Server virtual network name using PING of network name and FQDN |
| 2. Verify admin shares |
From each node, try to access the C$ and ADMIN$ shares of each of the other nodes. |
| 3. Verify network binding order |
- Click Start, point to Settings, click Control Panel, and then double-click Network and Dial-up Connections.
- On the Advanced menu, click Advanced Settings.
- In the Connections box, make sure that your bindings are in the following order, and then click OK:
-
- External public network
- Internal private network (Heartbeat)
- [Remote Access Connections]
The idea is to have the public network as the highest in the binding order.
|
| 4. Verify the cluster network priority and ensure that private network is for internal communications only. |
- Start Cluster Administrator.
- Click the cluster name at the root of Administrator. On the File menu, click Properties.
- On the Network Priority tab, verify that the private network is listed at the top. If it is not, use the Move Upbutton to increase its priority.
- Click the private network, and then click Properties.
- Click to select the Enable this network for cluster usecheck box.
- Click Internal cluster communications only (private Network).
The idea here is to make sure that the private network only carries internal cluster traffic and that it is listed as the #1 preferred network to carry that traffic.
Refer to http://support.microsoft.com/kb/258750 for this and the previous point.
|
| 5. Ensure that all the nodes are in perfect time synchronization with your DC |
Using NET TIME command you can check (and optionally set) the local time on each node. Failure to synchronize the time on the nodes will cause Kerberos authentication failures which in some cases can cause setup to fail. |
| 6. Verify that there are no ‘special’ characters in resource names |
Avoid the following special characters in the resource names:
- >
- <
- “
- ‘
- &
- (, )
- +
- Characters with a dieresis, a tilde, or a space character.
Reference: http://support.microsoft.com/kb/302491
|
| 7. Ensure all the physical disk resources in the cluster are online |
Though this issue primarily has been observed for SQL Server 2005, it may be a good idea to check it for all versions.
Reference: http://blogs.msdn.com/sqlserverfaq/archive/2008/12/17/sql-server-2005-setup-failing-to-install-on-cluster-with-unexpected-failure-while-performing-the-scc-checks.aspx |
| 8. Remote Registry |
Ensure that the remote registry service is started |
| 9. Service Account User Rights Assignment |
Ensure that your SQL Server service account has the following privileges:
- Act as part of the operating system (Microsoft Windows 2000 only
- Adjust memory quotas for a process
- Bypass traverse checking
- Log on as a batch job
- Log on as a service
- Replace a process-level token
- Lock Pages in Memory (Only for SQL Server Service account to use AWE on 32-bit)
Reference: http://support.microsoft.com/kb/283811, http://support.microsoft.com/kb/840219 and http://support.microsoft.com/kb/254321
|
| 10. Service Account should be member of local administrators |
Unfortunately the SQL Server 2000 program mandates this pre-requisite. But if you carefully follow the steps to assign the user rights, NTFS permissions and registry permissions as per the above mentioned KB articles, then you can change the account later on post setup. |
SQL Server 2005 specific points
| Checklist item |
Description |
| 1. Verify required services are started |
The following services must be started on both nodes:
- Task Scheduler
- Remote Registry
- COM+ System Application
- Server
- Cryptographic services
|
| 2. MSDTC cluster resource requirement |
If you are installing anything other than the database engine component on Windows Server 2003, then you must create the MSDTC resource in the cluster prior to running setup.
Reference: http://support.microsoft.com/kb/301600 |
| 3. Folder structure for installation files |
If you are installing from a network dump, make sure that the Servers and Tools sub-folders are preserved correctly. For example in the D:SQLServer2005 folder, create the following two subfolders:
|
| 4. Remote desktop connections on passive nodes. |
Except for the node from where the installation is being run, please log off from any Remote Desktop or Terminal Services sessions on all the other nodes. It may be a good idea to log off from the console session as well. |
| 5. Non-administrator Service Account |
The SQL Server 2005 service account need not be a member of local administrators. As long as it has the user rights (from point #9 in the previous table) assigned to it, it will work without any local administrative privileges. The SQL 2005 setup program automatically grants the necessary permissions and user rights to the service accounts chosen.
Reference: http://support.microsoft.com/kb/283811
|
Please let me know if you liked this article and if it was useful for your purposes, by rating the article and optionally providing any comments. If you have any questions as well please leave them as comments; I will respond to them!
Arvind Shyamsundar's technical blog 