Defrag Exchange

Go to:

http://support.microsoft.com/default.aspx?scid=kb;en-us;192185&sd=tech

Scroll down to Exchange 2000/2003 Defrag.

Good Luck,

CT

...just to add a note.  Exchange 2000 has an online defrag which runs nightly.  It will not recover whitespace (1225 or 1226 event IDs, if memory serves me correctly).

Hi.  Defragging the Exchange database is pretty staright forward.  What you need to keep in mind is the size of the database to be defragged and the disk space available.  You need 110%.  If you don't have enough disk space, you can choose not to defrag the .stm.  Also, you can choose to place the temp file on another drive--to me that's theory because I've never had to do it.

Also keep in mind the speed of the server--the overall performance in combination with the free space.  If you have a quick server but only 111% free, the process could take a while.  You don't want to plan on defragging and have your users come in and have to wait several hours to use email.

When I defrag, I backup the server promptly at the end of the business day--Exchange services stopped because the DB will be defragged anyway.  Then, immediately after the backup, I begin the defrag.  If it takes longer than expected, it won't affect the users.

I didn't want to take down our server for the 'estimated' hours it would take for an offline defrag so we just created new mailstores and moved the users from the old to the new, then deleted the old.  Did the same thing a defrag would but we never had to go down and we were able to move a few users a night (more on the weekends) without the users ever knowing anything.  The only trick was we had to restart the BB service after we moved a bunch or BB users for them to sync.  Also of note was that the Outlook 2003 clients didn't have to recache...they just picked up where they were!  
Only problem we had was if a user left their Outlook open overnight they had an error in the morning telling them to restart Outlook.  PS...we also checked with MS before doing this and support said it was just as good as the full offline defrag!

Yup...I sometimes have had to create new mail stores and move users versus taking a store (150GB+ usually) offline for an offline defrag.

Best Wishes,

Bob

I was going to rename the Primary Mailbox Store. Is this ok to do or should I leave it. I am confused as well bec. in the event log it says that Primary Mailbox Store has 8806MB left but other Mailbox stores I have created have only like 13 or 16MB left. The reason I am asking is because I have like 6 diff. departments in my company and I am in the process of reorganizing exchange to make it easier to find users. Kinda like I have in Active Directory and OU's.

I'm thinking its based on a sql engine so you can't rename the store without adversely effecting a great deal of things...

I would not not recommend renaming the mailbox stores once they are up and running, with users on them.  It is, however, possible to rename the store.  You need to dismount it prior to renaming it.  Don't be surprised if you run into a few small errors...most of them, I remember, were easily mitigated by Googling the event ID.

....and I noticed that we were straying way away from the topic of defragging your Exchange server.

...and the event ID you are looking at, likely a 1221, is not saying what they have left to be filled with, but the whitespace left.

Might be a good time to start reading the Microsoft Operations Framework for Exchange 2003.
I worked for an organization that started to rely heavily on the Microsoft Operations Framework, or MOF.  While it does not detail step-by-step procedures, it does describe what tasks should be performed and at what interval they should be performed.

http://www.microsoft.com/technet/itsolutions/cits/mo/mof/default.mspx

At one time Microsoft published a full guide for Exchange.

http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/opguide.mspx

Hi.  I wouldn't recommend renaming the stores until you're on Exchange 2003.  Really, you should organize Exchange users based on mailbox functionality and potential downtime.  If all users are in one store, and that store goes down, so do all users.  Also, if an entire department were in one store, and that store went down, so too would the entire department.  That also could be a positive in that only one department would be down.  Also, the better the data split in the stores, the less space needed to defrag a database!

If, however, you were to organize the mailboxes based on functionality for ease of administration, say, perhaps, for mailbox limits, then your job would become easier.  If also you were to ensure that an entire department wouldn't lose functionality because a store went down, that would even be better.

Consider global settings, % of potential users down in a department, and the importance of the mailbox.  Split them accordingly.  When you look at the properties of the user in Users and Computers, you should be able to see the mailbox store.