Exchange 2010: Implementing a dedicated backup network for a Database Availability Group…

Occasionally, customers that deploy highly available Mailbox servers use a dedicated or secondary network for backup operations. The way in which you do this in Exchange 2010 has changes, and it’s important that when you implement such a configuration that you don’t use the methods or instructions designed for previous versions of Exchange.


In Exchange 2003 and Exchange 2007, we leveraged the Windows Cluster service and used the cluster resource model. To implement a dedicated backup network, you would create a virtual IP address resource in the Exchange resource group corresponding to the network on which you wanted to perform backups. The network associated with the IP address would then be configured as follows:

· Allow cluster network communication on this network and Allow clients to connect through this network enabled (Windows 2008 and Windows 2008 R2)

· All Communications (Windows 2003 and Windows 2003 R2).

On the backup server a hosts file would be used to resolve the name of the Exchange Virtual Server (Exchange 2003) or Clustered Mailbox Server (Exchange 2007) using this dedicated IP address. Because each database was associated with a single server name this would allow the backup server to connect to the Exchange server name on the private network and leverage the backup agent installed on the node hosting those resources.


In Exchange 2010, there have been several changes that no longer allow this type of implementation to function. Exchange 2010 still leverages the Windows Cluster service for some of its high availability functionality, but it no longer uses the cluster resource model. Exchange 2010 includes a form of application level high availability known as the Database Availability Group (DAG). When an administrator creates a DAG they must provide a name and one or more IP addresses. The DAG name and the list of IP addresses are used when forming the DAG’s underlying cluster – these will become the Cluster Name Object (CNO) and the list of IPs will be associated with the cluster network name. All IP addresses assigned to a DAG must be on the MAPI network. This network is automatically configured to allow cluster network communications on this network and allow clients to connect through this network.


Exchange 2010 implements tightly coupled network integration with the Cluster service. This integration manages the settings of all networks found on the DAG members – for example Replication and backup networks. By default, Exchange 2010 sets these networks to allow cluster network communication on this network but does not set allow clients to connect through this network. When the setting allow clients to connect through this network is not enabled, virtual IP addresses cannot be bound to this network.


There is no straightforward way to create a dedicated backup network in Exchange 2010 using the legacy Exchange implementation. There are no application and service groups in which to create the IP address resources, ancillary networks do not support the settings necessary for a virtual IP address, and the integrated Exchange cmdlets do not allow you to assign an IP address to the DAG on a backup network.


Despite these challenges, some administrators have been semi-successful at implementing a variation of the solution (semi-successful as in, it works for a little while, but not for the long term). For example, administrators will find a way to change the network roles to allow virtual IPs to be created and will then update the Cluster core resources with the virtual IPs. This works, but only until Exchange reconfigures the network settings automatically, or until the administrator runs one of the integrated DAG cmdlets which removes the additional IP addresses being created.


So if that is the case how does one implement a dedicated backup networks, and what are some backup vendors doing? Unlike previous versions of Exchange where databases were associated with a server name, Exchange 2010 does not associated databases with a single server name per se. Instead, copies of a database are associated with a server. These database copies can exist across multiple members of the DAG with one member having an “active” database and one or more other members having “passive” databases. In order for backup vendors to determine database locations and status, some make a call to the DAG name to essentially perform a topology discovery. Remember that the DAG name is the name of the cluster, should have valid IP addresses for all subnets on which DAG members exist, and should be dynamically updating in DNS so that the DAG name always resolves correctly. Once this topology discovery is completed the backup server then initiates individual backup sessions to the DAG members themselves (via the DAG member names).


When implementing a dedicated backup network for an Exchange 2010, do not modify the cluster core resources. The backup servers should be allowed to do topology discovery over the MAPI network. This requires that the backup server has an interface that can query DNS, determine the IP address currently resolving to the cluster name, and establish a connection to that address.


Next, modify the hosts file on each backup server. In this configuration, each DAG member has a backup network interface with an IP address locally assigned to that interface. The hosts file entries on the backup server are used to resolve DAG member names.


How does this accomplish the task? Let’s take a look.


Here is an example 3-member DAG. The DAG has two networks, a MAPI network and a Backup network. Each member has an IP address statically assigned to each NIC..




When the backup software attempts to perform a backup operation, it queries DNS and determines that the IP address associated with the DAG is The backup software connects to the DAG and performs a topology discovery.




The backup software determines that a database that needs to be backed up resides on NodeA. Normally the backup software would access the backup agent by querying DNS for the IP address associated with NodeA. If this happens, the backup would occur over the MAPI network and not the Backup network. To prevent this from happening, the administrator edited the hosts file of the backup server and added an entry for with an IP address of The backup server uses this information and establishes a connection to the backup software agent running on NodeA via the Backup network.




In some scenarios, customers want to stop cluster heartbeat and continuous replication from using the Backup network. To do this, you can use the Set-DatababaseAvailabilityGroupNetwork cmdlet with the–IgnoreNetwork:$true and –ReplicationEnabled:$false parameters for the Backup network.


When implemented as described above, this configuration enables most backup applications to operate using a dedicated network without changing DAG settings that might be automatically disabled by the system.




Corrected location of host file entry change.





This weekend I reviewed a configuration that was using Backup Exec to protect their Exchange 2010 deployment.  It was pointed out to me that on the properties of the job, on the network and security selection, there is an option to select which network / subnet could be utilized for backup operations.  Some may find this helpful when configuring their jobs.  I would defer to Symantec on specifics of establishing this configuration.


Comments (18)

  1. TIMMCMIC says:


    Hi!  I suggest you contact Symantec.  This solution has been utilzed in my support cases with both BE and Netbackup.


  2. TIMMCMIC says:


    I still think you need to speak with your vendor.  Based on my experience with netbackup (which is not depth by any means – just assisting other people with these steps) I do not think what you are proposing will be possible.  


  3. TIMMCMIC says:

    @Nathan Scott:

    When doing multiple backup networks that are not spanned between DAG nodes you'd essentially do the same thing.  The issue you will run into is how do you backup between data cetners if that becomes necessary.

    I had one experience where what we did was in site A we put host file entries in for only the local backup network.  If for some reason the backup server in site A had to backup a database on a server in site B, it happened over the public network.  The reverse was done for the backup server in site B.  If the backup servers in each site will only be set to backup copies on local servers then this type of modifications should not be requires.

    From a DAG perspective each backup network will be enumerated as an individual DAG network.  You'd leave each of these DAG networks alone (ie do not try to collapse them into one etc) and then set the replication disabled / ignore flags as outlined in this article.


  4. Neothwin says:

    Thanks and appreciate your quick respond.

    We are using netbackup in our env. Adding mapi interface on backup server or routing to mapi network is not possible.

    I'm thinking to use static NAT between DAG mapi IP to backup network IP. (e.g. <=> So when backup server start topology discovery, it will use Will this approach work?

    Then again, we have another challenge if the DAG mapi network is across two network, DAG name have two different mapi IPs and only one will be up at a time. 🙂


  5. TIMMCMIC says:


    I have no personal experience with how that product operates so I cannot confirm.


  6. TIMMCMIC says:


    I apologize – somehow I missed your comment.

    All networks found on all DAG nodes will be enumerated as DAG networks.  Backup networks should be treated like iscsi networks and have the replication enabled flag set to FALSE and ignore network flag set to TRUE.

  7. TIMMCMIC says:


    There should not be any problems.


  8. TIMMCMIC says:


    No – that's the purpose of this blog.  The DAG is only designed to have IP addresses on the public / mapi network.


  9. TIMMCMIC says:


    You would have to consult with your backup vendor for this particular installation.  You will not though be able to add an additional IP address for the DAG on the dedicated network.  This may require that you establish access to the DAG on the MAPI network.


  10. TIMMCMIC says:


    Backup Exec is going to have to utilize some different instructions than what I put in this article since they have the built in network configuration within the backup job.


  11. Neothwin says:

    Is it possible to create new virtual IP for Backup network in DAG?

    Is it supported?


  12. turbomcp says:

    Great article

    Quick question regrading this

    If i have 3 networks but only two are used for Exchange(prod and repl)does the third actual network(lets say backup)

    need to be visible in DAG networks or should i remove all other networks when consolidating the DAG networks?


  13. Max says:

    Hi, this solution is not working for backupexec.

  14. Nathan Scott says:

    This looks very simple. in real world we have two networks MAPI / Replication / Backup. nodes are across two sites with different subnets.

    is their a detailed elaborated scenrio which explains how to deploy Backup Networks in this deployment.


  15. Zbynek says:

    Hi, check this one. I had the problem to use dedicated network in solution with 2 datacenters and Backupo Exec, but was able to solve it.…/789713f0-40dd-4041-a3c8-83619b562980

    Regards Zbynek

  16. Goldy says:

    Can we use the backup network interfaces for DAG replication ? Is this recommended or would there be issues ?

  17. Ronny_BUR says:

    is HP Data protector 6.20 included in the scope of this article???

  18. Neothwin says:

    Thanks for the great article.

    In our env, the backup server only have backup network, no access to mapi network at all. In this situation, how could we backup DAG?


Skip to main content