How to fix EDB file error while mounting an Exchange Server database

Sarthak Poswal

Updated On - February 27, 2024

There are incidents when fatal error in Exchange server aborts the exchange server application and thus make it not viable. In fact, you would be very much surprised to note that, at times, the behaviour of MS Exchange Server renders all your precious data inaccessible and results in the critical loss of data. Fortunately, there are various methods that users can implement to repair the damaged EDB file. Depending on the root cause, the solutions may get tricky.

Let’s say you try to mount an EDB file and encounter the error.

“An internal processing error has occurred. Try restarting the Exchange System Manager or the Microsoft Exchange Information Store service, or both.

ID no: c1041724

Exchange System Manager“

The moment you come across this situation, the mount operation gets aborted. It’s pretty obvious something is wrong.

1. Large Edb file
2. Interrupted by 3rd party application
3. Exchange server database mounting limit
4. Inconsistent / Corrupted database

1. Large EDB file:

   The Microsoft Exchange Server Standard Edition 2019, 2016 Standard Edition, and 2013 Standard Edition have a default database size limit of 1,024 gigabytes. EDB file with a size more significant than the default limit will not get mounted. EDB file contains mailbox data of numerous users, and each mailbox has its own inbox, email attachments, contacts and calendar data. Over time, this data may increase substantially. Resulting in over grown EDB file. Such EDB file are more prone to corruption. Therefore, it is recommended to keep track of EDB file and clean any obsolete email data. Additionaly, user may use to solve this issue.professional tool to solve this issue.

2. Interrupted by 3rd party application:

   Applications like an antivirus program or a system monitoring application might be blocking access to the EDB file or its logs. This can also interfere with the mounting procedure. Try marking the EDB file as safe or disable these applications until you mount the database.

3. Exchange server database mounting limit:

   Exchange server has a limit to how many databases it can mount. The limit depends on the version or edition of server. The Standard Edition of Exchange server can typically mount up to 5 databases. So, try verifying if you have hit the limit.

You can use the following command in the exchanger server management shell.

Get-MailboxDatabase -Status -IncludePreExchange | Sort Name | Format-Table Name, Server, Mounted

This will display all the databases along with their mount status.

To dismount a database, use the command.

Dismount-Database DatabaseName

Mount the database you want with the command.

Mount-Database DatabaseName



4. Inconsistent / Corrupted database:

   Another possible reason for facing such error could be if you have run eseutil /p repair utility on the affected database. But for some reason the log files remain intact and are not removed. In such a scenario, the database might fail to mount and throw the error mentioned above.

The entire issue could be resolved by opting for the following method:

• First, check whether eseutil /p command was previously executed or not. To do so, just run eseutil /mh. and for pub1.edb and priv1.edb, check the repair count value. If the count shows the value is ‘0‘, then the command has not been executed before. If the count value is greater than 0. It means repairs have been performed before. So, there is a possibility of data loss or issues with the log files. Microsoft recommends evacuating data from such database to a new consistent database.
• You also need to examine database consistency. If it exists in a Clean Shutdown state, then it means that the log files have been committed, and you can effectively remove the log files from Exchange Server folder.
• To check the database state, open Exchange management shell and run the following command

eseutil/mh “database_file_with_complete_path”

If the state is clean, then it will appear like below

Otherwise, it will display the state as Dirty Shutdown

• If the database shows ‘Clean Shutdown‘, then try the remounting again. If it shows a ‘Dirty Shutdown‘ state, then the possibility is very high that the database has gone corrupt or all the log files have not been committed yet.
• Now, to replay the transaction logs, do soft recovery by running the command

eseutil/r “database_file_with_complete_path ”

Note: If this command does not work, try navigating to the default location of eseutil, which is C:\program files\”exchsrvr folder”\bin\ESEUTIL, then return the command

C:\program files\exchsrvr folder\bin\ eseutil/r “database_file_with_complete_path ”

• Now recheck the state. If it’s clean, then move to the next step. Otherwise, do the hard recovery using eseutil/p.

C:\program files\exchsrvr folder\bin\ eseutil/p “database_file_with_complete_path ”

Note: Hard recovery is not recommended because it will delete the corrupted data permanently. 100% data restoration won’t be possible then.

• Now defragment the database file using eseutil/d

C:\program files\exchsrvr folder\bin\ eseutil/d “database_file_with_complete_path ”

• Now recheck the consistency, and if it shows Clean Shutdown, remount the database.
• If it still shows Dirty Shutdown, then your database is corrupted. In such scenario it is recommended to use a 3rd party tool for restoring data.

Conclusion

Following the methods mentioned in this article will help your email communication get back on track. The manual methods may get tricky at some point. Users must be careful while implementing these. Any inexact step may lead to permanent data loss. For a more accessible and swift solution, expert-recommended Recoveryfix for Exchange Server Recovery tool can be used. It can restore data from corrupted database file with 100% integrity and data retension.