“The time has come,” the Walrus said,
“To talk of many things:
Of shoes–and ships–and sealing-wax–
Of cabbages–and kings–
And why the sea is boiling hot–
And whether pigs have wings.”
– Lewis Carol, Through the Looking-Glass and What Alice Found There

Over the course of the last 18 months, many more clients have been experimenting with the new data protection technologies in Exchange 2007, most notably Cluster Continuous Replication (CCR) and Server (or Standby) Continuous Replication (CCR).  These tools were included with Exchange 2007 RTM and SP1 respectively, and celebrated a milestone in the history of Exchange Server.  Microsoft recognized that to get more companies to switch to, or stick with, Exchange Server, a compelling story for data protection had to be introduced - in much the same way as the Walrus and the Carpenter needed to create stories to convince their oyster friends to follow them.  Hopefully, it’s not to the same end as the Walrus and the Carpenter (you can read the entire narrative poem here), but at least in theory, they are the same.

As an Exchange Engineer, I find these new features not only welcome, but laud Microsoft for finally acknowledging that tape backup is not the be-all and end-all of Exchange recovery solution sets, and that Single Copy Clusters (SCC) do not provide the data redundancy that is a requirement of most organizational DR plans.  Now, as this is a blog about Double-Take, these last two paragraphs may sound odd, but read on Macduff.

Double-Take has always prided itself on working closely with Microsoft and 3rd party technologies to augment what they are doing and filling in the gaps that inevitably result when a single solution is applied to the varied requirements of different companies.  These newer technologies for Exchange Server follow that pattern, and we at Double-Take are more than ready to help clients achieve the solution they need, rather than just settling for the solutions provided by CCR and SCR alone.

CCR is a superb tool for many organizations to use to create a Microsoft Exchange Failover Cluster without having a single-point of failure.  In Server 2003, you are still limited to a single subnet configuration, and so while CCR will provide an Active/Passive redundancy for both data and servers, it will not assist with cross-site failover without expensive and complicated WAN-stretching technologies.  In Server 2008, the subnet limitations are gone, but you are still limited to very strict requirements (like Active Directory being at certain levels and only allowing certain cleared configurations), and therefore many clients will still prefer to create a CCR cluster locally within one datacenter.

SCC - or Single Copy Cluster - is the replacement terminology for traditional Microsoft Clustering, can comes with all of the same limitations and liabilities of shared-disk clustering.  As such, it does not make the best solution for multiple site failover operations.

SCR is another story, but one that deserves to be addressed.  SCR allows for log-shipping replication to occur between two Exchange Servers.  They may be on different subnets, in the same site, or really anywhere you have enough bandwidth to support the procedure.  The major misconception, however, is that SCR contains a failover solution set. It does *not* offer this feature, but rather relies on a totally different system - Database Portability - to handle moving users to the secondary system after a failure.  So while it could be used to replicate an Exchange dataset, it is not, nor was it meant to be, a failover tool  I know I’m going to enrage several Microsoft folks by saying this, but it’s true.  SCR also has no integrated data restore solution, you just SCR in the opposite direction, which means if you have 1TB of Exchange data, SCR will transmit 1TB of Exchange data across your link, no exceptions.

Database Portability is the failover solution that comes with Exchange 2007, and it will allow you to flip users within a storage group from one Exchange 2007 server to another.  While the technology is now available, the utilization of this feature has a few requirements that will make it difficult to implement in many organizations.  First, you will need to have someone skilled in PowerShell and Exchange 2007 to perform the required tasks.  For example, the Database Portability run will require several manual steps that must be issued via PowerShell commands to:

1. Check the database for consistency
   
2. Correct inconsistency with ESEUtil and related tools
   
3. Prepare the database for mounting
   
4. Mounting the database

Note: this is a GROSS oversimplification, please see this TechNet article for complete details.

Since you cannot know if step 2 is required before manually performing step 1, these procedures cannot be fully scripted or automated, requiring a trained engineer to perform them at the time of the failure.  Of course, if an ESEUtil run *is* required, those operations are traditionally rated in hours - not minutes - to completion.

Frankly, there is absolutely nothing wrong with this system for those organizations that have multiple, trained engineers available 24/7 - and we have many such companies who are customers of Double-Take Software.  However, for the majority of organizations, and even for the larger firms that don’t want to dedicate those resources, these solution sets simply do not meet their DR requirements alone.

Enter Double-Take.

For smaller organizations where clustering is not a good fit, Double-Take can provide a complete, automated failover and failback solution for Exchange 2003 and 2007 - none of the tools above help with anything but Exchange 2007.  We can use difference-only mirroring technologies and real-time replication to sync and maintain a Target system that is ready to be brought online in about 30 minutes; across a WAN; and without specialized Exchange expertise required at the time of that failover.  Since our patented byte-level transaction-intact replication engine keeps the Target dataset in the proper consistent state, an ESEUtil run is also not required, helping us dramatically cut failover times and make the process even more simple.  Being wizard-driven, PowerShell expertise is not required, but as we are a Microsoft ISV Partner, you can examine our failover routines and see that we do everything within Microsoft’s framework for handling Exchange databases correctly.

For clients exploring clustering, Double-Take is fully SCC and CCR cluster compatible, meaning we can run on the active node of the clusters and replicate the data to a stand-alone system, or another cluster - your choice.  This means that you can leverage clustering technologies locally, where they are best suited, and still gain the ability to quickly and easily fail over to another location if the cluster itself is compromised.  No re-seeding to the Target device (we use block checksum mirroring only when required, byte-level replication continuously), and no worries about making sure protection continues after a node-flip, as Double-Take will just start replication from the new active node when one occurs. So use the clustering technologies where they are the better fit, use Double-Take for everything else.

Finally, restoration is built into the Double-Take Exchange tools (specifically the Double-Take Application Manager, or DTAM, wizard).  These restoration systems allow you to return to either the original hardware and configuration, or any other valid Exchange setup - and to do so while sending only the differences between the data on the now live Target system, and the repaired/replaced Production system. Since a copy of the data can be transferred via USB or other removable storage, this means that if you have 1TB of Exchange Data, we many only need to send 100 or 200 GB of changes (we’ll check the dataset to be sure) instead of trying to move the entire dataset across a WAN link.  Of course, as with SCR, these solutions work while the end users are actively working on the Target server, so the downtime for both solutions is minimal, but the WAN impact differences can be tremendous.

To summarize - Double-Take does not advocate ignoring the relatively new protection technologies in Microsoft Exchange Server 2007.  CCR - as one example - is a huge leap forward in local data protection for Exchange, and should be used wherever such clustering is a good fit for the organization.  But these free tools alone are not the total answer to your DR questions.  You need a tool set that can handle WAN connectivity, potential lack of expertise at failover time, handle other non-Exchange 2007 systems and do it all at a price point that won’t crash the budget.  That’s what Double-Take Availability offers, and we will continue to enhance our products to take advantage of the new technologies that are built into Exchange both on 2007, and in the future.