If you would like to read the next part in this article series please go to Exchange 2007 Clustering Questions (Part 2).
Introduction
One of the big new features of Exchange 2007 is the introduction of the continuous replication technologies, most notably Cluster Continuous Replication (CCR). As one might expect when new technologies are introduced, there are many questions around the design and operation of these technologies, certainly this has been the case with continuous replication. Even though they may have read the product documentation and understood the ‘rules’ of design and deployment on Exchange 2007 continuous replication, I usually find that there are people on the various Exchange newsgroups and forums that ask questions that either attempt to bend those rules or simply are not addressed by the documentation. In this two part series, I will be looking at some of the questions asked.
Why Does Storage Group Health Show As Initializing?
One popular observation that can be made in a CCR, LCR or even a SCR environment, all center around the status of the storage group copies. Take Figure 1 for example, you can see that the health of the storage groups is listed as Initializing under the Copy Status column.
Figure 1: Storage Group Status in Exchange Management Console
The same thing can be seen when running the Get-StorageGroupCopyStatus cmdlet, as you can see in Figure 2, where the SummaryCopyStatus property is shown as Initializing.
Figure 2: Storage Group Status in Exchange Management Shell
I remember first seeing this a long time ago after constructing a new test CCR environment for a customer. In fact, before I realized that the storage group copy status was set to ‘initializing’, I had actually attempted to move the Clustered Mailbox Server (CMS) between the two cluster nodes using the Exchange Management Shell, only to experience a failure of this particular cmdlet. It was then that I examined the properties of the storage groups via the Get-StorageGroupCopyStatus cmdlet.
The case where the storage group copy status is set to ‘initializing’ is actually quite normal in some specific cases, most notably in test environments. The main reason for this is that a transaction log file has not been processed by the system. In my case, I’d literally just created new mailbox databases and then attempted to move the CMS between cluster nodes. The newly created mailbox databases had not yet generated any transactions and thus transaction logs, hence the status display of ‘initializing’. The quickest way around this particular issue is to dismount and then remount each mailbox database. This act causes transaction log roll to occur and therefore creates a transaction log.
How Do I Apply Update Rollups To Clusters?
With Exchange 2007, Microsoft changed its approach to patching Exchange servers. Rather than applying large service packs periodically, Microsoft now releases patches known as Update Rollups on a regular basis. At the time of writing this article, the current Update Rollup for Exchange 2007 Service Pack 1 is Update Rollup 9. The process of applying updates to a cluster is still something that I am asked about when deploying new clustered environments on customer sites. This process does, by and large, abide by the same principles that have been used when patching legacy Exchange clusters. The main principle to follow is to patch the passive node of the cluster first. However, things get more complicated when you have Standby Continuous Replication (SCR) in your environment. Let us have a look at the process to update a Cluster Continuous Replication (CCR) environment that is running in an organization also using SCR. I will not be covering Single Copy Clusters (SCC) here as CCR environments are predominantly what I, and I suspect many other organizations, deploy. Of course, before you apply any update to a system you should take a backup and verify that the backup was successful.
The first thing to do is to apply the update rollup to the SCR server(s). For the purposes of this article I am going to assume the SCR target is a single-node cluster which is not running an active Clustered Mailbox Server (CMS) at the time of the update application. Since this single node is simply running the passive CMS role, application of the update can be performed at any time as it will not actually affect the users in any way.
All the updates are available from the Microsoft download site. For example, Update Rollup 9 for Exchange 2007 Service Pack 1 is available here. You should note that there are different updates for the Release To Manufacturing (RTM) and Service Pack 1 editions of Exchange 2007, so make sure that you download the correct update. The updates consist of a single patch file, such as Exchange2007-KB970162-x64-EM.msp in the case of the 64-bit version of Update Rollup 9 for Exchange 2007 Service Pack 1.
To install this on the SCR single node cluster, it is just a case of running the .MSP file directly on the cluster node. The installation it is particularly exciting. Upon running the .MSP file, the update will display an initial welcome screen and then proceed to calculate disk space requirements. Once this has been done, you can proceed through the wizard screens which merely include a license agreement screen and an overall status screen.
Once applied to the SCR single node cluster, the update can then be applied to the CCR environment. The golden rule of applying updates to a CCR environment is that the update should only ever be applied to the passive node. Since there are two nodes in a CCR environment, one active and one passive, it therefore follows that you will need to move the CMS between nodes during the update process. The reason for applying the update to the passive node first is mainly because the cluster service is stopped and restarted during the update process. Therefore, if this node contained active cluster resources, these would need to be moved to the other node during the update process. Do not forget that when we refer to a node as being passive, this includes the fact that the default cluster resources should be running on the other node. You can see these resources in Figure 3, which is a Windows 2008 failover cluster.
Figure 3: Default Cluster Resources
Once the node is considered passive, apply the update to it. When this is done, the CMS should be moved to it to make that node active. To do this you can either use the Exchange Management Console or the Exchange Management Shell. In the Exchange Management Shell, you’ll use the Move-ClusteredMailboxServer cmdlet. Once the CMS has been moved, the previously active node is now passive and therefore can be updated as per the instructions previously given in this article. That completes the update rollup process for a CCR environment.
Can I Have More Than Two Nodes in a CCR Environment?
The short answer to this question is no. By design a CCR environment is limited to two nodes within the cluster; one node is active whilst the other is passive. The scenario that drives the question of how many nodes can exist in a CCR environment is typically one where a cluster arrangement exists within an Exchange 2003 environment and this environment is being migrated to Exchange 2007. In the Exchange 2003 environment, there might exist a multi-node cluster with up to eight nodes. For example, it could be that the Exchange 2003 infrastructure consists of two active nodes and a single passive node. If the decision has been made to migrate to a CCR environment in Exchange 2007, perhaps due to the attraction of the CCR’s non-shared storage model, there might be a concern that the existing two active cluster nodes might place too great a load for a single CCR environment.
This configuration may or may not be possible. This is based on many different parameters such as; the number of users, the user concurrency, the expected load on the system and so on. Whilst it is true that Exchange 2007’s use of 64-bit hardware, coupled with a sound design, may allow all users to be migrated to a single CCR environment, such a configuration would need to be planned for carefully. If it was found that two active cluster nodes were still required, the solution would be to implement two separate CCR environments since the fact remains that any single CCR environment can only contain two nodes.
Summary
That completes part one of this article series where we have covered three questions on Exchange 2007 clustering. These are the sort of questions that often appear on public newsgroups or forums. I will be taking a look at some additional questions in the next part of this article.
If you would like to read the next part in this article series please go to Exchange 2007 Clustering Questions (Part 2).
