When a database dismounts from the Exchange server, it breaks the server-client connectivity. Users having their mailboxes in the dismounted database can’t connect to their mailboxes, access their email account, or send/receive new emails.
In such a critical situation, it’s important to mount the database to restore user mailboxes and email flow.
In Exchange Server, you can mount the database using the Exchange Admin Center (EAC) or Exchange Management Shell (EMS) cmdlets.
However, if you try mounting a dismounted database, there could be two scenarios—the database will either mount successfully or fail with an error, such as:
Couldn’t mount the database that you specified. Specified database: MBX-DB-2016; Error code: An Active Manager operation failed. Error: The database action failed. Error: Operation failed with message: MapiExceptionDatabaseError: Unable to mount database. (hr=0x80004005, ec=1108) Diagnostic context: Lid: 65256 Lid: 10722 StoreEc: 0x454 Lid: 1494 —- Remote Context Beg —- Lid: 45120 dwParam: 0x569817 Lid: 57728 dwParam: 0x56995F Lid: 46144 dwParam: 0x569A97 Lid: 34880 dwParam: 0x569A97 Lid: 34760 StoreEc: 0xFFFFFE0B Lid: 46144 dwParam: 0x56A13F Lid: 34880 dwParam: 0x56A13F Lid: 54472 StoreEc: 0x1388 Lid: 42184 StoreEc: 0x454 Lid: 1750 —- Remote Context End —- Lid: 1047 StoreEc: 0x454 [Database: MBX-DB-2016, Server: mail.abc.com]
Reasons for Unable to Mount Database (hr=0x80004005, ec=1108) Error
An Exchange database may fail to mount due to several reasons as discussed below:
Reason 1: You cannot mount a database when the storage space on the drive where database and log files are stored is running low. Low disk space is also one of the main reasons behind database dismount and corruption.
Reason 2: Exchange services, such as Microsoft Exchange Information Store and Microsoft Exchange Replication, are required to mount a database in Exchange Server. If these services are not running or stopped, the database mount will fail and may result in “Unable to Mount Database (hr=0x80004005, ec=1108” or similar error.
Reason 3: There could be third-party software such as antivirus solutions which might find databases or files suspicious or could just lock the files. We need to be very careful when having an antivirus solution in our Exchange Server as misconfiguration or incompatible software may lead to such issues. Adding to this, disk performance or I/O degradation could lead to slowness and possible corruption of data. In this case and to release any locks, it would be suggested to first disable the antivirus (as a test) or just exclude the drive where the databases are located and restart the server.
Reason 4: Deleted or missing log files is one of the most common reasons behind a dismounted database in Exchange Server. Exchange Server records all changes or updates (transactions) in log files before updating the database.
If the logs go missing or deleted before the changes in the log are committed to the database, it may become inconsistent (Dirty Shutdown) and dismount. Such a database could not be mounted unless the logs are committed to the database or the database is in a Clean Shutdown state. If you try force mount, it may result in a failed attempt with an error message.
You cannot mount an Exchange mailbox database (.EDB) when it’s corrupt or damaged. To mount such a database, you must repair it by using the EseUtil or an Exchange recovery software, such as Stellar Repair for Exchange, to restore the user mailboxes and connectivity.
Steps to Fix Unable to Mount Database (hr=0x80004005, ec=1108) Error
To fix the Unable to Mount Database (hr=0x80004005, ec=1108) error in Exchange Server, you can follow these solutions in the given order.
Step 1: Backup the Database
Create a backup copy of the database along with transaction logs. This step is critical to avoid permanent data loss while fixing the causes behind the Unable to Mount Database (hr=0x80004005, ec=1108) error.
Step 2: Check Storage
Check the storage media where the database and transaction logs are stored. The drive should have at least 25% free storage to store more logs and changes to the database. However, if the storage is low, you can perform any of the following actions to resolve the unable to mount the database (hr=0x80004005, ec=1108) and mount the database.
- You can replace the storage media with a higher capacity drive.
- Make space in the storage drive by moving some data to another drive or volume.
Once you have enough free space, try mounting the database using the Mount-Database cmdlet in the Exchange Management Shell.
Mount-Database –Identity <DatabaseName>
If this fails, you may use the –AcceptDataLoss parameter to mount the database by removing uncommitted items or changes from the database. This can lead to missing mail items or mailboxes. Use the parameter only when you have created a database backup and at your own risk.
Mount-Database –Identity <DatabaseName> -AcceptDataLoss
Then check the status, using the following command
Get-MailboxDatabase -status | ft name,server,mounted
Step 3: Restart Exchange Services
If the database didn’t mount, follow these steps to start or restart the required Microsoft Exchange Services.
- Press Windows+R, type services.msc, and press the Enter key or click OK.
- Right-click on the Microsoft Exchange Information Store service and click Start or Restart. This will take a few seconds to finish.
- Similarly, right-click on the Microsoft Exchange Replication service and click Start or Restart.
Once these services are started/restarted, try mounting the database using the Mount-Database cmdlet. You may also use Exchange Admin Center to mount the database.
However, if the error ‘Unable to Mount Database (hr=0x80004005, ec=1108)’ persists, you may need to check Exchange database health and repair or recover as discussed in the next steps.
Step 4: Check Database State
To check the database status, you can use the EseUtil —a built-in command-line tool to check, recover, and defrag Exchange database. You can use the following EseUtil command in the elevated Command Prompt window or EMS to check the database state.
EseUtil /mh <DatabasePath/Databasename.edb>
For instance,
Eseutil /mh 'C:\Program Files\Microsoft\Exchange Server\V15\Mailbox\MBXDB02\MBXDB02.edb'
If the output displays the database state as Dirty Shutdown, it indicates the database is either inconsistent due to uncommitted logs or corrupt. In such a case, you must recover or repair the database to bring it to a Clean Shutdown state.
Step 5: Repair Exchange Database
To recover or repair a corrupt, damaged, or inconsistent database and mount it without encountering the Unable to Mount Database (hr=0x80004005, ec=1108) error, you can use the EseUtil to perform Soft Recovery or Hard Recovery.
In Soft Recovery, the uncommitted transaction logs are replayed on the database to bring it to a consistent state (Clean Shutdown state). Hard Recovery is required when the logs are missing/deleted. However, hard recovery is an invasive process that recovers the database by removing the irrecoverable mailboxes or items. Instead of hard recovery, we recommend you to use Exchange recovery software to restore user mailboxes from the corrupt database to a healthy database on your Exchange Server.
Below we have discussed these in detail.
Steps to EseUtil Soft Recovery
First, you need to run the below command to verify the logs required for soft recovery.
eseutil /ml <Log path location>
Once you have verified the logs and no damaged logs are found, you can perform soft recovery (EseUtil /r) by executing the following command. The log usually begins with E00, E01, or E02, etc.
This will start the process of recovery. Depending on the size and damage to the database, the process will take some time. Once it’s finished, you need to re-run Eseutil /mh command to check the database state. If the recovery was successful, the database state should be Clean Shutdown.
Once the database is in a clean shutdown state, it can be easily mounted to the Exchange Server using the Mount-Database cmdlet in EMS or Exchange Admin Center.
However, if the Dirty Shutdown state persists, you have two options:
- Restore the server from backup and lose all the data between the last backup.
- Perform a hard recovery process.
Again, if you perform a hard recovery, you need to accept the data loss as the process purges the damaged data, irrelevant of the amount. On the other hand, after you perform this process, Microsoft will not assist. This is because when a database is recovered with the hard recovery, it will hard code some information. When Microsoft notices this, it will refuse to provide support.
To perform the hard recovery, run the below command:
Eseutil /P <Database file location full path>
Once executed, you will be warned of data loss and need to accept it before proceeding. This recovery must be used as a last resort.
Once done, you will get a screen like the one below.
You will need to run the EseUtil /MH command to see if the database state is healthy (Clean Shutdown). If the database is healthy, you should be able to mount the database and fix the ‘Unable to Mount Database (hr=0x80004005, ec=1108)’ error.
If there is the case of DAG, to reduce the chance of issues or total stop to the business while acting as a load balancing of mailboxes, it is suggested to split the mailboxes and into multiple Exchange Server database. In the Standard version of Exchange Server, you can create up to 5 mailbox databases, while in the Enterprise version, there is no limit. When splitting the data, if there is a fault or issue with a particular database, it will not affect the entire business.
If the issues are not fixed then check following points as well-
- Try moving the checkpoint and logs to a temporary location and mount database to see whether it works.
- If you have a recent, good backup, restore it to a different server and migrate mailboxes to a new DB and delete problematic database
- Make sure to update BIOS, firmware and drivers for the hardware components.
- Update Windows server with the latest patches.
- Update Exchange server to the supported CU.
To Conclude
The above manual solution will take considerable time without knowing if it will successfully resolve the issue. It is also advised not to perform hard recovery as it will lead to irreversible data loss and hard code the database, voiding you from receiving any support from Microsoft. Fortunately, there is an easy solution available. You can use one of the Best Exchange Recovery Software – Stellar Repair for Exchange, to restore user mailboxes.
All you need to do is create a new database on your Exchange Server. Then repair the damaged database and export the mailboxes to the new database on your server directly using the Stellar Repair for Exchange with complete integrity. This solution allows you to restore the service in time, with no complex recovery processes. In addition, you may also save these mailboxes as individual PST files or export them to Office 365 tenant.
FAQ
How much free space is required on the database disk and on the log disk?
The best is to have half of the database size as free space in the database disk and about 60% of the drive in the database logs disk free taking in consideration that the backup is taken on a daily basis.In what case we can enable the circular logging?
One should only enable circular logging as a last resort if the transaction log location is full. This will cause problems when it comes to restore data from transaction logs. It’s important to use it in case of emergencies only.
Was this article helpful?
