Cluster service startup options (258078)

MORE INFORMATION

• Debug
  
  Function: Cluster logging may not contain any helpful information in diagnosing Cluster service to start failures. This is because the Cluster service may fail prior to the Cluster.log starting. Starting the Cluster service with this switch displays the initialization of the Cluster service and can help you identify these early occurring problems.
  
  Requirements: Use this switch for temporary diagnostic purposes only. If the Cluster service fails to start because of a logon error of the service account, or another system-related error, the service may not have a chance to run. As a result, a cluster.log file may not be created. This method runs the service outside the normal environment given by the Service Control Manager. To use this switch, you must be logged on locally with administrative rights and start the command from the command prompt. Do not use the debug switch for normal use or for any length of time. The service does not run as efficiently with the option set.
  
  Usage scenarios: This switch must be used only when the Cluster service fails to start up. This switch will display on the screen the operation of the Cluster service as it tries to start. This switch can only be used when starting the service from the command prompt, and you must be in the folder where the Cluster service is installed. By default, this is %SystemRoot%\Cluster. This is also the only switch that you do not use with the net start command to start the service.
  
  Operation: Open a command prompt, change to the %SystemRoot%\cluster folder, and then type the following

  clussvc /debug [loglevel#]"

  where loglevel# is one of the following.

  #	Description
  0	No logging takes place.
  1	Only errors are logged.
  2	Errors and warnings are logged.
  3	All events, including those not written to the event log, are logged.

  Alternatively, you can also use the set command to control the cluster log level when you use the debug switch. From the command prompt, type the following

  set clusterloglevel=x

  where x is one of the values that is shown in the previous table.
  
  The Cluster service sends output to the window similar to what you would see in the cluster.log. Alternatively, you can also capture this information to a file by using the following command syntax:
  

  clussvc /debug > c:\debug.log

  When the Cluster service is running correctly, press CTRL+C to stop the service.
  
  Note You can use the ClusterLogLevel environment variable to control the output level when you use the debug switch. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

  168801 How to enable cluster logging in Microsoft Cluster Server

• FixQuorum
  
  Function: Lets the cluster service start up despite problems with the quorum device. The only resources that will be brought online once the service is started is the Cluster IP Address and the Cluster Name. You can open Cluster Administrator and bring other resources online manually.
  
  Requirements: This switch MUST be used only in diagnosis mode on a very temporary basis and not during normal operation. Only 1 node must be started up using this switch and a second node must not be attempted to be joined to the node started up using this switch. Typically, this switch is used alone.
  
  Usage scenarios: If the cluster service is unable to start up in the normal way due to the failure of the quorum resource, users can start up the cluster service in this mode and attempt to diagnose the failure.
  
  Operation: After the cluster service is started up, all resources including the quorum resource remain offline. Users can then manually try to bring the quorum resource online and monitor the cluster log entries as well as the new event log entries and attempt to diagnose any problems with the quorum resource. The syntax is as follows:

  net start clussvc /fixquorum

• ResetQuorumLog
  
  Function: If the quorum log and checkpoint file is not found or is corrupt, this can be used to create files based on the information in the local node's %SystemRoot%\Cluster\CLUSDB registry hive. If the quorum log file is found to be in proper order, this switch has no effect.
  
  Requirements: Typically, only one node is started up by using this switch, and this switch is used alone. It must be used only by experienced users who understand the consequences of using information that is potentially out of date, to create a new quorum log file.
  
  Usage scenarios: This switch must be used only when the Cluster service fails to start up on a Windows 2000 or later machine due to a missing or corrupted quorum log (Quolog.log) and Chkxxx.tmp files. Windows NT 4.0 will automatically re-create these files if they do not exist. This functionality was added in Windows 2000 to give more control over the start of the Cluster service.
  
  Note If the cluster is running Windows 2000 Sservice Pack 4 (SP4) and the hotfix 872970 has previously been installed, /resetquorumlog is no longer needed. The default behavior is to create a new log file at startup if the old one is missing or corrupt.
  
  Operation: The Cluster service does an auto-reset of the quorum log file if it is found to be missing or corrupted by using the information in the currently loaded cluster hive by using the file %systemroot%\Cluster\CLUSDB. The syntax is as follows:

  net start clussvc /resetquorumlog

• DebugResMon
  
  Function: Helps you to debug the resource monitor process and, therefore, the resource dynamic-link libraries (DLLs) that are loaded by the resource monitor. You can use any standard Windows-based debugger.
  
  Requirements: Can only be used when the cluster service is started from the command prompt and when using the debug switch. There is no equivalent registry setting that can be used when Cluster service is run as a service. Debugger must be available for attaching to the resource monitor when it starts up. Typically, this switch is used alone.
  
  Usage scenarios: Developers can use this switch to debug the resource monitor process and their custom resource DLLs. This option is extremely useful if a bug in a resource DLL causes the resource monitor process to quit unexpectedly soon after it is started up by the Cluster service and before users can manually attach a debugger to the resource monitor process.
  
  Operation: Just before the resource monitor process is started up, the Cluster service process waits with a message "Waiting for debugger to connect to the resmon process X," where X is the Process ID (PID) of the resource monitor process. The Cluster service does this waiting for all resource monitor processes created by it. After the user attaches a debugger to the resource monitor process, and the resource monitor process starts up, the Cluster service continues with its initialization.
• NoRepEvtLogging
  
  Function: The norepevtlogging switch prevents replication of those events recorded in the event log. This switch is useful in reducing the amount of information displayed in the command window by filtering out events already recorded in the event log. Event log replication is a feature that was added in Windows 2000.
  
  Usage scenarios: This switch is used to prevent replication of the event logs. If there is a large number of event log entries, the Cluster service will replicate these, and log these to the cluster.log. This can cause the cluster.log to wrap quickly. The switch can also be used to start the Cluster service and log those events that are not recorded in the event log to a local file, Debugnorep.log. The syntax is as follows:

  clussvc /debug /norepevtlogging > c:\debugnorep.log\

  Operation: The norepevtlogging command can be set as a start parameter when starting the Cluster service from the Computer Management console.
  
  The command-line syntax is:

  net start clussvc /norepevtlogging

  This command prevents the node that was started with this switch from replicating its information to other nodes, but it will still receive information from other nodes that were started normally.
• NoQuorumLogging
  
  Function: Turns off all logging of the cluster registry changes to the quorum disk. Registry check pointing does not effect other resources.
  
  Requirements: This switch must be used only in diagnosis mode to diagnose problems with the quorum log file (Quolog.log) or the cluster hive checkpoint file (Chkxxx.tmp) in the \MSCS directory on the quorum drive. If one node is started up by using this switch, any other node must also be started up by using this switch. Typically, this switch is used on one node alone.
  
  Usage scenarios: Use this switch when the quorum log file or checkpoint files become corrupted and you want to manually replace these files with backup copies.
  
  Operation: The Cluster service completely bypasses the logging functionality in this case. When run in this mode, "partition-in-time" scenarios can occur. If this is the case, cluster node registry entries can fall out of synchronization, and new changes can be lost. The syntax is as follows:

  net start clussvc /noquorumlogging

• ForceQuorum
  
  Function: When you use a Majority Node Set (MNS) quorum model on a Windows Server 2003 cluster, in some cases a cluster must be allowed to continue to run even if it does not have "quorum" (majority). Consider the case of a geographically dispersed cluster with four nodes at the "primary" site and three nodes at the "secondary" site. While there are no failures, the cluster is a seven-node cluster where resources can be hosted on any node, on any site. If there is a communications failure between the sites or if the secondary site is taken offline (or fails), the primary site can continue because it will still have quorum. All resources will be re-hosted and brought online at the primary site.
  
  In the event of a catastrophic failure of the primary site, however, the secondary site will lose quorum, and, therefore, all resources will be terminated at that site. One of the primary purposes for having a multi-site cluster is to survive a disaster at the primary site; however, the cluster software itself cannot make a determination about the state of the primary site. The cluster software cannot differentiate between a communications failure between the sites and a disaster at the primary site. That must be done by manual intervention. In other words, the secondary site can be forced to continue even though the Cluster service believes it does not have quorum. This is known as forcing quorum.
  
  Because this mechanism is effectively breaking the semantics associated with the quorum replica set, it must only be done under controlled conditions. In the example above, if the secondary site and primary site lose communication and an administrator forces quorum at the secondary site, resources will be brought online at BOTH sites, thus allowing the potential for inconsistent data or data corruption in the cluster.
  
  Requirements: Forcing quorum is a manual process that requires that you stop the Cluster service on ALL the remaining nodes. The Cluster service must be told which nodes should be considered as having quorum.
  
  Usage scenarios: Special care must be taken if and when the primary site comes back because the nodes are configured as part of the cluster. While a cluster is running in the force quorum state, it is fully functional. For example, nodes can be added or removed from the cluster; new resources, groups, and so forth can be defined.
  
  Note The Cluster service on all nodes NOT in the force quorum node list must remain stopped until the force quorum information is removed. Failure to do so can lead to data inconsistencies OR data corruption.
  
  Operation: Set up the Cluster service startup parameters on ALL remaining nodes in the cluster. This is done by starting up the Services control panel, selecting the Cluster service, and then entering the following in the Start parameters option:

  net start clussvc /forcequorum node_list

  For example, if the secondary site contains Node5, Node6, and Node7, and you wanted to start the Cluster service and have those be the only nodes in the cluster, use the following command:

  net start clussvc /forcequorum /forcequorum node5,node6,node7

  Note There should be no spaces in the key (except where there are spaces in the node names themselves).