<

Microsoft Exchange Database Portability

Published on
3,520 Points
420 Views
1 Endorsement
Last Modified:
Editors:
Mahesh
Freelancer, IT Consultant experienced on Microsoft server, AD and Messaging projects
In this article will discuss what Microsoft exchange database portability is and how we can use it to restore email services along with mailbox data in case of Exchange Server failures.

Article Applicability: Microsoft Exchange 2010 and above versions.


Database portability refers to the ability to move or copy a database from one place to other or from one platform to another.


In Microsoft Exchange terms, a database can be moved \ copied \ restored (Ported) from one mailbox server to another mailbox server and users can be reconnected to a ported database.


Database portability allows you to point exchange mailboxes to a brand new empty database (dial tone database) when the original database fails or is unavailable so that users at least can use email services without current email data. Meantime the original database can be restored and the dial tone database would be replaced by the restored database. Later on, contents from the dial tone database can be merged to the original restored database. This way service disruption and data loss would be minimal.


Dial tone recovery is originally innovated in Exchange 2007 and was carry forwarded with next versions to minimize downtime impact due to database failure until the database is recovered. The process is a bit changed with Exchange 2010 when compared to 2007


With Exchange 2010 Microsoft came up with DAG for high availability and removed the dependency on shared storage and thus users will not be affected by mailbox server failure as long as DAG is configured.


However, the database portability feature is still useful for Exchange standalone deployments without DAG. Database portability can be triggered in below cases


Database Portability - Mailbox server failure in a non DAG environment with Native Storage 


If you have multiple mailbox servers without DAG with a native server disk, and if one of the mailbox servers gone down, you can point users in the failed mailbox database to a new temporary dial tone database on another server and keep emails service going for those users. Users will not get existing emails back until failed database restores, however they can at least send/receive newer emails. Later on, you can restore the original mailbox database on the same server or on another exchange server from backup under Recovery database. 


Now the recovered database can be swapped with the Dial tone database so that users will get old emails back. Any email data accumulated in the dial tone database can be merged with the recovered database so that the user will get most of his email data back, including old and new emails. Meantime the failed server can be rebuilt by a fresh install with the recoverserver switch to the state before failure. Now we can create a new mailbox database on the new server and move mailboxes from the current server to new server.


Database Portability - Mailbox server failure in a non DAG environment with External Storage 


The same scenario above with external storage (SAN / DAS) used for database and logs and if the server failed, on another healthy / alive mailbox server we do need to create a new mailbox database (dial tone database) and point users from the failed database to this empty database to quickly start with email service without existing mails. Meantime we can move storage LUN from the failed server and mount it on above healthy server. Also we need to create a recovery database and point it to the database on moved LUN location. swap the dial tone database with the recovered one and users should get old emails back. Later on we can merge emails from dial tone database to recovered database

If failed LUN can quickly made available / mapped to another exchange server, we can simply create new mailbox database pointing to edb file on mapped LUN and point mailboxes in failed database to this new database and eventually users would get old emails back immediately. In that case we don't need to create dial tone database


Standalone Exchange Server Failure 


In this scenario, you must restore the entire exchange server from a backup only including databases.


To demonstrate database portability with a dial tone database, we will use two exchange 2013 servers installed on windows server 2012 R2 with native storage without DAG


PMExchange2K13 (with 1 database DB1)

PMExchange2K14 (with 1 database DB4)

 

Consider PMExchange2k14 server suffered from hardware failure and all users part of DB4 were affected. It’s not possible to bring the server online immediately. We do have a database backup available to us. We could deploy fresh server and restore exchange configuration from AD and databases from the backup, but the process will take time and meantime, users won't be able to use email services and email loss could occur.


To minimize service disruption, we will use database portability and the dial tone recovery method. This will ensure that users can at least access email services and send/receive new emails. They won’t be able to access existing emails until the original database gets restored.

 

The method involves:


  1. Create a new empty mailbox database (Dial tone database) on the alive server
  2. Point failed database mailboxes to the above empty database
  3. Mount the empty database so that user’s mailboxes get online and they can use it to send/receive new emails
  4. Meantime restore the failed database in the recovery database.
  5. Post restore, swap Dial tone database and recovery database
  6. Merge contents in Dial tone database with recovered database

 

Prerequisites for dial tone recovery:


  1. At least two Exchange servers with mailbox server roles with the same OS version, Exchange version and CU version if any to avoid database schema conflicts
  2. All Exchange servers part of the recovery procedure must be part of the same exchange organisation
  3. The Server where you create a Dial tone database and recovery database should have enough disk space available to accommodate both databases. We may need to add an additional fixed disk to the server (SCSI \ DAS \ SAN drive in case of a physical server or VHD / VMDK in case of a virtual server)




Demonstrate database portability - mailbox serverfailure in non DAG environment with native storage:


1).    On a healthy exchange server, create an empty production database (AKA Dial tone database)


New-MailboxDatabase -Name DialToneDB -Server PMExchange2k13 -EdbFilePath I:\Dialtone\DialToneDB.edb -LogFolderPath I:\DialTone


The command warns us to restart the information store service to generate a new worker process for the database, in production we cannot restart the information store service during business hours because it causes a service disruption. We can work without restarting the service for now. Later on, during off business hours / night / period we can restart the service.


2).    Now rehome mailboxes in failed database DB4 to new Dialtone database.


Get-Mailbox –Database DB4 | Set-Mailbox –Database DialToneDB






Force AD replication as we are actually editing AD user attributes to point to the new database


3).    Now mount the new database.


Mount-Database DialToneDB


This step will resume user email services and they can send/receive new emails with the new database. In the above snapshot, DB4 is the database on the failed server.


4).    Now when a user opens outlook they will get prompted to use the temporary mailbox as shown below.



Here the user should select Use Temporary Mailbox and he should get a blank mailbox as an online mailbox. This happens because outlook knows to connect to the old database but when it starts, AD user properties point it to the new database hence it informs you to use the temporary mailbox. Users can use OWA as well to connect this empty mailbox.



This way once the users' service is restored (with an empty mailbox), we now need to restore the failed database.


5).    Create a new recovery database on alive exchange mailbox server (PMExchange2K13 in our case) and restore the failed database as a recovery database. The recovery database is a special type of database which cannot be accessed by any standard client protocols such as RPC, Mapi, HTTP, IMAP, SMTP etc. it only can be accessed by recovery tools and mailbox restoration API.


New-MailboxDatabase -Name RSGroup -EdbFilePath I:\Recovery\Recoverydb.edb -LogFolderPath I:\recovery -Recovery -Server PMExchange2k13


Note that the recovery database configuration is added to AD but the actual database is not generated yet until we mount the database.


6).    Now we need to restore the failed database to the recovery database folder through the use of the backup tool.



7).    Now we need to check the restored database health, if it’s in dirty shutdown, it won’t mount and we just need to repair it and bring it to clean shutdown state. Run the below command


eseutil /mh I:\Recovery\DB4.edb


The database is in a "Dirty Shutdown" State. We need to check if the required logs are restored with the restore operation. If logs are available, we can do a soft recovery. If logs are missing or still if soft recovery fails, we must use hard recovery. If hard recovery also fails, we need to use either 3rd party tools or to log a call to Microsoft support.



Required logs are available, hence we will attempt soft recovery, Run the below command from an elevated command prompt


eseutil.exe /r E01 /d I:\recovery /L I:\Recovery


The soft recovery attempt is successful. We now need to check if the database is in a clean state.



The database is in a clean shutdown state now.


8).    Now rename the restored database from “DB4.edb” to “Recoverydb.edb” which is the name we chose during the recovery database creation at step no. 5


9).    Now we need to ensure that the restored database will mount as a recovery database. Hence we need to run the below command. This will allow the restored database to overwrite the original recovery database, else the database won’t mount.


Get-MailboxDatabase RSGroup | Set-MailboxDatabase -AllowFileRestore $true
Get-MailboxDatabase RSGroup | fl *allow*


10).    Mount the recovery database and check what mailboxes it contains.


Mount-Database RSGroup
Get-MailboxDatabase RSGroup | Get-MailboxStatistics


Now it’s time to swap the recovery database with the Dialtone database so that users will get their old emails back. This step causes an email service outage/downtime for a short period as the process involves dismounting both databases and then swapping (move and rename) both databases and mounting again. Downtime window depends upon the location of both databases (on same drive \ different drive \ on a different server) and the database size.


11).    Dismount dial tone and recovery databases both. Run the below commands.


Dismount-Database RSGroup -Confirm:$False
Dismount-Database DialToneDB -Confirm:$False


12).    Now swap the recovery database file with the Dialtone database file. This operation includes the actual database file move from the recovery folder to the Dialtone folder and vice versa followed by renaming each one to match the original database name.


Ex: The recovery database to be moved to the DialToneDB database folder and the Dialtone database to be moved to the recovery database folder and rename Recoverydb.edb to dialtonedb.edb and dialtonedb.edb to Recoverydb.edb respectively.


13).    Now mark both databases to be overwritten by restore, this is an important step, otherwise, the swapped databases will remain locked and will not mount.


Get-MailboxDatabase DialToneDB | Set-MailboxDatabase -AllowFileRestore $true
Get-MailboxDatabase RSGroup | Set-MailboxDatabase -AllowFileRestore $true


14).    Mount both databases.


Mount-Database RSGroup
Mount-Database DialToneDB


Both databases mounted successfully. Here email downtime ends and users should get their old email back in Outlook. Users may need to close and re-open Outlook. Note that now users don't have emails post database failures as we have replaced and moved the current database.


15).    Now mailboxes that belong to DialToneDB should have all old emails but they don’t have newer mails transacted after the database failure. Those emails are now available with the swapped recovery database. We need to merge \ restore those leftover emails from the previous DialTone database (now recovery database). Run the below command and store swapped dial tone database in variable.


$mailboxes = get-Mailbox -Database DialToneDB
$mailboxes


Now run a mailbox restore request so that leftover mailbox data will get copied from the recovery database to the production database.


$mailboxes | % { New-MailboxRestoreRequest -SourceStoreMailbox $_.ExchangeGuid -SourceDatabase RSGroup -TargetMailbox $_ }


We can see that the restore request is queued and will be processed shortly. We can check the progress/status by running Get-MailboxRestoreRequest


If the status remains "Queued" for a long time, simply restart the Mailbox Replication Service.



We can see that the restoration has completed. Now users should have all emails both before and post the database failure time.


16).    Once all mailboxes are restored this way, you can dismount and delete recovery database.


Dismount-Database RSGroup
Remove-MailboxDatabase RSGroup




Database Portability - Mailbox server failure in a non DAG environment with External Storage:


In case the failed server has external storage, you can have below options to restore email functionality with downtime:


Option 1 - Direct Method

This option is useful if you can quickly unmap database LUN from failed server and map with alternate mailbox server. You can directly bring failed database online with this method with little downtime. Benefit of this option is, you can quickly restore email service with mailbox data by eliminating storage provision and separate Dial tone database

  1. Unmap database LUN from the failed exchange server and map it with alive / alternate mailbox server
  2. Ensure the database on LUN is in clean shutdown, if not attempt soft/hard recovery depending upon log file availability and health
  3. Create a new mailbox database pointing to above LUN in new folder separated from failed database folder with same database name as failed one, do not mount the database yet.
  4. Mark new database to be overwritten by restore and then move actual failed database to new database folder
  5. Mount new database
  6. Point / rehome the failed database mailboxes to a new database. At this point users can start using email service with existing emails.


Option 2 - Dialtone Method

Use this option if you cannot map database LUN from failed server to alternate server quickly for whatever reason

  1. On alternate / alive mailbox server - create a new mailbox database on drive where you have good amount of free space, you may need to provision storage drive
  2. Point / rehome the failed database mailboxes to a new database and mount the database to start email service without existing emails
  3. Unmap database LUN from the failed exchange server and map it with alive exchange server
  4. Ensure the database on LUN is in clean shutdown, if not attempt soft/hard recovery depending upon log file availability and health
  5. Create a new recovery database pointing to above LUN in new folder separated from failed database folder with same database name as failed one, do not mount the database yet
  6. Mark recovery database to be overwritten by restore and then move actual failed database to recovery database folder
  7. Mount and dismount recovery database
  8. Dismount new database as well. (Again service outage)
  9. Again mark the both databases to be overwritten by restore operation, this is a mandatory operation as we need to swap databases and until we remove this protection, the swapped database won't mount
  10. Swap database files (move and rename) between the recovery and new database
  11. Mount both databases (Email service resumes with old data)
  12. Restore mailbox data from the recovery database (This will restore email data post database failure)




Meantime you can recover the Failed server. This process involves:


1).    Prepare a new server with an identical configuration as the failed server. This includes OS, OS patches, hostname disks and partitions with drive letter, CPU and memory configuration, network card config

2).    Reset the failed server account in active directory

3).    Join the new server to the active directory domain, it will pick up the failed server computer account

4).    Install Exchange roles specific prerequisites (prerequisites should match to exchange roles which had installed on the failed server), you can get all prerequisites on the Microsoft web site

5).    Use the same exchange media used to install the failed server and run the below command from an elevated command prompt. The command is for Exchange 2013 and above


Setup.exe /Mode:RecoverServer /IAcceptExchangeServerLicenseTerms


Command completed successfully. Exchange has now recovered all the information from active directory including the database entry. Note that this switch does not recover the actual database file.


6).    Now you can mount the empty database on this server and then can move mailboxes from the other server. You do need to configure a few virtual directories URLs.


Server recovery with recoverserver switch method applies to exchange 2007 and above versions.


In this article, I have covered Exchange database dial tone recovery for both native and external storage.


If you liked this article, please click the Thumbs-up icon below

1
Author:Mahesh
Ask questions about what you read
If you have a question about something within an article, you can receive help directly from the article author. Experts Exchange article authors are available to answer questions and further the discussion.
Get 7 days free