For the users who aren’t aware of this, “mounting an Exchange database” means establishing a connection between an offline EDB file and the live Exchange Server. Generally, EDB file mounting is quite straightforward and it can be automated so that a particular offline EDB file mounts on the server as soon as it comes online. When everything is working as expected, the EDB file mounting is an unnoticeable procedure; just a step that enables users to get on with their work. But sometimes, internal errors can prevent an offline EDB file from mounting smoothly and throwing messages like:
“An internal processing error has occurred. Try restarting the Exchange System Manager or the Microsoft Exchange Information Store Service, or both.”
Such an occurrence causes further issues like mailbox inaccessibility and inconvenience for users and thus, resolving the root cause of the issue becomes essential. Through this post we’re trying to highlight a particular EDB mounting error and uncovering the reasons and solutions behind it so that users can gain insight into the whole scenario.
Reasons behind Exchange “Internal Processing Error”
The error mentioned above is associated with the numerical error code 1811 and the message JET_errFileNotFound. This error can arise due to any of the following reasons:
Before trying any other fix, simply follow the advice mentioned in the error message – “restart the Exchange System Manager or the Microsoft Exchange Information Store Service”. If that doesn’t work, depending upon the exact cause of the issue, you can try one of the solutions listed in the next section to fix the problem.
Note: The solutions mentioned below have been listed in an order corresponding to the list of reasons above, so proceed to the next fix only if the previous one doesn’t work.
1. If the trigger for the error has come from the antivirus, add Exchange Server directories to your antivirus’ “excluded locations” list. Blocks and scans from antivirus programs frequently mess with other applications. Also, check if any critical log files have been quarantined or deleted by the antivirus. If they have, recover them to their original location. If this doesn’t work, try restoring the database from a recent available backup.
2. If a hard recovery was performed without moving the log files to another location, here’s what you need to do.
Note: The example mentioned above is based on the following assumptions:
3. If the eseutil /r command has been run with incorrect log file base name, here’s what you need to do. Re-run the command with the correct syntax and log file base names, for example, ‘eseutil /r e00’, or ‘eseutil /r e01’, or ‘eseutil /r e02’.
Alternative Simpler Solution
If none of the above solutions work or if you’re looking for a simpler way to resolve the problem, you need to rely on a competent third-party EDB Recovery application. Stellar Phoenix Mailbox Exchange Recovery is a great tool that’s just right for the purpose. Laced with advanced algorithms which scan and repair corrupt EDB files, this software helps users recover dismounted and offline EDB files and make them fit for mounting. What’s more, using this product you can restore mailbox contents like emails, attachments, contacts, calendars saved within EDB files and save them in Outlook PST format or even export the data directly to live Exchange Server or Office 365. When Exchange mounting problems or any other complex issues strike, this product is just what you need.
Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.