Defragging HD on Exchange 2003/Server 2003
Hello everyone, I just inherited an Exchange 2003 server and was told to "make it work better". I don't have a lot of experience with exchange, but I've already gone in and started working with the Best Practices tool and I'm looking to upgrade to 2007. First, though, I'm wondering about defragging. I checked the volumes we have (C: and E:) and they are both pretty bad. Everything I've read so far talks about not defragging Exchange, but I'm nervous about the state of these drives. So my questions are: 1) Can I defrag the C drive without anything bad happening (I;m pretty sure nothing exchange related is there, but maybe AD)? 2) If I want to defrag E, I just have to turn exchange off, move the datastore, defrag and do the others in reverse, right? Or should I not even worry about it? For references, here are pictures of the analysis of both drives: C Drive - http://i56.tinypic.com/fegxgx.png E Drive - http://i54.tinypic.com/2r1zntw.png
February 14th, 2011 10:43am

You don't need to perform a file level defrag. Your partitions should only contain DB on one and logs on other. When you do this, file level fragmentation is pretty much negligible. If you're running into performance issues, I would focus elsewhere then the culprit being file level defragmentation even if the analyses shows fragmentation. Do we need to file-level defragment Exchange database drives? http://msexchangeteam.com/archive/2004/10/25/247342.aspxJames Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com
Free Windows Admin Tool Kit Click here and download it now
February 14th, 2011 11:36am

If you are using the Exchange performance analyzer, spend some time and review the read, write times on each drive. The results will tell you if you are having slow access to these drives without defragging. Also, you will see things like memory settings and the /3gig switch. /3GB /USERVA=2970 - In my case the userva works best at 2790. The most important will be the read and write times for starters. Do you have those results?
February 14th, 2011 11:49am

If you are using the Exchange performance analyzer, spend some time and review the read, write times on each drive. The results will tell you if you are having slow access to these drives without defragging. Also, you will see things like memory settings and the /3gig switch. /3GB /USERVA=2970 - In my case the userva works best at 2970. The most important will be the read and write times for starters. Do you have those results?
Free Windows Admin Tool Kit Click here and download it now
February 14th, 2011 11:50am

You should definitively defrag your C drive. NTFS does next-to-nothing to prevent file fragmentation. As to your Exchange(E:) drive, this is even more alarming. You have only 5 % free space left. You won't be able to defragment that volume, and it is not necessarily the best idea. Do you have the Exchange databases and transaction log files on the same volume? Do you use an Exchange-ware backup utility that removes old log files? Anyhow, you should ensure you have more free space than that. A common threshold is 20 %. In general best practices suggest to have your transaction log files on a different volume. As to Microsoft's recommendations about what to defrag on an Exchange server, I only know what System Center Operations Manager 2007 R2 tells on Exchange 2010, that is defragging the OS and program files volume and the volumes that hold the transaction log files. However, a general recommendation has for a long time has been not to defragment database volumes,which not might be true in all situations, but keep it as a guideline. How to move Exchange databases and logs in Exchange Server 2003? http://www.messagingtalk.org/how-to-move-exchange-databases-and-logs-in-exchange-server-2003 MCTS: Messaging | MCSE: S+M
February 14th, 2011 6:05pm

As Jon mentioned, to achieve the best results from Disk Defragmenter, it’s recommended that the volume has 15 percent of its space free for the utility to use. Hence, please move the databases and log file to some other volume and then run Disk Defragmenter on drive E again. As an additional information, please refer to the following article: http://technet.microsoft.com/en-us/library/cc778290(WS.10).aspx Thanks. NovakPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Free Windows Admin Tool Kit Click here and download it now
February 17th, 2011 12:00am

I work for a defrag vendor (disclaimer) and see the benefits of defragmenting Exchange servers all the time. The blog post from the Exchange dev team has some inaccuracies and is limited in scope. Can defrag be I/O intensive - yes. That does not mean the effort impacts production. Keep in mind that post is from 2004 and technology changes. There are defrag products that can move small pieces of files (i.e. a fragment or part of a fragment at a time) when there are idle resources available. While not as sophisticated as third party solutions, low priority I/O used by the built-in defragmenter in Win2k8/Vista OS and above, allows the process to be less intrusive than in older OS versions (i.e. your 2k3 server). As for the statement, in that post, that there is no benefit, that is based on theory and is simply incorrect. Obviously file defragmentation will only benefit to the degree there is fragmentation, but it does help. You can validate with Perfmon (baseline and post-defrag). Monitor split I/O and latency-related counters. Michael Materie, Diskeeper Corporation
February 21st, 2011 4:06pm

I agree, read everything with a grain of salt, I have seen many reports from end users seeing benefits after doing disk level defrags even when DB and logs are isolated to their own parititions.James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com
Free Windows Admin Tool Kit Click here and download it now
February 21st, 2011 4:37pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics