{"id":7651,"date":"2015-02-24T00:01:00","date_gmt":"2015-02-24T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2015\/02\/24\/when-to-use-wmi-and-powershell\/"},"modified":"2019-02-18T10:30:30","modified_gmt":"2019-02-18T17:30:30","slug":"when-to-use-wmi-and-powershell","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/when-to-use-wmi-and-powershell\/","title":{"rendered":"When to Use WMI and PowerShell"},"content":{"rendered":"

Summary<\/b>: Microsoft Scripting Guy, Ed Wilson, talks about when to use WMI.<\/span>\nMicrosoft 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 <\/span>Get-WmiObject<\/b> 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!<\/span>\nBut 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.\nHistorically, some of the tasks that required using WMI on local or remote computers <\/span>are:<\/p>\n