Read time 4 minutes
Database Availability Groups (DAGs) keep multiple copies of an Exchange database for automatic failover recovery. So, you can easily retrieve the crucial data in case of corruption or external threats to avoid business downtime. 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
Prerequisites of changing the path of the database copy
When you change Exchange database path for a mailbox database copy, you require some modification before proceeding. There are some prerequisites necessary for the process, such as:
- The user should have Organization Management and Database Copies permissions to change the path of the database copy.
- You will need to dismount the database temporarily 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.
How to change Exchange Database path using PowerShell
The task to manually assign a new path to replicated Exchange mailbox is quite complex & requires conceptual understanding. 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 of commands which you need to follow:
- Run the command to get the replay lag or truncation lag settings for all mailbox databases.
Get-MailboxDatabase Database3423 | Format-List *lag*
- Run the command to disable circular logging if it is in ‘Enabled’ status.
Set-MailboxDatabase Database3423 -CircularLoggingEnabled $false
- 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 from every database server where the file is removed. So, you don’t have to re-configure the database copies after adding them again.
- 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
- 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.
- After creating the folder hierarchy, move the database copies to these folders and their log streams.
- Add all the database copies which were removed in Step 3.
- Here, stop and restart the content index services for each Exchange Server, where the database copy is present. Run the command –
Restart-Service MSExchangeFastSearch
- Enable the circular logging.
Set-MailboxDatabase Database3423 -CircularLoggingEnabled $true
- Reconfigure the previous values of truncation lag time and replay lag time.
Set-MailboxDatabaseCopy Database3423\Server3423 -ReplayLagTime 00:10:00
- 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 - 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, it is recommended to go for a specialized professional tool which is secure and error-free. Once your EDB file is free from corruption, then it will become easier to change Exchange Database path.
Kernel for Exchange Server recovery software is loaded with robust features that easily resolves the corruption in Exchange database files. It is also 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.
Conclusion
In the above article, we have provided you with a prominent manual method to change the path of the Exchange database mailbox copy. Also, we have provided an automated solution with Kernel for Exchange Server software that will fix your corrupt EDB file using advanced algorithms. Understanding how to mount/dismount the Exchange 2016 database using Admin Center and PowerShell commands is a practical skill. It allows you to perform several changes in Exchange database mailboxes, making your management tasks more efficient.
