With the rise in popularity of Linux and Unix systems, more and more system administrators are beginning to see and seek the time and cost saving advantages using scripts in order to perform administrative functions, which when properly used can lower the cost of ownership for servers.
Additionally, many system administrators are leaning more and more towards simple, Command Line Interface (CLI) driven environments, which, although not "user friendly," allow an experienced administrator to quickly and elegantly perform numerous tasks. Microsoft's response to this is the increased power and versatility found in the newest version of its Windows Script Host (WSH).
In this article, I will introduce you to Microsoft's newest Windows scripting environment, WSH 5.6. My goal here is not to teach you how to script. Rather, this tutorial is meant to be an overview for those who wish to understand the concepts behind WSH a little bit better. I'll cover some of the newest improvements, including the increased functionality of the significantly enhanced command-line infrastructure, as well as some of the syntax. I'll also be talking about how to put this all together in the right order so as to do something which might in some instances resemble actual work. In the process, I'll point out various good sources of continuing education on the subjects covered.
Ok, before we start, I'll presume that you know and understand what a script is. If you do, then skip to the next section. If you don't, then keep reading.
A script is a set of instructions. The computer executes the instructions, then returns some sort of value: a number, string, list, or another data type. As far as the WSH goes, it might look something like this:
<? XML version="1.0" ? > <!-- Filename: Hello.wsf--> <job> <script language="VBScript"> WScript.Echo "Hello, from you VBScript friends! Please press OK." </script> <script language="JScript"> WScript.Echo ("Hey, this is JScript. Can you click OK again? I can't quite reach it.") ; </script> </job>
I say "might" because WSH is really a language-independent, object-model independent tool. At first, most of the stuff you'll be looking at will probably look like this:
'This will tell you the Username, Domain, and Computer Name Set WshNetwork = Wscript.CreateObject("Wscript.Network") Wscript.echo WshNetwork.Username Wscript.echo WshNetwork.UserDomain Wscript.echo WshNetwork.ComputerName
Just a tad different, wouldn't you agree?
If you're sure that you have at least WSH 2.0 installed, then go ahead and copy and paste these into Notepad, saving them as example1.wsh and example2.vbs (respectively). Double click on them and see how they work. If you're not totally sure that you have at least version 2.0 installed, keep reading before you do anything else. Don't worry about whether you know those commands mean right now. By the time you finish this you'll know at least what they're doing and how. All you should care about right now is that you know what a script is. Hazzah!
So now that you're well versed in what a script is (if you weren't to begin with), you probably want to know what a script host is. In short, a script host is a program that provides an environment in which users can execute scripts. If you're reading this, there's a 99.99% chance that you've used a script host before. For you *nix folks, shell programs such as C shell, Bash, and Korn shell are script hosts that use an object model that enable you to manipulate a file system. The DOS prompt can be thought of as a scripting environment because it can run scripts written in the "batch file" language. Heck, if you're reading this while using a browser that can execute scripts that use the Dynamic HTML object model, then you're using a script host right now!
That being said, the Windows Script Host (WSH) is what allows you to run scripts in the Windows platform by creating an environment for hosting scripts. It's a general purpose scripting environment that can run scripts in a variety of languages that use a variety of object models to perform specific tasks. That's because it imposes no restrictions on either the language used to write the script or the object model used by the scripts. In fact, it's a bit like the whole .NET thing, exercising the philosophy of many languages, one platform. Here's an overview of how it works:
When you run a script that you or someone else has written, the WSH will call the correct script engine in order to perform the given task(s), depending on what kind of script you wrote (whether it be JScript, VBScript, or with special preparation Perl, Python, REXX, among others). Now, it doesn't matter whether you double click on the script, run it from the command line, call it from another script, or it comes to you over a network; The WSH still comes up and runs it, provided it meets certain criteria.
If you're like me, you're probably thinking, "Hey, wait a minute? What about security? What do you mean it just 'runs it'?" Well, with the latest version of WSH, there's an improved security model which addresses some of those concerns. This is why you should make sure that you're running the latest release of WSH. You can go to the Microsoft website and download the latest version (5.6, as of this writing). If you're running Windows XP or 2003, don't worry - you're already up to date. For more information on the security improvements, loving in the wrong kind of way, and ugly babies, check out the MSDN scripting website. Note that all the information in this tutorial pertains to this latest version.
Ok, so you're running the latest version of WSH. Now you're ready to run scripts written in VBScript, JScript, or your favorite scripting language. All you have to do is double-click on any file that has the .js, .vbs or .wsf extension and that file will be executed within the WSH environment. Of course, you can also open up a DOS prompt to the right directory and run it from there. I don't recommend doing this with every .vbs, .js, or even .wsf file you can find, however. Not unless you want a virus infestation on your system bad enough to annoy Robin Miller. You'll want to make sure that your anti-virus definitions are up to date and that you scan every file that you didn't write. After testing your scripts thoroughly, you can even use the Windows Task Scheduler to schedule when to run them. For example, you can have Windows run WSH and the script automatically whenever Windows starts up or when you want to make sure you don't miss Futurama re-runs.
Now, what about Perl, Python, and all those other scripting languages that I promised you that you could run? After all, don't they have other extensions, like .plx and .py? Unfortunately, it wasn't until version 2.0 that WSH could run anything other than .vbs and .js scripts. In the later versions, Microsoft teamed up with a number of third parties to increase scripting language support for WSH. Still, if you try to run a Perl program with a .plx extension, it'll simply run as a Perl program. The same goes for Python. The way Microsoft's added this functionality and still kept it all under control is by implementing XML and tacking on the .wsf extension to these files. The biggest advantage of doing this is the ability to run multiple languages within one script, such as is the case in the following script:
<?XML version="1.0" ? > <!-- Filename: Hello.wsf--> <job> <script language="VBScript"> WScript.Echo "Hello, from you VBScript friends! Please press OK." </script> <script language="JScript"> WScript.Echo ("Hey, this is JScript. Can you click OK again? I can't quite reach it.") ; </script> </job>
Notice the switch in languages in line 7. This functionality allows you to perform multi-paradigmic tasks in one script. This comes especially handy when you're dealing with two totally different languages, such as VBScript and PerlScript. It also makes it easier to write reusable code and specify references to external type libraries.
Now that you understand a bit about what WSH is and what it does it's time to start using it.
There are two programs that we'll be dealing with in the following sections. The first is WScript.exe, which is the graphical version of WSH. It provides a standard Graphical User Interface (GUI) to set properties. The second is its command-line cousin, CScript.exe, which uses switches (such as //I and //B) to do the same thing. The differences between the two programs are more than just the difference between getting the output from a pop up window or a command prompt. In fact, there are certain advantages to both, which I'll discuss shortly.
As far as WScript.exe is concerned, there's not really much to tell. To see a script's properties you do what you always do to check the properties of a file: Right click on the file -> Properties. What you will notice is that in FAT and FAT32 environments you'll only get two tabs (General and Script), while in NTFS environments you'll get a third (Summary) and possibly a fourth (Security), depending on your configuration. When properties are set on a script, a text file by the name of the script and with a .wsf extension is created. This file is used as a control file for the scripts settings and can be used to launch the script.
A bit more interesting is the CScript.exe file, which you'll need to run from a command prompt. The syntax of the command is as follows:
Under most circumstances, of the three bracketed options, only the script name is required. Just typing cscript will display the command page. Speaking of which, here's the list of commands:
//I Default setting: Interactive mode (opposite of //B)
//B Batch mode: Suppresses script errors and prompts from displaying.
//D Enables active debugging.
//E:Engine Use a certain engine for executing scripts. This is useful because it allows you to run scripts with custom file name extensions. Example: cscript //E:vbscript test.admin The advantage of doing this is that it guards against accidentally double clicking and running a script you didn't want to run.
//Job:xxxx Executes a WSF job
//T:nn Time out in seconds. Maximum amount of time a script is allowed to run (default is indefinitely).
//logo Default: displays a logo banner.
//nologo Suppresses the logo banner. This is often used by scripts that output to a file which needs to be parsed or used as the control document for another script.
//H:cscript Changes default to CScript.exe.
//H:wscript Changes default to WScript.exe (this is the default).
//S Save the command line options. For example, if you never want to see the logo, then you would type the following: cscript hello.vbs //nologo //S.
As I mentioned before, there are certain advantages to using either the GUI or CLI versions of WSH. The biggest advantages are in favor of the CLI (CScript.exe), which allows you to exercise greater control over how a file should be run and interpreted. Running scripts under CScript enables them to run an external program and retrieve the output from the program. The biggest advantage of the GUI is that it doesn't take more than a twitchy finger to launch a script which will show you your output in a nice little pop-up box. Unfortunately, this becomes annoying when you have a script which is intended to prompt hundreds of times, such as an event log script. Instead, CScript neatly displays retrieved data in a command window.
The following are some example scripts which should allow you to get a feel how the WSH works. Just copy and paste them into Notepad and feel free to play around a bit with them.
These are just a few of the things that you can do with WSH. If you'd like to find out more, you should check out the following sources:
"Microsoft Windows Server 2003 Administrator's Companion" Microsoft Press, ISBN 0735613672
"Microsoft Windows 2000 Scripting Guide" Microsoft Press, ISBN 0735618674
"The Ultimate Windows Server 2003 System Administrator's Guide" Addison-Wesley Pub Co, ISBN 0201791064
I would also recommend visiting Rob van der Woude's Scripting Pages, found at http://www.robvanderwoude.com/index.html, which contains a number of usable .JScript, VBScript, PerlScript, REXX, and Python scripts for Windows.
Finally, I recommend you check out http://msdn.microsoft.com/scripting for the most up-to-date information on WSH and related programs and features. Of course, remember to check here at http://www.aspfree.com to find some of the best documentation on the web.
Windows Scripting 
/ 18 
Overview Of The New Windows Scripting Host 5.6
