The following is a description of some of the switches:
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.
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
Collapse this tableExpand this table
No logging takes place.
Only errors are logged.
Errors and warnings are logged.
All events, including those not written to the event log,
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
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:
How to enable cluster logging in
Microsoft Cluster Server
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
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
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
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
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
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.
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:
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
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.
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.
scenarios: Use this switch when the quorum log file or checkpoint files
become corrupted and you want to manually replace these files with backup
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
net start clussvc
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
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
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.
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
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).