Space required to run ISINTEG - fix

We have succesfully run ESEUTIL /P /CREATESTM on a our exchange 2003 edb after an offline defrag trashed the STM.
We now have a number of emails which can neither be opened or deleted which was expected.

Reading into this I now need to run ISINTEG -FIX to resolve this. Does anyone know how much space is needed for the refer.mdb file or any other advice before we run this? The .edb is 45GB and the STM is about 400MB
Who is Participating?

Improve company productivity with a Business Account.Sign Up

sunnyc7Connect With a Mentor Commented:
Usually the process is
a) Create a Blank Database, when you start defragging your EDB
Start mail flow using that. So that users can send / receive emails and Exchange is not out of action.
b) Do your eseutil's etc.
run isinteg's etc
run eseutil /cc
c) Load up the database in recovery storage group
d) Merge the EDB from RSG > to FSG

Given that you have already mounted the database, at this point we dont have anything other than isinteg -fix to test.
did you run eseutil /CC before running eseutil /p ?

insinteg -s SERVERNAME - FIX -Test Alltests

Isinteg doesnt need space. Those are required for TEMP.EDB files created during hard repair / offline defrag - for that 150% of space is advisable.

i woud day that is the ramification of running /p
running /p and /d should be used as the last resort..

restoring is back up is always better and recomended 

while isinteg -fix will  fix items at the store table level.. does not gatantuee
you will be able to open emails or attachments as the bad pages have been have been deleted by /p command

Thank you
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

omnisysAuthor Commented:
There was nothing wrong with the edb. We had to run /p /createstm because the .stm was the problem as it was corrupted during the defrag. We knew we would lose any mail held in the .stm. We are not hoping to open/recover any of the problem emails in the information store we just want to delete them but cannot. All the clients are outlook running in cached mode so we can recover any emails from the ost files on the local machines.

My question was really about the space required for running isinteg so thanks to sunnyc7 for the answer on that one.
My research has suggested that insinteg -s SERVERNAME - FIX -Test Alltests   will, if successful, allow us to delete these corrupt emails. I was wondering if anyone had found themselves in the same or similar situation and could advise?
omnisys - the emails are actually in the transaction logs I believe, not in STM files.
The STM file contains the mime data

If you are going to lose emails, that will be because the log files were not committed to the database.
That's why I was asking you about log-replay using eseutil /CC

Isinteg will run fine.
you will have to run it multiple times till you get ZERO errors. Same command.

I have done eseutil /p /d's many times, but didnt have to create STM files.

Let me know if you have any other questions.
omnisysAuthor Commented:
Thanks again sunnyc7. Do you think it's worth running /cc at this late stage? The 'disaster' was the weekend before last and we've backed up successfully every night since. Our main issue is just to get rid of the inaccessible emails.
I dont think /CC will help now :(

Infact a good test at this stage is this

eseutil /mh "c:\program files\exchsrvr\mdbdata\priv1.edb"

Check the shutdown state.
See the last date of full backup.
Check last committed log

start > run > calc
convert calc from DEC to HEX
enter the number there

that's the last committed log files.  in your c:\.....\log
omnisysAuthor Commented:
I ran eseutil /mh "c:\program files\exchsrvr\mdbdata\priv1.edb" before and after the repair and the shutdown state was clean. All the transaction logs are dated since last nights backup.
In your opinion, is it worth running isinteg - fix or are we stuck with these 'orphaned' emails?

Thanks again
You can run isinteg - fix.

then you can try eseutil /CC
then try to mount the DB.

We can give it a shot. Worst case it will error out.
omnisysAuthor Commented:
Ok, will give it go. Not sure when I'll get the opportunity to dismount the store but when I do I'll post the results.

Are we allowed to award points for good advice??

ok hang on a minute @

I didnt know that stores were already mounted. In that case
Please dont run eseutil /CC

I was under the impression that after eseutil /p /d and isinteg the stores are not mounted.

If mail flow has started that will create new log files. It will be tough to get old log files to commit to exchange server and might corrupt the database.

Yes Definitely @ good Advice.
omnisysAuthor Commented:
The store has been mounted since we successfully ran /p /createstm. The reason for running isinteg -fix was to fix the problem with the orphaned emails and funnily enough I've just found this ExpertsExchange post where someone had the same symptoms and it worked for them!
Did you try isinteg -fix ?
omnisysAuthor Commented:
Not yet. Just wanted to be sure it was the right thing to do as we appear to be in quite a unique situation and there isn't a lot of information on this particular problem.
omnisysAuthor Commented:
I will give it a go and poast the results. Cheers.
omnisysConnect With a Mentor Author Commented:
I was finally able to run isinteg -fix last weekend and we are now able to remove all the orphaned emails.

Thanks sunnyc7 for all your help.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.