Read time 4 minutes

Summary: The ‘Mailbox Database Copy Failed & Suspended” issue must be resolved in the Database Availability Group. Here, you will understand the prerequisites and process for reseeding a database copy. Additionally, you can rely on the Kernel for Exchange Server to handle any database corruption issues effortlessly.

In a Database Availability Group, when you copy a database from an Exchange Server and place it on a different Exchange Server, the process is called ‘Seeding.’ Thus, it becomes a replica of your database where the entire data is present. Seeding is performed using the ‘Update-MailboxDatabaseCopy’ cmdlet.

Basics of seeding in a DAG

In a Database Availability Group, the active copy of the database is accessed by users. However, other database copies are updated by replicating the active database. But sometimes, you might face errors during the process due to various reasons. In that case, you may need to update other servers from a passive copy. You must suspend the database copy and then proceed with reseeding. We will discuss the process here in detail.

Prerequisites to run the cmdlet

First, fix the issue due to which the active database has failed. Then try to update the database.

  • You need to suspend the database copy before running the update cmdlet.
  • Before running the cmdlets, the user should have all the permissions- Database Availability Group and Mailbox Database Copy. The update cmdlet requires some critical parameters, and they will be available only when the user has the permissions.
  • The server with the passive copy must be running a Remote Registry Service.
The situations in which seeding/reseeding is beneficial
  • The original database is unavailable after a server crash
  • The Exchange log files are corrupt and cannot be played on the original database
  • The original database hasn’t undergone offline defragmentation
Here is the syntax of the cmdlet
Update-MailboxDatabaseCopy -Identity DB322312\NDR32 -SourceServer NDR53

The cmdlet will seed the copy of the DB322312 on Server NDR32 using NDR53 as the Source Server.

If the cmdlet does not run correctly, then it will not create a copy at the destination server, and there will be an error in the event log.

MSExchangeRepl Event ID: 4113
Database redundancy health check failed. Database copy: DB322312 Redundancy count:1
Error: Passive copy ‘DB322312\NDR32’ is not in a good state. Status: FailedAndSuspended

You can also check the copy status using the Exchange Management Shell with a cmdlet.

Get-MailboxDatabaseCopyStatus
How to solve the error?

To fix the error, you need to update the mailbox database copy running the cmdlet:

Update-MailboxDatabaseCopy -Identity “DB322312\NDR32” -DeleteExistingFiles

For longer reseeds, if you want to keep the PowerShell closed, then use the below cmdlet:

Update-MailboxDatabaseCopy -Identity ‘DB322312\NDR32’ -BeginSeed

The DeleteExistingFiles cmdlet deletes the existing log files to avoid any error messages:

Update-MailboxDatabaseCopy -Identity “DB322312\NDR32” -BeginSeed -DeleteExistingFiles

Before running the reseeding cmdlet, the Exchange Administrator should check multiple points necessary for copying the database.

  • The reseeding process will take time as per the database size and the network speed between the source and destination Exchange Servers.
  • By default, the cmdlet will use only the DAG group member server with the active database copy as the host server to copy the database.
  • The final data at the destination will be larger than the source database. For example, if the size of the database is 100 Gigabytes, the database at the destination will have more than 100 Gigabytes because it will consist of transaction log files and content index information additionally.
  • The copy process will take less time if the source and destination Exchange Server belongs to the same DAG group. The copy process may take significant time to complete if the servers belong to different DAG groups.
Reseeding using the Exchange Admin Center

You can also use the Exchange Admin Center to reseed the copy process.

  1. Log in using Administrator credentials and go to Server>>Database.
  2. Here, select the database which is to be updated.
  3. Click the Update button to start the reseeding process.
  4. Click the Browse button to add the source Exchange Server.
  5. The method of reseeding will begin. Wait for the process to end.

So, this is the whole process of handling a ‘mailbox database copy failed and suspended’ situation. Thus, you can manage the situation using various PowerShell cmdlets and Exchange Admin Center.

But, if the database faces corruption, sometimes the copy process will not be fruitful. In that case, try a professional Exchange recovery tool, making the Exchange server work more efficiently and securely.

Kernel for Exchange Server

Exchange database recovery tool is a powerful Exchange database corruption remover that can access the entire database and remove the corruption in the least time. After recovering the database, you can directly save the data to the destination Exchange Server or even Office 365 cloud. Also, this tool supports all the latest versions of Exchange Server, including Exchange 2019.

Conclusion

When you try to seed a mailbox database, you may get an error ‘Mailbox Database Copy Failed & Suspended.’ However, after taking some precautions, you can reseed the database. Sometimes, you may face frequent issues due to the corruption of the Exchange database. This issue can be fixed only using a professional Exchange server repair tool.

Kernel for Exchange Server