In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!
One of the most common occurrences troubling an Exchange database is the “unable to mount database” (HR=0x80004005, EC=-543) error. When this error arises, users can do little except look for ways to resolve it since all their server related activity stays halted until the database can be mounted.
The right fix to an error can be found only if the right cause for it can be pinpointed. And when it comes to finding the cause for an error, the numerical codes associated with them can provide critical information. In this post, we’re trying to resolve the “unable to mount database” error with the error code “-543”.
Reasons behind the error
Generally, Exchange mounting errors can be the result of varied causes like:
However, researches across various technical forums suggest that the primary triggers of Exchange mounting error -543 include dirty shutdown state, missing transaction log files, or EDB file corruption.
Resolving Exchange Mounting Error -543
After conducting discussions with Exchange administrators across various organizations, we have compiled a list of the most used solutions to fix this error. Try them out one after the other to resolve the issue. But remember to take a backup of your EDB and STM files in their current state before starting with any of the fixes. Also, proceed to the next fix only if the previous one fails.
1. Quit all programs that might be using the EDB file
Check the automated backup software and anti-virus applications installed on the server and verify that they are not holding a lock on the EDB and STM files. If these database files are being blocked by some background processes, they can cause Exchange database to fail to mount. Unlock the files using third-party file unlocking utilities.
2. Restore database from backup or by replaying log files
This method however cannot be used if a recent relevant backup isn’t available or if some critical log files have been corrupted.
3. Move all log files to a different location
Create a new folder and move all log files to it. This will cause the database to automatically create new log files thereby overriding faulty ones and recreating missing ones.
4. Run Soft Recovery
Restoring the database from backup or from log files is the best way to fix errors within it. Thus, find out what state the database is in by running the following command:
eseutil /mh "Database file"
If the database is in “dirty shutdown” state, try a soft recovery on it using the following command:
eseutil /r "prefix"<E00> /l <log file location> /d <database location>
5. Create Recovery Database and Restore to it
To use this method, you should have the know-how of Exchange Management Shell. Here are the steps:
a. Use the following command in shell to create the recovery database:
New-MailboxDatabase -Recovery -Name RDB -Server “servername” -EdbFilePath "path" -LogFolderPath "path”
b. Select the Database to be restored from the “Backup Exec Restore” job properties
c. Go to Microsoft Exchange Redirection and select Redirect Exchange Sets.
d. Go to Microsoft Exchange and select Default options
e. Run the restore
f. Once the restore is successfully completed data from a RDB can be merged to an existing mailbox or exported to a folder
6. Hard Repair the Database (Risky Method)
Please note that this method should only be used as a “last resort” since it carries the risk of data loss. This method attempts to repair corrupted pages within the Exchange database, but discards the pages that cannot be repaired.
a. Run a hard repair on the database by running the command:
eseutil /p "Database file"
b. Thereafter, defragment the database. Offline defragmentation creates a new physical database structure and moves the existing data to that structure. Use the command:
eseutil /d “Database file”
c. Lastly, check the consistency of the database. You may need to run Isinteg several times until the summary report returns no errors. Use the command:
Repair Database files using Third-party Software
If you have tried all of the above solutions to no avail, the only way you can get the Exchange database back online is by using reliable third-party software. We recommend Stellar Phoenix Mailbox Exchange Recovery. This product is laced with powerful algorithms that enable it to scan even the most severely corrupted EDB files and repair them to facilitate the recovery of all mailbox data. In situations of crisis, this tool can be your last ray of hope.
To sum it up
When faced with database mounting problems, the safest resolution if restoring database using a relevant backup. If that’s not available, avoid going with risky manual fixes and stick to using Stellar Phoenix Mailbox Exchange Recovery as suggested.