Never mind the low idle time...need crash course on ESEUTIL /P ASAP!!! 1

[wahnula]

Well the server took a dive after the Internet came back...I went to plug in an external drive (backup 2, backup 1 is an IDE drive inside the SBS box) and everything went black. I remotely restarted it from a client and the RAID 1 was degraded again, even though there were no alerts in event log. Rebuilt it as always, system continued to boot. Still have the maxed-out CPU, but that's not the biggest problem anymore.

Everything else seems OK, except the Exchange logs & store, kept on the data RAID 5 array, are out of sync with the app. This has happened a few times before, resulting in a pro coming in and running ESEUTIL /P against the databases in 10 minutes and charging me $185. I'm not against a guy making a living, but I think I can do this myself with some guidance from the resident SBS folks here.

I am not an IT professional but love to learn and feel this is something I can handle. I've done a lot of web reading and research on the ESEUTIL procedure.

What I would like is a guide to setting up the command to re-sync the stores/logs with the app.

I have the Exchange data in a directory labeled "MBDATA" (yes I know) on the RAID 5 volume, which is assigned the letter L:

Inside the MBDATA directory there is another directory called "LYNNS2.log" (server name is LYNNS2) and its contents are the files E00.chk and tmp.edb.
Other residents of the MBDATA directory are the files priv1.edb, priv1.stm, pub1.edb, pub1.stm, and the log files priv1.INTEG.RAW and pub1.INTEG.RAW.

From my web reading, I know that ESEUTIL.exe resides in C:\Program Files\Exchsrvr\bin so my first command would be cd C:\Program Files\Exchsrvr\bin, correct?

Next, I'm guessing it would be eseutil.exe /p \L:MBDATA\priv1.edb , rinse and repeat on the priv1.stm, pub1.edb, pub1.stm ??? A little help loading the command line would be greatly appreciated. Thanks as always.

Tony

Users helping Users...

 

[ShackDaddy]

I'm heading out on a date with my wife, so I don't have a lot of time, but I'll tell you quickly that you don't run eseutil against the .stm file, only against the .edb file.

Also, your painting of the problem is a little off-base. The app and the database don't get out of sync. It's more that the database gets into an inconsistent state. If the store shuts down without a chance to properly process the logs, it's called a "dirty shutdown" and there are some basic things you can do, short of a repair, that sometimes resolve this. An esutuil /p shouldn't be your first resort when the store won't mount. There may be some other eseutil commands that will help you.

Beyond that, and more importantly, if the database state is the problem, then actually doing a restore of your Exchange database from backup and allowing it to automatically replay the logs created since you made that backup (automatically happens when the store mounts) should restore your mail to the point at which things crashed.

Hopefully some other locals can add to this and get you going.

Dave Shackelford
Shackelford Consulting

 

[wahnula]

ShackDaddy,

Thanks for the reply and the explanation. I have been trying to get my head around exactly how and why Exchange does what it does and have not been entirely successful. I even bought an Exchange book after checking the index for "eseutil"...when I got it home and turned to the page it said something like "eseutil is a tool for professionals and is too complex to describe here"...ARRRRGGGHHH

This Exchange problem has happened three times before, under the exact same conditions...problems with the RAID 1 array led to an unmountable store. All three times the tech ran eseutil /p and it solved the problem (after trying to recover from backup like you described).

Could this be because I have my transaction logs on C: and my store on L:? Looking into the C:ExchServer directory shows me today's log files.

Tony

Users helping Users...

 

[ShackDaddy]

Just try this (restore from backup) first:

http://technet.microsoft.com/en-us/library/aa996396(EXCHG.65).aspx

If that doesn't work, and the database won't mount, let us know here, post the event log errors. At that point you may want to copy your .edb/.stm files to a separate directory and then proceed with eseutil as in this article:

http://technet.microsoft.com/en-us/library/aa996436(EXCHG.65).aspx

Another option, if you are willing to lose all transactions since your last backup, is to move all your log files to a separate subfolder of your logging directory and then restore from backup. That will take you to the exact moment at which you ran the backup. But the normal goal is to recover up to the time of the actual crash.

Dave Shackelford
Shackelford Consulting

 

[wahnula]

Thanks Dave!

Tony

Users helping Users...

 

[ShackDaddy]

I worked with Tony on this, and while the sequence of events that led to the problem was somewhat convoluted, the end state seemed to be one in which the log files were older than the state of the database. Ultimately the only thing we did to resolve the problem was to move all the transaction logs out of the log directory into a subfolder.

Once we did that, the databases mounted without trouble. There weren't very many logs, and the state of the data seemed good to Tony, so we didn't worry about doing another restore and trying to engage the existing log-files in the recovery.

General concept to remember:

Most recent Database backup + log files since then = full recovery.

Older backup alone with no log files = recovery to a past point in time

Dave Shackelford
Shackelford Consulting

 

[ShackDaddy]

One more concept: when you do an SBS Backup you will first back up the C: drive, which will back up the mdbdata directory and all the transaction logs. Then the backup moves on to back up the Information Store, and after that completes, all transaction logs from before the backup are deleted.

So if you do a full restore, depending on your technique, it's possible to end up with a restored database and some logs that were from immediately before the Exchange backup, and the databases might not mount.

Dave Shackelford
Shackelford Consulting

 

[wahnula]

SHAMELESS PLUG: Yes, Dave did work with me on this, it was a fascinating educational experience (quick too) and highly recommended. Plus no empty Red Bull cans and Slim Jim wrappers to throw away afterward.

I'm not sure what exactly happened, as I followed the recovery guide from MS:

To restore your hard disks and system state, select the check boxes for the drives you want to restore and the system state. Do not check Microsoft Information Store because data stored in this folder includes Exchange Server data, and all Exchange Server data is restored from the drive or drives on which it is installed

...and Exchange worked perfectly after that restore. It was only after a subsequent reboot and necessary rebuild of the RAID 1 OS array that the database would not mount. I think I will move the logs over to their own directory on the same drive as the database.

I'm still trying to get my head around the relationship between the Exchange application, database and logs. Can anyone recommend a good book or source for this? Thanks again.

Tony

Users helping Users...