Exchange Server 2007 Service Pack 1 (SP1) introduces several high availability enhancements. In this article we will take a closer look at the Clustered Continuous Replication (CCR) cluster management interface included in the Exchange Management Console (EMC). One of the disappointments with the Exchange 2007 RTM version was that all CCR cluster related management had to be done via the respective cmdlets in the Exchange Management Shell (EMS). Exchange 2007 SP1 allows you to manage many of the CCR cluster related management tasks from within the EMC, but a few of the important ones are unfortunately still missing.
This article is based on Exchange Server 2007 SP1 Beta 2. This means that the CCR cluster management related features covered in this article can still change before Exchange Server 2007 SP1 RTW’s.
As you can see in Figure 1 below, we now have several new options when a Storage Group is selected on a Mailbox server that has been clustered using CCR cluster technology. Instead of using the EMS, we can now stop, start, and move (between nodes) a clustered mailbox server (CMS) using the Manage Clustered Mailbox Server wizard as well as suspend, resume, update, and restore continuous replication directly from within the EMC GUI.
Figure 1: New Clustered Mailbox Server options in the Exchange Management Console
Using the New Manage Clustered Mailbox Server Wizard
As those of you who have experience with managing Exchange 2007 RTM Mailbox servers that have been clustered using CCR technology are aware of, we needed to move, start, and stop a CMS using the Move-ClusteredMailboxServer, Start-ClusteredMailboxServer, and Stop-ClusteredMailboxServer cmdlets respectively. Although this worked fine for those of us who enjoyed managing Exchange 2007 via the EMS, this was a disappointment for Exchange administrators that liked to manage Exchange using the GUI. The good news is that Exchange 2007 SP1 includes a new Manage Clustered Mailbox Server wizard, which can be used to move, start, and stop a CMS. To launch the new wizard, open the EMC then drill down to the Mailbox node under the Server Configuration work center in the navigation tree. In the Result pane select a CMS and then select the storage group you want to work with. Now click the Manage Clustered Mailbox server link in the Action pane. On the Introduction page (Figure 2), we can select to move the CMS to another node (it doesn’t say move to a passive node since this option is also available for single copy clusters (SCC)) and start or stop the CMS.
Figure 2: Manage Clustered Mailbox Server wizard – Introduction page
Moving a Clustered Mailbox Server to another node
Let’s first try to move the CMS to the passive node in our CCR cluster setup. When clicking Next, we can specify the target machine which is our passive node. In addition, we can enter a comment about why we need to perform the move (Figure 3). When you have done so, click Next.
When you move the CMS from one node to the other, all the resources will be offline until the move is complete. Moving a CMS doesn’t typically take more than one to two minutes, but this of course depends on the number and size of storage groups/databases, server load, etc.
Figure 3: Entering a reason why the CMS is moving to the passive node
Remember that you should always move a CMS from one node to the other using either the Move-ClusteredMailboxserver CMDlet or the Manage Clustered Mailbox Server wizard. You should never use the Cluster Administrator nor Cluster.exe, since these two methods don’t validate the health or state of the passive copy. Some of you might wonder how you move the Cluster group resource, and I understand why since this can’t be accomplished using the EMC/EMS. But you really don’t have to worry about this, since the cluster group resource typically will be moved to the other node, should the first node go offline. I guess this is the reason why you still must use either the Cluster Administrator or Cluster.exe in order to move this resource.
Okay let’s move our CMS to the passive now shall we? To do so, click the Move button shown in Figure 4.
Figure 4: Moving CMS to the passive node – Configuration Summary page
The wizard will now begin moving the CMS to the passive node, and since I did this in a test environment for a CMS with only 5 storage groups/databases, this didn’t take more than 45 seconds. With the Exchange 2007 RTM version this actually took longer in the exact same test environment, but with Exchange 2007 SP1 the time it takes to move a CMS between nodes has been reduced by taking the databases offline without first flushing the database cache.
Figure 5: Moving CMS to the passive node – Completion page
When the move is completed, click Finish to exit the wizard.
Stopping a Clustered Mailbox Server
Although the second option in the Manage Clustered Mailbox Server wizard (Figure 2) is Start the clustered mailbox server, we’ll go directly to the Stop the clustered mailbox server option, since we really cannot start an already started CMS (perhaps the Exchange Product group should change the order of these tasks in the Manage CMS wizard?).
Okay, let’s select Stop the Clustered Mailbox server and click Next. As was the case with the Move the clustered mailbox server task, we now have the option of specifying a reason for why the CMS will be taken offline (Figure 6). When you have done so, click Next.
Figure 6: Entering a reason why the CMS is brought offline
On the Configuration Summary page, click the Stop button in order to take the CMS offline (Figure 7).
Figure 7: Stopping the CMS – Configuration Summary page
After a little while, the Completion page appears and the CMS is now offline. Now click Finish in order to exit the wizard (Figure 8).
Figure 8: Stopping the CMS – Completion page
Starting a Clustered Mailbox Server
Alright, when you’re ready to bring the CMS online again, select the Start the clustered mailbox server task, then click Next. On the Configuration Summary page, click the Start button (Figure 9).
Figure 9: Starting a stopped CMS
After a while (again depending on the number of storage groups and databases as well as database sizes) the CMS will be brought online again and you can click Finish in order to exit the wizard (Figure 10).
Figure 10: Starting a stopped CMS – Completion page
Managing Continuous Replication-enabled Storage Groups
With Exchange 2007 SP1, we can also manage continuous replication for our storage groups from within the EMC. This means we can now suspend, resume, update, and restore storage group copies using the GUI (Figure 11). In the Exchange 2007 RTM version we had to use the Suspend-StorageGroupCopy, Resume-StorageGroupCopy, Update-StorageGroupCopy, and Restore-StorageGroupCopy cmdlets in the EMS to perform these tasks.
Figure 11: New Continuous Replication tasks in the Exchange Management Console
Suspending a Storage Group Copy
There may be situations where you need to temporarily suspend (aka halt or stop) replication from the active node to the passive node on your CMS. This could be because you for example needed to seed a storage group or perform some other type of maintenance. When continuous replication has been suspended, both log file copying as well as replay is halted. To suspend replication to the passive node, you must select the respective storage group on the CMS, then click the Suspend Storage Group Copy link in the Action pane (Figure 11). This will bring up the Administrative Suspend window shown in Figure 12 below. Here you have the option of entering a reason for why the replication for the storage group is suspended.
Figure 12: Suspending a Storage Group Copy via the Exchange Management Console
When you have entered a comment, click Yes to halt replication.
Resuming a Storage Group Copy
When you have performed the necessary maintenance you should remember to resume replication for the respective storage group. To do so select the suspended storage group on the CMS, then click the Resume Storage Group Copy link in the Action pane (Figure 11).
Figure 13: Resuming a Storage Group Copy using the Exchange Management Console
Click Yes in order to resume replication (Figure 13).
Restoring a Storage Group Copy
The new Restore Storage Group Copy wizard in the Exchange Management Console can be used when a database cannot be mounted automatically. If/when continuous replication has been terminated for a storage group copy, the Restore Storage Group Copy task can be used to activate the storage group copy again.
The Restore Storage Group Copy wizard can only be used from the active node in the CCR cluster.
To restore a storage group copy, click the Restore Storage Group Copy link in the Action pane. This will launch the new Restore Storage Group Copy wizard as shown in Figure 14. On the Introduction page, make sure the correct Storage group is shown, and then click Next.
Figure 14: Restoring a Storage Group Copy using the Exchange Management Console
On the Configuration Summary page, click the Restore button (Figure 15).
Figure 15: Restoring a Storage Group Copy using the Exchange Management Console – Configuration Summary page
When the restore is completed, click Finish in order to exit the wizard.
Updating a Storage Group Copy
There may be times where you need to seed one or more storage group copies in your CCR cluster. Typically seeding is an automatic process, but in some cases manual seeding may be required. Exchange 2007 SP1 allows you to manually seed a storage group copy using the new Update Storage Group Copy Wizard.
To use the new wizard, click on the Update Storage Group Copy link in the Action pane (Figure 11). This will launch the Update Storage Group Copy Wizard as shown in Figure 16 below.
The Update Storage Group Copy wizard can only be used from the passive node in the CCR cluster.
On the Introduction page, make sure the correct storage group is listed, then select whether you wish to dele any existing log files in the target path or not. When you have done so, click Next.
Figure 16: Seeding a Storage Group Copy using the Exchange Management Console
On the Configuration Summary page, click Update to begin seeding the storage group copy (Figure 17).
Figure 17: Update Storage Group Copy – Configuration Summary page
When the seeding begins, the directories as well as Mailbox database files will be created automatically. However, if a database file or any obsolete checkpoint files exist in the target directory, you will be prompted to delete them as shown in Figure 18. Click Yes and let the seeding complete.
Figure 18: Confirming the checkpoint file should be deleted during the update
When the seeding has completed click Finish to exit the wizard.
You can read more about how to seed a storage group copy in the Exchange 2007 online documentation.
New Clustered Mailbox Server Property Page
In addition to the new wizards described above, Exchange 2007 SP1 also includes a new cluster continuous replication property page (Figure 19), where you can see the nodes in the CCR cluster, storage type (NonShared for CCR clusters), the state of the CMS, which node is the active node and how the failover availability settings have been configured. You can also change the Auto database mount dial setting from here (to read more about how to tune the failover and mount settings see the Exchange 2007 online documentation).
Figure 19: Clustered Mailbox Server tab
To view this information in the Exchange 2007 RTM version, we had to use the Get-ClusteredMailboxServerStatus cmdlet.
New CCR Tab on the Storage Group Property Page
With Exchange 2007 SP1, a new tab has also been added to the Storage Group property page (Figure 20). Here we can view continuous replication status information for the selected storage group. More specifically we can see seeding/copy status, target node, copy and replay queue length as well as when the last log file was inspected, copied and replayed to the passive storage group copy.
Figure 20: Cluster Continuous Replication tab on the Storage Group Property page
To view this information in the Exchange 2007 RTM version, we had to use Get-StorageGroupCopyStatus -Identity “server\storage group” command.
New Transport Settings Property Page
Another enhancement in Exchange 2007 SP1 is that you now can configure the Transport Dumpster settings via a new Transport Settings property page in the EMC. In the Exchange 2007 RTM version, you had to use the Set-TransportConfig cmdlet to configure the transport dumpster settings. As those of you who have experience managing a CCR cluster probably know, the transport dumpster is used to submit recently delivered mail after an unscheduled outage in a CCR environment (you can read more about the Transport Dumpster in the Exchange 2007 documentation).
To get to the Transport Settings property page, open the EMC then select the Hub Transport node under the Organization Configuration work center. Now select the Global Settings tab and open the property page for Transport Settings as shown in Figure 21.
Figure 21: The new Global Transport Settings option in the EMC
In the bottom on the General tab, we have the option of specifying the maximum size per storage group in MBs and the maximum retention time in days. By default the maximum size is set to 18 MB per storage group and the retention time to 7 days as shown in Figure 22.
Figure 22: Transport Settings Property page
The Maximum Size per Storage Group (MB) field is used to specify the maximum size of the transport dumpster queue for each storage group and the Maximum retention time (days) field is used to specify for how long e-mail messages should remain in the transport dumpster.
On a side note, with Exchange 2007 SP1 the transport dumpster is also supported in Local Continuous Replication (LCR) environments.
SP1 not only improves on existing high availability features and introduces several new ones such as Standby Continuous Replication (SCR), multiple subnet failover networks, support for Windows Server 2008 and IPv6 and new quorum models in Windows Server 2008, but as you have seen throughout this article, this service pack also adds most of the missing cluster specific management tasks to the EMC GUI. We’re definitely on the right track, but we are still missing options such as moving storage groups, test cluster server health, test replication server health and seeing dumpster statistics from within the EMC GUI. Of course this article is based on Exchange 2007 SP1 beta 2, but I don’t expect any additional features to be added to the GUI before Exchange 2007 SP1 RTW’s.