Using the Get-WMiObject Cmdlet

Retrieving Data Using WMI

At this point in time there are only a few cmdlets (Get-Process, Get-Service, and Get-EventLog) designed for carrying out system administration tasks. Because of that, WMI remains the primary automation technology for system administration, so system administrators will likely rely heavily on Get-WmiObject to help them with their routine management tasks.

And there’s an added bonus, too: unlike most cmdlets, Get-WmiObject can be run against remote computers. That means you really can use Windows PowerShell as a management tool.

By default, Get-WmiObject binds to the root\cimv2 namespace on the local computer, making it extremely easy to return property values for any class found in cimv2. For example, suppose you need information from the Win32_BIOS class. OK:

Get-WmiObject win32_bios

You get the idea: just call Get-WmiObject followed by the class name. Ah, you say, but what if that class is located on a remote computer? No problem; just add the -computername parameter followed by - you guessed it - the name of the remote computer (atl-fs-01):

Get-WmiObject win32_bios -computername atl-fs-01

Still not convinced? Good point: we did say that, by default, Get-WmiObject connects to the root\cimv2 namespace. Is there any way to connect to a class found in a different namespace? Of course there is: just include the -namespace parameter followed by the complete namespace path (e.g., root\ccm, not just ccm). For example, this command returns information from the SMS_Client class, which resides in the root\ccm namespace:

Get-WmiObject -namespace root\ccm -class sms_client -computername atl-fs-01

It should go without saying that you can use other cmdlets in conjunction with Get-WmiObject (although we seem to have said it anyway). For example, this command retrieves information from the CCM_InstalledComponent class on the remote computer atl-fs-01. The command then pipes that data to Select-Object, which filters out all properties except three: DisplayName, Name, and Version. In turn, that filtered data is passed to Sort-Object, which sorts the information by DisplayName. Here’s what the command looks like:

get-wmiobject -namespace root\ccm -class ccm_installedcomponent -computername atl-fs-01 | Select-Object displayname,name,version | Sort-Object displayname

And here’s the kind of data you get back:

displayname                name                       version
-----------                ----                       -------
CCM Framework              CcmFramework               2.50.4160.2000
CCM Policy Agent           CcmPolicyAgent             2.50.4160.2000
CCM Status Agent           CcmStatusAgent             2.50.4160.2000
SMS Client Core Components SmsClient                  2.50.4160.2000
SMS Inventory Agent        SmsInventory               2.50.4160.2000
SMS Remote Control Agent   SmsRemoteTools             2.50.4160.2000
SMS Shared Components      SmsCommon                  2.50.4160.2000
SMS Software Distributi... SmsSoftwareDistribution    2.50.4160.2000
SMS Software Metering A... SmsSoftwareMetering        2.50.4160.2000
SMS Software Update Agent  SmsSoftwareUpdate          2.50.4160.2000
SMS Source List Update ... SmsSourceUpdateAgent       2.50.4160.2000

On the other hand, there will likely be times when you don’t want a filtered set of properties and their values; instead, you’d just like to see everything Win32_BIOS has to offer. To ensure that you get back information on all the properties (and their values) your best bet is to pipe the data returned by Get-WmiObject to Select-Object, then use the wildcard character * to indicate that you want back all the property values:

Set-WmiObject win32_bios | Select-Object *

If you don’t want all the system properties (like __SUPERCLASS and __RELPATH) then add the -excludeproperty parameter and use the wildcard character to filter out any properties whose name begins with an underscore character:

Get-WmiObject win32_bios | Select-Object -excludeproperty "_*"

Bonus tip. WMI itself is actually pretty easy to use; what isn’t always so easy is figuring out the properties and methods for a specific WMI class. Check that: that’s what used to be difficult. With Windows PowerShell you can simply use Get-WmiObject to connect to the class in question (for example, Win32_BIOS), and then pipe that information through the Get-Member cmdlet:

Get-WmiObject win32_bios | get-member

And what will that do for you? That will show you the properties and methods of Win32_BIOS, including:

BiosCharacteristics       Property              System.UInt16[] BiosCharacte...
BIOSVersion               Property              System.String[] BIOSVersion ...
BuildNumber               Property              System.String BuildNumber {g...

Etc.

Get-WmiObject Aliases
  • gwmi