Previous Page
Next Page

WMI and the Network

In this section, you use Windows Management Instrumentation (WMI) to configure networking components. However, instead of just dashing off a quick WMI script, you will take a step forward and begin combining several of the techniques presented earlier in this book, such as writing to text files and reading from Active Directory. This little bit of magic will track every step of your networked operations, enabling you to avoid dire consequences should an operation fail to properly complete. You can use this technique to:

  • Import a list of computers from an organizational unit (OU) in Active Directory

  • Import a list of users from an OU in Active Directory

  • Import a list of users from a group that resides in Active Directory

  • Read Active Directory and make changes on workstations

  • Use a Lightweight Directory Access Protocol (LDAP) provider

  • Make an ActiveX Data Objects (ADO) connection

  • Execute an ADO command

  • Use While Not...Wend to iterate through the record set

  • Use WMI to make changes on desktop machines

Making the Connection

When creating a script with multiple parts or multiple actions, taking a systematic approach vastly simplifies the process. The script you will examine in this chapter has five major components. You will test each portion of the script after you write it to ensure it is working properly. Next, you will need to test the query syntax to ensure it is returning only the machines you want to modify. Once you have the query working properly, you will want to test the WMI portion of the script to ensure it works as planned. Finally, you will put the entire script together.

The following script is called ConnectToADOU.vbs, and it connects to Active Directory using the LDAP provider, makes an ADO connection, and executes an ADO command. Finally, it uses While Not...Wend to iterate through the returned record set. It does not use WMI at this point.

Note

To run the ConnectToADOU.vbs script, you need to have access to an Active Directory controller. You also need to ensure that you modify the oDom and the oOU variables to accurately reflect your environment.


ConnectToADOU.vbs

Option Explicit
'On Error Resume Next

Dim qQuery
Dim oConnection
Dim oCommand
Dim oRecordSet
Dim oDom
Dim oProvider
Dim oOU

oProvider = "'LDAP://"
oDom = "dc=nwtraders, dc=msft'"
oOU = "ou=mred,"
qQuery = "Select Name from " & oProvider _
& oOU & oDom & "where objectClass='computer'"

Set oConnection = CreateObject("ADODB.Connection")
Set oCommand = CreateObject("ADODB.Command")
oConnection.Open "Provider=ADsDSOObject;"
oCommand.ActiveConnection = oConnection
oCommand.CommandText = qQuery
Set oRecordSet = oCommand.Execute

While Not oRecordSet.EOF
    Wscript.Echo oRecordSet.Fields("name")
    oRecordSet.MoveNext
Wend

oConnection.Close

Header Information

The Header information section of the script continues to be rather uninteresting. However, you shouldn't ignore it just because it is boring. Remember, when we use Option Explicit, we must declare all our variables. Because all the variables get listed out, Option Explicit provides a good place to document their use. By documenting the use of every variable, you perform two functions: provide a reference for future modifications and provide a reference for others who might read the script at a point later in time. I will admit that in the past, I did not document some scripts because at the time I understood what the script was doing. However, later, when I had to modify the script, I had to conduct a lot of additional research to figure out what I had done. The time to add documentation to a script is when you write it, not months later. Additionally, it makes sense to document the changes you make when you modify the script. This can take the form of comments with an associated date, and you can easily incorporate these comments into a script template, as shown in the following code section:

'================================================
'
' VBScript: AUTHOR: Ed Wilson , MS, 11/09/2003
'
' NAME: <ConnectToADOU.vbs>
'
' COMMENT: Key concepts are listed below:
'1. making connection to AD
'2. Controlling results by using a filter
' REVISIONS:
' 11/10/2003 connection string - split into parts
' 11/11/2003 added computer filter to query
' 11/12/2003 changed names of vars from obj to o
'================================================

The standard header information is placed just below the template section, as shown here:

Option Explicit
On Error Resume Next

Dim qQuery
Dim oConnection
Dim oCommand
Dim oRecordSet
Dim oDom
Dim oProvider
Dim oOU

Reference Information

The Reference information section of the script is used to assign specific values to variables used in the script. One advantage of breaking the connection string into multiple parts is that the connection is easier to read and understand, and it also provides additional flexibility because of the ease of supplying different variables. The one issue to keep in mind when breaking up connection strings is that when the variables are concatenated back together, these variables must supply exactly what Microsoft Visual Basic, Scripting Edition (VBScript) is expecting.

Tip

I often find myself having to use the WScript.Echo command to list out my connection string or my query after it has been put back together. More often than not, I find I've left out a semicolon, comma, or quotation mark that VBScript was expecting. This is where echoing out the query is invaluable. It takes one second to echo something out, whereas it could take hours of staring, visualizing, and imagining what the query or connection string looks like when put back together.


The variable oProvider is assigned to the string 'LDAP://' and is used to tell VBScript you will be talking via LDAP to Active Directory. You use oDom to hold the domain components of the connection string. Using normal LDAP language, each part of the domain name is specified: Dc=nwtraders, dc=msft. In this example, you don't use a .com, .net, or .org upper-level domain name; you use the .msft imaginary name. The next variable you define is oOU, which you set equal to the workstations' OU. After assigning values to the provider, domain, and OU variables, you're ready to create the query. You use the qQuery variable to hold your constructed query. Notice that the syntax looks similar to a Structured Query Language (SQL) query. You are selecting the name field from 'LDAP://ou=mred, dc=nwtraders, dc=msft', but you want only the name field if the object class is a computer. So you specify that in the Where clause of the query.

oProvider = "'LDAP://"
oDom = "dc=nwtraders, dc=msft'"
oOU = "ou=mred,"
qQuery = "Select Name from " & oProvider _
& oOU & oDom & "where objectClass='computer'"

Worker and Output Information

The next six lines of the script make an ADO connection to Active Directory. You use oConnection to hold the ADODB connection object that comes back from using the CreateObject command to give you an ADODB connection. Next, you use oCommand to hold the command object that comes back from using the CreateObject command to give us an ADODB command object. If the previous sentence seems redundant, that's because it is. This is one of the features of ADO, in fact! To reduce the learning curve, the developers tried very hard to make the syntax similar. Once you have the connection object and the command object, you can move forward with making the connection into Active Directory. You can think of building the ADO connection into Active Directory as connecting pipes. The provider is the kind of pipe you are going to run, the connection object is the path you are going to take while running the pipes, and the command is the valve that controls the flow of data through the pipes. Just as pipes are run one stick at a time, so too is each piece necessary to connect to Active Directory placed one at a time.

Now it's time to open the valve, but just like a water valve in your house, you need to know which valve to open and how far to turn the valve. With ADO, you specify the provider (that is, which pipe), which in this case is ADsDSOObject, and you specify which connection is the active connection. Next, you specify the command text, which is your qQuery (indicates how far you will open the valve). Once everything is lined up, you execute (open the valve). But wait! At home, you need a glass or a bucket to hold the water. With ADO, you need something to hold your data flowin this script, you use the variable called oRecordSet to hold the data that comes back.

Iterate through the record set that comes back from the qQuery. To do this, you use a While Not...Wend statement. Because you don't know in advance how many computers are in the workstation OU, you return a set of records from Active Directory and work through each record in the set until you reach the end of the file, which is designated as oRecordSet.EOF. As long as the record set has records you haven't touched, you echo out the name of the record and then move to the next record in the set. If you come to the end of the record set, you end the While Not...Wend statement. You are using the Echo command right now as a test mechanism. In the script, right now, the Echo command is the Output section of the script. After you make sure the script works as planned, you replace the Echo command with some WMI code to change the Transmission Control Protocol/Internet Protocol (TCP/IP) address from static to dynamic.

Set oConnection = CreateObject("ADODB.Connection")
Set oCommand = CreateObject("ADODB.Command")
oConnection.Open "Provider=ADsDSOObject;"
oCommand.ActiveConnection = oConnection
oCommand.CommandText = qQuery
Set oRecordSet = oCommand.Execute

While Not oRecordSet.EOF
    WScript.Echo oRecordSet.Fields("name")
    oRecordSet.MoveNext
Wend

oConnection.Close

Quick Check

Q.

What is an advantage of using WScript.Echo to display the text of a query?

A.

An advantage of using WScript.Echo to display the text of a query is that it makes troubleshooting a concatenated query string easy.

Q.

Why do you need to use While Not in the Worker information section of the script?

A.

While Not is used to iterate through the record set. It gives you the ability to work with an unknown number of computers.



Previous Page
Next Page