To Fix or Not to Fix

People make mistakes. Programmers are people (well, most of us are). Ergo, programmers make mistakes. Therefore, software has flaws. (I don't like to call these flaws "bugs" because that makes them sound like cute, harmless little critters that just squirmed in—which they aren't.) Although many companies—including Microsoft—undertake rigorous testing procedures, no software is perfect.

For commercial developers, several software practices can reduce the incidence of flaws in delivered software. Microsoft rates well on the practices front, but even Microsoft developers occasionally slip up, and no organization builds flawless software from the start.

Microsoft has an extensive product-testing program. First, Exchange Server developers test code before they submit it for a build. Next, testers test the Exchange Server build. Then, the entire company runs the release candidate (RC) version well before Microsoft releases that version to the public—a practice known as "eating your own dog food" or just "dogfooding." Dogfooding gives Microsoft (or any company that follows the procedure) firsthand experience with how the product behaves under real-world conditions. Several partnership programs also exist to put products such as Exchange 2000 Server and Whistler in the hands of enterprise customers so that they can see how the products work for them. Build tests, integration tests, and dogfooding catch a large percentage of flaws. Beta tests by users catch an additional (but surprisingly small) percentage. But when the product ships, guess what? It still contains some flaws.

Vendors often offer postrelease product fixes that deal with the worst problems, but these patches can sometimes cause as many problems as they solve. How can you find out about these flaws and fixes, and where can you locate the fixes? How can you make the best use of available patches? How do you decide when to use a fix and when to hold off? Let's examine how Microsoft corrects flaws in Exchange Server (as well as in Windows 2000 and Windows NT) and how you can take advantage of Microsoft fixes.

In a Fix
Understanding how to apply post-release fixes depends on knowing what those fixes are and how they work. You'll see two kinds of fixes for Exchange Server and Windows-family products. The first type is called Quick Fix Engineering (QFE)—a term Microsoft now uses instead of "hotfix." The idea behind QFEs is that they fix a problem now, not later—in other words, they let you fix the problem before the next service pack release. QFEs aren't always regression tested (a fancy way of saying that although they fix one problem, you have no guarantee they won't exacerbate—or cause—another problem). Therefore, Microsoft recommends that you install a QFE only when you're experiencing the problem that it addresses.

In practice, most administrators grab as many QFEs as possible and slap the fixes on their servers. This habit isn't always the best course, but sometimes preventing a problem is better than waiting for the problem to occur. For example, suppose a QFE corrects a flaw that corrupts the Information Store (IS). You'd hardly want to sit and wait for the flaw to corrupt your store (even though the fix might cause another, lesser problem). But Microsoft doesn't test QFEs with third-party products and can't test every possible hardware and software configuration, so you should always first apply QFEs to a test system.

If a QFE is the software equivalent of an emergency patch kit for a flat tire, a service pack is the equivalent of an automaker-produced package that fixes or replaces several parts to make your car safer, more reliable—perhaps even faster. Service packs collect fixes for several (or many) problems into one unit and contain all the QFEs that Microsoft has released since the preceding service pack. For example, Exchange Server 5.5 Service Pack 4 (SP4) contains all the post-SP3 QFE releases in one easy-to-apply package. In addition, service packs are cumulative. In other words, instead of installing SP3 and SP4, you need to install only SP4, which includes the SP3 fixes and post-SP3 fixes in one bundle.

Of course, a service pack isn't truly one monolithic chunk; it's made up of files that replace or add to installed components of the OS or application to which the pack applies. The old-school approach to service packs bundled fixes and new features together in the same release, as when Microsoft introduced the Exchange Server 5.5 Move Server Wizard (MSW) in Exchange Server 5.5 SP1. But Microsoft seems to be rethinking that approach with Exchange 2000 Server and Win2K. The number of new features that the company will include in future service packs is unclear; Exchange 2000 SP1 introduced a few new features, but that trend might not continue.