MS Exchange problem

Did you test the database first?

Here are some tips



Note: Add the path to your Exchsvr\Bin directory to your Environmental Variables PATH statement.  That way you can execute ESEUTIL from within your MDBDATA directory.

Note: Delete log files whenever instructed by ESEUTIL or ISINTEG

Begin by stopping the information store service

Open a command prompt and navigate to your Exchsvr\MDBDATA directory

Check for Clean Shutdown
Run the following commands
    Eseutil /mh priv1.edb
    Eseutil /mh pub1.edb
Check for logs needed. If the report shows Logs Required 0/0 then delete all log files.
Delete *.log
If the shutdown was clean, skip to the defrag section of this FAQ.

OK, so IF the logs required was not 0/0 then lets try and repair the database.  The text in bold that follows are the commands you need to run.

Attempt a Soft Recovery

    Eseutil /r E00
 
If soft recovery fails, do a hard repair

    Eseutil /p priv1.edb
    Eseutil /p pub1.edb
    Delete *.log
    Mount and then dismount stores one at a time.

OK, by now your transaction logs should all be committed.  Let's move on and defrag the database to free up the space within the database that was being used up by deleted users.
 
Defrag the database

Before you defrag the database, you need to decide if you will perform the defrag in the current database or instead you can choose to have a brand new database created by the defrag.  The latter choice will give you a new database and even tighter defragmentation than the former.  Using this scenario the original database remains intact so there is less risk involved.

Verify that you have sufficient disk space to have two copies of your database in the same location.  If you do not then the defrag will fail.  If you are low on disk space, use the /t switch to identify WHERE to create the temp file used by ESEUTIL.
I'll outline the differences in the commands needed below.  

Quick and simple defrag:

Open a command prompt.  Navigate to the location of your database files.  If you added the Exchange bin folder to your path statement as specified above then you do not need to include path information to the ESEUTIL command.  Execute the following commands.


    Eseutil /d priv1.edb
    Eseutil /d pub1.edb
 
Start the Information Store service
Dismount the stores in Exchange System Manager
Note: if no repair was needed above you can start your stores again and you are done.  Please note that Microsoft recommends mounting and dismounting the stores after a defrag.

Creating a new database during defrag:

    Eseutil /d priv1.edb /t <tempfilename.edb> /p
    Eseutil /d pub1.edb /t <tempfilename.edb> /p

At the conclusion of the above commands you will have new EDB and STM files with the names specified in tempfilename.  Archive off or rename your current database files and then rename the newly created files to Priv1 and Pub1.  Move these files to the same location as the original database, you can then start the Information Store Service.

For those who have been experiencing errors logged in backups due to mailbox corruption, then the following will be really important to you.  You will want to run ISINTEG to fix any errors in the database itself.  It is important to run ISINTEG multiple times until you either get no errors, or you get the same errors reported each time.

Repair Errors In the Database With ISINTEG

    Isinteg -s servername -fix -test alltests

Note: This is important so I will repeat this point.  ISINTEG should be run multiple times until it returns either no errors or the same errors repeatedly.  At a minimum it should be executed twice.

At this point you should be able to return all services etc. to normal operation and allow users access to their mailboxes.

No.  I didn't test the database.  Also to justify what's happening, I was getting serious trouble from the client side.  Even though the local server and address were successfully resolved.  The client would not sync with the server.  Also re-asked for a psw which was a bit odd as it was already authenticated??

Cannot do much at the moment as the fileshare on the server is being used by the clients working.

Thanks,

S

Yes this is a difficult process.

I would scheduled testing your database to make sure you have now corruption.

It's certainly turning out to be difficult! :0  Is there a repair tool to check the database/  your instructions are a bit complicated in parts.  don't want to screw it up if you know what I mean?

Thanks again

S

Yes

use this

Repair Errors In the Database With ISINTEG

    Isinteg -s servername -fix -test alltests

You can search for more info on ISinteg

Hi.  Tried to run the ISINTEG but said it didn't recoginse the server?

Syntax correct and server decription wise, tried:

Isinteg - s server.kelleyko.local etc
                  kelleyko
                  kelleyko.local

Can't find it though?