Exchange online and offline defrag

With Exchange 2003 Enterprise, Exchange 2007 and Exchange 2010 there is no need to run an offline defrag of the Exchange database. All of these versions will allow the creation of another mailbox store. Once you have another mailbox store you can simply move the mailboxes from the fragmented store to the new one. This will provide you with a fully defragmented and error free mail store with the added bonus of no down time.

In Exchange 2003 Standard Edition with Service Pack 2 there is a soft database limit that can be set up to 75GB. Many believe that simply running an offline defrag of their data store will help them to stay below the limit. This is simply not true.

The 75GB limit in Exchange 2003 is a soft limit and it is based on the LOGICAL size of the database not the PHYSICAL size. The logical size of the database can be loosely calculated by taking the combined size of the EDB and STM files minus the free space reported in Event 1221 in the Application Event Log. Guidance on finding the true size of the stores can be found here: http://technet.microsoft.com/en-us/library/aa996139(EXCHG.65).aspx

By default, Exchange 2003 will run online maintenance every day, normally at around 5am. Part of this maintenance is to run an online defrag of the database. Details of what other tasks are run as part of the online maintenance can be found here: http://support.microsoft.com/kb/324358

Once the online maintenance has been completed there will be an event 1221 generated in the Application event log. There will be one for each store. The description will say “The database "\ ()" has megabytes of free space after online defragmentation has terminated” this event shows how much free space is in the EDB file (it does not include the STM file).


Creating “white space”

The free space that is reported by Event 1221 is often referred to as “white space”. This free space will be used by Exchange before expanding the physical size of the database. If your database has reached the 75GB limit then you will need to create free space to bring the logical size of the database below the limit.

The easiest way to do this is to delete any unwanted mailboxes and ask your users to archive some mail or delete mail that is no longer required.

Depending on your deleted item retention period, this may take a long time to be seen as free space. If you are trying to alleviate an immediate problem, then you can speed this process up by setting the deleted item retention periods to 0. This will make any items that are deleted, permanently deleted rather than sent to the dumpster, where you can recover them with the tools, Recover Deleted Items option in the Deleted Items folder within Outlook.

This will then hopefully bring you below the logical limit of your database.

Only if PHYSICAL storage on your server is a problem should you perform an offline defrag of the database to recover the free space reported by Event 1221. If there is no free space reported by Event 1221 then an offline defrag is a complete waste of time.


Offline Defrag

If you have read all of the above and you are still convinced you need to perform an offline defrag of the Exchange database then I would recommend you follow these guidelines:


•To run ESEUTIL you need to open a command prompt and change the folder to "C:\Program Files\Exchsrvr\Bin". This is the same for all the commands listed below
•Perform a FULL backup of the Exchange Information store using either Windows Backup or a 3rd Party Backup product. It must be an Exchange aware backup and it must be a FULL backup of the store not a brick level backup. This will ensure all the transaction logs are flushed.
•Dismount the store and make a copy of the STM and EDB Files to another drive. Consideration needs to be taken for the fact that the defragmentation process needs a minimum of 110% of the size of the store in free space. So if your store is 75GB you need an extra 83GB of free space. If the drive that the store is on does not have enough space then move it do a different volume and perform the defrag there. Alternatively you can direct the temporary database to a different volume using the following command: ESEUTIL /d "C:\Program Files\Exchsrvr\MDBDATA\Priv1.edb" /tD:\Priv1Temp.edb
•Run the ESEUTIL /d “C:\Program Files\Exchsrvr\MDBDATA\Priv1.edb” command to start the defragmentation.
Please note that depending on the specification of the server and any other additional tasks that it may be performing, you should expect a defragmentation of a database to run at a rate of between 4 and 7 GB per hour. So if you have an 80GB file it could take up to (and probably longer) 20 hours to perform a full defrag. During this time the Exchange Server will be unavailable to users.