In his blog article, “Exchange mailbox protection explained” , Stephen J. Bigelow discusses the problems with unprotected Exchange mailboxes and the various options for protecting them.

He explains that unsecured mailboxes can be easily compromised and their contents stolen. There are other problems associated with unsecured mailboxes such as: identity verification, privacy and proof of delivery. Additionally unsecured electronic mailboxes are subject to spam, viruses, and other harmful malware that is all too common with using popular, everyday email systems like Hotmail, AOL, Gmail and even Outlook. And almost all of these mail systems use the open-to-anyone Internet as their communications vehicle.

Stephen goes on to explain that the loss of email data impacts not only the productivity of the employee but also the productivity of the company or organization that the employee works for.

If I think about how the loss of my email content would affect my business activities then I immediately start thinking about backing up my data. I cannot afford to lose any of my emails. As an email administrator it is your responsibility to protect against the loss of, or the invasion of, all emails that circulate through your organization’s email server.

Stephen explains the various ways that an Exchange Server administrator can protect the email contents of their servers.

One of the options available to administrators using Exchange Server 2007 is known as “Cluster Continuous Replication”. Using Cluster Continuous Replication allows an administrator to: reduce the frequency of their full backups, reduce the total amount of data backed up and to shorten the recovery time objective (RTO). The RTO can be found in their department’s service level agreement (SLA) documents outlining the level of service which they are to provide for their customers’ or organization’s various departments.

Cluster continuous replication (CCR) is a high availability feature that combines the asynchronous log shipping and replay technology of Exchange server with the fail-over and management features provided by the Cluster service. CCR is designed to provide high availability for Exchange Mailbox servers by eliminating single points of failure and without requiring any special hardware. And there are no shared storage requirements to implement cluster continuous replication.

A second copy of the database is continuously and asynchronously updated using the database failure recovery functionality of Exchange Server. Thus, CCR operates in an active-passive mode with changes being made to an active copy of the database while the second (passive) database is also updated. Copying of the logs and replays are continuously performed.

The key points about Cluster Continuous Replication include the following:

• Continuous replication is asynchronous so not every log file that exists on the active server will be on the passive server. The logs are not copied until they are closed and no longer used by the Mailbox server. However, if an administrator has scheduled an outage on the active server for routine maintenance then the log files will be kept in sync.
• Continuous replication places almost no load on the CPU or input/output (I/O) devices. Secure file sharing is used by the passive node to obtain access to the logs.
• Servers in the cluster will take on both active and passive roles depending on their failover status. What may have been a passive node initially can change after a failover from the active node to the passive node. And vice-versa – the status of the active node can change to being a passive node after a failover has occurred.
• The time it takes to failover from node 1 to node 2 is the same amount of time it would take to failover from node 2 to node 1. On small servers, the estimated failover time is less than two minutes. For larger servers, a scheduled outage can be less than four minutes due to the time it takes to perform a controlled shutdown of an active node.
• CCR can be combined with standby continuous replication (SCR) to replicate storage groups locally in a primary data center. Replicating locally could provide for more highly available servers, using CCR, should a failure occur on the active server. A secondary remote datacenter could contain a passive node in a failover cluster that hosts the SCR targets for site resiliency. If the primary datacenter failed then the SCR targets hosted in the remote standby cluster could be quickly activated.

As noted by Stephen, in his article, CCR has been replaced with database availability groups (DAGs) in Exchange Server 2010.