microsoft.public.windowsupdate

Long-form reference · 9,952 words · about a 43-minute read

An address that used to move

The file name of this page ends in _messages, and that suffix was once a promise. On the mail-to-news gateway from which this directory descends, an address of that form did not merely describe a group; it showed one. The page rendered a list of the most recent articles the gateway had seen in microsoft.public.windowsupdate, and it changed as the feed changed. What survives at this address is the group’s identity rather than its contents: the name, the description that travelled with the name, and the administrative paper that documents both.

That is an unpromising basis for an article, and it would be a fatal one if the only thing worth saying about a support group were what its members happened to say. It is not. A newsgroup named after a software distribution service is a piece of evidence about the service: about when it was thought to need a room of its own, about what the vendor called it, about which neighbouring rooms it was given and when. And the service itself — Windows Update — is one of the better-documented pieces of consumer software infrastructure of its period, because almost everything it did was announced, numbered, dated, criticised in public and, on several occasions, undone in public. This article is built from that record and from the group’s own paperwork.

The group belonged to microsoft.public.*, the hierarchy Microsoft ran on its own news server and fed outward onto Usenet. How a software company came to operate newsgroups on an open protocol, who did the answering, what the Most Valuable Professional award was and how the whole arrangement was shut down between June and October 2010 are the business of the hierarchy’s hub page, and none of that is retold here. This directory holds no second page for this group, so what follows is the whole of what the site has to say about it.

The group’s own paperwork

The Internet Systems Consortium mirrors the Usenet administrative record, and for a corporate hierarchy that record is thinner than for the Big Eight but not empty. Its control archive holds one file for this group, and that file contains exactly one article. It was sent from [email protected] on Thursday 31 January 2002 at 11:10:45 Pacific time, approved by the same address, injected from a host recorded in the headers as tide84.microsoft.com and carried outward through the Microsoft news host that appears at the end of the path as tkmsftngp01. The body is two lines: the line reading “For your newsgroups file:” followed by the bare name of the group. There is no description, no charter, no rationale and nothing a Big-8 proposal would have recognised as a justification. There is also no removal message, anywhere in the archive, which is the mechanical reason the name is still in circulation a quarter of a century later.

That single date is worth more here than the equivalent date is worth for most of this hierarchy, and the reason is a quirk of the archive that this programme has documented elsewhere in the microsoft.public.* branch. On the morning of Monday 27 November 2000, the same Microsoft address issued a bulk re-announcement of the hierarchy: hundreds of names went out inside a few minutes, carrying timestamps clustered around 10:40 Pacific, including names for groups that plainly already existed. The Platform SDK security group’s page sets out the evidence for that reading in detail. Because of it, a 27 November 2000 stamp establishes only that a name was in the namespace that morning, and never that it was created then.

microsoft.public.windowsupdate is not in that batch. Its file opens fourteen months later and holds nothing earlier. That is still not a birth certificate — an article can be missing from a mirror — but it is a good deal closer to one than most names in this hierarchy can offer, because the sweep of November 2000 collected a great deal of what existed at the time and this name was not among it. The honest statement is that the name entered the propagated namespace on 31 January 2002, and that nothing in the record places it there earlier.

The date sits in a legible part of the calendar. Windows XP had reached general retail availability on 25 October 2001, ninety-eight days before, bringing with it both a redesigned Windows Update client and the background transfer service that client would come to use. Microsoft’s internal turn towards security, and the memorandum that announced it, belong to January 2002; that story is told on the Platform SDK security page and is not repeated here. A support room dedicated to the update mechanism, opened at the end of that month, is at minimum consistent with a company that had just decided patching was going to matter more than it had.

The other half of the paperwork is the present tense, and it comes from two files rather than one. ISC’s configuration directory carries a current active file and a current newsgroups file; the copies read for this page were fetched on 25 August 2026. The active file — which is what a news server actually consults — carries 1,770 names beginning with microsoft., and at line 37,100 sits this one. It records the group with a high-water mark of zero, a low-water mark of one and the flag y, meaning posting is permitted. In plain language: the group exists, it will accept an article, and it holds none.

Descriptions have to be sought elsewhere, because ISC’s newsgroups file carries no entry for any microsoft. name at all — the hierarchy appears in that mirror as bare names in the active file and nowhere else. The descriptions live in the hierarchy’s own newsgroups list, the list maintained alongside the PGP-signed control messages that keep these names propagating, and which carries the same 1,770 names. There the entry is a name and a description separated by a tab, and the description reads, in full:

microsoft.public.windowsupdate — Microsoft Windows Update newsgroup.

That is not a charter and was never intended as one. It is a vendor label of the kind the whole hierarchy carried, generated from a product name. It is worth noticing all the same that it is a product-specific label rather than a subtree placeholder. Several update-related names in the same list carry the description of the branch they sit in rather than of the thing they are about: microsoft.public.win2000.windows_update is labelled “Microsoft Windows 2000 newsgroup”, microsoft.public.win98.internet.windows_update is labelled “Microsoft Windows 98 newsgroup”, and both microsoft.public.windows.server.update_services and microsoft.public.windows.live.onecare.update are labelled, flatly, “Microsoft Windows newsgroup”. This group is not. Somebody wrote the words “Windows Update” into it deliberately.

The name outlived the server that announced it, the service it was named after in the form that service then had, the company’s news operation and the protocol’s commercial heyday. It is still listed because removing a name from a distributed namespace requires somebody to take the trouble, and for this name nobody ever did.

Sixteen names for one problem

Read the surviving namespace for update-related names and the shape of the problem appears without any need to open a single group. Sixteen names beginning with microsoft. refer to updating in the active file as it stood on 25 August 2026. They are microsoft.public.windowsupdate, its Italian, Japanese and Polish counterparts under it, jp and pl, microsoft.public.officeupdate, microsoft.public.microsoft_update_catalog, microsoft.public.softwareupdatesvcs, microsoft.public.windows.server.update_services, the German, Spanish and French update_services groups, microsoft.public.win2000.windows_update, microsoft.public.win98.internet.windows_update, microsoft.public.sms.software_updates, microsoft.public.windowsce.updates and microsoft.public.windows.live.onecare.update.

Sixteen rooms for one function is not redundancy; it is the catalogue naming this hierarchy used, applied to a service that touched every product line. The hub page explains why a vendor namespace multiplies doors where a consensus-run one would argue about consolidation. What the dates add is a chronology, and the control archive supplies them, one file at a time.

• 30 August 1999 — microsoft.public.win2000.beta.windowsupdate, a group for the Windows 2000 beta programme, announced not by Microsoft but from an unrelated outside address in Sweden: one of the stray control articles any open namespace accumulates. Microsoft removed the name itself on 18 February 2000, the day after Windows 2000 reached retail. It carries the earliest date attaching to any name in this archive that contains the string “windowsupdate”, and it is not Microsoft’s.
• 3 February 2000 — microsoft.public.win2000.windows_update, a genuine Microsoft announcement, arriving between the release of Windows 2000 to manufacturing on 15 December 1999 and its retail launch on 17 February 2000. Its file also holds a second, outside newgroup message sent from a German host on 7 August 2000, which is the same phenomenon as the 1999 article above.
• 27 November 2000 — microsoft.public.win98.internet.windows_update and microsoft.public.officeupdate appear in the bulk re-announcement, at 10:40:33 and 10:40:14 Pacific respectively, and those are the only articles their files hold. The batch establishes that both names were in the namespace that morning and nothing more. That it was a re-announcement rather than a creation is settled by the Windows 2000 group two lines above, whose file holds the genuine February article as well as a 27 November one timed at 10:40:31.
• 31 January 2002 — the group this page is about.
• 15 April 2002 — the Japanese counterpart.
• 17 June 2004 — the German, Spanish and French update_services groups, all three timed to the same second, 15:18:51 Pacific.
• 1 July 2004 — microsoft.public.windowsce.updates.
• 22 September 2004 — microsoft.public.sms.software_updates, for patching through Systems Management Server.
• 1 November 2004 — microsoft.public.jp.softwareupdatesvcs, announced twice the same day, at 08:14:42 and again at 10:12:59 Pacific.
• 6 June 2005 — microsoft.public.windows.server.update_services.
• 21 September 2005 and 26 January 2006 — the Italian and Polish counterparts.
• 21 June 2007 and 14 September 2007 — microsoft.public.windows.live.onecare.update and microsoft.public.microsoft_update_catalog, both announced not by Microsoft but by Julien Élie, the outside volunteer who maintained the hierarchy’s PGP-signed control messages.

Three of those entries repay a second look. The first is 6 June 2005, the date on the newgroup message for the Windows Server Update Services group. That is the day WSUS 2.0 was released. A vendor hierarchy could do that — open the support room and ship the product on the same date — and the correlation is exact enough to be worth stating, because it is the clearest surviving illustration of how these groups were created: not by proposal and vote, but by a product team filing a request.

The second is what Julien Élie’s articles say about themselves. They are not Microsoft messages and do not pretend to be. The 14 September 2007 article for the update catalogue group explains that the newsgroup “has recently been created on Microsoft news servers so I send this PGP-signed control article to improve its propagation”, and asks administrators to add the group if they want to carry the official and up-to-date list of Microsoft newsgroups. Unlike Microsoft’s own two-line announcements, these articles carry a description in the body — which is why the hierarchy has a maintained newsgroups list at all.

The third is microsoft.public.softwareupdatesvcs, the English-language group for the same product family. It stands in the hierarchy’s newsgroups list with the description “Microsoft Windows Server Update Services newsgroup”, and the ISC control archive holds no file for it at all — no creation message, no removal message, nothing. Its Japanese sibling has a full file and is gone from both the newsgroups list and the active file, removed on 15 December 2009. That removal is itself documented: the rmgroup article explains that 535 obsolete newsgroups had been removed from Microsoft’s servers on 10 December 2009, and that 535 matching control articles were being sent over five days at a rate of 107 a day. The English name has a description and no paperwork; the Japanese one has paperwork and no name left standing. Nothing sinister follows from either. It is simply what a distributed administrative record looks like after twenty years: mostly right, locally incomplete, and never audited.

Windows Update, dated: a web page that became a service

The thing the group was named after began as a web site. Windows Update was introduced with Windows 98, which reached manufacturing on 15 May 1998 and retail on 25 June, and in its first form it was less a patching mechanism than a shop. Its initial focus was free add-ons and new technologies: desktop themes, games, device driver updates and optional components such as NetMeeting. Windows 95 and Windows NT 4.0 were retro-fitted with access to it once Internet Explorer 4 had been installed. Security fixes for Outlook Express, Internet Explorer and other programs appeared later, as did access to beta versions of forthcoming Microsoft software; the Windows 98 corrections for the Year 2000 problem were distributed through it in December 1998. Microsoft afterwards attributed the sales success of Windows 98 in part to the site.

Because it was a web application it needed a browser, and because it did its work through ActiveX it needed Internet Explorer or a third-party browser that supported the same technology. That coupling is the single most consequential design decision in the service’s early history. It meant that the mechanism for repairing the operating system ran inside the component of the operating system with the largest attack surface, and it meant that a browser problem could become a patching problem. The coupling is documented in the service’s own history and does not need a thread to establish it.

The client went through recognisable generations. Version 3 of the web application sent no personally identifiable information to Microsoft at all: it downloaded the complete list of every available update and decided locally which ones applied. That is an admirably private design and it did not scale. Arie Slob, writing for the Windows-help.net newsletter in March 2003, noted that the size of the update list had passed 400 kilobytes and that this caused delays of more than a minute for dial-up users. Version 4, released in 2001 alongside Windows XP, reversed the arrangement: the client made an inventory of the machine’s hardware and Microsoft software and sent it to the service, offloading the matching work to Microsoft’s servers. The privacy properties of the two designs are opposite, and the second one is the one that survived.

The scale it reached is recorded in Microsoft’s own statements. At the beginning of 2005 the service was being accessed by about 150 million people, of whom roughly 112 million were using Automatic Updates. By 2008 it had about 500 million clients, processed about 350 million unique scans a day and maintained an average of 1.5 million simultaneous connections to client machines; on Patch Tuesday its outbound traffic could exceed 500 gigabits per second. Approximately ninety per cent of clients by then used automatic updating, the remaining ten per cent visiting the web site, which was built on ASP.NET and processed an average of 90,000 page requests per second. Those are the figures of a piece of public infrastructure, not of a download page, and they are the numbers behind everything in the next several sections.

The web application was eventually retired as the primary client. From Windows Vista and Windows Server 2008 onwards, the Windows Update Agent — a component of the operating system, driven from a control panel applet, from Group Policy or from a command line — replaced both the site and the separate Automatic Updates client. That change falls just after the middle of this group’s life and marks the end of the era the group’s name belongs to: the era in which updating your computer meant visiting a page.

Critical Update Notification, and the arrival of Automatic Updates

Between the shop and the service there was an awkward intermediate device, and it is worth describing because it set the pattern for everything that followed. The Critical Update Notification Tool, later Utility, shipped shortly after Windows 98. It was a background process that checked the Windows Update site on a schedule — by default every five minutes, and again whenever Internet Explorer started — for updates that had been marked critical. It fetched a single cabinet file listing the critical updates released for the operating system, compared that list against what was installed, and displayed a notification. A user could restrict the next check to particular times of day or days of the week, but any custom schedule was reverted to the default once a check had run, on Microsoft’s stated grounds that this ensured notification of critical updates in a timely manner.

Microsoft continued to promote the tool through 1999 and the first half of 2000, and initial releases of Windows 2000 shipped with it. It did not support Windows 95 or Windows NT 4.0 — an early instance of the pattern in which the update mechanism itself, rather than the updates, determines who can be patched.

The security researcher H. D. Moore examined the arrangement in early 1999 and published a critique on BugTraq, calling it horribly inefficient and susceptible to attack. His argument was about concentration: every Windows 98 machine that wanted an update had to rely on a single host for its security, and if that server were compromised, or an attacker cracked Microsoft’s name service again, there could be millions of users installing trojans every hour. It is an early and unusually clear statement of the problem that defines this whole subject — that an update channel is the most valuable single target on the network precisely because it is trusted by everything — and it was made three years before the group in question existed.

Automatic Updates succeeded the notification utility and changed the verb. It was released in 2000 with Windows Me, which reached manufacturing on 19 June and retail on 14 September that year, and it supported Windows 2000 from Service Pack 3. Where its predecessor could only tell you, Automatic Updates could fetch and install. It checked once a day rather than every five minutes, and after installation a notification balloon prompted the user to choose among three schemes: notify before downloading, notify before installing, or both. Updates ready to install could be applied before the machine was turned off, with a shield icon on the shutdown button to say so.

Windows XP and Windows 2000 Service Pack 3 added the Background Intelligent Transfer Service, a system component for moving files in the background without user interaction, capable of monitoring the user’s own internet activity and throttling its own bandwidth to keep user-initiated work in front; the Automatic Updates client on those systems was rebuilt to use it. This is the point at which updating stopped being an activity and became a condition: something the machine did on its own, out of sight, at a rate determined by how much of the line the user was not currently using.

It was not universally loved, and the complaint that is best attested has nothing to do with security. Automatic Updates in Windows XP gained notoriety for interrupting people at work: every time an update requiring a reboot was installed, a dialogue box offered an immediate restart or could be dismissed, in which case it reappeared ten minutes later. The developer and writer Jeff Atwood called it perhaps the naggiest dialog box ever, and the description stuck. Windows Vista and Windows 7 allowed the mandatory restart to be postponed for up to four hours and moved the revised dialogue behind other windows rather than in front of them, although standard user accounts still had fifteen minutes to answer it. Windows 8 raised the grace period to seventy-two hours and consolidated the restart requests for non-critical updates into one a month. Four operating system releases spent adjusting one dialogue box is a fair measure of how hard the underlying problem was.

The point at which it became the default

The decisive change in this history is not a version number but a default, and it arrived with Windows XP Service Pack 2. Microsoft announced the release of SP2 to computer manufacturers on 6 August 2004; it reached retail on 25 August. Its security work — headed by the former hacker Window Snyder and carried inside the company under the codename Springboard, the features being intended to underpin further changes in the release then called Longhorn — rewrote a set of defaults rather than adding features: the bundled firewall was renamed Windows Firewall and enabled by default, Data Execution Prevention was updated and gained hardware backing through the processor’s NX bit, raw socket support was removed, the Messenger service that had been abused to throw advertisements onto desktops as system messages was disabled by default, and a new Security Center presented the state of the firewall, the antivirus product and automatic updating in one window. Windows XP itself, its activation scheme and its service packs are the subject of a separate page in this directory, and the operating system’s own story is told there rather than here.

What belongs to this page is the delivery. Microsoft’s announcement of 6 August 2004 stated the plan plainly: the easiest way for existing Windows XP users to receive Service Pack 2 was to turn on Automatic Updates, and the company expected to distribute it to approximately 100 million PCs through that channel over the following two months, localising the software into twenty-five languages as the rollout proceeded. Customers without reliable internet connections could order a free CD, and manufacturers preloaded it on new machines, but the primary vehicle was the update channel itself. This was the largest single thing Windows Update had ever been asked to carry, and it was being carried to machines whose owners had, in most cases, made no decision to receive it.

Organisations objected, and Microsoft accommodated them in a way that is unusually well documented. A registry-based mechanism, distributed as a blocker tool kit, allowed an administrator to prevent Windows Update and Automatic Updates from delivering the service pack while continuing to deliver ordinary critical updates. Microsoft’s original intention had been to begin automatic installation around the middle of December 2004; to give businesses more time to prepare, the block was instead made to run for 240 days from 16 August 2004, expiring on 12 April 2005, after which the service pack was delivered to Windows XP and Windows XP Service Pack 1 systems regardless of whether the registry key was still set. That is the whole enterprise patching dilemma compressed into one deadline: a vendor that has decided a change is necessary, a customer that has not finished testing it, and a clock.

The testing mattered because the changed defaults broke things. Microsoft published a knowledge-base article numbered 842242, on programs that seem to stop working after Service Pack 2 is installed, with a companion list under 884130 of programs known to lose functionality or behave differently on an SP2 machine, naming applications from many publishers and some of Microsoft’s own. The mechanism of the breakage was rarely mysterious: a program that had been listening on a port now found the port closed; a program that had relied on an ActiveX control now found the control blocked; a program that executed data now found the processor refusing. None of that was a defect in the service pack, and all of it was a defect from the point of view of somebody whose accounting package had stopped opening. This is the exact species of problem a room named after the update service inherits, and it is why the second half of 2004 is the busiest imaginable moment for such a room.

The enterprise product and its successors

The corporate answer to all of this was a server that stood between the organisation and Microsoft. Software Update Services was first offered as an add-on component for Windows 2000 and Windows Server 2003. At first it delivered only hotfixes and patches for Microsoft operating systems: it ran on a Windows Server machine, downloaded updates for specified versions of Windows from Windows Update, and served them to the organisation’s own clients, which no longer had to connect directly to Microsoft. Support for it was originally planned to end on 6 December 2006 and, after customer feedback, extended to 10 July 2007.

Its successor was Windows Server Update Services, which broadened the range of things that could be distributed to include service packs, drivers and feature packs. The release history is precise: a release candidate on 22 March 2005, version 2.0 on 6 June 2005, Service Pack 1 on 31 May 2006 adding Windows Vista clients, further client languages and a SQL Server 2005 back end, a second beta of version 3.0 on 14 August 2006 with a Microsoft Management Console interface, a release candidate for it on 12 February 2007, version 3.0 on 30 April 2007, Service Pack 1 on 7 February 2008, Service Pack 2 on 25 August 2009 as part of Windows Server 2008 R2, and version 4.0 on 26 October 2012 with Windows Server 2012.

The arguments for it were bandwidth and control. Bandwidth first: where every machine in an organisation fetches its own copy, the traffic is the number of machines multiplied by the size of the updates; where one server fetches and the rest fetch from it, the external traffic is a single copy. Control second, and more importantly: an administrator could approve or decline each update before release, approve some for detection only in order to see which machines would need them without installing anything, force an installation by a given date, configure whole classes of update for automatic approval, and test a release on a small group of machines before letting it loose on the estate. Large organisations could chain servers hierarchically so that only one of them ever talked to Microsoft, and disconnected networks could be fed by exporting the patch data from a connected server and importing it from removable media. Client behaviour could be pinned down through Group Policy, or through local policy or the registry where there was no Active Directory, so that users could not opt out. For complex deployments Microsoft offered System Center Configuration Manager on top.

The consumer-facing service broadened at the same moment. Microsoft announced a first beta of Microsoft Update at the RSA Conference in February 2005 and released it in June 2005 as an optional replacement for Windows Update that covered other Microsoft products as well as the operating system — Office 2003, Exchange 2003 and SQL Server 2000 at first, running on Windows 2000, XP and Server 2003, and a lengthening list afterwards. The separate Office Update service was decommissioned into it on 1 August 2009. For anyone who needed the packages themselves rather than the service, the Microsoft Update Catalog offered individual downloads; the version of the catalogue site launched in August 2007 required an ActiveX control and worked only in Internet Explorer 6 and 7, which tells you something about what “the web” meant to this product family at the time. The newsgroup for the catalogue was announced a month after the site, on 14 September 2007.

The enterprise product long outlived the newsgroups. On 20 September 2024 Microsoft announced that Windows Server Update Services would no longer be developed as of Windows Server 2025, directing customers instead towards cloud-based update management. The room whose name pointed at it had by then been closed for fourteen years.

Patch Tuesday

Until late 2003, Microsoft released security fixes when they were ready. The consequence for anyone running more than a handful of machines was that patching had no schedule and therefore no place in a maintenance window: an update could arrive on any day, and each one had to be evaluated, tested and deployed as an interruption. The company’s own account of the reason is contemporary and blunt. Announcing the change, Amy Carroll, then a director of product management in Microsoft’s security business unit, said that one of the things the company had heard from its customers was that deploying patches on a weekly basis was too difficult.

The announcement came on 9 October 2003, as part of a broader security plan set out by Steve Ballmer in a keynote at Microsoft’s first Worldwide Partner Conference in New Orleans; the plan also promised smaller patches, fewer reboots, a reduction in the number of patching systems across the product lines, and customer education. The monthly schedule began immediately, and the first monthly bulletin summary was published on 14 October 2003 — the second Tuesday of that month — covering seven bulletins for Windows and Exchange Server. The convention that gave Patch Tuesday its name settled from there: bulletins on the second Tuesday of the month, released at ten in the morning Pacific time. Inside Microsoft the monthly bundle is the B release, distinguished from the C and D releases of the third and fourth weeks. Tuesday was chosen for scheduling reasons of an entirely mundane kind: it leaves the maximum number of working days before the weekend to deal with anything the patches break, while keeping Monday free for whatever the weekend itself produced.

The background event is usually given as the Blaster worm of August 2003, and the cost argument — that batching reduced the expense of distributing patches — sits alongside the customer-demand argument in the contemporary accounts. Both can be true. What is not in dispute is that from October 2003 the industry acquired a rhythm. Administrators could plan; vendors of other software began aligning to the same day; and the risk calculus around vulnerabilities acquired a monthly clock.

The cadence spread beyond Microsoft. SAP’s Security Patch Day was deliberately chosen to coincide with it, Adobe brought Flash Player updates onto the same day from November 2012, and Oracle’s quarterly releases were timed to fall on it too, so that a single day of the month came to carry a substantial share of the industry’s published vulnerability information. The bundling had a mechanical side effect as well. Because the updates are fetched by a client that uses idle bandwidth, and because that client measures the line by the speed the network adapter reports rather than by the capacity of whatever sits beyond it, a fast adapter behind a slow link will happily try to use the whole of a bandwidth that is not there; and because Microsoft’s update servers were reported not to honour the usual slow-start congestion behaviour, a site with many machines behind one shared link could find that link saturated on the same day each month. That is one of the arguments that sold the enterprise update server described above.

The obvious cost of the clock was stated at the time and has never been resolved. A fix that exists is withheld from the public for up to a month. When the vulnerability is obscure and unknown to attackers this is a reasonable trade; when it is not, it is a month of exposure imposed by a scheduling convention. Microsoft’s answer was the out-of-band release, issued when a newly discovered or prevalent exploit made it necessary, and out-of-band releases duly happened. But the default remained the calendar, and the calendar was public.

Exploit Wednesday, and what the research actually says

The day after Patch Tuesday acquired a name of its own, and the pattern behind the joke is well attested. A patch is a description of a defect. Comparing a patched binary with its predecessor reveals which checks were added, and an added check marks the place where an input was previously accepted that should not have been. For a defect that was not publicly known, the patch is frequently the disclosure. The concern is as old as the schedule itself: in the same October 2003 briefing at which Microsoft announced the monthly cycle, Amy Carroll noted that there was some anecdotal evidence that deploying a patch is what prompts the release of exploit code.

Two worms from this group’s own lifetime make the shape of it concrete, and both are documented in detail rather than folklore. Microsoft published bulletin MS03-026, correcting a buffer overflow in the DCOM remote procedure call interface discovered by the Polish research group Last Stage of Delirium, on 16 July 2003. The Blaster worm was first noticed on 11 August 2003 — twenty-six days later — and according to court papers it was created after researchers from the Chinese group Xfocus reverse-engineered the Microsoft patch. Infections peaked two days after it appeared, and by 15 August the number of infected systems was being reported at 423,000.

Blaster then did something that belongs in this article rather than a general history of malware: it was programmed to start a SYN flood against port 80 of windowsupdate.com from 16 August, turning the machine population it had infected against the mechanism that would have prevented the infection. The attack was largely unsuccessful, and the reason is a technicality of naming — that address was only a redirect, and the service itself answered at windowsupdate.microsoft.com — but the intent is the clearest statement anyone has made about what an update service is worth to an attacker. An eighteen-year-old from Hopkins, Minnesota, Jeffrey Lee Parson, was indicted in September 2003 for creating the B variant and sentenced to eighteen months in January 2005; the author of the original remains unknown.

The following spring the sequence repeated with an even shorter interval. Bulletin MS04-011, released on 13 April 2004 — a Patch Tuesday — addressed fourteen distinct vulnerabilities, among them a buffer overrun in the Local Security Authority Subsystem Service rated critical on Windows 2000 and Windows XP. The Sasser worm, which exploited exactly that flaw, was created on 29 April 2004, sixteen days after the fix for it had been published, and spread without any user action at all: it scanned address ranges, connected on TCP port 445, and pulled itself onto each new host from an FTP server running on the previous one. Its most characteristic symptom was a shutdown timer, produced by the worm crashing the very service it had exploited. Agence France-Presse lost satellite communications for hours and Delta Air Lines cancelled trans-Atlantic flights. Its author, an eighteen-year-old German named Sven Jaschan, was arrested on 7 May 2004 after a friend informed Microsoft, which had offered a bounty of 250,000 US dollars; he received a twenty-one-month suspended sentence on 8 July 2005.

The research literature took the question up formally, and the definitive result belongs to this era. In 2008 David Brumley, Pongsin Poosankam, Dawn Song and Jiang Zheng — then at Carnegie Mellon, the University of California, Berkeley and the University of Pittsburgh — presented a paper at the IEEE Symposium on Security and Privacy titled “Automatic Patch-Based Exploit Generation is Possible: Techniques and Implications”. They defined the problem exactly: given a program and a patched version of it, automatically generate an exploit for the potentially unknown vulnerability that is present in the first and fixed in the second. They then did it, for five Microsoft programs, using patches obtained from Windows Update.

Their timings are the part usually quoted, and they are worth quoting accurately. In each of their cases they were able to generate an exploit, usually within a few minutes; the fastest end-to-end generation of a verifiable exploit took under thirty seconds. Their conclusion was not that patching is harmful. It was that the security implication of staggered distribution needed rethinking: a scheme that spreads a patch out over hours or days may allow whoever receives it first to compromise a significant fraction of the hosts that have not yet received it — and, as they were careful to say, this holds irrespective of whether people would actually have applied the patch, since what is at stake is whether they even had the opportunity.

The measurement they leaned on for the staggering is itself a Windows Update study: work presented at SIGCOMM in 2006 by Christos Gkantsidis, Thomas Karagiannis, Pablo Rodriguez and Milan Vojnović on planet-scale software updates, from which Brumley and colleagues take the figure that it takes about twenty-four hours for eighty per cent of the unique observed addresses to check for a new patch. The three directions the 2008 paper canvassed for fixing staggered distribution — making the changed lines hard to find through obfuscation, encrypting patches so that everyone can download before anyone can apply, and distributing peer-to-peer so that everyone receives at about the same time — were offered as directions rather than recommendations, and each was discussed with its own objections attached, the authors noting for instance that obfuscation would be the easiest of the three to defeat. The paper is reported here as a matter of record. This page gives no security advice of any kind.

Why a room about patching fills up

There is a structural reason a support group about an update mechanism behaves differently from a support group about a word processor, and it is worth setting out because it explains the group’s existence better than any anecdote could.

An update mechanism is the one piece of software on a general-purpose operating system that is required to work on every installation of that system, without exception, and without the option of being avoided. A user who dislikes the spreadsheet can use a different spreadsheet. A user whose printer driver misbehaves can, at some cost, buy a different printer. There is no alternative supplier of fixes for Windows. Everything else in the product line has a population of users defined by who chose it; the update client’s population is defined by who has the operating system at all.

That population, in the years this group was open, was enormously various and mostly undocumented. It included machines that had never been patched since manufacture, machines whose owners had installed hardware drivers of uncertain provenance, machines behind corporate proxies with rules the update client had never been tested against, machines on metered dial-up lines, machines running localised builds, machines with disks too full to stage a download, machines whose clocks were wrong, and machines that were already compromised. An update mechanism has to succeed on all of them, and the ways in which it can fail are therefore not a list but a combinatorial space.

The genres of failure such a room carried are describable without inventing a single instance of any of them. There is the update that will not install: the download completes, the installation begins and does not finish, and the machine is left reporting the same update as outstanding on every subsequent check, so that the failure recurs forever rather than once. There is the machine that will not finish starting: an update that touches something loaded early in the boot sequence, on a machine whose early boot sequence is not quite what the update assumed, produces a computer that starts, fails and starts again, and — the distinctive cruelty of this category — cannot be repaired by the update mechanism, because the update mechanism runs on the operating system that is no longer reaching a usable state. There is the patch that breaks something unrelated: the fix is correct, installs cleanly and behaves exactly as documented, and an application that depended on the previous behaviour stops working, which from the user’s side is indistinguishable from the update being defective. And there is the failure of the channel rather than the payload: the client that cannot reach the service, or reaches it and is told something it cannot interpret.

Each of these produces a different kind of question, and only the third has an answer that a vendor could reasonably be expected to give in advance. Two properties of the whole class made a public newsgroup a plausible place to bring them. The first is that the diagnostic information was numeric and opaque: the client reported a code, and the code meant something to whoever had written the client and nothing to anybody else, so the natural move was to publish it and hope somebody recognised it. This page does not reproduce any such code, both because none can be quoted from a message it has not read and because doing so would invite the reader to treat an encyclopaedia entry as a repair manual. The second is that the population of failures was long-tailed. The common cases were absorbed by documentation. What reached a peer-support room was, by construction, the residue: the combinations nobody had tested, one machine at a time.

None of this is a claim about what was actually posted here, which this page cannot see. It is a claim about the structure of the problem the room was named after, and the structure is verifiable independently of the traffic.

Genuine software validation, and the criticism it drew

In 2005 Microsoft attached a licence check to the update service. Windows Genuine Advantage validated the installed copy of Windows and its licence key against the detected hardware before allowing certain downloads from Windows Update, Microsoft Update or the Download Center. Mechanically it was two things: an ActiveX control invoked when a user first visited the update site, which stored a licence file on the machine once validation succeeded, and — from 2006 — an installable component called WGA Notifications which hooked into the logon process and revalidated at every logon. The notifications component covered Windows XP and later, excluding Windows Server 2003 and the 64-bit edition of XP Professional; the ActiveX control also checked Windows 2000 Professional licences. In Windows 7 the whole apparatus was renamed Windows Activation Technologies. Despite the name, it evaluated nothing about the integrity or security of the machine.

A machine that failed validation was not locked out of security fixes. Microsoft’s stated position throughout was that critical security updates would continue to be delivered through Automatic Updates and the Download Center to every system, validated or not. What failure cost was everything else: optional and non-critical updates, a desktop background changed to black, and a persistent watermark in the corner of the screen. On Windows Vista before Service Pack 1 the penalty was steeper — Windows Aero, Windows Defender and ReadyBoost were disabled, and after a grace period the system entered what Microsoft called reduced functionality mode. That behaviour was removed in Vista Service Pack 1 in favour of prominent notices.

WGA Notifications began distribution as a critical update on 25 April 2006 and was revised repeatedly through that year — 23 May, 30 May, 6 June, 27 June, and a 29 November release which changed the installation process to explain what the program did, could keep itself updated, and told users whose copies had failed why their Windows was not being reported as genuine. Because releases did not roll out worldwide simultaneously, those dates are earliest appearances rather than universal ones. The data the programme transmitted was itemised publicly: computer make and model, BIOS checksum, make, version and date, MAC address, a globally unique identifier assigned to the installation, hard disk serial number, Windows version, product identifier and localisation, the Windows or Office registration key, and the results of validation and installation.

The criticism was immediate and came in three distinct forms, and it is set out here as it was made rather than adjudicated. The first was that the notification tool behaved like spyware: it contacted Microsoft on every boot and every twenty-four hours thereafter, which had not been disclosed, and it had been delivered through a channel users associated with security fixes rather than with licence enforcement. The complaint was aired in a series of postings by Lauren Weinstein, a co-founder of People for Internet Responsibility, between 5 and 13 June 2006, and picked up widely in the trade press that month. Microsoft acknowledged the behaviour, denied that it amounted to spyware, and said it would change the tool to report back once a fortnight instead of daily. That did not settle it: on 26 June 2006 a Los Angeles resident, Brian Johnson, sued in the US District Court in Seattle under the Washington and California anti-spyware statutes over the undisclosed behaviour. The case was dismissed with prejudice, Judge Richard A. Jones holding among other things that the tool announced its presence and was a component of Windows XP rather than separate software, whereas spyware by the usual definition hides from its user; the dismissal was reported in February 2010.

The second was false positives. An editorial in Ars Technica reported that the programme had flagged around 22 per cent of some 500 million Windows computers as failing the test, of which fewer than half a per cent were traceable to unauthorised software, the balance being edge cases of one kind or another. Microsoft declined to give a figure for pure false positives beyond saying it was under one per cent — which, on a base of 500 million, is an upper bound of roughly five million machines. Both numbers were disputed at the time. Both are reported here because both were published. That the operator itself expected wrong answers is visible in what it built around the programme: a support forum for users the check had rejected, and, from February 2007, a “Not Sure” category added to the result.

The third was reliability, and it produced the most legible incidents. On 25 August 2007 the validation servers suffered an outage, and legitimate copies of Windows XP and Vista were marked as counterfeit until the problem was resolved about twelve hours later; Microsoft said fewer than 12,000 systems were affected worldwide. Reports of the servers being unreachable surfaced again on 18 July 2008, which Microsoft characterised as a temporary failure of offline verification only. On 20 October 2008 the programme was extended to Simplified Chinese systems, and because unlicensed copies were widespread there the visible result — black desktops and repeated warnings on very large numbers of machines — became a public controversy in China, with contemporary polling by Chinese portals reporting that a large majority of those surveyed were hostile to the scheme.

What matters for this page is narrower than the merits. Whatever one thinks of licence enforcement, attaching it to the update channel meant that a user whose machine had stopped receiving updates now had two candidate explanations — a technical fault or a validation verdict — which presented identically from the outside and which required completely different responses. A support room named after the update service inherited both.

Withdrawn, re-released, and the update that updated itself

Updates are software, and software occasionally has to be taken back. Three episodes from this group’s lifetime are documented well enough to be stated with dates, and each is a different failure mode.

The first is a patch that introduced the class of flaw it was issued to remove. Microsoft published bulletin MS06-042, a cumulative security update for Internet Explorer, on 8 August 2006. On 24 August the bulletin and the Internet Explorer 6 Service Pack 1 updates were revised to deal with a further buffer overrun condition — one that affected only those customers who had applied the original 8 August version of the update. On 12 September the bulletin was revised again to address another long-URL buffer overflow, this time affecting Internet Explorer 6 Service Pack 1, Internet Explorer 5.01 Service Pack 4 and Internet Explorer 6 on Windows Server 2003. A security update that made one of its recipients’ configurations less secure than before, and had to be reissued twice inside five weeks, is not a common event, and Microsoft’s own bulletin records it in plain language.

The second is a patch withdrawn from distribution after release. Bulletin MS10-015, one of thirteen released on 9 February 2010, corrected a kernel defect seventeen years old in the 32-bit editions of Windows. Reports of machines failing to restart after installing it appeared almost immediately, and Microsoft halted the automatic distribution of the update two days later while it investigated. The finding, announced by Mike Reavey, then director of the Microsoft Security Response Center, was that the crashes occurred on systems already infected with the Alureon rootkit, which had modified kernel binaries in a way the corrected kernel no longer tolerated. Distribution resumed in early March with code added to block installation where such an infection was detected. Two features of the episode deserve emphasis: the update was not defective, and it still had to be pulled; and the machines it damaged were precisely the machines least likely to be in a condition to recover. It also happened four months before Microsoft began closing the newsgroups.

The third is not a withdrawal but a disclosure failure, and it concerns the update client rather than any update. In September 2007 it emerged that files on Windows XP and Windows Vista machines had been changed by Windows Update on systems where automatic updating had been switched off. Nine files were involved on each. Microsoft’s explanation, given by Nate Clinton, a program manager on Windows Update, was that these were not updates to Windows but updates to Windows Update itself, and that had the service failed to update itself automatically, users would not have been able to check for updates successfully and would in turn not have had updates installed or received the notifications they expected. Of the four settings the client offered — download and install automatically, download and let the user install, notify only, or switch updating off altogether — the first three permitted the service to update itself; only the fourth prevented it. Microsoft also conceded the point that had actually annoyed people, writing that the explanation was not meant to suggest the company had been as transparent as it could have been, and that people had told it that it should have been clearer about how Windows Update behaves when it updates itself.

That last episode is the purest expression of the bootstrap problem underneath this whole subject. The component that repairs the system cannot itself be left unrepaired, and the only channel available for repairing it is itself. Any policy about it is uncomfortable: update silently and you have acted without consent; do not update and the mechanism the user is relying on quietly stops working.

What replaced the room

Microsoft closed its public newsgroups in a phased shutdown running from 1 June to 1 October 2010, beginning with the least active groups and finishing with the busiest. The notice, the reasoning Microsoft gave, and the fact that individual closure dates were promised group by group and never consolidated into a published list are set out on the hub page. For this group as for every other, the precise last day is therefore a matter for the tail of its own archive, which this page does not hold.

The destination was a web forum. Microsoft’s consumer support site, Microsoft Answers, had launched in 2009 and was the general receiving ground for home-user questions of the kind a group about updating a desktop machine would produce; IT-professional traffic was directed to the TechNet forums, where the Windows Server Update Services product had a forum of its own. Microsoft’s migration material promised each closing newsgroup an equivalent forum, but this page has found no surviving statement naming the specific forum assigned to this group, and it does not guess.

For readers unwilling to abandon a newsreader, Microsoft distributed a piece of software it called the NNTP Bridge, which let supported news clients talk to the web forums as though they were newsgroups — a translation layer between a protocol the company had stopped operating and a platform that had replaced it.

The forums did not prove durable either. The consumer site outlasted the newsgroups by fifteen years and then went the same way: requests to answers.microsoft.com are now answered with a permanent redirect to the question-and-answer section of Microsoft Learn, a change made in the autumn of 2025. The whole sequence — newsgroup to forum to a differently branded forum — took about a quarter of a century, and the only part of it that is still reachable by its original address is the newsgroup name, which remains in the Usenet namespace because nobody removed it.

The hierarchy itself did not close when the origin server did. The public groups had been fed outward to other operators for years, and those operators were free to keep carrying them; readers were pointed at ordinary public news servers, where microsoft.public.* groups continued to accept articles, very much more quietly than before. The branch page lists what this directory carried of it.

The service outlived the room

Windows Update kept changing after the group closed, and several of the changes are worth recording because they bear on what the group had been for.

In 2011 Microsoft decommissioned the service for Windows 98, Windows 98 Second Edition, Windows Me and Windows NT 4.0, removing the old updates for those systems from its servers. The operating systems whose patching problems had produced the earliest update newsgroups in this hierarchy thereby lost the mechanism those groups had discussed, a year after the groups themselves were shut. On 3 August 2020 the same thing happened to Windows 2000, Windows XP, Windows Server 2003 and Windows Vista, as a consequence of discontinuing the SHA-1 based endpoints those clients relied on; the packages remained available from the Microsoft Update Catalog, but the automatic channel was gone.

The other is a defect in the update client that would have been squarely on-topic had there been anywhere left to report it. From 2013, Windows XP machines began spending very long periods — between ten minutes and two hours after startup — with the Automatic Updates client and the service host claiming the whole of the processor, rendering the machine unusable in the interim. Early reports appeared on Microsoft’s own TechNet forums in the late spring; the volume of complaints became large in September. The cause was an exponential algorithm in the evaluation of superseded updates, and the set of superseded updates had been growing for a decade. Attempts to fix it in October, November and December 2013 failed before the problem was escalated to top priority. It is a fitting late chapter: the component that had spent fifteen years being blamed for other software’s failures was finally undone by the sheer length of its own record.

The model changed again with Windows 10, in ways that resolved several of the arguments of this article by removing the choice that had generated them. Updates became cumulative rather than individual, which cut the number of downloads and reboots at the cost of making it impossible to install the fix for one problem alone; selective manual installation ceased; all updates, hardware drivers included, are downloaded and installed automatically, with the user’s remaining decision being when the machine may restart. A peer-to-peer distribution mechanism was added, so that machines share downloaded updates with one another as well as fetching them from Microsoft — which is, as it happens, one of the three directions the 2008 exploit-generation paper had canvassed for the staggering problem, arrived at here for reasons of bandwidth. Windows Update for Business, which arrived with Windows 10 version 1511 in November 2015, gave the Pro, Enterprise and Education editions the ability to defer categories of update for a bounded period rather than decline them.

What the record does not show

Five things about this group cannot be established from the material available, and it is better to name them than to let their absence be mistaken for insignificance.

The first is when the group was actually created. The earliest surviving control message is dated 31 January 2002, and the name is demonstrably absent from the bulk re-announcement of 27 November 2000 that swept up the rest of the hierarchy — which makes an origin in late 2001 or January 2002 the most economical reading. It is a reading, not a record. Microsoft published no founding dates for its groups.

The second is how large the group was. There is no subscriber count, no article count, no measurement of monthly volume for this group and no series of such measurements for the hierarchy from which one could be estimated. The active file records a high-water mark of zero, which reflects the state of the mirror rather than anything about the traffic the group once carried.

The third is what was discussed here, in what proportions, and by whom. This page has described the genres of failure that an update service generates because those genres are established from the documented history of the service. It has not claimed that any particular one dominated this group, because it has no way to know and no intention of guessing.

The fourth is the group’s last day. The 2010 shutdown was phased across four months, group by group, and no consolidated list of individual closure dates appears to have been published or preserved.

The fifth is the people. There was no moderator, since these groups were unmoderated; there is no roster of the volunteers who answered, no register of Most Valuable Professionals by group, and no way to identify the regulars except from their own postings. This directory does not attempt to name anybody.

Scope and limits

No article from this group has been read in the preparation of this page, and consequently nothing in it quotes, counts, summarises or characterises any posting. Where the text describes what a group of this kind carried, it is reasoning from the documented behaviour of the software the group was named after, and it says so. It reproduces no error codes, offers no diagnostic procedures and gives no security advice.

Everything dated above comes from one of three places. The first is the Usenet administrative record: the Internet Systems Consortium’s mirror of the control archive, one file per group, and its current active file, read on 25 August 2026, together with the hierarchy’s own newsgroups list, which is where the descriptions quoted here come from, ISC’s newsgroups file carrying no entries for this hierarchy. The second is Microsoft’s own published bulletins, announcements and knowledge-base material. The third is the published research and reference literature, cited by author and venue where it is research. Where a source gives a range rather than a date, the range is given. Where the record is silent, the previous section says so.

This is a historical description of a newsgroup and of the software distribution service that gave the newsgroup its name, written for readers who want to know what that room was and what it existed inside. Readers looking for the security-programming side of the same period will find it on the Platform SDK security page; the scripting hosts and mail clients whose vulnerabilities filled a great many of the bulletins discussed above have their own pages at microsoft.public.scripting.vbscript and microsoft.public.outlook.