Recipe11.12.Performing Dial-Tone Recovery with Exchange Server 2003

Recipe 11.12. Performing Dial-Tone Recovery with Exchange Server 2003

Problem

You need to perform a lengthy database restoration or maintenance procedure, but you need your users to be able to use their mailboxes and basic messaging capabilities during the process. Short-term outage of stored data is acceptable; downtime is not.

Solution

This solution is longer than most and encompasses a large number of separate steps. Many of these individual steps are covered by other recipes in this book, while others are going to vary depending on your specific configuration and situation. Rather than attempt to repeat every single step here, we're going to break it down into separate tasks and point you to other recipes in the book where appropriate.

Remove the failing database

Launch the Exchange System Manager.
Navigate to the server and storage group that contain the failing mailbox database.
Right-click on the database and select Properties.
Switch to the Database tab and make note of the path and filenames of the database files (c:\path\<filename.edb> and c:\path\<filename.stm>).
Right-click on the database and select Dismount Store. This takes the database offline.
Using the command line or Windows Explorer, move (not copy) these database files to a secure location.
Delete the mailbox store (see Recipe 6.6).

Create the dial-tone database

From the Exchange System Manager, navigate to the server and storage group that contained the failing database.
Create a new mailbox store with the same filenames and path as the failed database (see Recipe 6.4).
Using Exchange Tasks in the ADUC snap-in (see Recipe 5.2) and the Mailbox Recovery Center (see Recipe Recipe 11.10), recreate mailboxes for all users whose mailboxes were on the failing database.
Use ESM to find the location of the transaction logs for the storage group (see Recipe 6.3).
Copy all the storage group transaction logs to a secure location.

Recover the failed database

If a RSG already exists on your server, dismount any mounted databases and remove the RSG.
Following steps 2-4 of Recipe 11.11, create the RSG. Take note of the path where its transaction logs are stored.
Following steps 5-8 of Recipe 11.11, add the failed database to the RSG. Be sure to use a separate path, but use the same filenames for the database files, and ensure that they are on the same volume.
Copy the transaction logs from step 5 of the "Create the dial-tone database" task to the folder that the RSG uses.
Restore the backup of the corrupted database to the RSG following the procedure in Recipe 11.4. Since the logs are already in the appropriate folder, the Information Store service will be able to replay the logs. This will restore the database in the RSG up to the point of failure.
If there are any additional maintenance tasks that need to be run against the previously failed database, run them now against the database in the RSG.

Perform the recovery

Dismount the recovered database in the RSG.
Dismount the dial-tone database in the live storage group.
Move the database files (both .edb and .stm) for the recovered database in the RSG to a separate temporary location on the same volume.
Move the database files (both .edb and .stm) for the dial-tone database into the RSG location.
Move the database files (both .edb and .stm) for the recovered dataset in the temporary location to the live storage group.
Your recovered database should now be in the live location and the dial-tone database should now be in the RSG.
Mount both databases and confirm that your users have their original mailboxes back. They will not contain any items created during the dial-tone recovery period.
Move the items from the mailboxes in the dial-tone database back to the live database by running the two-step procedure offered by ExMerge and selecting step 2: Import data into an Exchange Server Mailbox and following the steps presented.

Discussion

This recipe is really a culmination of all of the rest of this book, and relies quite heavily on several new Exchange Server 2003 features (such as the Mailbox Recovery Center, RSGs, and more). There are several tricky points to consider:

You need to use the same disk volume for creating the dial-tone database as the original database was on. By doing so, you drastically reduce the amount of time that it takes to perform the final recovery process, as you don't have to copy large database files but can simply move them on the same volume. This means that keeping adequate free disk space on your live mailbox volumes is critical. If you don't have it, you can copy the files from other volumes, but doing so will definitely slow your recovery.
You have to manually control the naming and placement of several critical files. Be very certain that you do not overwrite existing files unless you know they need to be overwritten. This is why the recipe calls for moving the files being manipulated (with the exception of the transaction logs for the storage group) instead of just deleting them.
By moving the failed database files, you are temporarily disconnecting users from their mailboxes. This is why you need to use the Mailbox Recovery Center, to ensure that their mailbox properties in AD are resynchronized with the proper GUIDs to the correct database and storage group. If you don't do this, users won't be able to reach their old or new mailboxes.