On a regular working day, you might find out that some or all users on Exchange server are unable to send or receive emails and even not being able to access their mailbox. After looking into the issue, you notice that the mailbox databases are not mounted. When you try to mount the databases, you get an error, as given below.
Couldn’t mount the database that you specified. Specified database: Mailbox Database 2093613246; 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: Mailbox Database 2093613246, Server: R-FS1.webrooster.local]
In such a situation, the first thing to do is to look at the disk storage. Usually, unable to mount database (‘hr=0x80004005, ec=1108)’ error appears when the disk storage is full. Now, if you have the database and logs on separate disks, you can check both the drives. If the drive of the database is full, you need to extend the storage or move the database to a larger drive. There is no possible way to compress the database as it is already in a compressed format.
In case, the log location is full then the culprit could either be an antivirus software which is interfering with the backup or the backups are not correctly backing up your Exchange Database and purging the databases. Another reason for the log files not being purged is that the backup software is not application aware or Exchange Server friendly. In this case, you must either move the log files to another location which has more storage space or increase the disk space if the server is a virtual machine.
If the database is still unable to mount, after increasing the space, you need to check whether the database is damaged or not. To do so, use the ESEUTIL tool.
By running the below command, you can identify the state of the database.
EseUtil /MH <your edb file path>
If the database is in Dirty Shutdown state, you might be in a bit of sticky situation as the database might be damaged or there could be a missing log file.
In such a case, you can use EseUtil to perform a soft recovery or a hard recovery. However, there is no guarantee that the database will mount afterwards.
First, you need to run the below command to identify the required logs,
eseutil /ml <Log path location>
Once you have the log number, usually it is like E00, you need to use the R parameter to initiate a soft recovery:
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 command with / MH parameter to check the database state. If the database state is healthy, you will be able to mount your database.
If the Dirty Shutdown state persists, you have two options:
Restore the server from backup and loose all the data from the last backup
Perform a hard recovery process
CAUTION: If you perform 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 provide assistance. This is because when a database is recovered with the hard recovery, it will hard code some information. When this is noticed by Microsoft, 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 you need to accept it before proceeding. This recovery must be used as a last resort.
Once done, you will get a screen like below.
You will need to run the EseUtil again with the MH parameter to see if the database state is healthy. If the database is healthy, you will be able to mount the database.
The Easy Solution
The above manual solution will take a considerate amount of time, without knowing if it will successfully resolve the issue. However, there is an easy solution available. You can use Best Exchange Recovery Software – Stellar Repair for Exchange that can open any version of Exchange Server database. If the database is damaged, you can create a new database and move the users on it with a blank mailbox. You can attach the EDB file to Stellar Repair for Exchange and export all the mailboxes to the live new Exchange Server database. This solution allows you to restore the service back in no time, with no complex recovery processes.
Eric Simson is an Email Platform Consultant and is associated with Stellar Data Recovery from last 6 years. He writes about the latest technology tips and provides custom solutions related to MS Outlook, MS Exchange Server, Office 365, and many other Email Clients & Servers.