Fix: Unable to Mount Database HR0x80004005 EC1108 Error in Exchange Server

When the “Unable to Mount Database HR 0x80004005 EC1108” error occurs, the first approach is to check the database state by using the EeseUtil /mh command. If it is in Dirty Shutdown state, attempt a soft recovery (EseUtil /r). If this fails, proceed with the hard recovery (EseUtil/p). If you have a DAG setup, then suspend and resume the database copy or rebuild the passive copy from the active database. Follow this guide to know the stepwise process to perform these methods and fix the error.

What does the Error Unable to Mount Database (HR=0x80004005, ec=1108) Mean?

Let’s start by understanding the error message. It is related to database-level failure. This will have a critical impact on your Exchange Server since it prevents database from mounting. Due to this, the users will not be able to connect to their mailboxes. This issue can be caused by various reasons. Below are the most common ones:

• Corruption of the Exchange Server database.
• Missing or locked transaction log files.
• Abrupt shutdown of the database.
• Disk space issues on the server.
• A required service of the Exchange Server is not running.

This error can occur in Database Availability Group (DAG) setup and also in standalone Exchange Server 2010, 2013, 2016, 2019, and Subscription Edition (SE).

Identifying the issue

In a standalone server, the database not being able to mount with the said error indicates an issue with the database itself or the transaction logs. You can use the Eseutil /mh command to confirm the state of the database.

eseutil /mh <full path to the edb file including the file>

If you’ve a DAG setup, you can use the below command to check the database state.

Get-MailboxDatabaseCopyStatus

This command will give information related to the copy status of the database and its synchronization.

4 Methods to Fix the Unable to Mount Database (hr=0x80004005, ec=1108) Error in Exchange Server

Here are some methods you can follow to fix this database mount error.

Cause 1: Passive Copy Lost Contact with Active Manager

In a high availability (DAG) environment, when a passive copy loses connectivity with the Active Manager, it can disrupt the data and logs replication. As a consequence, the copy becomes inconsistent or out of sync. So, when you try to mount the database, you’ll receive the ec=1108 error.

In this case, you can suspend and resume the copy.

To suspend the database, run this command:

Suspend-MailboxDatabaseCopy-Identity "DB\Server"

To resume the database, execute this command:

Resume-MailboxDatabaseCopy-Identity "DB\Server"

Now, verify the database replication health by using the below command:

Get-MailboxDatabaseCopyStatus

Cause 2: Log Replay Failure on Passive Copy

This is the most common reason that can cause the ec=1108 error. When the passive database fails to replay the logs or falls behind in replication, it can cause issues with the database.

So, check the replication status by running the Get-MailboxDatabaseCopyStatus command. In the output, you can check the ReplayQueueLength values. This will help you identify the issues.

If any issue is found, use the below command to rebuild the passive copy from the active database.

Update-MailboxDatabaseCopy -Identity "DB\Server" -DeleteExistingFiles:$true

It is to be noted that Exchange database reseeding can take several hours depending on the size of the database and performance of the servers.

You can use the Get-MailboxDatabaseCopyStatus command (see the below example) to monitor the seeding progress.

Get-MailboxDatabaseCopyStatus -Identity "<DB\Server name>" | fl SeedingPercentage

Cause 3: Network Connectivity Issues between DAG Nodes

Network connectivity problems between the DAG nodes can disrupt the log shipping and replay process. This can also cause the fail to mount Exchange database error .In this situation, you can try the following troubleshooting steps:

• Use the Test-Connection command to test the connectivity between nodes.

Test-Connection <server name>

• Check MAPI/Replication network binding at the server and cluster level to ensure that all is working fine.
• Restart the Exchange Replication service and Information Store service by using the below commands.

Restart-Service MSExchangeRepl

Restart-Service MSExchangeIS

Cause 4: Active Database Copy Needs Failover

It might happen that there is an issue with the active database. In case the corruption or issues have not been replicated to the passive copy, you can simply set the passive copy as active. For this, move the active mailbox database by using the below command:

Move-ActiveMailboxDatabase-Identity “<DB Name>” -ActivateOnServer “<server name>”

Then, verify that the database has been mounted by executing this command:

Get-MailboxDatabaseCopyStatus

How to Verify that the Error is Fixed?

After applying the above fixes, you need to verify if the error is fixed or not. For this,

1. Check the Database State

You can check the state of database by using the ESEUtil /mh command.  If it shows the clean shutdown state, then you can mount the database.

To confirm if the database is in the clean shutdown state, you can use the command given below.

Get-MailboxDatabaseCopyStatus -Identity "<DB Name>" | fl *

In command output, you should confirm the Status and the ContentIndexState fields are showing the Healthy status.

2. Try to Mount the Database

You can use the Mount-Database “DatabaseName” command to mount the database. If it is successfully mounted, this means the error is resolved.

3. Check the Event Viewer

You can also check the Event Viewer for any errors related to database or Information Store.

What if the Error still Persists?

If the error still appears after applying the above solutions, then there might be serious issues with the database, possibly corruption. You can run the ESEUtil /mh command to see the database state. If it displays the dirty shutdown state, then you can run a smooth recovery on the database. Use the ESEUtil command as given below:

eseutil /r E00 /l <folder path of transaction logs> /d <folder path of database name>

This will replay the transaction logs and try to fix the issues. But if the transaction logs are missing or damaged, this will not work.

When the process is complete, again check the database state by running the ESEUtil /mh command. If is still is Dirty Shutdown state, you can perform the hard recovery by using the below command.

eseutil /p "<folder path of the database and database name>"

Note: Hard recovery is strongly not recommended since it just purges anything which is deemed corrupted, leading to data loss.

Another option is to restore the Exchange database from a backup. However, this can result in data loss for emails and other mailbox items created or modified between the time the backup was taken and the database failure.

Use Free Online Exchange Database Repair

If you prefer an online recovery option, you can try Free Exchange Database Repair. It can repair an Exchange database online without requiring an Exchange Server installation. The service offers free repair for EDB files up to 500 MB and let you preview the recovered mailbox data before downloading it.

For added privacy, all uploaded EDB files and recovered data are automatically and permanently deleted from the servers within 24 hours. This makes the online service a convenient option when you need to repair a smaller Exchange database quickly without installing software.

Use Specialized Exchange Recovery Tool

For larger databases, severely corrupt EDB files, or when you need more extensive recovery and export options, you can use a specialized Exchange recovery tool to minimize data loss and improve the chances of complete recovery.

Stellar Repair for Exchange is one such tool that can open databases from any Exchange Server version, regardless of their size or corruption state. After a quick or deep scan, it displays the complete database structure, allowing you to selectively choose mailboxes and other items and export them to PST and other file formats.

You can also export recovered items directly to a new or fresh Exchange Server database. Features such as automatic mailbox matching, priority-based recovery, and parallel exports help ensure a smooth and efficient recovery process.

Watch our complete guide on Unable to Mount Database (hr=0x80004005, ec=1108) Error

Conclusion

As you have seen, when a database fails to mount, then there could be a serious issue with the database or transaction logs. This can cause disruption to the business. Therefore, you should act immediately to resolve the issue at the earliest possible. To ensure recovery with no data loss, you can use Stellar Repair for Exchange – a powerful Exchange repair tool that can recover all the data from corrupted databases.

FAQs