Manage Learn to apply best practices and optimize your operations.

Timewasters, Part 2: Five more admin tasks you needn't bother with

Here's another batch of tasks that aren't worth the time and effort for busy systems administrators to perform them.

In October I listed five administrative tasks that weren't worth the time and effort to perform them. The high amount of interest the article generated prompted me to follow up with another list. So here's another batch of administrative tasks that aren't worth the effort.

1. Manually adding service packs to new OS installations instead of slipstreaming an install CD or file repository.

If you're constantly dealing with OS reloads, save yourself the extra step of having to add service packs, hotfixes and post-SP rollups by hand. It takes little time to add these things to an installation CD or file repository -- you can pick one day a month to do this, and thereby keep the image you're using for building new systems as fresh as possible. (If you're dealing with more workstations than you can comfortably re-image by hand, save yourself a step and look into automating that process.)

2. Supporting XP SP1 or Windows 9x.

This one should be a no-brainer, but I'll mention it here anyway. Any system with XP that's patched with anything less than SP2 should be upgraded or decommissioned immediately, and any system with Windows 9x should be upgraded stat, even if only to Windows 2000 as an interim step.

(Windows 2000 licenses go fairly cheap these days, at a fraction of the cost of a new workstation; a cursory search turned up several from legitimate resellers on eBay for about $50 or so.) In short: Don't support something that even Microsoft doesn't want to support anymore.

3. Full formatting a drive.

Once upon a time, putting a drive into service that hadn't had every single sector physically tested was madness. Go back far enough and you can find drives that came from the factory with a defect list pasted on the top of the drive, so you could pass appropriate instructions on which sectors to exclude during the format.

But with each succeeding generation of hard drive technology, drives have become more thoroughly spec'd out and reliable, to the point that it's no longer as necessary to physically test a new drive. Most drives—especially those in high-end RAID arrays—have self-checking mechanisms that can automatically detect physical problems and relocate data at risk. If you're determined to waste several hours performing a disk test that might simply be redundant, it probably won't do any harm, but it'll be sure to slow you way down. (Check your drive array's documentation for the straight dope on how new drives are provisioned.)

A major exception to this rule is if you're decommissioning a drive from service and don't want the data on it to be exposed to anyone outside your organization. In a case like that, don't even bother with formatting as a way to insure the data's wiped: go with a third-party program like Darik's Boot and Nuke.

4. Defragmenting workstations more than once a week.

Not long ago I wrote a series of articles about the benefits of defragmentation. One conclusion I came to was that on a system with reasonably modern hardware (anything less than three years old or so), defragmenting more than once a week in a workstation-type environment didn't provide any real, justifiable benefits. Defragmenting a workstation more than once a week is probably not going to help.

The real performance killer is fragmentation plus low free space; workstations with drives that are more than 75% full need to either be cleaned off or upgraded. Servers, on the other hand, can benefit from being defragmented more aggressively, but only when it's not at the expense of performance. Defragment servers during off-peak hours (i.e., 4AM) to keep the defrag process from slowing other things down.

5. Running CHKDSK in read-only mode.

CHKDSK needs to be run with the /F parameter to make any changes. This can only be done on a volume that hasn't been mounted: you can't run CHKDSK /F on a system drive without a reboot. Some people opt to run CHKDSK without the /F parameter—i.e., in read-only mode—to see whether or not a given partition needs to be error-checked in earnest.

The bad news is that CHKDSK in read-only mode doesn't give entirely accurate results about what might be wrong in the first place. It'll hint that something is wrong, but the only way to get a completely accurate picture of what might be wrong on a system drive is to run it with /F and reboot. The disparity of reports that you get when you run CHKDSK with and without the /F switch is due to files being locked for exclusive use.

If you're going to take the time out to run CHKDSK—whether because the dirty bit is set, or after a hard crash as a provisional measure—do it right the first time. Also, on drives that may have a lot of errors, CHKDSK /F will need to be run several times—at least until it no longer reports that it found any problems. A suspect system should be taken offline entirely until it passes muster. (If you're forced to run CHKDSK /F more than three times in a row, try booting to Safe Mode next time you reboot and seeing if that helps when CHKDSK runs.)

About the author: Serdar Yegulalp is editor of the Windows Power Users Newsletter, which is devoted to hints, tips, tricks, news and goodies for Windows NT, Windows 2000 and Windows XP users and administrators. He has more than 10 years of Windows experience under his belt, and contributes regularly to and

More information on this topic:

Dig Deeper on Windows Server troubleshooting

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.