microsoft.public.scripting.vbscript

Long-form reference · 8,984 words · about a 39-minute read

A room in a branch of eight

The address belongs to a hierarchy that was never Usenet's to govern. microsoft.public.* was a corporate namespace: created and closed by the company whose products it discussed, fed outward from a server of Microsoft's own, and carried onward by every news administrator who chose to accept it. How that arrangement worked, what the Most Valuable Professional award was, and how the whole hierarchy was retired in phases between June and October 2010 belong to the hierarchy's own page and are not retold here.

What concerns this page is the branch. Somebody at Microsoft decided that the scripting technologies deserved a short, flat family hanging directly off the microsoft.public stem rather than being filed under a product, and that decision is why the group has the name it has. The family has eight members, and the Internet Systems Consortium's mirror of the Usenet namespace still lists every one of them:

• microsoft.public.scripting.vbscript — the language
• microsoft.public.scripting.jscript — its sibling engine
• microsoft.public.scripting.wsh — the Windows Script Host, the shell that ran both
• microsoft.public.scripting.hosting — embedding a script engine inside somebody else's program
• microsoft.public.scripting.debugger — the script debugger
• microsoft.public.scripting.remote — running a script on another machine
• microsoft.public.scripting.scriptlets — script packaged as reusable components
• microsoft.public.scripting.virus.discussion — the one whose name explains itself, and whose date of creation is a document in its own right

That list is not a reconstruction. It is what the newsgroups file distributed by the Internet Systems Consortium contains today, each of the eight carrying the same laconic three-word description: Microsoft scripting newsgroup. In the copy dated 25 August 2026 consulted for this page, the same file lists 1,770 group names under the microsoft.* prefix, sorted into families by one-line labels that read like a product catalogue with the prices removed — Microsoft Windows newsgroup, Microsoft Office Access newsgroup, Microsoft Visual FoxPro newsgroup, and so on down the line.

The distinction worth holding on to is that a namespace file is a registry, not a census. A line in it records that a group name is known and considered valid on the network; it says nothing about whether anybody posted to that group this decade. The server that originated these names stopped answering years ago. The names survived it because propagation had already copied them to every server that had ever agreed to carry the hierarchy, and a name, once distributed, is nobody's to withdraw.

There is a second administrative curiosity in the record. The configuration file that news servers use to decide which control messages to honour — INN's control.ctl, maintained on the same Internet Systems Consortium archive — carries an entry for the Microsoft hierarchy which states plainly that its control articles are not issued by Microsoft itself but by a Usenet active participant in order to improve the quality of the propagation of Microsoft newsgroups. The signing address is at a third-party domain; the administrative group named for the hierarchy is microsoft.public.news.server, which the newsgroups file describes, with the same economy as everything else in it, as a Microsoft server newsgroup; and the file still records msnews.microsoft.com as the syncable server, an instruction to a machine that has not existed for many years. A corporate hierarchy, in other words, ended up being tended by a volunteer, which is about as Usenet an ending as a vendor namespace can have.

The names before this name

The Internet Systems Consortium also mirrors the archive of control messages, filed by hierarchy and group, and for this group it holds exactly two. The earlier is dated 26 October 1999 and did not come from Microsoft at all: it was posted from a third-party news server, carrying the distribution header collabra-internal that marks the Netscape Collabra software, and a body consisting of the words For your newsgroups file followed by the group name. The later is dated 27 November 2000 and did come from Microsoft, issued from an internal tool at an address in the microsoft.com domain.

Neither is a birth certificate, and it matters to say so. A newgroup control message is an assertion by one server that a group ought to exist; the Collabra-generated ones were a well-known side effect of certain news servers synchronising their group lists, so they establish only that the name was already in circulation on the network by that date. The Microsoft-issued message of November 2000 is a bulk re-assertion of the namespace rather than a founding: every one of the other seven groups in the branch carries the identical timestamp, 27 November 2000 at 10:40:19 Pacific time, down to the second. Somebody ran a tool over a list. The honest reading is that microsoft.public.scripting.vbscript existed by late October 1999 and that no earlier document about its creation appears to have been preserved anywhere the public can reach.

Within that late-October flurry the language group came first. The archive's earliest message for this group is dated 26 October 1999; the equivalents for the JScript group and the Windows Script Host group are dated 27 October, and for the hosting group 28 October. Three of the eight — the debugger, remote and scriptlets groups — have nothing at all before the Microsoft sweep of November 2000. That ordering is worth exactly what it is worth: it records the sequence in which one third-party server noticed the names, not the sequence in which Microsoft made them.

The same archive preserves an older name that tells the group's prehistory better than any creation date would. microsoft.public.programming.scripting.vbscript has a control message dated 11 March 1998, again generated automatically by a Netscape Collabra server, this one at an aerospace manufacturer. And microsoft.public.inetsdk.programming.scripting.vbscript is still in the current newsgroups file, described there as a Microsoft ActiveX Software Development Kit newsgroup — filed, that is, under the software development kit for building things for Internet Explorer. Its JScript twin sits on the line above it, under the same label.

Read as a sequence, the three names describe a promotion. VBScript entered Microsoft's namespace as an appendage of the web-authoring toolkit, moved to a generic programming branch, and finally acquired a top-level scripting family of its own alongside the host, the debugger and the component format. That is exactly the trajectory the language itself took between 1996 and 1999, from a browser feature to a system administrator's tool, and the namespace recorded it faithfully because Microsoft created groups by product-management decision rather than by public vote.

The branch also had language editions. The current newsgroups file lists Brazilian, French, Italian and Turkish scripting groups, plus a German one filed under the Windows Script Host, each with its own descriptive label in the same file. One of the French pair, microsoft.public.fr.scripting.ie-oe-animation, has a page of its own in this directory and owns the story of the French-language scripting rooms.

What VBScript was

VBScript — properly Microsoft Visual Basic Scripting Edition — is a scripting language for Windows built on the Component Object Model and derived from classic Visual Basic. It arrived in 1996 as part of a bundle Microsoft called the Windows Script Technologies, aimed in the first instance at web developers, and it acquired its real constituency almost by accident: administrators who wanted something more capable than the batch language they had been using since the early 1980s found that a VBScript file could reach anything on the machine that exposed a COM interface, which by the late 1990s meant nearly everything.

Its relationship to Visual Basic is one of deliberate subtraction. VBScript is Visual Basic with the compiler, the forms designer, the type system and most of the error handling removed. Every variable is a Variant unless a conversion function is applied to it. There is no event-driven form designer of the kind Visual Basic and Visual Basic for Applications provide; user interaction, in the base language, means the MsgBox and InputBox dialogues and nothing more. Strong typing, extended error trapping and variable-length argument lists are all absent. Procedures come in two flavours, functions that return a value and subroutines that do not, with positional parameters passed by value or by reference. Names are not case-sensitive. The control structures are the familiar ones and there are a great many named constants, which is the sort of design decision that makes a language easy to read and easy to fake fluency in.

What made the subtraction workable was that the language was never meant to be self-sufficient. It was a glue language, and everything it could not do itself it did by asking a COM object to do it. This is the single most important fact about VBScript and the reason a room about it stayed busy for a decade: the language could be learned in an afternoon, and the object models could not be learned at all except by asking somebody who had already done it.

By the time of Windows 98 the engine was installed by default in every desktop release of Windows, and it stayed there. That default is the whole of the language's later history in miniature: it is why VBScript became ubiquitous, why it became a mass-mailing worm's transport of choice, and why removing it took Microsoft from a deprecation notice in 2023 to a removal date that has still not been announced.

The version sequence, and what shipped each one

Microsoft published a version-information table in the VBScript language reference which maps engine versions onto the host products that first carried them, and it is the cleanest surviving statement of the sequence. It runs from the first release to the last:

• 1.0 — Internet Explorer 3.0, released 13 August 1996.
• 2.0 — Internet Information Server 3.0, December 1996.
• 3.0 — Internet Explorer 4.0 and Internet Information Server 4.0.
• 4.0 — Visual Studio 6.0, and no shipping browser or server; the odd one out of the sequence.
• 5.0 — Internet Explorer 5.0, March 1999.
• 5.1 — Internet Explorer 5.01 and Windows 2000.
• 5.5 — Internet Explorer 5.5, July 2000.
• 5.6 — Internet Explorer 6.0, and Windows XP through Service Pack 2.
• 5.7 — Internet Explorer 7.0, Windows XP Service Pack 3, and Windows Vista.
• 5.8 — Internet Explorer 8.0 and Windows 7.

Two things about that table shaped the traffic in this room. The first is that after version 5.0 the engine stopped travelling with a single product and started arriving with whichever of several products happened to be newest. Microsoft's own security bulletin of April 2010 states the resulting rule outright: the version of VBScript on a machine is the highest version included in the Internet Explorer, the Windows release or the Windows Script Host installed on it, and it changes when any one of those three is upgraded. The same bulletin records a genuine oddity at the other end of the range, noting that VBScript 5.1 survives only on new installations of Windows 2000 Service Pack 4 that have never had Internet Explorer 6 put on them. Questions of the form why does this script work on my machine and not on his very often had that shape and no other.

The second is where the features landed. Version 5.0 is the point at which the language stopped being a toy: it added regular expressions in the form of a RegExp object, classes and the Class statement, the With statement, the Eval, Execute and ExecuteGlobal facilities for running text assembled at run time, a function-pointer mechanism through GetRef, and support for Distributed COM. Version 2.0 had earlier supplied the string and array functions that any real work requires — Split, Join, Replace, Filter, Array — and, critically, CreateObject and GetObject, the two functions through which every object model in the rest of this article is reached. Version 5.5 added submatch access to the regular-expression object, catching VBScript up with a capability JScript already had. After 5.8 nothing was added at all.

One number should be treated with suspicion. Reference works occasionally record a VBScript 6.0 released in 1998, and one widely consulted encyclopedia gives September of that year. No Microsoft document traced for this page supports it: the company's own version table ends at 5.8, and every Microsoft statement about a shipping engine speaks of 5.0, 5.1, 5.5, 5.6, 5.7 or 5.8. The safest summary is that VBScript's version numbers ran 1.0 to 5.8 and then stopped, because after the arrival of the .NET Framework the scripting team decided that future language support belonged in ASP.NET and that no new VBScript engine would be developed. Maintenance passed to a sustaining engineering team responsible for bug fixes and security repairs, which is a polite way of saying the language was finished at the turn of the century and supported for another twenty-odd years.

VBScript and JScript: two engines, one socket

The pairing with JScript is not a rivalry and never was. Both were released in 1996, both are Active Scripting engines, and both plug into the same socket. Active Scripting — formerly called ActiveX Scripting — is the Windows mechanism for component-based scripting support, built on OLE Automation and therefore on COM, and its defining property is that the interfaces are public. Any application can implement them and become a scripting host; any language can implement them and become a scripting engine. The two Microsoft shipped were VBScript and JScript, and third parties supplied engines for Perl, Python, Ruby, Tcl, PHP, Lua, Delphi's Object Pascal, Fortran, Haskell and several dialects of Rexx besides. Of the outside languages, Perl was the one most used.

JScript is Microsoft's dialect of ECMAScript, first supported in Internet Explorer 3.0 in August 1996, and its numbering marched alongside VBScript's for the whole of their shared life: 3.0 with Internet Explorer 4.0 in October 1997, which Microsoft announced as the first scripting language to conform fully to the ECMA-262 standard; 5.0 with Internet Explorer 5.0 in March 1999; 5.5 with Internet Explorer 5.5 in July 2000; 5.6 with Internet Explorer 6.0 in October 2001; 5.7 with Internet Explorer 7.0 in November 2006; 5.8 with Internet Explorer 8.0 in March 2009. The name was a trademark manoeuvre rather than a technical distinction, adopted, as Douglas Crockford has explained it, so that Microsoft need not deal with Sun over the word Java.

For the newsgroup this architecture had a concrete consequence. Because the host supplied the object model and the engine supplied only the syntax, a question about mapping a network drive or enumerating a directory was the same question in the VBScript room and the JScript room, differing only in punctuation. What genuinely belonged to this group was the language: its Variant semantics, its date handling, its string functions, its error object, and the particular ways in which Visual Basic habits misfire when the compiler and the type system have been taken away.

Host one: the browser, and the road not taken

VBScript began as a browser language and never succeeded as one. Inside a page loaded by Internet Explorer it did what JavaScript did — interact with the document object model to produce behaviour that HTML alone could not — and outside Internet Explorer it did nothing at all. No competing browser engine implemented it; Netscape did not, and neither did any of the engines that came after. Any page that had to work for more than one audience was therefore written in JavaScript, and client-side VBScript survived mainly on intranets where the browser was a matter of corporate policy rather than user choice.

The escape from the browser was the HTML Application, introduced with Internet Explorer 5 in 1999 and run by mshta.exe. An HTA is a file of HTML, dynamic HTML and script that executes outside the browser security model as a fully trusted application: the user interface comes from the markup, the logic from VBScript or JScript, and the sandbox is simply absent. Microsoft was granted a patent on the technique in December 2003. Administrators took to HTAs immediately, because an HTA was the shortest path from a working script to something a colleague could be handed with a button on it. That the same property made HTAs an attractive delivery mechanism for other purposes is a matter dealt with further down this page.

The browser story has a tidy ending, two decades later. In 2019 Microsoft disabled VBScript by default in Internet Explorer 11 for the Internet and Restricted Sites zones: on Windows 10 from the cumulative updates of 9 July 2019, and on Windows 7, 8 and 8.1 from those of 13 August 2019. The setting remained configurable per zone, by registry or by group policy, for organisations with pages that still needed it. Client-side VBScript, the use the language was originally invented for, was thus the first of its hosts to be switched off.

Host two: the web server, and classic ASP

The server side is where VBScript first became a professional skill. Active Server Pages was Microsoft's first server-side scripting environment, released in December 1996, and the mechanism is worth stating precisely because it explains why so much VBScript exists in the world. A file with an .asp extension is ordinary HTML with islands of script delimited by <% and %>; the ASP engine, asp.dll, reads the file, hands each island to the appropriate script engine — vbscript.dll for the default language — and streams out whatever the script writes. The language could be switched per page by directive or per server by configuration, and JScript and PerlScript were both supported, but VBScript was the default and the great bulk of ASP was written in it.

The versions tracked Internet Information Services. ASP 1.0 shipped as part of IIS 3.0 in December 1996, itself delivered with Service Pack 2 of Windows NT 4.0. ASP 2.0 followed in September 1997 with IIS 4.0, distributed in the Windows NT 4.0 Option Pack, which also introduced the Microsoft Management Console administration model and the ability to run more than one web or FTP server on a machine. ASP 3.0 arrived with IIS 5.0, the version built into Windows 2000, adding Server.Transfer and Server.Execute, an improved error object and buffering by default.

What the host gave the script was a small set of intrinsic objects that every ASP author knew by heart: Request for what the browser sent, Response for what the server would send back, Server for utility functions and object creation, Session for per-visitor state, Application for state shared across the whole site, and an error object alongside them. Everything beyond that came from COM components instantiated on the server, which is why ASP work and administrative scripting shared a vocabulary: the same CreateObject call, the same programmatic identifiers, the same late binding.

ASP.NET superseded it in January 2002, at which point the older technology acquired the retronym classic ASP and a very long tail. Support on Windows 7 ran until 14 January 2020 and on Windows 8 until the end of that system's extended support in January 2023, and ASP remains available in current versions of IIS. A working technology that Microsoft has stopped developing but cannot quite stop shipping is a recurring theme in this article.

One boundary is worth marking. Questions about running the server itself had their own rooms — the newsgroups file still lists microsoft.public.inetserver.asp.general, .components and .db under the Internet Information Services label — so this group's share of the ASP traffic was the language-shaped part of it: what a Variant does when it meets a database null, why a date formats differently on the server than on the developer's desk, how to build a string without quadratic concatenation. The boundary was never policed, of course. Nobody was policing anything.

Host three: the shell

The host that made VBScript an administrator's language was the Windows Script Host, originally spelled Windows Scripting Host, which Microsoft describes as an administration tool and which is best understood as the thing that lets a script run with no browser and no web server anywhere in the picture. It appeared as an optional install on later Windows 95 media, became a standard component of Windows 98, reached Windows NT 4.0 through the Option Pack and Service Pack 4, was offered as an optional install for Windows CE from version 3.0 onward, and has shipped with every desktop Windows since.

It provides two executables and one distinction that generated a great deal of correspondence. wscript.exe runs a script in the graphical environment, where output means a dialogue box; cscript.exe runs the same script at the command line, where output means text on standard output that can be redirected, and where the exit code can be tested by a batch file or by whatever process launched the script. The same file behaves differently depending on which one opens it, and the graphical host is the default for a double-clicked script file, which is why so many administrative scripts open with instructions about running them under cscript.

The file types multiplied as the host matured. A plain .vbs file is VBScript source; .vbe is the same thing passed through Microsoft's script encoder, which obscures the text without securing it; .js and .jse are the JScript equivalents. A Windows Script File, extension .wsf, is an XML-styled wrapper that can hold several jobs and mix languages within one file, so a VBScript routine and a JScript routine can share a script. A Windows Script Component, extension .wsc, wraps script as an ActiveX-enabled class that other COM-aware programs can instantiate as though it had been compiled — the subject of the sibling scriptlets group.

The object model is the reason people wrote for this host rather than for the command interpreter. Microsoft's documentation states its size exactly: fourteen objects, with WScript as the root. From the root a script can read its own command-line arguments, named and unnamed, determine the name of the script file and which host is running it, create and connect to COM objects, sink events, write to the default output device, stop itself and set an exit code. The helper objects do the work an administrator actually came for: the shell object runs programs, manipulates the registry, resolves environment variables and the special folders such as Desktop and My Documents, and creates shortcuts; the network object maps and unmaps network shares and printers and reports information about the logged-on user. A controller object and a remote object, added later, allow a script process to be created on another machine, with a third object carrying back the error information when a remote script dies.

The host's own version numbering is a small trap for the unwary, because Microsoft published two tables that count differently. In the Windows Script Host table, version 1.0 shipped with Windows 98 and the Windows NT 4.0 Option Pack, 2.0 with Windows 2000, 5.6 with Windows XP, 5.7 with Windows Vista and Windows Server 2008, and 5.8 with Windows 7 and Windows Server 2008 R2. In the VBScript table the same Windows 2000 machine is a 5.1 machine. So a question of the form which version of the Windows Script Host do I have has two defensible answers for the years around the turn of the century, depending on which of Microsoft's own tables the asker had read, and only from 5.6 onward do host and engine agree on a number. This is precisely the sort of thing a newsgroup is for.

Two capabilities deserve singling out because they defined what the group's traffic could be about. From Windows 2000, Windows Script Host scripts could be used directly as user logon scripts, which is how a scripting language ended up executing on every desktop in an organisation at eight o'clock every morning. And from version 5.6 the host gained a security apparatus of its own: a Scripting.Signer object allowing a script to be digitally signed from within a script, given a valid certificate on the machine, with the signing tool from the Platform SDK extended to understand the script file types. Microsoft documented the 5.6 release in the May 2002 issue of its developer magazine under a headline promising Windows XP integration, security and a new object model — three subjects that had not been on the same line in 1998.

Host four: the applications

The fourth host is not one host but a category. Any program that exposed an Automation interface could be driven from a script, and the entry point was always the same pair of functions: CreateObject, which starts an instance of a component named by its programmatic identifier, and GetObject, which attaches to something already running or names a resource through a moniker. There is no compilation, no reference to add and no type library required — the call is resolved at run time through COM's dispatch interface, and a mistyped method name is a run-time error rather than a compile-time one, a trade the language made everywhere.

Microsoft Office was the obvious target and the most heavily used. A script could open a workbook, write a report into a document, query a database or address an item of mail, and it could do so from a scheduled task with no user present. The distinction that mattered, and which generated a permanent low-level confusion, is that Visual Basic for Applications lives inside the application, with the full language, the forms designer and a project system, while VBScript stands outside it and drives it from a file on disk. Code moves between the two with edits rather than cleanly. This directory's page on microsoft.public.excel.programming owns the VBA side of that story; what belonged here was the outside view — automation from a script rather than macros within a workbook.

There is one place where the boundary genuinely dissolved. Outlook 97 used VBScript, not VBA, as its macro language; Office 2000 was the release at which every component moved to Visual Basic for Applications 6.0. Script behind an Outlook form was therefore VBScript by design, in the years that mattered. That detail is not a curiosity: it is the reason the mass-mailing worms of the following years had a script engine and a mail client's object model in the same address space, which the next sections take up.

The reverse arrangement also existed. The Microsoft Script Control, distributed as msscript.ocx, let an ordinary application embed the script engine and expose its own objects to it, so that a commercial program could offer VBScript as its macro language without writing an interpreter. That was the business of the sibling hosting group, and it is why a surprising number of terminal emulators, test tools and line-of-business applications of the period were scriptable in exactly the language this newsgroup discussed. The arrangement outlived the newsgroup: VBScript is still the scripting language of at least one major commercial test-automation product, and still turns up as the macro language inside industrial operator interfaces.

The object models everyone actually used

Because the language was deliberately small, competence in VBScript was really competence in a handful of object libraries. Three of them account for most of what was ever written.

The first is the Scripting Runtime, scrrun.dll, a library distributed alongside the engines and quite separate from the language. It supplies Scripting.FileSystemObject, the object through which a script reaches drives, folders and files: creating, copying, moving and deleting them, testing for their existence, building and parsing paths, and opening them as TextStream objects to be read or written a line at a time. The earliest VBScript and JScript engines had no file access at all, because the base languages did not, so the FileSystemObject is in practice part of the language for anyone who used it. The same library supplies Scripting.Dictionary, an associative container of key and item pairs which Microsoft's own reference describes, in as many words, as the equivalent of a Perl associative array. Between them these two objects are the reason a beginner could get useful work out of VBScript within a day.

The second is Active Directory Service Interfaces, a set of COM interfaces used to reach the features of directory services from different network providers and to present one vocabulary for managing network resources whatever directory holds them. ADSI shipped with an LDAP provider and a WinNT provider, and Internet Information Services added a provider of its own, so the same code shapes that enumerated users in a domain could also read and write the web server's configuration store. Microsoft's description of the intended audience is unusually blunt about who it was for: network administrators automating common tasks such as adding users and groups, managing printers and setting permissions on network resources. Directory scripting is where VBScript stopped being a convenience and became infrastructure, because a script that creates a thousand accounts correctly is worth a great deal more than a script that opens a dialogue box.

The third is Windows Management Instrumentation, which is not covered here: this directory has three pages on WMI, of which microsoft.public.windowsxp.wmi sits closest to this room's concerns, and they own the subject between them. It is enough to record that WMI was reachable from a VBScript file through the same COM machinery as everything else, and that a great deal of what looked like VBScript expertise in the 2000s was really WMI expertise wearing VBScript's syntax.

Around those three sat the rest of the working set. ActiveX Data Objects provided database access, and its stream class doubled as the way to handle binary data, to convert between byte arrays and strings, and to assemble long strings without the quadratic cost of repeated concatenation. The Microsoft XML libraries parsed and generated XML and, through their XMLHTTP and ServerXMLHTTP classes, fetched content over HTTP — which is how a scripting language with no networking of its own became a tool for talking to web services. And beyond all of these lay the general case: anything with a programmatic identifier could be created and asked to do something, which meant the practical limit on what a script could do was the reader's knowledge of what was installed.

Two boundaries are worth stating for the reader who arrives here from a search. Scripted administration — creating accounts, reading the registry, walking a file tree, driving an application — is this page's subject. The Win32 security model underneath it, the access control lists and security identifiers and tokens and the API that manipulates them, is the subject of microsoft.public.platformsdk.security, and the two rooms had genuinely different populations even when they were discussing the same permission.

Why a language this small needed a newsgroup

It is a fair question why a language with so few moving parts sustained a busy support group for a decade, and the answer is not that the language was hard. The answer is that the surrounding equipment was thin.

Microsoft did not routinely ship a development environment for VBScript. The Microsoft Script Editor came bundled with certain versions of Office; the Microsoft Script Debugger existed, was never much updated, and is remembered chiefly for having a clumsy interface. The ordinary tool for writing a script was a text editor, and the ordinary tool for finding out why it did not work was to run it and read the message: the host reports the type of error and the number of the offending line, and nothing else. There is no stack trace. In a language where every variable is a Variant and an undeclared name silently becomes a new empty variable unless Option Explicit is in force, a line number and an error type is a thin diagnosis. Third parties filled the gap with their own debuggers, and most text editors of the period learned to colour the syntax, which tells you where the demand was.

The documentation had the same shape. The reference material was a language reference and an object-model reference — complete, accurate, and organised by the thing being described rather than by the thing being attempted. What an administrator actually needed was the opposite: a worked example of the specific task, with the right programmatic identifier, the right method order and the one property that is not optional. Microsoft eventually supplied that too, in the form of a book-length collection of sample scripts published by Microsoft Press as the Microsoft Windows 2000 Scripting Guide — dated 16 December 2002 in the publisher's own catalogue, credited to Microsoft Corporation rather than to named authors, organised by administrative subject, and advertised as carrying more than four hundred sample scripts on an accompanying disc. The same material later reached the web through the Script Center and the long-running Hey, Scripting Guy! column, which answered reader questions in the same register a newsgroup does.

But the book arrived at the end of 2002, six years after the language, and a book is a fixed set of answers. A newsgroup is a machine for producing worked examples on demand, and that is the function this group performed. The unit of value in the archive is not the discussion; it is the short block of code that does the thing, posted in reply to somebody who described the thing badly.

Who answered, and what can honestly be said about them

Microsoft's public newsgroups were answered largely by people Microsoft did not employ and did not pay. That is a structural fact about how the company's support worked in this period rather than an observation about this particular room: the company created the groups, seeded them with occasional staff participation, recognised the most visible outside contributors through the Most Valuable Professional award, and otherwise let a volunteer population carry the load. The award itself — what it recognised, how long it lasted, and what it conspicuously did not confer — is described on the hierarchy page, which also records that recognition brought no moderator status and no privileged posting path, because there were no moderators and no privileged paths to have.

This page does not name individuals. The reason is evidentiary rather than coy. There was never a roster: no moderator list, no published register of which contributors were recognised in which year for which group, and no archived membership of any kind. The only surviving evidence of who answered questions here is the postings themselves, and a signature block asserting an award term is a self-description, not a record. Names circulate in the folklore of Windows scripting, and some of them are certainly right; verifying that a named person was associated with this specific group, from a source that would satisfy a reader checking a citation, is a different matter, and this directory does not guess.

What can be said about the cohort structurally is more useful anyway. The answering population in the scripting groups behaved like a small profession. Its members maintained reference material off Usenet — personal script libraries, annotated examples, frequently-asked-questions files — and answers in the groups routinely pointed at those pages rather than repeating their contents, which is one reason so much surviving Windows scripting material on the open web reads as though it were written to be linked to from a newsgroup post. Microsoft occupied the same territory from the vendor side with the Script Center and its scripting column. The two bodies of material were complementary and, at the level of individual worked examples, frequently indistinguishable.

There is one more structural point, and it is the least flattering. A volunteer support economy answers the questions it finds interesting. The archive of a group like this one is therefore not a representative sample of what users needed; it is a sample of what users asked in public and what answerers chose to pick up. The unanswered postings are in the archive too, and they are part of the record.

The reversal: what scripting cost, 1999 to 2001

Everything that made VBScript convenient made the mass-mailing worm possible, and the sequence is short enough to state exactly.

The overture was not VBScript at all. The Melissa virus, released on 26 March 1999 by David L. Smith, was a macro virus carried in a Microsoft Word document; Smith used a stolen America Online account to post the infected file to the newsgroup alt.sex with a claim that it contained passwords for pornographic sites. Opening it in Word 97 or Word 2000 copied the infected document into Word's default template and lowered the program's macro security, and on machines using Outlook it mailed a copy of the document to the first fifty entries in the user's address book, above a subject line that began with the words Important Message From and the sender's own name. It did not usually destroy anything. It did not need to: by 29 March the Computer Emergency Response Team at Carnegie Mellon had reports from 250 organisations and estimated at least 100,000 workplace machines affected, and the FBI later reported mail servers overloaded at more than 300 companies and government agencies, about a million accounts disrupted, and cleanup costs of some $80 million. Smith was arrested on 1 April, pleaded guilty that December and was sentenced in May 2002 to twenty months in federal prison. The technical lesson was already complete: the address book was the attack surface, and the mail client would enumerate it for anything that asked.

ILOVEYOU supplied the rest. Released on 4 May 2000 and written in VBScript, it arrived as an e-mail with the subject line ILOVEYOU and an attachment named LOVE-LETTER-FOR-YOU.TXT.vbs, and the Windows Script Host ran it when the attachment was opened. It overwrote files with copies of its own source, installed further copies to run at reboot under names imitating Windows system libraries, removed the registry value that limited how long a script could run, attempted to fetch a password-stealing trojan, spread over Internet Relay Chat as well as by mail, and mailed itself to every entry in the address book rather than the first fifty. It reached an estimated ten per cent of internet-connected computers and is generally credited with something on the order of ten billion dollars of damage. Because the worm was plain text, it was trivial to modify, and more than twenty-five variants were recorded. Its author, Onel de Guzman, was a student at a computer college in the Philippines whose thesis proposal for a credential-stealing trojan had been rejected; Philippine prosecutors dropped the charges because the country had no law against what he had done, a gap the government closed within weeks with an e-commerce act that could not be applied to him retroactively.

The coda came nine months later. On 11 February 2001 Jan de Wit, a twenty-year-old in the Netherlands using the name OnTheFly, downloaded a worm-generation toolkit written by an Argentine programmer known as [K]Alamar, produced a VBScript worm with it the same day, and posted it to a newsgroup. It travelled as AnnaKournikova.jpg.vbs, promising a photograph of the tennis player, and Outlook could suppress the trailing extension so that the attachment appeared to be an image. It corrupted nothing; it simply mailed itself to every address in the Outlook address book, and the resulting traffic was enough that firms shut their mail systems off as a precaution. The CERT Coordination Center heard from more than a hundred sites on 12 February, the day it went round the world. De Wit turned himself in on 14 February and was sentenced on 27 September to 150 hours of community service, his CD-ROM virus collection confiscated; the court rejected the FBI's damage estimate as insufficiently detailed but rejected his denial of intent too. There is a thread joining the three cases, and it is documented: Smith, by then cooperating with the FBI, supplied the bureau with de Wit's name and address. The significant detail, though, is the toolkit. By 2001 writing one of these no longer required knowing the language this newsgroup existed to discuss.

None of the three exploited a defect in VBScript. What they exploited was a set of perfectly reasonable defaults that had never been considered together: a script engine present on every desktop and associated with a double-clickable file extension; a mail client whose object model would read the address book and send messages on a script's behalf without asking anybody; and a shell that hid extensions for known file types, so that a name ending in .TXT.vbs or .jpg.vbs read as a text file or a photograph. Any one of the three is defensible. The combination was a delivery system.

A newsgroup created the day after

The eighth member of the scripting branch is microsoft.public.scripting.virus.discussion, and the control-message archive dates its creation precisely. The newgroup message was issued by Microsoft's own internal posting tool, from an address in the microsoft.com domain, and carries the date Friday 5 May 2000 at 10:00:26 Pacific time. ILOVEYOU had been released the previous day.

What that timestamp establishes is narrow and should not be stretched. It shows that Microsoft created a public newsgroup for discussion of scripting viruses on the first working morning of the outbreak; it does not show that the group was conceived that morning, and no internal record of the decision is public. But the sequence is on the record in a form anyone can check, and it is a rare thing to be able to date a support institution's response to a specific incident to the minute.

The group is still listed in the current newsgroups file, with the same one-line description as its seven siblings, and it received the same bulk re-assertion as the rest of the branch that November. Whatever was said in it during May 2000 is in the archive rather than on this page; what the namespace itself records is that the company's answer to the worm included, within twenty-four hours, opening a room.

What the defaults became

The mitigations that followed are the other half of the record, and they are worth listing in order because together they describe the end of an era of convenience.

• The Outlook E-mail Security Update, 2000. Microsoft's direct response to Melissa and ILOVEYOU introduced a category of attachment types, universally called Level 1, which Outlook would not open or save — executables, batch files, script files including .vbs and .js, and dozens of others. The attachments remained in the message; Outlook simply refused to give the user access to them. The update also introduced an object model guard which warns the user and asks for confirmation when an untrusted program tries to read address information out of Outlook or send mail through it. It was distributed for Outlook 98 and Outlook 2000, and the same protection has been built into every version from Outlook 2000 Service Pack 2 onward.
• Script signing, 2001. From Windows Script Host 5.6 a script could be digitally signed, either from within a script through the Scripting.Signer object with a certificate present on the machine, or with the signing tool from the Platform SDK, which was extended to understand the script file types.
• Software Restriction Policies, Windows XP. A machine could be configured to execute only scripts stored in trusted locations, or matching a known hash, or signed by a trusted publisher — the first general mechanism in Windows for saying no to an arbitrary script by policy rather than by antivirus signature. The mechanism itself was later deprecated in favour of AppLocker and application control.
• The Attachment Manager, Windows XP Service Pack 2, August 2004. One service in Windows applying a consistent judgement to attachments arriving with mail and to files saved from the internet, blocking what it considered unsafe or warning before it opened, rather than each application implementing its own list.
• Antivirus interception. Vendors added specific controls over scripts running in the Windows Script Host environment, and some published advice recommending that the host be disabled outright on machines that did not need it — a suggestion that would have been unthinkable in 1998 and was commonplace by 2001.
• The browser, 2019. VBScript disabled by default in Internet Explorer 11 for the Internet and Restricted Sites zones, as described above.

The object model guard deserves a note of its own, because its effect on this newsgroup's subject matter was direct and lasting. A prompt that a human must answer defeats a worm; it also defeats a scheduled script that was supposed to run unattended at three in the morning. Legitimate mail-automation scripts written before mid-2000 broke, and the workarounds — administrative policy settings, alternative libraries, redesigning the job so that it never touched Outlook — became a permanent category of question. Microsoft's own documentation later conceded the difficulty in as many words, observing that the default circumstances in which the guard fired produced excessive prompting for legitimate applications and that the limits of COM made it hard for a user to tell which program was asking. This is the honest shape of the security reversal: the defaults changed, the worms mostly stopped, and a large amount of ordinary automation had to be rewritten. The record shows all three outcomes and this page takes no view about the trade.

What replaced it

Two successions happened, one for each half of the language's working life.

On the web, ASP.NET arrived in January 2002 and the older technology became classic ASP. The scripting team's decision that future language support belonged in ASP.NET is also the reason the VBScript engine stopped being developed: the road forward was compiled managed code, and the interpreter was left where it was.

On the shell side the succession is a longer story, and every date in it postdates the 2000 to 2004 window in which this directory's gateway operated, so the reader should treat what follows as the aftermath rather than the period. Microsoft began work on a new approach to command-line management by 2002, under the code name Monad; the chief architect, Jeffrey Snover, published the design in August 2002 in a white paper called the Monad Manifesto. Monad was shown publicly at the Professional Developers Conference in Los Angeles in October 2003, reached public beta on 17 June 2005, and was renamed Windows PowerShell on 25 April 2006, a rename Microsoft used to position the shell as a significant part of its management technology rather than a side project. PowerShell 1.0 was released in November 2006 for Windows XP Service Pack 2, Windows Server 2003 Service Pack 1 and Windows Vista, and as an optional component of Windows Server 2008. Version 2.0 integrated with Windows 7 and Windows Server 2008 R2, and in October 2009 Microsoft's own TechNet Magazine described proficiency with it as the single most important skill a Windows administrator would need in the coming years.

The design argument is the interesting part for anyone reading VBScript today. The Windows Script Host let a script call COM objects, which was a large improvement on batch files, but everything crossing a pipe was still text. PowerShell's premise was that Windows exposes structured data through interfaces rather than text through files, and that a shell for Windows should therefore pass objects between commands rather than lines. Snover has said as much explicitly: his attempt to bring Unix tooling to Windows failed on that architectural difference, because one system treats everything as a text file and the other as an interface returning structured data. VBScript scripts did not stop working — they still run — but from 2006 onward the new material, the new documentation and eventually the new answerers were somewhere else.

The formal end came much later and is still in progress. In October 2023 Microsoft added VBScript to its published list of deprecated Windows features, with the note that it would be available as a feature on demand before its removal from the operating system. A three-phase plan followed in May 2024. In the first phase the VBScript features on demand are preinstalled in Windows 11 version 24H2 and enabled by default, so that existing dependencies keep working while they are migrated; in the second, which Microsoft places around 2027, they will no longer be enabled by default and will have to be switched on deliberately in the optional-features list; in the third the libraries themselves are removed and anything depending on them stops working. No date has been announced for the third phase. Microsoft's stated replacements are PowerShell and JavaScript.

Twenty-seven years elapsed between the release and the deprecation notice, which is a long run for a language that shipped as a browser feature, and the notice is in its way a compliment: a technology that could simply be switched off would not have needed a three-phase plan.

The group's own record

Set against the technology, the group's own documentary record is thin, and this is the ordinary condition of vendor newsgroups rather than a failure of searching.

There is no charter. Microsoft's hierarchy had no proposal process, no discussion period and no vote, so nothing was ever ratified; the nearest thing to an official description of this group is the three-word line in the newsgroups file, which is shared verbatim with its seven siblings. There is no creation record beyond the two control messages described earlier, the earlier of which was generated automatically by somebody else's server. There is no moderator, because the hierarchy had none. There are no published traffic figures for any individual group, no subscriber counts, and no register of contributors.

What does exist is the archive, and the shape of the archive is itself evidence. A group that ran from the late 1990s to 2010 in a namespace fed outward to public news servers left a very large body of dated, threaded, attributable text, in which the questions record what people were actually trying to do with Windows in those years and the answers record how it was actually done — as distinct from how the documentation said it should be done. That is the group's value now, and it is a documentary value rather than a nostalgic one.

Four things this page cannot settle. When the group was created: the evidence supports late 1999 at the latest and no more. Whether it was a rename of the older inetsdk-era group, a promotion from the programming branch, or an independent creation that coexisted with both: the namespace shows all three names, the inetsdk one is still listed today, and the control archive records no relationship between them. How busy it was relative to its neighbours: no per-group figures were ever published. And who did the answering: the postings name themselves, and this page declines to convert self-description into attribution.

Scope and limits

Everything technical on this page has been checked against Microsoft's own documentation, its published security bulletins and deprecation notices, or the Usenet administrative record mirrored by the Internet Systems Consortium, and where two sources disagree — as they do about a VBScript 6.0, and as Microsoft's own two version tables do about the Windows Script Host in 2000 — the disagreement is stated rather than resolved by preference.

Several adjacent subjects are deliberately absent because other pages in this directory own them. The microsoft.public.* hierarchy itself, the news server, the Most Valuable Professional award and the 2010 retirement belong to the hierarchy page. Windows Management Instrumentation belongs to this directory's three WMI pages. The Win32 security model, its access control structures and its APIs belong to the Platform SDK security group's page. Excel programming and Visual Basic for Applications belong to the Excel programming page. The French-language scripting rooms belong to their own page.

Two further limits are the reader's to keep in mind. The first is that this article describes a language and its hosts in order to explain what a room was for; it is a history, not a manual, and it contains no code and no operational guidance of any kind, including in the sections about worms, where the mechanisms are described only to the level the published record already describes them. The second is that no group-specific colour has been invented to fill the gaps. Where the record is silent — on creation, on traffic, on the people — this page says so and stops, which is less satisfying than a story and considerably more useful to anyone who needs to cite it.