POLL: POWERSHELL VS. GUI - DO YOU WANT TO BE A DEVOP OR AN ADMIN?

WBEMTest – Part 2: WMI queries

In the first part of the series we looked at using a utility called WBEMTest that is included with Microsoft Windows, to validate WMI connectivity and credentials with a remote machine. In this article I want to look at using WBEMTest to validate WMI queries.

WBEMTest

1. WBEMTest – Part 1: Testing WMI connectivity
2. WBEMTest – Part 2: WMI queries
3. WBEMTest – Part 3: Tips and tricks

Creating a basic query

If all goes well you should get the menu below which shows that I am connected to the Root\Cimv2 namespace on computer NOVO8.

WBEMTest – Start query

Now to test my query. Click the Query button. In the query field enter your WMI query.

WBEMTest – Query

Click Apply. Depending on your query, it may take a few minutes but you should get results like in the screenshot below:

WBEMTest – Query result

If your query returns multiple instances it will look like this:

WBEMTest – Query result with multiple instances

Of course, if your query is invalid WBEMTest will tell you.

WBEMTest – Error 0×8004107 – Invalid query

Even though there is a button for more information I’ve never been able to find out what in particular is bad about my query. But if it doesn’t work here, it won’t work in PowerShell or anywhere else. If you use an invalid class that error is more meaningful.

WBEMTest – Error 0×80041010 – Invalid class

Query results

But let’s assume the query returned multiple instances. Double-click on any entry and you should get this output:

WBEMTest – Hide System Properties

It’s too bad the window can’t be re-sized. One step I usually take is to hide all of the WMI system properties like __GENUS. I rarely need them so check the Hide System Properties box. Now I can see the class property names and values.

WBEMTest – Class property names and values

Creating a complex query

This is very useful because now I can build a more advanced WMI query. In looking at the service instance I can see what properties and values to use in a query that will get all services that are set to auto start but are not running. As you see in the next screenshot I can try out a new query.

WBEMTest – Complex query

By the way, at any point along the way you can close WBEMTest windows you no longer need. When I run this query I get a new set of results:

WBEMTest – Complex query result

Excellent. I’ve now verified a WMI query. I can go back to the Query window in WBEMTest and copy the query. In PowerShell I can paste it in my script or command.

PS C:\> get-wmiobject -query "select * from win32_service where startmode='auto' AND state='stopped'" -computer Novo8

Or I can re-format it now that I know the filter is valid. Remember, WMI queries use the legacy operators.

PS C:\> get-wmiobject win32_service -filter "startmode='auto' AND state='stopped'" -computer Novo8

If I try this against another remote and it fails, I’ll know it’s not my query and can use WBEMTest to verify connectivity.

Summary

WBEMTest is a handy utility for testing your WMI queries and exploring the results. If you can’t get your query to work in WBEMTest it will never work in PowerShell, or whatever language or tool you are using. Many people struggle with Get-WMIObject when the real problem is that they don’t know enough about the WMI class and instances that they are trying to query. There are other 3^rd party WMI explorers, many of them free so don’t feel this is your only choice. But WBEMTest is installed everywhere and is easy to use once you get the basics down. Next time, I’ll show you some other fun things you can do with WBEMTest.

Series Navigation

WBEMTest – Part 1: Testing WMI connectivity - WBEMTest – Part 3: Tips and tricks