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:
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:
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 http://go.microsoft.com/fwlink/?LinkId=69434. Specifically, look under Operations | High Availability | Cluster Continuous Replication.
I searched this info a long time. I just registered to say THANK TOU.
Did you notice the reference in the DPM V2 Product Information FAQ to support for Continuous Cluster
PingBack from http://exchangemct.com/blog1/2007/06/22/exhange-server-2007-resources/
PingBack from http://johnacook.wordpress.com/2008/06/22/even-more-ccr/
PingBack from http://www.unix86.org/?p=1051
About two-and-a-half years ago, I blogged about about a new feature in Exchange Server 2007 called Cluster