Exchange 2010 introduced the concept of Mailbox Database Copies in the scenario of a Database Availability Group. A Mailboxy Database Copy is – as the name might give away – a second (or third, or fourth…) copy of a mailbox database. Mailbox Database Copies are kept up to date with the source database (which is the active copy of the database on one of the member servers participating in a DAG) via a process called transaction log shipping. In short: transaction logs are copied from the active mailbox database to the different copies where the transactions are also replayed into the database. This creates consistent database copies across different servers, which allows a database to be easily mounted on another server if the primary – active – copy would fail.
To get more information on Database Availability Groups and Mailbox Database Copies, check out the following link: http://technet.microsoft.com/en-us/library/dd979799.aspx
Transaction Log Shipping is done through a DAG’s replication network. However; sometimes a database copy can get out of sync with the source database. There are different reasons why this can happen, of which the following are amongst the most common causes:
- (Temporary) network interruption between source and target server
- Unavailability of the passive database copies files (e.g. storage issues/storage unavailability)
To verify the status of a mailbox database copy, run the Get-MailboxDatabaseCopyStatus cmdlet:
The output will provide you with some more information about the copy. As you can see from the example above, the database is in a “FailedAndSuspended”-state. This means that the copy of the database is out of sync and currently not replicating.
Before we can troubleshoot this error, we need to make sure that the cause of this issue is resolved. If it were are (temporary) glitch in the network we could update and resume the copy. However, if the root cause is still be present, we cannot to update the copy.
Let’s see an example of such an error:
In this example, the paths to the database(s) were unavailable due to a misconfiguration. As a result, the database could not be updated. After sorting that error out, storage was reconnected back to the server after which the different paths became once again available.
Next, I proceeded to update the Mailbox Database Copy, but was faced with the following error:
After re-running the cmdlet, but this time with the –DeleteExistingFiles parameter; reseeding started:
Once reseeding was completed, the database copy returned to a healthy state:
A word on content indexing issues
Sometimes it’s possible, that only the content indexing catalog is affected. Errors with the CI catalog are indicated with the following error when running the Get-MailboxDatabaseCopyStatus:
To troubleshoot content indexing issues, Microsoft has created a script called “Troubleshoot-CI.ps1” which can be found in the Exchange\Scripts folder.
The script detects and resolves the following problems with the CI catalog:
- Backlogs (corrupt indexes)
- Stalls (Indexes are not updated)
In order to run the tool, you add the –detectandresolve parameter.
Results for that cmdlet will be displayed in the Event Logs:
Sometimes you might be required to reseed the Content Indexing catalog, which you can do running the following cmdlet:
This cmdlet will update only the CI catalog and leave the database untouched. If you add the –DeleteExistingFiles parameter, the existing files will be deleted and overwritten. Adding the –SourceServer paramter allows you to indicate what server the CI catalog needs to be copied from.
If you need more information on Exchange Search (including content indexing), please have a look at the following address: http://technet.microsoft.com/en-us/library/bb232132.aspx
Michael Van Horenbeeck