SysCloud.dev

Ever wondered how to move a whole database from one DAG to another without going through mailbox by mailbox migrations? For what reason? (you might ask)

We had to split two remote sites to two separate DAG’s to limit DAG dependability on link between them due to some reliability issues. This has caused us problems in the past and lots of headaches to keep users happy.

The original setup consisted of two multi-role Exchange 2010 servers in a stretched DAG with File Share Witness (FSW) being in Site A. If the link goes down or becomes intermittent then all DB’s would fail over to Site A and Site B will have no or very limited access to their mailboxes (See figure below).

What we needed to achieve is to have both sites working even during link failures, which isn’t possible with one DAG, hence the proposal of two DAG’s. Using the current design above we have managed to split users according to site into their own DB’s and activated those DB’s on their respective sites.

In order to create a second DAG and migrate DB’s across to new DAG, we followed following steps:

1. Make sure all DB’s are in sync (healthy)

2. Ensure all required DB’s for second DAG are activated on the swing server (i.e. in our diagram MBX2).

3. Remove any DB copies that tie that server with MBX1 before attempting to evict it off DAG1.

4.  ENSURE YOU ARE REPLICATING AD CHANGES AT EACH STEP! OTHERWISE YOU WOULD HAVE SPLIT BRAIN ISSUE AND CAUSE YOUR DB TO FAIL. LISTEN TO ME WHEN I SAY I AM TELLING YOU FROM ‘EXPERIENCE‘ 🙂

5. Evict MBX2 from DAG1 ( Under Organization Configuration – Mailbox – Database Availability Group – right click on the DAG you want to evict MBX2 from and click on Manage Database Availability Group Membership).

6. Select MBX2 (in our case) and click on X to remove it.

7. Now, now right click on the DAG that you want to join and follow the same steps above to add MBX2 to the DAG.

8. Setup your DB copies.

This process should be seamless to end users with no interruptions to service, just make sure AD topology is updated at each step to avoid any DB downtime.

I hope this article will help you to save some time and effort in regard to DB re-allocation rather than mailbox-by-mailbox migrations. Of course mailbox-by-mailbox replications has it’s benefits, if you have lots of white space which you want to recover rather than dismounting the DB and running an offline defrag which is time consuming and it requires downtime depending on the size of the database.