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.
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.
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:
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.
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.
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.
Experienced Messaging Specialist with a demonstrated history of working in the information technology and services industry. Skilled in WSUS, Domain Name System (DNS), Data Center, Printer Support, and System Center Configuration Manager (SCCM). Strong information technology professional with a International Diploma in Programming focused in Computer Programming from CTI.
It is observed that in most cases ESEUTIL fails to perform these operations. So, I used Stellar Mailbox Exchange Recovery software to get rid of this problem. Through this I can easily access EDB files into Exchange.
Great!
We always here for making customer’s journey hassle free.
Hello Erick,
This command (eseutil /ml) helped me to explore and verify the presence of all logs in the same directory.
Then, I did successful mounting Exchange database in following steps:
1.Removed all checkpoints
2.Executed eseutil /r
I can say that your tutorial encourage me to do all things without any fear.
THANK You!
Your success will encourage other users to perform this operation with confidence.
I have tried updating my copy from Exchange Administrator centre as well as running the command Update-Mailboxdatabasecopy on Eseutil but it failed again.
I think the corruption is far too severe since I’ve spent quite a lot of time on fixing this but it still doesn’t show any good sign.
How can I ensure that Stellar’s Mailbox Recovery software will be able to recover the unmountable mailboxes?
Hi Boris,
For 100% transparency, I suggest going for a demo version of this one tool. Then, you would be able to take a right decision for your organization.