For many years, at least since Exchange Server 5.5, if you needed high availability for an Exchange Server - you built a cluster. Call it a Wolfpack cluster, a NLB cluster, a Windows server cluster - whatever. They are all the same, just by any other name.

Any Windows-based cluster requires, at some level, at least one computer system which is ready for at least one of the other systems to fail. Whether active (currently taking transactions from clients) or passive (sitting there waiting for another computer system to fail). This has meant, in the past, that to properly size your cluster members for performance, you need to oversize (super-size? J) your cluster members. As of Exchange Server 2003, Microsoft required all Exchange server clusters to have at least one passive member - that is, at list one cluster member that was not doing anything else in the cluster.
In Exchange Server 2007, Microsoft has enabled a technology known as Continuous Replication. They have enabled this in three different ways (as of Service Pack 1). Those three ways are: Cluster Continuous Replication (CCR), Local Continuous Replication (LCR), and Stand by Continuous Replication (SCR). Each of these replication methods are ways of creating (almost) real-time versions of your Exchange database.

In all versions of Exchange server prior to 2007, the log files that Exchange produced are exactly 5 MB in size (and I mean exactly - 5,242,880 bytes). In Exchange Server 2007, those log files have changed to exactly 1 MB in size (1,048,576 bytes). This change was made, primarily, to support the continuous replication features.

All of the continuous replication methods depend on log shipping. Log shipping is the process of taking each Exchange transaction log, once closed, and transferring it to a continuous replication destination, applying that log file to a destination copy of an Exchange database, and then waiting for the next transaction log. This process allows for a remote destination to have a close-to-current copy of your local Exchange database. A real restriction is that any of the continuous replication methods only work if you have a single Exchange message store within your Exchange storage group.

The initial process of creating a continuous replication destination includes “seeding” the destination copy. After the initial seed, the copy is kept up to date by applying the log files from the source. In order to keep copies more close to current is the (one of the main) reason why the log files were reduced in size. Any continuous replication solution requires that a storage group only have a single mailbox store associated with it.

CCR is the process of taking a copy of the local database, from a cluster, and sending it to a REMOTE destination. LCR is the process of taking a copy of the local database, from a non-cluster, and sending it to a LOCAL destination. SCR (new in Exchange 2007 service pack 1) is taking a copy of a local database, from a non-cluster, and sending it to a REMOTE destination.

All of these (CCR, LCR, and SCR) can provide improved high-availability to Exchange 2007 installations. In many cases, they can replace third-party products that provide similar capabilities, at a lower cost. If you want to know how to implement these - let us know!