Why Are All Your Scripts Written in VBScript?

Posted by Greg Stemp. In general, I think people have found the TechNet Script Center to be incredibly useful. That doesn’t mean they think the Script Center is perfect. (True confession time: It’s safe to say that we don’t think it’s perfect, either.) As a result, we get numerous questions from people wondering why the Script Center has been set up the way it is. Perhaps the most often-asked of these questions is this one: “How come all your scripts are written in VBScript? How come you don’t ever use Jscript or Perl or Kixtart or ….” And close on its heels would be questions like these: “How come all your scripts are designed to run against one computer? How come they never use error-handling, how come the output is never nicely-formatted, how come ….“ 


Because there seems to be so much interest in this, I thought I’d officially kick off the Scripting Guys’ Blog by answering some of these questions. To do so, though, we’ll first have to take a journey back through the mists of time.


The History of the TechNet Script Center


You might think that the TechNet Script Center is the result of extensive market research, that it was put together only after we had conducted numerous surveys and hosted scores of focus groups. And it was, except for the fact that there was no market research, no surveys, and no study groups. Instead, it just sort of happened.


Back in August, 2000, I was hired to be a technical writer for a new book: The Microsoft Windows 2003 System Administration Scripting Guide. (Of course, back then it was known as the Whistler Scripting Guide. And we never officially referred to it as the System Administration Scripting Guide, it was always the acronym SASG, much in the same way no one at Microsoft has a first or last name, they only have an email alias. And unless you're willing to take action items, unless you want to take this discussion offline, or unless you have the bandwidth, don't even bother applying for a job here: you'll never understand a single thing said in any of our meetings. Which, come to think it, would pretty much put you in the same boat as me.)


To this day, I still have no idea why I was hired; I had zero experience as a technical writer, and even less experience as a script writer. Nevertheless, all of a sudden I found myself part of the Scripting Guide team. That probably tells you something about how important scripting was viewed back then. Let’s see, we just hired a guy with no discernible knowledge or abilities ... hey, I know, we’ll make him a writer on the Scripting Guide!


Ok, sorry: we'll make him a writer on the SASG!


Interesting side note: When my Microsoft recruiter called to offer me the job, she was suffering from a terrible case of the flu. I agreed to take the job, and went in to sign all the papers. After the paperwork was done, and after it was agreed that I would start work the coming Monday, she said she was feeling just awful and was going home. Needless to say, I didn’t blame her. However, in her understandable haste to get home, she forgot to notify anyone that I had taken the job. On Monday I went to my new employee orientation, and then showed up to work, only to find that no one was expecting me: I had no office, no computer, no keycard, no account on the Microsoft network, nothing. I spent my first week sitting in the office of someone who was on vacation, being careful not to touch anything, and reading a bunch of whitepapers, not because they had anything to do with scripting, but because they couldn’t figure out what else to have me do. (As befits any big company, they wouldn’t let me just stay home until they had something for me to do, even though I said I would do that without pay.)


Once they finally got me in the system, gave me a place to sit (my new officemate, who previously had the office all to herself, refused to speak to me for two weeks), and gave me a computer (one they pulled out of the recycle pile, a computer that’s still my primary machine today) I was finally ready to go to work. My first assignment was to write a chapter on scripting event log management. That was a daunting assignment, but, fortunately, they’d already prepared a detailed outline for me. All I had to do was fill in a few words here and there.


One of the first things I noticed about the proposed chapter on scripting event log management was the fact that there weren’t any scripts in it; it was all about using command-line tools to manage event logs. I have nothing against command-line tools, but I felt compelled to ask why there weren’t any scripts in there. “That’s because you can’t manage event logs using scripts,” I was told.


Now, to be honest, I had no idea whether you could manage event logs using scripts; like I said, I knew nothing about scripting. I did, however, know a little bit about this thing called WMI, so I said, “What about WMI? Can you manage event logs using WMI?”


“WMI?” was the reply. “You can’t do anything with WMI. It’s way too slow, it’s too hard for people to understand, and it doesn’t even work.” And so, not knowing any better, I proceeded to write a chapter on scripting event logs, a chapter that included a grand total of zero event log scripts. And when I finished that, they gave me a second chapter – one on managing services – that didn’t have any scripts in it, either.


By now I was getting a little nervous about this, so I started looking into WMI on my own. About the same time, we hired Bob Wells. How little did I know about scripting back then? Well, Bob Wells was Mr. Scripting in those days (and still is), and I’d never even heard of him. But there’s no doubt that Bob saved us from releasing a scripting book that had no scripts in it, and through sheer force of will he got us moving in the right direction. Several months after it was decided to write a scripting book, we finally made the decision that maybe this book ought to actually include some scripts after all. (At that point in time we still didn’t have a chapter on VBScript, but that’s a story for another day.)


Of course, after we decided to actually add scripts to the book we then went overboard in that direction. Up to that point we had a book with no scripts in it. Now we decided that, in deference to Bob, we’d have VBScript scripts; however, in deference to all other sentient beings in the universe, we’d also have batch files, Jscript scripts, and Perl scripts. Each time we had a task (say, clear an event log), we’d have to write four separate scripts: VBScript, Jscript, batch file, and Perl. For me, this was an interesting turn of events. Up until then I felt bad because I didn’t know VBScript; now I didn’t know Jscript, batch files, or Perl, either. Considering the fact that I was, to a very large extent, the only writer on the team, I could see nothing but disaster ahead.


Fortunately, Bob stepped in again and, in his immortal words, said it was time to “put a stake in the ground.” He decided we would limit ourselves to VBScript, recognizing that:


  • VBScript was a Microsoft technology.

  • VBScript was part of the operating system

  • VBScript was far more powerful than batch files.

  • VBScript was easier to learn than Jscript, at least for system administrators (who were our target audience).

  • There weren’t many system administration scripts available back then, but the few that had been written were typically done in VBScript.

  • Not many admins knew any scripting language, but many had had at least some exposure to BASIC and/or Visual Basic. Because VBScript is a subset of Visual Basic, VBScript seemed a little less exotic and programmer-like than, say, Jscript.

  • We didn’t have the resources to write scripts in multiple languages and, even if we did, we’d likely end up with a 900-million page book that would confuse and bewilder anyone strong enough (or silly enough) to open it.


So there you go. Why do we write all our scripts in VBScript? Because Bob told us to (and if you know Bob Wells, then you knoiw it's always best ti do whatever Bob tells you to). And, all things considered, I think that was one of the smartest decisions he (or anyone else around here) ever made; the enormous success of the Script Center and the huge number of system administrators who are now writing scripts attests to that. Nonetheless, I feel compelled to note that, as VBScript-centric as we might be, we’re not opposed to other scripting languages; in fact, to a very large extent we consider the language to be the least of your worries. Why? Because no scripting language, in and of itself, allows you to do much in the way of system administration tasks anyway; to really do something useful with a script, you need to tap into WMI or ADSI, something any scripting language can do. What you need is a language capable of interacting with WMI and ADSI; beyond that, well, under the covers all scripting languages are remarkably similar (they all have some kind of echo function, they all have some kind of If-Then construct, they all allow for looping, they all have some kind of error-handling mechanism, they ....)


Editor's note. That's my opinion, at least. I'd love to hear opposing viewpoints (e.g., why you absolutely must use Perl or Rexx or Kixtart or ....).


By while we're agnostic on the subject of which scripting language is “best,“ we do at least pay lip-service to the fact that VBScript isn’t for everyone. Scriptomatic 2.0 (which we really do intend to release someday) can write scripts in VBScript, Jscript, or Perl. And we also have long-standing plans to do a translation guide, something that will show you how to take a typical Script Center script and convert it not only to Jscript or Perl, but to Rexx, or Kixtart, or whatever. I don’t know for sure if that translation guide will ever see the light of day, but at least it’s on our wish list. Until then, it’s VBScript all the way; as the old saying goes, ya gotta dance with whut brung ya.


Tomorrow: Why the scripts in the Script Center are all so simple.


Comments (12)

  1. Jack Mayhoff [MSFT] says:

    NET languages becoming scripting alternatives, would there be a subset of C# for C# scripting to be an alternative to VBS and I guess this would mean Windows Scripting Host would get an upgrade to have its own mini CLR, right?

    If there is such a subset of C# for scripting (if its not gona be fully functional) would this be ECMA/ISO standardized like the full C# or would it be proprietry?

  2. ntdoc says:

    Why? Did you ask WHY?

    Well, I’m not sure anyone can put a solid dollar amount on the amount of DAMAGE done to computer systems due to VB Script. I’m sure it must be approaching the $$ Billion dollar mark by now as they still keep churning them out almost daily in the VIRUS/WORM department.

    This though is only due to the fact that it is associated in the registry and has autorun macro capability. That is where the danger is with VBS. Great language otherwise, just think Microsoft needs to really come up with a "GOOD" solution to controlling it. Not the sort of things they typically try by removing capabilities etc… Of course since it is out and has been out on Windows computers for years now and you can’t FORCE users to update their systems I think we will always be stuck with a certain amount of systems around the World that will be unwilling participants in the Virus/Worm Wars.

    One of the nice things about KiXtart is that it does support Windows 9x and NT/2000/XP/2003 without having to have anything installed on the client. For the NT class machines it only requires a single EXE file to function. VB Script / Windows Scripting Host requires external dll and ocx files to properly function. Since KiXtart is not part of the operating system it has no native file associations to auto launch it for things like Virus and Worm activities. Yet it can still be easily used for Administrative work or logon scripts etc…

    KiXtart was developed by Ruud van Velsen of Microsoft Netherlands as a Logon Script tool. It has many macros and functions designed to easily be used to return or set information on a computer system.

    Many tasks can be written with much less code using KiXtart then VBS for typical logon functions such as adding printers, checking group memberships, etc… It too as you’ve stated supports running ADSI and WMI.

    KiXtart also supports creating your own functions for code portability. You can write your own functions for repetitive tasks, or like the Script Center, just copy any of the pre-written scripts and use as is, or with minor modifcations for your environment.

    KiXtart UDF


    KiXtart UDF from ScriptLogic


    KiXtart also has GUI Form support that allows a script writer to wrap his/her own code within a GUI wrapper.

    KiXforms site


    KiXforms demo scripts


    There are dedicated editors for KiXtart


    There is also a KiXforms Designer written in .NET to support the KiXtart GUI Interface


    There is a Commercial product to make KiXtart scripting even easier for a total novice that either does not have the time or isn’t willing to spend the time to learn any scripting language. ScriptLogic 5

    Starting out new writing VB Scripts can be quite frustrating with with minimal feedback as to why your script didn’t work.

    KiXtart attempts to tell you more specifically what is missing and on what line.

    There is also a tool to take a complete script and run through it and have it tell you where there are errors in the script such as missing quotes or miss-matched IF ENDIF or other functions. KiXstrip analyzer tool


    The main site http://www.kixtart.org has a LOT of very responsive members that typically will answer just about any scripting question within minutes of posting.

    Well there are many, many other reasons why I use KiXtart – but hopefully that gives you some insight as to why I continue to use KiXtart.

    IT’S THE PEOPLE, at [KORG] KiXtart’s BBS

  3. Lonkero says:

    so, greg.

    what you are basically saying is that VBscript is there because of you listened bob who had personal liking in vbscript?

    no wonder, total n00b with a person that can script, that must have felt like heaven to you.

    but, vbscript in my mind even isn’t a scripting language.

    it’s com-port via which you can start scripting.

    it has nothing inbuild and the syntax is more than loong.

    perl on the other hand is powerfull (almost as much as TCL [personal comment, don’t shoot me for it]) yet can go way over the heads of an script-kiddie.

    now, take a totally unintroduced buddy to write a script.

    any script. say clear eventlog.

    with kiXtart it’s only about running script with one line:


    that just an example.

    you see question is not about bob’s personal opinion.

    it’s about the personal opinion of system admins around the world.

    and even though at some points corp administration may force vbscript everywhere, there will be fight.

    for freedom to write simpler faster and easier to understand scripts with 10% the time.

    oh, btw.

    KiXomatic 2.1 is foundable at:


  4. Tarjei T. Jensen says:

    Thanks for the explanation. It was spot on.

    The important bit is to keep things simple and illustrate the point.

    Now we hope that microsoft manages to clean up the WSH/WMI stuff, make it work and BACKPORTS it. We still have older stuff working. We won’t ditch it just because WSH/WMI support is patchy.

    To me it looks like the WSH/WMI stuff was a good idea, then suddenly the programming team got pulled and had to work on something else. Either that or there were no system administrators in the group (hey guys! it is not finished until I can do <specific points inserted here>).

    We really need Microsoft to follow through on this one.


  5. Greg Stemp says:

    Just a few responses to the various comments posted here.

    First, nice to see the Kixtart guys represented. I was sort of vaguely familiar with Kixtart when I started working here, and I had heard nothing but good things about it. I was also very surprised when I first learned that it was developed here at Microsoft. Why didn’t we adopt that as our primary scripting technology? I have no idea. And I can’t really comment on the pros and cons of Kix other than to say that it looks interesting. (I know, you’d think it be part of my job to be up on all scripting languages. As it is, though, I’m still struggling to get a handle on VBScript.)

    But we’ll see what we can do about publicizing some of these other languages. (The truth is, we don’t really care what language you use; we’re more concerned with helping people learn about WMI and ADSI.) We don’t have a good mechanism for doing this right now (although we are responsible for the content in the Script Center, we can’t currently do things like add links to it), but we’re working on that.

    As for the comment about backporting WMI stuff, we can definitely pass this suggestion on to the WMI team. That’s not much, but that’s about the best we can do for now.

  6. Sealeopard says:

    I think you ended up with VBScript exactly because it is a toned-down version of Visual Basic and it is highly integrated into Microsoft Products. You basically have the same scripting language as VBA in Microsoft Office, VBScript in Internet Explorer, Visual Basic in Visual Studio. So, there is definitely some consistency going on. It makes it easy for people to migrate between the different versions

    KiXtart used to be part of the Resource Kit, but I guess it lost out because it did not make its presence felt as much as VB*

    BTW, one of our fellow KiXtart BBS Moderator "borrowed" your Script-O-Matic code and changed it to KiX-O-Matic. You can see the results under the following URL: http://www.kixtart.org/ubbthreads/showflat.php?Cat=&Board=UBB13&Number=86416

    KiXtart and VBScript are syntactically very closely related so that transforming scripts form one language to the other is basically changing the way variables are defined (KiXtart requires a preceeding $ sign) and strings are concacenated ("&" in VBScript versus "+" in KiXtart)

    Re Backporting: Yes, the new Windows Server 2003 and Windows XP WMI functionality should definitely be backported to Windows 2000 at least. Windows 2000 will not go away until the next OS release (at least) as a lot of companies will jump the Windows XP/Server 2003 revision and upgrade directly to Longhorn. It also makes it easier to write admin scripts as you do not need to worry about the operating system of the remote client or even the local computer it is run from.

    BTW, nice to be able to interact with you!

  7. Yehoshua says:

    I’ve written a few scripts in VBS and a few in Perl. I find VBS easier oto use the Perl, but if I have to do anything serious with a string, I use Perl. e.g., I wanted to change the logon scripted being used to one with a similiar name. Try doing this with VBS:

    use strict;

    use Win32::OLE(‘in’);

    my $logscr;

    my $objDomain = Win32::OLE->GetObject("WinNT://company,domain")

    or die "LDAP connection failed.n";

    $objDomain->{Filter} = "User";

    foreach my $objItem (in $objDomain)


    $logscr = $objItem->{loginscript};

    #check if logon script is variation of "time", time1, time3 and change it to time

    if ( $logscr =~ /timed+/)


    print "n Name: $objItem->{Name}";

    print "t Old Login Script: $logscr";

    $objItem->{loginscript} = ‘time.bat’;


    print "t New Login Script: $objItem->{loginscript}";



    print "n"

  8. Lonkero says:


    checked your code and quick draft gives for KiX:


    $objDomain = GetObject("WinNT://company,domain")

    if @error exit @error endif

    $objDomain.Filter = split("User")

    for each $objItem in $objDomain

    if "time" = left($objItem.loginscript,4)

    "Name: " $objItem.Name ?

    "Old Login Script: " $objItem.loginscript ?

    $objItem.loginscript = "time.bat"


    "New Login Script: " $objItem.loginscript ?




    so, not sure which is harder…

    obviously, VBS code would be little longer but not harder.

  9. Roy Sprague says:

    I’ve written scripts in VBS, Kix, Rexx and Perl and find Perl to be easier to read and more powerful. VBS and Kix are useful for logon scripts but for real administration of remote machines and parsing files nothing beats Perl.

    I’ve been using Perl since 1997 and have saved well over $100,000 using Perl to consolidate domains. Try migrating 12000 select users from 5 domains with over 50000 users into one domain and create all the associated groups with VBS.

    Try parsing through your exchange 5.5 log files with VBS. The following is something I’m just about to finish up and will report how many emails users are sending to each other to identify abuse. The syntax would be exlog.pl \email01tracking.log

    Try doign this with VBS or Kix.

    use Term::ReadKey;

    my $logs_dir = $ARGV[0];

    my %sendercnt;

    my @dir;

    foreach $logs_dir (@ARGV)


    opendir( DIR, "$logs_dir" )

    or die("Can’t access directory: $logs_dir");

    my @lists = grep {/^200/} readdir( DIR );

    @dir = (@dir, @lists) ;


    foreach my $log_file ( @dir )


    my $file = "<$logs_dir/$log_file";

    open ( my $log, $file ) || print "Can’t open $log_filen";

    my $size = (stat($log))[7];

    print "$sizen";

    my ($percent, $prev_percent, $lines, $prev_lines) = ( 0, 0, 0, 0 );

    while(<$log> )


    $percent += length($_) / $size * 100 if $size;

    if ( $percent – $prev_percent > .01 )


    print sprintf("Processing $log_file: %2d%%r", $percent);

    $prev_percent = $percent;



    my @line=split(/t/,$_);

    if ($line[6] ne "")


    @sendline = split("=",$line[6]);

    $sender = lc($sendline[$#sendline]);

    $unknown = index($sender,"unknown");

    $event4 = $line[1];


    next if $unknown >= 0;

    if ($event4 == 7 or $event4 == 8 or $event4 == 9 or $event4 == 1000)


    if (index(lc($line[0]),"cn=") > 0 or index(lc($line[0]),"smtp=") > 0)


    @recipline = split("=",$line[0]);

    $recipient = lc($recipline[$#recipline]);





    print "Processing $log_file: Done n";


    print "Enter user to search for or type all: ";


    $user = ReadLine(0);

    chomp $user;

    print $user;

    my $report_file = "./" . $user . "s.txt";

    open(my $report1, ">$report_file") || die "Can’t create $report_file: $!";

    print "Writing the report to: $report_filen";

    print $report1 <<EOT;

    Email Activity

    Sender Recipient Number

    of hits

    ————————————————– ————————————————— —————


    my $sendercnts = %sendercnt;

    foreach $k1 ( sort keys %$sendercnts ) {

    my $h;

    $h = $k1;

    foreach $k2 ( keys %{$sendercnts->{ $k1 }} ) {

    my $line = sprintf("%-50.50s", $k1 );

    $line .= sprintf(" %-50.50s", $k2 );

    $line .= sprintf(" %8d", $sendercnts->{ $k1 }{ $k2 } );

    if ($user eq "all")


    print $report1 "$linen";




    $oput = index($line, $user);

    next if $oput < 0;

    print $report1 "$linen";




  10. Tim Scarfe says:

    Hey Greg,

    It was fascinating to read your bits and pieces about starting at Microsoft. I hope one day when I am an MSFT employee (fingers crossed) I will write a similar account!

    I have always used JScript, JScript and nothing but JScript. I really don’t like VBS because it seems like a bit of a kiddie language. For one of my clients I am forced to work on a large web application written in Classic ASP with VBS and it’s such a headache it gives me nightmares.

    I origionally come from a DHTML background (I am one of the guys from http://www.dhtmlcentral.com) so I have been used to hardcore JavaScript. Even the most complicated JScript programs I write to deal with COM object i.e. FSO, Databases, WMI, ADSI et al seem like childs play compared to the DHTML wrangling!

    I only really use interprited scripting now when I have to because to be honest 9 times out of 10 it’s easier just to cook something up in the .NET framework. Of course I understand scripting is an administrators thing and you can use group policy to easily deploy scripts. It’s funny because I haven’t worn my administrators hat in a couple of years now so I look at it all from a dev’s perspective.

    Enough rambling. Great blog – will keep reading.

  11. lonkero says:

    heh, remembered this blog when was browsing MSDN "what MS thinks of Perl":


Skip to main content