PowerShell is a powerful tool that can be used to manage computer information. It can be used to create and manage scripts, to automate tasks, and to access data from computers. PowerShell is a versatile tool that can be used in many different ways.
WMI and its newer brother CIM can both be used to manage the Windows machines in your environment. But do you know the difference between them? Join us as we take a look.
Be sure to read the previous articles in the series:
Learn How to Automate Windows with PowerShell Learning to Use Cmdlets in PowerShell Learning How to Use Objects in PowerShell Learning Formatting, Filtering and Comparing in PowerShell Learn to Use Remoting in PowerShell
And stay tuned for the rest of the series all week.
Introduction
WMI stands for Windows Management Instrumentation. The word “Instrumentation” refers to the fact that WMI allows you to obtain information about the internal state of your computer, much like the dashboard instruments in your car can retrieve and display information about the state of your cars internal components.
WMI consists of a repository which contains classes that represent components that could be managed within in your machine. By that we mean just because WMI has a Win32_Battery class doesn’t mean that your machine contains a battery. These classes can then be queried for information locally or even across a network using a query language very similar to SQL called WQL. However, WMI has been known to be very unreliable, mostly due to the fact that it’s based on RPC (Remote Procedure Calls), which do some crazy things with the ports they choose to communicate on.
Starting with Windows 8 and Server 2012, WMI is being phased out in favor of the Common Information Model or CIM for short. The only difference between WMI and CIM is the transport protocols they use. While WMI performs queries using Remote Procedure Calls, CIM uses HTTP, which seems to make a huge difference. On the backend they are still talking to the same repository of information.
Using WMI
The quickest and easiest way of exploring the information available to you via WMI is to grab a copy of any free WMI Object Browser. We like this one. Once downloaded, fire it up and you will have a graphical interface to browse the WMI Classes.
If you want to find out something about a computer’s disk configuration, press the Ctrl + F keyboard combination to bring up a search box, then type “logicaldisk” and press enter.
Immediately this will take you to the Win32_LogicalDisk class.
On the bottom half of the application, you can see we have two instances of the class.
Once we have the class we are looking for, querying it from PowerShell is straight forward.
I haven’t seen that syntax for a while with people these days preferring to use the new parameterized syntax.
If you want to get the information from another computer on your network, you can simply use the ComputerName parameter.
Using CIM
Keeping in mind that CIM is only available on Windows 8 and Server 2012, moving forward this is definitely the way to go.
There is also tab completion for the –ClassName parameter when using Get-CimInstance, which shows that going forward this is where Microsoft’s efforts will be focused.
In fact, WMI was developed by a completely separate team within Microsoft, but has subsequently been taken over by the folks in charge of PowerShell. They were the ones who noticed that it is going to be very hard to clean up the mess WMI left behind. In an attempt to remedy the situation, they are trying to make WMI and CIM more available by writing wrapper cmdlets that use WMI and CIM underneath the hood. The only way to check if a cmdlet is a wrapper is by looking at the documentation. For example, the Get-Hotfix cmdlet is a wrapper for the Win32_QuickFixEngineering class, as seen in the documentation.
That means you can get the hotfixes on remote machines using the Get-HotFix cmdlet instead of a WMI Query.
So there you have it. Just remember that if there is a dedicated cmdlet you will always want to use it, followed up by CIM should a cmdlet not exist. Finally, if all else fails, or you have older machines in your environment, you will want to use WMI. That’s all I have for this time. See you tomorrow for more PowerShell fun.
