Creating DAG Copies of Existing Databases - A Methodology RRS feed

  • General discussion

  • After having worked with creating DAG copies of existing databases and having the "normal" methodology fail every time, I wrote up this "how to" based on my experience. I am offering it as a help to those many Admins who have posted time and again about the failure of getting the process to work. At any rate, where are my observations:

    Process for Adding a Database Copy (DAG) of an Existing Database


    We have had a lot of problems adding database copies of databases that are populated with mailboxes. It appears from my experience that the issue is a corrupt database search index, which consists of many files in a folder directly under the main database folder called CatalogData followed by a sting of alpha-numeric characters. The procedure below has worked every time to successfully get a working database copy in the DAG.

    Note: Never believe what shows in the Database Copies window unless you first click the Refresh button.

    1. In Organization Configuration, Mailbox, right-click the Database that you want to add a copy of and choose Add Mailbox Database Copy. The wizard starts and you need to choose the server that you want the copy on, my experience shows that the process will fail and that the copy will show Suspended or Failed and Suspended as the state.
    2. Next, stop the Microsoft Exchange Search Indexer on the destination server only.
    3. On the destination servers, find the directory where the Database you are working on is housed and delete the folder starting with “Catalog.”
    4. Next, restart the Microsoft Exchange Search Indexer service.
    5. Finally, right-click the database copy in the Suspended state and select Update Database Copy. Take the defaults in the wizard and let it work. It is a time consuming process and will take several minutes to hours, depending on database size. The Copy Status will show Seeding while the wizard is running.

    Sometimes you get to do the process over and over until magic happens and it finally succeeds.

    If the source server has a corrupt index (Catalog files), it may be necessary to stop the Indexing service on both servers, delete the Catalog directory files on both servers, restart the indexing service on both servers, then try Updating the copy. There is a fair likelihood that the first time won’t work and may require the “normal” procedure above. In one case, the best way was to delete both catalogs, allow the primary to rebuild completely, then stop the Indexing service on both, but delete the DAG copy of the Catalog and restart the Indexing service on both servers and rerun the Update wizard.


    Thursday, April 26, 2012 1:24 PM

All replies

  • That's one way to do it, and I admit it's a way that works.  If your databases are large, however, you'll end up with a lot of crawling afterward.

    Something to try first is simply stop and start the Microsoft Exchange Search Indexer service.  It's amazing how often that will clear up a failed index.

    Another option if you have a healthy copy of an index on another member of the DAG is to run Update-MailboxDatabaseCopy with the -CatalogOnly switch.

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Friday, April 27, 2012 6:14 AM
  • Whilst the blog article is not relevant to this thread. The -CatalogOnly switch that Ed mentions is valid and is what I used to fix a corrupt catalog issue. It should help you as Ed states

    My blog: http://www.exchange2007.com/2012/04/cannot-activate-database-copy-because.html

    Oliver Moazzezi | Exchange MVP, MCSA:M, MCITP:Exchange 2010, BA (Hons) Anim | http://www.exchange2010.com | http://www.cobweb.com | http://twitter.com/OliverMoazzezi

    Friday, April 27, 2012 10:13 AM