Thursday 16 October 2014

Exchange 2013 SP1: Performing a Mailbox Database Restore using Database Portability in Exchange Server 2013

Since Exchange Server 2007 you have been able to perform Mailbox Databases restore using a feature called "Database Portability", this allows you to take an Exchange EDB file, copy it to another Exchange Server in the Organization and mount it. It's a great feature for disaster recovery.
I have written this post after having done it in production for a client running Exchange Server 2010 SP3, it is my notes should I never have to do it again. Hopefully it is also going to help you.
Step One: Repairing the Exchange EDB Database
Whatever has happened to your Exchange Server that has failed you must one way or another get a copy of the Exchange EDB file. This could be from means of extracting it from the failed server or restoring it from backup. When you get the EDB file you must use ESEUTIL to determine the "State" of the database file.
The following command can be used to determine the state of the Exchange EDB file.
ESEUTIL /mh “Database EDB Path”


In my example the state is "Clean Shutdown" this is mainly because I am doing it in my lab to document the process for myself. There is a very high chance that if you have found this blog post you are looking to restore an Exchange Database from a failed Exchange server. If your Exchange Server lost power suddenly or has suffered corruption there is a high chance the Exchange Database state will be "Dirty Shutdown".
If when you use ESEUTIL against your Exchange Database it reports a "Dirty Shutdown" it is because there are transaction logs that have not been committed to the database. From the ESEUTIL output window the fields Log Required and Log Committed will give you an indication exactly what log files have not been committed.

In the event the failed Exchange Server was designed and configured properly and you have access to the log files you can use the following command to "play back" the log files manually into the Exchange Database.
The following command integrity checks the Transaction Logs to see if they are in a state to be committed to the Exchange Database.
ESEUTIL /ml “Transaction Logs Path”

If the output states the Transaction Logs are "OK" you can use the following command to commit them to the databases. The only variable that is maybe not obvious here is the "E00" this is the prefix of the Transaction Logs.
ESEUTIL /r E00 /l “Transaction Logs Path”  /d "Database EDB Path"

As you can see from a vanilla Exchange Server the Transaction Logs all start with "E0" when each Transaction Log reaches 1MB in size it is written to disk and a new log created.
.

It is also possible that your Transaction Logs are either unavailable or corrupt, in which case means you cannot commit them to the Exchange Database. The following command can be used to perform a hard repair.
ESEUTIL /p "Database EDB Path"

When you run ESEUTIL with the /p switch you will get a warning on screen "You should only run Repair on damaged or corrupted databases. Repair will not apply information in the transaction log files to the database and may cause information to be lost. Do you wish to process?" if you have tried to recovery the database and it has not worked you have no choice, click OK. After you click OK the ESEUTIL tool with perform a defragmentation the database.

The time ESEUTIL takes to complete largely depends on the size of the EDB file. It is why when I am designing Exchange Server solutions I try to have multiple databases, to keep the sizes of the individual mailstores smaller.
Step Two: Configuring the Recovery Mailbox Database
The next step is to ensure you have a new Exchange Server or Server's built to host the Mailbox Database, please note that the versions of Exchange (and builds) must be exactly the same or you will experience an error when trying to mount the recovered database. This TechNet article that states all of the Exchange Server build numbers;
When you have a new Exchange Server you must now create a new Mailbox Database to restore into. The following command can be used to create a new mailbox database with PowerShell.
New-MailboxDatabase –Name “Mailbox DB Name” –EDBFilePath “Path to Store EDB with .edb”
Server: ServerHostname


You must make one configuration change from the ECP in Exchange Server 2010 you could use the "-AllowFileRestore:$true" switch when creating the new database, this seems to be deprecated in Exchange Server 2013. If you know the new equivalent please comment below.
To make the change from the ECP browse to Servers\Databases click the new mailbox database and use the pencil icon to edit the properties. Click on the Maintenance tab and select "This database can be overwritten by a restore" option, click OK.

Now if it is not already, dismount the newly created mailbox database. Then browse to the path the database is stored at and rename the EDB file that is for the newly created database. I usually just put a dash before the name, once this is done copy the recovered mailbox database into the same location and rename that to match that of the newly created mailbox database.

Delete the Transaction Logs for the new databases, don't worry these will be created when the recovered database is mounted.

Mount the recovered database again from the ECP or using PowerShell. In my instance I am mounting the "Mailbox Mailstore - Recovered" database for clarity.
Step Three: Reconfigure Users Mailboxes
The following command will display all the users mailboxes that are hosted on the old, failed or corrupt mailbox database.
Get-Mailbox –Database “Old Database”


Then to perform the reconfiguration pipe Set-Mailbox -Database "Recovered Database" onto the previous command.
Get-Mailbox –Database “Old Database” | Set-Mailbox –Database “Recovered Database”


The last step is to perform a mailbox cleanup using the following PowerShell command.
Clean-MailboxDatabase “Recovered Mailbox Database”

Now you have successfully completed an Exchange Server Mailbox Database restore using Database Portability.