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.