Is this procedure/command correct to defrag an Exchange 2003 mail store offline? In viewing MS documents I found some differences, options, quotes, no quotes, etc. Exchange Server Info: - SBS 2003 SP2 - eseutil program is located in C:\programfiles\exchsrvr\bin - Exchange Database is located in separate drive partition (X:\exchsrvr\mdbdata\priv1.edb) - New temporary defragged database is to be written to S: drive partition - Not enough space to do instate defrag (110% needed) on X: drive 1. Dismount Store 2: cd C:\programfiles\exchsrvr\bin 3. eseutil /d /p X:\exchsrvr\mdbdata\priv1.edb /ts:\tempdfg.edb Are these steps correct after defrag is run? 4. delete the old priv1.edb and priv1.stm data bases in the X: drive 5. rename new tempdfg.edb and tempdfg.stm on S: drive to priv1.edb and priv1.stm 6. Move new priv1.edb and priv1.stm from S: drive to X:\exchsrvr\mdbdata 7. Remount Store I'm doing this offline defrag because I am running out of space and I have recently deleted some large mailboxes. Thank you in advance for your comments, corrections, and suggestions.

You are aware that on Exchange 2003 Sp2, the limit on the database size takes in to account the white space? You don't have to offline defrag to keep below the 75gb limit. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources

assuming you still want to do it despite of Sembee advise 1. you should NOT have the /p in step 3 that's for repairing a database 2. steps 4 5 6 are not needed eseutill will take care of this Full time IT consultant since 1998 mainly on Exchange\ISA\AD MCSE NT4.0,2000/2003, CCNA MCITP: Enterprise Messaging Administrator 2007/2010 MCT since 2001

Agreed with all and post /D I would run ISINTEG - Fix as wellTroy Werelius www.Lucid8.com

Agreed with all and post /D I would run ISINTEG - Fix as wellTroy Werelius www.Lucid8.com

Actually in this case the /P in the command line use put forth is not for a Repair its to tell ESEutil to not copy the defragmented EDB back over the original EDB. So remove that /p command from your syntax and you will not have to copy the files back in place, instead ESEutil will do the work for you. More on the command here http://www.lucid8.com/faq/faq_GEvsMStools8.asp Agreed with all and post /D I would run ISINTEG - Fix as well Troy Werelius www.Lucid8.com

Thank you for your comments...re: not have /p in step 3 and not necesaary to do steps 4,5, and 6 I understand that if I remove the /P switch and leave the /ts: option then the priv1.edb and priv1.stm database will be defragged on my S: drive, with the temporary database names of tempdfg.edb and tempdfg.stm. After the defrag is completed, eseutil will automatically rename the new temporary databases and then copy them back into my X: drive (X:\exchsrvr\mdbdata\priv1.edb and priv1.stm) overwriting the old databases. Is correct?

Thanks for your response. I have 40GB X: Drive Partition for Exchange Mail. I'm using 34GB. I understand the only to reclaim the space that some large deleted mailboxes were using is to do an offline defrag? The rate my users are adding emails it won't be long until I will out of space.

Additional ideas from my previous post If you have another available local drive, the other option would be to create a new EDB on that alternate drive and then move the mailboxes into the new EDB and upon completion of moving all users you can delete the original EDB. All of this of course depends upon how much true slack space you have in the EDB. Look for event 1221 which you should see nightly and it should tell you how much slack space is in the EDB and IMO its a bit conservative, i.e. you will get more then it says but its a good guideline. Other issue could be that users are utilizing the "Deleted items" folder as a filing cabinet, i.e. never deleting anything, so if you can get them to empty those items it may help Other issue to look at is the Deleted Item retention settings, i.e. if its set to 30 days than that means anything deleted today will not be available to truly clear up EDB space until 30 days from now and thats assuming that the online nightly maintenance process runs without fail http://www.lucid8.com/faq/faq_GEvsMStools2.asp Another thing to consider is that in the end your best move may be to add a larger new HD and move the database there Troy Werelius www.Lucid8.com

Perfect. /p is to preserve the temp database in the destination drive. That is just to make sure that we dont have any kind of corruption or issue while copying back the temp database back to original location over network or whatever mediaVinod |CCNA|MCSE 2003 +Messaging|MCTS|ITIL V3|

I agree on the premise/reason its used but in reality its really not safer IMO and also slows things down because; From a best practice standpoint I would first make a copy of the existing database before I took any action Then I would run the /D without the /p command because Eseutil will do all the work of replacing the old file with the newly created file without any need for interaction on the admins part Eseutil is also more efficient at moving the file back in place then say a straight copy and again it doesn't have to wait on user interaction If for some reason Eseutil has a failure during the copy back process you are in no worse position then before because the temp file still exists for you to manually copy back as does your backup copy. Troy Werelius www.Lucid8.com

I have one final question that I would your insight on: Most MS KB articles and other forum posts show syntax examples with no quotes around the path. But I have seen a few that strongly recommend it. For example: eseutil /d "X:\exchsrvr\mdbdata\priv1.edb" /t"s:\tempdfg.edb" Is this necessary or desirable? Thanks again for all your help.

really depends on the path used. I use them by default since having them doesn't hurt anything and causes less frustration if you end up with a long file name path, i.e. it will just workTroy Werelius www.Lucid8.com

I Ran offline Defrag and then Isinteg check after defrag. No issues. It took 9 hours for both...34GB Store. Thank you all for your assistance...

Happy to assist and glad all went wellTroy Werelius www.Lucid8.com