SB

Has anyone had any good/bad experiences when running a Defrag or Consistency Checker on Exchange 5.5

I am contemplating running this, but wanted some feedback first.

Cheers

shunty

don't do it unless:

1) - you need to
2) - you have fully restorable backup's (tested of course)
3) - you have 110 -125% of the size of your priv.edb (that's the big one) disk space spare
4) - you can get someone else to hit the "enter" button & take full responsibility
**do not log in with your username or tell anyone you are doing the defrag & then running the ISDS Adjuster, just blame the firewall team for changing the rulebase when exchange goes down

On a serious note get as much documentation as you can, read throughly & make sure you have someone on the other end of a mobile if you havn't done it before
I have some very good docs on exchange recovery, repair etc. If you want them let me know & I'll e-mail you them.

shunty

IanW

I have run it on a few occasions, the only draw back is the fact that it needs 110% of the space that the Information stores are using to complete.

Each time i have run it it has substantially decreased the size of the store.

ozzy

SB,

I defraged our PRIV.EDB and PUB.EDB at the weekend. The PRIV.EDB was 10GB and has reduced to around 4GB. Didn't have any problems whatsoever, but I only ran the /D defrag option. There's a MS article regarding the repair options and problems you might (or will) encounter.

I made sure I had a Full backup first, then stopped all the Exchange services, copied the PRIV.EDB and PUB.EDB to a PC and ran ESEUTIL /D PRIV.EDB, then ESEUTIL /D PUB.EDB from the copies on the PC.

I renamed them to PRIVNEW.EDB and PUBNEW.EDB and re-copied the originals back over to the workstation and deleted them off the Exchange box. That way I have the originals and modded ones on the PC.

** I only needed to do this as I didn't have sufficient disk space on the Exchange server **

I then copied the NEW files back across to the Exchange server, renaming them as PRIV.EDB and PUB.EDB.

I then restarted the services and hey prestor, it worked.

I checked the Event Viewer and noticed the services ran some checks on the new files.

The best thing to do is make sure you have a fast and reliable restore method if it goes pear-shaped. I had the choice of a restore from tape or simply copying the original files back across from my PC.

Stefan

dogmaul

oh dear there must be some really bad IT departments out there !! Dont you have any mailbox limits set and things like that i mean not to have room to do the defrag is quite shocking as you shouldn't let your free space fall bellow 50% really

ozzy

Ok I'll take the bait

Trouble with Exchange is, even if you delete mailboxes or delete loads of items, the databases don't re-use the disk space.

So, you might have limits set (as we do), but if a whole bunch of users leave (we employ hundreds of contractors), then you need to defrag after a while otherwise it'll keep on growing as people come and go.

Stefan

dogmaul

i know that, thats why ur supposed to do it every few months, also if you limit what they can keep it never gets too large or you could use and exchange archive program that can store old stuff in a different location

SD

Ahem. The decision for us not to have mailbox limits comes from our MD. He sees it as limiting people's ability to do their job properly. He's not technical.

We did ours over the weekend as it was 27GB. The point about it is it's just an enormous SQL database and when you create space inside the database by deleting mailboxes and mail items the database doesn't shrink dynamically. That's not to say the free space inside the database won't get re-used in the future - If you watch the size after deleting a few mailboxes then it'll stay constant for a while until that new free space inside the database is used up.

There are a couple of other reasons why you'd want to run eseutil /d. Like restoring the IS to a server with different NT service packs and so on. But as everyone says, make sure you have a backup!

Simon

[Edited by SD - 4/16/2002 1:38:59 PM]