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:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.