Latest posts by Jeffery Hicks (see all)
- Clean up user profiles with PowerShell - Mon, Jun 9 2014
- Track user logons with a PowerShell script - Fri, Jun 6 2014
- Configuring logon PowerShell scripts with Group Policy - Tue, Jun 3 2014
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 0x8004107 – 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 0x80041010 – 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.
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 3rd 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.