How to Resolve Exchange Database Clean Shutdown Won’t Mount Issue?
Summary: This write-up will guide the users and provide solutions if they are facing Exchange Database Clean Shutdown won’t mount issue. The following segment of the article explains the entire scenario in detail along with the reasons behind it.
In the Microsoft Exchange Environment, the IT administrator or Exchange users might encounter an issue where the Exchange mailbox database won’t mount. This can occur after a regular patch cycle or a normal boot. When the user checks the mount status of the mailbox via EAC or EMS, the status is displayed as Dismounted or Updating.
Although many users try using the Mount-Database cmdlet to mount the dismounted database, the associated issues with the mailbox don’t allow users to mount the database, hence providing an error message.
Thus, in the following section, we have discussed the solution in detail.
A Solution to Fix Exchange Database Won’t Mount Issue
Before directly mounting the database, it is important to first check the health of Exchange mailboxes. You can do this by running the below command:
Eseutil /mh Database_Name
If the mailbox is in a Clean Shutdown state, then you can try mounting the database again. However, if there is some issue with the mailbox, then you might encounter an error message as shown below:
Once you encounter this error message, the next step is to run hard recovery on Exchange mailboxes that won’t mount. This command will help you remove the corruption issues from the mailbox and get them back in a healthy state.
However, one of the major drawbacks of using this cmdlet is the chances of data loss that are associated with it. So, if you don’t want to compromise your data, then you must go with an advanced solution discussed below.
Eseutil /p
Users can also notice that the error occurred in the event viewer in the application log which is associated with the DB with its respective copies.
<database name0>, <database name01>
<database name0>: For this DB, there were database redundancy check failures which may increase the risk of data loss and lower its redundancy.
Redundancy counts are given below:
(i) Expected Redundancy Count
(ii) Detailed error(s)
<Exchange Server>
Database “<database name0>” doesn’t have enough copies configured to meet the validation criteria.
<database name01>: There was a redundancy check failure for this database i.e. “<database name01>” that might lower the redundancy and increases the risk of data loss.
See the Redundancy Count – (A) Expected Redundancy Count (B) Detailed Error(s)
<Exchange Server>
Database “<database name01>” doesn’t have enough copies to meet the validation criteria.
Exchange Database is in Clean Shutdown State but Won’t Mount – How to Fix
Now, the next step involves looking for the Database Availability Group (DAG). You can do this by opening the Failover Cluster Manager on the server. This is just to check if the Cluster is in a healthy state or not.
Once the window opens, it will show you all the cluster event logs. If there is an error in the cluster, then you will see a red X corresponding to the cluster.
When users proceed with the steps to solve the Exchange database clean shutdown won’t mount, you have to expand the Database Availability Group name in the failover cluster manager & view the member within it. It will help them to see that it is in a healthy state.
In this scenario, more than 1 member of DAG was showing offline because the database isn’t mounting. Then in the next task, reboot the server which is showing offline. During the reboot process, it is important to keep an eye on the server’s health. When it is online, then wait for some time and reboot the next server.
Now after all the rebooting is done, the offline members must be now in an online state. When you visit the Exchange Management Shell again and check the status of the Database Availability Group, the databases must be in a mounted state.
In the final step, users have to get the database copies index state to the healthy state. Then the copy is to be updated from the Exchange Admin Center (EAC) or you can run the following cmdlet in the Exchange Management Shell (EMS).
Update-Mailboxdatabasecopy – “<Name of database>” -Catalogonly
If this commands fails, then execute the cmdlet given below to update the copes by deleting the existing ones.
Update-MailoxDatabaseCopy”<Name of database>” -DeleteExistingFiles
Note: It is a time taking process because it depends on the size of the Exchange mailbox database
If the above solution does not work, it is recommended to use the advanced software provided in the below section.
When You Should Look for a Professional Solution
It is quite common for Exchange administrators to have health issues with Exchange databases. In such situations, the best option is to opt for advanced solutions like Exchange Mailbox Recovery Software by SysTools. This software is advanced enough to get rid of the corruption issues and export databases again in a healthy state.
So, if you are also experiencing any corruption issues in your Exchange DB files and want to fix those issues, then we will recommend you to give this solution a try. There is a free demo version of this utility that you can use to ensure the working of the application.
Once the database issues are fixed, you can either convert EDB files into PST format or directly import the DB into Exchange Server.
Bringing It All Together
If you are experiencing problems while mounting the Exchange database while it is in a clean shutdown state, then this write-up will help you get rid of the issue. Here, we have provided a detailed explanation of how to resolve this error at your end. Additionally, we have also pitched a professional solution that will help you repair EDB files in Exchange Server 2016, 2013, and 2010.