Manage Learn to apply best practices and optimize your operations.

Single item recovery changes in Exchange Server 2010

With the release of Exchange Server 2010, Microsoft eliminated storage groups. Learn why recovery databases are important, how they've changed since Exchange 2007 and why you'll need them for single item recovery in Exchange 2010.

When Microsoft created Exchange Server 2010, it made major changes to the storage engine's architecture, including eliminating storage groups. While this architectural change may seem irrelevant to the subject of single item recovery, the recovery storage group was the primary mechanism for single item recovery in Exchange Server 2007.

Since neither storage groups nor recovery storage groups exist in Exchange Server 2010, you have to use a recovery database. While the basic principles of single item recovery should not be completely unfamiliar to administrators with Exchange Server 2007 experience, there are some important differences.

Recovering a single item in Exchange Server 2007 involved creating a recovery storage group, then restoring an Exchange database into it. In Exchange Server 2010, you have to restore the backup and then create the recovery database.

But before doing this, you must check the database's properties sheet (Figure 1) and verify that the This Database Can Be Overwritten by a Restore check box is not selected. Otherwise, the restore process could potentially overwrite the production database.

Check that the
Figure 1. Before creating a recovery database, check that the "This Database Can Be Overwritten by a Restore" check box is not selected.

The next step in the recovery process is to restore your database. The restoration process works differently depending on the backup software you're using. In the case of Windows Server Backup, you must instruct the recovery wizard to perform an application-level restore (Figure 2).

Instruct the recovery wizard to perform an application-level restore
Figure 2. You must perform an application-level restoration.

Next, you must choose to restore Exchange Server (Figure 3).

Pick Exchange Server as the application you will restored
Figure 3. Pick Exchange Server as the application you will restored.

Instruct the Recovery Wizard where to restore the backup to. In Exchange Server 2007, if the Database Can Be Overwritten option is not enabled, instruct Windows Server Backup to restore the database to its original location. Then, Exchange Server will automatically redirect the restoration to a recovery storage group. But this works differently in Exchange Server 2010.

Create an empty folder on the server's hard drive -- Windows Server Backup won't create it for you -- then tell Windows Server Backup to restore Exchange Server to this folder (Figure 4).

Recover Exchange to an empty folder on your server's hard drive
Figure 4. You must recover Exchange to an empty folder on your server's hard drive.

More on Exchange 2010:
What's new in Microsoft Outlook 2010?

New OWA features in Exchange Server 2010

Understanding the Legal Hold role in Exchange Server 2010

Once the restoration process completes, the restored database and its transaction logs will be placed into the folder that you specified. Now you can create a recovery database. The trick is telling Exchange Server to use the restored files as the recovery database.

Exchange Server 2010 requires you to create a recovery database using Exchange Management Shell commands. So, open the EMS and enter the following command:

New-MailboxDatabase –Recovery –Name <database name> -Server <mailbox server name> -EdbFilePath "D:\Recovery\Database.edb" –LogFolderPath "D:\Recovery"

Creating a recovery database is similar to creating a mailbox database; both procedures are based on the New-MailboxDatabase command. The difference between the two processes is that you must specify the –Recovery switch to create a recovery database. Otherwise, Exchange will create a regular mailbox database. You also must name the database that you created and specify on which mailbox server to create the database.

The previous command includes an –EdbFilePath that you can use to specify the path to the database. You must provide Exchange Server with the path and filename for the database that you restored from backup. Likewise, the –LogFolderPath must point to the location of the transaction logs within your recovery folder.

Keep in mind that specifying the folder name alone isn't enough. You must provide the full path to the database and transaction log files. For example, I restored a backup to a folder named Recovery. However, the full path to my database is: C:\Recovery\C_\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 1284628427.

Create the recovery database so that it uses the database that you recently restored
Figure 5. You must create the recovery database so that it uses the database that you recently restored.

If you look at Figure 5, you'll see that you received confirmation that the recovery database is using previously existing files. If you don't receive this confirmation, it means that you've entered the command incorrectly. If so, delete the recovery database and try again.

About the author: Brien M. Posey, MCSE, is a five-time recipient of Microsoft's Most Valuable Professional (MVP) award for his work with Exchange Server, Windows Server, Internet Information Services (IIS), and File Systems and Storage. Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at

Do you have comments on this tip? Let us know.

Dig Deeper on Exchange Server setup and troubleshooting

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.