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.
There are some prerequisites necessary for the process. See the following points –
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:
Step – 1. Run the command to get the replay lag or truncation lag settings.
Step – 2. Run the command to disable to circular logging if it is in ‘Enabled’ status.
Step – 3. Now, remove database copies from the database with the help of the following cmdlet.
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).
Step – 4. Perform the move operation for a mailbox database path to a new location. During this operation, the database copy will remain ‘Dismounted.’
Step – 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.
Step – 6. After creating the folder hierarchy, move the database copies to these folders and their log streams (refer to Step 3).
Step – 7. Add all the database copies which were removed in Step 3.
Step – 8. Here, stop and restart the content index services for each Exchange Server where the database copy is present. Run the command –
Step – 9. Enable the circular logging.
Step – 10. Reconfigure the previous values of truncation lag time and replay lag time.
Step – 11. Finally, check the health of database copies by examining the transaction logs using the two commands –
Step – 12. Verify the whole process by running the cmdlet.
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.
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 recover the data instantly.