Udostępnij za pośrednictwem

Introduction to WMI

  • Artykuł

I have been thinking of writing a few blog posts on leveraging some useful WMI classes through PowerShell. Before moving into those examples, I thought it would be better to create a blog post on essential cmdlets in WMI so that I can ask you to refer to this post while discussing examples.

In this blog post, we will focus on Get-WMIObject, Invoke-WMIMethod and [WMIClass] type accelerator.

Lets start with Get-WMIObject first. Get-WMIObject is used to create instances of WMI classes. Using this cmdlet, we can create objects of WMI classes and start using members (methods and properties) of the WMI objects.

Example, lets create an instance of win32_process class. Once you do a Get-Member on that object, you will get a list of instance members you can access on that object. Also, if you refer to the example below, you will see that the Type of the object  is System.Management.ManagementObject. In other words, we created an "object" of win32_process WMI class. All the members are instance members and we can access them using the win32_process object e.g. $procObj.ProcessName.

 

Now lets look at [WMIClass]. [WMIClass] is a type accelerator for creating ManagementClass. What's the need of referring to a class? In WMI, there are instance members and static members. Static members are accessed on the class itself. So, if you want to access any static members of a WMI class you could use the WMIClass type accelerator. In the example below, you can see that [WMIClass] creates a System.Management.ManagementClass type. Apart from that, also notice that this time the members which you see are static members of the win32_process class. Now we can call the Create static method by using $processClass.Create, because $processClass is a class and static members can be referred to on a class. That is, we can say:

$processClass.Create("notepad.exe").

 

Now lets look at a different way of referencing a WMI class - using Get-WMIObject cmdlet. Along with creating instance of a WMI class, the Get-WMIObject cmdlet can also used for listing the WMI classes using the -list parameter. Once we have that list, we can filter any of the specific classes we want through this list. That selected class would be our reference of a WMI class. Lets look at an example of that:

So you will notice that the class type is same as the type name generated by the [WMIClass] type accelerator. There is a huge advantage in using this method over [WMIClass] and we will look into this when we discuss different examples of WMI (Hint: Think Remoting to different machines).

Now we can use the Static method "Create" of the Win32_Process class using the class reference $procClass:

 

That's one way of calling static members of a WMI class. However, PowerShell also gives you a cmdlet of calling methods of WMI classes, and the cmdlet is Invoke-WMIMethod. Following example shows use of Invoke-WMIMethod:

We provide the WMI class name to -Class parameter, method name to -Name parameter and parameters for the method to the -ArgumentList parameter. It also has a parameter which may be of amazing interest to you -ComputerName.  Using this cmdlet, you can run methods on remote machines as well.

Hopefully, this article gave you a good overview of different ways of interacting with WMI classes. There are other WMI type accelerators as well, such as [WMISearcher], but we should be good to start interacting with WMI with an understanding of what we discussed in this blog. Again, I will refer you to this post, when needed, while discussing about different WMI classes.

Comments

  • Anonymous
    September 15, 2012
    Excellent article about a topic which seems to be confidential. What i reproach to the WMI classes documentation is that it seems not updatable. I have posted several feedbacks to obtain updated or more precise informations in this documentation but no answer,no feedback. I am using frequently Win_Process,Win32_OperatingSystem and Win32_ComputerSystem classes (mainly) in my own applications for several OS ( since XP Pro upto Windows 7 ) . It is why this post is so interesting for me and i am waiting impatiently for its " small brothers" ( maybe a bad translation , a better one following ones ) You are on the good road