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

In an Exchange environment, a database (EDB) may dismount due to damage to the database file caused by abrupt shutdown, system crash, virus or malware, etc. This could also occur after a routine patch cycle or a normal reboot. You can check the Exchange database mount status by using the PowerShell cmdlets via Exchange Management Shell (EMS) or Exchange Admin Center. When database is dismounted, the status is displayed as updating or dismounted.

Although you can mount the database by using the Mount-Database cmdlet in Exchange Management Shell (EMS) or Exchange Admin Center (EAC), you might come across a scenario where Exchange database does not mount. This is usually caused by problem with the storage device.

In this guide, we’ve discussed some workarounds to fix this issue. In addition, you’ll get to know about a third-party Exchange recovery tool that can help you to recover mailboxes from such a database to a new database on your live Exchange server.

How to Mount Exchange Database?

Before mounting the database, you must check the status of mailbox database by using the following command,

Eseutil /mh

Then try to manually mount the Exchange database. Most probably, it will mount if the database is in Clean Shutdown state. However, in some cases, you are presented with a very long error message and the command just seems to hang when it is run. The Exchange database copies index state is displayed as “Failed” as well and it logs an event ID of 1009. Here is a sample of the error:

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, the following command for Hard Recovery should not be run, unless the databases are in “Dirty Shutdown” state.

Eseutil /p

Only use this command if the Exchange database is completely corrupted. Do not use it unnecessarily or if you don’t want to lose data. Instead, you can use an Exchange recovery tool, such as Stellar Repair for Exchange.

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.

Steps to Resolve ‘Database won’t Mount, Shows Clean Shutdown’ Issue

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. 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 Exchange databases will not mount.

What needs to be done next is reboot the servers that are showing as offline and let them start up, and 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. 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 want to run the eseutil /p command, you will need to create a new mailbox database and perform mailbox moves as that Exchange 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 run the following command from the Exchange Management Shell:

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

If that fails, then the following command will need to be run to update the copies by deleting existing files and letting it re-seed the database copy. It is to be noted that 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 Mailbox Exchange Recovery tool.

This tool allows you to open the .EDB file that will not mount in Exchange and lets you export it to .PST file or directly to Exchange or Office 365. You need a licensed copy of Mailbox Exchange Recovery to take full advantage of this software.

Conclusion

When Exchange database does not mount even if it’s in clean state, it could be due to problem with storage media or database file. In such cases, you can’t attempt Hard Recovery as database is already in clean state. To resolve such issues, you need to go through a series of steps to troubleshoot the problem. However, you may use a third-party Exchange recovery tool, such as Stellar Repair for Exchange to extract and import the mailboxes from such database into a new database file on Exchange server directly.

It features a graphical user interface that makes mailbox export quick, easy, and convenient. It saves time and restores mailbox connectivity.