Reseeding after ‘Mailbox Database Copy Failed & Suspended’

Aftab Alam | Updated On - 10 Apr 2020 |

When you copy a database from an Exchange Server and place it on a different Exchange Server, then you may call the process ‘Seeding.’ Thus, it becomes a replica of your database where the entire data is present. Seeding is performed using the ‘Update-MailboxDatabaseCopy’ cmdlet.

Here are some points which you should understand before running the cmdlet –

• You need to suspend the database copy before running the update cmdlet.
• The user should have permissions before you run the cmdlet. There are some critical parameters which the update cmdlet requires, and they will be available only when the user has the permissions.

Here is the syntax of the cmdlet –

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

If the cmdlet did not run correctly, then it will not create a copy at the destination server, and there will be an error at 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.

How to solve the error?

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

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

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

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

• The reseeding process will take time as per the size of the database 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 Gigabyte, then the database at the destination will have more than 100 Gigabyte because it will consist transaction log files and content index information additionally.
• If the source and destination Exchange Server belongs to the same DAG group, then the copy process will take quite less time. If the servers belong to different DAG groups, the copy process may take significant time to complete.

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 handle the situation using various PowerShell cmdlets and Exchange Admin Center.

But, if the database faces any corruption, sometimes the copy process will not be fruitful. In that case, try a professional Exchange recovery tool. Which makes Exchange server working more easy and secure.

Kernel for Exchange Server

Kernel for Exchange Server recovery tool is a powerful Exchange database corruption remover which 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.