Avatar of iMonkey69
iMonkey69 asked on

Exchange 2007 failure to mount error -1216 (JET_errAttachedDatabaseMismatch, An outstanding database attachment

Hi.  I have an exchange 2007 server and after a "compact" was done on it's virtual instance.  I seem to have come into a dirty shutdown state and now cannot mount it.

State: Dirty Shutdown
Log Required: 489316-489335 (0x77764-0x77777)
Log Committed: 0-489336 (0x0-0x77778)

Running recovery fails on this command:

eseutil /r e00 /l "E:\Program Files (x86)\Microsoft\Exchange Server\Mailbox\First Storage Group\bak" /d "E:\Program Files (x86)\Microsoft\Exchange Server\Mailbox\First Storage Group\Mailbox Database.edb" /a

After testing and trying to re-run the log files I get an error:

Operation terminated with error -1216 (JET_errAttachedDatabaseMismatch, An outstanding database attachment has been detected at the start or end of recovery, but database is missing or does not match attachment info) after 0.328 seconds.

All the log files check "Ok" on eseutil /ml E00

There is NOTHING on the web of how to bypass this or even just take a loss of the 5 hours it was down and get it mounted again.

I do not want to run a eseutil /p for fear of even more damage.  

Does anybody know how to get rid of the attachment inconsistency and get this mounted again.

I don't have enough disk space to even do all the defrags etc as it builds an entire db in-line.

crud...need some help:-(

ExchangeWindows Server 2008Email Servers

Avatar of undefined
Last Comment

8/22/2022 - Mon
Seth Simmons

Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
Sign up - Free for 7 days
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
See how we're fighting big data
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a question

Holy crud.  You're magic. I think I had tunnel vision.  I DID see this, but one article switched on /a which errored.  This still has me in a "dirty shutdown" state.  

Have a next step on that?

Seth Simmons

couple things...

1) i noticed in the eseutil /r command you ran it shows the path as program files (x86) - are you running 32bit version of exchange or is that just happen to be a manual path created on that volume?

2) it's been a while since i've needed to do a database repair (since 2003 days) so trying to remember everything...if you notice the link i sent with the /d switch it specifies a path while you have the total database name.  without having a 2007 server in front of me at the moment, transaction logs are per storage group, not the database itself so it would be the path where the database group resides (notice the 4th screenshot in that article).  have you tried with /d using just the path to first storage group instead of directly to the .edb?

I did get to the "path" only solution.  Have not managed to shake the dirty db.  I have the "required" logs, but they don't seem to be helping.  I'm not sure what triggers them.  I've separated them in a "back" folder with the E00.log file, but although it did complete with /i option, now I seem to be getting the following. Running with /a returns the same.  So, I'm not sure where the logs are supposed to be in or if that's a red herring?

Recovery has indicated that there might be a lossy recovery option.  Run recovery with the /a argument.

n terminated with error -528 (JET_errMissingLogFile, Current log file missing) after 0.219 seconds.
Experts Exchange has (a) saved my job multiple times, (b) saved me hours, days, and even weeks of work, and often (c) makes me look like a superhero! This place is MAGIC!
Walt Forbes

An update to that.  Separating the required files in a back with the old E00.log returns the lossy error.  if they are in the regular log dir the /i and /a return completed, but the dirty state stays the same.

dang it. feels so close.  a /p will take 2 days I'm sure.
nashim khan


Please move the log file to other location and desable any third party antivirus service.And then try to mount the same.

Nashim Khan

The end result was that I was lucky enough to have a backup from 12AM the previous night.  The virtual VHD file compact seems to have been the culprit to some degree.  Ultimately, I learned a whole lot with the eseutil command prompt.  I never did use the repair /p command although I started it on a copy to see how long, and holy cow....that's a risky proposition with a DB of any significant size.  I certainly could not wait for that.

From the backup (with logs) I managed to commit the logs and get to a "Clean State".  I copied that into the production directory after clearing out ALL other chk and log files and mounted it to allow fresh files.  It was unfortunate as while I had my current log files still, one in the middle of ~10 had an off time stamp, and from what I gather it's done at that point unless you want to wait 3 days for a /p run with zero guarantee's.  

I believe users were at risk of losing some email between I'd say 1-2am and 9am. Not a bad compromise being on a Saturday and the jury is still out if they get sent on a retry later.

Thanks seth2740, I think I was deep into tunnel vision and you gave me great perspective and a clearer head with a few tips to boot.  Much appreciated.

We're live and after 33 hours with 1 hour's sleep all systems are even better(all that maintenance while waiting;)

A Good lesson in validating your backups!!  Without that, 15 years of data would have been gonzo!!

Get an unlimited membership to EE for less than $4 a week.
Unlimited question asking, solutions, articles and more.

Sooo happy guys like this are out there in the wee hours when it counts!!