0

Scenario:

  1. Exchange 2010 VM, running on VMWare
  2. 120gb of data
  3. Run window of Saturday 12am-8am (can be extended a little bit, if needed)

Two action packed questions:

  1. I want to unmount my datastores, take a snapshot of my Exchange VM, run a drive level defragmentation of C and D (database) drives, remount the datastores & remove the snapshot (if everything is ok).

  2. My other option is: take a snapshot of my Exchange VM, unmount data stores, run ESEUTIL offline & defrag C drive (not D drive?), remount the datastores & remove the snapshot (if everything is ok).

What are your thoughts? Am I taking the correct approach to defragging / error checking my exchange server?

Improve this question
5
  • First of all... Why? Exchange 2010 runs a background maintenance job (including online defrag), on all mounted databases, once every 24 hours (look for event id 1221 in the application event log). Second, what kind of disks are you using?
    – Mathias R. Jessen
    Aug 25, 2012 at 18:11
  • It says that the volumes are really fragmented.. Vmdk over iscsi NAS - SATA (not SSD)
    – InfoTech
    Aug 25, 2012 at 20:21
  • @infotech an exact error message, source and event id would be helpful.
    – Tim Brigham
    Aug 25, 2012 at 21:47
  • Ditto Mr.Jessen.
    – Simon Catlin
    Aug 25, 2012 at 22:36
  • Is the VMDK fragmented, or the files on it? Or both? If you've got a Thin provisioned, fragmented VMDK, an OS defrag won't help much.
    – HopelessN00b
    Aug 26, 2012 at 2:56

1 Answer 1

Reset to default
1

Before I went to all that work to defrag the drive + DB's just to satisfy a generic warning message, I would do a few things:

  1. What would you expect to get out of it? Exchange Server fragmentation is largely irrelevant to your users if they are all using Outlook cached mode. If Exchange is given enough RAM, it's storing chunks of each mailbox in RAM so your disks become less important. Modern Exchange is actually designed to run on slower disks then old Exchange (2000/2003).

  2. Defragmenting inside a VM is not what you think it is. You've got multiple levels of abstraction between your physical disks and the exchange DB's. You've got a RAID set serving up a LUN off of a shared set of iSCSI disks, how do you know if that LUN is contiguous on the actual disks? I doubt it is, especially if it's thin provisioned. Then you've got a .vmdk file you created in VMWare, which is likely fragmented itself. Did you thin provision it, or ever change the .vmdk size after initial creation? If you went through all these different levels starting with iSCSI, then to vmdk, then to guest OS, then to Exchange... what would it result in? Maybe faster OWA, if that...

Bottom line is I've never seen production systems that are virtual get defragmented and actually result in an improvement in the user experience. I'm not saying it's impossible to do... I'm just saying it's unlikely.

Tips on VMWare VM's and defragging: http://blogs.vmware.com/vsphere/2011/09/should-i-defrag-my-guest-os.html

One interesting quote from that link:

"I should point out that I have read that, internally at VMware, we have not observed any noticeable improvement in performance after a defragmentation of Guest OSes residing on SAN or NAS based datastores."

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .