Comparing WMI and Native PowerShell


Summary: Microsoft Scripting Guy, Ed Wilson, talks about comparing WMI and using native Windows PowerShell.

Microsoft Scripting Guy, Ed Wilson, is here. When Windows PowerShell was still in beta, there was a saying (song?) that said there must be 50 ways to stop a process. Actually, I am not certain it was ever turned into a Windows PowerShell song, but it probably could have been. Anyway, the conversation was a reflection of the many ways of doing things that are available in Windows PowerShell…and that was back in the Windows PowerShell 1.0 days. Today, there are even more ways of doing things. So what is the deal?

Well, the overriding principle of Windows PowerShell is to fade into the background and to permit one to work as one wishes to work. That is why one of my pet peeves is when someone says, “That is not a very PowerShell way of doing things.”

To be honest, there is really no specific “PowerShell way” of doing things. Windows PowerShell is a tool that permits one to work the way that one wants to work. Sure, some ways are easier, but if one is already familiar with C++ programing, and one wishes to work with native Win32 APIs, and if it works in Windows PowerShell, then I guess I can say that it is Windows PowerShell.

For one who has not done much C++ programing in over 15 years, that would not be my first choice. In fact, I prefer to do everything the easiest way possible. But then, what is easy is often what one is comfortable with—or what takes the shortest amount of time.

If on the other hand, one has no programing background and has done no scripting previously, or if one is seriously attempting to explore the boundaries of what Windows PowerShell has to offer, then wrestling with native Win32 APIs may not be the fastest way to get things done. (In fact, I would say it probably is not the fastest way…unless you already have a script that does what you need to get done, and if it works perfectly…well, then, maybe.)

Comparing two ways to do the same thing

There are lots of WMI scripts out there. Often when people search around to find a script to solve a problem, they run across a WMI script. OK. Finding a script is often faster and easier than writing a script. But suppose that I do not have a script or that I am in a locked-down environment, and I do not have access to a script. What then? Well, that is where knowing a bit about Windows PowerShell and WMI comes to the rescue.

Processes

One of the first WMI scripts I ever used was one that retrieved information about processes. And as I said, Windows PowerShell made it easy to use WMI. So if I want information about processes, I use the Win32_Process class.

Note  When you are using the Get-CimInstance cmdlet, don’t forget that Tab completion works for WMI class names (in the Windows PowerShell ISE and the Windows PowerShell console).

In Windows PowerShell 1.0, the WMI cmdlet was Get-WmiObject. It was a huge improvement over writing WMI scripts that required lines and lines of often obscure commands. But beginning with Windows PowerShell 3.0, the CIM cmdlets are even a bigger improvement. As shown here, often the change in command is direct substitution:

Get-WmiObject win32_process

Get-CimInstance Win32_Process

But there are other times when there are changes—even in parameter names. For example, Get-WmiObject uses –Class, and Get-CimInstance uses –ClassName. One of the cool things is the way Get-CimInstance formats the output. Here is the output from Get-WmiObject:

Image of command output

Here is the output from Get-CimInstance:

Image of command output

If I want to find out information about a Notepad process, I need to create a filter. This is shown here:

PS C:\> Get-CimInstance Win32_Process -Filter "name = 'notepad.exe'"

ProcessId          Name            HandleCount       WorkingSetSize    VirtualSize

---------               ----                 -----------             --------------         -----------

5280               notepad.exe            91                    6905856           2199127113728

If I want to use a native Windows PowerShell command to find out information about Notepad, I can use the Get-Process cmdlet. This is shown here:

PS C:\> Get-Process -Name notepad

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)        Id      ProcessName

-------        ------        -----        -----     -----      ------        --        -----------

     91           8          1620          6744       99       0.02         5280       notepad

The commands appear here:

Get-Process -Name notepad

Get-CimInstance Win32_Process -Filter "name = 'notepad.exe'"

So, the native Windows PowerShell command appears to be a bit easier to use and understand. And the output is similar.

So there is a bit about comparing WMI and Windows PowerShell. WMI Week will continue tomorrow when I will talk about more cool Windows PowerShell stuff.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy 

Comments (0)

Skip to main content