Welcome to WSH scripting, part two. In part one, we defined some basic scripting concepts, such as the definition of an object, and examined the wScript and wshShell objects and some of the features that each object makes available. In part two, we’ll revisit the wshShell object briefly and then move on to the remaining built-in objects.
The pop-up method of the wshShell object allows a script to communicate interactively with a user via pop-up dialogs. Its implementation is similar to the VB and VBA Msgbox function (which is available if you are programming VBScript) with one new wrinkle: the time-out parameter. This feature allows a script to wait for a user’s input for a specified number of seconds before continuing execution, whether the user has dismissed the dialog or not. Scripts can be interactive while still allowing unattended execution for automating your mission-critical processes.
Since most logon scripts are responsible for drive or printer mapping, no coverage of WSH scripting should exclude the WshNetwork object. WshNetwork allows the manipulation and creation of links to network resources, as well as to important workgroup information. User, domain, and computer names are available, and this object can create new mapped drives and printers as well as change the system default printer.
While not truly a built-in WSH object, belonging instead to the scripting run-time library, the FileSystem object is so useful that I can’t leave it out of this discussion. This object’s rich feature set allows object-oriented access to all drives, files, and folders installed on a system, and it has built-in methods to read from, write to, and create ASCII text files.
Drives and folders are all exposed as collections, and the full set of attributes of each can be read from and written to by scripts. Files can be copied, moved, and opened in several modes. While the extra steps involved may be initially confusing, the elegance and efficiency involved in dealing with files as replaceable, generic objects is incredible. This is the highest-level file system access that I have ever seen for Windows—replacing the entire VB file access system—and I think we’ll all be seeing a lot more of it.
Putting it all together
To utilize WSH scripts for logon scripts, you need only to call Wscript.exe with the name of the script you wish to execute from the user’s normal logon batch file—i.e. Wscript.exe Logon.vbs. From then on, you have the luxury of Windows-aware logon scripts.
However, as with all other things, this silver lining has a cloud. For example, on my test Win98 machine, the AddPrinterConnection method of wshNetwork appears crippled—it can only capture a printer port to an existing printer, not map a printer on the fly—and I was never able to get wshEnvironment to report any information whatsoever, even when using examples from Microsoft.
These troubles aside, the possibilities are great for scripting, and we’ve only just scratched the surface here: It’s possible to have logon scripts open database connections for other apps, run scripts as scheduled events, even create full-blown ActiveX components using nothing but script—and we haven’t even mentioned ASPs. Be sure to check the resources section for more information and then go script!
For more information be sure to check out the WSH Programmer’s Reference , an exhaustive reference to every built-in object the WSH contains, and the Microsoft Scripting Run-Time Library Reference Features .