Misconfigured Subnets Appear in Exchange Server 2013 DAG Network

With an Exchange Server 2013 database availability group you may encounter misconfigured subnets in the DAG network configuration.

These will be noticeable in the output of the Get-DatabaseAvailabilityGroupNetwork cmdlet.

exchange-2013-dag-network-misconfigured-01

This can occur when the database availability group automatic network configuration is not able to correctly determine how to configure each network.

Exchange Server 2013 Automatic DAG Network Configuration

Automatic network configuration is a new feature of database availability groups in Exchange 2013. In Exchange 2010 although DAG networks were automatically created they were usually not configured correctly by default, especially when multiple subnets were being used.

As a result Exchange 2010 administrators had to manually reconfigure and collapse the DAG networks for the best DAG network performance and to avoid some problem scenarios.

Automatic network configuration in Exchange 2013 seeks to relieve some of that burden, however it can have problems when it is not able to clearly determine which subnets should be configured on which networks.

To make those decisions Exchange 2013 follows a few basic rules of DAG network interface configuration.

  1. The MAPI, or client-facing network interface should be configured with
    • a default gateway
    • at least one DNS server
    • “Register this connection’s addresses in DNS” enabled
  2. The replication network interfaces, if there are any, should be configured with:
    • no default gateway
    • no DNS servers
    • “Register this connection’s address in DNS” disabled
    • static routes if the network will span multiple IP subnets

If those conditions are not met then DAG network automatic configuration may not produce a good result.

Example Scenario

For example, in this three member DAG the server E15MB3 is located in a different subnet to the other two servers.

exchange-2013-dag-network-misconfigured-02

The “Register this connection’s address in DNS” checkbox has been inadvertently left ticked.

exchange-2013-dag-network-misconfigured-03

Before the server E15MB3 is added as a DAG member the networks appear like this:

[PS] C:\>Get-DatabaseAvailabilityGroupNetwork | select Name,Subnets,Interfaces

Name               : MapiDagNetwork
Subnets            : {{192.168.0.0/24,Up}}
Interfaces         : {{E15MB1,Up,192.168.0.187}, {E15MB2,Up,192.168.0.188}}

Name               : ReplicationDagNetwork01
Subnets            : {{10.1.100.0/24,Up}}
Interfaces         : {{E15MB1,Up,10.1.100.2}, {E15MB2,Up,10.1.100.3}}

After the server is added as a DAG member the networks appear like this:

[PS] C:\>Get-DatabaseAvailabilityGroupNetwork | fl

Name               : MapiDagNetwork
Subnets            : {{192.168.0.0/24,Misconfigured}, {192.168.1.0/24,Misconfigured}, {10.1.101.0/24,Misconfigured}}
Interfaces         : {{E15MB1,Up,192.168.0.187}, {E15MB2,Up,192.168.0.188}, {E15MB3,Up,192.168.1.190},
                     {E15MB3,Up,10.1.101.2}}

Name               : ReplicationDagNetwork01
Subnets            : {{10.1.100.0/24,Up}}
Interfaces         : {{E15MB1,Up,10.1.100.2}, {E15MB2,Up,10.1.100.3}}

Correcting the Misconfigured Subnets

Once the misconfiguration is present in the DAG networks you can take a few steps to correct it.

The first is to review the network interface configurations and adjust them to align with the conditions outlined earlier. In this case this means disabling DNS registration on the replication network interface of E15MB3.

exchange-2013-dag-network-misconfigured-04

The Set-DatabaseAvailabilityGroup cmdlet has a -ManualDagNetworkConfiguration parameter that can be enabled to allow manual network configuration.

[PS] C:\>Set-DatabaseAvailabilityGroup E15DAG -ManualDagNetworkConfiguration $true

Simply running that command appears to force the DAG to reassess the network configuration, and in my own testing this resulted in a correct DAG network configuration without me actually having to perform any manual configuration.

[PS] C:\>Get-DatabaseAvailabilityGroupNetwork | select Name,Subnets,Interfaces

Name       : MapiDagNetwork
Subnets    : {{192.168.0.0/24,Up}, {192.168.1.0/24,Up}}
Interfaces : {{E15MB1,Up,192.168.0.187}, {E15MB2,Up,192.168.0.188}, {E15MB3,Up,192.168.1.190}}

Name       : ReplicationDagNetwork01
Subnets    : {{10.1.100.0/24,Up}, {10.1.101.0/24,Up}}
Interfaces : {{E15MB1,Up,10.1.100.2}, {E15MB2,Up,10.1.100.3}, {E15MB3,Up,10.1.101.2}}

With the networks now correctly configured you can set the DAG back to automatic network configuration if you wish.

[PS] C:\>Set-DatabaseAvailabilityGroup E15DAG -ManualDagNetworkConfiguration $false

The DAG networks should remain correctly configured.

Summary

As you can see automatic network configuration in Exchange Server 2013 database availability groups makes our lives a bit easier by reducing the amount of manual configuration required in more complex DAGs.

However, it relies heavily on correct underlying network interface configurations, so you need to ensure those are configured properly before you begin adding servers to your DAG.

About Paul Cunningham

Paul is a Microsoft Exchange Server MVP and publisher of Exchange Server Pro. He also holds several Microsoft certifications including for Exchange Server 2007, 2010 and 2013. Connect with Paul on Twitter and Google+.

Comments

  1. It is disappointing that Microsoft is still pushing a two network solution in 2013. Single network should be the standard configuration with splitting the Replication network only required in unique situations. That is a rant about Microsoft’s choices though, good write up on the caveats of this new auto configuration feature.

    • Single network is still the only requirement. There’s no push to a two (or more) network solution. On the contrary, most Microsoft folks I talk to agree that less complexity is better, so don’t add more networks unless you have the genuine need (which some do).

  2. We use Microsoft Exchange Server 2013 and found it very efficient , better performance than previous one and them most valuable part it is easy to understand.

  3. Peter Smith says:

    A useful article, Paul. Thanks. However, I found that, about five minutes after I set the ManualDagNetworkConfiguration back to $false, the auto-configuration changed the MAPI networking to “misconfigured” again. So, I’m running happily with manual configuration permanently on. It seems that auto-configuration is not to be trusted.

  4. Peter Smith says:

    I can’t see anything wrong with the networks, Paul. The fact that, as soon as you enable manual config, it’s all OK without having to tweak anything seems to confirm this.

    The two cluster members are connected by three LANs on separate subnets; only one (the client/MAPI one)is registered in DNS and this one is top of the bindings. Cluster manager is quite happy with this arrangement.

    So, the answer to your question is: No, I haven’t fixed anything but it’s all happy until I turn suto config on.

  5. Peter Smith says:

    I’ve gone carefully through that document and all parameters are correct except that the MAPI network has no default router (it doesn’t need to get anywhere that is not on connected networks) and the one big difference is that both cluster members are also domain controllers (yes, I know – but hardware constraints make this necessary).

    Because two of the subnets do have other traffic on, I disabled replication on these and installed a new LAN between the two machines on a new subnet. This ONLY has replication traffic. On switching to auto-configuration, the networks immediately go to “mis-configured” and revert to proper configuration when auto is disabled.

    Since I’m running on DCs, MS aren’t going to be interested in this but I do think it validates your original article and your advice to turn network auto-configuration off – even if there’s a difference of opinion whether to turn it back on again.

    Can I also say how valuable I’ve found your articles during my migration from WS08R2/EX2010 to WS12/EX2013. You always have good advice presented in an easy-to-read format. Many thanks.

    • I would say that the lack of a default gateway on the MAPI network interfaces the most likely problem then.

      Network auto-config can’t work out which networks to configure without all those clues being present.

  6. Peter Smith says:

    I thought you might be interested in the underlying reason why autoconfig got it wrong on my setup. Although the networks are set up exactly in your para 2 above, i.e. with “Register this connection’s address in DNS” disabled, one of the DNS serves was listening on a Replication subnet. This automatically added entries in DNS for that interface which couldn’t be deleted from DNS manager and that cause autoconfig to pick these up as MAPI enabled; hence mis-configured multi MAPI subnets.

    As I said above, I’m running EX2013 on DCs and it’s habit to run DNS on those servers. Multi-homed DCs are OK if DNS is right – but it wasn’t. The important thing is to get DNS working exactly right. All is happy and clean now!

  7. Nicholas Herbert says:

    Hi Paul
    I am relatively new to exchange and completely new to ex 2013 but am learning the basics now (required for job)
    could you explain quickly why someone would have 2 different networks for a DAG – why not have just replication and MAPI traffic on the 1 network? From my early reading on exchange 2013 I though that MAPI is no longer used in exchange 2013 and it uses RPC over HTTP for users connecting through outlook to Mailboxes both internally and outside the organisation? When you say MAPI or client facing network – you mean users accessing their email through outlook – right? and replication is for the log shipping to keep database copies up to date in the DAG? I probably am way behind technically on exchange than your other users at the moment – but thats how we learn!! Thanks for you help

    • Yes, in 2013 the RPC communications from the Outlook clients are occuring inside a HTTP/HTTPS connection.

      However, the client does not connect directly to the DAG. TechNet pages such as this one…

      http://technet.microsoft.com/en-us/library/dd638104(v=exchg.150).aspx

      …include statements such as “Each DAG must have a single MAPI network, which is used by a DAG member to communicate with other servers”.

      You can just have one DAG network if that suits your environment, and it will be used for both MAPI and replication traffic. However, this DAG network misconfiguration issue doesn’t occur in single-network scenarios. So I am using a multi-network DAG to demonstrate the issue.

      Yes, “replication” refers to the database replication that is occuring from the active database copy to the passive database copies.

  8. Hey Paul,

    I have just been planning the setup of our DAG for exchange 2013. I went in with a plan of 3 NICs per mailbox server. 1 for ‘client facing’ traffic on the main network, and then two interfaces on a 192.168.102.x subnet for DAG replication.

    I created the DAG and added in two mailbox servers. Doing a Get-DatabaseAvailabilityGroupNetwork | fl shows that the networking has been set up well. I changed the networking to manual mode though so I can disable replication on the ‘Mapi’ network.

    But, it only added one of the NICs per server into the ‘ReplicationDAGNetwork01′ that was automatically created.

    Am I best just to team the two NICs and present 1 NIC to the mailbox server, rather than having 2 individual NICs on each mailbox server in hope of getting all of those interfaces included in DAG replication?

    Cheers.

    • I see no advantage to having two NICs on a server both on the same DAG network, in fact I’m not even sure it will work properly. Teaming is also not necessarily going to work well.

      My recommendation would be to have each NIC on a separate DAG network.

      • OK thanks Paul. I wasn’t sure if the best way was to have multiple NICs on the same network (for throughput and for HA purposes) or on different networks. Thanks for the advice.

  9. Patrick Spencer says:

    We do not have the property “Subnets” in our installation of Exchange 2013 CU3.
    What version of the Exchange 2013 is this documented from?
    We have a single network and both servers are on the same subnet.

    We are obviously having issues, otherwise I wouldn’t be ready this. :)
    I get an error when I try to create a Database copy in one direction, but not problem in the other direction.
    The server giving the problem shows 2 IP Addresses (One is a DHCP Address of all things) on the single network card.

  10. Hi Paul,

    How to configure Replication NIC across the site.

    shall i give the static route in replication NIC or extend the replication VLAN to another site.

    • Both are valid solutions and it is entirely up to you which one you choose.

      Stretching the VLAN may be the easiest. If that isn’t possible then static routes are the way to go.

      • Thanks a lot.

        One more query i have we are facing Copy queue length with our Mail box server same site as well as cross site.

        And, We have single NIC for MAPI & replication.

        do you think because of Single nic we are facing this issue or it may relevant to other concern.

        • Could be network adapter being saturated, could be other network component being saturated, could be disk performance issues, could be a very high volume of transaction logging.

          You’ll need to dig into it further.

  11. Philip Townsend says:

    Hi Paul! Thanks for all you do!

    We have a 2 site, 4 member, Exchange DAG configured similarly to the one in your example but we have two separate replication subnets (one at each of 2 sites, not routed). The DAG members replicate cross-site over the single routed mapi network.

    On a Get-ReplicationHealth we get a message – “Network ‘ReplicationDAGNetwork01′ (the Site2 Replication subnet) has no network interface for server ‘site2-e2k13mbx1′” despite the results of Get-DatabaseAvailabilityGroupNetwork showing the interface for ‘site2-e2k13mbx1′ UP and part of the network. We’ve cleaned up DNS registration and double checked other ‘best practice’ settings but can’t get the ReplHealth to report pass for that network. Do you know what else could be causing the auto-config you recommend to not work?

    We are not sure about having two separate replication subnets. To correct this situation we’re considering adding static routes between the replication subnets OR removing the replication network altogether. Our physical/WAN layout does not necessitate the separate replication network at this point. Can you also comment more on what scenario would necessitate a separate repl network?

    Thanks again!

Leave a Comment

*

We are an Authorized DigiCert™ SSL Partner.