Windows Scripting

For many years, network administrators and "power users" used MS-DOS batch files (.bat) to automate certain tasks. When Windows came along, the need to automate some tasks still existed, but Microsoft didn't include any scripting capability in Windows itself.

Not until the development of Automation, which allowed scripting languages to access COM objects, was real scripting possible in the Windows environment. Automation allows scripting languages to create instances of COM objects and access the properties and methods of those objects at runtime.

Basically, the first script hosts were Microsoft applications, Word and Excel, among others. These applications also included Microsoft Visual Basic for Applications (VBA), a slightly trimmed down version of the popular language that ships as part of the Visual Basic programming environment.

As the Internet became more popular, Microsoft included support for VBScript, an even more trimmed down version of Visual Basic than VBA, and JScript, Microsoft's implementation of JavaScript, in Microsoft Internet Explorer and Microsoft Internet Information Server (IIS).

A proliferation of languages, including VBA, VBScript, JScript, large applications such as Word, client Web browsers, and Web servers, all can make use of COM objects that support Automation.

Windows Script Host

The missing piece is an execution environment independent of an application, which is where Windows Script Host comes in. In 1998, Microsoft made Windows Script Host 1.0 available for download and included it in the Windows NT 4.0 Option Pack and Windows 98. Windows Script Host doesn't actually execute the scripts themselves; it provides a means for a script engine to execute a particular script.

The script engine is specific to a programming language. The Windows Script components include engines for VBScript and JScript. Other languages, such as Perl and Python, also have engines available. The ability to code in the language of your choice and have your program execute across the Windows platform is extremely powerful. Each script engine provides the features native to the languages, such as VBScript's For Each statement or JScript's C/C++ style comments (/* */ and //). Many Perl scripts written as CGI Web server scripts can now be easily ported and run independently of a Web server.

Windows Script Files

Version 1.0 of Windows Script Host loads a particular script engine based on the filename extension of the file containing the script code. For example, a file named Simple.vbs would instruct Windows Script Host to load the VBScript engine, whereas Simple.js would indicate that the JScript engine is required. Starting with Windows Script Host 2.0, available in Windows 2000, Windows Script Host adds support for a new file type, a Windows Script file (.wsf), that uses XML tags to define various sections. A major benefit of a Windows Script file is that it can contain multiple scripts, in any supported language. A practical example of this capability would be a system administrator's toolkit. These tools are likely to be written in various languages. With a Windows Script file, these tools can be collected and bundled into a single .wsf file. The scripts contained in a .wsf file can also invoke procedures contained in the same or in another .wsf file.

The other major benefit of Windows Script Host 2.0 is its ability to create Windows Script Components. A Windows Script Component is a COM object created by a program written in one of the Windows Script languages. Let's say you've developed a nifty script that gathers the names of all the users logged onto the network. Now, instead of cutting and pasting that code into each script in which you need to perform that task, you can publish it as a Windows Script Component and any script, or any application that uses COM, can take advantage of your code! That is true code reuse, enabled by Windows Script.

A Windows Script file is structured differently from a .vbs or .js file. A Windows Script file is actually an XML file. This format allows for a lot of flexibility in the creation of scripts, such as including multiple scripts in a single file and handling events. The XML elements I'll use are job, script, and reference. The job element tells Windows Script Host to treat its content as one task. Multiple jobs can be included in a single file and referenced using a command-line argument. The script element specifies which language the script is written in. This is used by Windows Script Host to load the correct scripting engine. The reference element specifies a type library, which I'll discuss in more detail later in this chapter.

The naming and versioning of Windows Script can be a little hairy. Microsoft uses the term Windows Script, which is a collection of the various Windows scripting components. At the time of this writing, the current version of Windows Script is 5.5, and includes Windows Script Host and Windows Script Components 2.0, VBScript 5.5, JScript 5.5, and the Windows Script Run-Time 5.1. The next version of Windows will ship with Windows Script 5.6, which has a wealth of new features including improved argument handling, comment blocks, remote scripting, and object model improvements. Windows Script 5.6 also includes support for documenting and digitally signing scripts.

Windows Script Object Model

Windows Script provides an object model that can be used by any script engine. The WScript object provides access to information about the execution environment, whereas the WshArguments object contains information and methods to retrieve command-line arguments—a requirement of scripting. Other objects in the model include WshShell, an interface to the user interface shell of Windows, and WshNetwork, which allows scripts to use file and print resources on a network. The model also includes objects that represent drives, folders, and files. Any script running under Window Script Host can use these objects. Table 10-1 lists the Windows Script Host objects along with objects supplied by the Windows Script runtime engine.

Object	Description	Supplied By
WScript	Data and methods that represent the current execution environment	Windows Script Host
WshArguments	Collection of command-line arguments	Windows Script Host
WshEnviroment	Collection of named system environment variables	Windows Script Host
WshNetwork	Properties and methods to work with networking	Windows Script Host
WshShell	Methods to control processes and the registry and to create new shortcuts	Windows Script Host
WshShortcut	Represents a shortcut file	Windows Script Host
WshSpecialFolder	Collection of special Windows folders such as Desktop, Control Panel, and Start Menu	Windows Script Host
WshUrlShortcut	Represents a shortcut to a URL	Windows Script Host
Dictionary	Simple database array	Windows Script runtime
Drive	Properties related to logical disk drives	Windows Script runtime
Drives collection	Collection of Drive objects available	Windows Script runtime
Encoder	Mechanism to encode script files so that they can't be easily read	Windows Script runtime
File	Properties of a file and methods to copy, move, or delete	Windows Script runtime
Files collection	Collection of File objects within a folder	Windows Script runtime
FileSystemObject	Properties and methods related to the file system	Windows Script runtime
Folder	Properties of a single folder within the file system	Windows Script runtime
Folders collection	Collection of Folder objects within a Folder	Windows Script runtime
TextStream	Provides read/write access to a text file	Windows Script runtime

Table 10-1 Windows Script objects.

Type Libraries

A type library is a definition of one or more COM objects that includes information about the objects' interfaces such as properties, methods, parameters, and data types. A type library allows compilers like Microsoft Visual C++ and Visual Basic to perform type checking, for example, verifying that the data type being passed to a method is correct. It also improves performance because the compiler can create code that directly invokes a method, rather than perform a series of steps at runtime. This is called early binding and is discussed in Chapter 3.

Type libraries also contain the definitions for constants, enumerations, and structures. A constant is simply a named value. For example the ADS_USE_SSL constant has a value of 2. By using constants, it's easier to write and understand the source code. Enumerations are a group of related constants. The ADS_USE_SSL constant is part of the ADS_AUTHENTICATION_ENUM enumeration that defines the various authentication options available with the ADsOpenObject function and IADsOpenDSObject interface.

Until recently, Windows Script developers could not utilize type libraries. The original version of Windows Script Host did not support type libraries, and constants had to be explicitly defined, which hampered the porting of source code from Visual Basic to VBScript. However, Windows Script Host 2.0 can be instructed to load a type library so that constants defined in that type library can be accessed. Listing 10-1 shows a script available on the companion CD that uses the ADSI type library, named the Active DS Type Library (ActiveDS.tlb), in conjunction with the handy ADSI Pathname object.

Unlike in Visual Basic, referencing a type library in a script does not mean you can declare variables of a specific data type. Also, objects in a script that reference a type library are still late bound. However, referencing a type library does allow a script to use the constants defined in the type library.

 <job > 
<reference gu/>
<script language="VBScript">
` Bind to the local global catalog server
Set adsRootDSE = GetObject( "LDAP://RootDSE" )
 ` Create ADsPath to the default directory partition
strADsPath = "LDAP://" & adsRootDSE.Get( "defaultNamingContext" )  ` Create an ADSI Pathname object
Set adsPathname = CreateObject("Pathname")
 ` Provide the Pathname object with our ADsPath
adsPathname.Set strADsPath, ADS_SETTYPE_FULL
 ` Retrieve various formats of the ADsPath 
strWindows  = adsPathname.Retrieve(ADS_FORMAT_WINDOWS)
strX500     = adsPathname.Retrieve(ADS_FORMAT_X500)
strProvider = adsPathname.Retrieve(ADS_FORMAT_PROVIDER)
 ` Prepare strings and display
strADsPath  = "Original ADsPath:" & vbTab & strADsPath  & vbNewLine
strWindows  = "Windows format:"   & vbTab & strWindows  & vbNewLine
strX500     = "X.500 format:"     & vbTab & strX500     & vbNewLine
strProvider = "Provider only:"    & vbTab & strProvider & vbNewLine
WScript.Echo strADsPath & strWindows & strX500 & strProvider
</script>
</job> 

Listing 10-1 UseTypeLib.wsf shows how to reference the ADSI type library and how to use constants defined in that type library.

Figure 10-1 shows an example of the output when you run the UseTypeLib script.

Figure 10-1 Output of UseTypeLib.wsf script, using the Pathname object and constants defined in the ADSI type library.

The reference element is used to tell Windows Script Host to load the ADSI type library. The string "{97D25DB0-0363-11CF-ABC4-02608C9E7553}" is the GUID of the type library. Windows Script Host uses this number to look up the actual type library file, ActiveDS.tlb, in the computer's registry, normally installed in the %SystemRoot%\System32 folder.

The UseTypeLib sample uses several constants defined in the Active DS Type Library file. For maximum effect, I chose the ADSI Pathname object, because it uses many of the ADS_XXX constants. The Pathname object helps to work with paths in ADSI. Once a path for the Pathname object is specified via the Set method, different formats for the path can be retrieved using the Retrieve method. The Windows format is sometimes known as OSF-style or the canonical format and is commonly used by the Exchange 5.5 directory. The X.500 format uses the familiar distinguished name (DN) style you've seen throughout this book. A sample, named Pathname.wsf, that demonstrates some of the capabilities of the Pathname object is available on the companion CD.

The reference element can also identify a type library by using a program identifier (ProgID) stored in the registry. Some COM components, such as ActiveX Data Objects (ADO), incorporate a type library within the component. Unfortunately, with ADSI, you must reference a GUID to identify the Active DS Type Library.

---

Type Libraries: More Than You Want To Know

Type libraries are created by the developer of the COM component using the Object Definition Language (ODL). A special compiler, MIDL, is used to create the type library file (.tlb). This file can then be distributed with the component or embedded in the binary code as a resource. Visual Basic developers use the References command to instruct the compiler to load and use a type library. Visual C++ (5.0 and later) developers can instruct the compiler to reference a type library by using the #import directive.

---

Creating and Editing Scripts

Although creating simple scripts is easy, scripting does have its drawbacks. Currently the development environments available from Microsoft for creating scripts are limited. Programmers accustomed to working with the rich editors and debuggers in Visual C++ 6.0 and Visual Basic 6.0 are stuck using Notepad to create many scripts. Even the script editor in Microsoft Visual InterDev 6.0 only recognizes scripts designed for its specific environment. While Visual InterDev 6.0 can be tweaked to provide syntax coloring and IntelliSense statement completion, you cannot use the built-in debugger easily. Many script developers use Notepad and the Microsoft Script Debugger to create small scripting applications.

The upcoming release of Microsoft's development environment, Visual Studio.NET, brings welcome relief to script developers. You can create a Windows Script file using the new XML editing environment and take advantage of Visual Studio's IntelliSense feature to provide statement completion and use drop-down lists of properties and methods. Debugging Windows Script files, a bane to many, is also integrated into Visual Studio.NET.

For more information on scripting in Windows, you can refer to an excellent book, Microsoft Windows Script Host 2.0 Developer's Guide by Günter Born (Microsoft Press, 2000).

Let's turn our attention now to using Windows Script to actually manage network resources in Active Directory.