Is there anything I should be aware of
You should seriously re-consider if you want to run an offline defrag. In most cases, you would not, unless:
- If you have deleted a large amount of data out o the store and want to reclaim the hard drive space for whatever reason. This includes situations when databases reach the 16 GB limit on Standard versions of Exchange server.
- If you had to run a hard repair of the database (eseutil /p - and that's another thing that we do NOT recommend unless this is a last possible thing to do). After running a repair, you should always offline defrag the database to get a new database file that has not been repaired. For more on what to do after the repair, please go here.
- If you are experiencing a specific issue and have found a reference that says offline defrag will fix it.
- If you are working with PSS and resolving the issue requires an offline defrag.
- As a general rule, only defrag to reclaim space if you're going to reclaim more than 30% of the space. You can look for Event 1221 after nightly online defrag to get a conservative estimate of how much free space is in the database. For more info on Event 1221, please go here.
Other than that, I personally have run offline defrags a couple of times over a network connection - it worked as expected. Your store is going to be offline for the time of the defrag and the database copy operation afterwards. Note this official statement from the Exchange documentation:
We do not recommend that you use a network drive to hold the temporary database. When you use a network drive for the temporary database, defragmentation will take longer, and any transient or permanent network error will end the process. Because defragmentation cannot be resumed, you would have to start over from the beginning.
Although the actual impact is rather limited. Server network connections do not tend to be interrupted all that often. And a defrag to a network location would presumably not run slower if your database file is located on a single hard disk or a RAID 1 array without a large write cache - the numerous read/write cycles caused by having the temporary file on the same drive would prevent large linear reads/writes and significantly reduce data throughput anyway.