Is your Exchange database as in a ‘Clean Shutdown’ state? But it is not mounting?

In your exchange environment, you might come across a scenario where a database does not mount. This could be after a routine patch cycle or a normal reboot. If you had to launch the Exchange Admin Center you are presented with the status of “Updating”. If you launch the Exchange Management shell (EMS), it shows the databases as dismounted.

Quick overview:

• Checking the status of the DAG
• Running eseutil to check if the databases are in a healthy state
• Checking Failover Cluster Manager
• Update the content index
• Use Stellar Phoenix Exchange Recovery to export the data from all mailboxes

You can check the above by running the following command:

• Get-Mailboxdatabasecopystatus *

You then try to manually mount the databases and you are presented with a very long error message and the command just seems to hang when it is run.

The next step is to check the shutdown status of the databases. From within the same Exchange Management Shell you have to run the following command to check the status of the Databases, remember the below command needs to be run from an Elevated EMS:

• eseutil /mh

Once the command ran it shows all databases are in a “clean shutdown“ state, but then why won’t the Exchange databases mount?

The exchange database copies index state is showing as “Failed” as well and it logs an event ID of 1009. Here is a sample of the error below:

The indexing of mailbox database <database name> encountered an unexpected exception. Error details: Microsoft.Exchange.Search.Core.Abstraction.OperationFailedException: The component operation has failed. —> Microsoft.Exchange.Search.Core.Abstraction.ComponentFailedPermanentException: Failed to read notifications, MDB: 6ef27c68-8839-4397-8f0f-64420c2f788e. —> Microsoft.Mapi.MapiExceptionMdbOffline: MapiExceptionMdbOffline: Unable to read events. (hr=0x80004005, ec=1142)

At this point running the following command below should not be run unless the databases are in a “Dirty Shutdown” state:

• eseutil /p

Only use this command if the Exchange database is completely corrupted.

The reason for this is that you could potentially have some level of data loss.

You also notice the errors logged in event viewer in the application log regarding the databases and their respective copies:

<database name1>, <database name2>

<database name1>- There were database redundancy check failures for database ‘<database name1>’ that may be lowering its redundancy and putting the database at risk of data loss. Redundancy Count: 1. Expected Redundancy Count: 2. Detailed error(s):

<Exchange Server>:
Database ‘<database name1>’ does not have enough copies configured to meet the validation criteria.

<database name2>- There were database redundancy check failures for database ‘<database name2>’ that may be lowering its redundancy and putting the database at risk of data loss. Redundancy Count: 1. Expected Redundancy Count: 2. Detailed error(s):

<Exchange Server>:
Database ‘<database name2>’ does not have enough copies configured to meet the validation criteria.

Database redundancy health check failed.
Database copy: <database name1>
Redundancy count: 1

Error: There were database redundancy check failures for database ‘<database name1>’ that may be lowering its redundancy and putting the database at risk of data loss. Redundancy Count: 1. Expected Redundancy Count: 2. Detailed error(s):

<Exchange Server>:
Database ‘<database name1>’ does not have enough copies configured to meet the validation criteria.

The next step would be to start looking at the Database availability group (DAG) itself. This can be done by opening Failover Cluster Manager on the Server. We are not going to be making any changes but just checking if the Cluster is in a healthy state.

Once you have it opened, you can view the event logs for the cluster and if you look next to the cluster name you will notice a red X if there are any errors.

From within failover cluster manager, expand your DAG name and view the members, you will see if they are all in a healthy state. In this case, more than 1 member of the DAG was showing as offline which would result in quorum loss so the databases will not mount.

What needs to happen next is to reboot the servers that are showing as offline and let them start up, keep an eye on the health of the server in failover cluster manager, once it comes online, give it a few minutes to settle down and then reboot the next server.

Once you have done with all the reboots, the members that were showing offline should be online now and if you go back to the Exchange Management Shell and check the DAG copy status you should notice that the databases should now show as mounted.

If you ran the eseutil /p command, you will need to create a new mailbox database and perform mailbox moves as that database now is not in a healthy state.

The final step is to get the database copies index state back to a healthy state. You can try updating the copy from within the Exchange Admin Center or you can run the following from the Exchange Management Shell:

• Update-Mailboxdatabasecopy – “<Database Name>” -Catalogonly

If that fails, then the following command below will need to be run to update the copies by deleting existing files and letting it re-seed the database copy, take note this will take some time depending on the size of your Exchange database.

• Update-MailiboxDatabaseCopy “<Database-Name>” –DeleteExistingFiles

If the above still does not work for you, I would recommend looking at a professional tool provided by Stellar called Mailbox Exchange Recovery.

This tool allows you to do is open up the .EDB file that will not mount in Exchange and let you export it to .PST files or directly into Exchange again or even to Office 365. Do take note though that you need a licensed copy of Mailbox Exchange Recovery to take full advantage of this software.