Article ID: 257905 - View products that this article applies to.
This article was previously published under Q257905
NoticeThis article applies to Windows 2000. Support for Windows 2000 ends on July 13, 2010. The Windows 2000 End-of-Support Solution Center
(http://support.microsoft.com/?scid=http%3a%2f%2fsupport.microsoft.com%2fwin2000)is a starting point for planning your migration strategy from Windows 2000. For more information see the Microsoft Support Lifecycle Policy
Windows Clustering reports details about changes in the cluster in a log file. If this file becomes corrupted for any reason, the Cluster service may not start. You may receive the following error message when you attempt to start the Cluster service:
The following events may be reported in the system event log:
Could not start the Cluster Service on Local Computer.
Error 1067: The process terminated unexpectedly.
Event ID: 1019
The error message can occur if the quorum log file (Quolog.log) cannot be found or read at Cluster service startup. This file must be readable to confirm that the cluster configuration on the local node is current. If the Cluster service cannot read the log, the service is not prevented from loading stale configuration data.
The log file may be corrupted if the time and date stamp of the Chkxxx.tmp file does not match the stamp of the Quolog.log file in the \MSCS folder on the quorum drive. The corruption can occur if you recently performed a restore operation, or if you experienced a power outage.
To resolve this issue, start the Cluster service with the -ResetQuorumLog switch:
You can restore the quorum from a backup source by restoring the system state on one of the nodes that contains the most recent changes that were made to the cluster. For more information about backing up and restoring cluster configuration information, click the following article number to view the article in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/248998/ )How to properly restore cluster information
Cluster database and registry managementEach node that participates in a cluster maintains a local copy of the cluster database in the %SystemRoot%\Cluster\Clusdb file. When the Cluster service starts for the first time on a node, an updated copy of the cluster database is created and maintained as a registry hive (HKEY_LOCAL_MACHINE\Cluster). When you restart the cluster server, the existing cluster hive is used and then updated.
The Cluster service replicates the cluster registry in a file located on the quorum resource. The checkpoint file is located at \Mscs\Chkxxx.tmp. Every time a checkpoint is taken in, a checksum record is logged to the \Mscs\Quolog.log file. The following events trigger cluster registry checkpointing:
Cluster log managementThe cluster server uses quorum logging to record changes to the cluster registry. Changes are tracked so that when cluster nodes rejoin the cluster that was offline, the nodes undergo all the modifications that were made to the cluster configuration while they were offline.
When you disable quorum logging within a cluster, changes to the cluster configuration cannot be logged. If a node goes offline during this period, recent changes may be lost if the changes cannot be communicated to the other node. Quorum logging should only be disabled when it is necessary to recover from log file corruption.
Quorum logging is turned on every time a node goes offline and a checkpoint is taken, and it is turned off when all cluster nodes are running. The Quolog.log file is located in the \Mscs folder on the quorum drive. When the cluster is formed, the latest \MSCS\Chkxxx.tmp file is used to load the cluster registry, by default. The \Mscs\Quolog.log file is used to apply all the changes to the cluster database since the last checkpoint. This algorithm applies even if the node was down for period of time.
For more information about the the KB872970 hotfix, click the following article number to view the article in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/872970/ )The quorum log file becomes corrupted in your Windows 2000 Advanced Server-based cluster environment