The Exchange database may sometimes fail to mount owing to various technical reasons. A dismounted EDB file can be the source of many Exchange errors including mailbox inaccessibility for users. Resolving the root cause of mounting problems becomes imperative to bring the server back online.
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:
- The antivirus installed on your machine has deleted / quarantined critical Exchange log files
- Exchange database hard recovery has been performed with eseutil / p command without moving transaction log files to another folder
- Exchange repair has been performed with eseutil /r command with incorrect log file base name
- The signature and LGeneration of an Exchange file don’t match (this may happen even if the database is in consistent state)
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.
- Confirm whether hard recovery was indeed performed by opening a Windows command prompt and executing: ‘c:\program files\exchsrvr\bin\eseutil /mh “c:\program files\exchsrvr\mdbdata\name of Exchange database.edb”’
- In the result of this command, locate an attribute named “repair count”. If the count value is zero that means an eseutil /p operation wasn’t completed successfully or wasn’t run at all. Any value other than zero indicates that the operation was executed.
- Check if the database is in clean shutdown state and if it is, move all the transaction log files from all the metadata directories into the backup folder.
- Now attempt to mount the databases.
Note: The example mentioned above is based on the following assumptions:
- Exchange server program files are located in c:\program files\exchsrvr folder.
- The database itself is stored at c:\program files\exchsrvr\mdbdata folder.
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.