Windows Script Host (WSH), a feature of the Microsoft® Windows® 2000 family of operating systems, is a powerful multi-language scripting environment ideal for automating system administration tasks. Scripts running in the WSH environment can leverage the power of WSH objects and other COM-based technologies that support Automation, such as Windows Management Instrumentation (WMI) and Active Directory Service Interfaces (ADSI), to manage the Windows subsystems that are central to many system administration tasks.
What is WSH?
As the name implies, WSH is a script host. A script host is a program that provides an environment in which users can execute scripts in a variety of languages, languages that use a variety of object models to perform tasks.
What are all the Capabilities of WSH
WSH capabilities can be divided into four major areas;
|•||The ability to intrinsically carry out system administration tasks|
|•||The ability to use COM objects to carry out system administration tasks|
|•||The ability to add standard programming features to WSH-compatible scripting languages|
|•||The ability to run command-line tools|
Describe the WSH Architecture
WSH has a modular architecture: It is made up of separate parts, each responsible for performing a specific function. This modularity gives WSH two important capabilities: it can make use of multiple scripting languages and it can leverage COM objects.
Figure illustrates the major components of the WSH environment and their interactions. The WSH environment includes script files, script hosts, scripting language engines, and COM objects.
Major components of WSH architecture
( Components of the WSH Environment)
What is Script Files
You create WSH script files to automate system administration tasks. Script files (more commonly referred to simply as scripts) are plain-text files that contain instructions describing how to accomplish a task or set of tasks. (Plain-text means that the files cannot include any special formatting characters.)
Script File Name Extensions
|File Extension||Sample File Name||Scripting Language|
|•||It is possible to run scripts even if you use a nonstandard file name extension (such as .xyz).|
What is Script Hosts
The script host initiates and coordinates the running of your script; it reads your script file and interacts with components of the WSH environment and any COM objects required by the script. It is also the responsibility of the script host to determine which language engine to use when running the script. For example, if the script has a .vbs extension, the script host will load the VBScript language engine and begin working with that engine to execute the code.
The WSH environment includes two script hosts: the console-based CScript and the GUI-based WScript. The two script hosts provide nearly identical capabilities, and in most cases, it does not matter which of the script hosts you use to run your scripts.
The two exceptions lie in how you interact with a script; that is, how you get information into a script (input) and how the script displays information it has retrieved (output). In general, CScript receives input from the command prompt and displays output in a command window. WScript, by contrast, receives input through a graphical dialog box and displays output in a graphical message box.
What is Scripting Language Engines
Although the script host is responsible for initiating and coordinating the running of a script, it is not capable of interpreting any scripting language. The WSH environment separates the logic necessary to interpret a given scripting language from the script host.
It is this separation that enables WSH to be a multi-language scripting environment. This is because WSH does not attempt to “speak” VBScript, JScript, ActivePerl, Rexx, Python, or any other scripting language. Instead, it is up to the language engine to translate a script into commands that WSH can understand. You can write a WSH script in VBScript because the VBScript language engine can translate the code in your scripts into commands that WSH can understand and act upon. You cannot write a WSH script in C++ because there is no language engine that can translate C++ code into WSH commands.
When a scripting language engine is installed, at least one mapping is recorded in the registry. The mapping associates a file name extension with the dynamic link library (DLL) that implements the scripting language engine. The script host usually determines the language used in a script by examining the file name extension and then checking the registry to determine the corresponding scripting language engine.
|•||You can force the script host to use the scripting language engine of your choice by specifying the //E: command-line option.This option allows you to use any file name extension on your script files, regardless of the scripting language in which they are written.|
What are the COM Objects in WSH
WSH includes the WScript object and three COM-based objects: WshShell, WshNetwork, and WshController. Although they are included with the WSH environment, you use them in your scripts in the same way you use other COM objects.
The WSH COM objects possess neither the depth nor the breadth of the system administration capabilities found in WMI or ADSI. Nevertheless, you are likely to find these objects useful in several situations:
|•||If you need to carry out a task that cannot be carried out using another Automation object. For example, the WshNetwork object allows you to map network drives; this capability is not available in either WMI or ADSI.|
|•||If you have down-level clients that are not running WMI or ADSI. For example, ADSI might be the preferred method to retrieve the name of the local computer, but ADSI did not ship with Windows 98. For Windows 98 computers, you can use the WshNetwork object to retrieve the name of the local computer.|
|•||If you need to run a script on a remote computer, and neither WMI nor ADSI is capable of carrying out this task remotely. In that case, you can use the WshController object to run the script on the remote computer.|
How the Components of the WSH Environment Work Together
Components in the WSH environment must interact with one another to run scripts. These interactions include the following:
Script Host and Script File When a script host is invoked to run a script, it begins by examining the file-name extension of the script file. The script host searches the registry to determine the scripting language engine that corresponds to the extension and then loads the script file in preparation for interpreting its instructions. All this happens before a single line of code is actually executed.
Script Host and Scripting Language Engine After determining the language used in the script, the script host works with the corresponding scripting language engine to interpret the instructions in the script. The script host communicates with the scripting language engine through the Windows Script Interfaces. The entire script is read and checked for syntax errors before any code is executed
The WSH environment includes the built-in WScript object and three COM objects: WshShell, WshNetwork, and WshController. Your scripts can use these objects to help automate system administration tasks.
The WSH objects provide your scripts with functionality that might not be available elsewhere, including the ability to work with command-line arguments, control script execution, and run scripts on remote computers. This means that the scripting language does not have to supply these elements. VBScript, for example, does not include any methods for working with command-line arguments. However, you can still use command-line arguments with VBScript by using the argument capabilities built into WSH.
WSH and the WSH objects do not include all the things system administrators might want to do; far from it. In addition, even tasks that are covered by the WSH objects are often better handled by using technologies such as WMI and ADSI.
WSH Objects and Associated Tasks
The following table is a list of the WSH objects and the typical tasks associated with them.
What you can do with this object
|Wscript|| Set and retrieve command line arguments
Determine the name of the script file
Determine the host file name (wscript.exe or cscript.exe)
Determine the host version information
Create, connect to, and disconnect from COM objects
Stop a script’s execution programmatically
Output information to the default output device (for example, a dialog box or the command line)
|WshArguments||Access the entire set of command-line arguments|
|WshNamed||Access the set of named command-line arguments|
|WshUnnamed||Access the set of unnamed command-line arguments|
|WshNetwork|| Connect to and disconnect from network shares and network printers Map and unmap network shares Access information about the currently logged-on user|
|WshController||Create a remote script process using the Controller method CreateScript()|
|WshRemote|| Remotely administer computer systems on a computer network
Programmatically manipulate other programs/scripts
|WshRemote Error||Access the error information available when a remote script (a WshRemote object) terminates as a result of a script error|
|WshShell|| Run a program locally Manipulate the contents of the registry Create a shortcut
Access a system folder
Manipulate environment variables (such as WINDIR, PATH, or PROMPT)
|WshShortcut||Programmatically create a shortcut|
|WshSpecialfolders||Access any of the Windows Special Folders|
|WshURLShortcut||Programmatically create a shortcut to an Internet resource|
|WshEnvironment||Access any of the environment variables (such as WINDIR, PATH, or PROMPT)|
|WshScriptExec||Determine status and error information about a script run with Exec()Access the StdIn, StdOut, and StdErr channels|
The WScript object is the root object of the Windows Script Host object model hierarchy. It never needs to be instantiated before invoking its properties and methods, and it is always available from any script file. The WScript object provides access to information such as:
Set objWshShell = WScript.CreateObject(“WScript.Shell
The WshArguments object is a collection returned by the WScript object’s Arguments property (WScript.Arguments). Two of the WshArguments object’s properties are filtered collections of arguments — one contains the named arguments (querying this property returns a WshNamed object), the other contains the unnamed arguments (querying this property returns a WshUnnamed object). There are three ways to access sets of command-line arguments.
You can access the entire set of arguments (those with and without names) with the WshArguments object.
You can access the arguments that have names with the WshNamed object.
You can access the arguments that have no names with the WshUnnamed object.
Set objArgs = WScript.Arguments
For I = 0 to objArgs.Count – 1
WshController object is used for creating a remote script process. This object has a single method that accesses the script to run remotely and returns a WshRemote object that provides control over the script process.
RemoteScript Set Controller = WScript.CreateObject(“WSHController“)
Set RemoteScript = Controller.CreateScript(“remote1.js”)
Do While RemoteScript.Status <> 2
You create a WshNetwork object when you want to connect to network shares and network printers, disconnect from network shares and network printers, map or remove network shares, or access information about a user on the network.
Set WshNetwork = WScript.CreateObject(“WScript.Network“)
WScript.Echo “Domain = ” & WshNetwork.UserDomain
WScript.Echo “Computer Name = ” & WshNetwork.ComputerName WScript.Echo “User Name = ” & WshNetwork.UserName </script>
You create a WshShell object whenever you want to run a program locally, manipulate the contents of the registry, create a shortcut, or access a system folder. The WshShell object provides the Environment collection. This collection allows you to handle environmental variables (such as WINDIR, PATH, or PROMPT).
set WshShell = WScript.CreateObject(“WScript.Shell“)
strDesktop = WshShell.SpecialFolders(“Desktop”)
set oShellLink = WshShell.CreateShortcut(strDesktop & “\Shortcut Script.lnk”) oShellLink.TargetPath = WScript.ScriptFullName
oShellLink.WindowStyle = 1
oShellLink.Hotkey = “CTRL+SHIFT+F”
oShellLink.IconLocation = “notepad.exe, 0”
oShellLink.Description = “Shortcut Script” oShellLink.WorkingDirectory = strDesktop oShellLink.Save
What are all the Advantages of Windows Script Host
Using WSH in scripting provides the following advantages
- The primary purpose is to provide the functionality to carry out the administrative tasks
- Access to network resources like drives and printers
- Create, modify the registry keys and values
- Modify environment variables
- Create shortcuts on local system or local network
- Performs repetitive operations
- Run command line tools
- WSHController object provides the ability to run the scripts on remote computers. This object is also used to create a folder on the remote machine.
- Controlling script execution and handling events
- Displaying messages to script users
I hope this has given you a taste of what’s possible with the features provided by Windows Script Host. WSH is really excited topic by the new features of it and it will help the packagers to write scripts easier in custom actions.
There are some additional things we need to take care while we use wscript objects in MSI custom actions,Like we can’t use Wscript.sleep object in customactions.
Don’t worry I will be back with more tips regarding this soon!!!
Reference : MSDN