How to Resolve ‘Exchange Database Fails to Mount’ Error?

An Exchange database gets dismounted from the server due to abrupt system shutdown, sudden power failure, server crash, and various other reasons. In such a situation, users with mailboxes in the dismounted database are not able to access their mailbox data and send or receive emails. This necessitates the need to mount the database on the server as soon as possible. However, when you try to mount the database, you face a problem where the Exchange database fails to mount and you receive an error message similar to the below:

'Unable to mount database (hr=0x80004005, ec=-528).

--------------------------------------------------------

Microsoft Exchange Error

--------------------------------------------------------

Failed to mount database 'EXDB01'.

EXDB01

Failed

Error:

Couldn't mount the database that you specified. Specified database: EXDB01; Error code: An Active Manager operation failed. Error The database action failed. Error: Operation failed with message: MapiExceptionJetErrorMissingLogFile: Unable to mount database. (hr=0x80004005, ec=-528)

. [Database: EXDB01, Server: mail.mycompany.com].

An Active Manager operation failed. Error The database action failed. Error: Operation failed with message: MapiExceptionJetErrorMissingLogFile: Unable to mount database. (hr=0x80004005, ec=-528)

. [Database: EXDB01, Server: mail.mycompany.com]

An Active Manager operation failed. Error Operation failed with message: MapiExceptionJetErrorMissingLogFile: Unable to mount database. (hr=0x80004005, ec=-528)

. [Server: mail.mycompany.com]

MapiExceptionJetErrorMissingLogFile: Unable to mount database. (hr=0x80004005, ec=-528)

There are various reasons why the Exchange database is not mounting. Let’s take a look at the possible reasons behind the Exchange database fails to mount issue and see how to resolve it.

Reasons for the Exchange Database Fails to Mount Issue

An Exchange database may fail to mount on the server due to different reasons, such as:

  • An Exchange database may fail to mount on the server due to different reasons, such as:

  • Some Exchange services are stopped
  • Log files are missing or corrupted
  • Insufficient storage space on the disk/drive where the database is stored
  • Conflicting antivirus or any other third-party application
  • Database file is corrupted
  • Backup software is not application-aware

Methods to Resolve Exchange Database Fails to Mount Issue

Here are some methods that can help you resolve the Exchange database fails to mount issue.  

Method 1: Check and Start the Exchange Services

It might happen that some Exchange Server services are not running that are causing the issue while mounting the database. So, you can check that if any services are stopped. If there are any, then start them to resolve the issue. Follow the steps mentioned below:

  • Open the Server Manager. Click on Tools and select Services from the list.

  • On the Services screen, check that all the services of Exchange Server are running. Make sure that any service, which has the Startup Type set to Automatic, is started.
  • 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

Once all the services are started, try to mount the database. If the issue persists, follow the next method.

Method 2: Check the Disk Space

If there is lack of storage space on the disk, then you may face issues while mounting the database. You can run the following PowerShell command to get information about all the drives:

Get-PSDrive –PSProvider FileSystem

The above command will list all the drives supported by Windows PowerShell File System provider, along with details related to free and used storage space. You can check the ‘Free’ space of the drive, where the database is stored. If the space is low, then try to free up the space by deleting unwanted data or add a disk with more storage capacity.

Method 3: Check if Backup and Antivirus Software are Application-aware

If the backup software is not compatible with the Exchange Server installed, it will result in incomplete or unhealthy backups. If the backup software is not taking the backup properly, then the log files will not be committed and get piled up, filling up the disk space. This will cause issues while mounting the database on the server. You can verify that the backup software is application-aware and compatible with your Exchange Server. You can use Windows Server Backup, recommended by Microsoft.

If your antivirus software is not application-aware, then it can cause problems in Exchange Server. So, make sure that your antivirus software is compatible with your Exchange Server. You can check this with the antivirus provider or vendor.

Method 4: Restore the Database from Backup

If the above methods fail to resolve the issue, then it means that the database or log files are corrupted. In such a case, you can restore the database from the latest healthy backup. However, restoring the database from backup means that any changes, from when the database is updated till the time when the issue has occurred, will be lost. For example, if the backup was last updated 24 hours ago, then all the emails, tasks, or any other changes, of an entire day will be lost.

Method 5: Repair the Exchange Database

If you don’t have an updated backup, then you can repair the corrupted database using the EseUtil commands. Here’s how to use the EseUtil commands to repair the database.

First, you need to use the EseUtil/ mh command (as given below) to check the state of database.

eseutil /mh ".edb"

If the database is in Dirty Shutdown state, you can perform Soft Recovery on the database. To perform Soft Recovery, run the following command:

eseutil /r E00 /l "C:\Path to log file" /d "C:\Path to database"
NOTE: Soft Recovery will work only if the log files are available. In case log files are missing, the process would fail.


Once the process is completed, check the database status again using the eseutil /mh command. If it shows the database state as Clean Shutdown, you can mount the database. However, if it still shows the database state as
Dirty Shutdown, then you can perform Hard Recovery by using the below command:

eseutil /mh ".edb"
  Case Study
bannerEseutil Failed? Worktrainers Ltd. Recovery from Critical Email Outages! - Explore the Full Journey

See how Worktrainers Ltd used Stellar Repair for Exchange

Read Case Study


If the database is in Dirty Shutdown state, you can perform Soft Recovery on the database. To perform Soft Recovery, run the following command:

eseutil /r E00 /l "C:\Path to log file" /d "C:\Path to database"
NOTE: : Soft Recovery will work only if the log files are available. In case log files are missing, the process would fail.


Once the process is completed, check the database status again using the eseutil /mh command. If it shows the database state as Clean Shutdown, you can mount the database. However, if it still shows the database state as Dirty Shutdown, then you can perform Hard Recovery by using the below command:

eseutil /p

It is to be noted that the hard recovery process can result in data loss as it purges any data that is deemed as corrupted. Additionally, Microsoft will not provide any support after hard recovery as the database will be hard coded. Furthermore, there is no guarantee that the process will work and recover the database.

Repair Corrupted Exchange Database without Data Loss

To avoid data loss and to quickly repair the corrupted Exchange Server database, it is recommend to use a third-party Exchange recovery tool, such as Stellar Repair for Exchange. It can help you to quickly repair damaged or corrupted Exchange database, even without a running Exchange Server. There’s no risk of data loss as the tool extracts all the mailboxes and other items from the corrupted database and save them to PST files with complete integrity.

Stellar Repair for Exchange also allows to export the recovered mailboxes from the damaged database (that fails to mount) directly to a new database on live Exchange Server or Office 365 tenant. It auto-maps the source and destination mailboxes and uses parallel processing for faster exports to the destination server. This not only helps you save significant time and effort but also reduces downtime. 

Conclusion

When the Exchange database gets dismounted, it can prevent users from sending or receiving new emails. In such cases, you should immediately mount the database. However, if the database fails to mount, then it indicates problem with the database. You can check the database state using the EseUtil /mh command. If it shows Dirty Shutdown state, you can perform recovery to bring it to Clean Shutdown or mountable state. For this, you can perform Soft Recovery or Hard Recovery. Although Soft Recovery is safe, performing Hard Recovery on the database can lead to data loss. To avoid such a risk, it would be wise to use a more efficient Exchange database repair tool, such as Stellar Repair for Exchange. This Exchange recovery software can repair even severely corrupt databases, extract mailboxes, and save them to PST format or export them directly to live Exchange Server or Office 365 tenant.



Was this article helpful?
FAQs
For sure one cannot just delete or move the logs manually. Logs are purged automatically after a healthy backup. Another process, one could move the transaction logs to a newer partition create or the newly added hard drive. The process of moving the transaction logs cannot be done manually. One should use the Move-DatabasePath command which dismount the database during the process. There might be folders still present in the previous location, one can simply delete them. If you get a warning on the folders, one should restart the Microsoft Exchange Host Controller service and the Microsoft Exchange Search service. Once this is done, one can run the Get-Mailbox and verify the LogFolderPath of the database.
Enabling Circular logging will prevent log file from filling up the storage and keeping them to a reasonable size. This can save disk space, but it will affect the recovery of data in case one should need to restore from backup. This should only use this feature as a last resort.
Yes, after a successful backup with an application aware and compatible backup solution, the transaction logs will be committed and automatically purged.
This is the error thrown when one would try to mount a database which state is set as Dirty Shutdown.
This error related to a database failing to mount due to lack of disk space or disk space is low on the location of the databases.
Like the error 1011, this is related to someone trying to mount a database with Dirty Shutdown state which means that either the database or log are corrupt.
This error is also related to data corruption of the database, or database transaction files.
This error is when an antivirus software installed on the server is locking the EDB file. This is due to misconfiguration or incompatibility from the antivirus software.
The Active Manger is responsible of managing the Exchange Server databases, and when a transient error is mentioned, it would be related to when a mailbox or mailboxes are moving from one database to another, or during a migration of data.
About The Author
author image
Ravi Singh linkdin Icon

Senior Writer at Stellar®. He is an expert Tech Explainer.

Table of Contents

WHY STELLAR® IS GLOBAL LEADER

Why Choose Stellar?
  • 0M+

    Customers

  • 0+

    Years of Excellence

  • 0+

    R&D Engineers

  • 0+

    Countries

  • 0+

    PARTNERS

  • 0+

    Awards Received