We’ve been spending a lot of time in the Azaleos engineering team trying to select the correct approach to supporting business continuity needs with Exchange 2007.

Hypothetically, using Cluster Continuous Replication (CCR), customers can deploy stretch clusters for Exchange 2007. This is where Active and Passive nodes of a server cluster are deployed at geographically disperse sites. But do you really want to do this?

Exchange 2007 offers the following options for business continuity and disaster recovery:

1. Use new Cluster Continuous Replication (CCR) feature in a stretch cluster configuration. This ships log files from the active to passive Exchange cluster nodes, replaying them on passive nodes to synchronize mail store databases across the cluster nodes
2. Use older proven standby recovery cluster (with local CCR or newly named Single Copy Cluster - SCC for local high availability) with volume snapshots (preferably hardware based)using Volume Shadow Copy services in Windows server, and then mirroring/replicating those snapshots to a second site.
3. Use third party software based solutions (Veritas, etc...)

Cluster Continuous Replication seems to require a Majority Node Set (MNS) Windows cluster configuration which means you always need a majority of nodes to be in communication to have an operational cluster.

That said, I think many people misunderstand Majority Node Set (MNS) with file share witness and what that means to them:

1. Every server/node presents a share of their local disk quorum: See Technet article
2. The file share witness (introduced with Windows Server 2003 SP1) acts as an additional node that allows ties to be broken, i.e. two node A/P cluster can be deployed with a network file share to break the tie (removes requirement of third node running Windows enterprise effectively for A/P two node cluster). See KB article
3. In one scenario we could use either a SAN (with CIFS support) or one of the systems hosting the Exchange 2007 Hub Transport or Client Access Servers role to serve as the third node to avoid requiring yet another Windows enterprise server license

Where should you deploy the file share witness?

1. Right next to your two nodes with equal bandwidth/connectivity – this seems perfectly fine and makes sense in removing the shared storage (twin tail or SAN) requirement for clustering
2. At the primary site - if you do this with equal node distribution (same number of nodes at each site) stretch cluster and deploy it locally to one site (let's say primary for argument), then you have no automated disaster recovery capability as the backup site nodes will not constitute a majority node set and will hence shut themselves down in case of primary site failure
3. An independent site share (i.e. a third site with equal connectivity to both sites) which is probably not an option for most companies

I think the implication of the above is that Microsoft Exchange 2007 CCR clustering is still not practical for geographically separated hosting facilities except under exceptional circumstances (super good connectivity), even with Exchange 2007.

CCR clustering is still good for localized high availability with benefits over SCC of protecting against mail store database corruption and reducing user impact of backups. This comes at the cost of effectively doubling database storage requirements.

In summary, I believe the most widely applicable solution for Microsoft Exchange business continuity and disaster recovery continues to be standby servers with snapshot based storage mirroring/replication across geographically diverse sites.

Ronald Woan
Director of Development
Azaleos Corporation