Last Friday, I cleaned up my office. Hauling out three garbage bags of outdated flotsam, packing up three boxes of books, and rearranging the ancient (and heavy) furniture led me, naturally enough, to wonder about cleaning up Exchange Server systems. If you like your office better when it's clean, wouldn't you like your Exchange servers better that way too?
The first step toward cleaning up is jettisoning old email. Whether or not you believe in setting mailbox limits, most of us are stuck with finite storage resources and budgets. Therefore, in most cases, limits predominate, primarily because they make it easy to estimate the maximum amount of storage you're likely to need on a server. You can use the Exchange Mailbox Manager and Outlook's Auto-Archive feature to help reduce the volume of data in your Exchange databases, which leads naturally to another cleanup-related topic: defragging the Exchange database.
Even when you remove information from the Exchange database (say, by deleting 15,000 copies of MyDoom from your users' mailboxes), the database files won't shrink unless you do an offline defrag. (The best analogy I've heard is from Exchange MVP Ed Woodrick. Think of a balloon made of molten steel. When you blow more air into the balloon, its size will increase, but the balloon will never shrink back to a smaller size, even if you let air out of it.) An offline defrag of the database might seem like a good idea, but most administrators know that regular offline defrags aren't necessary for a simple reason: Exchange recycles unused-but-allocated space in the .edb file before allocating additional extents on the disk. And the amount of data that the Exchange .edb files contain isn't necessarily the same as the amount of on-disk space they consume. In a few cases (e.g., when you're dangerously low on disk space), an offline defrag might make sense, but typically there's no good reason to perform one. What about .stm files? The Exchange Information Store (IS) automatically defrags the .stm files associated with the Exchange Server 2003 or Exchange 2000 Server .edb files, and on a more aggressive schedule than the nightly online defrag of the .edb files. This behavior occurs because the .stm file provides streamed access to Internet-format MIME content, and performance suffers if the IS must hop around within that file instead of reading the requested data in a neat linear stream.
One thing many administrators don't know is that, if left unchecked, other kinds of gunk will build up on your servers. For example, Exchange never removes messages that a connection or a sender filter drops in the Badmail folder (so that you can review the messages to ensure that none of them are actually important). You can delete these files at any time, though, and several intrepid admins have written scripts to automate the process. You might periodically need to groom various log files (including the Microsoft IIS protocol logs and message-tracking logs) as well, although when doing so, avoid throwing away information that might be useful for security logging. (Remember, if you didn't log it, it didn't happen.)
You can consider cleaning other things, too, such as your list of user accounts and mail-enabled contacts, but I'll save those for another day. I have a sudden urge to go out to the garage and organize my toolbox.