Staging a local copy of Exchange Databases for geographically dispersed Database Availability Groups (DAG) is an alternative to seeding databases over a WAN. Microsoft documents this on Technet as (manually copy an offline database). The steps include dismounting the database and then copying to an external volume. I prefer to leave Exchange up and running, so I am going to use a VSS snapshot of the Exchange databases using diskshadow.exe so that I can copy the databases while they are in an online state. This technique is documented very well on Michael Smith’s blog here and Tim McMichael’s blog here.  The only difference between these two approaches is the VSS snapshot that diskshadow produces is crash consistent (as if the power plug was suddenly removed from the server), whereas dismounting the database produces an application consistent snapshot.

Prior to taking a snapshot sing diskshadow, I had 697 GB of free disk space on the E:\ drive where my Exchange databases resided on server CATINEXC04.


I verified that the Exchange VSS writer is in a stable state.  I also checked to make sure any backup jobs had already completed.


set context persistent 
begin backup
add volume e: alias shadow_e
expose %shadow_e% q:

After the create command, the VSS snapshot used 3GB of data from the E:\ drive. The expose command created a Q: drive that is a mirror of E at the time the snapshot was taken.


I then copied the Q: drive contents (464GB) to my external USB Drive on D:\. This took approximately 4 hours to complete (the USB drive allowed for an average of 36 Megabytes per second transfer rate).

The next step is to sneakernet the drive to the disaster recovery site where the other DAG member resides.


After the drive arrives, plug it into your remote DAG member and copy the contents to the same drive letter and path on the remote server as they existed on the source server. For example, if the active copy database path is D:\DB1\DB1.edb and log file path is D:\DB1, then you would copy the database files to D:\DB1 on the server that will host the copy.

Then run the following command from the Exchange Management Shell:

Add-MailboxDatabaseCopy –Identity “Mailboxes L-P” -MailboxServer Catinexc07 –SeedingPostponed

In the EMC, I noticed that the Copy Status was ‘Failed’ for the new mailbox database copy on my remote server catinexc07.


I was tempted to run the update-mailboxdatabasecopy command to force Exchange to manually seed the new copy but after about 5 minutes the copy status changed to Healthy and the copy queue length began to decrease.


One thing to note: I did not run any backups on the source (original) database until the drive had arrived at the DR site and the add-mailboxdatabasecopy command was run and all of the logs had been copied, because I was concerned that the logs would be truncated by the backup and I assumed this would prevent the seeding from working correctly. I need to do additional testing to confirm if my method of avoiding backups is required.

You can check the status of the copy queue length from the Exchange Management Shell with the Get-MailboxdatabaseCopyStatus cmdlet.


When the CopyQueue length is back to zero, I then reclaimed the 3GB of drive space lost to the VSS Snapshot by running these two commands on the source server.

end backup
delete shadows exposed q:

The ‘end backup’ command will flush the Exchange transaction logs. The ‘delete shadows exposed q:’ command will erase the snapshot backup so you can recover the drive space used for the snapshot.

That’s it! This is very helpful when you have extremely large Exchange databases and/or a congested or small WAN connection.