Summary: Microsoft Scripting Guy, Ed Wilson, talks about querying WMI in this excerpt of his book, Windows PowerShell 3.0 First Steps.
Microsoft Scripting Guy, Ed Wilson, is here. Today I have the last excerpt from my new Microsoft Press book, Windows PowerShell 3.0 First Steps.
In most situations, when you use WMI, you are performing some sort of query. Even when you are going to set a particular property, you still need to execute a query to return a dataset that enables you to perform the configuration. (A dataset includes the data that come back to you as the result of a query, that is, it is a set of data.) There are several steps involved in performing a basic WMI query:
- Connect to WMI by using the Get-WMIObject cmdlet.
- Specify a valid WMI class name to query.
- Specify a value for the namespace—omit the Namespace parameter to use the default root\cimv2 namespace.
- Specify a value for the ComputerName parameter—omit the ComputerName parameter to use the default value of LocalHost.
Windows PowerShell makes it easy to query WMI. In fact, at its most basic level, the only thing required is gwmi (alias for the Get-WmiObject cmdlet) and the WMI class name. An example of this simple syntax is shown here, along with the associated output:
PS C:\> gwmi win32_bios
SMBIOSBIOSVersion : BAP6710H.86A.0064.2011.0504.1711
Manufacturer : Intel Corp.
Name : BIOS Date: 05/04/11 17:11:33 Ver: 04.06.04
Version : INTEL - 1072009
However, there are more properties available in the Win32_Bios WMI class than the five displayed in the previous output. The reason for the limited output that is displayed from the command is a custom view of the Win32_Bios class defined in the types.ps1xml file that resides in the Windows PowerShell home directory on your system. The following command uses the Select-String cmdlet to search the Types.ps1xml file to see if there is any reference to the WMI class Win32_Bios.
Select-String -Path $pshome\*.ps1xml -SimpleMatch "Win32_Bios"
In the following image, several Select-String commands display results when a special format exists for a particular WMI class. The last query (for the Win32_CurrentTime WMI class) does not return any results, indicating that no special formatting exists for this class.
The Select-String queries shown in the previous image indicate that there is a special formatting for the Win32_Bios, Win32_DesktopMonitor, and Win32_Service WMI classes. The Types.ps1xml file provides information to Windows PowerShell that tells it how to display a particular WMI class. When an instance of the Win32_Bios WMI class appears, Windows PowerShell uses the DefaultDisplayPropertySet configuration to display only five properties. The portion of the Types.ps1xml file that details these five properties is shown here:
The complete type definition for the Win32_Bios WMI classis shown in following image:
Special formatting instructions for the Win32_Bios WMI class indicate that there is an alternate property set available—a property set that is in addition to the DefaultDisplayPropertySet. This additional property set, named PSStatus, contains the four properties in the PropertySet shown here:
Finding the PSStatus property set is more than a simple academic exercise, because it can be used directly with Windows PowerShell cmdlets such as Select-Object (select is an alias), Format-List (fl is an alias), or Format-Table (ft is an alias). The following commands illustrate this technique:
gwmi win32_bios | select psstatus
gwmi win32_bios | fl psstatus
gwmi win32_bios | ft psstatus
Unfortunately, you cannot use the alternate property set, PSStatus, to select the properties via the Property parameter. Therefore, the following command fails.
gwmi win32_bios -Property psstatus
That is all there is to using Windows PowerShell to query WMI. Join me tomorrow when I will have a guest post from Yuri Diogenes, Security Series: Using PowerShell to Enable BYOD—Part 1.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at email@example.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy