Error Resolved: eseutil operation terminated with error -1032 jet_errfileaccessdenied

After a restart from updates, routine maintenance or installed applications we ran into an issue with the database of our Exchange server not being able to mount. We looked for clues and immediately we went to panic. After looking around on the internet and even on the server, we checked for the correct storage, any issues with certain updates or corruption in the Exchange Server on underlying storage. After some more research we have tried using the EseUtil to identify if the database’s state is healthy or in a dirty shutdown state. I have executed the below command.

Eseutil /mh “M:\mailboxes\mailbox01.edb” 

As soon as I ran it I got the below message.

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server Version 14.00 Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating FILE DUMP mode...

Error: Access to source database 'mailbox01.edb' failed with Jet error -1032.

Operation terminated with error -1032 (JET_errFileAccessDenied, Cannot access file, the file is locked or in use) after 20.31 seconds.

The Jet errors are quite hard to resolve and could easily harm or corrupt your mailbox database. Looking a bit on the error the -1032 I found out that it would be related to the fact that apart from the file being locked by an application. After some look up I identified that lately we have installed an update to our antivirus server and after some more digging I found out that the application was scanning and being held by our antivirus solution which was degrading the performance and manageability of the database.

I have dismounted the database from the Exchange using the PowerShell command line and I have setup the scanning exclusion on the database drive. After a restart of the machine it was noted that the database still didn’t mount. After looking at the results after running again the EseUtil with the /mh parameter I found out that the database health status was showing dirty shutdown. Although the antivirus now is not scanning the drive of the database, it seemed that the database got corrupted in some way. I have tried many resolutions to recover the status of the database but was not successful.

After this the only solution was to use the EseUtil to try to recover the database from corruption. I have executed the command again but also noted the line saying Log Required.

In this case the Log Required was showing 3-3 (0x3-0x3)

In this case then I executed the command again but now using the /R E003 with the second part of the command being the missing log file from the /mh report. Since you might have the database in another location you would need to specify the location and to be honest it would always be best to specify it. This can be achieved by running the command with the /l parameter as below. Also of course you would need to use the /d to specify the location of the impacted database.

Eseutil /r E03 /l “M:\mailboxes” “M:\mailboxes\mailbox01.edb” 

After this is complete, you would need to count your blessing and hop the database mounts. If this doesn’t work you would need to run the hard recovery. This of course takes a considerate amount of time by using the /p parameter as below

Eseutil /p “M:\mailboxes\mailbox.edb” 

After waiting for quite a long time for this, it is highly suggested to do a defrag of the data which can be achieved by running the PowerShell command New-MailboxRepairRequest if you have Exchange Server 2010 with Service Pack 1 or later. It’s important to note that once you run this command there is no way to stop the process half way. You would need to kill the process but honestly I wouldn’t do that as it will increase the damage on the database for sure.

So, once the process is complete you can try to EseUtil and if you are lucky you will have the database state on Clean Shutdown. Now you can safely mount the database. Another important thing is that the hard recovery process is not a process that repairs your database and everything is fine. This process works in a way to eradicate the problematic or corrupted data from the database and any data is not recoverable and lost.

Although we made the database up the lessons learned from this was that if you have problems with the Exchange Server as Microsoft recommends you cannot just recover the whole Exchange Server virtual machine as apart from losing all the data from the last backup you will have implications and serious issues. From this we would note that the native recovery processes will take quite an amount of time and it could be unsuccessful.

With a hard recovery process you will lose the data from the EDB file as the process chops off the corrupted data. Apart from this one must also consider the administrative hours it took for the engineers to restore the server and what about the lost business hours of the company or the incoming/ outgoing emails?

Things like these would be lost business to the company or client apart from the disappointment of having the service down for several hours. The solution is by using third party applications which work great in such situation and could save your bacon. Applications like Stellar Repair for Exchange will surely come in handy as a tool for the business and its engineers.

One important fact about the application is that it’s very simple to operate and after adding the corrupted EDB and the scan is complete, it’s a simple process to either export to PST and other formats or export directly to a newly created database. This wouldn’t imply the fact that the admins would need to recreate the databases as the application can map the mailboxes to the Active Directory users and import the mailboxes to existing users and also create new users. The tool can be also used to migrate the databases even if they are on Office 365 directly or if you are running a hybrid system.