Hello We are running Exchange 2003 SP2 on Windows 2003 SP2 servers. On one of our Exchange mailbox servers, the stores are getting a bit too large for comfort. This is the store where we locate Executive mailboxes with the higher mailbox limit. I guess we can run an offline defrag assuming Event ID 1221 says we are going to reclaim enough space or We can move the mailboxes to another (temp) store, delete the original store and recreate the original store Are there any other options? What do people recommend?

I never recommend an offline defrag. It takes too much time and their are risks associated with it. I suggest creating 2 new databases and splitting up the users among the two databases. The reason for not just one database, is that you will be in the same boat again in a few months. Keep the databases smaller and create more of them. Better performance and better DR/SLA implications.Tim Harrington - Catapult Systems - http://HowDoUC.blogspot.com

Thanks Tim. We'll go for the second option. Out of interest, what are the risks associated with offline defrag?

Whenever you take a store offline and perform an operation against it using isinteg or eseutil, there is always the possibility of something going wrong. Power, disk, corruption, or it winds up taking 12 hours when you were expecting it to last only 2 hours. etc etc...

Thanks both. Looks like we'll be avoiding offline defrags :) Out of interest, is it possible to make a copy of a database, run a defrag on the copy, and then - if that was succesful - mount that as the live database? This way, if there was an issue with the offline defrag we could always revert to the original db?

Yes. But of course, that means downtime because the production store will have to remain down during the offline defrag on the other copy. You can also use eseutil /b to create a backup copy.

Hmm...so let's say we do this. StoreA is the db we want to defrag. So we run eseutil /b to make a copy (I assume StoreA needs to be dismounted to make a copy?). Once we have the copy we mount StoreA. But we run the offline defrag on the copy of StoreA. Once the defrag has run, we dismount StoreA and then mount the defragged copy? Is that not possible?

During the defrag, store A is online and taking in messages, handling deletions, copies, moves, etc... So when you dismount and replace it with the defragged copy, you have just lost a few (hours?) of mail and information.

Good point :) So, if we were forced to carry out an offline defrag (for whatever reason), then would the best way to be? 1. Backup database, dismount and then defrag the db. If there is a problem, restore. 2. Backup database, dismount store and copy. Run a defrag of the copy. If there was a problem, then mount the original?

Depending on how much time you had and the size of the database, I would make a copy and then run the defrag, but since offline defrags are really unnecessary, you'll hopefully never be in that position :)

There are NO risks whatsoever with running of offline defrag. Always run offline defrag followed by isinteg. It is not recommended to delete the default mailbox store because it homes system attendant mailbox, smtp mailbox and system mailboxes. Thanks------Exchange, OCS------

On Sun, 5 Sep 2010 10:44:54 +0000, Dr. RPC wrote: >There are NO risks whatsoever with running of offline defrag. There are no zero-risk disk operations. To say otherwise is foolhardy. >Always run offline defrag followed by isinteg. Correct. >It is not recommended to delete the default mailbox store because it homes system attendant mailbox, smtp mailbox and system mailboxes. The store, or the database file? The mailboxes will be recreated if the database file is deleted. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Out of interest, why the need to run isinteg -fix (presumably) after the offline defrag? And regarding the 'special' mailboxes (system attendant, smtp etc) - what happens if these are located on a store we wanted to delete the white space for and were planning a mailbox move to a new store on the same server? Should we move these as well? Thanks everyone

On Sun, 5 Sep 2010 21:21:46 +0000, Joe Budden wrote: >Out of interest, why the need to run isinteg -fix (presumably) after the offline defrag? It's not a necessity, but it sure is recommended. The ESEUTIL program rearranges the database pages within the file but has no idea of the contents of those pages. The ISINTEG ensures that all the tables within the database are intact and, depending on the options you select, that things like folder sizes and item counts are updated and correct. >And regarding the 'special' mailboxes (system attendant, smtp etc) - what happens if these are located on a store we wanted to delete the white space for and were planning a mailbox move to a new store on the same server? Should we move these as well? With the exception of the system attendant mailbox, the others are specific to the database. The system attendant mailbox should be recreated in another database when you remove the one you're emptying. If that doesn't happen automatically, restart the SA service. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

On Sun, 5 Sep 2010 21:21:46 +0000, Joe Budden wrote: >Out of interest, why the need to run isinteg -fix (presumably) after the offline defrag? It's not a necessity, but it sure is recommended. The ESEUTIL program rearranges the database pages within the file but has no idea of the contents of those pages. The ISINTEG ensures that all the tables within the database are intact and, depending on the options you select, that things like folder sizes and item counts are updated and correct. >And regarding the 'special' mailboxes (system attendant, smtp etc) - what happens if these are located on a store we wanted to delete the white space for and were planning a mailbox move to a new store on the same server? Should we move these as well? With the exception of the system attendant mailbox, the others are specific to the database. The system attendant mailbox should be recreated in another database when you remove the one you're emptying. If that doesn't happen automatically, restart the SA service. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP I agree there are no zero risk operations. My statement is my own view stemming from numerous numerous offline defrags i ran as a part of maintenance on databases of various shapes and sizes. Never encountered any issue. Going by your logic there is risk in each and every maintenance operation but that does not mean we should not be performing them. Infact running offline defrag once in a while is highly recommended. and it is MUST after you have run an eseutil /p on the database. Sometimes people face issue after defrag is because they do not run isinteg just after defrag. ----- The system attendant mailbox defined for the server is automatically stored in the first mailbox database created during setup. If you delete the default mailbox database and/or storage group , the homeMDB attribute with the system attendant mailbox are no longer valid. and just wont be created by restarting the system attendant service. You have to re home (MANUALLY)the system attendant mailbox to point to the newly created database. Thanks. ------Exchange, OCS------

Running an offline defrag "once in a while" has never been highly recommended nor should be part of any regular maintenance. Microsoft says this themselves: http://msexchangeteam.com/archive/2004/07/08/177574.aspx "....offline defrag is definitely not something to do on regular basis. And it is typically not needed either" Any yes, after running eseutil/p , you need to run an offline defrag. But running eseutil/p is a last-resort option. Restoring from backups is preferred over a repair.

The system attendant mailbox will be moved automatically if the first store is permanetly deleted: http://technet.microsoft.com/en-us/library/aa996235(EXCHG.65).aspx If the store is then deleted, the System Attendant mailbox will be moved automatically into another mailbox store on the server, that is, the HomeMDB value on the directory object will be updated. The system attendant service must be restarted to reconfigure MSExchangeFBPublish to use the new mailbox location, and the mailbox object may not reappear under the Mailboxes node of Exchange System Manager until it is used in the future. If there is a System Attendant directory object but no mailbox object, the mailbox store object will be re-created automatically in the mailbox store referenced by the HomeMDB attribute as soon as it is needed. Note that one cause of this is using a blank store for troubleshooting.

On Mon, 6 Sep 2010 08:02:02 +0000, Dr. RPC wrote: >On Sun, 5 Sep 2010 21:21:46 +0000, Joe Budden wrote: >Out of interest, why the need to run isinteg -fix (presumably) after the offline defrag? It's not a necessity, but it sure is recommended. The ESEUTIL program rearranges the database pages within the file but has no idea of the contents of those pages. The ISINTEG ensures that all the tables within the database are intact and, depending on the options you select, that things like folder sizes and item counts are updated and correct. >And regarding the 'special' mailboxes (system attendant, smtp etc) - what happens if these are located on a store we wanted to delete the white space for and were planning a mailbox move to a new store on the same server? Should we move these as well? With the exception of the system attendant mailbox, the others are specific to the database. The system attendant mailbox should be recreated in another database when you remove the one you're emptying. If that doesn't happen automatically, >restart the SA service. --- Rich Matheisen MCSE+I, Exchange MVP >--- Rich Matheisen MCSE+I, Exchange MVP > >I agree there are no zero risk operations. > >My statement is my own view stemming from numerous numerous offline defrags i ran as a part of maintenance on databases of various shapes and sizes. Never encountered any issue. Going by your logic there is risk in each and every maintenance operation but that does not mean we should not be performing them. There's no need to run eseutil as part of any normal, day-to-day, maintenence activity. http://msexchangeteam.com/archive/2004/07/08/177574.aspx Do you take all your servers offline every day and run "chkdsk /f" on them? If not, why not? Do you take your servers offline every day and defrag the MFT? >Infact running offline defrag once in a while is highly recommended. and it is MUST after you have run an eseutil /p on the database. "Highly recommended" by whom? Certainly by the OEMs that tout their "perfromance improving" software. But who else? >and it is MUST after you have run an eseutil /p on the database. Before you run ISINTEG after ESEUTIL /P you should run ESEUTIL /D. There's no telling what the repair operation did to the database. >Sometimes people face issue after defrag is because they do not run isinteg just after defrag. No argument there. >The system attendant mailbox defined for the server is automatically stored in the first mailbox database created during setup. Yes, it is. >If you delete the default mailbox database and/or storage group , the homeMDB attribute with the system attendant mailbox are no longer valid. and just wont be created by restarting the system attendant service. Visit this link: http://technet.microsoft.com/en-us/library/aa996235(EXCHG.65).aspx See the 2nd bullet in the section "System Attendant Mailbox FAQ". > You have to re home (MANUALLY)the system attendant mailbox to point to the newly created database. I think you've been reading some misinformation. While you can't *move* the SA mailbox without making modifications to the AD (at least you used to have to do that -- I haven't tried using the UI to move it in, well, a long time) it certainly isn't necessary to move the mailbox if you're just removing the database. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

==================================== There's no need to run eseutil as part of any normal, day-to-day,maintenence activity. ==================================== Let go back to the scope of this thread, which is Exchange databases getting large. Reclaiming the white spaces by running offline defrag, because the database size has gotten big. This scenarion is not a day to day activity or daily maintenance opeartion. This is somehting one will do once and is not required to do like every week or month. ===================================== Do you take all your servers offline every day and run "chkdsk /f" on them? If not, why not? Do you take your servers offline every day and defrag the MFT? ===================================== No comments! ====================================== "Highly recommended" by whom? Certainly by the OEMs that tout their "perfromance improving" software. But who else? ====================================== Obviously recommended by Microsoft See the 2nd bullet in the section "System Attendant Mailbox FAQ". ===================================== I agree. This is how it should be as per 2nd bullet in section. But if one asks people who have worked on system attendant mailbox issues this is not always the case and especially if the default mailbox store has been deleted. If you delete the default mailbox store you may have to rehome the Homemdb attribte to point to the DN of the new/other mailbox store. ====================================== I think you've been reading some misinformation. While you can't *move* the SA mailbox without making modifications to the AD (at least you used to have to do that -- I haven't tried using the UI to move it in, well, a long time) it certainly isn't necessary to move the mailbox if you're just removing the database. ======================================= There is no misinformation. I have always maintained that need of rehoming arisies if the default mailbox store is deleted. System attendant mailbox points to the Distinguished Name of Mailbox store and is not related to the database files (.edb etc) itself. "When the default mailbox database and/or storage group are removed and recreated, the homeMDB associated with the system mailbox and system attendant mailbox are no longer valid. When a storage group and database are recreated, the system mailbox should be created and the system attendant mailbox rehomed to this store. The issue here is when these operations fail. When any of these operations fail, the following operations may also fail. Thanks http://blogs.technet.com/b/timmcmic/archive/2009/04/12/exchange-2007-renaming-the-default-storage-group-mailbox-database-or-deleting-and-recreating.aspx says ------Exchange, OCS------

On Mon, 6 Sep 2010 16:52:51 +0000, Dr. RPC wrote: [ snip ] >Let go back to the scope of this thread, which is Exchange databases getting large. Okay, let's. >Reclaiming the white spaces by running offline defrag, because the database size has gotten big. > >This scenarion is not a day to day activity or daily maintenance opeartion. Nor is it a necessary one. >This is somehting one will do once and is not required to do like every week or month. It also requires that the entire database be taken offline. Moving the mailboxes to a new database (if you have space to defrag you have space for the new database) and then removing the empty database is not only safer, it only inconveniences a few people at at time, and only for as long as it takes to move the mailbox. >===================================== > >Do you take all your servers offline every day and run "chkdsk /f" on >them? If not, why not? Do you take your servers offline every day and >defrag the MFT? > >===================================== > >No comments! I think you meant to say "Of course not." >====================================== > >"Highly recommended" by whom? Certainly by the OEMs that tout their > >"perfromance improving" software. But who else? > >====================================== > >Obviously recommended by Microsoft Where? > See the 2nd bullet in the section "System Attendant Mailbox FAQ". > >===================================== > > I agree. This is how it should be as per 2nd bullet in section. > > But if one asks people who have worked on system attendant mailbox issues this is not always the case and especially if the default mailbox store has been deleted. > If you delete the default mailbox store you may have to rehome the Homemdb attribte to point to the DN of the new/other mailbox store. "May have to" and "have to" aren't the same, are they? >?====================================== > >I think you've been reading some misinformation. While you can't >*move* the SA mailbox without making modifications to the AD (at least >you used to have to do that -- I haven't tried using the UI to move it >in, well, a long time) it certainly isn't necessary to move the >mailbox if you're just removing the database. > >======================================= > > There is no misinformation. I have always maintained that need of rehoming arisies if the default mailbox store is deleted. System attendant mailbox points to the Distinguished Name of Mailbox store and is not related to the database files (.edb etc) itself. > "When the default mailbox database and/or storage group are removed and recreated, the homeMDB associated with the system mailbox and system attendant mailbox are no longer valid. When a storage group and database are recreated, the system mailbox should be created and the system attendant mailbox rehomed to this store. The issue here is when these operations fail. When any of these operations fail, the following operations may also fail. > >Thanks > >http://blogs.technet.com/b/timmcmic/archive/2009/04/12/exchange-2007-renaming-the-default-storage-group-mailbox-database-or-deleting-and-recreating.aspx says Following the instructions would create a new, empty database. It doesn't seem to address the case where the empty database will be removed. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

============================================== It also requires that the entire database be taken offline. Moving the mailboxes to a new database (if you have space to defrag you have space for the new database) and then removing the empty database is not only safer, it only inconveniences a few people at at time, and only for as long as it takes to move the mailbox. ============================================== -My previous posts are nevr to estabilish the superamacy of offline defrag over move mailboxes. They are about clearing misconceptions surrounding offline defrag. ============================================== >Obviously recommended by Microsoft Where? ============================================== -Recommended by MS. http://support.microsoft.com/default.aspx/kb/328804 says Defragmentation helps increase data access and retrieval speed. When you defragment your hard disks, you can increase disk performance and help the servers in your organization run more smoothly and efficiently. ==================================================== "May have to" and "have to" aren't the same, are they? ==================================================== Yes, they aren't same and if you go through the complete sentence you will find that people who have woked on system attendant mailbox issues know what I mean. Because we have seen similar issues after the default mailbox store has been deleted. =============================================== >http://blogs.technet.com/b/timmcmic/archive/2009/04/12/exchange-2007-renaming-the-default-storage-group-mailbox-database-or-deleting-and-recreating.aspx says Following the instructions would create a new, empty database. It doesn't seem to address the case where the empty database will be removed. =============================================== I refernced this article to show the risks associated with deleted/renaming the mailbox store and also the need of manually rehoming the homemdb attribute. Thanks ------Exchange, OCS------

-Recommended by MS. http://support.microsoft.com/default.aspx/kb/328804 says Defragmentation helps increase data access and retrieval speed. When you defragment your hard disks, you can increase disk performance and help the servers in your organization run more smoothly and efficiently. That is referring to file-level disk defragmentation. Not Exchange offline defrags

-Recommended by MS. http://support.microsoft.com/default.aspx/kb/328804 says Defragmentation helps increase data access and retrieval speed. When you defragment your hard disks, you can increase disk performance and help the servers in your organization run more smoothly and efficiently. That is referring to file-level disk defragmentation. Not Exchange offline defrags Yeah, Same logic applies for Exchange databases as well.------Exchange, OCS------

Clicked the wrong button and proposed as answer. Oh well. That article is not Microsoft recommending Exchange offline defragmentation. In fact, as we pointed out eariler, they say just the opposite.

On Mon, 6 Sep 2010 18:42:03 +0000, Dr. RPC wrote: >============================================== It also requires that the entire database be taken offline. Moving the mailboxes to a new database (if you have space to defrag you have space for the new database) and then removing the empty database is not only safer, it only inconveniences a few people at at time, and only for as long as it takes to move the mailbox. ============================================== > >-My previous posts are nevr to estabilish the superamacy of offline defrag over move mailboxes. They are about clearing misconceptions surrounding offline defrag. > > > > > >============================================== >Obviously recommended by Microsoft Where? > >============================================== > >-Recommended by MS. > >http://support.microsoft.com/default.aspx/kb/328804 says > >Defragmentation helps increase data access and retrieval speed. When you defragment your hard disks, you can increase disk performance and help the servers in your organization run more smoothly and efficiently. Ummm . . . that part of the paragraph is referring to *disk* defragmentation. Assuming you have each database on it's own disk/volume/lun the amount of file (disk) fragmentation is minimal and hardly ever becomes an issue. >==================================================== "May have to" and "have to" aren't the same, are they? > >==================================================== > >Yes, they aren't same and if you go through the complete sentence you will find that people who have woked on system attendant mailbox issues know what I mean. Because we have seen similar issues after the default mailbox store has been deleted. Okay. Here's the complete sentence: "If you delete the default mailbox store you may have to rehome the Homemdb attribte to point to the DN of the new/other mailbox store." Those are your words, not mine. Nobody's saying there aren't sometimes problems. But to say there are always problems is incorrect. So I'm agreeing with what you said, that ". . . you MAY have to . . ." >=============================================== >http://blogs.technet.com/b/timmcmic/archive/2009/04/12/exchange-2007-renaming-the-default-storage-group-mailbox-database-or-deleting-and-recreating.aspx says Following the instructions would create a new, empty database. It doesn't seem to address the case where the empty database will be removed. > >=============================================== > >I refernced this article to show the risks associated with deleted/renaming the mailbox store and also the need of manually rehoming the homemdb attribute. That blog's not going to be much help to the original poster who's running Exchange 2003. If he has a problem it's ADSIEDIT time. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

On Mon, 6 Sep 2010 19:36:23 +0000, Dr. RPC wrote: [ snip ] >That is referring to file-level disk defragmentation. Not Exchange offline defrags > > Yeah, Same logic applies for Exchange databases as well. How many hundreds (thousands) of extents must there be before you'd you'd defrag the database, remove all secondary indexes and whitespace, and then immediately begin expanding the defragged file and rebuilding all the indexes? How many hours of downtime to defrag the database vs. what small percentage of improved perfromance (if there really is any)? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Good question. In exchange 2003 the rate of defrag is approx 5 Gb/ hour. In exchnage 2007 it is approx 10GB To know more about the indexes and structure of your exchange database file you can run eseutil /ms on the database. Multiply the output by 4 and the resultant number would be the amount (in KB) that you will reclaim after the defrag is over. Defragmenting the database not only helps in reclaiming white spaces but it also makes makes used storage contiguous and there by increase in performance. Thanks ------Exchange, OCS------

Do you work for GoExchange?

Do you work for GoExchange? No Sir, I donot work for GoExchange.------Exchange, OCS------