If you would like to read the first part in this article series please go to Exchange 2007 Clustering Questions (Part 1).
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:
- 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.
- 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.
- 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\MSExchangeSA\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.
If you would like to read the first part in this article series please go to Exchange 2007 Clustering Questions (Part 1).
