Mounting a dismounted or offline Exchange database requires both database and log files. If the log files are missing, you can’t mount the database as the database enters into an inconsistent state. Similarly, if the database or log files are corrupt, database mounting attempt fails, and errors such as “MapiExceptionCallFailed: Unable to mount database. (hr=0x80004005, ec=-515)” appears.
The complete error is as follows,
Failed to mount database 'Mailbox Database'.
Mailbox Database
Failed
Error:
Couldn't mount the database that you specified. Specified database: Mailbox Database; Error code: An Active Manager operation failed. Error: The database action failed. Error: Operation failed with message: MapiExceptionCallFailed: Unable to mount database. (hr=0x80004005, ec=-515)
. [Database: Mailbox Database, Server: SERVER.rapidspillrespo.local].
An Active Manager operation failed. Error: The database action failed. Error: Operation failed with message: MapiExceptionCallFailed: Unable to mount database. (hr=0x80004005, ec=-515)
. [Database: Mailbox Database, Server: SERVER.rapidspillrespo.local]
An Active Manager operation failed. Error: Operation failed with message: MapiExceptionCallFailed: Unable to mount database. (hr=0x80004005, ec=-515)
. [Server: SERVER.rapidspillrespo.local]
MapiExceptionCallFailed: Unable to mount database. (hr=0x80004005, ec=-515)
In such a case, you need to do a few checks and repair the Exchange database to mount it and avoid the database mounting error.
Steps to Fix Error “MapiExceptionCallFailed: Unable to mount database. (hr=0x80004005, ec=-515)”
Below we have discussed the steps to fix this error and successfully mount a database (EDB) in Exchange.
Step 1: Check Database
Before mounting a database, you must check whether the database is in Dirty Shutdown or Clean Shutdown state. The error appears when you try to mount a database that is either corrupt or in Dirty Shutdown state. A database is said to be in Dirty Shutdown state when the log file is either not committed to the database or missing.
To check the database state, you can run the following command in PowerShell as an administrator,
eseutil /mh "PATH TO EDB FILE\Database.EDB”
This will provide an output with the current state of the database file that you are trying to mount. If it displays State: Dirty Shutdown, then it means that the database was not shut down properly.
Thus, you must repair the database file before mounting it and avoid the “MapiExceptionCallFailed: Unable to mount database. (hr=0x80004005, ec=-515)” error.
Step 2: Repair Database
If the database is in Dirty Shutdown state, use the following command in PowerShell to repair the database and bring it back to the Clean Shutdown state.
eseutil /p "PATH TO EDB FILE\Database.edb”
After running this command, re-run the previous command to again check the shutdown state of the database. It should be State: Clean Shutdown.
Once it displays Clean Shutdown state, you can try to mount the database. If it mounts successfully, then the problem is resolved. If it doesn’t mount even when the shutdown state is Clean, follow this guide, Is your Exchange database as in a ‘Clean Shutdown’ state? But it is not mounting?
If the shutdown state is still ‘Dirty’, then check the database logs.
Step 3: Check Database Logs
If the database is still in a dirty shutdown state or fails to mount, check the database log files. For this, run the following command in PowerShell,
eseutil /ml "PATH TO LOG FILE\Mailbox Database\E00"
Note: E00 is the starting sequence of the logs.
The output will display a list of log files. If the log files are clean, the status of log files should be shown as OK.
Step 4: Recover Database
If the database logs are clean and OK, you can perform Soft Recovery on the database by using the following command,
Eseutil /r /l "PATH TO LOG FILES\E00" /d "PATH TO DATABASE FILE\Database.edb"
In case the log files are not OK, back up the log files to a safe location and then delete them from the original location. Then try to mount the database.
If this also doesn’t fix the error “MapiExceptionCallFailed: Unable to mount the database. (hr=0x80004005, ec=-515)” and fails to recover/mount the database, then you need an Exchange Recovery Tool.
An Exchange Recovery Tool, such as Stellar Repair for Exchange can help you recover dismounted or offline Exchange database file and fix the database mounting error “MapiExceptionCallFailed: Unable to mount database. (hr=0x80004005, ec=-515)”.
The software scans damaged or corrupt Exchange database (EDB) files and recover all the mailbox items such as emails, attachments, contacts, notes, tasks, calendars, journals, and public folders. After repairing the database file with Stellar Repair for Exchange, you can export the mailboxes directly to Live Exchange server or Office 365 in a few clicks. This way, you can avoid the database mounting error and restore the database and mailboxes.
Besides, the software supports all Exchange versions such as MS Exchange 2019, 2016, 2013, 2010, 2007, 2003, 2000, and 5.5.
The software is the most effective way to restore a database that fails to mount without the risk of data loss. It doesn’t require log files to perform the repair and restore process.
To recover the database with Stellar Repair for Exchange, follow this instructional guide on How to Recover the Corrupt/ Inaccessible Exchange Mailboxes Using this Software.
Conclusion
Database corruption may occur due to several reasons, such as missing log files, dirty shutdown, etc., which leads to database dismounting. When the database is offline, it impacts the email flow and business. Thus, it’s critical to mount the database as quickly as possible. However, sometimes, you may face errors while mounting the database, such as “MapiExceptionCallFailed: Unable to mount the database. (hr=0x80004005, ec=-515)”.
This guide helps you with various steps to resolve the error and mount the dismounted or offline database successfully. It further discusses the steps to restore the database by using the Exchange Recovery tool in case the database fails to mount after repair and recovery via EseUtil in Exchange.
Was this article helpful?
