Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 2)

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


In part 1 of this multi-part article, I gave you a look at how medium organizations typically deployed a site resilient solution

with Exchange 2007. In addition, I described the two scenarios that will be the most interesting to medium organizations.

In this part 2, I’ll describe the deployment steps necessary for the first scenario which is a two-datacenter model. In this scenario each datacenter will use different namespace and both will have Internet connectivity. In addition only the primary datacenter will have active users unless we’re speaking short periods where the active database copy is switched over to the failover datacenter for one reason or the other.

Figure 1:
Site Resiliency in Exchange 2010 (active/passive datacenter model)

Lab Environment

The environment has been built using Hyper-V R2 based virtual machines. As you can see in Figure 1, the environment used as the basis for this multi-part article simulates two datacenters:

Primary Datacenter

The primary datacenter consists of:

  • 1 x AD site (Datacenter-1)
  • 1 x MAPI replication network (subnet:
  • 1 x Replication network (subnet:
  • 2 x Windows Server 2008 R2 Domain Controllers
  • 2 x Exchange 2010 multi-role servers (CAS/HUB/MBX)
  • 1 x Redundant hardware load balancer (KEMP LoadMaster)

Failover Datacenter

The failover datacenter consists of:

  • 1 x AD site (Datacenter-2)
  • 1 x MAPI replication network (subnet:
  • 1 x Replication network (subnet:
  • 2 x Windows Server 2008 R2 Domain Controllers
  • 2 x Exchange 2010 multi-role servers (CAS/HUB/MBX)
  • 1 x Redundant virtual load balancer (KEMP LoadMaster)

Since Hyper-V doesn’t include any routing functionality, I use a virtual Vyatta based router to isolate the networks. I’ve created four networks in the router and each MAPI network and each replication network are allowed to communicate with each other on all ports. But no cross network communication between MAPI and replication networks are allowed as this isn’t recommended nor supported by Microsoft.

All four Exchange 2010 servers runs Windows Server 2008 R2 Enterprise edition as DAG requires the Enterprise edition. This is because like CCR and SCR, DAG still utilizes part of the Windows Failover Cluster component (heartbeat, file share witness, and cluster database). Bear in mind that the Exchange 2010 DAG functionality itself is not dependent on Exchange 2010 Enterprise edition (only Windows Server 2008 R2 Enterprise edition). This means that you can use the standard edition of Exchange 2010, if you are going to follow along in your own lab. The standard edition just limits you to a total of 5 databases (including active and passive copies) on each Exchange 2010 server.

Each Exchange 2010 server has 2 network cards installed, one connected to the production (MAPI) network and another connected to an isolated replication network. Although it’s a good idea to use at least two NICs in each DAG member (one for MAPI access and one or more for replication, seeding and heartbeat purposes), it is worth mentioning that Microsoft supports using a single NIC for both MAPI access, replication, seeding, and heartbeats.

Active Directory

Going through the steps required in order to deploy an Active Directory forest as well as configuring the AD topology is outside the scope of this articles series, but in short the environment consists of 4 domain controllers and the AD name is named “”. Two AD sites exist, the “” subnet is associated with “Datacenter-1” and subnet “” is associated with “Datacenter-2”.

Figure 2: Active Directory sites and subnets

Preparing the Exchange 2010 Servers

In this section, I’ll take you through configuration of the virtual machines on which Exchange 2010 will be installed.

Network Settings

Two NICs have been installed in each of the four Exchange servers. Let us look at the way each NIC has been configured. To do so, open “Network Connections”. Here we have the two NICs listed, and as you can see we have a PROD (connected to the production/MAPI network) and a REPLICATION interface (connected to an isolated network used for database replication, seeding, and heartbeat).

Figure 3: Network connections

Let’s open the property page of the “PROD” interface. Here it is typically fine to leave the default settings as is. Optionally, you can uncheck “QoS Packet Scheduler” and “Internet Protocol Version 6 (TCP/IP v6)”.

Figure 4: Properties of PROD interface

Open the property page of “Internet Protocol Version 4 (TCP/IPv4)”. Here we have a static IP address configured as well as the other necessary settings (default gateway, subnet mask, and DNS server).

Figure 5: TCP/IP Version 4 Properties for the PROD interface

When you have configured the NIC correspondingly, close the property page by clicking “OK” twice.

Let’s switch to and configure the network settings for the “REPLICATION” interface. We do so by opening the property page of the “REPLICATION” NIC. Uncheck “Client for Microsoft Networks” and “File and Printer Sharing for Microsoft Networks” as shown in Figure 6. In addition, you may optionally uncheck “QoS Packet Scheduler” and “Internet Protocol Version 6 (TCP/IPv6)”.

Figure 6: Properties for the REPLICATION interface

Now open property page of “Internet Protocol Version 4 (TCP/IPv4)” and enter an IP address and subnet mask on the isolated replication subnet. Although each Exchange server must be able to communicate with Exchange servers located on another subnet in another datacenter, you should not specify any default gateway or DNS servers as it isn’t supported with multiple default gateways via the GUI on a Windows 2008 R2 server with Exchange 2010 installed. I’ll show you how we solve our little routing issue in just a minute.

Figure 7: TCP/IP Version 4 properties for the REPLICATION interface

Now click “Advanced” and uncheck “Register this connection’s addresses in DNS” and then click “OK” twice.

Figure 8: Advanced TCP/IP Properties for REPLICATION interface

Now that we have configured each NIC, we must make sure the “PROD” NIC is listed first on the binding order list. To bring up the binding order list, you must press the ALT key, and then select Advanced > Advanced Settings.

Figure 9: Selecting Advanced Settings in the Network Connection menu

If not already the case, move the “PROD” NIC to the top as shown in Figure 10.

Figure 10: Binding order for the network interfaces

Click OK and close the Network Connections window.

You should of course make sure the above steps are performed on all four servers.

Configuring Static Routes for the Replication Networks

Since we have two NICs on different subnets in each server and because it isn’t supported to specify a default gateway on multiple NICs in the server, we need to create static routes for the replication network on each Exchange server.

Figure 11: Warning message when configuring multiple default gateways

If you configured your routing device properly, each MAPI subnet and each replication subnet should now have been configured so MAPI to MAPI and replication to replication network communication is allowed. This means that a server in the primary datacenter should be able to ping a server in the failover datacenter using the Netbios (server) name or IP address and vice versa.

Figure 12: Pinging from one MAPI subnet to the other 

However, pinging a server using the IP address on the replication subnet in the other datacenter should fail since Windows tries to use the default gateway of the MAPI network.

Figure 13: Request timed out when ping the replication subnet in other datacenter

We can fix this issue by creating a static route for the replication subnet in the other datacenter. If you have ever created static routes on a Windows machine, you probably used “Route Add” to do so. Although “Route add” should do it, the recommendation for Windows Server 2008 and R2 has changed. We should instead use the “Netsh” tool for this purpose. But fear not “Netsh” is just as easy to use as “Route add”, the syntax is just a bit different.

So to create a static persistent route for from subnet to using “Route add”, we would use the following command:

Route add mask –p

This would send all traffic destined for to the gateway which then would route it to the respective servers on the subnet. To create the same static route using “Netsh”, we would instead use the following command:

Netsh interface ipv4 add route “REPLICATION”

Figure 14: Creating static route using Netsh

Where the name of the replication network interface is “REPLICATION” and the default gateway is

With “Netsh” the route by default and unlike “Route add” will be created as a persistent route.

We should now be able to ping IP addresses on subnet and vice versa.

Figure 15: Pinging IP address on replication subnet in other datacenter

Okay we have now configured the network settings accordingly.

Storage Preparation

In the environment used in this article series, I have created a total of four virtual disks (LUNs) for each Exchange server. This is because we will create four mailbox databases and each will employ a DAG where we have a database copy on each Exchange server. This means we need four database LUNs per server in this particular environment. Since we have +3 database copies, we will enable circular logging and have log files located in the same folder as the EDB databases. Figure 16 shows the LUNs in Disk Manager.

Figure 16: Database LUNs on each Exchange server

Ok this ends part 2 of this article series. But fear not part 3 will be published in the near future.

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

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top