For Exchange server users to access their mailboxes, the Exchange database must be mounted on the server. If the database is dismounted from the server, it is mounted using EAC or Mount-Database cmdlet.
However, there may be instances when the above two methods fail to mount the database back on the server. In this case, you will face error messages in EAC or while running the Mount-Database command on EMS.
This problem occurs due to the following reasons:
- Exchange services have stopped
- There is an insufficient disk space on the server due to log files
- The database you are trying to mount may be corrupted.
Let us look at some troubleshooting methods to resolve the ‘Fail to Mount Exchange Server Database’ issue.
Methods to resolve the ‘Fail to Mount Exchange Server Database’ Issue
To resolve the issue with the database that is failing to mount on the server, follow the methods described below:
Note: Before using any of the methods mentioned below, check the edition of your Exchange server. If it is in Standard edition, you can have up to 5 mounted databases. With the Enterprise edition, you can have up to 100 mounted databases on the server.
Method 1- Check and Restart Exchange Services
For proper functioning of the Exchange Server, all the services must be in the Running state. If any of the Exchange services are stopped, then you may face issues and errors when you try to mount the database on the server. So, check and ensure that all the Exchange services are running. To do so, follow these steps:
- Open the Server Manager. Click on Tools and select Services from the list.
2. On the Services screen, check that all services of the Exchange Server are running. Make sure that any service, which has the Startup Type set to Automatic, is started.
3. If the status of any service(s) is Stopped, right-click on it, and select Start.
Alternatively, you can use the following PowerShell cmdlet to restart all the Exchange services:
Get-Service *Exchange* | Where {$_.DisplayName -notlike “*Hyper-V*”} | Restart-Service –Force
4. Recheck the Services to confirm if all the services have the Status as Running.
Once all the services are running, Mount the database on the server again. If the issue persists, use the following method.
Method 2- Backup the server and truncate the log files
In Microsoft Exchange server, transaction logs are used to record all the activities on the server. Once you take a backup of the entire server, the log files up to the time of backup are truncated.
If the backup application that you are using to create backups , is not consistent with your server, the backup will not be created. This will cause the log files will accumulate and increase the disk space. If the disk space runs out, the server cannot write new logs, leading to potential data loss and inconsistency. This causes the database to dismount from the server.
The solution is to use a backup software or tool that is consistent with your server. You can verify the compatibility of the application and the server by your vendor. You can also use Windows Server Backup, as Microsoft recommends it for server backups. Once you have a backup of your server, you can delete the old log files to free up the disk space.
Mount the database on the server, If you are still facing the issue, use the next method.
Method 3- Repairing the Corrupt Database
If you cannot mount the database on the server after using both of the above mentioned methods, it is possible that the database that you are trying to mount is inconsistent or corrupted. You have to repair the database to make it consistent before mounting it on the server.
To repair the database, first check the state of the database. Use the eseutil /mh cmdlet on the EMS to check the status of the database. Use the following syntax:
eseutil /MH <edb file path>
If the database State is Clean Shutdown, mount the database using Mount-Database cmdlet. However, if the State is Dirty Shutdown. Check the Log Required field in the output of the /mh command to see which log files are missing. Repair the database using either EseUtil recovery methods or use third-party recovery software.
The drawback of using eseutil is that the Hard Recovery process causes permanent data loss by truncating the inconsistent log files and restoring the database to a consistent state. Additionally, after hard recovery, the database becomes hard coded and it is recommended to move all the mailboxes in the database to another database.
To avoid the risk of data loss use Stellar Repair for Exchange. The software first scans and extracts data from the corrupt EDB file, and then saves its data in various formats such as PST, MSG, EML, RTF, PDF, or HTML. The data can also be directly exported to, Live Exchange, or Office 365. The software does not make any changes to the original data. After scanning the EDB file, the software shows a preview of the original data.
Conclusion
The Exchange database may dismount from the server due to reasons like, stopped Exchange services, insufficient disk space or database corruption. However these issues can be resolved by starting the exchange services, freeing up the disk space or by repairing the corrupted database.
To repair the database corruption, you can use EseUtil’s recovery process. You can use soft recovery to roll back the transactional log file and commit all the uncommitted changes. Otherwise, you can use hard recovery to truncate the inconsistent log files and make the database consistent.
However, using the hard recovery process results in data loss as it purges the log files. It is recommend to use third party exchange recovery software like Stellar Repair for Exchange to extract data from EDB files of severely corrupted databases and save it in various formats such as PST, MSG, EML, RTF, PDF, or HTML.