Skip to content

Configuring DAG Networks in Exchange 2010

by on September 26, 2012

Many Exchange 2010 administrators are familiar with working with database availability groups (DAG) and the multiple copies of mailbox stores they provide. One area of confusion around DAGs, however, is properly configuring DAG networks. This article reviews how to configure a multi-site DAG that consists of multiple networks.

The example I will be using consists of Exchange Servers hosted in two physical locations. Each server has three network cards and resides on three different VLANs. For simplicity, there will be no teaming. The VLANs serve the following functions:

  • General network traffic: This network resides on the server VLAN and is fully routable. In Exchange terms, this network is known as the MAPI network. All standard network traffic communicates on this network.
  • Replication traffic: This network is dedicated to replication traffic between the Mailbox servers that are members of the DAG. This network is known as the replication network.
  • Storage network: This network is used for iSCSI based storage and connects to the SAN. Certainly, many installations will not include a storage network. I include it as an example because when doing the initial configuration of the DAG, there are steps that must be taken to ensure that specific NIC cards are excluded from participating in the DAG.

It is also common to have a dedicated network reserved for running system backups only. This network should be configured the same way as the storage network being used here in that it should be excluded from participating in the DAG.

There are several items to keep in mind when configuring DAG networks:

  • There must be one MAPI network. If there is not going to be a replication network, the MAPI network will be used for replication.
  • Replication networks are optional. There can be multiple replication networks.
  • If the replication network fails, the DAG will fail back to the MAPI network for replication.
  • If you want to utilize a replication network, it must reside on a different subnet than the MAPI network. This often makes it difficult to use a replication network when building a DAG across multiple locations. The reason being that multiple WAN connections would be needed in order to separate the MAPI traffic from the replication traffic. (After all, creating multiple VLANs within a single WAN connection defeats the purpose of creating a replication network since both networks would be sharing the same bandwidth.)
  • Each server within a DAG must have the same number of replication networks. This means that you cannot use a replication network between two local Mailbox servers and not use a replication network for a server that is a member of the same DAG located across a WAN connection.

Before configuring the DAG, it is important to set up the network adapters properly.

  • Start by giving each adapter a descriptive name. I like MAPI, Replication, and Storage.
  • Configure the properties of each NIC.
    • Assign each network card an IP address and subnet mask.
    • Assign a default gateway only to the MAPI adapter. The default gateway must be blank on the Replication and Storage adapters.
    • Assign DNS entries — again only to the MAPI adapter. Leave the other two blank.
    • Uncheck the Register this connection’s address in DNS box on the Replication and Storage networks.
    • Configure the network adapters as follows:
Network Client for MS Networks QoS Packet Scheduler File & Print Sharing IPv6 IPv4 Link-Layer Mapper I/O Driver Link Layer Responder
MAPI Enabled Optional Enabled Enabled Enabled Enabled Enabled
Replication Disabled Optional Disabled Enabled Enabled Enabled Enabled
Storage Disabled Optional Disabled Enabled Enabled Enabled Enabled
  • Configure static routes for the replication adapter cards using netsh. This could also be done using the Route Add command, but Microsoft recommends not using this method as there have been issues with it. The commands are as follows (I will use networks and in the example below):
    • netsh
    • interface
    • ipv4
    • show interfaces (make note of the correct interface name)
    • add route “Replication Network” (for servers on the network)
    • add route “Replication Network” (for servers on the network)
    • Confirm that the servers can ping one another on the replication network. Use Tracert to ensure that the two adapters are communicating with one another directly and not routing across the MAPI network.
  • Lastly, configure the binding order of the network cards. The main task is to configure the MAPI network to be first. The order of the others is not so important. To set the binding order: go to Network Connections, hit Alt N, and select Advanced Settings to expose the Adapters and Bindings screen. See the screenshot below.

Now we are ready to configure the DAG networks. Of course, this can be done through the Exchange Management Console or the Management Shell.

Since this DAG sits in two physical locations, don’t forget to enable DAC mode: Set-DatabaseAvailabilityGroup –identity <name of DAG> –DatacenterActivationMode DagOnly. You may also want to prevent the mailbox stores from automatically mounting on servers in the second site: Set-MailboxServer -Identity <name of server> -DatabaseCopyAutoActivationPolicy blocked.

After initial creation of the DAG, if you navigate to the DAG properties in the Exchange Management Console (Organizational Config > Mailbox > Database Availability Groups > Highlight the DAG) you will notice that under the Networks tab there will be networks labeled DAGNetwork01, DAGNetwork02, etc. This represents each physical network that exists within the DAG. In my example, there were six DAG networks: three in the primary data center for the server, replication and storage NICs; and another three in the disaster recovery center.

If some entries are missing, you can have Exchange rescan the network by executing the following command: Set-DatabaseAvailabilityGroup – DiscoverNetworks

Configuring the DAG network:

First, collapse the networks. In my example, the six unique networks will be collapsed into three (MAPI, Replication, and Storage).

Note: It might be helpful to re-label three of the DAG networks at this point. To do so, right click and select properties for each DAG network to expose this setting.

Expand the Network Interface node under each DAG network to expose the IP addresses. You will be able to tell which NIC card is assigned to each DAG network. I started by dragging the IP address of the MAPI network adapter of the server in the DR site to the Network Interfaces node of the DAG network of the servers in the primary data center.

Once you’ve done this for all three networks, delete the three DAG network nodes that are now empty. The screenshot below shows my configuration.

The next step is to configure the networks. There are two things that need to be done: Disable replication traffic on the MAPI and Storage networks; and prevent the storage network from participating in DAG activities. Both these tasks are done with the Set-DatabaseAvailabilityGroupNetwork command:

  • Set-DatabaseAvailabilityGroupNetwork -Identity “<DAG>\MAPI Network” -ReplicationEnabled:$false
  • Set-DatabaseAvailabilityGroupNetwork -Identity “<DAG>\Storage Network” -ReplicationEnabled:$false -IgnoreNetwork:$true

If the Replication network should fail, DAG replication traffic will failback to the MAPI network even though it has been disabled. In the screenshot above, that replication shows it is disabled on the MAPI and Storage networks and enabled on the Replication network. Also, you’ll notice that despite setting the Ignore attribute on the Storage network, EMC does not show this. You can see the configuration of each network with the Get-DatabaseAvailabilityGroupNetwork command. For example, Get-DatabaseAvailabilityGroupNetwork –Identity “<DAG>\mapi network” | fl

Notice that ReplicationEnabled and IgnoreNetwork are both set to false, which is what we would expect for the MAPI network. The MapiAccessEnabled is set to true. This is not a parameter that can be set so it should be ignored. In my example, it also showed true on the backup network, even though the IgnoreNetwork attribute had been set to false.

Confirm that replication is occurring on the Replication network by issuing the following command: Get-MailboxDatabaseCopyStatus * -connectionstatus | fl inc*, out*

Finally, confirm that the IncomingLogCopyNetwork and OutgoingConnections shows the Replication network.

From → Infrastructure

Comments are closed.

%d bloggers like this: