Summary: Sometimes, even when the database is in Clean Shutdown, the Mount_Database cmdlet or the EAC may fail to mount the database on the server. In such a critical situation, you need to check if there are any storage-related or indexing issues and when the database has some other problem. In this guide, we will help you troubleshoot and resolve the problem that prevents the database from mounting even if the database is clean.
Contents
In an Exchange environment, a database (EDB) may dismount due to inconsistency caused by uncommitted transaction logs or damage to the database file caused by the abrupt shutdown, system crash, virus or malware intrusion, etc.
A mailbox database may also dismount after a routine patch cycle or a normal reboot. You can check the Exchange database mount status using the Get-MailboxDatabase PowerShell cmdlet with –Status parameter via Exchange Management Shell (EMS) or Exchange Admin Center (EAC).
When the database is dismounted, the Mounted status is displayed as False in the EMS output. In EAC, the status displayed is either updating or dismounted.
In such cases, you should first check the database state, i.e., whether the database is in a Clean or Dirty Shutdown state. If the database is in a Dirty Shutdown state, you must recover the database using EseUtil commands to Clean Shutdown state and then mount the database back on the server using the EAC or Mount-Database cmdlet in the EMS.
However, if the database is in a Clean Shutdown state but still does not mount, this could be due to storage device issues or other underlying problems with the Microsoft Exchange Services.
In this guide, we’ve discussed solutions with stepwise instructions to help you resolve the issues and mount the database on the server.
A database with a Clean Shutdown state can be easily mounted using the Mount-Database cmdlet or EAC. However, in some cases, you may encounter a very long error message, and the Mount-Database command seems to hang when it is run.
Also, the Exchange database copies index state is displayed as “Failed,” and it logs an event ID of 1009. The error may look like this:
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)
You also notice multiple 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.
Follow these steps to troubleshoot and fix the problem and prevent a database from mounting even though it’s in a Clean Shutdown state.
In many cases, the low storage on the drive where the database is stored dismounts the database and prevents it from mounting again, even if it’s in a clean shutdown state. Therefore, you must ensure that the drive where the database is located has 25-30% free storage space available to avoid such issues and mount the database successfully without errors.
TIP: Transaction Logs can grow quickly and eat up the storage space. This usually leads to such issues if the logs and database are stored on the same drive. To prevent logs from eating up entire storage, perform regular VSS backups using the Windows Server Backup service. This will create a backup and automatically purge the logs, which will help you conserve storage. It’s also the safest way to purge transaction logs. Do not enable Circular Logging to purge logs.
Check the Database Availability Group (DAG) by opening Failover Cluster Manager on the server. We will not be making any changes but just checking if the Cluster is in a healthy state.
Once it is 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.
Expand your DAG name from the failover cluster manager and view the members. You will see if they are all in a healthy state. In this case, more than one member of the DAG was showing as offline, resulting in quorum loss, so the Exchange databases will not mount.
Next, reboot the servers showing as offline and let them start up. Also, keep an eye on the server’s health in the failover cluster manager. Once it comes online, give it a few minutes to settle down and reboot the next server.
Once you have done all the reboots, the members 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 is no longer in a healthy state.
The final step is to restore the database copies index state 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 Exchange database copy. Note 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 recommend looking at a professional Mailbox Exchange Recovery tool.
Since the database is already in a Clean Shutdown state but not mounting, you may run the Hard Recovery to fix the database. However, it is not recommended to execute Hard Recovery on a database as it purges irrecoverable mailboxes and mail items that can lead to
data loss.
Instead, you can use an Exchange recovery tool, such as Stellar Repair for Exchange, to recover and restore all mailboxes from such damaged database to a new database on your Exchange Server with complete integrity.
This tool allows you to open the .edb file that will not mount in Exchange even if it’s in Clean Shutdown State or Dirty shutdown State and lets you export the mailboxes to .PST file. You can also export the recovered mailboxes from a repaired database directly to Exchange or Office 365.
When the Exchange database does not mount, even if it’s in a Clean Shutdown state, it could be due to a problem with storage media or database files. You can’t attempt Hard Recovery in such cases as the database is already in Clean State. In addition, you need to go through a series of steps to troubleshoot and resolve the problem.
You should use a third-party Exchange recovery tool such as Stellar Repair for Exchange to save time and effort and prevent data loss. The software can help extract and import the mailboxes from such a database into a new database file on the same Exchange Server directly. It features a graphical user interface that makes mailbox export quick, easy, and convenient. In addition, 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.