Change the Exchange mailbox database path for a mailbox database copy

Read time 4 minutes

Database Availability Groups (DAGs) serve as a safeguard by maintaining redundant copies of an Exchange database to ensure seamless recovery in the event of a failure. These redundant copies, while residing on distinct servers, are meticulously structured to mirror the path of the original database. For instance, if the primary database’s path is “Documents\database\mailbox1.edb,” the copy database on its respective server must adhere to the identical path, preserving “Documents\database\mailbox1.edb” for continuity.

Once a database copy is generated, continuous replication is automatically initiated between the original and the copy database. Exchange assigns a unique automatic identity to these database copies following the format <database>\<host server name>. This built-in feature serves as a safeguard against various potential issues, such as sudden deletion, data corruption, mishandling, and more, ensuring the overall stability and reliability of the database.

Changing the path of the database copy pre-requisites

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

Once the entire process is finalized, the copied database will reside in a distinct location from the original one. However, it becomes evident that this is a time-consuming endeavor, particularly when dealing with a substantial number of database copies or when the database size is extensive. Any single error or misstep in this process could potentially lead to corruption in the primary database.

What to do if the Exchange Database is corrupt?

In certain instances, the Exchange database can become entirely inaccessible, rendering traditional methods like relocating the database or altering its file paths ineffective in resolving corruption issues. In such cases, it is advisable to opt for a specialized professional tool that guarantees both security and error-free performance.

Introducing Exchange Server recovery software, a versatile solution designed to effectively address Exchange database file corruption issues. This software not only facilitates recovery but also serves as a seamless migration tool, effortlessly accessing the database from its current location and securely transferring it to a new Exchange Server. In the aftermath of database corruption, employing this software is a prudent choice, ensuring the retrieval of critical data and its safe relocation to a different Exchange Server. Eliminating the need for complex configuration adjustments or prerequisites, this software streamlines the recovery process, allowing you to swiftly Repair corrupt Exchange database with ease.