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'.
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)
Why is Exchange Server ‘Unable to Mount the Database’?
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.
Such a situation may also arise due to one or more of the following reasons:
- 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.
Solutions to Resolve Exchange Database Fails to Mount Issue
Below we have discussed some manual methods to troubleshoot and resolve the unable to mount database issue. 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.
Use EseUtil
To resolve the issue, 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.
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
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.
Conclusion
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 the database’ 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.
