WMI

Using Vbscript to gather server performance counter data with WMI

In my last entry I shared with you how to use WMI in Vbscript to reboot a server from a scheduled job (either locally or remotely) and I hinted at a scenario where I needed to use this script because a server had a memory leak in an application (Trend Micro OfficeScan 8.0, to be exact). They’ve got a fix out but we just upgraded to 8.0 and apparently that didn’t go well, plus this patch is a server patch that immediately rolls out to the clients– so they are less than willing to jump onto the razor’s edge with a patch. (Politics– We’ve all been there, right?)

 Well, in this entry I’m going to share the function I wrote to pull Poolmemory Non-Paged Bytes from the server using Win32_PerfFormattedData_PerfOS_Memory. I’ll not go into detail about this class and its functions and members here in this posting, but you can find out more details at Microsoft’s MSDN site here. Remember from a previous post (Determining properties and methods used in a WMI object for use in a vbscript), that you can always find out what properties are available by looking at the class definition of these pages.

 The function I wrote pulls the PoolnonpagedBytes property from the Win32_PerfFormattedData_PerfOS_Memory object. This function requires you to pass it the last value of the performance counter. While it doesn’t use it to get the data it does internal to the function compute the delta of the last and the new value– which is handy if your logging and/or monitoring in real time troubleshooting.

The following is a function only, not a complete vbscript to save space and to focus in on this part of the code. For a complete working example script that is tehone I’ve been talking about in the last two posts go here that combines the previous posting’s reboot function, this function, and takes into account the number of times a value can exceed a threshhold during a time frame look here in the vbscript section for “non-paged pool memory“.

Function GetMem(last)
     Set oLoc=CreateObject(”WbemScripting.SWbemLocator”)
     oLoc.Security_.ImpersonationLevel=3
     oLoc.Security_.AuthenticationLevel=WbemAuthenticationLevelImpersonation
     Set owmi=oLoc.ConnectServer(strSrv,”root\cimv2″)
     Set oRef=oWmi.ExecQuery(strQuery)

     For Each detail In oRef
         Newval = detail.PoolNonpagedBytes
         WScript.Echo Newval & vbtab & Newval-last
         getmem = (Newval/1024)/1024
     Next
End Function

Obviously, you have to do some work before you call the function setting up both a variable to recieve the return and also some sort of variable to keep track of the last value. If you aren’t after tracking the changes and only want the return value you can pass any number, including zero, to the fuction and remove the wscript.echo lines in the above code snippet.

Also, since it’s a snippet and as I write this I noticed that you will need some setup in the main routine like:

•  a variable in your main script called strSrv that has the name of the server you want to pull the value of the counter.
•  The following line in the main routine that sets up the “SQL” call for WMI and initializes the value of strQuery. (Btw, for a good back to basics look at SQL calls, check out the SQL Server with Mr. Denny Blog here on ITKE.)

              strQuery=”SELECT * From Win32_PerfFormattedData_PerfOS_Memory”

You can find more performance monitor classes that are available to you here. Basically, if it’s available in perfmon– you can get it with vbscript! Just look for classes named like Win32_PerfFormattedData…. or Win32_PerfRawData…, these classes will get you what you want. Keep in mind that Raw data is just that and most times you are going to want to get PrefFormatted data in the beginning. If you’d like more information on the differences, post a comment and I’ll come back to it later.

Again, this code snippet works perfectly in my original script, but sometimes when you strip a piece of code out of a script it doesn’t work right when you plant it somewhere else. Also, sometimes the formatting of the blog breaks the code if you copy and paste it into your editor. So, if you’d like to not type or troubleshoot any syntax errors due to the copy and paste problems I’ve provided the complete original script code (and this snippet) for download for you from my website’s (www.webstemsadministration.com) File Depot under the Vbscripts and ITKE Blog Scripts category respectively.

Enjoy and happy scripting!

Extra credit: This is double extra credit, I guess, in my last entry I gave you a hint at my last extra credit question in my previous post– I just made the call a different way. The last posting asked you about what this part of the code did:

{impersonationLevel=impersonate,authenticationLevel=Pkt,(Shutdown)}

Does this help give you more information to go on?

Determining properties and methods used in a WMI object for use in a vbscript.

In this entry we’ll take a look at the microsoft documentation for win32_printerdriver and determine how we can determine what values to use to get data once we’ve created a script to get set of data back from a WMI object into a collection object. Most of the previous discussion can be read, in order in my blog but here are links in order, if your just tuning in:

Finding HP Printers using PCL6 Drivers with WMI
Using error control in a vbscript to recover from odd errors
Using Set, GetObject, ExecQuery, and For Next in VBSCRIPT to use WMI objects

Microsoft has a great deal of documentation here on the win32 WMI classes.  However, here is an excerpt from their win32_Printer class. Most of their documentation is written for c/c++ programmers it seems– don’t let that scare you off, you don’t need this code in yours nor do you need c/c++ experience to use them.

Below you see the first line creates a “class” called Win32_PrinterDriver that is of a type called CIM_Service. Essentially, a class contains data and tools you can use in your programs. CIM_Service is just the name of the data type the class is created as– you’ll see references to CIM all over the place with WMI. It stands for Common Information Model, check out the preceding link for more information.

After that, the items in curly braces ( {} ) are the actual names of the properties and what types of data they contain. Again, as long as you are using the data in strictly Vbscript code you don’t even need to know what the type is– VBSCRIPT takes care of that for you. However, on ocassion you’ll see a “type mismacth” error in your code. This is simply referring to the fact that you have put a value in a variable of one type (a string for example) into a variable that is meant to have another type (an integer for example), typically this happens when you use a external component that was written in another language that is more strict about the data types than vbscript, like c, c++, or others. (Which is almost all of them outside of the Visual BASIC family)

class Win32_PrinterDriver : CIM_Service
{
  string Caption;
  string ConfigFile;
  string CreationClassName;
  string DataFile;
  string DefaultDataType;
  string DependentFiles[];
  string Description;
  string DriverPath;
…
};

In the code I wrote for this series I used Wscript.echo to print the data to the screen inside the For Each/Next loop, like so:

Wscript.Echo “DriverPath: ” & objItem.DriverPath

Remember, objitem was a collection of printer driver information objects?
Notice the last part of that line, .DriverPath?
Notice the last line I gave you from the microsoft documentation?

Yeap, they are both DriverPath! There’s a reason… they are the same thing! Essentially, ANY of the items listed in the Win32 classes can de used in conjuction with a collection object– providing you have collected the same type of object with a WMI object before hand! So this documentation is like GOLD for a systems administrator! So, if you didn’t take a hour or 50 before when I gave you the link check it out here again.

For example, I didn’t use the property Version in my original code. If you needed this information in the program you could add another line in the For Each/Next loop to gather that information as well! Like so:

WScript.Echo “Version: ” & objItem.Version

You can do that with any of the properties and methods in the win32_printerdriver class, and it expands beyond that to all of WMI.

One thing to keep in mind with much of WMI is that it is dependent on the driver or hardware manufacturer to provide the information– not all manufacturers provide that information 100% reliably, so you’ll have to play and tweak what your hardware vendor does give you. My bet is even if it’s not 100% of all the information available, it will be more than you had to start with without hours of digging.

So, here is the original code again. Take a few minutes to play around with the code and the win32_printer driver documentation and see what interesting pieces of information you can pull out of WMI.


On Error Resume Next
strComputer = “.”
Set objWMIService = GetObject(”winmgmts:\\” & strComputer & “\root\cimv2″)
Set colItems = objWMIService.ExecQuery(”Select * from Win32_PrinterDriver”,,48)
For Each objItem in colItems
Wscript.Echo “ConfigFile: ” & objItem.ConfigFile
Wscript.Echo “DataFile: ” & objItem.DataFile
Wscript.Echo “DriverPath: ” & objItem.DriverPath
Wscript.Echo “Name: ” & objItem.Name
Wscript.Echo “OEMUrl: ” & objItem.OEMUrl
WScript.Echo “_________________” & vbcrlf
Next

That concludes this series!

 Extra Credit: Can you modify the code above to pull actual printer hardware/software data from Win32_Printer? Hint: stay clear of the properties with a [] after them for now, they will potentially trip you up. And also, remember just because it pulled back one value that was blank doesn’t mean you did something wrong– some items aren’t populated by hardware vendors to WMI unfortunately.