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 from backup, but this will also result in data loss from when the backup is taken to when the database has failed. Therefore, you should look for specialized Exchange recovery tool to minimize the impact and have a guaranteed data recovery.
Stellar Repair for Exchange is one such tool that can assist in the matter as you can open any database from any Exchange Server version, of any size, and in any state. After a quick or deep scanning of the database, you will be presented with a full structure of the database. You can granularly select the mailboxes or other items and export them to PST and other file formats. You can also export the items directly to a new/fresh Exchange Server database with automatic mailbox matching, priority and parallel exports, thus ensuring a smooth and seamless recovery.
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
