It's been said that if something is not worth doing well, it's not worth doing. But if you're a Windows administrator, there are also some things that are not worth doing, period. I've put together a list of five tasks that are simply not worth the trouble for a busy admin.
1. "Urban legend" Registry tweaks. The Internet is rife with tips that describe Registry tweaks to change the behavior of Windows in any number of aspects. Some of these tweaks are quite useful. But many of them are simply obsolete -- for instance, the IoPageLockLimit value, which was used in the RMT version of Windows 2000 but was eventually phased out. Unless you have first-hand proof that a given tweak works, don't bother with it.
One reason why these tweaks tend to suddenly appear and then just as suddenly disappear is because Windows is a moving target. It's constantly being revised and updated, and those revisions include changes to the system "under the hood<" changes that improve performance and obviate the need for a given tweak.
The more Microsoft works on Windows, the more it becomes self-tuning, and doesn't need to be tweaked as aggressively as it used to. Any tweak described as "undocumented" should be considered especially suspect, because there's no guarantee you'll ever see it again.
More than a few time, I've fallen into this trap myself, both in using such tweaks and recommending them, and have deeply regretted it. I now try to persuade other people not to waste their time chasing these spectres. One way to determine if a given tweak is legit or not is to use a utility like Strings to parse the system files in the Windows directory for the Registry tweak in question. If you can't find a reference to that Registry entry in the system itself, chances are it's bogus.
2. Clearing the Windows Prefetch directory. Deleting the files in the Windows Prefetch directory is an "optimization" that has been repeatedly shown to do no good. In fact, it may even do more harm than good. The Prefetch directory in Windows contains information about commonly used files in the system—applications, system files, etc.—and uses this information to load them quickly. This directory, as well as its files, are self-maintaining; lesser-used files will eventually be removed from the Prefetch directory automatically.
Unless something has gone seriously wrong, it's not a requirement for you to delete anything from the Prefetch directory. . .especially the LAYOUT.INI file, which describes to Windows how system directories should be arranged. As far as I can tell, deleting this file will not cause it to be automatically rebuilt. At least one utility program, CCleaner, offers an option to clean "Old Prefetch data," which would, at best, be redundant.
3. Using CHKDSK /R to perform surface tests on some RAID arrays. The /R option in CHKDSK performs a surface test in an attempt to locate bad sectors and recover any data in them. It sounds like a good idea, but it's terribly slow. On some RAID arrays, it's both redundant and slow. For instance, the HP StorageWorks 1000 performs background surface tests on connected disks, and moves out data if it finds a bad sector to prevent future problems. Running surface tests through CHKDSK on such a drive is like polishing a no-wax floor. If the manufacturer has surface-test tools of its own, use those instead.
4. Performing spurious offline defragmentation of Exchange databases. Exchange 2000 and 2003 defragment themselves internally once a day, at 2:00 AM. Some Exchange administrators seem to get especially twitchy about the amount of space used up by the Exchange database, since the only way to compact the database files is to run ESEUTIL (which essentially recreates the database in an entirely new file). This takes anywhere from 1GB to 7GB of database space per hour (estimates vary widely), and you're going to have the take the whole database offline to do it.
Unless there's an urgent and overriding reason to run ESEUTIL—i.e., as part of a larger error-checking or crash-recovery operation, or when the database is not startable—and unless you have a current backup of the database, it's a waste of time to run it just for the sake of reclaiming free space. One way to determine if an offline defrag will be worth it is to inspect the application log on the Exchange server and look for event 1221, which contains an estimate of how much free space might be recovered.
5. Using memory "optimizer" utilities. I shouldn't even have to discuss this one at this point, but I'm amazed at how often I hear people talking about it. There are a bunch of utilities—some freeware, some shareware, some commercial software—that claim to "defragment your system memory," mostly by allocating and then deallocating large blocks of physical memory. Do not use them! Why? For the simple reason that they try to second-guess the way the memory manager works in Windows, which simply trades one set of problems for another. If you need more physical memory, buy it. Memory is cheap.
In the same vein, many people have claimed that disabling the pagefile in Windows produces a performance boost. I've seen some cases where this is true, but it comes at a risk of incurring spurious "out of memory" errors from some applications—and it's not always predictable when that will happen, or to what extent. The best results seem to come from setting the pagefile on a different physical drive than the Windows installation, and setting its size to be managed by the system. Again, second-guessing the system has a nasty way of backfiring.
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 SearchWinComputing.com and SearchSQLServer.com.
More information on this topic: