Windows Scripting Host in Action

A hands-on guide to using WSH

Windows Scripting Host (WSH) is a new Microsoft technology that is sure to become extremely popular because of its versatility. WSH lets Windows NT host any Microsoft ActiveX scripting language, including Visual Basic Script (VBScript) and JScript (Microsoft's implementation of the ECMAScript scripting language, formerly known as JavaScript). WSH also lets NT host third-party ActiveX scripting languages, such as ActiveState Tool's PerlScript (http://www.activestate.com).

WSH is a general-purpose, scripting-enabling tool. With the base WSH object model and a scripting language, you can create scripts that automate common setup, configuration, and administrative tasks, including:

The base WSH object model consists of five types of objects: WScript, WshShell, WshNetwork, WshShortcut, and WshUrlShortcut. As Table 1, page 124, shows, each object type has certain properties and methods that define it. (If you are unfamiliar with the component object model—COM—concept and ActiveX objects, see http://www.microsoft.com/activex.)

Two of the WScript object's methods—GetObject and CreateObject—work with any ActiveX object servers (including NT 5.0's ActiveX Directory Objects) registered on the local system. Thus, you can use WSH to access other object servers, such as Active Directory Services Interface (ADSI), Internet Explorer (IE), and Microsoft Office. With WSH and these object servers, you can set passwords, add users and organization units, initialize a browser, and manipulate and print documents.

Microsoft will integrate WSH into Windows 95 updates, NT 5.0, and the NT Option Pack. You can download WSH from Microsoft's Web site (http://www.microsoft.com/management/wsh.htm) for use with Win95 and NT 4.0.

The WSH package is surprisingly small, consisting of two separate scripting hosts, three support DLLs, six sample scripts, and a Help file. The two scripting hosts—command shell (cscript.exe) and Windows shell (wscript.exe)—let you run scripts from a command line and from the Windows environment, respectively. The command-shell host is particularly useful when you combine it with traditional command-line options, such as piping the output to a text file or other device. The Windows-shell host uses message boxes to display output information (unless you use an additional ActiveX component to handle the file I/O). The following simple examples show how you can use these two scripting hosts.

Reading and Writing Variables
You can use WSH with ADSI 1.0 (version 2.0 is in beta), Microsoft's new programmability layer on top of NT 5.0's Active Directory (AD) services, for reading and writing AD variables. (For more information about ADSI, see Sakari Kouti, "Manage Directory Resources with Active Directory Service Interfaces," November 1997. You can download ADSI 1.0 from Microsoft's Web site at http://www.microsoft.com/win32dev/netwrk/adsi.htm.)

With ADSI installed, your system has a COM-based object interface to four network providers: Lightweight Directory Access Protocol (LDAP) 2.0, NetWare 4, NetWare 3, and Windows NT. These network providers give you access to underlying objects. To obtain access, you need to use the appropriate reference, as Table 2 shows.

To use the NetWare objects, however, ADSI currently requires that you install Microsoft's Gateway Services for NetWare for NT Server or Client Services for NetWare for NT Workstation on the local machine. If you don't have these services installed and attempt to access NetWare objects using ADSI, an error dialog box will appear saying that Windows is unable to locate nwprovau.dll.

Microsoft plans to extend ADSI to cover non-network interfaces. For example, if you have Internet Information Server (IIS) 4.0, you can use ADSI to access the IIS: namespace. Exchange 5.5 also has an ADSI interface.

To learn about your directory services, you can use WSH to list the installed ADSI namespaces by running the VBScript program in Listing 1. You can use a standard text editor, such as Notepad, to enter this script. Although you can use Microsoft's Visual InterDev to write script code, you're better off using Notepad because it requires much less overhead.

Listing 1 includes Dim statements. However, you need not include these statements in your script because VBScript will automatically create them. I included the Dim statements in Listing 1 because manually declaring variables is a good programming practice that resolves any potential problems with names at parse time instead of run time.

Here is what the script in Listing 1 does. First, the GetObject method creates a reference to the ADSI object and assigns it to the adsNS variable. Like many objects in ADSI, this object is a collection of objects (in this case, namespaces), so the script includes a For Each...Next loop that cycles through every object in the collection and concatenates each object's name onto a string. Finally, the Echo method displays the resulting string.

If you save this script as a text file (enumadsi.vbs) and run it from Windows, the script will go to the Windows-based WSH host. You will then receive the message box in Screen 1, page 126, that lists the ADSI namespaces in your directory services.

If you run the same script from the command-shell host (cscript enumadsi.vbs), you will get the same message box. However, if you enter

cscript enumadsi.vbs > names.txt

instead, you will receive a small text file with the ADSI namespace names.

Although WScript's Echo method is flexible, you might want to use WshShell's Popup method for additional capabilities. With the Popup method, you can customize the title of the dialog box and specify a delay after which the dialog box disappears automatically. You can even specify constants to create dialog boxes that look like familiar Windows message-box styles, complete with familiar icons and buttons. For example, Listing 2, page 125, shows how to use the Popup method to create a dialog box that looks like Screen 2, complete with an Information icon and multiple buttons (including a custom default).

Once you know the ADSI namespaces in your directory service, you can use WSH to identify domain objects and their classes in those namespaces. In ADSI, objects represent every element in a domain. Thus, for example, objects represent the various servers, printers, and users. A domain's objects fall into certain classes that represent the different types of elements in a directory service. For example, the objects that represent Joe, Sue, Paul, and Mary fall into the user class. Identifying objects and their classes not only helps you learn about your directory service, but also is a good introductory exercise in using WSH with ADSI.

Suppose you want to identify the objects and their classes in the domain on the WinNT: namespace. You can again use the CreateObject, GetObject, and Popup methods, as the VBScript program in Listing 3 shows. This script is searching the KRP domain; when you use this script, you need to substitute your domain's name for KRP.

Running the script in Listing 3 on a Windows-shell host will generate a dialog box with all the objects and their classes, as Screen 3 shows. The column on the left contains the classes for the objects listed in the right column.

You can make this information more presentable by modifying the code in Listing 3 so that it opens a text file, writes the same information about the domain's objects and classes, and closes the file. Listing 4 contains the modified code. You can even modify this script so that it opens Excel and plugs the information into individual cells. Listing 5, page 128, contains the Excel version of the code, and Screen 4 shows the output. Unlike the text file script, this Excel script leaves the application running on your desktop, but you can easily adapt it to close the file. You can also adapt the script to perform other tasks, such as printing, mailing, and exporting the Excel file.

Another approach to making information more presentable is the FileSystemObject method. This method, which comes with IIS's Active Server Pages (ASP), writes information to a text file.

Creating Shortcuts for Users
You can use WSH for tasks more sophisticated than reading and writing AD variables. For example, you can add shortcuts for users on their desktop so that they have easy access to the applications they regularly use.

WSH lets you access a collection of special folders on each user's system. These folders have names such as Desktop, Favorites, Fonts, My Documents, NetHood, PrintHood, Programs, Recent, SendTo, Start Menu, Startup, and Templates. Under NT, you can also access several special folders, including All UsersDesktop, All UsersStartMenu, All UsersPrograms, and All UsersStartup.

WSH works with two types of shortcuts: file, in which you use the WshShortcut object, and URL, in which you use the WshUrlShortcut object. Each object has one or more properties that define it (as you see in Table 1).

To put a file shortcut on a user's Desktop (or in any special folder), you must initialize the WSH object, specify the folder's path, create a shortcut object, set several properties, and save the shortcut. Listing 6, page 128, contains the VBScript for creating this file shortcut.

Creating a URL shortcut on a user's Desktop is even easier than creating a file shortcut. Although the process is similar, you have fewer properties to specify. Listing 7, page 128, contains the VBScript for creating the URL shortcut.

Debugging Scripts
When writing scripts for WSH, you can use Microsoft's Script Debugger 1.0, which comes with IE 4.0 and IIS 4.0. You can download the Script Debugger from http://www.microsoft.com/scripting/debugger/default.htm. Screen 5, page 127, shows both the Script Debugger checking a block of code running in the Windows-shell host and the Command window for interactively entering commands and testing values. Unfortunately, each WSH script launches a separate instance of wscript.exe or cscript.exe, so you must pause each WSH script to check it in the Script Debugger. To pause a script, either use the Stop statement or employ the WshShell Popup method as follows:

Set WshShell = WScript.CreateObject("WScript.Shell")WshShell.Popup "Start Debugging"

This method lets you switch to the Script Debugger, select the correct document, and set the Break at Next Statement option. Microsoft will improve the handling of WSH scripts in Script Debugger 1.1, which will ship with NT 5.0 and be available on Microsoft's Web site in early 1998.

Short Scripts Long on Results
WSH is an extremely useful extension to Microsoft's 32-bit Windows operating systems. It lets you harness the power of full-featured scripting languages so that you can access ActiveX objects. As the examples show, you can use short scripts to automate common setup, configuration, and administrative tasks.

Corrections to this Article: