Summary: Unable to mount database (hr=0x80004005, ec=-1011) error appears when you try to mount a database with Dirty Shutdown state. Failing to mount a offline or dismounted data can lead to outage and downtime, preventing users from sending or receiving emails and accessing their mailboxes. Learn how to fix the error and mount the database to restore services. Also, learn to restore user mailboxes from a damaged offline database that cannot be mounted using an Exchange recovery software.
Mostly with large firms you get to make a disaster recovery testing, as well as test, restores for your Exchange Servers. With small companies it is the case but not so often. When restoring an Exchange Server mailbox database you need to be careful as you might end up with integrity issues and the actual database being unable to mount.
In this scenario, the team wanted to restore an Exchange 2010 mailbox into a Recovery Storage group. When we tried to mount the mailbox database won?t mount. This was on an Exchange Server 2010 SP1 with a DAG setup for failover. You will be presented with an error stating that the database was unable to mount due to an error (hr=800004005, ec=1011).
Microsoft Exchange Error
Failed to mount database ‘db01’.
mail2FailedError:
Couldn’t mount the database that you specified. Specified database: db01;
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=1011)
[Database: db01, Server: srv-exc-001.mydomain.lan]
An Active Manager operation failed. Error: The database action failed.
Error: Operation failed with message: MapiExceptionCallFailed: Unable to mount database. (hr=0x80004005, ec=1011)
[Database: db01, Server: srv-exc-001.mydomain.lan]
An Active Manager operation failed. Error: Operation failed with message:
MapiExceptionCallFailed: Unable to mount database. (hr=0x80004005, ec=1011)
[Server: srv-exc-001.mydomain.lan]
MapiExceptionCallFailed: Unable to mount database. (hr=0x80004005, ec=1011)
These messages will be showing the Event Viewer also with MSExchangeIS and MSExchangeIS Mailbox Store with having codes 9519, 1087, 9518, 9519 and 1087. The database integrity check will fail and the database will not mount when you try to mount an exchange database on the replica server manually when restoring into a Recovery Storage Group. If this is the case your database will not mount if the synchronization had any issues which mounting a database on a replica server while the DAG replication is still running. You can stop the scenario before the full synchronization finishes but it will lead to a database being corrupted on the live and replica.
In such cases you might stop the replication for the live database, remove the replica and check the database for any corruption using the EseUtil with the /mh parameter. If the state of the database is showing Dirty Shutdown you might need to run a soft recovery on the database using the /r parameter. Thou if after running this your database is still showing as Dirty Shutdown you would need to run the purge recovery which will mean that the corrupted data will be purged from the database to try to make the database state to change to a Clean Shutdown by using the /P parameter thou leave this option as a last resort. Depending on the level of corruption or the number of mailboxes, this might take some time and there is not guarantee that the database will mount. Afterwards you would need to run a defragmentation of the database which will take a considerate amount of time and the process cannot be stopped.
Before drastically doing this you, if after the soft repair your database will be in a clean state, you might need to try to run the following to be able to mount the database.
- Open the Exchange Management Console
- Click on Organization and Mailbox
- Open the Mailbox database properties
- Click on the Maintenance tab
- Tick ?This database can be overwritten by a restore? and click OK
- Mount the database again
If this doesn?t work then you would need to try to do the full purge recovery with the EseUtil and see if the database will change the state to healthy. If it doesn?t work do not despair as there is an alternative of starting everything from scratch and trying to convince the client that all his data is lost or you would need to loop in a Microsoft expert to help you out which will take more time and resources. The alternative is an application called Stellar Repair for Exchange.
Exchange Server Recovery Software will allow you to either find or open one or more databases in the application and after a scan of the EDB file, it will present you with all the tree of the mailbox database. You can then create a new EDB file in your Exchange Server and apart from exporting to PST and other formats, you can export the mailboxes directly into a live Exchange Server. Here you can select to either create or match with a mailbox already created in the Exchange Server. The same concept is applied if you wish to export directly to an Office 365 tenant. You can make granular search in the database and export multiple mailboxes from different EDB files.
The application is the best tool that an Exchange Administrator can have which will surely get the things done in such cases and will reduce the time to fix a disaster.
