Three Exchange Server disaster recovery tips
Wednesday, October 18, 2006 10:18 AM
There is a way to recover an Exchange server quickly with minimal headaches. Check out these useful tips.
Although a normal restore operation is definitely the preferred method for recovering an information store, sometimes an organization's logistical needs demand using different techniques. For example, in some organizations e-mail is such a critical application that business will come to a grinding halt if users are unable to send and receive messages. The tips listed here can help you recover an Exchange server quickly and with a minimum amount of headaches.
Perform a dial tone recovery
In some situations, it may be better to perform a dial tone
recovery than to use a traditional restore operation. A dial tone recovery is a
little bit more complicated than a normal database restoration, but it has the
benefit of requiring much less downtime. The idea behind this type of recovery
is that you can return the Exchange Server to a functional state before you
actually recover any of the user's data. That way users can begin sending and
receiving messages almost immediately. You are then free to recover the actual
data without being under quite so much pressure.
To see how this technique works, let's pretend that an Exchange Server was completely destroyed during some kind of catastrophe, but that all of the other servers on the network are still functional. For the purposes of this example, we will also assume that you have a good backup of the Exchange Server.
In a situation in which a server has been physically destroyed, the first thing that you will want to do is to use the Active Directory Users And Computers console to delete the server's computer account from the Active Directory. After doing so, you must also delete each user's mailbox. This isn't as difficult a task as it sounds because Windows Server 2003 allows you to select multiple user accounts to perform the operation on.
Now that you have cleansed the Active Directory, you need to bring the replacement server online and install Exchange Server onto it. Initially, you'll want to make sure that Exchange Server is running the same service pack level as the server that was destroyed.
Once you get the new server up and running, go back to the Active Directory Users And Computers console and create mailboxes for all of the users. Again, Windows Server 2003 allows you to select multiple user accounts so that you can create all of the necessary mailboxes simultaneously.
At this point, the new server is online and should be functional. The users should be able to access their new mailboxes, although Outlook may have to be reinitialized. In a situation like this where time is of the essence, it might be better to instruct users to access Exchange Server through OWA rather than through Outlook until you complete the recovery operation.
Recovering old server data
Now it's time to begin recovering the old server's data. The
recovery process is complicated a bit by the fact that users are now sending
and receiving messages. You won't be able to do a simple restore because the
users' mailboxes now contain live data that you don't want to overwrite. There
are also live transaction files that must be taken into account. Since you won't
be able to restore the databases in the usual way, the plan is to restore the
old server's databases to an alternate location and then merge the old and the
new data together. The tool of choice for this operation will be a recovery
storage group.
To create a recovery storage group, open the Exchange System Manager and navigate to Administrative Groups | your administrative group | Servers | your server. Now, right-click on your server and select the New | Recovery Storage Group commands from the resulting shortcut menu. When you do, you will see the Recovery Storage Group Properties sheet.
This properties sheet asks you to enter a location for restored transaction logs and for the system path. You can enter any path that you want, but you must make sure that there is enough free disk space to accommodate the information that you will be restoring. You must also make sure that you choose a location that will not overlap with any of the server's existing databases. In most cases the default path will be fine so long as there is sufficient disk space. Click OK and Exchange will create the new recovery storage group.
If you expand the server's node within the Exchange System Manager, you will see that there is now a Recovery Storage Group container listed beneath the server container. Right-click on the Recovery Storage Group container and select the Add Database to Recover command from the resulting shortcut menu. When you do, the Exchange System Manager will display the Select Database to Recover dialog box. This dialog box contains a notification displaying the current Exchange Server build. It informs you that databases from later versions of Exchange as well as databases from versions of Exchange 2000 prior to Service Pack 3 will not be shown.
If you look at the lower section of this dialog box, you'll see a listing of all of the information stores on the server. Choose the information store that contains the user mailboxes for which you will be restoring data and click OK twice. After a bit of a delay, a new mailbox store will be created beneath the Recovery Storage Group container. It is extremely important that you do not try to Mount the store. Doing so can disrupt the checkpoint files and make the recovery process more difficult.
Restoring mailboxes from the old server
Now it's time to restore the mailboxes from the old server. You
will restore these mailboxes in the normal way, and the restoration will be
automatically redirected to the Recovery Storage Group. One thing to keep in
mind though is that for right now you should only recover mailboxes. Don't try
to recover public folders or log files. You will be able to restore these later
on, but only after the mailbox data is back in place.
When the recovery process completes, it's time to move the user's data into a location that is accessible to them. In order to do so, you will need to let the users know that the Exchange Server will be unavailable for a little while. The reason for this is that the procedure requires you to dismount and swap databases.
Open Windows Explorer and navigate to the location where the recovery storage group is stored. Create a folder named Save_Original. Now, use the Exchange System Manager to dismount the information store database. Next, use Windows Explorer to move the recovery storage group's .EDB and .STM files to the Save_Original folder. At this point, you should go back into the Exchange System Manager and delete the recovery storage group's database. This will delete the logical database structure, but not the database itself. Go back to Windows Explorer and navigate to the directory containing the active information store. Create a folder named SaveDialTone. Copy the .EDB and the .STM files associated with the information store into the SaveDialTone folder.
Go back into the Exchange System Manager and change the path for the information store so that it now points to the recovery storage group's database path. Use Windows Explorer to move the files that are in the Save_Original folder back to the recovery storage group path. Go back into Exchange System Manager and right-click on the information store. Verify that all of the information is correct and then select the Database tab. Select the This Database Can Be Overwritten By A Restore check box and click OK
 It is now OK to mount the information store. After doing so, the user should have access to all of their old messages, but will not have access to any messages that have accumulated since they began using the temporary information store.
Now, go back to Windows Explorer and create a folder named DialTone at the same level as the SaveDialTone folder. Switch back to the Exchange System Manager and right-click on the Recovery Storage Group and select the Add Database to Recover command from the resulting shortcut menu. Select the name of the information store that you are working on and click OK. When you see the properties sheet, enter the path to the DialTone folder and click OK. Go back into Windows Explorer and move the files from the SaveDialTone folder into the DialTone folder. You may now mount the recovery storage group database.
Recovering mailboxes
It's now time to recover the mailboxes. Before doing so, you
must verify that your Exchange Server is running Exchange Server 2003 with
Service Pack 1 or higher. If for some reason your organization has decided not
to use Service Pack 1 for Exchange Server, then the remainder of this procedure
will not work. You will have to use ExMerge is an alternative.
To recover the mailboxes from the Recovery Storage Group, expand the Recovery Storage Group container and then expand the database container. You should now see three sub containers, one of which is named Mailboxes. Right-click on the Mailboxes container and select the Exchange Tasks option from the resulting shortcut menu. When you do, Windows will launch the Exchange Tasks Wizard.
Click Next to bypass the wizard's welcome screen on the following screen, select the Recovered Mailbox Data option and click Next again. Verify the destination mailbox store, and click Once again. You will now be prompted to decide whether you want to merge the restore data into the users mailbox or if you'd prefer to copy the contents of the restored mailbox over top of the user's existing mailbox. Although the merge option sounds like the logical choice, you must use the copy option instead. Choosing the merge option will cause problems since you have swapped databases. Click Next and enter a start time for the recovery process. Click One more time and the mailboxes will be restored. When the process completes click Finish.
If you have ever had to restore an Exchange Server database to a consistent state, you know how challenging the process can be. The recovery process is easier in Exchange Server 2003 than it was in previous versions of Exchange Server, but if you don't know exactly what you are doing then getting a database to mount can still be a frustrating experience.
This is where the Exchange Server Disaster Recovery Analyzer (ExDRA) tool comes in. The ExDRA analyzes the database that you are attempting to mount and gives you a step by step list of instructions for bringing the database into a consistent state so that it can be mounted.
You can download the ExDRA tool for free from the Microsoft Web site. The tool offers an extremely simple installation process. Once Setup is complete, you can access the tool from your computer's All Programs | Microsoft Exchange menu.
When you launch the program, check for and download any available updates. After applying any available updates, you will see the tool's Welcome screen. The Welcome screen basically just tells you that the tool can be used against any server running Exchange 2000 with Service Pack 3 or higher, or against an Exchange 2003 Server.
Click Next and you will be asked if you would like the ExDRA to automatically detect the database location or if you would like to specify it manually. I've always had good luck using the auto detect option, but depending on your server's current state you may have to use the manual input mode once in a while. After choosing the auto detect option, you will be prompted to enter your server's name, a domain controller's name, and a set of authentication credentials. Click Next and the ExDRA tool will validate the credentials that you have entered.
At this point, you will be asked to select the storage group that is having problems. Make your selection and click Next. The ExDRA will now show you which databases are and are not mounted. You must now select the database that you are trying to recover and click the Analyze Selected Database link.
Depending on the database's size and condition the analysis process could take a while. When the process completes, you will see a report that tells you about your database's current condition and what you need to do to fix the problem. The report even contains links to pertinent Microsoft Knowledgebase articles that you can use for extra help.
Recovering data from workstations
The last tip that I want to share with you is a recovery
technique that almost always works, but that should only be used as a last
resort because of the amount of work involved. Outlook 2003 is designed so that
it stores a cached copy of each user's Exchange data in a file named
OUTLOOK.OST. If a mailbox store is lost with no chance of recovery, it is
possible to recover almost all of the user's data by using this cache. You won't
be able to recover messages that have accumulated since the last time that the
user opened Outlook, but you should be able to recover everything else. The
catch is that you have to perform the recovery in just the right way or you
will trigger a hidden self destruct mechanism that invalidates all of the
cached data.
The Outlook cache was designed so that all of a user's Exchange data is cached to the user's profile. The idea behind this is that a user will still have access to their messages, contacts, etc. even if it an Exchange Server is off-line. The good news is that this cache is enabled by default, and therefore any workstation that's running Outlook 2003 should have a cached copy of the user's data.
If you find yourself having to create a new mailbox store, then you obviously have to create new mailboxes for the users as well. Before you link these mailboxes to their corresponding user accounts though, you need to go to each workstation and login as the user whose data you want to recover. When you open Outlook, you should see all of the user's messages, contacts, etc. You must now create a PST file and copy all of the users Exchange data into it. This step is absolutely critical to the recovery process.
After you have created all necessary PST files and have verified that they contain the data that you're trying to recover, you can link the newly created mailboxes to the corresponding user accounts. After doing so, you will have to go back to each workstation and configure the Outlook profile to detect the user's new mailbox. Even if the new mailbox has the same name as the old mailbox, you must still perform this step. Otherwise, Outlook will never actually attached to the Exchange Server.
When you attach Outlook to the new Exchange mailbox, you will find that all of the cached data disappears. The OUTLOOK.OST file contains a security code that links it to the old mailbox. When you attach Outlook to the new mailbox, the security codes will no longer match because the new mailbox has a different security code than the old mailbox did. This security code mismatch means that the cached data is invalidated. Once you have configured to users Outlook profile to point to a different mailbox, there is no getting the cached data back. That's why it's so important for you to copy the cached data to a PST file early in the process.
Assuming that you did create the PST file, and Outlook is now attached to the user's new Exchange mailbox, the server is now functional. The user can send and receive e-mail. The only thing that's left is to recover the user's data. To do so, simply open the PST file that you created earlier, and drag the contents into the appropriate folders.
There are currently no comments for this post.