Installing a Continuous Copy Replication or CCR Cluster Part2…



Okay, time to get down to the nitty gritty, actually installing a CCR cluster!!  First lets take a look at what we have in our environment already:


We have already installed two separate Hub Transport/Client Access Server, NYHT01.ponzeka.test and NYHT02.ponzeka.test.  We have two more servers who are going to be our CCR nodes, NYCCRNODE1.ponzeka.test and NYCCRNODE2.ponzeka.test.  They will eventually be part of the CMS, NYMB01.ponzeka.test.

There are several things to note.  First, each of the nodes need a “heartbeat” network to speak to each other.  This is the network that allows the separate nodes to kind of keep tab of each other, and determine if the other node has failed, and if it needs to take over the CMS.  This should be separate from your production network.

Next, notice that NYMB01.ponzeka.test has two IP’s.  One,, is the actual IP that the users will see as the server, NYMB01.ponzeka.test will resolve to this IP.  The other IP,, is the cluster management IP address.  This is used to connect the Microsoft Cluster Management Console to, in order to manage the cluster as a whole.

The first thing we need to do, before we even install Exchange, is to actually create the cluster.  On NYCCRNODE1, we need to configure the separate networks, one for production that clients will connect to, and the second for the heartbeat network.

ScreenHunter_02 Feb. 14 11.31

So, if we notice we have one NIC already labeled as “Production”.  There aren’t any settings you need to change for this.  We do need to make some changes to the heartbeat connection.  The first thing we need to do is configure the IP address of the heartbeat adapter:

ScreenHunter_03 Feb. 14 11.33

There isn’t a need to configure a default gateway or DNS servers.  Next select the Advanced button, then the DNS tab.  Make sure you un-check the “Register this connection’s address in DNS”

ScreenHunter_04 Feb. 14 11.34

Now go to the WINS tab.  Check “Disable NetBIOS over TCP/IP”:

ScreenHunter_05 Feb. 14 11.35

Save all your settings and close the NIC properties box.  Back in Network Connections, select “Advanced-> Advanced Settings”.  Here, make sure that your Production connection is the highest.  Also, un-check “File and Print Sharing for Microsoft Networks” on the heartbeat adapter.

ScreenHunter_06 Feb. 14 11.38

Click OK to save the settings.  Now, configure the same network properties on NYCCRNODE2.ponzeka.test.  Of course, make sure you use unique IP addresses.  After you have configured both on each node, make sure you can ping each server through its respective heartbeat, as well as production networks.  Resolve any issue before going forward.

Now, its time to create the cluster.  Remember, this has to be done before you install Exchange.

Go to Start Menu –> Administrative Tools –> Cluster Administrator.  Under “Action”, select “Create a New Cluster”

ScreenHunter_07 Feb. 14 11.43

You’ll be presented with the New Cluster Wizard. It will ask for a Cluster Name.  This must be a valid computer name.  This should NOT be what you want your exchange server CMS name to be.  In our example, we want our CMS name to be NYMB01.ponzeka.test.  The name you enter in this screen, is just for management of the cluster.  We’ll use ManagementCCR.  The cluster wizard will automatically register this name in DNS so you can use the name ManagementCCR.ponzeka.test to connect to the management tools instead of the IP:

ScreenHunter_08 Feb. 14 11.47

Next, it will ask you for the first node in the new cluster.  It will by default input the name of the server you are working on:

ScreenHunter_09 Feb. 14 11.48

Next, the wizard will test the feasibility of the cluster.  You will receive warnings because there are not shared resources that will be available to multiple nodes.  This is fine, remember, this is a “Share Nothing” Cluster.  Select Next:

ScreenHunter_10 Feb. 14 11.49

Next it is asking for the IP address for management of the cluster.  Again, this will NOT be the IP address end users will connect to for exchange services.  This is simply for the management of the cluster.  We earlier stated we would be using as the management IP.  Input that here and select next:

ScreenHunter_11 Feb. 14 11.51

Next, you are asked to provide a cluster service account.  This can be a standard domain user account, but it will be given administrative access to each node in the cluster.  Because this is simply a test environment, we will use the admin account, but do not do this in production!

ScreenHunter_12 Feb. 14 11.52

At the next screen you could just select next, and finish the cluster, and chances are it would work fine.  However, notice the quorum button on the bottom right.

ScreenHunter_13 Feb. 14 11.54

We can select the “Majority Node Set”.  This is a new clustering ability provided to us by Microsoft.  Essentially, we will use a share located on a third server, completely separate from the cluster to hold the Quorum data.  This will allow a total of three votes in the cluster.  Two votes would be needed to initiate a failover.  This ensures a more consistent and accurate detection of node failures and cluster failover.  Microsoft recommends the third server, be a Hub Transport server in the same site as the two cluster nodes.

Select OK, and next.  The wizard does a final analysis of the cluster.  You should receive no errors or warnings here, if you do resolve them before moving forward.  Click next and finish, and you should have your cluster!

ScreenHunter_14 Feb. 14 11.59

Now we need to add the second node to the cluster. Simply right click on the name of the management node and select New –> Node.

Browse for the computer name and select Add:

ScreenHunter_16 Feb. 14 12.01

Select next.  Now the wizard will check the configuration to ensure everyone is working.  You should receive no warnings or errors.  Select next.

Enter the password for the cluster service account:

ScreenHunter_17 Feb. 14 12.02

Select next, and then after the summary page, select next to add the node.  At the last screen you should again receive no warnings or errors.  You should now have both nodes in your cluster:

ScreenHunter_18 Feb. 14 12.05

So we have completed setting up the initial cluster configuration.  Next, we need to set up the file share witness for the Majority Node Set.  We are going to use NYHT01.ponzeka.test as the file share witness. 

On NYHT01, create a folder and share it out.  Make the name descriptive:

ScreenHunter_01 Feb. 14 12.10

Change the security settings so that NTFS permissions do not inherit.  Make sure domain admins (or any specific group that manages clusters) has Full Control, and that the cluster admin account has Modify:

ScreenHunter_02 Feb. 14 12.13

Now, we have the file share created.  We need to activate it in the cluster.  Log back into NYCCRNODE1.  Start up command prompt and type the following command:

Cluster res “Majority Node Set” /priv MNFSFileShare=\NYHT01ManagementCCR_FSW and press enter:

ScreenHunter_19 Feb. 14 12.16

The warning you receive is expected.  It’s telling you that the change won’t take effect until after the next time the resource is brought online.  Luckily for us, this is easy to do!  You simply need to move the resource over to the secondary node.  In Cluster Administrator, expand groups.  Now right click on Cluster Group and Select “Move Group”  this will cause the cluster to offline, move to the second node and come back online. 

ScreenHunter_20 Feb. 14 12.19

Now move it back to NYCCRNODE1.  We should now be able to see that the Majority Node Set is configured correctly.  On NYCCRNODE1, issue the command: Cluster Res “Majority Node Set” /priv

ScreenHunter_21 Feb. 14 12.21

Notice how the MNSFileShare is set to the correct share?  We are all set.

This concludes part 2 of the series.  Next article, we are going to set up the Transport Dumpster on the Hub Transport servers, and begin installing Exchange!

Leave a Reply

Your email address will not be published. Required fields are marked *