Video series – Exchange 2007 Cluster Continuous Replication (CCR)

Now that Beta 2 of Exchange Server 2007 is available for public download and preview, I thought I would present a blogcast about one of my favorite features: Cluster Continuous Replication, or CCR for short.  CCR is a high availability feature of Exchange 2007 that combines the asynchronous log shipping and replay features built into Exchange 2007 with the failover and management features provided by the Microsoft Cluster service. CCR is a solution that can be deployed within a single data center or between two data centers, with no single point of failure.


To demonstrate how to deploy CCR, I have created a 7-part blogcast that takes you through the process.  The blogcast video parts are as follows; please click on video thumbnails below to see the videos:


1. Introduction to CCR



2. Creating the directory and file share for the file share witness



3. Forming a failover cluster with a Majority Node Set (MNS) quorum



4. Configuring the MNS quorum to use the file share witness



5. Installing the active clustered mailbox server role



6. Installing the passive clustered mailbox server role



7. Verifying cluster status, failover, and manageability



These blogcast videos are intended to be watched in full-screen resolution (at least 1024 x 768), and in numbered order. To save time and reduce video size, some of the demos in this blogcast have been compressed or edited without affecting the quality or the results of the demos.


In addition, I ran batch files to accomplish the steps in some of the demos. A couple of the demos involve multiple commands, so to minimize the chance of errors and typos, and to save time, I performed some of the steps using batch files.


A few notes about the blogcast:


-      In Part 3 of the blogcast, I mention that there are some expected errors that I encounter during the formation of the cluster. In the demo, these are actually warnings, not errors. The warnings being encountered refer to the lack of shared storage in the cluster. These warnings can be safely ignored because CCR does not require, or use, shared storage. Some of the warnings being encountered also refer to additional networks and local storage that is present on each node. These extra resources are present because I use these systems for a variety of different demos. Rather than remove them, I leave them disabled. When the New Cluster Wizard analyzes the systems to determine their readiness as a cluster, it finds these disabled resources and issues warnings about them.  It is these types of warnings that can be safely ignored. When you form your own failover cluster, be sure to fully investigate all warnings and errors that appear, and resolve them if necessary.


-      In Part 4 of the blogcast, once the MNS quorum has been configured to use the file share witness, and once the default cluster group has been taken offline and online, the file share witness will be used. Below is a screen shot displaying the contents of the file share witness directory and its sub-directory on the demo system (\\E2K7\MNS_FSQ_EXCLUS). As you can see, there is very little data in the directory. The load on the file share is very light. The presence of the recently created directory (the long GUID with the $ at the end of it) is evidence of the file share witness at work. Once activated, the MNS quorum with file share witness creates a single file in the directory. In order to prevent split brain syndrome, the current MNS resource owner (the node that currently owns the Cluster Group) acquires an exclusive lock on that file when the other node is down or otherwise unavailable. Only the owner of the exclusive lock may survive when nodes lose communication with each other. The current MNS resource owner will also write membership data into that file. When a node starts and forms the cluster, it will use that membership data to determine whether it has the latest cluster state information and can form the cluster without causing split brain syndrome.



Figure 1 - File Share Witness Directory on Hub Transport Server


-      In Part 5 of the blogcast, I mention that the cluster needs a "special, unique IP address." I meant to say it needs a "static, unique IP address." In order for a failover cluster to be supported, it must have at least two network interface cards (NICs) in each node. One NIC is typically dedicated to the private network traffic (e.g., cluster heartbeat traffic), and the other NIC is used for both public network traffic (e.g., client, server, and administrator interaction with the clustered mailbox server and the cluster) and private network traffic (only if the dedicated private network fails). When forming the failover cluster, be sure to follow the instructions in the Exchange Server 2007 product documentation:

-Exchange 2007 Product Documentation (Online/Web) -

- Exchange 2007 Product Documentation (Offline/CHM) -


-      In Parts 5 and 6 of the blogcast, the clustered mailbox server is installed into the cluster (first the active node, then the passive node). Be aware that any pre-requisite checks that fail when installing the clustered mailbox server are not re-checked on the passive. It is very important that you ensure that the passive node meets all pre-requisites, too.


If you now need a refresher of the LCR (Local Continuous Replication) - please see my earlier video on the subject here.


Of course we welcome your feedback on CCR, the documentation for CCR, and this blogcast. Thanks for reading/watching!


-Scott Schnoll

Comments (36)
  1. Animesh says:

    Thanks a million for posting these videos. These are going to be very important assets for us, the exchange engineers. But if you could let us download a copy of them like downloadable webcasts, that would be absolutely wonderful.



  2. Exchange says:


    You can indeed download the videos now if you want to. If you go the the individual videos page, there is a link under the video that says "Download". Right-click on it, say "Save target as…" (or the equivalent in browsers other than IE) and then save it locally.

  3. AnOracle says:

    Have you gotten this to work under Longhorn Beta 2?

    I can get my cluster built but I can’t get it to see or use the file witness that was created. During the installation of Exchange Active Node, it gets all the way to the point where I can choose between LCR and CCR and no matter what is chosen, the Server ID parameter is incorrect and won’t continue.

    Great work on the podcasts!!

  4. GiraffeBe says:

    Please see the E2K7 system requirements.  It is not currently supported on Longhorn Beta 2.

  5. SMB says:

    What are the geographic and network requirements for CCR? i.e. Can the Active and Passive nodes be in separate (well connected) datacentres?

    Is CCR is viable replacement for the current Geo-Clustered solutions in Exchange 2003?

  6. Robert says:


    Great post. It looks like mns is now preferred way to set-up exchange clusters. What about using standard local quorum disk? Will this feature be still supported in exchange 2007 and beyond?

    Thank you

  7. Scott says:

    SMB: We have this documented in the CCR content at  CCR is our built-in solution for geographically dispersed clustered mailbox servers in Exchange 2007.

    Robert: We still support shared storage clusters in Exchange 2007. We call those Single Copy Clusters now.  You can find details on SCC at

  8. Trebor3 says:

    The requirement for a private network connection is still a stumbling block for geographically dispersed systems. Creating a VLAN and stretching it across sites is a little messy, certainly in my environment.

    Perhaps there could be an option for manual failover only, if a private network is not used?

  9. Scott says:

    Trebor: Thanks for your feedback.  We’ve heard the same from some other customers, too.  This requirement actually comes from the Microsoft Windows Cluster Service, and not from Exchange.  MSCS requires a stretched subnet for geographically-dispersed clusters.  In my experience, setting up a VLAN is a fairly straightforward and simple process. If you are experiencing difficulty, I recommend contacting your network hardware vendor, as they can probably walk you through the process pretty quickly.

    The single subnet requirement will be lifted in the Longhorn Server timeframe, but Exchange 2007 won’t be supported on Longhorn until after RTM.  We’ve not set any specific date for Longhorn support, but we do want to give customers a heads up about what will be changing in the future.

    But for today, and at RTM, stretching a subnet using a VLAN will be required for any stretch Exchange cluster (SCC or CCR).

  10. SGE says:

    Many many thank to Scott Schnoll

    This document helped us to make our CCR on-line and working

  11. Great article, thank you Scott!

    Have my own test environment, and followed every step.  Everything went smoothly, but, my first attempt to install Exchange 2007 Beta 2 on the Active node of the cluster failed, with the following error: An error occurred. error code was 2147500037. The operation failed. The ExchangeSetup.log didn’t give much more information (same error message listed,  right after he stated that he was creating the IIS Metabase objects for Base DAV protocol).  Re-ran service pack 1 of Windows 2003, and it went perfectly fine! Passive node was installed in about ten minutes without a problem.

    Great feature this CCR, and LCR! Looking forward to the "stretched" options after RTM!

  12. Simon says:

    Hi Scott,

    Great set of videos. I got the CCR up and running.

    It might be worth mentioning somewhere that hotfix 921181 is needed on the cluster nodes in order to get this working. I couldn’t find it documented anywhere.


  13. Scott says:

    Simon: Thanks for the kind words.  I did mention in the videos that this hotfix is needed, and we also have that documented at, among other places.

  14. Francesco says:

    Hi Scott,

    i’ve a problem during the installation of ex2k7 on CCR. the 1st installation on Active node (NODEA) tell me that didn’t detect Hub Transport Role and client access role, i could go on next step, but i tried to go on but Ex2k7 report an error in the end is not installed.

    Any suggest?

    Many thaks

  15. Scott says:

    Francesco: Only the Mailbox role can be clustered in Exchange 2007.  This means that you need the Hub Transport role and Client Access role on one or more standalone systems.  Depending on your needs and situation, both server roles can be installed on the same computer, or they can be installed on different computers.

    Once you have the Hub Transport and Client Access roles installed on a standalone system, you can then proceed with deploying CCR.

  16. scottdotnot says:

    Apparently longhorn is going to not require the cluster nodes be on the same subnet.  The question is how many nodes will longhorn support.  Going with a CCR it would be nice to have more than 4 nodes in each site.

  17. jeremy says:

    Q1: Does CCR require to use Windows Server 2003 64-bit Enterprise Edition and Exchange 2007 Enterprise Edition?

    Q2: Can Exchange 2007 Enterprise Edition run on Windows Server 2003 64-bit Standard Edition but CCR is still available? (Q2 is depending on Q1, but just would like to make sure).


  18. zemi says:

    What about the "set transort config" command and the transport dumpster? Can you tell me how to set that up?

  19. zemi says:

    Thanks Scott.

  20. Leif says:

    So from what I read to run CCR you need 2 servers with *ONLY* the Mailbox role installed? Is this correct or can other roles be installed on the servers also?Thanks….

  21. Scott says:

    Hi Leif,

    Only the mailbox role can be clustered, and when you cluster the mailbox role, you cannot install any other server roles.  Information on high availability strategies for the other server roles can be found at

    Hope this helps.

  22. zemi says:

    Scott, I plan on reading the links you’ve provided to educate myself but in the meantime I have run into a couple of issues. I have 4 servers in my testlab: domain controller, nodeA, nodeB, and the hub transport.

    1st: My command shell doesn’t recognize any of the commands.

    2nd: In order for my Exch Man Console to look exactly like yours I had to install the mailbox role on the hub transport server along with the client access and hub transport roles. I loaded Outlook on my domain controller and pointed it to e2k7ccr. I went to Tools>Email Accounts in Outlook and saw it was actually pointing to my hub transport server. Isn’t this a single point of failure?  Thanks, Zemi

  23. Scott says:

    Hi Zemi,

    What happens when you run a command in the shell?  Also, are you launching the Windows Powershell, or the Exchange Management Shell?  For Exchange tasks, you’ll want the Exchange Management Shell.  If you do launch the Windows Powershell, you can always add the EMS snap-in by running: add-mshsnapin *exchange*

    Note that after Beta 2, this cmdlet will change to: add-pssnapin *exchange*

    What version of Outlook are you running?  If it is Outlook 2007, then Outlook will connect to the Client Access Server first as part of its Autodiscover process.  Did you verify that the mailbox to which Outlook is connecting is located on the clustered mailbox server?  Perhaps the mailbox was created on the standalone server and needs to be moved?

    Also, for a great place to browse and ask more questions related to Exchange 2007, see

  24. zemi says:

    Yes I was using the wrong command shell.

    Yes I did create the mailbox on the standalone.

    I’m using Outlook 2003.

    With that cleared up, I have wiped and reloaded my testlab (love that Acronis disk imaging software). On my standalone do I have to install the mailbox role?

  25. Scott says:

    No, the standalone system does not need the Mailbox role installed.  It does need the Hub Transport and Client Access roles installed.

  26. andreas says:

    Hi Scott,

    I’ve heard/read that it should be possible to configure CCR so that for transaction log shipping between both nodes the privat LAN could be used/defined. So public LAN used by client access, privat LAN used for heartbeat and transaction log copy process (assumed that privat LAN is 1GB). Is that totally nonsens ? If not, how do I set this up ?



  27. Scott says:

    Hi Andreas,

    In CCR, replication occurs over the public network only.  There is currently no way to configure log file replication to occur over the private (heartbeat) network.

  28. zemi says:

    I’m still concerned about the standalone server hosting the Hub Transport and Client Access roles. Isn’t that a single point of failure? If I have nodeA and the Hub server at our local site and nodeB at our disaster recover site and our local site burns down how would we get email or OWA out at the DR site?

  29. Scott says:

    Hi Zemi,

    What we’re saying is that CCR is a mailbox HA solution with no single point of failure.  But you still need to use other strategies to achieve HA for the other Exchange server roles that you’ll have in your environment (e.g., CAS, Hub, etc.).  You can find the HA strategies for the other server roles documented at

    All messages will travel through a Hub Transport server at some point.  So to ensure you have HA for transport, you’ll want to make sure that you have multiple Hub Transport servers in each AD Site.  There is built-in resiliency and HA logic in the Hub Transport role, so you don’t need to use load balancing, RR DNS, or other techniques to achieve HA.

  30. chrismin says:

    This may be explained, but can I have an active/active/passive setup where I have 2 active servers each with a mail store on it and have them both update on the passive node. And/or is there any links I can go to that describes how to use more then 2 nodes in a cluster

  31. Scott says:

    Hi Chrisman,

    CCR only supports pairs of active/passive nodes.  So you cannot have A/A/P using CCR.  You can do that with a Single Copy Cluster (see

    Also, you can have multiple CCR pairs in the same cluster, although for HA purposes, you would be better off having a dedicated cluster for each CCR pair.

    Hope this helps.

  32. Anonymous says:

    DPM is a fantastic product – I’ve personally seen many customers taking advantage of it’s robust feature

  33. Anonymous says:

    I’ve previously blogged about the two forms of continuous replication that are built into Exchange 2007:

Comments are closed.

Skip to main content