Summary: Microsoft Scripting Guy, Ed Wilson, talks about when to use WMI. Microsoft Scripting Guy, Ed Wilson, is here. One of the things that Windows PowerShell has done is make 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 taught WMI classes, I would say, “The only thing consistent about WMI is that it is inconsistent.” Although 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. Historically, some of the tasks that required using WMI on local or remote computers are:

• Working with the registry
• Working with processes 
• Working with services 
• Performing hardware inventory 
• Working with files and folders 
• Working with event logs 

Beginning with Windows PowerShell 2.0, you can perform these tasks (except for a hardware inventory) by using Windows PowerShell. There is no need to use WMI to work with files, folders, event logs, the registry, processes and services—either locally or remotely.

Note  There are still some things related to these topics that require WMI, but most of the main tasks related to these topics can be performed without using WMI. Beginning with Windows PowerShell 3.0 in Windows 8 and Windows Server 2012, many of the hardware-related tasks (such as inventorying hard disks and network adapters) no longer require complex WMI queries.

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 opening a 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