Putting It All Together: Your First WMI/ADSI Script

Visual Basic Scripting (VBScript) and Windows Management Instrumentation (WMI) are vital tools for systems administrators grappling with the increasing complexity of Windows technologies. Ready to put them to use? In this sample book chapter, you'll learn the complete design process for an entirely new script.

This chapter is from the book

This chapter is from the book

It's time to leverage what you've learned about ADSI and WMI scripting. In this chapter, I'll walk you through the entire design and creation process for a new script. In addition to
demonstrating a useful new purpose for WMI and ADSI, this chapter will help strengthen your script design skills.

By now, you should have a good idea of what WMI and ADSI can do for you. In this chapter, I'll walk you through the complete design process for an entirely new script. This time,
I'll use both WMI and ADSI in the same script. The script's job will be to check in on every computer in an Active Directory or NT domain and query
some information about its operating systems. I want the script to output this information to a text file on a file server.
The information I want to collect includes operating system version, service pack level, number of processors in the machine,
maximum physical memory in the machine, and so forth. This is a useful way to quickly inventory a network and see what machines
might need to be upgraded before deploying a new application, or to see what machines don't have the latest service pack applied.

Designing the Script

My script is a reasonably complex undertaking, so it helps to break it down into manageable tasks. I need the script to do
three things:

Query a list of computers from the domain.

Query information from each computer.

Write information out to a text file.

The last bit is probably the easiest. I can use the FileSystemObject to open a text file, write information to it, and then
close the text file. Something like the following would work.

For more information on using the FileSystemObject, refer to Chapter 12.

Querying a list of computers from the domain shouldn't be too hard, either. If I want the script to work with both NT and
Active Directory domains, I need to use the WinNT ADSI provider, because only that provider works with both domains. I can query all of the objects in the domain, and then use
an If…Then construct to work with only the computer objects. Code such as the following should do the trick.

Dim oDomain
Set oDomain = GetObject("WinNT://" & sDomain)
Dim oObject, sComputerName, sDetails
For Each oObject In oDomain
'is this object a computer?
If oObject.Class = "Computer" Then
'yes  do something with it
End If
Next

For more information on querying domains by using ADSI, see Chapter 14, and see "Querying Domain Information" in Chapter 15.

Pulling the operating system (OS) information is tougher. WMI seems like the way to go, but WMI has about three gazillion classes. Which one do I need? Fortunately, I have a way to cheat. My primary script editor is Sapien
Technology's PrimalScript 3.0, and it includes a WMI Script Wizard.

A trial version of PrimalScript 3.0 is included on the CD that accompanies this book.

Running the wizard displays the dialog box shown in Figure 20.1. The left side of the dialog box shows a list of every WMI class that my computer knows about. Scrolling through the list, I find that there's a class named Win32_OperatingSystem. That seems like a good place to start.

Figure 20.1. The WMI Wizard starts with a list of all available WMI classes.

Clicking the Win32_OperatingSystem class changes the dialog box to look like the one shown in Figure 20.2. Here, the wizard has filled in a sample script capable of querying information from the selected class. I see things like
service pack level and operating system version, so this is probably the class I want. The wizard offers an Insert button to immediately insert this code into my script, and a Copy button to copy the code to the clipboard. Listing 20.1 shows the complete wizard code.

The wizard's code pulls more information than I want, and it's displaying the information in message boxes, rather than writing
them to a file, but the code makes a great place to start. I can easily modify it to meet my needs.

The script is designed! I identified the three major tasks that the script needs to be able to complete, and I've created
some prototype code that can be adapted to the script's exact requirements. In short, I now know how to do everything I need;
I just need to rearrange it and customize it.

What, No Wizard?

If you're not using PrimalScript, there are some other tools you can use to make WMI scripting easier. In Chapter 18, for example, I introduced Microsoft's Scriptomatic tool, which performs a similar function to the PrimalScript WMI Wizard. You can also dive into the WMI documentation in the MSDN Library (http://msdn.microsoft.com/library), which documents each WMI class and includes some scripting examples.