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.
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.
- 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
- 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.
The “Register this connection’s address in DNS” checkbox has been inadvertently left ticked.
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.
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.
[adrotate banner=”49″]
Hi all,
I just ran into this problem and the issue was that the Replication network did indeed have the register in DNS enabled. After solving that problem , I found you could also re-run the Set-DatabaseAvailabilityGroup E15DAG -DiscoverNetworks and that also resulted in Exchange correcting the setup.
Hi Mark,
I have exchange 2013 server with 12 Nodes , 8 in DC and 4 in DR
When I run the command get-databaseavailibilitygroupnetwork I dont get any response and I have to press ctrl+c to get the cursor back. Even in EAC the cursor keeps on saying please wait on the databaseavailibitlygroup page and I cant see the network config of DAG. I have some subnet/routing issues on 2 of my DR Nodes which I want to correct but I am not sure what to do when I am unable to run the get-databaseavailibilitygroupnetwork command
pls help
Hi Paul,
We have exch-mbx1,exch-mbx2 (exchange server 2016) servers. exch-mbx1 has MAPI,replication interfaces and exch-mbx2 has MAPI,replication,Public interfaces. We use that Public interface to connect OWA and OutlookAnywhere from internet.
When we run test-replicationhealth, clusternetwork is failed and error message is Subnet on network “MapiDagNetwork” is not up. Current state is misconfigured.
Please, help me to solve that problem 🙂
Having a separate “public” network for client connectivity is not going to work. Clients connect to the MAPI network, and only one network can be client-facing.
Hi Paul, in the past I have successfully set up several DAG (2010 and 2013) with networks in AUTO mode and MANUAL, but right now I have a very strange problem…
If I set the settings in AUTO mode, create the DAG sucessfull without errors, but the MAPI network and ISCI leave them enabled replication; that’s not good, you know. I canĂ˝ disable replication because it is AUTO mode.
Then if I switch to MANUAL mode, I can configure manually my 3 interfaces correctly and all good. But when you restart the Exchange 2013 Mailbox servers Exchange change my settings again and leaves interfaces and ICSI MAPI-enabled replication.
I confirm you that I have reviewed 5 times each interface and each one is configured correctly according to the requirements of Microsfot and of ExchangeServerPro web site. I dont´have configuration interfaces failure. By the way, my networks ISCI and REPLICATION are private networks and isolated VLAN.
You think it’s a new BUG/ISSUE of Exchange 2013 ??? My servers has SP3 with CU13.
I hope you help me please , regards!
Hi Paul, I have a situation where I have 2x EX2013 servers in a London datacentre in a DAG, plus I have 2 further EX2013 servers in another Datacentre in Germany across the WAN.
If I add a copy of one of the London databases to any of the German Exchange servers, the network utilisation goes through the roof ( maxed out).
I guess a replication network would not ease this issue,or would it?
Would using Policy-based QOS via group policy to throttle the outbound throttle rate help in this instance, or would I see backpressure events due to delaying the replication?
Hi Mr Paul ,
i have two datacenter, where 1 – HQ, 1 – DR.
in HQ site, we have 2 mailbox, and in DR site, only 1.
We already create 1 DAG for this 3 server.
We already set the preference where, 1 and 2 parameters was set to HQ server and
3 set to DR server. Issues is, we will have intermittent network between two datacenter.
That network is not under our control and when have something issues with that network,
our database will split, some will go to DR server .But we dont want that happen. As we decide for DR server will be passive and only will be up if both server at HQ totally down. (etc Because disaster) .
We configured for failover cluster automatically move. But have any idea, where we can prevent it happen ? our quorom /share witness server in HQ.
i hope have any solution so we can prevent it move to DR automatically. We also have set timeout 60 min.. But still happen.
You can block database copies, or an entire server, from automatic activation. Look into activation policies for mailbox servers.
Paul, i need to change just the subnet mask of the DAG Replication Network. i cannot do this in EMC i need to go from /24 to a /26 Subnet mask. I cannot add it and i cannot change the /24 to /26 because it gives me “Subnets parameter must be distinct and not overlap”. I’ve already changed the Subnet mask of the Network Adapters which reflect properly to match the nic settings 255.255.255.192. Thanks for your advice!
Dear Paul,
Your valuable innformations have helped me lot so may times.
I have a 3 member DAG with exchange 2013,two servers in PR and one in DR,i have found that the PR to DR replication is fine,while DR to PR replication is not working,after reading this article of yours,i have found in my DR server there is only one netwrok adapter,
My question is if diiferent sites require mutliple adapter then how come my PR to DR replication is working fine?
Please correct me ,my DR to PR replication is still failing i need to correct it ASAP
Thanks Paul.
Removing “Register DNS Connection” did the trick for me. However it didnt reassess the DAG network and still showed misconfigured.
I forced to -ManualNetworkConfig to True and the DAG was configured properly automatically.
Yes, the article explains that setting manual network config to $true then back to $false allows the automatic config to try again.
Hi
DAG with 2 Exch 2013 and 1 FWS
i have 3 NIC’s (10.213.0.1, 192.168.0.1 and 10.10.10.1 for DAG replication)
i’m gestting error Misconfigured on Mapi DagNetwork,
removing subnet 10.213.0.1 from DAG Network details does not work (subnet does not be removed).
how can i tell DAG not do use 10.213.0.1 for DAG?
Hi Paul,
I’m hoping you can shed some light on my issue.
I’ve an IP less DAG setup between 2 AD sites. It works fine, however I noticed that my main site has auto-negotiated it’s connection at 100 mbps. It’s a Gig Nic connected to a Gig switchport (set for AutoNeg). The second site is currently on a 100 Mbps ethernet switchport.
Would the 2013 Automatic network configuration component be responsible for autonegotiating to a speed to match the remote site server?
It’s affecting my backup performance & I need it to be 1000Mbps.
Thanks in advance.
Seems unlikely to me.
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!
Pingback: Installing an Exchange Server 2013 Database Availability Group | Hisham Mezher
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.
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.
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.
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.
Pingback: Exchange Server 2013 Database Availability Groups
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!
Interesting, thanks for sharing.
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.
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.
Ok. So the DNS registration is just one of several possible configuration issues that can trip up network auto-config.
Try this article for Exchange 2010 DAG networks and scroll down to the tables for the MAPI and replication NIC configs to see whether any of your other settings are not the recommended ones.
http://technet.microsoft.com/en-us/library/dd638104.aspx#NR
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.
Are you fixing the underlying network configuration issues that are causing auto-config to go astray?
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.
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).