Exchange 2010 and Exchange 2013 offer several different methods to recover from mailbox server failures. One such method is known as database portability, which allows a mailbox database that was mounted on one mailbox server to be remounted on a different mailbox server.
This can be helpful when there is a server failure and the physical database files are still intact (and, of course, a different copy of the database is not available to be activated if the server is a member of a DAG).
In the example below we experienced a server failure and did not have database copies available to activate. This particular mailbox server experienced a hardware failure, so rebuilding the server with the RecoverServer switch was not an option until the faulty hardware was replaced (The RecoverServer option is a parameter that can executed during a server build that is used for rebuilding failed servers). As such, we decided the fastest option for restoring the databases was to mount the databases that were hosted on the failed server on a different server (as coincidence had it, this other server was going to host a second copy of the databases once additional storage was made available).
The first step is to gain access to the physical database files. This includes both the database file and its log files. In our case, the data was stored on a SAN unit. As such, we were able to re-present the LUNS to the healthy server. If the server was virtualized, you might be able to reconnect the virtual disks to a different virtual server. Another option might be to restore the database files (though it might be better to use a recovery database if circumstances require).
Once you have access to the physical files, the next step is to determine if the mailbox database was shut down in a clean state. This is done using EseUtil. The syntax to use is:
EseUtil /mh <MyDatabase.edb>
Either run this command from the folder the database file is located in or include the full path.
Look for the value of State as shown below:
If the server crashed, chances are the shutdown state will be dirty as shown above. If this is the case, this must be fixed before moving forward. If the shutdown state is clean, move onto the next step.
A dirty shutdown is when a database was shut down before the existing log files were processed into the database (which typically happens when a server crashes). If a database dismount is performed, the database should shut down in a clean state. To recover from a dirty shutdown, the log files must be available. To perform a soft recovery (play the log files forward) execute the following command:
EseUtil /r <Log file prefix such as E01> /d <path to edb file>
The log file prefix will be the first three characters of the log files for the database. In the example below, the log file prefix is E01.
Once complete, you should have a clean shutdown. Run the EseUtil again with the /mh parameter (as shown above).
At this point, the database is in a healthy state, which means it should mount successfully.
Next, create a database on the server you want to move the database to. Make sure to create the new database in a different location than the existing database you want to recover. Do not mount the new database. I found it is easiest to create the new database on the same volumes as the one to be restored (meaning place the new database location in a different folder on the same volume as the database to be recovered and do the same for the logs). The reason for doing this will become apparent in a subsequent step.
It does not matter if you use the GUI or the Exchange Management Shell to create the database.
New-MailboxDatabase -Name <database name> -Server <Server name> -EdbFilePath <Name of database including the path> -LogFolderPath <Path to log files>
Then mark the database so that it can be overwritten by a restore.
Once the new database has been created and configured, move the database and log files of the database to be restored to the location specified for the new database. Since the new database has not been mounted yet, the physical files will not exist. Make sure the physical name of the database matches the name of the new database you created in the step above.
If you created different folder names for the new database as mentioned above, all you will need to do is to rename the original folders to match the ones you just specified for the new database. Make sure the path and database name of the original database match what you defined for the new database.
At this point, the new database should be pointing to the physical database of the original database and the log files should be sitting in the folder that was defined for the new database.
Now, mount the database and confirm it has mounted successfully. There is one final step. Even though the database is mounted, the users whose mailboxes are stored in this database are still pointing to the original database on the original server. As such, the attributes for those users need to be updated to point to the new location. To do this type the following command:
Get-Mailbox -Database <Original database> | Set-Mailbox –Database <New database>
That’s all there is to it. Users should be able to reconnect to their mailboxes under the following conditions:
- Active Directory replication has occurred
- Users are running Outlook 2007 or higher
If users are using an older version of Outlook (which they should no longer be, since it is not supported), the profile will need to be manually updated.
Users who run Outlook in cached mode may see the following message in Outlook:
This will happen if the Outlook cache has not updated itself to point to the new server. Should this message appear, instruct users to select Use Temporary Mailbox. Users should not see the message a second time. This message is typically associated when a dial tone database has been deployed as part of mailbox database failure. It should not typically show up for database portability.
Under the right circumstances, database portability can be a very useful tool for recovering from mailbox server failures. I have also used it to quickly move databases from one server to another. It has also proven very helpful for seeding database copies – especially when large databases need to be seeded across a WAN connection.