• facebook
  • twitter
  • linkedin

Read time 3 minutes

Database mounting in Exchange Server involves 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 effectively resolve the issue.

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:

Cause #1

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.

Cause #2

If the antivirus programs 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 need to recover them to their original location. And if the log files are deleted, you need from backups. You can also think of restoring an available database. If all these methods fail, you need to use run repair unities to bring the database back to consistent state.

Cause #3

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:

  1. Go to Start, type Run in the search box, then type cmd in dialog box that appears and click Ok.
  2. 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.
  3. 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.

Cause #4

If you run the eseutil /r command with incorrect log file base name.

How to resolve it: First, make sure you are using right switch for running commands. The commonly used log file base name are e00, e01, and e02. Hence the right command will be the one having right log file base name like:

‘eseutil /r e00’

Final words

If none of the aforementioned resolutions prove effective, it is advisable to consider investing in a third-party Exchange EDB file recovery tool to save valuable time. An excellent option in this regard is Kernel for Exchange Server, a proficient third-party tool. With Exchange Server recovery software you can effortlessly 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.

Related Posts