Help Us Maintain Reliable, Bug-Free Systems--An Open Letter to Microsoft

As the time between service pack releases for both Windows 2000 and Windows NT 4.0 increases, we (your customers) face several challenging problems as we attempt to keep legacy and new platforms current and bug free. Most of us now support a mix of old and new systems, and just as your tasks as a major vendor have increased in technical complexity, so have ours. Daily, we face Win2K bugs, NT 4.0 bugs, and errors and omissions that impede interoperability between new and legacy systems.

To your credit, you regularly inform us of new security hotfixes, and you maintain a public Web site that contains this security information. At the security Web site, we can peruse updates and, when we determine that documented security vulnerabilities can adversely affect our systems, download them—without a phone call or a support call charge.

However, you leave us completely in the dark about nonsecurity updates for both Win2K and NT 4.0. Very few of us have any idea of how many post-Service Pack 1 (SP1) updates you've released for Win2K or post-SP6a updates you've released for NT 4.0. When we search for the appropriate string at the support Web site, we receive the maximum 200 entries in response. As you are well aware, the number of outstanding updates for Win2K and NT 4.0 far exceeds 200.

To help us do our jobs, we desperately need improvements to the OS-specific support structure. To start with, we need access to a comprehensive list of every post-SP1 update for Win2K and every post-SP6a update for NT 4.0 you've released. I receive mail from readers every week asking me where they can find this information, and—as of today—I've found no one source. You can solve this problem by creating a new Web site for each platform that documents every update you've released or plan to release before Win2K SP2 and NT 4.0 SP7. Each entry on the list should contain the Knowledge Base article reference number, the original release date, and information about patches that supercede the original, if any. In the best of all possible worlds, you would also include links to documented security hotfixes for each OS.

And please consider identifying whether you plan to include each update in the next service pack. If you don't plan to include a published code fix, we need to know why. For example, you might tell us that you developed the solution to a problem too late for inclusion in an upcoming service pack or that the fix applies only to a rarely used legacy hardware device. The Win2K and NT 4.0 update sites should remain current long after you release a service pack that combines the majority of the updates. With such information, customers who purposely delay a service pack rollout can check the status of and install critical updates you release in the interim.

Second, we need public access to the code fixes that correct documented errors or omissions. Many of us are highly trained. Those of us who maintain small to midsized businesses are capable of downloading, installing, and evaluating OS updates in a safe and nonintrusive manner—assuming, of course, that each update is thoroughly tested before release. Given the expertise we've acquired over many years, many of us find the cost of support calls and contracts difficult to justify.

Today, those of us who do not have support contracts (surely we number in the millions) determine through a time-intensive process of searching your Web site that our system behavior corresponds to a problem you have both documented and corrected. However, to obtain a documented bug fix, we must call support, set up a credit card transaction (for a charge that will be refunded), describe our problem to someone who frequently has less experience than we do, then convince that person to escalate the problem to the proper support level. This process is arduous, time consuming, and frustrating. We then must remember to check our credit card statements to verify that you have processed the support call refund charge in a timely manner.

You can significantly improve your effectiveness and response time, as well as customer satisfaction, with one easy move. Simply publish all known Win2K and NT 4.0 updates on a public site. If you want to track who downloads what, leave a cookie or ask us to fill out a short form. This is a small price to pay in exchange for timely access to an update. Without such access, we're frequently unable to complete a project or meet an important deadline.

If you can provide this support for security hotfixes, you surely can extend this vision to include updates released between service packs. As Windows XP goes public, even in beta form, the release will increase the pace once again. To keep up, you and your customers will need to work smarter and faster. Two new Web sites—one for Win2K and one for NT 4.0—that simply reorganize the information you currently have can go a long way toward accomplishing this goal. We need you to collect all the documentation for updates between Win2K and NT 4.0 service packs. We need to be able to download the code updates from a public site. Please help us do a better job.

Readers: If you agree with the ideas expressed in this column and/or you have additional suggestions, please send an email directly, [email protected]. I promise to collect and forward all your responses, both positive and negative. You might also consider posting your response on the Windows 2000 Magazine’s Web site in the Reader Comment section for this specific article.