Change the Exchange Mailbox Database Path for a Mailbox Database Copy

Aftab Alam | Updated On - December 02, 2022 |

Read time 4 minutes

Database Availability Groups (DAGs) keep multiple copies of an Exchange database for automatic failover recovery. Though these copies may remain on different servers, the database copies should have a path similar to that of the original database. For example, if the primary database has a path like Documents\database\mailbox1.edb, then the copy database should have the same path in its Server as Documents\database\mailbox1.edb.

As soon as a database copy is created, continuous replication will be enabled automatically between the original and copy database. Exchange assigns an automatic identity to the database copies in the format <database>\<host server name>. It saves the database from many problems like abrupt deletion, corruption, improper handling, etc.

Prerequisites of Changing the Path of the Database Copy

There are some prerequisites necessary for the process. See the following points –

• The user should have Organization Management and Database Copies permissions to change the path of the database copy.
• Will have to dismount the database during the moving operation. So, users will not be able to access it.
• Disable the replication of database for all the copies. It can be done using the Remove-MailboxDatabaseCopy cmdlet.

To create a new path to the database copy, you can take the assistance of Exchange Management Shell only as there is no option in Exchange Admin Center (EAC) which you can use to complete the job. Here is the step-by-step process which you need to follow:

1. Run the command to get the replay lag or truncation lag settings.
   Get-MailboxDatabase Database3423 | Format-List *lag*
2. Run the command to disable to circular logging if it is in ‘Enabled’ status.
   Set-MailboxDatabase Database3423 -CircularLoggingEnabled $false
3. Now, remove database copies from the database with the help of the following cmdlet.
   Remove-MailboxDatabaseCopy -Identity Database3423\CopyDatabase3423 -Confirm:$False

   After you remove all the database copies, protect the database and transaction log files which will help you to reseed the database copies after adding them again (refer to Step 6 and Step 7).

4. Perform the move operation for a mailbox database path to a new location. During this operation, the database copy will remain ‘Dismounted.’
   Move-DatabasePath -Identity Databae3423 -EdbFilePath C:\NewFolder\ Databae3423.edb
5. Create the same folder structure for the database copy at each Exchange Server (that hosted the passive copies of the database previously). For example, if the primary database has a path like Documents\database\mailbox1.edb then create a similar path for the database copy in each server.
6. After creating the folder hierarchy, move the database copies to these folders and their log streams (refer to Step 3).
7. Add all the database copies which were removed in Step 3.
8. Here, stop and restart the content index services for each Exchange Server where the database copy is present. Run the command –
   Restart-Service MSExchangeFastSearch
9. Enable the circular logging.
   Set-MailboxDatabase Database3423 -CircularLoggingEnabled $true
10. Reconfigure the previous values of truncation lag time and replay lag time.
    Set-MailboxDatabaseCopy Database3423\Server3423 -ReplayLagTime 00:10:00
11. Finally, check the health of database copies by examining the transaction logs using the two commands –
    Get-MailboxDatabaseCopyStatus -Identity Database3423 | Format-List
    and
    Test-ReplicationHealth -Identity Database3423
12. Verify the whole process by running the cmdlet.
    Get-MailboxDatabaseCopyStatus CopyDatbase3423

After completing the whole process, the database copy will have a different path than the original database. But you can easily conclude that it is a long process when the number of database copies or database size is large. If there is a single error or misstep, then that may corrupt the primary database.

What to do if the Exchange Database is Corrupt?

There are some situations in which the Exchange database is completely inaccessible. Moving such a database or changing their paths may not fix the corruption issue. So, go for a specialized professional tool which is secure and error-free.

Kernel for Exchange Server recovery software which is useful for handling the corruption in Exchange database files. It is also a migration software which can access the database from its location and safely put it to a different Exchange Server. After database corruption, it is a wise option for you to use this software to recover the database and save data to different Exchange Server. You need not make any changes in the settings or any prerequisites before starting the process. Just use the software and Repair corrupt Exchange database instantly.