To run a single script against multiple computers you can include each computer name as a command-line argument. For example, this command runs the script Monitor.vbs against Server1, Server2, and Server3:

Cscript Monitor.vbs Server1 Server2 Server3

This works fine for a script that runs against two or three computers, but it is far less effective for scripts that need to run against scores of computers. For scripts that must run against more than a handful of computers, you will likely find it much more efficient to store the list of computer names in a text file; your script can then open the text file, read in each computer name, and then run against each of these computers. Not only is this efficient, but your text file need be no more complicated than this:

atl-dc-01
atl-dc-02
atl-dc-03
atl-dc-04

You can read arguments into a script by using the FileSystemObject. In the script shown in Listing 17.1, the FileSystemObject is used to read a list of server names from a text file; each name is then stored as a key-item pair with a Dictionary. This demonstration script then successively runs against each name in the Dictionary, connecting to the computer and reporting the number of services installed on that computer.

Note

This might not be the most practical use of an enterprise script; you rarely need to know how many services are installed on a computer. However, the actual activity performed by the script is irrelevant; the important aspect is how the script reads server names from a text file and then connects to each computer. A trivial task such as reporting the number of services installed was chosen simply to keep the focus on connecting to multiple computers and not on the activity carried out after each connection is made.

Scripting Steps

Listing 17.1 contains a script that retrieves arguments from a text file. To carry out this task, the script must perform the following steps:

 1 Const ForReading = 1
 2 Set objDictionary = CreateObject("Scripting.Dictionary")
 3 Set objFSO = CreateObject("Scripting.FileSystemObject")
 4 Set objTextFile = objFSO.OpenTextFile _
 5     ("c:scriptsservers.txt", ForReading)
 6 i = 0
 7 Do Until objTextFile.AtEndOfStream
 8     strNextLine = objTextFile.Readline
 9     objDictionary.Add i, strNextLine
10     i = i + 1
11 Loop
12 For Each objItem in objDictionary
13     StrComputer = objDictionary.Item(objItem)
14     Set objWMIService = GetObject("winmgmts:" _
15     & "{impersonationLevel=impersonate}!\" & strComputer& "
ootcimv2")
16     Set colServices = objWMIService.ExecQuery _
17         ("SELECT * FROM Win32_Service")
18     Wscript.Echo strComputer, colServices.Count
19 Next

cscript monitor.vbs dns_servers.txt

Set objArgs = Wscript.Arguments
Wscript.Echo objArgs(0)

Set objArgs = WScript.Arguments

Set objTextFile = objFSO.OpenTextFile _
    ("c:scriptsservers.txt", ForReading)

Set objTextFile = objFSO.OpenTextFile(objArgs(0), ForReading)

 1 Set objArgs = WScript.Arguments
 2 Const ForReading = 1
 3 Set objDictionary = CreateObject("Scripting.Dictionary")
 4 Set objFSO = CreateObject("Scripting.FileSystemObject")
 5 Set objTextFile = objFSO.OpenTextFile(objArgs(0), ForReading)
 6 i = 0
 7 Do While objTextFile.AtEndOfStream <> True
 8     strNextLine = objTextFile.Readline
 9     objDictionary.Add i, strNextLine
10     i = i + 1
11 Loop
12 For Each objItem in objDictionary
13     StrComputer = objDictionary.Item(objItem)
14     Set objWMIService = GetObject("winmgmts:" _
15     & "{impersonationLevel=impersonate}!\" & strComputer& "
ootcimv2")
16     Set colServices = objWMIService.ExecQuery _
17         ("SELECT * FROM Win32_Service")
18     Wscript.Echo strComputer, colServices.Count
19 Next

Databases are especially useful if you have scripts whose arguments might vary each time the script is run. For example, you might have a script that backs up a separate set of computers each day. Although this information can be stored in a text file, you would need to parse the entire text file each time the script ran, picking out the computers of interest. By contrast, you can construct a database query that will retrieve only the computers scheduled to be backed up on a given day. This approach is more efficient than reading through and parsing a text file.

Table 17.1 shows a simple database listing computer names and the day of the week each computer is scheduled for a full backup.

To create a script that runs against the appropriate computers on the appropriate days, you simply include code that limits data retrieval to a specific day. For example, this SQL query returns only the set of computers designated for backup on Thursday:

"SELECT * FROM Computers WHERE BackupDay = 'Thursday'"

By including additional fields within the table, you can construct an all-purpose database that contains the arguments for many of your scripts. For example, additional fields might indicate the date to back up and clear event logs, the dates and times for performance monitoring, or the list of services to be checked on a routine basis.

Note

Databases are discussed in more detail later in this chapter.

Scripting Steps

Listing 17.3 contains a script that retrieves arguments from a database. (The database and the database table must exist before this script can run.) To carry out this task, the script must perform the following steps:

 1 Const adOpenStatic = 3
 2 Const adLockOptimistic = 3
 3 Const adUseClient = 3
 4 Set objConnection = CreateObject("ADODB.Connection")
 5 Set objRecordset = CreateObject("ADODB.Recordset")
 6 objConnection.Open "DSN=Inventory;"
 7 objRecordset.CursorLocation = adUseClient
 8 objRecordset.Open "SELECT * FROM ServerList" , objConnection, _
 9     adOpenStatic, adLockOptimistic
10 objRecordSet.MoveFirst
11 Do While Not objRecordSet.EOF
12     strComputer = objRecordSet("ComputerName")
13     Set objWMIService = GetObject("winmgmts:" _
14     & "{impersonationLevel=impersonate}!\" & strComputer& "
ootcimv2")
15     Set colServices = objWMIService.ExecQuery _
16         ("SELECT * FROM Win32_Service")
17     Wscript.Echo strComputer, colServices.Count
18     objRecordSet.MoveNext
19 Loop
20 objRecordset.Close
21 objConnection.Close

Large organizations typically have more than one system administrator. In addition, those administrators generally are not responsible for managing the entire network; instead, they most likely have been delegated control over some subset of the network. For example, Administrator A might be responsible for managing users and computers in the Finance department, while Administrator B might be responsible for managing users and computers in the Human Resources department.

To facilitate system administration, Active Directory is often designed to mimic these management areas. Instead of placing all computer accounts in the Computers container, computer accounts might be put in organizational units (OUs) that correspond to these management areas. Thus all the accounts for computers belonging to the Finance department would be placed in the Finance OU, and all the accounts for computers belonging to the Human Resources department would be placed in the Human Resources OU.

Structuring Active Directory in this fashion not only facilitates system administration but also of benefits script writers. For example, suppose you need to write a script that takes a hardware inventory or checks the service pack version for all the computers under your control. If those computer accounts — and only those computer accounts — are stored in the same Active Directory container, you do not have to create a text file or database from which to extract computer names. Instead, you can simply bind to the appropriate Active Directory container and retrieve all the computer names from there.

Binding to Active Directory also ensures that you will have the most up-to-date list of computers, without having to do additional work to maintain a text file or database containing computer names.

To retrieve a list of computer names from Active Directory, use Active Directory Service Interfaces (ADSI) and:

Scripting Steps

Listing 17.4 contains a script that retrieves arguments from an Active Directory container. To carry out this task, the script must perform the following steps:

 1 Set objDictionary = CreateObject("Scripting.Dictionary")
 2 i = 0
 3 Set objOU = GetObject("LDAP://CN=Computers, DC=fabrikam, DC=com")
 4 objOU.Filter = Array("Computer")
  5 For Each objComputer in objOU
 6     objDictionary.Add i, objComputer.CN
 7     i = i + 1
 8 Next
 9 For Each objItem in objDictionary
10    StrComputer = objDictionary.Item(objItem)
11    Set objWMIService = GetObject("winmgmts:" _
12    & "{impersonationLevel=impersonate}!\" & strComputer& "
ootcimv2")
13    Set colServices = objWMIService.ExecQuery _
14        ("SELECT * FROM Win32_Service")
15    Wscript.Echo strComputer, colServices.Count
16 Next

Although the command window offers little in the way of formatting options, it is possible to at least align output in table format. Simply displaying multiple properties one after another, all on the same line, usually results in confusion; who really knows what to make of a command window display such as this:

Alerter Auto Running
Application Management Manual Running
Ati HotKey Poller Auto Stopped
Computer Browser Auto Running
Indexing Service Manual Stopped

However, that same data, displayed in the same command window, is remarkably easy to read and interpret when displayed in tabular format:

Alerter                                    Auto             Running
Application Management                     Manual           Running
Ati HotKey Poller                          Auto             Stopped
Computer Browser                           Auto             Running
Indexing Service                           Manual           Stopped

To display data in tabular format, you need to use fixed-width columns. With fixed-width columns, you determine in advance the number of characters that will be displayed in each column in the table. In the preceding example, the following column widths — based on a command window 80 characters wide — are used:

After you decide on the widths for each column, you must then ensure that each item displayed in the table takes up the requisite number of spaces. This is done by using the following procedure on each item of data:

The net result is that each item of data expands to fill the column width, even if many of the characters in that item are blank spaces. For example, the word dog expands to 10 characters (the underscores represent blank spaces in the string):

A subset of VBScript functions that can be used to format data for display in the command window are shown in Table 17.2. In addition to the functions listed in the table, VBScript also includes functions you can use to display numbers and dates in a specific manner. For more information about these functions (such as FormatNumber, FormatDate, and FormatPercent), see “VBScript Primer” in this book. The discussion of formatting output used in the “VBScript Primer” chapter is similar to the discussion in this chapter.

strTestString = "This is a test."
intCharacters = Len(strTestString)
Wscript.Echo intCharacters

strTestString = "This is a test."
strCharacters = Left(strTestString, 7)
Wscript.Echo strCharacters

strTestString = "This is a test."
strCharacters = Right(strTestString, 7)
Wscript.Echo strCharacters

strTestString = "This is a test."
strCharacters = strTestString & Space(15)
Wscript.Echo strCharacters

Scripting Steps

Listing 17.5 contains a script that displays formatted script output in a command window. To carry out this task, the script must perform the following steps:

 1 strComputer = "."
 2 Set objWMIService = GetObject("winmgmts:" _
 3     & "{impersonationLevel=impersonate}!\" & strComputer& "
ootcimv2")
 4 Set colServices = objWMIService.ExecQuery _
 5     ("SELECT * FROM Win32_Service")
 6 For Each objService in colServices
 7     intPadding = 50 - Len(objService.DisplayName)
 8     intPadding2 = 17 - Len(objService.StartMode)
 9     strDisplayName = objService.DisplayName & Space(intPadding)
10     strStartMode = objService.StartMode & Space(intPadding2)
11     Wscript.Echo strDisplayName & strStartMode & objService.State
12 Next

When the script runs under CScript, it displays formatted output similar to the following:

Alerter                                 Auto                Running

Application Management                  Manual              Running

Ati HotKey Poller                       Auto                Stopped

Computer Browser                        Auto                Running

Indexing Service                        Manual              Stopped

By using the various string manipulation functions found in VBScript, you can display data in tabular format within the command window. This makes the data easier to analyze but only partly compensates for the limitations found in the command window. For example, no VBScript function lets you use multiple fonts and multiple colors within the command window. Likewise, no VBScript method lets you easily print data from within the command window. Instead, you must copy the entire data set (assuming that the data does not exceed the command window display buffer), paste the data into another application, and then print the data.

If you prefer to use formatting that goes beyond a tabular display or if you would like the ability to print the returned data, you might consider outputting information to Internet Explorer rather than the command window. Unlike the command window, Internet Explorer lets you use multiple fonts and multiple colors; you can even include graphics within your output. In addition, you can use the Print function of the browser to print the data, without having to copy and paste it into another application.

In the examples that follow, you do not create a Web page (that is, an .HTM file). Instead, you use VBScript to instantiate an instance of Internet Explorer, and you then use VBScript commands to control that instance of the browser. This is possible because Internet Explorer provides an Automation object model that can be controlled from within a script. You can use this object model to create an instance of Internet Explorer and then do such things as:

In fact, nearly all the functionality of Internet Explorer is exposed through the Automation object model. Some of the properties and methods especially useful to script writers are shown in Table 17.3.

Set objExplorer = _
  CreateObject("InternetExplorer.Application")

Do While (objExplorer.Busy)
    Wscript.Sleep 250
Loop

objExplorer.Left = 200

objExplorer.Top = 100

ObjExplorer.Navigate "about:blank"

ObjExplorer.Navigate "file://c:scripts
service_data.htm"

ObjExplorer.Navigate "http://www.fabrikam.com"

Internet Explorer also exposes several other objects that let you not only control the behavior of the browser but also dynamically control the contents of the browser window. For example, you might create an instance of Internet Explorer and open a blank Web page. You can then use the Document object to dynamically change the contents of that Web page.

This has nothing to do with creating pages for the World Wide Web. In fact, you still create files with the .vbs file name extension; you do not create Web pages with the .htm file name extension. Instead, you use a script to open Internet Explorer and then use a combination of scripting code and HTML tags to redirect the script output to the browser window.

Creating an Instance of Internet Explorer

You can use Internet Explorer as a display device by creating an instance of the browser and then issuing the appropriate commands to:

To create an instance of Internet Explorer, use the CreateObject method and the ProgID InternetExplorer.Application. For example, this line of code creates an instance of Internet Explorer and assigns it to the object variable objExplorer:

Set objExplorer = CreateObject("InternetExplorer.Application")

After the object has been created, you can control it by using the object variable assigned to that instance of Internet Explorer. For example, this command will hide the toolbar:

objExplorer.ToolBar = 0

Any commands you issue will affect only the instance of Internet Explorer you created. If you have multiple copies of the browser running, a command to hide the toolbar will hide only the toolbar in the instance of Internet Explorer under the control of your script. The toolbar will remain visible in any other instances of Internet Explorer that are running.

Scripting Steps

Listing 17.6 contains a script that creates an instance of Internet Explorer. To carry out this task, the script must perform the following steps:

1 Set objExplorer = CreateObject("InternetExplorer.Application")
2 objExplorer.Navigate "about:blank"
3 objExplorer.ToolBar = 0
4 objExplorer.StatusBar = 0
5 objExplorer.Width = 300
6 objExplorer.Height = 150
7 objExplorer.Left = 0
8 objExplorer.Top = 0
9 objExplorer.Visible = 1

When the script in Listing 17.6 is run, you will see a blank Web page similar to that shown in Figure 17.1.

Figure 17.1. A Blank Web Page in Internet Explorer

Displaying Data in a Web Page

Web pages provide an alternative to displaying script output in the command window. Unlike the command window, Web pages support a wide array of formatting options, including color, fonts, and graphics. This lets you display script output in a manner that is much easier to decipher at a glance than output displayed in the command window. For example, you might use red to format the status of any services that are stopped. That way, an administrator can verify that all services are up and running without having to stop and read through the entire display. Figure 17.2 shows a simple example of how you might display service status information.

Figure 17.2. Data Displayed in a Web Page

Perhaps the easiest way to display real-time data is to use the WriteLn method. With this method, you can use a script to open a blank Web page and then send HTML code to the page. Each time you send information to the Web page by using WriteLn, that information is appended to the end of the page. For example, this code writes the numbers 1 through 5 to a Web page, without any formatting of any kind:

objDocument.Writeln "1"
objDocument.Writeln "2"
objDocument.Writeln "3"
objDocument.Writeln "4"
objDocument.Writeln "5"

The resulting Web page will look like this:

12345

To place each number on a separate line, include the HTML tag <BR> as part of the WriteLn parameter:

objDocument.Writeln "1<BR>"
objDocument.Writeln "2<BR>"
objDocument.Writeln "3<BR>"
objDocument.Writeln "4<BR>"
objDocument.Writeln "5<BR>"

The revised Web page will look like this:

1

2

3

4

5

You can include any HTML tags as part of the WriteLn parameter; in that regard, dynamically creating a Web page is no different than using a text editor to write an .htm file. For example, to write text formatted with the <H2> heading level, use code similar to this:

objDocument.Writeln "<H2>This is an H2 heading</H2>"

Scripting Steps

Listing 17.7 contains a script that displays data in a Web page. To carry out this task, the script must perform the following steps:

1. Create an instance of Internet Explorer.

2. Open a blank Web page by navigating to “about:blank”.

3. Configure various Internet Explorer properties, such as the width and height of the window, and hide items such as the toolbar and status bar.

4. Set the Visible property to 1 to display the instance on the screen.

5. Create an object reference to the Document object.

6. Prepare the Web page for writing by opening the Document object (objDocument.Open).

7. Use HTML tags to:

   • Set the page title.

   • Set the background color (bgcolor) to white.

   • Insert a table that fills 100% of the document width.

   • Create the initial table row with two columns: one labeled Service and the other labeled State.

8. Create a variable to specify the computer name.

9. Use a GetObject call to connect to the WMI namespace rootcimv2, and set the impersonation level to “impersonate.”

10. Use the ExecQuery method to query the Win32_Service class.

    This query returns a collection consisting of all the services installed on the computer.

11. For each service in the collection, create a new row in the table. Each row has two columns, one containing the service name and the other containing the service state.

12. Use HTML tags to mark the end of the table, the document body, and the document head.

Example 17.7. Displaying Data in a Web Page

 1 Set objExplorer = CreateObject("InternetExplorer.Application")
 2 objExplorer.Navigate "about:blank"
 3 objExplorer.ToolBar = 0
 4 objExplorer.StatusBar = 0
 5 objExplorer.Width = 800
 6 objExplorer.Height = 570
 7 objExplorer.Left = 0
 8 objExplorer.Top = 0
 9 objExplorer.Visible = 1
10
11 Do While (objExplorer.Busy)
12 Loop
13
14 Set objDocument = objExplorer.Document
15 objDocument.Open
16
17 objDocument.Writeln "<html><head><title>Service Status</title></head>"
18 objDocument.Writeln "<body bgcolor='white'>"
19 objDocument.Writeln "<table width='100%'>"
20 objDocument.Writeln "<tr>"
21
22 objDocument.Writeln "<td width='50%'><b>Service</b></td>"
23 objDocument.Writeln "<td width='50%'><b>State</b></td>"
24 objDocument.Writeln "</tr>"
25
26 strComputer = "."
27 Set objWMIService = GetObject("winmgmts:" _
28     & "{impersonationLevel=impersonate}!\" & strComputer& "
ootcimv2")
29 Set colServices = objWMIService.ExecQuery _
30     ("SELECT * FROM Win32_Service")
31
32 For Each objService in colServices
33     objDocument.Writeln "<tr>"
34     objDocument.Writeln "<td width='50%'>" & objService.DisplayName & "</td>"
35     objDocument.writeln "<td width='50%'>" & objService.State & "</td>"
36     objDocument.Writeln "</tr>"
37 Next
38
39 objDocument.Writeln "</table>"
40 objDocument.Writeln "</body></html>"
41 objDocument.Write()
42 objDocument.Close

Clearing a Web Page

The WriteLn method allows you to add information to a Web page: Each time you call the WriteLn method, the new data is appended to the bottom of the page. This works fine in many situations. For example, if you want to extract a particular set of records from an event log, you can display those records in a Web page by using WriteLn. The fact that WriteLn appends these records one right after the other is no problem — in fact, that is exactly what you want it to do.

In other cases, however, you might want to periodically clear the screen to make room for new information. For example, if you have a script that monitors printer status every 15 minutes, you want the initial printer status displayed in the Web page. When the printer status is resampled, you probably do not want the second set of data to be appended to the end of the first set. Instead, you want to clear the browser screen and display only the current set of data.

One quick way to clear the browser screen is to create a TextRange object that encompasses the entire document and then set the Text property of that object to nothing. A TextRange object represents text within an HTML element; these elements include the document body, a button, a text box, and any other element that has a Text property.

For example, this code creates a TextRange object that encompasses the entire body of the document and then clears that object by setting the Text property to an empty string (“”):

Set objTextRange = objDocument.body.CreateTextRange() objTextRange.Text = ""

Stopping a Script When Internet Explorer Is Closed

Although Internet Explorer provides an excellent alternative to displaying script output in a command window, you can encounter a problem if the browser window is closed before your script finishes running. For example, you might have a script that creates an instance of Internet Explorer and then writes service information to the document window. If Internet Explorer is closed before you finish writing the service information, the script will fail; this occurs because the script is attempting to write to an instance of the browser that no longer exists.

To avoid this problem, you can configure your script to respond to Internet Explorer events. When Internet Explorer is closed, the browser triggers an onQuit event. Your script can watch for this event and take the appropriate action when it occurs. For example, the script might create a new instance of Internet Explorer, or it might use the Wscript.Quit method to terminate itself.

When creating this instance of Internet Explorer, you must use the Wscript CreateObject method; this is the only way to add event handling to a script. To enable event handling, CreateObject requires two parameters: the ProgID “InternetExplorer.Application” and a second argument consisting of a name to be given to the event handler. This name typically bears some relation to the created object followed by an underscore. For example, this code assigns the name IE_ to the entity responsible for handling Internet Explorer events:

Set objExplorer = WScript.CreateObject("InternetExplorer.Application", "IE_")

Although you do not have to follow this naming convention, it does make it easier for someone to read your script and understand how it works.

The event handler then watches for events triggered by Internet Explorer. When an event occurs, the event handler checks the script to see whether any procedures should run in response to that event. For example, this procedure causes the script to terminate itself any time the onQuit event is detected:

Sub IE_onQuit()
   Wscript.Quit
End Sub

In other words, any time the browser window is closed (thus triggering the onQuit event), the script will terminate itself. The script will thus automatically quit any time Internet Explorer quits.

You can create other procedures to respond to other events as well. For example, to respond to the onLoad event fired by Internet Explorer, create a procedure named IE_onLoad().

Note

Event handling will not work with all scripts. WSH scripts automatically terminate themselves when the last line of code is run; in some cases, therefore, the script will terminate itself before the Internet Explorer event can be fired. If this is a problem, you might have to use Wscript.Sleep to pause the script for a specified amount of time, or you might have to create a loop that keeps the script running until a particular event is detected.

Scripting Steps

Listing 17.8 contains a script that terminates itself when the browser window closes. To carry out this task, the script must perform the following steps:

1. Use the Wscript CreateObject method to create an instance of Internet Explorer, and assign the name IE_ to the event handler responsible for monitoring Internet Explorer events.

2. Open a blank Web page by navigating to “about:blank”.

3. Configure various Internet Explorer properties, such as the width and height of the window, and hide items such as the toolbar and status bar.

4. Set the Visible property to 1 to display the instance on the screen.

5. Create an object reference to the Document object.

6. Prepare the Web page for writing by opening the Document object (objDocument.Open).

7. Create a variable to specify the computer name.

8. Use a GetObject call to connect to the WMI namespace rootcimv2, and set the impersonation level to “impersonate.”

9. Use the ExecQuery method to query the Win32_Service class.

   This query returns a collection consisting of all the services installed on the computer.

10. For each service in the collection, use the WriteLn method to write the service display name and a carriage return/linefeed (<BR>) to the browser window.

    Because this is a demonstration script, a two-second pause (Wscript.Sleep 2000) is inserted after each service name is written to the browser. This ensures that the script will continue running long enough for you to close the browser window.

11. Create a subroutine named IE_onQuit(). This subroutine will be called whenever Internet Explorer is closed.

12. If the subroutine is called (meaning Internet Explorer has been closed), use the Wscript.Quit method to terminate the script.

To demonstrate how the script responds to Internet Explorer events, start the script and then close the browser window before all the service names have been written. When the browser window closes, the script will automatically terminate itself without generating an error.

Example 17.8. Stopping a Script When Internet Explorer Closes

 1 Set objExplorer = WScript.CreateObject _
 2     ("InternetExplorer.Application", "IE_")
 3 objExplorer.Navigate "about:blank"
 4 objExplorer.ToolBar = 0
 5 objExplorer.StatusBar = 0
 6 objExplorer.Width = 400
 7 objExplorer.Height = 250
 8 objExplorer.Left = 0
 9 objExplorer.Top = 0
10 objExplorer.Visible = 1
11 Set objDocument = objExplorer.Document
12 objDocument.Open
13 strComputer = "."
14 Set objWMIService = GetObject("winmgmts:" _
15     & "{impersonationLevel=impersonate}!\" & strComputer& "
ootcimv2")
16 Set colServices = objWMIService.ExecQuery _
17     ("SELECT * FROM Win32_Service")
18 For Each objService in colServices
19     objDocument.Writeln objService.DisplayName & "<BR>"
20     Wscript.Sleep 2000
21 Next
22 Sub IE_onQuit()
23    Wscript.Quit
24 End Sub

Although you can control Internet Explorer from a separate script, you will have to include code to repeatedly ensure that the browser is still running. If you do not, you will encounter problems such as:

Embedding the script code inside a Web page enables you to overcome these problems. When you embed the code, the Web page and the script are linked together; closing the Web page will also terminate the script. However, this introduces a new set of problems. Because Internet Explorer is designed for use over the Internet, it has a number of built-in security precautions that prevent Web sites from harming the local computer in any way. For example, if you include Windows Management Instrumentation (WMI) or another ActiveX® control in a Web page, a message box similar to the one shown in Figure 17.3 will appear when the script is run.

Figure 17.3. Unsafe for Scripting Message Box

In turn, the script will suspend itself until you click Yes. This means you cannot create a Web page that can refresh itself (for example, a Web page that periodically updates the status of all the printers on a print server). Each time the page queries the WMI service, the “unsafe for scripting” message box will appear and the script will pause until you click Yes.

One way to work around the security issues inherent in Internet Explorer is to embed your script within a hypertext application (HTA) rather than an HTML file. In its simplest form, an HTA is nothing but a Web page with the .hta file name extension rather than the .htm file name extension. In fact, you can convert any Web page to an HTA just by changing the file name extension.

However, HTAs run in a different process (Mshta.exe) than do HTML files. This allows HTAs to bypass Internet Explorer security. (Of course, HTAs still respect such things as operating system security and the NTFS file system security.) HTAs are fully trusted applications, meaning that you will not receive any security warnings when using objects such as WMI or the FileSystemObject.

Although HTAs respond to the same commands that can be issued to an instance of Internet Explorer, a number of additional attributes are available through the HTA object model. Several of these attributes are listed in Table 17.4.

HTML applications require no special coding; you can create an HTA simply by changing the .htm file extension of a Web page to .hta. However, by adding the <HTA:Application> tag to the Web page code, you can gain additional control over how the HTA will be displayed on the screen and which elements of the user interface will be available. To configure any of these elements, include the <HTA:Application> tag and the appropriate elements within the Web page <HEAD> tag.

For example, the following code snippet prevents the HTA from being displayed in the taskbar:

<HTA:Application
    ShowInTaskbar = No
>

Scripting Steps

Listing 17.9 contains HTML tags for creating a sample HTA file. Type this code into a text editor, and then save it with the .hta file name extension.

To create an HTA file, you must:

 1 <HTML>
 2 <HEAD>
 3 <HTA:Application
 4     Border = Thick
 5     BorderStyle = Complex
 6     ShowInTaskBar = No
 7     MaximizeButton = No
 8     MinimizeButton = No
 9 >
10 </HEAD>
11 <BODY>
12 This is a sample HTA.
13 </BODY>
14 </HTML>

A sample HTA that displays service information is shown in Listing 17.10. In this script, the code to retrieve service information and to write that data to the browser window is included in a window_onLoad procedure. This procedure automatically runs anytime the Web page is loaded. As a result, service information will be displayed anytime you start (or refresh) the HTA.

 1 <HTML>
 2 <HEAD>
 3 <HTA:Application
 4     Border = Thick
 5     BorderStyle = Complex
 6     ShowInTaskBar = No
 7     MaximizeButton = No
 8     MinimizeButton = No
 9 >
10 <SCRIPT LANGUAGE="VBScript">
11 Sub window_onLoad
12     Set objDocument = self.Document
13     objDocument.open
14     strComputer = "."
15     Set objWMIService = GetObject("winmgmts:" _
16         & "{impersonationLevel=impersonate}!\" & strComputer & "
ootcimv2")
17     Set colServices = objWMIService.ExecQuery _
18         ("SELECT * FROM Win32_Service")
19     For Each objService in colServices
20         objdocument.WriteLn objService.DisplayName & "<br>"
21     Next
22 End Sub
23 </SCRIPT>
24 </HEAD>
25 <BODY>
26 </BODY>
27 </HTML>

The script shown in Listing 17.10 provides a quick and easy way to display data. Like most standard Web pages, however, it does not allow you to manipulate that data in any way. The data cannot be sorted; instead, it is displayed in the order it is returned by WMI. Sorting is not the only limitation of this script; in addition, you cannot retrieve information for all the services on a computer and then choose to display only those services that are running. To filter the data display, you would need to edit and rerun the script so that it returns only the services that are running. To again look at all the services, you would need to re-edit and rerun the script.

The tabular data control (an ActiveX control that is installed with Internet Explorer) provides a way to display data in tabular format. But the tabular data control does more than just make it quick and easy to display data in a table. By adding a few lines of code, you can sort this data any way that you want; for example, you can sort a list of services by name, by status, by the service account under which they run, or by any other property in your data set. Likewise, you can also filter the data dynamically; for example, you can show all the services, dynamically hide all the services that are not running, and then dynamically show all the services again. This can all be done without having to refresh the page or requery the data set.

With the tabular data control, you do the following:

You can also use other HTML formatting in creating your table. For example, if you want to display the Service Name in bold, you can insert the HTML tag for bold (<B>):

<TD><B><DIV datafld="Service Name"></DIV></B></TD>

The tabular data control supports the properties shown in Table 17.5.

Scripting Steps

Listing 17.11 contains a Web page that displays script output by using the tabular data control. To carry out this task, the Web page must include the following:

 1 <HTML>
 2 <BODY>
 3 <OBJECT id="serviceList" CLASSID="clsid:333C7BC4-460F-11D0-BC04-0080C7055A83">
 4    <PARAM NAME="DataURL" VALUE="c:scriptsservice_list.csv">
 5    <PARAM NAME="UseHeader" VALUE="True">
 6    <PARAM NAME="TextQualifier" VALUE=",">
 7 </OBJECT>
 8 <H2>Current Service Status</H2>
 9 <table border='1' width='100%' cellspacing='0' datasrc=#serviceList>
10 <THEAD><TR>
11 <TD>Computer</TD>
12 <TD>Service</TD>
13 <TD>Status</TD>
14 </TR>
15 </THEAD>
16 <TBODY>
17 <TR>
18 <TD><B><DIV datafld="System Name"></DIV></B></TD>
19 <TD><DIV datafld="Display Name"></DIV></TD>
20 <TD><DIV datafld="Service State"></DIV></TD>
21 </TR>
22 </TBODY>
23 </TABLE>
24 </BODY>
25 </HTML>

<PARAM NAME="SortColumn" VALUE="Service State">

<PARAM NAME="SortColumn" VALUE="Service State;Display Name">

<PARAM NAME="SortColumn" VALUE="-Service State">

1
11
2
27
3

Service Name:Text,Local Service:Boolean,Install Date:Date MDY

 1 <HTML>
 2 <BODY>
 3 <OBJECT id="serviceList" CLASSID="clsid:333C7BC4-460F-11D0-BC04-0080C7055A83">
 4    <PARAM NAME="DataURL" VALUE="c:scriptsservice_list.csv"> <PARAM
 5 NAME="UseHeader" VALUE="True">
 6    <PARAM NAME="TextQualifier" VALUE=",">
 7    <PARAM NAME="SortColumn" VALUE="Service State">
 8 </OBJECT>
 9 <H2>Current Service Status</H2>
10 <table border='1' width='100%' cellspacing='0' datasrc=#serviceList>
11 <THEAD><TR>
12 <TD>Computer</TD>
13 <TD>Service</TD>
14 <TD>Status</TD>
15 </TR>
16 </THEAD>
17 <TBODY>
18 <TR>
19 <TD><B><DIV datafld="System Name"></DIV></B></TD>
20 <TD><DIV datafld="Display Name"></DIV></TD>
21 <TD><DIV datafld="Service State"></DIV></TD>
22 </TR>
23 </TBODY>
24 </TABLE>
25 </BODY>
26 </HTML>

Filtering Data by Using the Tabular Data Control

Data can also be filtered by using the tabular data control. This capability can help administrators quickly spot items of interest. For example, if an administrator is interested only in services that are currently stopped, he or she can use a filter to display only those services. In this way, a single data source can serve multiple purposes. Otherwise, you might have to save information about stopped services to one text file and information about paused services to another text file.

To create a filter for the tabular data control, set the value for the Filter parameter to the name of the column to be filtered, and set the criteria for which records are to be included or excluded. For example, this line of code creates a filter that will limit data retrieval to those records for which the Service State is Stopped:

<PARAM NAME="Filter" VALUE="Service State = Stopped">

Note

Although it is beyond the scope of this chapter to demonstrate, both filtering and sorting can be done interactively. For example, you might configure your Web page so that each time you click a column heading, the data is sorted by that column.

Scripting Steps

Listing 17.13 contains a Web page that displays script output by using the tabular data control. In this example, a filter is applied so that only services that are stopped are displayed. To carry out this task, the Web page must include the following:

1. The starting <HTML> and <BODY> tags.

2. An <OBJECT> tag used to insert the tabular data control. You must specify an id for the control as well as the CLASSID:

   clsid:333C7BC4-460F-11D0-BC04-0080C7055A83.

   In addition, specify the following parameters:

   • DataURL, along with the path to the comma-separated-values file.

   • UseHeader, indicating that the first row in the comma-separated-values file contains header information.

   • TextQualifier, indicating that the comma is used to separate items within each row of the text file.

   • Filter, which specifies the datafld and value to be filtered on (ServiceState = ’Stopped’).

3. An <H2> tag used to provide a heading for the page.

4. A table, with the datasrc set to #serviceList, the id assigned to the tabular data control. This means that table will derive its data from the tabular data control.

5. A <THEAD> and <TR> tag to mark the first row in the table. Three <TD> tags are used to indicate individual columns in the table:

   • Computer

   • Service

   • Status

6. A <TBODY> and <TROW> tag used to delineate the data columns. The three columns must specify a datafld used in the header row of the text file:

   • System Name

   • Display Name

   • Service State

7. Ending tags for the table, body, and HTML.

Example 17.13. Displaying Filtered Data by Using the Tabular Data Control

 1 <HTML>
 2 <BODY>
 3 <OBJECT id="serviceList" CLASSID="clsid:333C7BC4-460F-11D0-BC04-0080C7055A83">
 4    <PARAM NAME="DataURL" VALUE="c:scriptsservice_list.csv">
 5    <PARAM NAME="UseHeader" VALUE="True">
 6    <PARAM NAME="TextQualifier" VALUE=",">
 7    <PARAM NAME="Filter" VALUE="Service State = Stopped">
 8 </OBJECT>
 9 <H2>Current Service Status</H2>
10 <table border='1' width='100%' cellspacing='0' datasrc=#serviceList>
11 <THEAD><TR>
12 <TD>Computer</TD>
13 <TD>Service</TD>
14 <TD>Status</TD>
15 </TR>
16 </THEAD>
17 <TBODY>
18 <TR>
19 <TD><B><DIV datafld="System Name"></DIV></B></TD>
20 <TD><DIV datafld="Display Name"></DIV></TD>
21 <TD><DIV datafld="Service State"></DIV></TD>
22 </TR>
23 </TBODY>
24 </TABLE>
25 </BODY>
26 </HTML>

DataList.Sort = "ServiceAccountName"

 1 Const adVarChar = 200
 2 Const MaxCharacters = 255
 3 Set DataList = CreateObject("ADOR.Recordset")
 4 DataList.Fields.Append "ServiceName", adVarChar, MaxCharacters
 5 DataList.Fields.Append "ServiceState", adVarChar, MaxCharacters
 6 DataList.Open
 7 strComputer = "."
 8 Set objWMIService = GetObject("winmgmts:" _
 9     & "{impersonationLevel=impersonate}!\" & strComputer& "
ootcimv2")
10 Set colServices = objWMIService.ExecQuery _
11     ("SELECT * FROM Win32_Service")
12 For Each Service in colServices
13     DataList.AddNew
14     DataList("ServiceName") = Service.Name
15     DataList("ServiceState") = Service.State
16     DataList.Update
17 Next
18 DataList.Sort = "ServiceState"
19 DataList.MoveFirst
20 Do Until DataList.EOF
21     Wscript.Echo DataList.Fields.Item("ServiceName") _
22         & vbTab & DataList.Fields.Item("ServiceState")
23 DataList.MoveNext
24 Loop

To connect to a database by using ADO, you follow the same standard procedure regardless of the type of database to which you are connecting. Your script must:

When using the Recordset object Open method, include both a standard SQL command (for example, “SELECT * FROM Inventory”) and parameters specifying CursorLocation, CursorType, and LockType. These parameters are described in more detail in Table 17.8.

When you are finished with the database connection and the recordset, use the Close method to close both objects.

Scripting Steps

Listing 17.15 contains a script that creates an ADO connection. To carry out this task, the script must perform the following steps:

 1 Const adOpenStatic = 3
 2 Const adLockOptimistic = 3
 3 Const adUseClient = 3
 4 Set objConnection = CreateObject("ADODB.Connection")
 5 Set objRecordset = CreateObject("ADODB.Recordset")
 6 objConnection.Open "DSN=Inventory;"
 7 objRecordset.CursorLocation = adUseClient
 8 objRecordset.Open "SELECT * FROM Hardware" , objConnection, _
 9     adOpenStatic, adLockOptimistic
10 objRecordset.Close
11 objConnection.Close

Many enterprise scripts are designed to take data from multiple sources (for example, all the event logs on all your domain controllers) and then combine that information into a single database. This is typically done for two reasons: It creates a central repository for this data, and it makes it possible for you to use database tools to analyze the data.

To copy information to a database, your script must create a new record for each piece of information retrieved. (For example, a new record must be added to the database for each event retrieved from an event log.)

You use the AddNew method to add new records to a database. After you have opened a connection to a database and a recordset, do the following:

You can use the AddNew method only if the recordset can be updated. If you opened the recordset in read-only mode, any attempt to add a new record will fail.

Scripting Steps

Listing 17.16 contains a script that adds a new record — the name of a sound card — to a database. To carry out this task, the script must perform the following steps:

 1 Const adOpenStatic = 3
 2 Const adLockOptimistic = 3
 3 Const adUseClient = 3
 4 Set objConnection = CreateObject("ADODB.Connection")
 5 Set objRecordset = CreateObject("ADODB.Recordset")
 6 objConnection.Open "DSN=Inventory;"
 7 objRecordset.CursorLocation = adUseClient
 8 objRecordset.Open "SELECT * FROM Hardware" , objConnection, _
 9     adOpenStatic, adLockOptimistic
10 strComputer = "."
11 Set objWMIService = GetObject("winmgmts:" _
12     & "{impersonationLevel=impersonate}!\" & strComputer& "
ootcimv2")
13 Set colSoundCards = objWMIService.ExecQuery _
14     ("SELECT * FROM Win32_SoundDevice")
15 For Each objSoundCard in colSoundCards
16     objRecordset.AddNew
17     objRecordset("ComputerName") = objSoundCard.SystemName
18     objRecordset("Manufacturer") = objSoundCard.Manufacturer
19     objRecordset("ProductName") = objSoundCard.ProductName
20     objRecordset.Update
21 Next
22 objRecordset.Close
23 objConnection.Close

Many enterprise scripts require you to perform an action on multiple records in the database. For example, you might have a script that updates the hardware inventory for a set of computers. The script needs to connect to the database, locate the record for the first computer, and apply any required updates. The script must then repeat the process for each computer being inventoried.

It is possible to create an SQL query that returns only the name of computer being updated (for example, “SELECT * FROM Inventory WHERE ComputerName = ’WebServer’”). However, if your script must update 100 computers, this would require 100 separate SQL queries being passed to the database server, one for each computer being updated. A more efficient approach might be to download the entire set of computers and then use the Recordset object Find method to locate each computer as needed.

The Find method requires two steps:

You can use the Recordset object EOF (end-of-file) property to determine whether a record was found. If EOF is True, this means the recordset has been searched from beginning to end and no record was found. This is important because your script will fail if it attempts to take action on a record that does not exist. For example, you might use the Find method to locate a particular record and then use the Delete method to delete that record. If the record does not exist, however, both the Delete method and your script will fail.

Using the Find method also helps you eliminate duplicate records within a database. For example, when creating an inventory of your computers, you probably want one record per computer; you do not want multiple records for the computer WebServer. To prevent the possibility of creating duplicate records, follow a procedure similar to this:

Scripting Steps

Listing 17.17 contains a script that finds a record in a recordset. To carry out this task, the script must perform the following steps:

 1 Const adOpenStatic = 3
 2 Const adLockOptimistic = 3
 3 Const adUseClient = 3
 4 Set objConnection = CreateObject("ADODB.Connection")
 5 Set objRecordset = CreateObject("ADODB.Recordset")
 6 objConnection.Open "DSN=Inventory;"
 7 objRecordset.CursorLocation = adUseClient
 8 objRecordset.Open "SELECT * FROM Hardware" , objConnection, _
 9     adOpenStatic, adLockOptimistic
10 strSearchCriteria = "ComputerName = 'WebServer'"
11 objRecordSet.Find strSearchCriteria
12 If objRecordset.EOF Then
13     Wscript.Echo "Record cannot be found."
14 Else
15     Wscript.Echo "Record found."
16 End If
17 objRecordset.Close
18 objConnection.Close

Scripts often need to update existing records rather than add new records to a database. For example, with an inventory script you do not want to add a new record each time the script is run. If you did, you would end up with multiple records for the same computer. Instead, you want to update the existing record for each computer, replacing the old inventory data with the newly retrieved data.

To update a record by using ADO, do the following:

Scripting Steps

Listing 17.18 contains a script that updates a record in a database. To carry out this task, the script must perform the following steps:

 1 Const adOpenStatic = 3
 2 Const adLockOptimistic = 3
 3 Const adUseClient = 3
 4 Set objConnection = CreateObject("ADODB.Connection")
 5 Set objRecordset = CreateObject("ADODB.Recordset")
 6 objConnection.Open "DSN=Inventory;"
 7 objRecordset.CursorLocation = adUseClient
 8 objRecordset.Open "SELECT * FROM Hardware" , objConnection, _
 9     adOpenStatic, adLockOptimistic
10 strSearchCriteria = "ComputerName = 'WebServer'"
11 objRecordSet.Find strSearchCriteria
12 strComputer = "."
13 Set objWMIService = GetObject("winmgmts:" _
14     & "{impersonationLevel=impersonate}!\" & strComputer& "
ootcimv2")
15 Set colSoundCards = objWMIService.ExecQuery _
16     ("SELECT * FROM Win32_SoundDevice")
17 For Each objSoundCard in colSoundCards
18     objRecordset("ComputerName") = objSoundCard.SystemName
19     objRecordset("Manufacturer") = objSoundCard.Manufacturer
20     objRecordset("ProductName") = objSoundCard.ProductName
21     objRecordset.Update
22 Next
23 objRecordset.Close
24 objConnection.Close

There will undoubtedly be times when you want to delete a record or set of records from a database. For example, you might decommission the DNS Server service on a computer; in turn, you will then need to delete that computer from the database table that contains the names of your DNS servers. Or suppose you maintain three months of performance monitoring information in a database. Each month you will need to delete some of the old data to make room for the new data. For example, in April you will need to delete the data for January. After you add the April data, the database will again contain data for three months: February, March, and April.

To delete a record by using ADO, do the following:

When you use the Delete method to delete a record, the record will be deleted as soon as the method is called. You do not need to use the Update method to apply the changes. No warning of any kind will be issued before the record is deleted.

Scripting Steps

Listing 17.19 contains a script that deletes a record from a database. To carry out this task, the script must perform the following steps:

 1 Const adOpenStatic = 3
 2 Const adLockOptimistic = 3
 3 Const adUseClient = 3
 4 Set objConnection = CreateObject("ADODB.Connection")
 5 Set objRecordset = CreateObject("ADODB.Recordset")
 6 objConnection.Open "DSN=Inventory;"
 7 objRecordset.CursorLocation = adUseClient
 8 objRecordset.Open "SELECT * FROM Hardware" , objConnection, _
 9     adOpenStatic, adLockOptimistic
10 strSearchCriteria = "ComputerName = 'WebServer'"
11 objRecordSet.Find strSearchCriteria
12 objRecordset.Delete
13 objRecordset.Close
14 objConnection.Close

There will also be times when you need to clear a database table, deleting all the records. For example, suppose at the end of each month you import event log records into a database and then run a series of statistical analyses on that data. At the end of the next month, you might want to clear the table; that way, the next set of records imported into the database will not commingle with any previous records.

Although you can clear a database by finding and deleting each record individually, a better and faster approach is to use an SQL Delete query to delete all the records in a single operation.

Scripting Steps

Listing 17.20 contains a script that deletes all the records in a database table. To carry out this task, the script must perform the following steps:

 1 Const adOpenStatic = 3
 2 Const adLockOptimistic = 3
 3 Const adUseClient = 3
 4 Set objConnection = CreateObject("ADODB.Connection")
 5 Set objRecordset = CreateObject("ADODB.Recordset")
 6 objConnection.Open "DSN=Inventory;"
 7 objRecordset.CursorLocation = adUseClient
 8 objRecordset.Open "DELETE * FROM Hardware" , objConnection, _
 9     adOpenStatic, adLockOptimistic
10 objConnection.Close

You can use Internet Explorer as a way to enter passwords. To mask passwords using Internet Explorer, you need to:

Scripting Steps

Listing 17.21 contains a script that masks passwords entered in Internet Explorer. (To actually use the script, you will have to create the file C:ScriptsPassword.htm.) To carry out this task, the script must perform the following steps:

 1 Set objExplorer = WScript.CreateObject _
 2     ("InternetExplorer.Application", "IE_")
 3 objExplorer.Navigate "file:///c:scriptspassword.htm"
 4 objExplorer.ToolBar = 0
 5 objExplorer.StatusBar = 0
 6 objExplorer.Width = 400
 7 objExplorer.Height = 250
 8 objExplorer.Left = 0
 9 objExplorer.Top = 0
10 objExplorer.Visible = 1
11 Do While (objExplorer.Document.All.OKClicked.Value = "")
12     Wscript.Sleep 250
13 Loop
14 strPassword = objExplorer.Document.All.PasswordBox.Value
15 objExplorer.Quit
16 Wscript.Sleep 250
17 Wscript.Echo strPassword

The script shown in Listing 17.22 shows how a masked password can be retrieved from Internet Explorer, and then used to connect to a remote computer and install a software package. In line 10, the variable strPassword, which contains the value typed by the user, is used to connect to the remote computer. This is done rather than hard-coding the password in the script.

 1 Const wbemImpersonationLevelDelegate = 4
 2
 3 Set objExplorer = WScript.CreateObject _
 4     ("InternetExplorer.Application", "IE_")
 5 objExplorer.Navigate "file:///c:scriptspassword.htm"
 6 objExplorer.ToolBar = 0
 7 objExplorer.StatusBar = 0
 8 objExplorer.Width = 400
 9 objExplorer.Height = 250
10 objExplorer.Left = 0
11 objExplorer.Top = 0
12 objExplorer.Visible = 1
13 Do While (objExplorer.Document.All.OKClicked.Value = "")
14     Wscript.Sleep 250
15 Loop
16 strPassword = objExplorer.Document.All.PasswordBox.Value
17 objExplorer.Quit
18
19 Set objWbemLocator = CreateObject("WbemScripting.SWbemLocator")
20 Set objConnection = objwbemLocator.ConnectServer _
21     ("WebServer", "rootcimv2", "fabrikamadministrator", _
22          strPassword")
23 Set objSoftware = objConnection.Get("Win32_Product")
24 errReturn = objSoftware.Install("\atl-dc-02scripts1561_lab.msi",,True)

Enabling a script to send automated e-mail messages provides a way for your script to send realtime alerts whenever a particular event occurs (for example, when the script runs, when the script finishes, or when the script encounters a problem of some kind). Alerts are commonly used in system administration scripting, but these notices are typically displayed either by using pop-up message boxes or by recording an event in the event log. Although both of these techniques are useful, they require someone to either physically sit at the computer where the message box is displayed or continually monitor the event log for the occurrence of new events.

By contrast, e-mail alerts can be directed to a particular administrator or group of administrators regardless of their physical location; administrators can receive these alerts even if they are offsite. Because most administrators read their e-mail more often than they read event logs, there is a greater chance that they will respond quickly to the e-mail alert. With the new generation of PDAs and cell phones that can be used to check e-mail, the ability to programmatically send alerts using this technology becomes even more valuable.

E-mail can be sent from any Microsoft® Windows® 2000–based computer by using CDO.

Scripting Steps

Listing 17.23 contains a script that sends an e-mail message by using CDO. To carry out this task, the script must perform the following steps:

For this script to work, the SMTP service must be installed on the computer where the script is being run.

1 Set objEmail = CreateObject("CDO.Message")
2 objEmail.From = "[email protected]"
3 objEmail.To = "[email protected]"
4 objEmail.Subject = "Atl-dc-01 down"
5 objEmail.Textbody = "Atl-dc-01 is no longer accessible over the network."
6 objEmail.Send

The script shown in Listing 17.23 can be used as long as the SMTP service is installed on the computer where the script is running. Obviously, this poses a problem: Most likely, you do not want the SMTP service to be installed and running on every one of your computers.

Even if the SMTP service is not installed on the computer, you can still send e-mail from a script as long as the SMTP service is installed somewhere on your network. To do this, your script must include code that specifies the properties of the computer and the SMTP service that will be used to send the message.

Each e-mail Message object has an associated Configuration object that defines configuration settings for sending the message. These settings are stored as fields within the Configuration object; each field is a Uniform Resource Identifier (URI) that contains information for the configuration setting. The three URIs required to send an SMTP e-mail message are shown in Table 17.10.

Scripting Steps

Listing 17.24 contains a script that sends e-mail from a computer that is not running the SMTP service. To carry out this task, the script must perform the following steps:

 1 Set objEmail = CreateObject("CDO.Message")
 2 objEmail.From = "[email protected]"
 3 objEmail.To = "[email protected]"
 4 objEmail.Subject = "Server down"
 5 objEmail.Textbody = "Server1 is no longer accessible over the network."
 6 objEmail.Configuration.Fields.Item _
 7     ("http://schemas.microsoft.com/cdo/configuration/sendusing") = 2
 8 objEmail.Configuration.Fields.Item _
 9     ("http://schemas.microsoft.com/cdo/configuration/smtpserver") = _
10         "MySMTPHost"
11 objEmail.Configuration.Fields.Item _
12     ("http://schemas.microsoft.com/cdo/configuration/smtpserverport") = 25
13 objEmail.Configuration.Fields.Update
14 objEmail.Send

If you feel that a script needs a progress indicator, it is recommended that you use a graphical progress indicator; after all, if visual cues are important, your progress indicator should be visually compelling. Perhaps the easiest way to add a graphical progress indicator to your scripts is to use Internet Explorer.

By the way, this is true even if the script runs in a command window under CScript; Internet Explorer can be instantiated and used as a progress indicator even if the script is running from the command line.

One way to indicate progress by using Internet Explorer is to display a message in the browser. In some cases, you might want to display a single message (“Please wait ....”) and then have the message disappear when the script is finished. Alternatively, you might want to periodically change the message to reflect whatever the script is doing. For example, if you have a script that stopped a service, waited two minutes, and then restarted the service, you might display these messages in the browser:

Regardless of the number or the type of messages you choose to display, you can display custom messages within Internet Explorer by configuring the InnerHTML property of the document body. This replaces the entire document body with the specified text. For example, this code clears the document and displays the message, “Service retrieval in progress.”:

objExplorer.Document.Body.InnerHTML = "Service retrieval in progress."

You can also use standard HTML tags to include formatting when setting the InnerHTML property. For example, this code uses the < B> tag to display the message in bold:

objExplorer.Document.Body.InnerHTML = "<B>Service information retrieved.</B>"

There are two important points to keep in mind when using Internet Explorer as a progress indicator:

To prevent this, use On Error Resume Next statement within the script. Anytime you attempt to manipulate Internet Explorer, check the error number. If the error number is anything other than 0, that means a problem occurred, and it is likely that Internet Explorer is no longer available. In that case, you must decide whether you want your script to terminate itself, continue without a progress indicator, or generate a new instance of Internet Explorer.

For information about a way to overcome these problems, see “Stopping a Script When Internet Explorer Is Closed” in this chapter.

Scripting Steps

Listing 17.25 contains a script that tracks script progress by using Internet Explorer. To carry out this task, the script must perform the following steps:

 1 Set objExplorer = CreateObject("InternetExplorer.Application")
 2 objExplorer.Navigate "about:blank"
 3 objExplorer.ToolBar = 0
 4 objExplorer.StatusBar = 0
 5 objExplorer.Width = 400
 6 objExplorer.Height = 200
 7 objExplorer.Left = 0
 8 objExplorer.Top = 0
 9 Do While (objExplorer.Busy)
10     Wscript.Sleep 200
11 Loop
12 objExplorer.Visible = 1
13 objExplorer.Document.Body.InnerHTML = "Retrieving service information. " _
14     & "This might take several minutes to complete."
15 strComputer = "."
16 Set objWMIService = GetObject("winmgmts:" _
17     & "{impersonationLevel=impersonate}!\" & strComputer& "
ootcimv2")
18 Set colServices = objWMIService.ExecQuery _
19     ("SELECT * FROM Win32_Service")
20 For Each objService in colServices
21     Wscript.Sleep 200
22 Next
23 objExplorer.Document.Body.InnerHTML = "Service information retrieved."
24 Wscript.Sleep 3000
25 Wscript.Quit

The script shown in Listing 17.26 displays a message when the script starts and then displays a second message when the script ends. To create a more dynamic progress bar, you might want to do something to indicate the intermediate steps taken by the script. This can be as simple as displaying an asterisk (*) inside the browser window each time a service is retrieved and acted upon.

To create a dynamic progress indicator, you can use the WriteLn method to write information to the browser each time the script takes a particular action. As a result, you end up with a progress indicator similar to the one shown in Figure 17.4. Each time a service is retrieved and acted upon, another asterisk is added to the browser window.

Figure 17.4. Tracking Dynamic Script Progress by Using Internet Explorer

Tip

By using different fonts, you can create a progress indicator that uses solid bars or dots rather than asterisks. For example, the letter “n” in the Wingdings font looks like this:.

Scripting Steps

Listing 17.26 contains a script that tracks script progress dynamically by using Internet Explorer. To carry out this task, the script must perform the following steps:

 1 Set objExplorer = CreateObject("InternetExplorer.Application")
 2 objExplorer.Navigate "about:blank"
 3 objExplorer.ToolBar = 0
 4 objExplorer.StatusBar = 0
 5 objExplorer.Width = 400
 6 objExplorer.Height = 200
 7 objExplorer.Left = 0
 8 objExplorer.Top = 0
 9 objExplorer.Visible = 1
10
11 Do While (objExplorer.Busy)
12 Loop
13
14 Set objDocument = objExplorer.Document
15 objDocument.Open
16 objDocument.Writeln "<html><head><title>Service Status</title></head>"
17 objDocument.Writeln "<body bgcolor='white'>"
18 objDocument.Writeln "Retrieving service information. Please wait. <p>"
19
20 strComputer = "."
21 Set objWMIService = GetObject("winmgmts:" _
22     & "{impersonationLevel=impersonate}!\" & strComputer& "
ootcimv2")
23 Set colServices = objWMIService.ExecQuery _
24     ("SELECT * FROM Win32_Service")
25
26 For Each objService in colServices
27     objDocument.Writeln "*"
28 Next
29
30 objDocument.Writeln "<br>Service information retrieved."
31 objDocument.Writeln "</body></html>"
32 Wscript.Sleep 4000
33 objDocument.Close
34 objExplorer.Quit

Set objDocument = objIE.Document
objDocument.body.style.cursor = "wait"

objDocument.body.style.cursor = "default"

Tracking Script Progress by Using an Animated .GIF

Because it is often difficult to report absolute script progress (for example, to note that a script is 37 percent complete), an alternative approach is to display a pseudo progress indicator that simply informs the user that an operation is in progress. For example, in Figure 17.5 an instance of Internet Explorer is used to note that a script operation is in progress. Instead of tracking the percentage of the operation that is complete, however, the dialog box merely displays a ticking clock and the message, “Please wait while service information is retrieved. This might take several minutes to complete.”

Figure 17.5. Tracking Script Progress by Using an Animated .GIF

To use this type of progress indicator, start by creating an HTML file that includes both an animated GIF (for example, a ticking clock or a moving hourglass) and any other message you want the user to see. In your script, you create an instance of Internet Explorer and then use the Navigate method to open the HTML file. When the script completes, you then use the Quit method to close Internet Explorer.

Scripting Steps

Listing 17.27 contains a script that tracks script progress by displaying a pseudo progress indicator. This progress indicator is simply a Web page that includes an animated .GIF and a message asking the user to please wait. (The assumption is that you have already created this Web page.) To carry out this task, the script must perform the following steps:

1. Create an instance of Internet Explorer.

2. Open the HTML page by navigating to “file://c:scriptsprogress.htm”.

3. Configure the user interface settings, and then show Internet Explorer by setting the Visible property to True.

4. Create a reference to the Internet Explorer Document object.

5. Set the cursor style to wait.

6. Pause for 5 seconds (5,000 milliseconds). This is done simply to keep the browser window open long enough for you to see the progress indicator.

7. Use the Quit method to dismiss Internet Explorer.

Example 17.27. Using an Animated .GIF as a Progress Indicator

 1 Set objIE = CreateObject("InternetExplorer.Application")
 2 objIE.navigate "file://c:scriptsprogress.htm"
 3 objIE.left=200
 4 objIE.top=200
 5 objIE.height=175
 6 objIE.width=450
 7 objIE.menubar=0
 8 objIE.toolbar=0
 9 objIE.addressbar=0
10 objIE.statusbar=0
11 objIE.visible=1
12 Do While (objIE.Busy)
13     Wscript.Sleep 200
14 Loop
15
16 Set objDocument = objIE.Document
17 objDocument.body.style.cursor = "wait"
18 Wscript.Sleep 5000
19 objIE.Quit

Running a script in a command window does not preclude you from using Internet Explorer as a way to track script progress; an Internet Explorer instance can be created and controlled from CScript in the same way it can be created and controlled from WScript.

At the same time, however, it is unusual for a command-line utility to generate a graphical progress indicator. Users might not recognize that the script running in the command window is tied to the progress indicator running in Internet Explorer. Because of this, you might want progress to be tracked in the same command window where the script is running.

Although you can track progress in a command window, there are at least two limitations:

Of course, you can use Wscript.Echo to periodically display progress messages in a command window. For example, you might have script output that looks similar to this:

C:Scripts>cscript services.vbs
Now completing Step 1 of 5.
Now completing Step 2 of 5.
Now completing Step 3 of 5.
Now completing Step 4 of 5.

Another approach commonly used with command-line utilities is to display a series of dots (periods) as a script progresses:

C:Scripts>cscript services.vbs
Retrieving service information. This might take several minutes.
........................................................................

Each time the script performs a subtask, a new dot is written to the command window. However, this cannot be done by using Wscript.Echo. Each time you call Wscript.Echo, the value is written to a new line. Because of this, your progress indicator would look like this:

C:Scripts>cscript services.vbs
Retrieving service information. This might take several minutes.
.
.
.
.

To append text to the command window, you must instead use the Wscript.StdOut.Write method and write each new value to the standard output stream.

Important

You can write to the standard output stream only if the script is running under CScript. If a script running under WScript attempts to write to the standard output stream, an “invalid handle” error will result.

Scripting Steps

Listing 17.28 contains a script that tracks script progress in a command window. To carry out this task, the script must perform the following steps:

 1 Wscript.Echo "Processing information. This might take several minutes."
 2 strComputer = "."
 3 Set objWMIService = GetObject("winmgmts:" _
 4     & "{impersonationLevel=impersonate}!\" & strComputer& "
ootcimv2")
 5 Set colServices = objWMIService.ExecQuery _
 6     ("SELECT * FROM Win32_Service")
 7 For Each objService in colServices
 8     Wscript.StdOut.Write(".")
 9 Next
10 Wscript.StdOut.WriteLine
11 Wscript.Echo "Service information processed."

Scheduled tasks can save a great deal of work for administrators, especially if these tasks are well coordinated for minimal impact on users, computers, and the network. However, poorly planned scheduled tasks can cause a number of problems.

For example, if multiple tasks are scheduled to run at the same time, some tasks might interfere with other tasks. Likewise, CPU-intensive or network-intensive tasks scheduled to run at inopportune times might negatively affect users or the network.

To help ensure that tasks are carried out on a regular basis, but without adversely affecting users or the network, it is important for administrators to know which tasks are scheduled to run on their computers and when they are scheduled to run. Enumerating your scheduled tasks can help you minimize the impact of these activities on an individual computer and on the network as a whole.

The Win32_ScheduledJob class can be used to enumerate the following items about the scheduled tasks on a computer:

Scheduled task properties available through the Win32_ScheduledJob class are shown in Table 17.13.

Scripting Steps

Listing 17.29 contains a script that enumerates the scheduled tasks on a computer. To carry out this task, the script must perform the following steps:

 1 strComputer = "."
 2 Set objWMIService = GetObject("winmgmts:" _
 3     & "{impersonationLevel=impersonate}!\" & strComputer & "
ootcimv2")
 4 Set colScheduledJobs = objWMIService.ExecQuery _
 5     ("SELECT * FROM Win32_ScheduledJob")
 6 For Each objJob in colScheduledJobs
 7     Wscript.Echo "Caption: " & objJob.Caption
 8     Wscript.Echo "Command: " & objJob.Command
 9     Wscript.Echo "Days Of Month: " & objJob.DaysOfMonth
10     Wscript.Echo "Days Of Week: " & objJob.DaysOfWeek
11     Wscript.Echo "Description: " & objJob.Description
12     Wscript.Echo "Elapsed Time: " & objJob.ElapsedTime
13     Wscript.Echo "Install Date: " & objJob.InstallDate
14     Wscript.Echo "Interact with Desktop: " & objJob.InteractWithDesktop
15     Wscript.Echo "Job ID: " & objJob.JobID
16     Wscript.Echo "Job Status: " & objJob.JobStatus
17     Wscript.Echo "Name: " & objJob.Name
18     Wscript.Echo "Notify: " & objJob.Notify
19     Wscript.Echo "Owner: " & objJob.Owner
20     Wscript.Echo "Priority: " & objJob.Priority
21     Wscript.Echo "Run Repeatedly: " & objJob.RunRepeatedly
22     Wscript.Echo "Start Time: " & objJob.StartTime
23     Wscript.Echo "Status: " & objJob.Status
24     Wscript.Echo "Time Submitted: " & objJob.TimeSubmitted
25     Wscript.Echo "Until Time: " & objJob.UntilTime
26 Next

To run a program or script at a specified time on a specified date, you must create a scheduled task that contains the following information:

Scheduled tasks can be created on local computers by using the Scheduled Task Wizard. However, this wizard cannot be used to schedule tasks on remote computers (or to simultaneously schedule tasks on more than one computer). If you need to create scheduled tasks on remote or multiple computers, you can use the command-line tool At.exe or create a custom script by using the WMI class Win32_ScheduledJob.

The Win32_ScheduledJob Create method can be used to create scheduled tasks on a computer. The Create method requires the parameters shown in Table 17.14. Parameters not required for a specific task should be left blank.

When a scheduled task is created, one of the error codes shown in Table 17.15 is returned, indicating the success or failure of the procedure.

Scripting Steps

Listing 17.30 contains a script that schedules a task on a computer. To carry out this task, the script must perform the following steps:

 1 strComputer = "."
 2 Set objService = GetObject("winmgmts:" & strComputer)
 3 Set objNewJob = Service.Get("Win32_ScheduledJob")
 4 errJobCreated = objNewJob.Create _
 5     ("Monitor.exe", "********123000.000000-420", _
 6         True , 1 OR 4 OR 16, , , JobID)
 7 If Err.Number = 0 Then
 8     Wscript.Echo "New Job ID: " & JobID
 9 Else
10     Wscript.Echo "An error occurred: " & errJobCreated
11 End If

When a scheduled task is no longer needed on a computer, it should be deleted. If a task is not deleted, it will continue to run as scheduled. This can create problems that might be a minor irritant (running a monitoring program whose data is no longer needed) or that might be extremely destructive (deleting files and folders that should not be deleted).

Scheduled tasks can be deleted using the Win32_ScheduledJob Delete method. There are two ways to delete scheduled tasks:

Scripting Steps

There are multiple ways to delete scheduled tasks:

Deleting a single scheduled task

Listing 17.31 contains a script that deletes a scheduled task on a computer. To carry out this task, the script must perform the following steps:

 1 strComputer = "."
 2 Set objService = GetObject("winmgmts:\" & strComputer)
 3 Set objInstance = objService.Get("Win32_ScheduledJob.JobID=1")
 4 objInstance.Delete

Deleting all the scheduled tasks on a computer

Listing 17.32 contains a script that deletes all the scheduled tasks on a computer. To carry out this task, the script must perform the following steps:

 1 strComputer = "."
 2 Set objService = GetObject("winmgmts:\" & strComputer)
 3 Set colScheduledTasks = objService.ExecQuery _
 4     ("SELECT * FROM Win32_ScheduledJob")
 5 For Each objTask in colScheduledTasks
 6     intJobID = objTask.JobID
 7     Set objInstance = objService.Get_
 8         ("Win32_ScheduledJob.JobID=" & intJobID & "")
 9     objInstance.Delete
10 Next