Exchange 2007 Clustering Questions

[patris1]

http://www.msexchange.org/articles_tutorials/exchange-server-2007/high-availability-recovery/exchange-2007-clustering-questions-part1.html

PART-1

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.

---

موضوعات مشابه:

• Configuring the Native Exchange 2007 MP for OpsMgr 2007 R2
• SolutionBase: Outlook 2007's new features and how they work with Exchange Server 2007
• Configuring Outlook 2007 with Exchange Server 2007
• Transitioning from Exchange 2000/2003 to Exchange Server 2007
• replication exchange 2003 and exchange 2007

---

[patris1]

http://www.msexchange.org/articles_tutorials/exchange-server-2007/high-availability-recovery/exchange-2007-clustering-questions-part2.html

PART-2

Introduction

In part one of this article series we looked at some of the questions, often posted in the various public newsgroups and forums, related to the continuous replication features of Exchange 2007. These questions focused on topics such as the status of storage group copies, applying update rollups to clusters, and the number of nodes in a Cluster Continuous Replication (CCR) environment. Here in part two we will continue by looking at additional clustering questions related to Exchange 2007.
How Can I Move an Existing Single Server to a New CCR Environment?

Some organizations have deployed a single Exchange 2007 server to satisfy their needs. These servers will always be running the mailbox, Client Access Server and Hub Transport server roles as these three roles are mandatory in any Exchange 2007 organization. In some cases, it has been known for the Unified Messaging role to also be co-located on the same server. Sometimes these organizations realize that messaging has become more and more important to the business and therefore a move to one of the clustered mailbox server roles becomes attractive. By clustered mailbox server, I am referring to either a CCR or Single Copy Cluster (SCC) environment.
The first area to understand about a possible move to a CCR or SCC environment is the following ‘rules’ regarding the clustered environment:

1. If you implement a clustered mailbox server running either CCR or SCC, you cannot have any roles other than the mailbox server role running on that clustered mailbox server.
2. Noting point 1, this means that at least one server outside of the CCR or SCC environment is required to run one or both of the Client Access Server or Hub Transport server roles.
3. A CCR environment consists of two nodes, whereas a SCC environment can consist of between two and eight nodes.

Therefore, let us look at a likely design of a new infrastructure that is moving away from a single combined server. If a single combined server is performing satisfactorily, then it is fair to say that either a two-node CCR or SCC environment will more than suffice. This will need to be constructed on new hardware alongside the existing server, with new storage groups and new databases constructed. Once the new clustered environment has been built, the mailboxes can simply be moved from the existing combined server to the new clustered environment using the built-in tools found in either the Exchange Management Console or the Exchange Management Shell. Once this has been done, the mailbox role can be removed from the combined server to leave a server running just the Client Access Server and Hub Transport server roles.
You may be wondering at this stage what the point of a clustered environment is if there is only a single Hub Transport or Client Access Server role. It is a valid point since the single server running both of these roles have a chance to fail, vital functions (such as the ability for users to send or receive any new messages) will be lost. If you are going to deploy high availability for your mailbox server role, you really should be deploying high availability for the Client Access Server and Hub Transport server roles. Therefore, the most logical thing to do is to deploy an additional server that can also run the Client Access Server and Hub Transport server roles and load balance this with the existing server running the same two roles. This means that the new system has high availability throughout.
The result is that you have moved away from a single server environment to a new environment consisting of four servers.
Is The MSDTC Cluster Resource Required In Exchange 2007?


The simple answer to this question is no. In earlier versions of Exchange, such as Exchange 2003, the Microsoft Data Transaction Coordinator (DTC) resource was required in a clustered environment for operations such as installing Exchange service packs. This is not the case in Exchange 2007 and therefore a DTC cluster resource is not required.
Can a Single SCR Server Exist as a Target For Multiple CCR Environments?


Yes, one of the features of Standby Continuous Replication (SCR) is the fact that a single SCR server can function as a target server for multiple source servers. For example, a production system could consist of two separate CCR environments in one data centre, whilst a single standby cluster could exist in the disaster recovery data centre and serve as the SCR target server for both production CCR environments. Note, though, that such a configuration would not provide true site resilience for both production CCR environments, as only one CCR environment at any time could be recovered to the SCR target server. It would be possible to consider a scenario where, perhaps, one of the CCR environments hosts VIP mailboxes that are recovered if the site hosting both production CCR environments is lost. There are several configuration areas to watch for if this configuration is being planned. They are:

• The SCR target server cannot host more than 50 storage groups in total. Therefore, both CCR environments in the production data centre cannot have a combined total of more than 50 storage groups. For example, a valid configuration would be one where each production CCR environment contains 25 storage groups.
• The SCR target server must be running the same operating system as the production CCR environments.
• It is very important to plan the storage group and database paths on the CCR and SCR environments as they must not clash. For example, a situation to avoid would be one where both CCR environments had the first storage group database stored in, say, the D:\SG1DB folder. In this case, it would not be possible to enable SCR for this storage group as both storage groups would be contending for the same folder location on the SCR target server.

However, it is also worth pointing out that, in the case where multiple CCR environments replicate to a single SCR standby cluster, there is another limitation of this configuration that you should understand. For example, if you were to recover a single Clustered Mailbox Server (CMS) onto the SCR standby cluster, the remaining CCR environments will no longer replicate their transaction logs to the SCR standby cluster since it will now be hosting an active CMS. Therefore, it is more likely that you would need to configure the SCR target server as a standalone server rather than a standby cluster and use database portability to recover databases as required. All in all, this configuration should be planned carefully and any limitations understood.
What’s The Deal With The Offline Address Book on a Cluster?


Many Exchange administrators have deployed a CCR environment and hosted the Offline Address Book (OAB) on this CCR environment only to discover that the event log entry shown in Figure 4 is generated some time after the CCR environment has been failed over.

Figure 4: Event Log Entry 9395
Let us examine what this event log entry means in more detail. Consider a freshly installed CCR environment that consists of two nodes called CCRA and CCRB. In this CCR environment, the node CCRA was installed first. If we examine the contents of the HKLM\System\CurrentControlSet\Services\MSExchangeS A\Parameters\CCRA registry key on either cluster node, we can see that the EnableOabGenOnThisNode entry is set to a value of CCRA, which is the name of the first node installed into the CCR environment. This is shown in Figure 5.

Figure 5: The EnableOabGenOnThisNode Registry Key
If the OAB is hosted on a CCR environment, it should be noted that it can only be generated on a single node of that CCR environment and obviously by default this is going to be the first node installed to form that CCR environment. The reason for this is that the data that comprises the OAB is stored locally to each server and does not therefore form part of the continuous replication process used within a CCR environment. Once the CCR environment has been failed over to the remaining node, event 9395 shown above in Figure 4 can be recorded.
To work around this issue after a failover event, it is possible to modify the registry on the now active node so that the registry key mentioned earlier now references the new node name. For example, in the CCR environment that I am detailing in this article node CCRA was the first node to be installed and therefore the registry key references this node name. If the CMS is now moved to node CCRB, the registry key on node CCRB can be modified to reference the server name CCRB. However, be careful when doing this as a new OAB is generated as a result. The result of this is that the new OAB will need to be downloaded by the clients which may cause significant network traffic. Of course, if the CMS is moved back to node CCRA, the same process would be required.
The recommendation is not to generate the OAB on a clustered environment. It is a technically acceptable location but is not necessarily the best location. For more information on this topic, I strongly recommend that you read Dave Goldman’s blog post here.
Summary

That concludes this article series where we have examined various questions that are asked around the use of clustering in Exchange 2007. The topic of clustering in Exchange 2007 is huge and obviously not all scenarios and questions can be covered in this article. Hopefully, though, the areas that have been covered will prove useful to those of you reading this article.