Testing SCR in a Production Environment (Part 4)

If you would like to read the other parts of this article series please go to:






This is the fourth and final part of an article series on how to recover a Clustered Mailbox Server (CMS) onto a Standby Continuous Replication (SCR) standby cluster for testing purposes without destroying the SCR source copy. In this article, the SCR source is a two-node Cluster Continuous Replication (CCR) environment.


We left part three having mounted the databases on the SCR target server and proved that we could access the mailbox contents. Now that this has been done, it is time to move back to using the production CCR environment which you will remember had been shut down cleanly and is therefore ready and waiting to be enabled. However, it is not as simple as just starting each node of the CCR environment since the CMS is currently running on the SCR target server; it needs to be removed before the CCR environment is brought back online. With that in mind, let us get going with step 11 in the overall process.


Step 11 – Stop the CMS


After proving that the CMS has been successfully recovered to the SCR standby cluster it is now time to switch back to the production CCR environment. However, we are not going to be using the setup.com /RecoverCMS process on the CCR environment as you shall see later. The first thing to do to switch back to using the production CCR environment is to stop the CMS on the SCR standby cluster, which is achieved using the Stop-ClusteredMailboxServer cmdlet. Since I have already covered this cmdlet in step 2 of this article, I shall not cover it again.


Step 12 – Clear the SCR CMS


Even though the CMS has now been stopped on the SCR standby cluster, the actual CMS object is still associated with this server and therefore clients will still attempt to connect to it. What we need to do now is to remove the CMS so that it is no longer running on the SCR standby cluster. Remember, we have a perfectly good CMS waiting to be run again on the CCR environment that was shut down earlier, so the CMS that has been running on the SCR standby cluster is no longer required.


To remove the CMS we can use the Exchange 2007 setup.com program with the /ClearLocalCMS switch. When using this switch, it is also a requirement to specify the CMS name to be removed, via the /CMSName switch. An example of the full command to run is:


setup.com /ClearLocalCMS /CMSName:E2K7


Figure 14 shows the result of running this command. As you might expect, both steps should show as COMPLETED.


Figure 14: Clearing the Local CMS


When this command has completed, I always like to run the Cluster Administrator or the Failover Cluster Management program and check that the CMS resources have indeed been removed from the cluster. You can see this in Figure 15. As you can see, there are no longer any services or applications running on the standby cluster CLUSTER-S.


Figure 15: Confirming Absence of CMS


One other thing to note here is that running the /ClearLocalCMS command disables the CMS computer account. Add Tim’s explanation here. This will need to be re-enabled just a little later in the process.


Step 13 – Start Up CCR Environment


Much like Step 3 where the CCR environment was shut down, there’s not really much to say about Step 10. Once the CMS has been cleared successfully, it is now time to start up both nodes of the CCR environment. First you will need to start up the node that was previously running as the active node and make sure that it has fully booted without errors or other issues. Once this has completed you must then start up the passive node and again check that it has booted without any issues. The result is a CCR environment that has been started up successfully but it is not ready to serve the users yet as we shall see.


Step 14 – Reset RedundantMachines


You will remember from part one of this article series that I detailed the RedundantMachines parameter, an important parameter of the Get-MailboxServer cmdlet. When a CCR environment has been constructed, this parameter will be set to contain the names of the two nodes that comprise the CCR environment as you saw in part one of this article series. In my example, the RedundantMachines attribute was set to {CCRA,CCRB}. Since then, the CMS has been recovered to the SCR standby cluster, tested, and removed.


Let us now run the Get-MailboxServer cmdlet against the CMS and filter it to see what the RedundantMachines parameter is set to currently. The cmdlet I will run to do this is:


Get-MailboxServer E2K7 | fl RedundantMachines


This cmdlet ensures that only the RedundantMachines attribute is displayed in the output as you can see from Figure 16.


Figure 16: RedundantMachines Attribute After SCR Test


Interestingly, you can see that the RedundantMachines parameter is now set to just a single server name, namely the SCR standby cluster node. The reason for this change is because this attribute was set by the Exchange 2007 setup.com program when the /RecoverCMS switch was used. This is all well and good, but the problem is that the CCR environment has now been powered back up and therefore the RedundantMachines attribute really should be set to the value of {CCRA,CCRB} since these are now the two cluster nodes that make up the CCR environment. However, we are not going to be recovering the CMS onto the CCR environment as it is already there so consequently there is no need to run the setup.com program with the /RecoverCMS switch. Therefore, it is necessary to manually alter the value of the RedundantMachines parameter via the Set-MailboxServer cmdlet. You can only modify this value once both cluster nodes have been started, which is why this step was performed earlier. An example of the cmdlet to run to modify the RedundantMachines attribute is:


Set-MailboxServer –Identity E2K7 –RedundantMachines CCRA,CCRB


You just need to set the RedundantMachines attribute as a comma-separated pair of server NetBIOS names. There is no output given back by the Exchange Management Shell if things have gone correctly, so it is always wise to re-run the Get-MailboxServer cmdlet to ensure that the attribute has been set correctly as you can see from Figure 17.


Figure 17: Setting the RedundantMachines Attribute


Step 15 – Re-enable Computer Account


As stated earlier in this article, the running of the /ClearLocalCMS process also disables the CMS computer account so clearly this needs to be re-enabled. Therefore, the next step is to run the Active Directory Users and Computers snap-in and locate the CMS computer account. Once located, simply right-click it and choose Enable Account from the context menu.


Step 16 – Start the CMS


Starting the CMS also starts other key resources within this cluster group, such as the IP address and Network Name resources. The starting of the Network Name resource also means that the DNS A record for the CMS is now correctly updated such that it is back to the same value that it was when the CCR environment was running.


Once the CMS has been started you should use the Failover Cluster Management snap-in to verify that all CMS resources are online.


Step 17 – Test Mailbox Access


Once again it is time to test mailbox access to prove that the CCR environment is functioning correctly. There’s not much to say at this point, other than to ensure that your testing is thorough and conclusive before allowing the users back onto the system.




That’s it for this article, where you have seen how to prove that the copy of the databases on your SCR target server are consistent and contain the correct data. This is a valuable exercise to perform periodically as it will help to streamline the process should you experience a failover scenario for real.



If you would like to read the other parts of this article series please go to:



Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top