Backing Up and Restoring Microsoft Exchange Server 2007, Part 2

Executive Summary:

The key to any backup and recovery situation is knowing what to do by planning ahead. As I showed in "Backing Up and Restoring Microsoft Exchange Server 2007, Part 1" (http://www.windowsitpro.com/Articles/ArticleID/97383/97383.html), you can use NTBackup to create a full backup of your Exchange organization, and you can use simple Windows PowerShell commands through Exchange Management Shell to restore a mailbox database and individual mailboxes or mail items if the deleted items retention period hasn't expired. Having covered the simplest methods of recovery in the previous article, I'll now show you how to recover a single mailbox or mail item when the retention period has expired, and then move on to the problem of getting users reconnected after a server failure.

Using the Recovery Storage Group
When you need to restore a single mailbox or mail item after the retention period has expired, you'll have to restore from backup to a special storage group called a Recovery Storage Group (RSG). Each Exchange Mailbox server can contain one RSG, which you can use to recover data without affecting the existing live mailboxes. To use an RSG, you must associate a database with it so that the restore path is targeted automatically at the RSG. When you recover data from a database mounted in an RSG, you have two options:

The merge option is used most often with a dial-tone recovery. In this scenario, mail flow is brought online rapidly after a failure but historical mail isn't available. After the restore is complete, the historical mail is merged with the new data. If you're restoring a single area of the mailbox, it's easier to use the copy option to restore data into a distinct folder; the user can then reorganize items into his or her existing folder structure.

You can create and manage RSGs in Exchange 2007's Exchange Management Console; however, the interface doesn’t let you set the location for a new RSG. The default location is the location of the database you link to the RSG. This can be a problem if you've set aside specific disk space for restores. Therefore, I'll discuss using Exchange Management Shell commands to create and configure an RSG.

To create a new RSG, use the following command:

New-StorageGroup -Server e2k7cas-ht ` -LogFolderPath c:rsg1rsglogs ` -Name RSG1 -SystemFolderPath ` c:rsg1rsgdata -Recovery

Note that the backtick (`) at the end of a line indicates that the command continues on the next line; in Exchange Management Shell, you could enter the command all on one line without the backticks. In this command and those that follow, replace e2k7cas-ht with your server name. The -Recovery parameter is what defines the new storage group as an RSG.

Next, use the following command to create the database you'll restore to in the RSG:

New-MailboxDatabase ` -MailboxDatabaseToRecover ` "e2k7cas-htfirst storage group" ` + "Mailbox Database" ` -StorageGroup e2k7cas-htrsg1 ` -EdbFilePath ` c:rsg1rsgdatadatabase.edb

The -MailboxDatabaseToRecover parameter is used to set which live database you want to link to the RSG database for recovery. The -EdbFilePath parameter sets the location for the new database; use the same location as you did for -SystemFolderPath when creating the RSG. Note the use of the plus sign (+) on the fourth line; when a string continues to a new line, you need to treat the parts as separate strings and use PowerShell's concatenation operator (+) to join them.

Finally, use the following command to allow the new database to be overwritten by a restore:

Set-MailboxDatabase -Identity ` "e2k7cas-htrsg1Mailbox Database" `-AllowFileRestore:$true

Having created the RSG and database, you're now ready to restore from backup, which you can do using NTBackup as described in "Backing Up and Restoring Microsoft Exchange Server 2007, Part 1" (http://www.windowsitpro.com/Articles/ArticleID/97383/97383.html). When you perform the restore, the database is automatically restored into the location you specified when creating the RSG.

After you've completed the restore, mount the database in the RSG by using the command

Mount-Database -Identity `"e2k7cas-htrsg1Mailbox Database"

Recovering a Mailbox or Mail Item with an RSG
At this point, to restore an individual mailbox or mail item, you can either switch to Exchange Management Console or proceed with the PowerShell commands. Let's take a look at both methods. To restore a user mailbox with an RSG through the console, you must select Toolbox in the navigation tree in the left pane, then open the Database Recovery Management tool, as Figure 1 shows. Because the tool is typically configured to automatically check for updates, you might need to click through updates to get to the Enter Server and User Information screen, which Figure 2 shows. On this screen, enter the Exchange server name and a domain controller you'll work on. Then click Next to move to the tasks screen.

When you're at the tasks screen, select Merge or copy mailbox contents from the Manage Recovery Storage Group section, as Figure 3 shows. On the next screen, which Figure 4 shows, you'll see a list of databases mounted in the RSG; select the database you want to restore from. Click Gather merge information to move to the next screen, then select the mailbox matching criteria by which you'll link the mailbox to be restored with the mailbox it will restore to. As Figure 5 shows, you need to click Show Advanced Options to make changes. In this case, I left the default of Mailbox GUID for both Match and Sort options. You can use the Advanced Options section to restore specific items according to your filter options, and to determine whether restored items are merged into the existing mailbox hierarchy or simply copied into a newly created folder. Click Perform pre-merge tasks, then select the mailbox you want to restore, as Figure 6 shows. Finally, click Perform merge actions for the merge to take place.

If you prefer to use PowerShell commands to work with RSGs, you can use the following command to perform a mailbox merge:

Restore-Mailbox ` -Identity "Nathan" -RSGDatabase ` "RSG1Mailbox Database" ` -TargetFolder "NW Restore" ` -RSGMailbox "Nathan" ` -SubjectKeywords "testsecure" ` -IncludeFolders Inbox

Note that you'd replace Nathan with the alias of the mailbox you're restoring. The command uses the -TargetFolder parameter to route the restore into a folder called NW Restore, thus creating a copy. Using the copy method lets you compare existing mailbox items to those restored, and it also keeps the restore in a self-contained area. I have also used the -SubjectKeywords and -IncludeFolders parameters to show how to narrow your restore criteria; in this case, we're looking only for items in the Inbox with testsecure in the subject line.

Cleanup
After performing a recovery that uses an RSG, it's good practice to remove the RSG from your Exchange environment to simplify future restores. Your first step is to dismount the database in the RSG by using the following command:

Dismount-Database `"e2k7cas-ht RGS1Mailbox Database"

Next, you'll use the following command to remove the database from the RSG:

Remove-MailboxDatabase `"e2k7cas-htrsg1Mailbox Database"

Then, use the following command to remove the RSG:

Remove-StorageGroup "e2k7cas-htrsg1"

Finally, locate and delete the folder where the RSG was created.

You can also perform this cleanup in the GUI using the Mount or dismount databases in the recovery storage group and the Remove the recovery storage group tasks that Figure 3 shows. You would, however, still need to delete the folder manually.

Using a Dial-Tone Database for Server Recovery
I'll now show you how to solve some more complicated problems. For instance, what if you need to get users up and running quickly after a problem, but can afford to get their data back more gradually? You could use the dial-tone restore method, which provides a quick return of email service to users without giving them immediate access to their previous data.

You can perform a dial-tone restore using one or more servers. Depending on the type of problem, you'll have different options for solving it; for example, if only a single database is broken, you could create a dial-tone database on the same server. However, let's look at something more challenging: One of your Mailbox servers has had a major disk failure and no longer boots. To get mail flow restored ASAP, you can create a dial-tone database on another Mailbox server to return email service to users. Then, you can restore or rebuild the original Exchange server and switch users back to it with all new and old mail available. Note that this procedure assumes that a suitable backup of mailbox data is available for the failed server.

You'll start this process by creating a dial-tone database. Open Exchange Management Shell on a different Mailbox server and create a new storage group to hold the dial-tone database by using the command

New-StorageGroup -Server e2k7mb2 ` -LogFolderPath c:sg1sg1logs ` -Name SG1 ` -SystemFolderPath c:sg1sg1data

Next, use the following command to create the dial-tone database:

New-MailboxDatabase -Name DialTone1 ` -StorageGroup e2k7mb2sg1 ` -EdbFilePath c:sg1sg1datadatabase.edb

Finally, mount the database by running the command

Mount-Database "e2k7mb2sg1DialTone1"

With the dial-tone database up and running, you can get users working again by using the command

Get-Mailbox -Database ` "e2k7mb1first storage group" ` + "Mailbox Database" ` | Move-Mailbox -ConfigurationOnly ` -TargetDatabase ` "e2k7mb2sg1DialTone1"

This command takes advantage of a great new Exchange 2007 feature called dial tone portability: You can change a user’s Mailbox server without moving the mailbox data. The -ConfigurationOnly parameter is what makes this feature possible. After you run this command, you can let your users know they can log back on to Outlook. However, any users who are still logged on (i.e., they haven't closed Outlook since the server failure) won't immediately get connected to the new server. They'll need to close and relaunch Outlook so that Autodiscover can connect the mailbox to the new server.

When I used this restore method, my users were in cached mode and didn't receive any updates. I manually turned off cached mode and restarted Outlook, at which point I received a dialog box, as shown in Figure 7, that gave me the choice of using the temporary mailbox or working offline with the original mailbox. When a user clicks the Use Temporary Mailbox button, they'll be able to send and receive email and continue to work as usual, but won't have access to their old data. If you use the command to move mailboxes when users aren't in cached mode, they'll be prompted to restart Outlook, which will then automatically use the new dial-tone database.

Now that users are up and running again, we can turn our attention to getting the failed server back up and restoring the users’ data. First, repair the hardware fault and install a new copy of Windows. Make sure you name the server the same as it was before. Next, install the prerequisites for Exchange 2007, which you can find out about in the Microsoft article "Exchange 2007 System Requirements" (http://www.microsoft.com/technet/prodtechnol/exchange/2007/evaluate/sysreqs.mspx). Also, be sure to check out the Learning Path at the top right of this page for additional articles about preparing for and implementing Exchange 2007.

The next step is to run Exchange setup in Disaster Recovery mode. Enter the following command at a standard command prompt:

Setup.com /m:recoverserver

It should be noted that the above command is not an EMS command and should be run from a standard command prompt, having first navigated to the Exchange installation media.

In this install mode, Exchange installs only the necessary files to get Exchange running, and then it pulls the server configuration from Active Directory (AD) so that you effectively get back the same server you started with. Now all you have left to do is restore the mailbox data.

On the repaired server (which, in my example, is E2K7MB1), open Exchange Management Console and ensure that the database you need to restore exists; as Figure 8 shows, it should be dismounted.

Next, use the following command in Exchange Management Shell to ensure the database allows restores:

Set-MailboxDatabase -Identity ` "e2k7mb1first storage group" ` + "Mailbox Database" ` -AllowFileRestore:$true

Now you're ready to follow the restore procedure for a database, which I presented in "Backing Up and Restoring Microsoft Exchange Server 2007, Part 1" (http://www.windowsitpro.com/Articles/ArticleID/97383/97383.html). If you still have access to the database transaction logs from the failed server, you can restore even more fully by copying them to the transaction log path of the storage group where the database is being restored. They'll then be replayed as part of the restore.

After you've restored the database, it's time to get your users back to their data by migrating them using the -ConfigurationOnly parameter as before:

Get-Mailbox ` -Database "e2k7mb2sg1DialTone1" ` | Move-Mailbox ` -ConfigurationOnly -TargetDatabase ` "e2k7mb1first storage group" ` + "Mailbox Database"

Users now have their old data available but no longer have the most recent data, which is still only in the dial-tone database. This data must now be merged with the old data to complete the restore. To perform the merge, you'll create an RSG on the repaired server, then create a database in the RSG and set it to allow restores; to do so, you'll use essentially the same commands you used to create the first RSG. After you've completed those steps, dismount the dial-tone database from the temporary Mailbox server and copy the .edb file to the location specified for the new database (which, in my example, is c:rsg1rsgdata). Then mount the database using this command:

Mount-Database -Identity `"e2k7mb1rsg1Mailbox Database"

With the database mounted, you can now merge the data using the Database Recovery Management tool. When the merge completes, you'll see both the old and new email in the mailbox, as Figure 9 shows.

Restoring Other Server Roles
You've probably realized that we've only examined the recovery of an Exchange Mailbox server role. You can recover all the server roles with the same basic method, except for the Edge Transport role. The Edge Transport role is different because it's not a domain member and therefore doesn't have its configuration information stored in AD. To backup and restore an Edge Transport server, you need to use Exchange Management Shell commands to clone the configuration. For information on this procedure, see the Microsoft article "Using Cloned Configuration Tasks for Edge Transport Server Disaster Recovery" (http://technet.microsoft.com/en-us/library/bb125150.aspx).

The general recovery steps for other server roles are as follows:

In addition to rebuilding the server as shown in the walk through for the Mailbox server role, the Hub Transport and Client Access roles require some additional steps for full recovery.

Hub Transport Role. The main purpose of the Hub Transport role is facilitating message flow. The Hub Transport role uses a message queue database to process and route mail. Message queues aren't backed up because mail is rarely there long enough. However, if queues can be recovered from a failed server, they can be mounted on another Hub Transport server and any messages in the queue can be retrieved. Detailed instructions can be found in the Microsoft article "Working with the Queue Database on Transport Servers" (http://technet.microsoft.com/en-us/library/b6904662-d1f1-4ad5-bbc1-5a7791aa2d75.aspx).

You might also need to restore message tracking logs and protocol logs. If these logs are important, they should be backed up as part of daily server maintenance. By default, they're found at C:Program FilesMicrosoftExchange ServerTransportRolesLogs. Finally, having a copy of the system state is also a good idea.

Client Access Role. The Client Access role runs various services, including providing all remote access (e.g., OWA). Although it requires more files for a full restore than the Hub Transport role, backing up the Client Access directory, found at C:Program FilesMicrosoftExchange ServerClientAccess, should cover you for the vast majority of scenarios. Details about individual files contained within the Client Access directory and its subdirectories can be found in the Microsoft article "Client Access Server Data" (http://technet.microsoft.com/en-us/library/aa998364.aspx).

Finally, one of the most important things to restore on the Client Access server role is the Microsoft IIS metabase, which is the configuration store for IIS. You can use a PowerShell script with Exchange 2007 to back up and restore the metabase; details of the process, including the code to create the script, can be found in the Microsoft article "How to Back Up and Recover a Client Access Server" (http://technet.microsoft.com/en-us/library/bb124359.aspx).

Prepare for Disaster
You should now have a clear idea of how to perform the most common Exchange restore scenarios. You can find more details about these procedures in the Exchange 2007 Help file which, while not always completely accurate, is a good source of information to put into your test scenarios. Finally, make sure you test thoroughly. You don't want to learn about the quirks of recovery for the first time in a real disaster-recovery situation!