Read time 3 minutes
Database mounting in Exchange Server involves connecting establishing a connection between an offline EDB (Exchange Database) and the live server. While this process is generally straightforward, there are instances where mounting the database store in Exchange Server can be challenging. During your attempt to mount the database, you might encounter an error message:
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”
As stated in the error message, restarting both the Exchange System Manager and the Microsoft Exchange Information Store Service is recommended to address this issue. However, should the problem persist, further steps may be required to resolve the issue effectively..
Reasons behind Exchange Server internal processing error
There could be certain reasons behind the occurrence of this error. All of them are referenced below with their possible solutions:
Error 1811 that indicates JET_errFileNotFound. This error may arise when the signature and LGeneration of an Exchange file mismatches. In this case, the information store may encounter mounting issues even if the consistency of the database is maintained.
How to resolve it: To solve this issue, you should contact Microsoft Product Support Services. They can restore your account from internal processing errors and provide a seamless solution.
Occasionally, antiviruses can affect the EDB files and remove some files. If the antivirus program deletes or quarantines the Exchange log file, mounting issues can occur.
How to resolve it: You need to add Exchange Server directories to the list of ‘Excluded locations’ for antivirus scanning. If the Exchange log file is already quarantined, you must recover and take it to its original location. And if the log files are deleted, you need backups. You can also think of restoring an available database. If all these methods fail, you need to use run repair utility to bring the database back to consistent state.
If the log files were not removed and eseutil/p command was run on corrupt databases.
How to resolve it: First of all, you need to confirm whether the eseutil/p command was run. It involves the following steps:
- Go to Start, type Run in the search box, then type cmd in dialog box that appears and click Ok.
- Run the following in command prompt:
‘c:\program files\exchsrvr\bin\eseutil /mh “c:\program files\exchsrvr\mdbdata\name of Exchange database.edb”‘
Note: The mentioned example is based on following assumptions:
- All the program files of Exchange server are located in c:\program files\exchsrvr folder.
- The database is contained in c:\program files\exchsrvr\mdbdata folder.
- Look through the repair count attribute. If the count is zero, the eseutil/p command was not operated. If the count appears an any number except zero, the eseutil/p command was operated.
If the database is in clean shutdown state, move all the transaction log files from all the metadata directories into the backup folder and then, mount the databases.
If you run the eseutil /r command with incorrect log file base name, you can face some errors while running the code. Also, the process will fail when the wrong code is executed..
How to resolve it: First, make sure you are using right switch for running commands. The commonly used log file base names are e00, e01, and e02. Hence, the right command will be the one having right log file base name like:
Alternative solution to fix internal processing errors
Mounting an EDB file is necessary to fix the internal processing errors. We have mentioned some manual methods that will assist you in fixing internal errors while mounting an EDB file. However, manual methods are time-consuming and risky. In that scenario, you can rely on a professional tool to help fix corruption and internal issues in the Exchange Server. The Kernel for Exchange Server software helps you to fix internal processing errors while mounting an EDB file in Exchange Server.
Final words
Internal processing errors can damage the EDB files and abruptly stop the Exchange Server. So, keeping your EDB file mounted and experiencing the Exchange server without facing any error is essential. We have mentioned some manual methods to mount an EDB file. If none of those above-mentioned resolutions prove effective, it is advisable to consider investing in a third-party Exchange EDB file recovery tool to save valuable time.
The software lets you retrieve mailboxes and seamlessly transfer them to a live Exchange Server. Furthermore, you can effortlessly migrate mailbox data from EDB to PST, simplifying the entire process.
