A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 2)

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

 

 

• A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 1)
• A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 3)
• A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 4)
• A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 5)
• A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 6)
• A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 7)
• A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 8)
• A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 9)

 

Introduction

 

In part one of this article, I set the scene for the remaining parts of this article as well as detailed the general configuration options that applied to all servers on this particular project. We left part one having prepared the Active Directory schema to receive the first Exchange 2007 server. Here in part two we will continue the look at the order of events required to construct the new Exchange 2007 infrastructure, starting with the installation of the Hub Transport and Client Access Server roles.

 

Hub Transport and Client Access Server Installation

 

It was now time to install the first combined Client Access Server and Hub Transport server. Since these servers were being installed manually the Graphical User Interface (GUI) version of setup was invoked and the option to install a Custom Exchange Server Installation chosen. This was preferred over the Typical Exchange Server Installation option since this option installs the Mailbox server role as well as the Client Access Server and Hub Transport server roles. Selecting the Custom Exchange Server Installation option allowed me to select just the Client Access Server and Hub Transport server roles as you can see from Figure 1.

 

Figure 1: Installing the Hub Transport and Client Access Server Roles

 

When installing the Hub Transport server role onto an Exchange 2007 server that is to coexist in an Exchange 2003 infrastructure, you will be presented with a screen in the setup wizard that asks you to select a target Exchange 2003 bridgehead server that will be the connection point for a new Routing Group Connector that the Exchange 2007 setup program creates for you. This screen is shown in Figure 2.

 

Figure 2: Bridgehead Server Selection

 

In my case the Exchange 2003 environment simply consisted of a single routing group that contained two back-end mailbox servers so for this option I was able to select either of the Exchange 2003 servers for this purpose.

 

Once the setup routing had completed successfully, I checked the Exchange setup logs for signs of any errors that would be a cause for concern. The setup logs are found in C:\ExchangeSetupLogs and checking these is something that I like to do even if I receive a success message from the setup process. At the time of this particular installation the most recent update rollup for Exchange 2007 SP1 was Update Rollup 3 so this was applied manually simply by executing the MSP file downloaded from the Microsoft Downloads site. However, you should be aware of a handy tip for simplifying the process of applying the update rollup patches, particularly if you are deploying a large number of servers. If you examine the file structure of the Exchange source media, you should notice a folder called Updates that contains a single readme.txt file. If you examine the contents of this text file you will see the following text:

 

“Updates added to this folder will be installed during setup.”

 

Therefore, to automatically deploy the relevant update rollup patch at the same time as installing Exchange 2007, simply copy the update rollup patch to the Updates folder.

 

Once Update Rollup 3 had been applied, the newly installed Exchange 2007 server was then fully activated by launching the Exchange Management Console and entering the product key via the Enter Product Key menu option from the Action pane. This entire process was then repeated on the second combined Client Access Server and Hub Transport server.

 

Cluster Nodes Preparation

 

Although the actual CCR cluster nodes had been prepared with the Windows 2003 operating system and associated update patches, there was still quite a lot of configuration work to do regarding the network configuration. Obviously each cluster node contained two network cards as is standard for cluster configuration, with the additional network card existing to function as the intra-cluster communication channel or heartbeat network. Therefore, for easy identification purposes, I renamed the network connections from their defaults of Local Area Connection and Local Area Connection 2 to Public and Private respectively. Additionally, since the network now named Private only existed for cluster heartbeat purposes, there were several configuration changes that I had to make to this network connection. They were:

 

 

• Make sure that no DNS servers were defined on this network connection.
• Make sure that the check box titled Register this connection’s addresses in DNS was not selected. This option is shown in Figure 3.
• Make sure that the WINS option titled Disable NetBIOS over TCP/IP is selected.

 

Figure 3: Private Network Configuration

 

This network connection should not be using DNS servers since these are configured on the Public network connection. Additionally, this network connection will not be using NetBIOS over TCP/IP for similar reasons. Remember, this network connection exists for the purpose of allowing the two cluster nodes to communicate with each other. However, one important thing to remember here is that Microsoft generally recommends that you have the Client for Microsoft Networks and File and Printer Sharing for Microsoft Networks options enabled for the Private network connection. It is recommended that multiple networks (in this case the Private and Public networks) have this option enabled to provide fault tolerance for the Majority Node Set quorum resource that will be created later, but of course this depends on factors such as your network configuration. Finally I made sure that the network connection order was correct. This was achieved by going to the Network Connections object in Control Panel and on the Advanced menu option choosing Advanced Settings. This brings up the Advanced Settings window as you can see in Figure 4. The correct order of priority is Public, Private and then Remote Access connections.

 

Figure 4: Network Connection Order

 

The cluster nodes were then prepared with the pre-requisite software, namely .NET Framework 2.0 SP1, Windows PowerShell 1.0, Network COM+ Access and the World Wide Web Publishing Service.

 

Cluster Creation

 

The next step was the actual formation of the cluster itself, prior to the deployment of Exchange 2007 onto each cluster node. You can either do this via the Cluster Administrator program or via the command line using cluster.exe. Personally I chose to use the Cluster Administrator program so that’s what I will detail here. Before running the cluster wizard, I created a cluster service account in the domain which I’ll reference within this document as neilhobson\excluster.

 

I’ll briefly cover the screens presented within the cluster wizard:

 

 

1. First up was the opening Welcome screen of the New Server Cluster Wizard which I simply skipped past.
2. Next I was asked for the name of the domain into which the cluster was being installed, followed by the name of the cluster. In this case, that was CLUSTER1.
3. The next screen asked for the first node to be added to the cluster, for which I specified NODE1.
4. After this the wizard analyzed the configuration of NODE1 to ensure it was feasible to participate in a cluster. This proved successful and I was able to continue.
5. Next up was the IP Address page where I configured the IP address of the cluster itself. Note that this is not the IP address of the Clustered Mailbox Server (CMS) that Outlook users will connect to later.
6. The Cluster Service Account screen was then presented, whereby the service account that I created earlier was entered.
7. Finally, the Proposed Cluster Configuration screen was presented that gave me a summary of my chosen options. However, one important extra configuration item needed to be performed at this point and this was the configuration of the quorum resource. In Figure 5, you can see the Quorum button which when selected presented me with the Cluster Configuration Quorum window as you can see. I needed to make sure that the quorum was set to the Majority Node Set option.

 

Figure 5: Configuring the Quorum

 

Summary

 

This concludes part two of this article in which we have covered the installation of the Hub Transport server and Client Access Server roles as well as the initial cluster preparation steps. In part three of this article we will be taking a look at the cluster and file share witness configuration as well as the installation of the Clustered Mailbox Server (CMS).

 

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

 

 

• A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 1)
• A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 3)
• A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 4)
• A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 5)
• A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 6)
• A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 7)
• A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 8)
• A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 9)