On a standalone Exchange Server, it is not enough to ensure business continuity. For the failover and business continuity requirements, you can use Microsoft’s Database Availability Groups (DAG) to ensure that your Exchange Server continues to run, if one instance fails. For this to work, you would need two or more servers to achieve a DAG, with Microsoft Exchange Server Standard or Enterprise edition. The decision to go with either Standard or Enterprise edition is entirely depends upon the design and volume of your mailboxes.
If you do not need more than five mailbox databases, then you can go for the Standard edition. With regards to licensing, you need to buy the Exchange Server Standard/Enterprise for each server. With regards to the user client access licenses (CALs), you only need to purchase them once.
A typical Database Availability Group (DAG), with two Exchange Servers and a File Share Witness server, having quorum and voting majority is illustrated below.
When you create Database Availability Groups (DAG), you have a copy of a database in one server and a passive copy on another server. So, the active copy is always the one being accessed and the other database replicates from it.
In the illustration below, you can see that there are two databases where the active copy of DB1 is on EX01 Server and the passive copy is on EX02 Server. And the active copy of DB2 is on EX02 Server and the passive copy is on EX01 Server.
When you add a new mailbox database to a Database Availability Group (DAG), you need to first take a copy to the second server (in the case of our illustration, it is EX02). After the full copy, which is called the first seed, is complete, the Database Availability Group (DAG) will continue to replicate any changes. You can also do this by taking a copy of the database and copy it on the secondary server. It all depends on the size and speed of the network between the two nodes.
Sometimes, due to hardware or software issues, you need to re-seed the database. This could be due to corrupted information on the database copy or there was an error on the database which made the copy unusable by the Database Availability Group (DAG).
During seeding, you might encounter an issue with the passive database and the seeding stops with the error “Mailbox Database Copy Failed or Suspended.” After investigation, you would find the following message in the event viewer.
MSExchangeRepl Event ID: 4113
Database redundancy health check failed. Database copy: DB01 Redundancy count:1
Error: Passive copy ‘DB01\EX02’ is not in a good state. Status: FailedAndSuspended
To start the troubleshooting, you must first get the status of the copy from the Exchange Management Shell (EMS) by using the PowerShell cmdlet - Get-MailboxDatabaseCopyStatus.
To understand the root cause of the issue, you can use the Exchange Best Practice Analyzer against the servers. From the Exchange Management Shell (EMS), run the Test-ServiceHealth and Test-ReplicationHealth. This will give the information that all the services needed are running. Of course, you can also run a self-check on the Exchange Servers.
Let’s try to repair the database by suspending the copy between the active and passive database. This can be done by using the Suspend-MailboxDatabaseCopy.
Suspend-MailboxDatabaseCopy –Identity "DB01\EX01"
Here is where you can investigate the matter. You need to re-seed the database. To start off, you need to clear off any copies of the database. You can use the PowerShell cmdlet Update-MailboxDatabaseCopy with the -DeleteExistingFiles to clean the setup and delete the copies. An example of the command is given below:
Update-MailboxDatabaseCopy -Identity "DB01\EX01" -DeleteExistingFiles
This will re-seed the database from the active to the passive copy.
Some things to consider before running the re-seed process:
- Depending on the size of the database, performance of the servers, and network speed between the nodes, the process may take a considerable amount of time.
- If you have more than two servers, the PowerShell command will take the active copy of the database. You cannot choose from where you re-seed the copy.
- There will be a difference in size between the active and passive copy, since the copy will have the size of the database along with additional transaction log file and content index.
Alternatively, you can re-seed the database using the Exchange Admin Center (EAC).
For this,
- Click on the Server section and on the Database node.
- Select the database which is to be updated and click the Update button to start the reseeding process.
- Select the Source of the active database and the destination.
Conclusion
The above process can help you in clearing off the “Mailbox database copy failed and suspended” error. But what to do if the problem re-occurs again? What happens if the active copy is damaged and you need to retrieve the data from the copy? Or what happens if the active and passive copies are both damaged?
You can rely upon a third-party Exchange database recovery tool that can get you out of such sticky situations. Stellar Repair for Exchange is one such application that can open any type of Exchange Database being healthy or not, retrieve the data to PST and other formats. You can also export directly to a new Exchange mailbox database or to an Office 365 tenant.
Rating by expert: Reference
6 min read
