Seed an Exchange 2010 DAG database locally

If you have an Exchange 2010 DAG deployment it is very likely that you have multiple datacenters for disaster recovery scenarios.  You may find that you need to reseed a DAG database but since bandwidth is at a premium between sites, what can you do?  If you have multiple copies of a database in the same datacenter, the best scenario is to seed an Exchange 2010 DAG database locally.

Consider this situation:  You have  two DAG nodes in you DR site and one of them requires a hardware replacement.  It is possible to create another copy of the database on the other node in the same datacenter using the local database copy as the source.  Using this method you are able to preserve the database copies in the secondary datacenter.  When the hardware is replaced and the DAG node is functional, you can seed the database copies back to the original DAG node.    The following PowerShell commands should be used to seed an Exchange 2010 DAG database locally.  Let’s assume that you have ExSvr1 and ExSvr2 in the secondary datacenter.  Each holds a database copy from servers in the primary datacenter.  You must create a copy of DB01 on ExSrv2 before shutting down ExSvr1.

Create a new database copy on ExSvr2.  Use the database name as the identity and set the mailbox server where this copy will live.  Also set the activation preference and postpone the seeding.

Once the PowerShell command completes you will receive the following warning.
WARNING: Replication is suspended for database copy ‘DB01’ because the database copy needs to be seeded.

The next step is to begin the seed process by using the -SourceServer switch and specifying ExSvr1 which is currently hosting the database copy in the secondary datacenter.


Here is a link to the official Microsoft Exchange 2010 documentation on the Update-MailboxDatabaseCopy which provides an example on how to seed an Exchange 2010 DAG database locally using the -SourceServer switch.

Monitoring the DAG Replication Network

The Exchange 2010 Database Availability Group (DAG) is an important feature that provides high availability.  Therefore, monitoring the DAG replication network is an important part of keeping the high availability in your environment as healthy as possible.  Replication of Exchange 2010 databases in your messaging environment has specific network requirements outlined in this TechNet document.  The best scenario is to use two network adapters per DAG node member.  One adapter supports the MAPI Network which is used by other servers, for example other Exchange 2010 servers or directory servers.  The other adapter is for the DAG replication network which is dedicated for database replication.  With all this said, Exchange 2010 is smart enough to switch replication from the replication network to the MAPI network in the event of a communications problem on the DAG replication network.

Read moreMonitoring the DAG Replication Network

DAG Replication Network

Setting up DAG replication is extremely important as outlined in Tim McMichael’s TechNet post, Exchange 2010: Collapsing DAG Networks.  Even when you correctly disable the MAPI network from log shipping, Exchange 2010 will still resort to log shipping on the MAPI network if there is a communication problem on the replication network.  Once you become aware that there has been a communications problem between DAG nodes on the DAG replication network, the next thing you should do is to check a few things out.


Read moreDAG Replication Network