SUMMARY
This step-by-step article describes how to troubleshoot SQL Server 2000 Virtual Server setup failures. SQL Server 2000 Virtual Server setup operations might stop responding and you receive the following error message:
Setup failed to perform required operations on the cluster nodes.
This error message does not indicate which sub-operation in Setup stopped responding or why the failure occurred. This article will help you to troubleshoot Setup failures and it will show you how to look at various logs and to identify the appropriate error message information.
You can also use the information in this article to troubleshoot a SQL Server 2000 Virtual Server service pack setup. The only difference between a virtual server setup and a service pack setup is in the naming convention that Setup uses for the log files. A virtual server setup process creates log files that start with the characters "Sqlstp." For example: Sqlstp.log, or Sqlstp0.log.
A service pack setup log starts with the characters "Sqlsp." For example: Sqlsp.log, or Sqlsp0.log.
back to the top
Understanding the SQL Server 2000 Virtual Server Setup Process
SQL Server 2000 Virtual Server Setup involves the following processes:
- An interactive setup process where the configuration information for a virtual server is gathered from the user. There is only one operation such as this for a virtual server setup. This process starts unattended setup operations on each node of the cluster that is configured for the virtual server that you are setting up. After the unattended setup operations return successfully, Setup creates the virtual server resources that help you manage the server.
- The interactive setup process to install SQL Server on each node of the cluster creates one or more unattended setup operations. The number of these operations, which is each completed by a separate thread, is equal to the number of nodes that are part of the virtual server configuration. The unattended setup process that is running on the node where the virtual server setup process is initiated creates databases on a shared drive and runs initial configuration scripts. The unattended setup process on all the other nodes that are also part of the virtual server configuration involves copying the required binaries and registering components that must run SQL Server on the node.
Overview of Virtual Server Setup Log Files
Each of the preceding operations has a unique log file. All log files for a virtual server setup are created in the default Windows directory (
WINDIR). This article uses C:\WINNT to represent the default Windows directory in the following examples. The interactive setup operation creates the Sqlstp.log log file on the node where the virtual server setup is initiated. This log file is overwritten every time that the virtual server setup is started, which means that you can only see the last installation attempt log file. The unattended setup operations create log files with the naming format Sqlstp
N.log (where
N is an integer) on each node where the unattended setup is run. These log files are given incremental names and there can be up to 100 of these log files at any given time. The following examples demonstrate the file naming convention.
A failed virtual server setup can be caused by an error in any of the preceding operations. You must look at each log file to identify the error message and the resulting failed operation. The error message that you find in one of the log files can help you to troubleshoot the failed setup process.
Example 1
Consider a cluster with the node names NODEA, and NODEB. If you initiate a virtual server setup process from NODEA to create a virtual server that is configured to run on both nodes, there is an interactive setup process on NODEA that creates an SQLSTP.log file in the C:\WINNT folder on NODEA. The interactive setup process then creates two unattended setup operations on both NODEA and NODEB. Each unattended setup process creates an Sqlstp0.log file in the C:\WINNT folder of each node on which the unattended setup is running. The following is a summary of the log files that will be available:
- The Sqlstp.log file in C:\WINNT on NODEA. This log file corresponds to the interactive virtual server setup process.
- The Sqlstp0.log file in C:\WINNT on NODEA. This log file corresponds to the unattended setup process that ran on NODEA.
- The Sqlstp0.log file in C:\WINNT on NODEB. This log file corresponds to the unattended setup process that ran on NODEB.
Example 2
Consider a cluster with the node names NODEA and NODEB. Assume that this is your second attempt to install a virtual server on the cluster. For this example, also assume that the previous attempt to install a virtual server failed and did not create a remote unattended setup for NODEB. The following files already exist before you try the virtual server setup because of the previous failed setup attempt:
- C:\WINNT\Sqlstp.log and C:\WINNT\Sqlstp0.log on NODEA.
- No setup log files exist on NODEB because there was no unattended setup run on NODEB in the previous failed setup attempt.
After the second attempt to install a virtual server, you have the following log files available:
- The Sqlstp.log file in C:\WINNT on NODEA. This log file corresponds to the interactive virtual server setup process.
- The Sqlstp1.log file in C:\WINNT on NODEA. This log file corresponds to the unattended setup process that ran on NODEA.
- The Sqlstp0.log file in C:\WINNT on NODEB. This log file corresponds to the unattended setup process that ran on NODEA.
IMPORTANT:
- The interactive setup process overwrote the Sqlstp.log file from the previous virtual server setup attempt. Every attempt to install a virtual server from a node on the cluster creates a new Sqlstp.log file.
- The unttended setup operations do not create log files with the same name on both the nodes. For example, they are named as Sqlstp1.log on NODEA and Sqlstp0.log on NODEB. The log file name is completely dependent on the last SqlstpN.log file on the node. A log file named Sqlstp(N+1).log is created on each node.
A virtual server setup process also involves creating virtual server resources that are used to manage the virtual server from Cluster Administrator. This occurs after the unattended setup processes complete successfully on all the involved nodes. This step of Setup writes detailed messages to the Cluster.log file (which, by default, is located in C:\WINNT\CLuster) on the node from which the virtual server Setup is run.
Troubleshooting Tip:
For the latest setup information, view the Sqlstp.log file for the interactive setup information from the node where Setup was initiated and the highest numbered Sqlstp
N.log for the unattended setup information on each of the nodes.
back to the top
Troubleshooting
The first step in troubleshooting a virtual server setup failure is to identify the error message that is written to one of the log files that are described in the
Understanding SQL Server 2000 Virtual Server Setup Process section in this article. After you identify the error, use keywords in the error message to perform a search on the Microsoft Knowledge Base to find more detailed information about the error, and the workarounds or resolutions (or both) to the problem. The two examples in the
Examples of Troubleshooting Virtual Server Setup Failures section helps to identify the error message from the logs and includes additional information by providing links to articles in the Microsoft Knowledge Base.
back to the top
Examples of Troubleshooting Virtual Server Setup Failures
The following examples describe how to use the information in the setup logs, which are created during a virtual server setup, to troubleshoot a failed Setup.
Example 1
This example demonstrates how to troubleshoot the problem that is addressed in the following Microsoft Knowledge Base article by using the log files that are discussed in this article:
318672 BUG: Error Message: 'Setup Failed to Perform the Required...'
If this problem occurs on a virtual server setup, Setup fails and you receive the error message "Setup failed to perform required operations on the cluster nodes."
- Collect the latest Setup logs:
- Sqlstp.log from the node from which you ran the virtual server setup.
- SqlstpN.log from the nodes that you configured for the virtual server.
- Sqlstp.log will have the following error footprint that indicates that the remote unattended setup process on NODE2 stopped responding:
CThreadPool::RunUntilCompleteHlpr WaitForMultipleObjects returned: 0
CThreadPool::RunUntilCompleteHlpr signaled thread [0xa4]
Thread [0xa4] exit code: [0x0]
CRemoteProcess::RunUntilComplete [0xa8] exit code: 2
Remote process exit code was '2' (NODE2).
- With the knowledge that Setup on NODE2 stopped responding (which you know from the "Remote process exit code was '2'" line), you can now look at the SqlstpN.log from NODE2 where you see the following error footprint:
13:50:08 Begin Action: ShowDlgInstanceName
13:50:20 End Action: ShowDlgInstanceName
13:50:20 ShowDlgInstanceName returned : -1
13:50:20 ShowDlgInstanceName: GetLastError returned: 50044
{....}
13:50:20 Installation Failed.
- To resolve this problem, view the following article in the Microsoft Knowledge Base:
Search by using the string " ShowDlgInstanceName: GetLastError returned: 50044". This article includes the complete documentation for this problem.
NOTE: When you search for information with error messages, make sure that the search strings do not include environment specific information such as computer names or domain names.
In Example 1, you learn how to start with only the generic error message, identify the underlying problem, and then with the help of the Microsoft Knowledge Base article, obtain workarounds and resolutions to the problem.
Example 2
This example demonstrates how to troubleshoot the problem that is addressed in the following Microsoft Knowledge Base article by using the log files that are discussed in this article:
312584 FIX: Setup May Fail with 'Setup is in resume...' Error Message
If the problem that is described in Q312584 occurs on a virtual server setup, Setup fails and you receive the "Setup failed to perform required operations on the cluster nodes" error message.
- Collect the latest Setup logs:
- The Sqlstp.log file from the node from which you ran the virtual server setup.
- The SqlstpN.log file from the nodes that you configured for the virtual server.
- Sqlstp.log will have the following error footprint that indicates that the remote unattended setup process on NODE2 stopped responding:
13:42:24 Begin Action : GetRemsetupRetCode
13:42:24 Installation return status on NODEA : 0
13:42:24 Installation return status on NODED : 0
13:42:24 Installation return status on NODEB : 0
13:42:24 Installation return status on NODEC : 2
13:42:24 End Action : GetRemsetupRetCode #### SQL Server Remote Setup - Start Time 05/24/01 13:37:36 ####
- With the knowledge that setup on NODEC stopped responding (which the "return status on NODEC : 2" line indicates), you can look at the SqlstpN.log from NODEC where you see the following error footprint:
13:38:41 Name = NODEC, Type = 0x2000000a
13:38:41 Setup is in resume mode in some of the cluster nodes. Only local install is allowed.Click yes to Continue.
13:38:41 End Action DialogShowSdMachineName
13:38:41 End: ShowDialogs()
13:38:41 Action CleanUpInstall:
13:38:41 StatsGenerate returned: 2
13:38:41 StatsGenerate (0x0,0x0,0xf00000,0x0,1033,0,0x0,0x2000000a,0,0,0
13:38:41 StatsGenerate -1,)
13:38:41 Installation Failed.
- To resolve this problem, view the following article in the Microsoft Knowledge Base:
312584 FIX: Setup May Fail with 'Setup is in resume mode in some of the cluster nodes' Error Message
Search by using the string "Setup is in resume mode in some of the cluster nodes. Only local install is allowed.Click yes to Continue." This article includes the complete documentation for this problem.
NOTE: When you search for information with error messages, make sure that the search strings do not include environment specific information such as computer names or domain names.
In Example 1 and Example 2, you learn how to how to troubleshoot a virtual server Setup failure. You can also apply the same troubleshooting technique to a service pack Setup failure.
back to the top