New File Share Witness and Force Quorum Guidance for Exchange 2007 Clusters
Published Apr 03 2008 01:29 PM 8,572 Views

In Exchange Server 2007 RTM and SP1, the Exchange team has published guidance for using a CNAME record in DNS as part of the provisioning process for the file share witness (FSW) component of a Majority Node Set (MNS) quorum on Windows Server 2003, and a Node and Share Majority quorum on Windows Server 2008. Specifically, we state the following in the documentation:

"We also recommend that you create a CNAME record in the Domain Name System (DNS) for the server hosting the share, instead of the actual server name. When creating the share for the file share witness, use the fully qualified domain name (FQDN) for the CNAME record instead of the server name because this practice assists with site resilience."
Upon review of this guidance, we have learned that its effects and success can be unpredictable in some environments. As a result, we decided to revisit this guidance, and after working closely with the Windows Cluster team on various site resilience scenarios, we have decided to revise our configuration guidance. In summary, we no longer recommend using a CNAME record as part of the FSW provisioning process. Instead of using a CNAME record and changing the FQDN for the target host to point to a server with a replacement FSW, in a backup site activation process, or in the reactivation process for a primary site, we now recommend using the Cluster service's built in "force quorum" capabilities. Background To illustrate exactly how this guidance is changing, consider a topology in which a two-node cluster continuous replication (CCR) environment is deployed across two physical sites: a primary datacenter and a backup datacenter, as shown below. In this example, the Active Directory Site named Redmond-Prod is stretched across two datacenters, Datacenter A, the production datacenter, and Datacenter B, a warm backup datacenter that has dedicated resources (global catalog, Client Access, Hub Transports) for the Redmond-Prod site. Datacenter B also contains a second Active Directory Site named Redmond-DR, which contains dedicated resources that can be moved from the Redmond-DR site to the Redmond-Prod site in Datacenter B. Focusing just on the cluster implementation, we have a two-node CCR environment that during normal production hours has the clustered mailbox server (CMS) hosted on NodeA in Datacenter A, and NodeB is the passive node residing in Datacenter B. The CCR environment is configured to use an MNS quorum with FSW. In this configuration, there are two options for the location of the file share used for the FSW: (1) locate the share on a server in Datacenter A, or (2) locate the share on a server in Datacenter B. The general recommendation in this configuration is to use a share on a Hub Transport server in Datacenter A that is in the same Active Directory Site as the CMS. In addition, to save time during the process of activating Datacenter B, we also recommend staging a replacement share for the FSW on a Hub Transport server in Datacenter B, as shown below. If Datacenter A fails or is otherwise unavailable, and Datacenter B is to be activated, our original guidance called for quickly switching over to a replacement share for the FSW by changing the FQDN of the target host for the FSW CNAME record in DNS from that of the Hub Transport server in Datacenter A to the Hub Transport server in Datacenter B. For example, say you have the following:
  • A CMS named EXMBX1 in a CCR environment in the Redmond-Prod Site located in Datacenter A.
  • EXHUB1 in the Redmond-Prod Site located in Datacenter A. It has been provision with a file share named FSW_EXMBX1, which will be used for the FSW for EXMBX1.
  • EXHUB2 in the Redmond-DR Site located in Datacenter B. It has been provision with a file share named FSW_EXMBX1, which will be used for the FSW for EXMBX1 when Datacenter B takes over for Datacenter A.
Instead of configuring the MNS quorum with FSW to use a path of \\EXHUB1\FSW_EXMBX1 for the witness share, our original guidance was to:
  1. Configure a CNAME record in DNS, using an alias of EXMBX1FSW.
  2. Configure the CNAME record to initially point to EXHUB1.
  3. Configure a file share on EXHUB1 and on EXHUB2 called FSW_EXMBX1.
  4. Configure the MNS quorum with FSW to point to \\EXMBX1FSW\FSW_EXMBX1.
  5. When Datacenter B is being activated, reconfigure the CNAME record to point to EXHUB2.
Why Change this Guidance? While the practice of changing the FQDN of the target host for a CNAME record in DNS in order to redirect a Windows failover cluster configured with an MNS/FSW quorum to a replacement witness share does work, we no longer believe it to be the best option in these environments. Effectively, the original guidance was a bit of a trick that was designed to "out-smart" the FSW quorum using DNS sleight of hand. While the trick works well and does not appear to have caused any known issues, we do know that larger, more complex DNS topologies, particularly those in which DNS replication or convergence can take a while, can make this trick prone to unpredictable behavior. And as you know, DNS issues for Active Directory, Exchange, or Windows can cause all sorts of problems. New Guidance The new guidance for these configurations is to use the built-in "force quorum" capabilities provided by the Cluster service to use a standby share on another Hub Transport server that is located in the datacenter that is being activated. This new guidance applies to both Windows Server 2003 and Windows Server 2008, and to both CCR and single copy clusters (SCC) that use a Majority Node Set with File Share Witness quorum (Windows 2003) or a Node and Share Majority quorum (Windows 2008). Using the example topology above, the new guidance is as follows: Windows Server 2003 Clusters
  1. Provision a new share for FSW on EXHUB2 in Datacenter B (if this is not already done).
  2. Force quorum on NodeB in Datacenter B by adding the following registry value to the node: HKLM\System\CurrentControlSet\Services\ClusSvc\Parameters REG_SZ: ForceQuorum Value: NodeB
  3. Start the Cluster service on NodeB in Datacenter B by running the following command: net start clussvc
  4. Reconfigure the cluster quorum to use the FSW share on EXHUB2.
  5. Take the clustered mailbox server offline.
  6. Remove the registry value, and then reboot NodeB.
  7. Start the clustered mailbox server.
To re-activate NodeA in Datacenter A:
  1. Provision a new share on EXHUB1 in Datacenter A.
  2. Bring NodeA online.
  3. Reconfigure the cluster quorum to use the FSW share on EXHUB1.
  4. Stop the clustered mailbox server.
  5. Move the Cluster Group from NodeB to NodeA.
  6. Move the clustered mailbox server from NodeB to NodeA.
  7. Start the clustered mailbox server.
Windows Server 2008 Clusters
  1. Provision a new share for FSW on EXHUB2 in Datacenter B (if this is not already done).
  2. Force quorum on NodeB in Datacenter B by running the following command on NodeB: net start clussvc /forcequorum
  3. Use the Configure Cluster Quorum Settings wizard to configure the Node and Share Majority to use the FSW share on EXHUB2.
  4. Reboot NodeB.
  5. Start the clustered mailbox server.
To re-activate NodeA in Datacenter A:
  1. Provision a new share on EXHUB1 in Datacenter A.
  2. Bring NodeA online.
  3. Use the Configure Cluster Quorum Settings wizard to configure the Node and Share Majority to use the FSW share on EXHUB1.
  4. Stop the clustered mailbox server.
  5. Move the Cluster Group from NodeB to NodeA.
  6. Move the clustered mailbox server from NodeB to NodeA.
  7. Start the clustered mailbox server.
Do I need to change my existing configuration? This updated guidance is for new deployments. There is no urgency or recommendation to reconfigure existing deployments that are using the original guidance of changing a CNAME record in DNS for switching to a replacement file share for the FSW. However, in the event that you do activate a backup datacenter, we do recommending decommissioning the use of the CNAME record and configuring the UNC path for the file share to use actual server names. What About the TechNet Documentation? We are in the process of updating several topics in the Exchange Server 2007 Library on TechNet (aka, the Exchange TechCenter). The documentation being updated with this new guidance is expected to be published with the May 08 documentation refresh, and it includes: The following topics have been updated to remove the old guidance, and they are published with the April 08 documentation refresh: - Scott Schnoll
11 Comments
Version history
Last update:
‎Jul 01 2019 03:36 PM
Updated by: