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

Exchange database (.edb) fails to mount is a fairly common problem that usually occurs when the disk storing the logs or the database file runs out of storage or has no storage left. An Exchange database may also dismount from the server due to several other reasons, such as abrupt shutdown, power failure, storage media errors, etc.

However, you can mount the database back on the server by using the Exchange Admin Center (EAC) or PowerShell commands in Exchange Management Shell (EMS) after making the required changes, such as freeing up the storage by cleaning the database white space or moving data to another volume.

But sometimes, you may fail to mount the database and encounter the following error message:

'Unable to mount database (hr=0x80004005, ec=-528).
Microsoft Exchange Error
Failed to mount database 'EXDB01'.
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:].
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:]
An Active Manager operation failed. Error Operation failed with message: MapiExceptionJetErrorMissingLogFile: Unable to mount database. (hr=0x80004005, ec=-528)
. [Server:]
MapiExceptionJetErrorMissingLogFile: Unable to mount database. (hr=0x80004005, ec=-528)

Reasons for ‘'Unable to mount database (hr=0x80004005, ec=-528) error.?

The error message 'Unable to mount database' indicates that the Exchange Server cannot mount the database. This may occur due to some missing or uncommitted transaction logs. Transaction logs are an essential part of a healthy database. These are not just log files of what's happening in the database. Exchange Server works on write-ahead logging or WAL concept where it uses transaction logs to keep temporary and unprocessed data, before committing to the in-memory copy of the mailbox database with these logs.

If there are uncommitted or missing log files, this will cause performance or functional issues on your Exchange Server, leading to database inconsistency. As a result, the database dismounts and prevents the server from mounting the database.

Reasons for Failed to mount database An Active Manager operation failed error:

  • The Exchange database (.edb) you are trying to mount is either corrupt or inconsistent.
  • The server has little or no disk space to complete the database mount. Thus, it can’t store new logs or provide space for database expansion.
  • Missing or deleted transaction logs.
  • Dirty Shutdown.
  • Server is not updated with latest SU.
  • The upgrade is failing with mounting error.
  • This error might also appear if some other process had the Exx.log open at the same time as when Exchange was trying to open it. It's one of the reasons why you configure your anti virus to not look at the log or database directories. You might have to restore the log files you deleted to mount. 

Solutions to Resolve 'Unable to mount database (hr=0x80004005, ec=-528) error

Below we have discussed some manual methods to troubleshoot and resolve the 'Unable to mount database (hr=0x80004005, ec=-528).. However, it is important to note here that these methods require additional roles, permissions, and more time and effort. Moreover, it's not necessary that these methods will work or restore the database. Most importantly, there's always a risk of data loss. We have mentioned the risks involved for your knowledge to help you analyze and decide whether to proceed with the methods or not.

Restore from Backup

This option is one way of resolving the issue. This would involve restoring either the entire server (if there is only one database) from backup, or by restoring the database using Recovery Database.

Restoring the database from the last healthy backup means that any changes from that time till the server failed to mount the database, will be lost. If the last server backup was 24 hours ago, then all the new emails, tasks, sent emails, public folder changes, mailboxes, or any other changes, will be lost.

One needs to factor in that using a recovery database, would require more administration effort and resources in storage and time.

Use EseUtil

To resolve the 'Unable to mount database (hr=0x80004005, ec=-528 error, you can use the EseUtil utility, which is a native tool of the Exchange Server. This command line-based tool will give you an insight into the database to help you take appropriate action and fix the unable to mount database issue.

Step 1: Check the Database State

First, check the status of the Exchange database by running the following command in the Command Prompt or Exchange Management Shell (EMS) as administrator.

eseutil /mh 

path to="" database="" /path

For instance,

eseutil /mh M:\ExchangeDatabases\EXDB01

Check the output and look for the database state. If the state is displayed as Clean Shutdown, move the checkpoint file along with the log files outside the database folder and try to mount the database again.

However, if the database state is shown as Dirty Shutdown, your database is either corrupt or inconsistent. Continue following the next steps to recover the database to the Clean Shutdown state.

The command output also displays which logs are missing or uncommitted.

Caution: It is strongly suggested to make a copy of the database, along with its respective files, before continuing with the recovery process to avoid permanent data loss.

Step 2: Perform Soft Recovery

You can perform Soft Recovery on the database, if there is minor damage or some uncommitted logs files. For this, run the following command.

eseutil /r E04 /l M:\ExchangeDatabases\logs /d M:\ExchangeDatabases\EXDB01

The E04 in the command is the log prefix and represents the missing log file. You can get this information from the output of the eseutil /mh results. Note down the line saying the log file required, as given below.

Log Required: 4-4 (0x4-0x4)

Once the command is executed, check the database status again using the eseutil /MH parameter. If the database is recovered, the state goes back to the Clean Shutdown. If it does, you can try to mount the database again using the EAC or the Mount-Database cmdlet in the Exchange Management Shell.

However, if Soft Recovery fails and the database still shows as Dirty Shutdown, the only manual solution would be to run Hard Recovery by using the eseutil /P parameter. But before running Hard Recovery process, it's important to note the risks involved:

The process will purge any corrupted or irrecoverable mailbox or mail items and data from the database. This can lead to significant data loss. When you run Hard Recovery, you will see a prompt to accept the risk of data loss from the database.

  • During this process, the database will not be accessible to the users.
  • In the case of Exchange Server 2013 or later, you also need to run the database defragmentation process by using the PowerShell cmdlet New-MailboxRepairRequest. 
  • Once the Hard Recovery is started, you will not be able to stop the process. You must wait for the process to complete and then mount the database.

Note: It's not guaranteed that ESEUtil will fix your database.

If recovery is successful, move the mailboxes from the recovered database to a new healthy database. This will require more time and lead to further downtime. However, it is critical as the recovered database has more chances of failure in near future.

  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

Things to Remember while using the Native Tools to Recover the Database that Fails to Mount

  • The restoration process with native tools will take a considerable amount of time, depending on the size of the database and available resources.
  • Require lot of time and administrative effort.
  • Involves downtime as the database remains unavailable until the recovery is complete and the database is mounted.
  • If you ask for Microsoft support after you have tried to repair the database with EseUtil Hard Recovery, you will not get the support as the database will be hard code marked.
  • Recovery is not guaranteed.
  • Users will not be able to access the data while the Exchange Admins are running the restore process.

Use Exchange Recovery Software to fix 'Unable to mount database (hr=0x80004005, ec=-528)

Fortunately, there is a reliable and advanced Exchange recovery tool, called Stellar Repair for Exchange that can help overcome the challenges associated with manual methods. It can help you quickly repair severely damaged or corrupt Exchange databases without log files or additional permissions. There’s no risk of data loss as the tool repairs and extracts the mailboxes and mail items from the damaged database to PST files with complete integrity.

Stellar Repair for Exchange also allows you to export the recovered mailboxes from the damaged database (that fails to mount) directly to a new database on your 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 and restores the user mailboxes in a few clicks most efficiently and reliably.  


When the Exchange database dismounts, it can disconnect Outlook and prevent users from sending or receiving new emails. In such cases, you should immediately mount the database. However, if the database fails to mount or you encounter an 'Unable to mount database (hr=0x80004005, ec=-528) error , check the database state using EseUtil. If it shows Dirty Shutdown state, you must perform recovery to bring it to Clean Shutdown or mountable state.

For this, you have two options. You can either perform Soft Recovery or Hard Recovery. Although Soft Recovery is safe, running Hard Recovery on the database that fails to mount can have severe consequences. It can lead to data loss and hardcode the database. Microsoft does not provide support once the database is hardcoded. With so many risks and challenges involved, it would be wise to use a more efficient and quicker solution, such as Stellar Repair for Exchange. The Exchange recovery software can repair even severely corrupt databases, extract mailboxes, and save them to PST format or export directly to your live Exchange Server or Office 365 tenant.

Was this article helpful?
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 Choose Stellar?
  • 0M+


  • 0+

    Years of Excellence

  • 0+

    R&D Engineers

  • 0+


  • 0+


  • 0+

    Awards Received