Seeding in the Exchange Server is the term used to update the Exchange database by copying it to another Exchange Server. But sometimes, seeding fails due to unwanted issues, and the user is required to reseed the database. The database is copied to the Database Availability Group of different Exchange Server and it becomes a passive copy of the original database. The replicated database replays the log copied from the original database.
Here are following conditions that are solved with the seeding of a database;
- When the original database has faced a catastrophe and has become unavailable, then the passive copy database can be useful in restoring the data.
- When the Exchange Server has caught a corrupt log file that cannot be played in the original database, then it can be tested in the copy database.
- When the offline defragmentation has occurred with the original database.
- When the log generation for the Exchange database has been changed to 1.
There are some prerequisites that you need to follow to complete a successful update process;
- The user should have the Database Availability Group and Mailbox Database Copy Permissions to run the process. The Exchange Administrator should assign such permission to the user.
- Any existing mailbox database copy should be suspended.
- The Exchange Server hosting the passive database should be running the Remote Registry Service.
If you are unable to run the copy database process smoothly, then you will have to face a failed status for the process error –
Passive copy ‘Mailbox Database Jim4231331’ is not in a good state. Status: FailedAndSuspended
You can also run a cmdlet to get the current status of the update;
The cmdlet will bring all the update processes that have failed to run.
The error message for the failed seeding process is as follows –
Passive copy ‘Mailbox Database <database name>’ isn’t in a good state. Status: FailedAndSuspended
If you want to run the update process again, then it is called reseeding.
How to reseed a failed mailbox database copy?
If you are facing the error of a failed database update process, then you will want to restart it again. But, before reseeding the database, you should suspend the failed one.
If it was a single mailbox, then write the following command;
If there were multiple mailboxes, you need to run the command a little differently.
The cmdlet will delete all the ongoing processes that were failed and suspend them. Now you can move ahead in resuming the reseeding process again.
The update mailbox command will reseed the database again and delete the existing files that were moved in the failed command. For longer reseeds, the Begin Seed parameter will work fine.
Note: The duration of the reseeding process of the Exchange mailbox database depends upon its size, Network bandwidth, and Speed of hard disk
Use Exchange Admin Center for Reseeding
There are few simple steps involved in the reseeding process via Exchange Admin Center as described below.
- Login to the Exchange Admin Center.
- Go to Server > database.
- Go to Database Copies section under Details and then click Suspend for the passive database copy. Click on Save.
- Select the same .mailbox database copy and click on Update link.
- Choose the Exchange Server database as source with the Browse option. Click Save.
- It would start the reseeding process which would take some time for the completion.
- Now database copy is in healthy state and replication can be continued.
How to know that the above method worked?
To verify that you have successfully seeded a mailbox database copy by the above method and the problem is resolved, perform one of the following steps:
- In the Exchange Management Shell (EAC), navigate the following path Servers > Databases. Then, select the database that was seeded. Copy the status of the database and its content index displayed In the Details pane along with the current copy queue length.
- In the Exchange Management Shell (EAC), run the given below command for the verification of the mailbox database copy was seeded successfully.
There are multiple points that the Administrator should know about the reseeding process because they are going to affect the mailbox data-
- The new database at the destination exchange server will have slightly more size than the actual database. If the size of the mailbox database was 10 GB in the first Server, then the destination server will have the database more than 10 GB in size.
- For the swift reseeding process, both Exchange Servers should be in the same DAG group. If they are in different groups, then it is going to take more time to complete.
- The cmdlet chooses the Exchange Server as host only when it is a member of the DAG group member server.
Conclusion
Reseeding is a good process to increase the availability of your Exchange Server database. If the primary database is lost or facing corruption, then you should use the passive copy database is the recovery database.
Sometimes, when the corruption hits the Exchange database, then it affects more than one database and the manual methods like ESEUTIL tool are not able to recover the data. So, you should use professional Exchange Recovery software that can recover the data from corrupt EDB files.