Adding a member server to the DAG is an easy and worthy process, as it could provide protection against server failures and for remote sites it could save on bandwidth in regard to RPC (Outlook client) traffic to mail server.
In our situation, we have a stretched cluster which extends the DAG over a microwave link. copying a database over that link could take days, or weeks especially if we are talking about several databases with over 300 GB in size. This article will take you over offline seeding, this process proved successful in our case and very effective, but in order to get a successful result each of the steps outlined below have to be covered in that order.
Steps to offline seed Exchange 2010 DB
1. Before you even start, you should stop backing up the databases. Backups could truncate your logs files and cause the database to fail at the other end if any of the logs are missing.
2. Using DISKSHADOW.EXE tool, this tool is part of Windows 2008/2008 R2. With this tool we will be able to create a read only copy of the database volume before copying it to an external or network media.
3. At the command prompt, type DISKSHADOW.EXE
4. You can query available disk shadows by running: list shadows all
5. Set the snapshot as crash consistent type : Set Context Persistent
6. Add your volume ready for a snapshot (in our case the K drive): add volume K: alias kdrive
8. To create the VSS snapshot type: create
9. To expose the snapshot as a read only, type: expose %kdrive% Z:
10. Now at that point you should be able to see a Z drive available, it will give you a read only access which allows you to copy the content to a USB drive or directly to the target if the bandwidth permits. In our case we shipped it on a USB drive to our other remote site where we loaded it onto a temp drive on the target Exchange server. After copying the database, you can remove the volume and snapshot by running the following command using the Diskshadow.exe utility:
unexpose Z:
delete shadows volume K:
11. At this point we can create another database copy by running this Exchange PS command: (Make sure to use the -seedingpostponed key)
Add-MailboxDatabaseCopy -Identity DatabaseName -MailboxServer TargetExchangeServerName –SeedingPostponed
12. Place the database .db file in its corresponding directory
13. Then run PS: Resume-MailboxDatabaseCopy “DatabaseName\TargetExchangeServerName“
Now Exchange would validate the database and copy the required and missing log files form the source Exchange server.
SysCloud.dev 
#1 by John Smith on 2 August, 2013 - 2:24 am
Excellent article. Saved me today. One question I have if you don’t mind. We had to disable indexing on the database that we are trying to seed to another server. Will I run in to any issues when trying to add mailbox database copy because content indexing would be in failed state ? Can I bypass that ? Thanks in advance.
#2 by Sami on 4 August, 2013 - 3:00 pm
Hi John
Thanks for your comments, a failed index can be easily fixed.
After successfully seeding your databases you can run the following command to update your index.
Update-MailboxDatabaseCopy -CatalogOnly
#3 by Mikey on 13 July, 2015 - 11:40 am
Hi.
How about the exchange log files? Do they also need to get copied over using diskshadow method?
I tried above method by copying .edb file ONLY + stopping the backups, and it failed. Event log indicated that it was looking for a missing log.
#4 by Sami on 13 July, 2015 - 12:17 pm
Hi Mikey
This depends on the nature of your problem. if originally the DB had a healthy copy on another node before the failure then you could run ESEUTIL /mh on the .edb file and find what log files are needed to mount the DB. I have followed this process on various occasions without any issues as long as you have the required logs available. If you are missing a log file then copy it manually, you don’t need to copy the whole log volume.
Let me know if you require any assistance or further information.
#5 by Alan on 4 August, 2017 - 7:04 pm
does the circular log been turned off on the database?
#6 by Sam on 4 August, 2017 - 11:35 pm
Hi Alan, you are right. Circular logging should be turned off.
#7 by Alan on 5 August, 2017 - 10:55 pm
My situation is this. The source db has circular log turned off. I now did all the step in article. when I ran Resume-MailboxDatabaseCopy “DatabaseName\TargetExchangeServerName”, in EMC it show failed in status. did I miss something? Do I need stop Backup on the database to do it? I copied only the DB file to remote site and this takes a long time, about 12 hours. Does the resume-mailboxdatabasecopy automatically request and copy move the missing logs? I feel that I missed something here.
#8 by Sam on 6 August, 2017 - 12:36 pm
Very important thing you need to keep in mind before you take that vss snapshot, neither circular logging or backup should be running. These two processes or any other that could effect the consistency of the db and truncate those logs or overwrite them could potentially cause the seeding copy to fail – so please stop them both before you take that vss snapshot and try again.
Note – dont turn them back on until your secondary db has seeded successfully.
#9 by Alan on 10 August, 2017 - 6:42 pm
I did exactly as descripted. I trun off Circular logging and backup. It took 3 days to copy the database.
Run Add-MailboxDatabaseCopy -Identity DatabaseName -MailboxServer TargetExchangeServerName –SeedingPostponed
Place the database .db file in its corresponding directory
Then run PS: Resume-MailboxDatabaseCopy “DatabaseName\TargetExchangeServerName“
The EMC database status shows “failed”
#10 by Sam on 12 August, 2017 - 11:22 am
How big is your db? how much logs do you accumulate over the course of copying the VSS copy to your remote destination? is your primary db healthy? Parse the event logs for Exchange errors to check why the db is failing, this would give you a good indication if it’s a db or logs issue.
#11 by Alan on 12 August, 2017 - 4:18 pm
DB is about 300GB. Logs is about 40GB. I saw ehe resyndatabase number keeps going up. How to check if primary db is health? The event logs say there is a log missing… Should I manually copy the log over to the member server? But if it can’t find the log on primary server, then most likely it is not there.
#12 by Sam on 16 August, 2017 - 7:55 am
I think the first thing you need to do is make sure your antivirus isn’t deleting or quarantining those log files by turning it off. Look for those files manually and see if you could find them, if you do copy them over manually. You are generating a lot of logs in comparison to db size in such a short period.