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.
