However, eseutil should never be executed as a part of routine maintenance. Never as a part of routine maintenance. (Yes, I repeated that phrase.) We are in complete agreement there ! You'll grin at the situation with the Exchange 5.0 that crashed, as much as I remember... A single Compaq server with Exchange 5.0 SQL 6(.5?) ArcServe (including Exchange Bricks-Level agent) TM1 ( pivot table data analysis ) Office 95 Office 97 w Access 97 and I'm sure a few other tidbits competing for memory and cpu Came in one morning to a 'unknown application error' ... event logs weren't clear as to which app puked first ... ultimately got the store back online by end of day, only to find out that although they were doing daily backups, they never did a RESTORE test, the backups were useless <g>
Erik Goldoff IT Consultant Systems, Networks, & Security _____ From: Michael B. Smith [mailto:mich...@theessentialexchange.com] Sent: Friday, December 19, 2008 4:49 PM To: NT System Admin Issues Subject: RE: Exchange Puzzle I missed Mr. Ross' original message. Eseutil may certainly very well remove item and folder data from the store, if it cannot validate the data. Same for isinteg, at a different level. (ESEUTIL works at the ESE [Jet] level. ISINTEG works at the Exchange application level.) A defragmentation is always a lossy operation - it will always remove indices (which can be very expensive to reconstruct). However, it will not remove user item and folder data unless it detects some corruption. That can be a single message, a single folder, a single mailbox, an entire message store - and pretty much anywhere in between. A repair is AT LEAST as lossy as a defragmentation. Best practice says not to use eseutil unless you are certain that it is necessary and appropriate; preferably under the guidance of CSS/PSS. That being said - I'm sure quite a few people are capable of making that decision properly for themselves. However, eseutil should never be executed as a part of routine maintenance. Never as a part of routine maintenance. (Yes, I repeated that phrase.) This is my guidance, but it's also Microsoft guidance; and has been for a number of years. Your best bet is to move-mailbox and remove the old store. Let's see..I've been an IT professional since 1980; so I've got 28 years in the saddle from that perspective. I started working with Exchange in 1996, so I've got a dozen years in that saddle. In my career, what I've seen: #1 cause of downtime - poor change management. #2 cause of downtime - poor backups #3 cause of downtime - admin/management arrogance #4 cause of downtime - inadequate testing #5 cause of downtime - cheap hardware YMMV. Regards, Michael B. Smith, MCITP:SA,EMA/MCSE/Exchange MVP My blog: http://TheEssentialExchange.com/blogs/michael I'll be at TEC'2009! http://www.tec2009.com/vegas/index.php From: Erik Goldoff [mailto:egold...@gmail.com] Sent: Friday, December 19, 2008 4:36 PM To: NT System Admin Issues Subject: RE: Exchange Puzzle last Exchange crash I used it on was Exchange 5.0 where the store would not remount, and I was brought in to help in a hurry, the man in charge didn't want to 'waste' time with backups or images, or consistency checks first ... after running, the store *did* mount, but was waaaaay lighter than before the crash ... I've got about a dozen years in the saddle too, but still remember that one time Erik Goldoff IT Consultant Systems, Networks, & Security _____ From: Michael Ross [mailto:mr...@itwif.com] Sent: Friday, December 19, 2008 1:18 PM To: NT System Admin Issues Subject: RE: Exchange Puzzle Eseutil never removes data from the store.. if you run it with a /d or /g, it doesn't remove emails, or calendar data, or mailboxes for example Then again, if you run it and lose data, the database was in poor shape anyway and that needed to be done to insure you didn't have another crash later. You could always restore to a RSG, and exmerge any missing data out of there to a PST and exmerge it back into the live database if need be. Eseutil is your friend, never be afraid to use it with the proper switches. Always do a /g first and if its consistant, do a /d to defrag it. A defrag will never hurt the database. (to be honest, and not to insult anyone, that's 12 years of Exchange experience coming out of my brain) Ive never, ever, lost data doing a defrag, even back to the days of 5.5 From: Erik Goldoff [mailto:egold...@gmail.com] Sent: Friday, December 19, 2008 11:16 AM To: NT System Admin Issues Subject: RE: Exchange Puzzle yeah, but IMNSHO, I'd try to image the drive first to at least preserve current state for multiple troubleshooting efforts... sometimes, as we all know, eseutil is like removing cancer, you often find that you removed wanted material along with the mess Erik Goldoff IT Consultant Systems, Networks, & Security _____ From: Michael Ross [mailto:mr...@itwif.com] Sent: Friday, December 19, 2008 12:10 PM To: NT System Admin Issues Subject: RE: Exchange Puzzle Yes it will . id run eseutil and clean up the white space in the db.. I know that's not a popular statement to make, but it would at least make the database contiguous and consistent to say the least. From: Erik Goldoff [mailto:egold...@gmail.com] Sent: Friday, December 19, 2008 10:37 AM To: NT System Admin Issues Subject: RE: Exchange Puzzle Hmmmm, not an SBS expert (actually not even a fan) but does that version of Exchange get rid of the 16gb store limit that Exchange Enterprise does ? Erik Goldoff IT Consultant Systems, Networks, & Security _____ From: Jim Majorowicz [mailto:jmajorow...@gmail.com] Sent: Friday, December 19, 2008 11:11 AM To: NT System Admin Issues Subject: Exchange Puzzle I've got a client (SBS 2003 SP2) that has a fairly large DB for the Private store. I had set the DB Size Limit in GB to 64 GB, but yesterday at 5 AM it spontaneously reverted back to 16GB after failing a defrag and of course dismounted the store. When I checked to make sure it was working properly after changing the setting back I couldn't help but notice some discrepancies in the numbers. The 9690 event that took the DB offline shows the size at 48 GB. At 8 am, when the 1216 and 9685 events that report the failure to mount (done before coffee or even a check of the event logs), the size reported was 53 GB. The 1216 Event after I fixed the DB Size Limit in the registry, still said 53 GB. To really confuse me, the Usage Report (Which is what I use to monitor the size of the store in the first place) shows the total of all mailbox sizes to be 38,623.8 MB, which is about 37.5 GB... In the effort of full disclosure, this server is bane of my existence. It eats SCSI drives for lunch on an almost quarterly basis. It has had a critical failure in the past year that forced me to restore from backup. I've been hesitant to ESEUTIL this store because of the trouble I had getting the damn thing back online after the restore. Still, I'm a little worried. I don't have anything in either the APP or SYS logs that show what the heck happened at 5 AM to change the DB Size Limit, and I'm a little hesitant to blow off a 16 GB gap in reported size differences as simple whitespace. Anybody have any insight, or should I just run the ESEUTIL and hope it cleans up the issue? ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
