Thanks to everyone who responded to my May 14 column about the size and frequency of service packs. After all these years, I'm still amazed at the Internet's power to keep us connected. Although the bulk of responses came from the United States, I also heard from readers in UK, Norway, Germany, South Africa, Australia, New Zealand, and several locations in Canada.
I tabulated the responses, without any personal information except location, in Table 1. Table entries are organized by the preferred frequency of service pack releases, starting with zero, and ending with monthly. Several responses made me laugh, including one that suggests that Microsoft developers adopt a techie version of the Hippocratic oath that states "First, do no harm...." My personal favorite is the response at the top of the list from a reader who stated, "I would prefer Microsoft release an OS that works. " Although we might accuse this individual of pie-in-the-sky thinking, I know deep down we all agree with this premise.
According to the responses, big shops opt for an annual service pack update, and small shops prefer monthly updates. I'm sure one reason for this size-specific preference is that big shops have service level agreements (SLAs) and can easily obtain interim bug fixes, while small shops must wade through the painful process of dealing with Microsoft Product Support Services (PSS) and the whole credit card charge/credit fiasco. I suspect another contributing factor is that large networks are more complex and require rigorous testing to validate a service pack for production systems, while small shops are less diverse, require less testing, and can release updates more quickly. Overall, more readers want service packs two to four times per year than once a year.
One theme that emerged from the responses is the concept of cumulative updates for all known bug fixes across all products and platforms. A cumulative update is a superset of all previously released code fixes plus new changes. Microsoft does make service packs cumulative, and we saw the first such cumulative update of security hotfixes in Security Rollup Package 1 (SRP1) earlier this year. As with a service pack, you must reapply SRP1 every time you add, remove, or modify OS components. If you're not familiar with this SRP1 requirement, read the Microsoft article "Windows 2000 Security Rollup Package 1 (SRP1), January 2002, Release Notes" at http://support.microsoft.com/default.aspx?scid=kb;en-us;q315683.
The advantage of the cumulative approach is that you can guarantee that all available updates exist on a machine each time you install a new bug fix or hotfix. Unfortunately, each cumulative download is larger and takes more time to install. I think the trade-off is acceptable, given that most systems suffer from update bloat anyway, which means that if you haven't updated your OS for a week, it's probably not current. For small shops with less time and technical expertise, cumulative updates are a great solution. Until Microsoft can truly stabilize the OS, the cumulative approach is probably the fastest and easiest method for ensuring that an OS contains the most recent version of files that are common to multiple patches, whether OS or security related. Many of you also suggested quarterly service packs, with a cumulative version at the end of each calendar year.
One savvy reader pointed out that although we can often install Microsoft Exchange Server, Small Business Server (SBS), and SQL Server updates without rebooting, many of the fixes Microsoft releases for Internet Explorer (IE), Windows Media Player (WMP), and other utilities require a reboot to complete the installation. To build a new Windows 2000 client, this reader must reboot the system eight times. Although the Qchain utility might reduce the number of reboots, the process is inefficient and a very sad commentary on the state of the most widely used technology on the planet. The reboot requirement is a consequence of the method Microsoft uses to implement the tech tinker toys. As this reader points out, Microsoft can circumvent this reboot requirement by implementing add-on components as services that you can stop, modify, and restart. I heartily endorse this suggestion.
Other common suggestions include a single download location for all updates, regardless of the platform or product; the ability to download and distribute updates internally using functionality similar to Windows Update or the Corporate Update site; using .msi installer package format for all updates (hear, hear); updates bundled by a fixed number of updates (e.g., 250); public distribution of all bug fixes without requiring a call to PSS; and solutions that address bandwidth concerns for downloading and distributing mammoth updates to a mobile workforce.
Microsoft has promised that Service Pack 3 (SP3) will include a new version of the Critical Update Notification client. When we combine this client with planned changes to the Corporate Windows Update site, we should be able to download updates to our internal servers for internal distribution. These two features will reduce the complexity of managing the current update process. But the list of concerns is still long and, coming full-circle, I refer back to the pie-in-the-sky comment I started with: "Microsoft should release an OS that works."