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
- Anonymous
February 11, 2004
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? - Anonymous
February 12, 2004
The comment has been removed - Anonymous
February 12, 2004
The comment has been removed - Anonymous
February 12, 2004
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.
greetings, - Anonymous
February 13, 2004
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. - Anonymous
February 13, 2004
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! - Anonymous
February 14, 2004
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';
$objItem->{SetInfo};
print "t New Login Script: $objItem->{loginscript}";
}
}
print "n" - Anonymous
February 15, 2004
Yehoshua...
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"
$objItem.SetInfo
"New Login Script: " $objItem.loginscript ?
endif
next
-------------------------------------------------------------
so, not sure which is harder...
obviously, VBS code would be little longer but not harder. - Anonymous
February 18, 2004
The comment has been removed - Anonymous
February 19, 2004
The comment has been removed - Anonymous
February 23, 2004
heh, remembered this blog when was browsing MSDN "what MS thinks of Perl":
http://msdn.microsoft.com/library/en-us/dnclinic/html/scripting012299.asp - Anonymous
May 29, 2009
PingBack from http://paidsurveyshub.info/story.php?title=the-scripting-guys-first-blog-why-are-all-your-scripts-written-in