System Inventory Mini-App

Executive Summary:

I started a system inventory script a while ago that uses some very basic Windows Management Instrumentation (WMI) Win32 classes, and it's grown steadily since then as other needs arose and I discovered more properties of interest. SysInfo.hta is WMI "to the max” and is a type of tool that virtually all systems administrators need in their toolkit. I use the script primarily to generate computer build documentation when a new server goes into production, and from time to time when I need to check out the health and current state of a server or desktop.

Because I gather virtually every property that's available within several WMI Win32 classes, the code is lengthy. But don’t let the size concern you: If you open the SysInfo.hta HTML Application (HTA) file in a text editor such as Notepad and look through the code, you’ll see that each class property has a line of code associated with it for use as a header, so almost half the code is nothing more than Excel worksheet column heads. Further, each class is in its own subroutine, meaning you can easily locate a specific routine and the code for a particular class should you want to analyze the code or make changes.

In addition to describing a quick and easy method of collecting data from local and remote computers, this article and the HTA introduces you to some new WMI properties that were made available with the release of Windows Vista and lays the groundwork for an upcoming article that uses this code in a Vista Sidebar gadget. For those who might have tried running the HTA before reading this article and were wondering why the application window is such a tiny little thing, the reason is that I developed the HTA not only to run on its own but as part of a mini-app that could be used as a Vista Sidebar gadget. However, Vista isn't required to run this application, and if you run it on another OS such as Windows Server 2003, Windows XP, or Windows Server 2000, the new Vista-exclusive properties will simply have no values under their property headings.

You can download SysInfo.hta by clicking the Download the Code Here button at the top of the article. Before you use the HTA, it's helpful to know about the input you need to provide, the output you'll receive, the code behind the HTA, and some of the new WMI properties that it includes.

Input and Output
Even though the HTA application window is small, it has a clean look and feel. I can easily leave open on my XP machine because it doesn’t use a lot of desktop real estate. Figure 1 shows what you’ll see when you run the application.

Despite its length, SysInfo.hta is a rather bare-bones tool that doesn't contain any bells or whistles. There’s no F1 Help functionality and no error trapping. Its purpose is to demonstrate a method of retrieving a lot of information from a local or remote computer and to point out some of Vista's new WMI properties. But even as a bare-bones app, it produces essential and useful information and documentation for a computer.

To use SysInfo.hta, you can simply leave everything blank and click Go to gather information for the local computer. To gather information for a remote computer to which you have administrative rights, type a computer name or IP address into the System Inventory Server Name box and click Go. If you need to specify alternative credentials, just type your DomainAdmin ID in the AdminID box and the password for that ID in the Password box before you click Go.

The values that you enter are stored as variables and used to make the WMI connection. When you enter a password, you’ll notice that it isn't exposed as plain text. This is one of the nice, simple-to-use security features available to you when you use HTAs to develop interactive administrative scripts.

After you click Go, the HTA retrieves computer information on the following Win32 WMI classes:

As you can see, this script collects a lot of information, and I’ve chosen to use Microsoft Excel as the script's reporting medium. To the best of my knowledge, any relatively recent version of Excel will work just fine. I've tested the script on Microsoft Office 2007/XP/2003/2000 versions of Excel.

The Excel output is conveniently arranged so that each class is in its own worksheet. If you need to focus on a specific class, simply click the appropriate worksheet tab.

After you run SysInfo.hta, you might notice that the value returned for a few properties is simply a number or code value rather than a descriptive value. For many of the properties that I often use, I've taken the time to write functions that convert the return codes into more useful and meaningful information. However, I've left several of the return codes as is—some because of the enormous number of possible return value codes, some because it was more beneficial to look up the meaning of the values rather than rely on a heading, and others because I just didn’t see the need to elaborate. With that said, you might wonder why I included such properties in the output. The answer is simply because it was easier to include all the property values, knowing that I could later comment out or remove those I didn’t want.

The Code Behind the HTA
The script, albeit large, is really quite simple. When you enter a computer name or IP address, the script connects to that machine and collects WMI data using a subroutine call to each of the Win32 classes that I listed earlier. Each subroutine creates an Excel worksheet for its particular class, writes headings for each property of that class, then gathers the WMI property values from the target machine and writes them under the appropriate headings.

You can easily exclude one or more subroutines from your output if you want to. Maybe you want just processor info and a summary, or just information about services that are running on a particular machine. To limit what goes into the report, just comment out the subroutine calls for the classes that you don’t want. When you narrow down the number of classes you go after, not only do you get just what you’re looking for, but also the script runs much faster. (It’s worth noting that some of the classes, such as Win32_Product and Win32_Service, tend to take a bit longer to complete than others.)

Listing 1 shows the code for one of the subroutines, all of which work in a similar fashion. Keep in mind that the connection to the local or remote machine has already been made as each Win32 subroutine runs. Each routine starts with On Error Resume Next so that if it hits a property that isn’t available (e.g., a new Vista property), the program continues without a problem. Then a simple line of code such as

XL.Sheets.Add.name = "ComputerSystem" 

adds a worksheet to the Excel spreadsheet for the class being queried—in this case, the ComputerSystem class. The next step is to collect the information for the class. For the ComputerSystem example, the routine uses the code

Set colItems = objWMIService.ExecQuery _ ("Select * from Win32_ComputerSystem") 

to query the computersystem class.

As you can see in Listing 1, two big chunks of code follow. The first chunk adds the headers of the computersystem class to the worksheet, and the second writes the win32_computersystem collection of data to the spreadsheet. Notice that the second section is in a For Next loop, which steps through the entire win32_computersystem collection for the machine that’s being queried. Also notice that in both these big chunks of code, the column number (Col) is incremented after each property and a heading is written. In callout A at the end of the subroutine, the line of code

XL.Cells.EntireColumn.AutoFit 

touches up the worksheet so that the columns are expanded. I also use the line

XL.ActiveWindow.FreezePanes = True 

to keep the headers visible should you scroll down.

Virtually all the other subroutines use the same process. The functions that the subroutines use are near the end of SysInfo.hta.

The script also creates a separate Summary worksheet for each machine from which you've collected data. The Summary subroutine, which you can see in Listing 2, simply pulls specific property data from selected classes to compile a sort of quick reference for each computer. The Summary worksheet includes column headings such as SerialNumber, AdapterDescription, DNSDomain, IPAddress, ClockSpeed, Processor, TotalPhysicalMemory MB, and Disk Space GB.

The Newest WMI Properties
Because you're probably familiar with most of the properties of the 15 WMI classes from which the HTA collects data, I won't cover them here. (Those who are unfamiliar with those classes' properties can find detailed information about them on the Microsoft Developer Network. A good starting point is the Win32 Classes Web page, http://msdn2.microsoft.com/en-us/library/aa394084.aspx.) Instead, I’d like to introduce you to some of the new WMI properties that are available through Vista, specifically for the Win32_CDROMDrive (http://msdn2.microsoft.com/en-us/library/aa394081.aspx), Win32_DiskDrive (http://msdn2.microsoft.com/en-us/library/aa394132.aspx), Win32_ComputerSystem (http://msdn2.microsoft.com/en-us/library/aa394102.aspx), and Win32_Processor (http://msdn2.microsoft.com/en-us/library/aa394373.aspx) WMI classes.

There are two new properties in the Win32_CDROMDrive class: MfrAssignedRevisionLevel and SerialNumber. MfrAssignedRevisionLevel reveals the manufacturer-assigned firmware revision level of the computer's CD-ROM drive. Having this information available is helpful if you need to call techical support regarding your CD-ROM drive. The SerialNumber property is just what it says: the manufacturer-supplied serial number for the drive. As a point of interest, on the Windows Vista Home Premium Dell laptop I use, the MfrAssignedRevisionLevel property returned a value but the SerialNumber property did not. Also, some property fields refer to the actual CD or DVD that’s in the drive, so when a disc is in the drive, more of the spreadsheet fields will be populated.

The new properties of the Win32_DiskDrive class are FirmwareRevision and SerialNumber. In this case, the FirmwareRevision property returns the manufacturer-assigned disk-drive firmware revision number and the SerialNumber propery provides the disk drive's serial number. Both properties returned values for my laptop and could prove useful when you're troubleshooting a disk drive problem or in the event of a disk-drive recall.

PCSystemType and NumberOfLogicalProcessors are new properties of Vista's Win32_ComputerSystem class. PCSystemType is especially nice: It reveals the type of computer that’s in use (e.g., laptop, desktop, server). However, the property's return value is numeric and needs to be converted if you want to see a more meaningful value. The possible values and their meanings are as follows:

SysInfo.hta's PcsysType function returns the descriptive values listed above instead of the numeric property value. (PcsysType is one of several functions that SysInfo.hta uses to convert codes to descriptive values.)

The other new property in the Win32_ComputerSystem class is the long-awaited NumberOfLogicalProcessors, which tells you how many logical processors the computer has rather than the number of physical processors. Using Intel's Hyper-Threading Technology, some processors nowadays can make a physical processor function as if it were actually two or more processors. In pre-Vista versions of Windows, WMI could report only the total number of processors, which included both physical and logical processors. If a server utilized Hyper-Threading and had two physical processors, each of which had two logical processors, WMI would indicate that the server had four processors, making the report misleading. With Vista, if you use the NumberOfProcessors property to return the number of physical processors, you can determine whether the computer is Hyper-Threading by querying the NumberOfLogicalProcessors property.

Multicore processors further complicate determining how many processors a system has. Multicore processors are physical processors that have multiple computational "cores," each of which can have multiple logical processors. If a server has one physical processor with two cores and each core has two logical processors, that server has four logical processors. So now you might need to figure out how many cores a processor has.

New properties of the Win32_Processor class can help you obtain this information. This class now has a NumberOfLogicalProcessors property (which is identical to the NumberOfLogicalProcessors property in the Win32_ComputerSystem class) and a new property called NumberOfCores, which tells you whether the processors are multicore. Using a simple script such as VistaWMIProcessorInfo.vbs, which Listing 3 shows, you can get more accurate processor information for Vista machines. VistaWMIProcessorInfo.vbs obtains the number of physical processors on the computer, a description of the processor (e.g., Intel® Core2 Duo CPU T7300 @ 2.00GHZ), the number of logical processors, and the number of cores each physical processor has.

There are also two other new properties in the Win32_Processor class: L3CacheSize and L3CacheSpeed. Like the L2 cache, the L3 processor cache is an external memory area that can be accessed faster than RAM. The cache size is represented in kilobytes and the cache speed is in megahertz.

Stay Tuned for More
I've incorporated all of Vista's new WMI properties in the SysInfo mini-app. You'll find them conveniently placed at the end of the associated class listing in the code and at the end of each worksheet. If you run this mini-app on a Vista machine, you should see values for most all the new properties. If you don’t have Vista, the script runs without error and the fields for the new properties are blank.

I hope you find this mini-app useful. I also hope you’ll return to Scripting Pro VIP soon to check out my next article, which will show you how to make SysInfo.hta into a Vista Sidebar gadget.