15 Feb 2011

Exchange Defrag (ESEUTIL /d) Fails – File Locked Or In Use

IT Tips No Comments

I ran into an interesting problem the other weekend that stressed me out a bit.  I was running an Off-line exchange on a SBS2003 server.  They have about 60GB priv1edb file so I started the defrag on a Friday night knowing it would take 5 to 6 hours to complete.  When I checked on it the next morning, I got this error:

Moving ‘TEMPDFRG8620.EDB’ to ‘d:\progra~1\exchsrvr\mdbdata\priv1.edb’…
File Copy Status (% complete)

0    10   20   30   40   50   60   70   80   90  100
|—-|—-|—-|—-|—-|—-|—-|—-|—-|—-|
……………………Error: Could not re-instate ‘d:\progra~1\exchsrvr\mdbdata\priv1.edb’. It may be manually re-instated by manually copying ‘TEMPDFRG8620.EDB’ to ‘d:\progra~1\exchsrvr\mdbdata\priv1.edb’ (this will overwrite the original copy of the file with the defragmented copy).

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

What I found out was that even though the Information store is dismounted in ESM, it may still be locked open

I could of stopped the following services and re-run the defrag (which will take another 6 hours of time)

  • Net stop MSEXCHANGEIS
  • Net stop MSEXCHANGESA

Or I could do this first and it should only take about 10 minutes.

If the defrag has finished with no errors and did not overwrite the main priv1.edb you can overwrite the original database with the defragged database and restart all servers (recommended as you will NOT have to re-run the defrag process again).

  • Stop the Exchange Information Store and System Attendant services
  • In your Exchange MDB directory, rename priv1.stm to priv1-backup.stm (if applicable)
  • In your Exchange MDB directory, rename priv1.edb to priv1-backup.edb (if applicable)
  • Copy the new temp defrag of the .stm file (in our case TEMPDFRG8620.stm) to the Exchange MDB directory – ENSURE the file name is changed to priv1.stm
  • Copy the new temp defrag of the .edb file (in our case TEMPDFRG8620.edb) to the Exchange MDB directory – ENSURE the file name is changed to priv1.edb
  • Restart all Exchange services
  • Mount the Information Store
  • PERFORM IMMEDIATE EXCHANGE BACKUP (this is VERY important as the old log files – pre-defrag cannot be used to replay a restoration with the newly defragmented database).

This worked for me and I was very happy!  I did not feel like re-running the defrag or even worst, restoring from a tape backup.  Just remember that an Off-line exchange database defragmentation will generally handle 9-10gb per hour – there is no way to speed up this process.  Please evaluate your database sizes BEFORE you start this process as large database defrags may need to be started over a weekend.

Comments are closed.