Summary: Microsoft Scripting Guy, Ed Wilson, talks about when to use WMI and when not to use it.
Microsoft Scripting Guy, Ed Wilson, is here. One of the things that Windows PowerShell has done is to make Windows Management Instrumentation (WMI) very easy to use. Beginning with Windows PowerShell 1.0 and the Get-WmiObject cmdlet, WMI information has become much easier to access. Whereas a simple VBScript script or Perl script would require a minimum of seven lines of rather complicated code to access WMI information, Windows PowerShell made the same information available as a one-liner. Truly a marvelous win for IT Pros!
But one problem remains. WMI, even in Windows PowerShell, can be complicated and inconsistent. In fact, when I used to teach WMI classes, I would say “The only thing consistent about WMI is that it is inconsistent.” While that is a bit of an overstatement, anyone who spends much time working with WMI, also spends a lot of time researching anomalies on MSDN, the Microsoft Developer Network.
Historically, some of the tasks that required using WMI are shown here:
- Working with the registry on local or remote computers
- Working with processes on local or remote computers
- Working with services on local or remote computers
- Performing hardware inventory on local or remote computers
- Working with files and folders on local or remote computers
- Working with event logs on local or remote computers
Beginning with Windows PowerShell 2.0, you could perform these tasks, except for hardware inventory, by using Windows PowerShell alone. There is no need to use WMI to work with files, folders, event logs, the registry, processes and services—either locally or remotely.
Note To clarify, there are still some things related to these topics that will require WMI, but most of the main tasks related to these topics can be performed without WMI.
Beginning with Windows PowerShell 3.0 on Windows 8 and Windows Server 2012, many of the hardware-related tasks, such as inventorying hard disks, network adapters, and the like, no longer require complex WMI queries either.
Note The underlying technology is still WMI, but the classes are basically wrapped and exposed as functions that behave like Windows PowerShell cmdlets.
So, what is the best way to use WMI? Avoid using WMI at all. If I can use a Windows PowerShell command such as:
Get-NetAdapter
instead of typing:
Get-WmiObject Win32_NetworkAdapter
-or-
Get-CimInstance Win32_NetworkAdapter
then, of course, I want to use the Windows PowerShell command.
The other thing that is great about using the Get-NetAdapter cmdlet is that it uses CIM, which uses Windows PowerShell remoting instead of remote procedure call (RPC). This means that I can query for network adapter information from a remote computer through one port in the firewall, instead of having to open a whole bunch of ports in the firewall. The other advantage is that it is much faster.
This week I will talk about when to use Windows PowerShell and when I still have to use WMI. It will be fun.
That is all there is to using Windows PowerShell to find WMI stuff. WMI week will continue tomorrow when I will talk about more cool 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