Exchange 2007 Cluster Continuous Replication: Can I Get a Witness?

As of today, you can!  A file share witness, that is.  Let me start from the beginning.

Exchange Server 2007 introduces a new feature called cluster continuous replication (CCR).  CCR combines the log shipping and replay functionality in Exchange 2007 with the failover functionality in the Microsoft cluster service (MSCS). Unlike previous versions of Exchange that also supported clustering, CCR does not require shared storage. Instead, each node in the cluster has it own locally connected storage (e.g., SAS, DAS, iSCSI). On the active node in the cluster is the production clustered mailbox server (CMS). On the passive node is a relatively up-to-date copy of the CMS that is created and maintained by log shipping and replay.

Because CCR does not use shared storage for the Exchange data, we wanted to make sure we didn’t need shared storage anywhere in the cluster. The only other resource in the cluster besides the CMS is the default cluster group, which contains the quorum resource. To eliminate the need for shared storage to host the quorum resource, Exchange 2007 supports the Majority Node Set (MNS) quorum.

Traditionally, MNS is a three-node solution where one of the nodes is known as a “voter” node. One purpose of the voter node is to prevent a condition known as a split brain syndrome, where each node in the cluster thinks it is in charge of the cluster.  Another purpose is to prevent a problem that is known as a partition in time. I won’t got into detail here, but lets just from the cluster’s perspective, both problems are tantamount to world chaos.

But requiring three cluster nodes for a CCR solution does not exactly help reduce costs of ownership, which is one of the original themes for Exchange 2007. So enter a new type of MNS quorum – the MNS quorum with file share witness. The MNS quorum with file share witness means that CCR only requires two cluster nodes. The voter node requirement is replaced with the new file share witness variant to the MNS quorum.

The Exchange team worked very closely with the Windows Cluster team to create a new type of quorum device based on the MNS quorum model. Instead of using a third voter node, a file share on a non-clustered system is used. We recommend that a share on a Hub Transport server be used.

The Windows Cluster team delivered the new quorum device in the form of a QFE (hotfix), which is documented in Knowledge Base article 921181. The QFE, which requires Windows Server 2003 with Service Pack 1 or Windows Server 2003 R2 in order to be installed, actually contains two significant updates for MSCS:

  1. File share witness. The file share witness feature is an improvement to the current MNS quorum model. This feature lets you use a file share that is external to the cluster as an additional “vote” to determine the status of the cluster in a two-node MNS quorum cluster deployment.
  2. Configurable cluster heartbeats. The configurable cluster heartbeats feature enables you to configure cluster heartbeat parameters. This may help avoid unnecessary cluster failovers. These failovers occur because of a temporary network problem that may cause packets to be dropped or delayed. The configurable cluster heartbeats feature may help in an environment where cluster nodes are geographically dispersed.

Knowledge Base article 921181 goes into a lot of detail on the new private MNS resource configuration properties that are added by the new file share witness feature, including MNSFileShare, MNSFileShareCheckInterval, and MNSFileShareDelay. It also contains details on configurable heartbeats, as well as step-by-step instructions for configuring heartbeats.

Once you’ve obtained the QFE and after you’ve finished reading 921181, the process for creating an MNS quorum with file share witness for use with CCR is as follows:

  1. Before the cluster has been formed, install the QFE on each node, one at a time. Each node will need to be restarted at the installation in order to complete the installation. Once both nodes in the cluster has the QFE installed, proceed to step 2.
  2. Form a new cluster with an MNS quorum.
  3. Create and permission the file share. Login as an administrator on the machine that is going to host the file share (we recommend that you use a Hub Transport server for the share) and perform steps 4, 5 and 6:
  4. Start a command session and make a directory to be the share. We recommend following the following naming convention: MNS_FSQ_DIR_<clustername>.  This can be done with the following command: mkdir <shareDirectory>.  For example, mkdir C:\MNS_FSQ_DIR_EXCLUS.
  5. Create the share by running the following command (we recommend using the following naming convention MNS_FSQ_<clusterName>): net share <shareName>=<shareDirectory> /GRANT:<ClusterServiceAcccount>,FULL.  For example, net share MNS_FSQ_EXCLUS=C:\MNS_FSQ_DIR_EXCLUS /GRANT:DOMAIN\CLUSSVC,FULL.
  6. Permission the share by running the following command: cacls <shareDirectory> /G BUILTIN\Administrators:F <ClusterServiceAccount>:F.  For example, cacls C:\MNS_FSQ_DIR_EXCLUS /G BUILTIN\Administrators:F ClusSvc:F.
  7. Next, configure MNS to use the file share. The share name is stored in a property on the MNS resource.  The name of the resource can be changed by an administrator but the default is “Majority Node Set”.  To set the property perform the following operation from a command prompt use the following command: Cluster res “Majority Node Set” /priv MNSFileShare=<UNCPathtoShare>.  For example if the server name is e2k7 and the share name is MNS_FSQ_EXCLUS, then the command would be:

    Cluster res “Majority Node Set” /priv MNSFileShare=\\E2K7\MNS_FSQ_EXCLUS

    When this command completes an error message is produced.  The message indicates that the resource must be restarted to have the change take effect.  The following command will accomplish this: Cluster group “Cluster Group” /move

  8. Perform the command a second time to complete the configuration of the MNS File Share Witness. To check that the property run the following command: Cluster res “Majority Node Set” /priv

Once the MNS quorum with file share witness is created and validated, you can configure the cluster heartbeat as desired using the instructions in Knowledge Base article 921181.

Then, proceed with the installation of Exchange 2007 in a CCR environment. For detailed instructions on how to do that, see the online content at Specifically, look under Operations | High Availability | Cluster Continuous Replication.

Comments (12)

  1. Anonymous says:

    Enjoy and have a nice weekend!&amp;nbsp;

    RIM Will Face A Tough Sell For Its Hosted BlackBerry Service…

  2. Anonymous says:

    A new quick fix download is available from Microsoft for Windows Server 2003 or the R2 Edition –;amp;DisplayLang=en

  3. Anonymous says:

    A new quick fix is available from Microsoft for Windows Server 2003 or the R2 Edition –;amp;DisplayLang=en

  4. Anonymous says:

    I searched this info a long time. I just registered to say THANK TOU.

  5. Anonymous says:

    Did you notice the reference in the DPM V2 Product Information FAQ to support for Continuous Cluster

  6. Anonymous says:

    About two-and-a-half years ago, I blogged about about a new feature in Exchange Server 2007 called Cluster

  7. cnschindler says:

    I assume that the cluster fix will be included in SP2 for Windows Server 2003 and the feature be available in Longhorn Server, right? Christian

  8. Scott Schnoll says:

    Christian, yes this update is slated for inclusion with SP2.  I don’t know about Longhorn server, though, so I will have to check and post back here with my findings.