How to Resolve Exchange Database Fails To Mount Error

Updated on March 15, 2018

The article displays information about Exchange Server (HR=0X80004005, EC=-528) error that DBAs experience after the database fails to mount. In such cases, it becomes essential to employ a professional recovery tool considering few measures mentioned in the article.

Transaction log files are essential for the smooth functionality of Exchange as they track records of all the transactions being made to EDB files. If a log file that is not written to associated database gets removed, several issues can hinder Exchange performance to some extent. In severe cases, the database may fail to mount.

Removing all transaction log files may help resolve the issue; however, database consistency needs to be checked before removing the files. If the database exists in an inconsistent state, it requires restore Exchange mailboxes from backup. Sometimes, when you try to mount Exchange mailbox store, an error message may appear stating:

“Exchange is unable to mount the database that you specified. Specified database: Servername\First Storage Group\Mailbox Database; Error code: mapiExceptionCallFailed: Unable to mount database. (hr=0x80004005, ec=-528)”

Factors Leading to ‘Unable to Mount Database Error’

Regardless of the number of attempts made towards mounting a database store, the same error message will appear each time. The main cause behind the existence of the error message is the missing one or more transaction log files before they are committed to the associated database.

In several cases, the Exchange Server is not properly shut down due to sudden power failure or similar reasons. This turns database to aDirty Shutdownstate. If you encounter (hr=0x80004005, ec=-528) message, you will need to resolve to resume Server functionality.

In case the database is properly shut down, make sure to move the Checkpoint file as well as all the log files to any other folder and attempt to re-mount it. The defined procedure to bring the database to a consistent mode is mentioned in the upcoming section.

Workaround to Resolve Error

To fix error HR=0X80004005, all the transaction log files need to be moved to a different folder. Once all the files are moved, follow the steps below: 

  1. Stop the Exchange Information Store and all the databases existing in the storage group.
  2. Run eseutil/mh command to check the integrity of the database. The switch must be followed by the database name. (Example: if the database name is Mailbox Project1, the name of the database is Mailbox Project1.edb). Under the header section, analyze the value corresponding to ‘State’
  3. If the database is properly shut down and is in a Consistent state, safely remove all the transaction log files and store them to a different folder. Ensure that the current transaction log files are not removed.
  4. If the database is in Inconsistent state or not properly shut down, try to restore from last online backup. Run eseutil/ r for soft recovery if the online backup is invalid.

Run eseutil/ p for hard recovery or utilize third-party EDB Repair software to restore Exchange mailboxes without data loss. Eseutil/ p will execute a thorough check on the database to analyze if any corrupt pages exist within. 

It is vital to back up the entire database components as data loss can occur at any stage of the recovery procedure. Also, ensure that enough free space is available on the drive (approximately twice the volume of the database). This space is utilized by the temporary database that is created during the recovery procedure. 

There are several things that DBAs must consider before implementing professional EDB recovery procedures. 

Points to Consider while Employing Third-Party EDB Recovery Apps

    Once you have completed trying all the recovery methods and nothing seems to work to bring the database to the consistent mode, the next step is to employ a third-party Exchange Recovery solution. Before doing so, it is important to analyze the features and functional criteria of the tool before making any initial investment:

  • Must Handle Different Levels of Corruption:
  • The very first attribute of the third-party Exchange Recovery tool is that it must be capable to recover corrupt EDB database under all circumstances. With the ability to handle all the levels of corruption, be it higher or lower, the tool must recover the entire mailbox components including emails along with attachments, contacts, notes, calendar entries, etc.

  • Must Support Recovery of Deleted Mailboxes:
  • The tool that you are employing for recovery of Exchange Database must be capable of restoring deleted folders as well as mailboxes. The tool should be developed using advanced recovery algorithms with efficiency to recuperate all possible data from intentionally or accidently deleted mailboxes. 

  • Must Export Mailboxes to Live Exchange Server:
  • While looking for the software to restore Exchange mailboxes, you must check if the intended tool allows exporting recoverable data to live Exchange Server environment. Above all, the tool must be functional over the latest editions of the application that includes Exchange Server 2016, 2013, and lower versions. 

    In addition to this, there are other attributes as well that a user must search for at the time of selecting the EDB mailbox recovery software. The tool must generate a preview of all recoverable data before initiating recovery so the user must get an idea about its efficiency. Moreover, availability of a trial version is one such feature that comes as an extensive benefit to end users and makes it more scalable. 

The Way Forward - Stellar Phoenix Exchange Mailbox Recovery

An efficient EDB repair software, Stellar Phoenix Exchange Mailbox Recovery Software incorporates all the above mentioned attributes and the ability to bring the inaccessible database to the consistent mode. The software is a proficient way to repair EDB as well as associated streaming files that turned inaccessible during the attempt to fix error HR=0X80004005.

The recovery software is engineered using highly progressive scanning algorithms that can be used on the Exchange EDB files as per the level of damage or data loss to make entire procedure faster. If the database fails to mount and displays (HR=0X80004005, EC=-528) error, you may experience missing mailbox folders or data components when the database is brought online.

In such cases, the third-party Exchange mailbox recovery solution can be employed, and the database can be restored to either existing or new database. Recoverable contents can then be exported to the live Server environment by providing the necessary details.

Related Articles

 

How to Fix Exchange Jet Errors 1018 & 1216

Updated on March 15, 2018 | Read Article

 

How to Recover Exchange Database when Log files are missing

Updated on March 15, 2018 | Read Article

 

How to Repair Exchange 2010 database with Eseutil Switches

Updated on March 15, 2018 | Read Article

 

How to Resolve Exchange "Dirty Shutdown" Error

Updated on March 15, 2018 | Read Article

 

How to Restore Exchange 2016 Mailboxes Easily

Updated on March 15, 2018 | Read Article