Dynamics of Exchange Server Database Portability

 

In this blog we are going to understand the simplicity of Database Portability in Exchange 2013/2016.

 

  • Database Portability was incepted and introduced in Exchange 2010. Indeed it was a great innovation via Microsoft for Disasters or for the case where your back up take long time and you lead to minimize the load on one server which is going to minimize the backup time of that server.
  •  

  • Talking about Database Portability for the situation where you need to reduce the load from one server. We wish to append a new server to minimize the load on server1 to complete his backup faster.

 

We must follow the sequence of steps given below to perform the database portability

Step 1:

 

OS and Exchange:

  • Implement same Exchange server version and Same CU.

 

Step 2:

 

Planning:

  • Allot location path over the Directory location in the new serv.
    Database location E:\exchange\databases\DBName\DBNAme.edb
    Log Files location L:\exchange\tlogs\DBName
  • Accumulate the LogFilePrefix which is msExchESEParamBaseName AD attribute

 

NOTE: –

  • In case you just replicate the database and mount it then earlier backup cannot be replay the log files. Hence, in case you wish to continue the log sequence then we must to give same LogFilePrefix to the new database

 

LogFilePrefix to the new database

 

  • Duly take the database Backup
  •  

  • And declare 1-hour outage.

 

Step 3:

 

Creation of a new Database:

  • Run the following given below cmdlet:
  •  

  • New-MailboxDatabase -Name DatabaseName -Server DestinationServerName -EDBFilePath E:\exchange\databases\DBNAMEFolder\DBNAme.edb -LogFolderPath L:\exchange\tlogs\DBNAMEfolder

 

Step 4:

 

  • Reboot Information store to get it restarted
  •  

  • Restart the Information Store service in the new server.

 

Step 5:

 

  • Perform Database restore Enable.
  •  

  • Set-MailboxDatabase Databasename -AllowFileRestore $true

 

Step 6:

 

  • Edit and Update msExchESEParamBaseName value

 
msExchESEParamBaseName value
 

  • Now, Open Configuration partition in Adsiedit.msc
  •  

  • Expand to CN=Configuration,DC=DOMAIN,DC=LOCAL > CN=Services > CN=Microsoft Exchange > CN=EXCHANGE_ORG > CN=Administrative Groups > CN=Exchange Administrative Group (FYDIBOHF23SPDLT) >CN=Databases
  •  

  • Next, Go to the properties of old database and trace or look for msExchESEParamBaseName value. It should be 3 characters starting with Exx. Copy this.
  •  

  • Now, Go over to the properties of new database and traverse to look for msExchESEParamBaseName value. Alter it to same value as Old Database. In case you had coped previously then paste here. Then, Click ok and close Adsiedit.msc

 

Step 7:

 

  • Now, Dismount the OLD Database. This time user will get disconnected from the server.

 

Step 8:

 

  • Determine and perform verification of Database, Log and Checkpoint file.
  •  

  • Execute the following cmdlet on the dismounted database to verify in case it is a clean shut

 
eseutil.exe /mh “E:\exchange\databases\DBFolde\DBName.edb”
 
 dismounted database
 

  • Execute the following cmdlet over the dismounted database’s checkpoint file to verify check the last log

 
eseutil.exe /mk “L:\exchange\tlogs\CheckpointFilePath\Checkpointfilename.chk”
 
Check the Checkpoint – 0x5D954
 
 verify check the last log
 

  • Execute the following cmdlet against the dismounted database’s last log file (file going to be only of 3 letters and numbers starting with Exx, xx might be anything from 0-9 of A-F) to validate the last log file name.
  •  

  • This will depict if it is the same that committed to the DB last Log which is in the Checkpoint file shown in the previous step.

 

eseutil.exe /ml “L:\exchange\tlogs\LogFilePath\LastLogFileName.log”
Check the LGeneration 0x5D954

 

DB last Log which is in the Checkpoint file

 

Step 9:

 

  • Copy/replicate the database at the new location

 

Step 10:

 

  • Copy/replicate the last Exx.log and Exx.chk file at the new location

 

Step 11:

 

At the time while Database is being copied, update the following database properties

  • Restrict to Set the limits tab same as the source database for mailbox size and retention.
  •  

  • Restrict to Set the Offline Address Book same as source database
  •  

  • Restrict to Set the Journaling mailbox same as Source Database.

 

Step 12:

 

  • Rename the Copied Database to the name of the created database that we have
    configured previously.

 

Step 13:

 

Now, Mount the Database over the new server:

  • Execute the below mentioned cmdlet
    Mount-Database Databasename

 

Step 14:

 

  • Alter the Mailbox’s Database property which is homeMDB and HomeServer by running
    the following cmdlet
  •  

  • Get-Mailbox -Database |where {$_.ObjectClass -NotMatch ‘(SystemAttendantMailbox|ExOleDbSystemMailbox)’}| Set-Mailbox -Database -Confirm: $False

 

Step 15:

 

Recycle the following App Pools in the IIS Manager

  • Open IIS Manager
  •  

  • Expand it and choose Application Pools
  •  

  • Then Recycle the given AppPools
    MSExchangeAutodiscoverAppPool
    MSEXChangeOWAAppPool
  •  

  • Perform the same in all frontend and backend servers.

 

Step 16:

 

  • Now, perform the AD replication to all domain controllers from AD sites and Services

 

Step 17:

 

  • Next, Delete the dismounted old database from EAC.

 
Step 18:

 

  • Then, Delete the health mailbox emails from the queue which is going to look like the screen.

 
Delete the health mailbox emails from the queue
 

Step 19:

 

  • Execute the following command to verify the mail queue
    Get-queue

 

Step 20:

 

  • Now, execute the following command to resubmit the emails for delivery
    Get-Queue | Retry-Queue -Resubmit $true

 

Step 21:

 

  • Next, Delete health check monitoring mailboxes of those respective databases.

 

Step 22:

 

  • Now, Backup the old logs and database and then delete them from the old server.

 

Exchange Server Database Portability should not be used as a Migration Method

  • Database portability is a feature of Exchange Server that exists in Exchange 2007, Exchange 2010, and Exchange 2013 and again in Exchange 2016.
  •  

  • Actually, database portability permits an Exchange Server mailbox database to be migrated and mounted on another mailbox server within the same enterprise.
  •  

  • Database portability (or database mobility) is one of the developments happens in Exchange which makes database availability groups possible. This is also very useful for disaster recovery situations, like when a server fails, as it might be quicker in few cases to mount a database present on another server rather than waiting for the failed server to be repaired and brought back online.

 

As per Microsoft this is a benefit mentioned in their documentation:

  • “By using database portability and reliability is improved by removing several error-prone, manual steps performed from the recovery processes. In addition, database portability reduces the overall recovery times for various failure scenarios”
  •  

  • Database portability should ensure that it must not be used for migrating entire contents of a database from one server over to another.
  •  

  • However, customers have different perspective. As per few users database portability is a disaster recovery capability, and mailbox moves are a migration capability.
  •  

  • In other words, the idea is don’t use a DR feature to migrate data. Let’s explore and compare the two processes.

 

First, database portability includes:

  • Dismounting the database (start an outage for your users)
  •  

  • Manually replicating the database and log files to another server (quite difficult to estimate duration, is going to depend on amount of data, the speed of network, and speed of disks)
  •  

  • Possible need to conduct soft recovery for the database
  •  

  • Database creation on the new server and mount using the copied files.
  •  

  • Update and edit mailbox attributes of affected users (then wait for Active Directory replication, this will end the outage for users).
  •  

  • And Re-submit queued messages

 
At the time of database portability process, there’s a lengthy outage, all performed are manual steps, no error handling, having broad impact (all mailbox users for the database simultaneously), and no roll back (in case you mount the database and re-submit queued messages, then probably you spot a problem, you can’t just dismount and turn back to the old database).
 

In comparison, mailbox moves include:

  • Creation of move requests or batches
  •  

  • Waiting for the migrations to process (no user impact yet)
  •  

  • Scheduling a finish time for the final cutover (summarized outage per user and possible Active Directory replication delay
  •  

  • At the time of mailbox migration there’s no disruption for the end user till the brief outage during final cutover, the mailbox data is migrated automatically for you, the mailbox shifts have error handling and statistics reporting, no need to perform manually re-submit queued messages after the final cutover, also you can control the impact on a per-mailbox basis.

 
In conclusion, the database portability is not a sensible strategy for migrating data among two Exchange servers.

Kristin is a content strategist at Techarex Networks. Kristin follows the B2B technology space closely and loves to write on the latest changes in technology, futuretech and fixes for day to day how to issues. Besides writing Kristin also loves music, moves and skating.

Techarex Networks provides the complete range of Hosted Exchange solutions and services, giving access to reliable, secure, messaging and collaborative enterprise-grade solutions having 99.999% uptime with unmatched SLA. Provide enterprise-level sync with Outlook Web App and mobile devices. Anywhere, anytime access using Instant Message and video calling integration.