Exchange corrupted message store

While again i do agree with cscharff, there is a way to find out which mailbox in particular owns the data which lies over the corrupted page.

isinteg -pri -dump -l isdump.txt

You will need to stop the information store, then make an offline copy at least.

You then run the above command which will dump the entire database out to the specified text file.

You then search the .txt file for "error" - When you find the error, see which mailbox is listed as having the data which points to the corrupted area.

The following article gets more detailed about the command.

XADM: How to Determine Which Mailbox Owns a Particular Page in a Database

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q262196

When/if you successfully track down the offending mailbox/es - you can recreate their mailbox/es after saving their data out, then import it back in. The corruption will then be in white space which will be detected after online maintenance has run. This way you may only have to rebuild 1 or a few instead of them all.

You can then run

eseutil /d /ispriv     (offline defrag) to get rid of the white space, which now holds the corrupted pages.

This is not gauranteed to work, but it's worth a shot if you do not want to do the first three options cscharff gave you. (Which is the best options if the command i gave you doesn't work)

Here's the quickest and probably least painful way...

Get a good, online, verified backup (better to get more than one). Write protect it and lock it away!

Take Exchange offline.

Copy ISPRIV.edb to another location (this is your "offline" copy--again, just in case.)

Run ESEUTIL /P and tear out the bad data.

Start Exchange and verify that all mailboxes still exist. Notify your users to verify that their own mailboxes are healthy.

This usually works with little to no noticeable data loss.

If something breaks, your next best option is to move mailboxes to a temporary Exchange server in your (Exchange) site.

Avoid exemerging mail out to PSTs and back in--you loose your single instance storage and your database can grow in size significantly. Moving mailboxes between Exchange servers preserves single instance storage and will leave data corruption behind.

cscharff.
I didnt want to use exmerge as i would loose the one instance storage and the HD wont be up to that.

kevala.
I Have already used the technique that you specified.
I had found out that the corruption was in the 1-24 Table
which when you search through the ISDUMP.txt you find out that the name is  the MDB Attachments folder.

Xeaza.
I had tried running the Esutil.exe /P but had not worked.
I like the idea of moving the mailboxes... I think my bridgehead server has room on it.

Ill try that next...

You're lucky that repairing the database didn't cause you to lose ALL attachments and much more (which i have seen countless times ) - repairing the database is never the best option if all it will cost you is disk space. If your disk space is more valuable than your data, then repair all day long. But as far as losing the least amount of data...the repair is not the way to go. It is always a LAST RESORT. Especially when the service is running and the DB is in production.

Exmerge will grab EVERYTHING except for exactly what is corrupt.

Repair - Possibly lose ENTIRE attachments table losing all attachments plus more

Exmerge - Costs you some disk space, but pulls the good data skipping only the corrupted information

I have a gut feeling that the move mailbox will fail on at least one, maybe more due to the physical corruption.....

In my experience-- :)

A "rip and tear", we call it (eseutil /p) usually fixes the problem with no "significant" losses. If the loses are seen as significant we use the move mailbox method (which preserves everything).

Using exemerge you WILL loose data.
   Single instance storage -- GONE!
   Rules will act differently (Server side rules will be unchecked--is this something you want your helpdesk to spend time on?--something to consider).
   Schedule+ is not supported. (no big deal)

So you see ... no option is perfect!

Here's the way we handle data corruption:

First preference: Restore from Tape.

Second preference: Move mailboxes (drawback--takes time)

Third preference: eseutil /p

Fourth preference: Find an old, successful backup. exmerge out all mail after that date. restore the old tape and exmerge in all the newer mail.

Fith preference: exmerge everything out and in.

Note: A mailbox move will fail on data corruption. That's the point that you switch over to exmerge and save what you can from that mailbox.

****************************************

Question: You said that eseutil /p didn't work. What went wrong?  

Okay - Eseutil /p - You have no control over how much data you lose. In your experience the dataloss has been minimal? Well in my 3 years of supporting the product, it hasn't. I take calls every day on disaster recovery, and eseutil /p as by far the last resort.

You can spend however long it takes repairing the database, then hope that you haven't lost entire table. And if you have, then oh well, or you'll be saying "Man i wish i would have just exmerged, this way i would have known for a fact that ONLY THE CORRUPTED DATA IS LOST" and not an entire attachments table or half the database which I see on a DAILY basis. (If you've been lucky, well i'm happy for you)

As far as the rules with Exmerge....All you have to do to preserve the rules is check all boxes on the export procedure tab....this will grab the rules...

Like i said in my first post, if disk space is more valuable than the actual data is, then repair it and take a Chance, instead of exmerging, costing yourself a little disk space  (preserving the rules), losing ONLY the corrupted data, and having a new database.

Exmerge is just more of a sure fire way to resolve corruption. Since you never no what is going to come of a repair, plus the fact that you have to run ISinteg after the repair (which doubles the time), you have more comfort and security with Exmerge.

You lose single instance storage, but the database size doesn't always grow that much, and even if it does, you have to weigh that against all of the time you might waste running a repair (un-necessarily).

If you don't run Exmerge, please go with the move mailbox option (which will still fail at one point or another)

I would just hate to see you waste your time repairing and fixing only to find out half of your data is gone and you will in fact have to go another route. (That's 30min to 1hour per gig X 3 wasted)

Sure you will lose a little data with each method

Eseutil /p - No telling, could lose half the database

Move mailbox - An entire mailbox, maybe more

Exmerge - I know i will only lose the one piece of mail that is on the corrupted page - (Man, that's great)

If you've got the disk space (Considering the database Might grow - Not for sure), the only sure-fire (and safest/Microsoft recommended) way to get it done in One shot and know for a fact you will lose the least amount of data (only corrupted) is Exmerge.

P.S. - In Exmerge, to preserve the rules, i meant all options on the Data tab - "associated folder messages" etc...

So what went wrong with eseutil /p when you tried it?

the guys onisite said that they started it and it just locked up, they left it all night as well... Im supporting this remotly... I think that I will have to go with the exmerge option... thanks for your help guys...

Regards

Hi guys, I'm reasonably new at exchange fixes. Can anyone tell how large a private store may grow if I use exmerge to remove attachments. One of my users emailed 40 of their workmates withing the organization (same mail server). Only problem is that she attached a 7 MB file to each. Now my store grew from 18 GB to 27 GB. My only hope here is to use exmerge to extract and remove the attachments ...correct?