Exchange Server 2007 SP1: Configuring a Redundant Network for Log Shipping

Introduction

Exchange Server 2007 SP1 introduced a lot of new features to Exchange Server 2007, in this article we are going to validate one of these new features which enables a CCR to use a different network than the public network for log shipping and seeding on Windows Server 2003/2008.

In Exchange Server 2007 RTM, all operations (transaction log file copying and seeding) occurs over the Public network which is the same as used by the clients to access their data (Figure 01). In some cases if there are a higher number of log files to be transferred it might impact client performance. From a security perspective the log files are being transferred through the Public network and to secure this process we can use encryption that increases the performance of the servers involved.

Figure 01: All communications between Active node and clients occur through the Public network, and the same behavior for the transactional logs

After SP1, we can use one or more networks for log shipping. We just need to associate a hostname and IP address to be used by the Replication service. If we have more than one redundant network available the service will pick one randomly to use. If one redundant network becomes unavailable the other redundant network will be selected. If none of the redundant networks are available the public network will be selected. The replication service discovery service runs every 5 minutes. As soon as an available redundant network is detected the replication will start to use the redundant network instead of the public network.

Another change in SP1 was a new parameter for the Update-StorageGroupCopy cmdlet, called DataHostNames. Using this parameter we can specify which Continuous Replication HostName will be used for seeding.

Prerequisites to deploy the redundant network feature in Exchange Server 2007 SP1

Before creating the hostnames and IP address resources to be used we must make sure that some points were covered, such as:

• Configure the network that will be used to replicate as a Mixed network in the Cluster Administrator.
• Configure Windows Server 2003 to be accessed through Alias names.
• Configure resolution to the new hostnames that can be done using DNS or host files.

Our current settings for this article can be seen in the first three columns of the table below (Table 01). Let us assign a Continuous Replication Hostname and an IP Address for each node. Note: this IP address must be an address in the same range of the Redundant Network.

Table 01: Defining the Host and IP address to be in use by the Replication service

Configuring the Cluster network

Even though this network will not be accessed by external clients it must be defined as a mixed network. This is because we cannot create a cluster resource using a network defined as Internal cluster communications only. To change this setting:

1. Open Cluster Administrator.
2. Expand Cluster Configuration, then Networks.
3. Right click on the network designated to be the internal network (also known as Heartbeat) and then Properties.
4. Select the option All communications (mixed network) and then click on OK (Figure 02).

Figure 02

Accessing Windows Server 2003 through an alias name

In Windows Server 2003 a registry key must be added in all nodes of the CMS (Clustered Mailbox Server) to allow access through the alias name – by default this behavior is blocked.

Open the registry, and expand HKEY_LOCAL_MACHINE, System, CurrentControlSet, Services and Parameters. Then, right click on the right side and click on New, click on Dword Value, type in DisableStrictNameChecking, define the new value as 1. The result will be shown in Figure 03.

Figure 03

For the changes to take effect a server restart is required and this process must be done on both nodes.

Configuring name resolution

We must make sure that the node cluster will be able to resolve the correct IP address of the Continuous Replication HostNames which will be used to replicate. The names specified in Table 01 must be resolved on the cluster nodes; we can accomplish this in two different ways:

DNS Server

1. Open the DNS Manager responsible for DNS resolution on that box.
2. Expand your internal zone.
3. Right click on your zone and click on New, Add A Record.
4. Type in the Host Name that will be used to replicate and its IP address.
5. Repeat steps 3 and 4 for each node.

Host File

The second method is using the HOSTS file. To do that we need to edit the file called hosts which is located in C:\windows\system32\drivers\etc and manually add the entries for each Continuous Replication Hostname.

Configuring a Redundant Network

We are not able to set this feature up through the Exchange Management Console, all the steps must be performed through the Exchange Management Shell.

To create the hostname for replication we will use the Enable-ContinuousReplicationHostname cmdlet for all nodes that will be used in the replication (Figure 04), the syntax is demonstrated below:

Enable-ContinuousReplicationHostname –Identity <CMS Name> -TargetMachine <Node Name> -HostName <Network Name for Replication> -IPV4Address <IP Address>

Figure 04: In our article we going to add the hosts Node01Bkp and Node02BkP using the information in Table 01

The cmdlet which we have just run will take some time to execute, after that we can open the Cluster Administrator and we will see a new Cluster Group with two resources: IP and Name, as shown in Figure 05.

Figure 05: The two new cluster resources created by the cmdlet Enable-ContinuousReplicationHostname

Now, we can check out which Host Names are being used by the clustered Mailbox Server for replication. To do that we can use the Get-ClusteredMailboxServerStatus cmdlet (Figure 06). We will be able to see that we have 4 (four) operational replication hostnames: two Continuous Replication HostNames (node01bkp and node02bkp) and two server names. At the moment only the Host Names node01bkp and node02bkp are being used to replicate the CMS data. This means that the replication is occurring through a redundant network.

Figure 06

Now, let us validate the replication using the Performance tool. We will open the tool in the second node and we will add the performance counter called Bytes Total/Sec. From the object Network Interface we will also add the two instances Network card 1 and 2. After sending a message of 4MB to a user located in the CMS server, we will be able to see that replication is using the backup network instead of the Public Network. (Figure 07)

Figure 07: Analyzing the redundant network usage in the Performance Monitor

Turning off the redundant networks

In order to understand how to manage a redundant network, we have to know how to remove an existing hostname. To remove a Continuous Replication Name we use the Disable-ContinuousReplicationName cmdlet. In Figure 08 we can see the syntax that is only the hostname and a confirmation to get it done. This process also removes the cluster group from the cluster configuration.

Figure 08

Conclusion

In this article we have seen how to manage redundant networks to be used for the log file shipping and seeding process in a CCR environment.