Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The error is:

eseutil (2860) JetDBUtilities - 3928: The log file \?\GLOBALROOT\Device\HarddiskVolumeShadowCopy84\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 0501047257\E000000B4E0.log is damaged, invalid, or inaccessible (error -501) and cannot be used. If this log file is required for recovery, a good copy of the log file will be needed for recovery to complete successfully.

Exchange appears to be running fine at the moment.

I have looked this error up and it looks like the log file specified may be permanently corrupt (I think this is what an error-501 means). Unfortunately a good version of that log file is too old to be on our backups.

There are various suggestions on the internet to run eseutil /mh to check the database and see what state it is in and see if that log file is actually required. Since this all require un-mounting the database, I am looking for the best first step to avoid any problems, for example, if the database won't remount. Is there a way, for example to back up everyone's email before unmounting the database, without going down the pst route?

share|improve this question
up vote 1 down vote accepted

I've just done an experiment in a VM to try and mimic your situation. I've purposefully corrupted one of the transaction log files and I'm using Windows Server Backup as the backup application. Everything I say below is based on this experiment, but reality shouldn't differ too much.

Even though you say it's all working fine at the moment, you are very right to be concerned about this error, and by asking this question you may well have just saved your future self some grief and panic.

First, some background on why you should be concerned. When Exchange successfully completes a backup, it flushes (deletes) the committed transaction logs, so if your backups are actually failing with this message there's a very good chance that your transaction logs are actually not being flushed and are building up. If the old transaction logs aren't being flushed, you unfortunately have a time-bomb on your hands that may explode at any moment (sorry for sounding so dramatic, but it is actually quite serious). When the volume the transaction logs are on fills to near capacity, the associated mailbox databases will dismount themselves until there is adequate space for new transaction logs. Depending on the amount of transaction logs you accumulate will determine when your mailbox databases will dismount themselves due to lack of space.

You're going to have to dismount the database to do what I suggest, however it should dismount without issue, and when I dismounted my database it was in a Clean Shutdown state, which is good news.

Dismount the database and just do a sanity check and run eseutil /mh <edb file name> to make sure the database is in a Clean Shutdown state. Next, move all of the *.log files except for E00.log and E00tmp.log somewhere safe out of the way (don't delete them, you'll need them back if it all goes tango-uniform). Once they're all moved, mount the database again and try a full backup of the database as soon as possible (it should be a full backup, not an incremental). That process worked in my VM, and hopefully should resolve your problem.

Warning: DO NOT __EVER__ delete transaction log files unless you are absolutely certain you know what you're doing. If you need to remove a transaction log from the equation, move it somewhere else, just don't delete it.

share|improve this answer
Thank for for your response. I will be trying this in the next day or two. – Dominic Fitzpatrick Aug 10 '11 at 7:55
I dismounted the database and copied the whole lot in case of typos. eseutil /mh reported a clean shutdown (hooray). I then moved the log files and remounted the database. A successful backup has just completed. Thanks for your answer! – Dominic Fitzpatrick Aug 11 '11 at 11:07
That is great news. Glad you got it sorted :-) Out of interest, were your transaction logs actually being deleted or were they just piling up? – Ben Pilbrow Aug 11 '11 at 12:25
They were just piling up. 3000 of them. I was only being emailed the Windows Backup/Operation event log ID 4 message that says the the back completed successfully. I have changed that to include ID 14 that contains the consistency check. – Dominic Fitzpatrick Aug 11 '11 at 13:25
Wow, impressive! Good job you solved the problem before the transaction log volume filled up then :-) – Ben Pilbrow Aug 11 '11 at 15:02

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.