Supplement 4's VBScript Tools

Monitor system state and machine characteristics

As I wrote in "Windows NT Resource Kit Supplement 4," May 2000, Microsoft Windows NT Server 4.0 Resource Kit Supplement 4 includes a wealth of new administrative tools written not in the traditional way (i.e., as C code resulting in opaque .exe files) but in VBScript. Because VBScript is an interpreted language, the programs are visible for your inspection with Notepad. (Hmm, could this fact mean that Microsoft is embracing the open-source movement? Nah, that thought is too frightening.) These scripts exhibit a commendable level of consistency, and Supplement 4 provides a lot of them—I counted 62 in my copy of Supplement 4. Let's look at what some of these scripts can do. (For another opinion about some of these tools, see Michael Otey, Top 10, page 131.)

One group of tools—ps.vbs, pstop.vbs, eventlogmon.vbs, and logmeminfo.vbs—monitors the system's state. You can run these tools on the local system, or you can use the /s option (case is irrelevant) to run them on a remote system. As Task Manager does, ps.vbs lists the processes that are running on the system, but it provides an extra benefit: Ps.vbs also shows you where the programs' executables reside. For example, in addition to telling you that lsass.exe is running and has process ID 136, ps.vbs reveals that the program that is lsass.exe is in C:winntsystem32lsass.exe. Ps.vbs puts all this information into the standard output device Stdout, of course, so you could write another script to do something with that process information. The command

ps /s somemachine

will show you the processes running on a machine named somemachine (note that you don't need to prefix the name with two backslashes).

As ps.vbs does, pstop.vbs lists process names and IDs, but it lists them in decreasing order of the amount of CPU time that each process has used. (Even better, pstop.vbs doesn't bother to report that "idle" has taken up the lion's share of the time.) Pstop.vbs can also use a /s option to report on a remote machine. If the remote machine doesn't recognize your user account and you have an account that the machine does recognize, you can offer that account's name and password with the /u and /w options, respectively. For example, the command

pstop /s bigpc /u ignatz /w swordfish

uses an account named ignatz and the password swordfish to interrogate a machine named Bigpc.

Eventlogmon.vbs is a neat script that lets you watch items appear in the event log as applications add the items. After you run eventlogmon.vbs in a command window, the utility continues to run until you press Ctrl+C. Eventlogmon.vbs lets you do tasks such as keep an eye on the Security log of a computer that you suspect an intruder is trying to access. Because eventlogmon.vbs runs on remote systems as well as the local computer, monitoring for an intruder is simple.

The last tool in this group, logmeminfo.vbs, is also the simplest. Logmeminfo.vbs displays the current status of memory—physical, virtual, pagefile, and available memory.

Another group of Supplement 4 scripts lets you inventory characteristics of machines around the network. All these tools are similar and give you information about the hardware that each tool's name suggests: keyboard.vbs, listdisplayconfig.vbs, listprinters.vbs, motherboard.vbs, parallelport.vbs, pointdev.vbs, processor.vbs, scsicontroller.vbs, serialport.vbs, sounddevice.vbs, and tapedrive.vbs (I'm sure I've missed one or two).

The real value of these scripts probably doesn't lie in what they can do right now. Supplement 4 includes the source code for the scripts, so they provide actual working examples of the power of VBScript. Do you need to do inventories around your network? Imagine the cool script you could build by cutting and pasting pieces of the inventory scripts. You could build a custom script that collects from the network detailed hardware information about your company's computers and peripherals, then dumps that data into a database. With a bit of extra and snazzier coding, the script could feed the data to a Microsoft Access database—sort of a poor person's Microsoft Systems Management Server (SMS).

These scripts are just the start. I'll cover some other exceedingly powerful scripts in upcoming columns. But don't wait for me. Try them out yourself!