- 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
List namespaces ^
The namespace that most IS Pros use is root\cimv2. But there are others. We can use WBEMTest to list them. A WMI namespace is just another type of class and we can enumerate them. Click the Enum Instances button that I’ve highlighted in the screenshot.
In the dialog box enter the class name __Namespace as I’ve done in the next screenshot.
Class name __Namespace
Even though there is an option to search recursively, that doesn’t seem to really work in WBEMTest. Clicking OK gives me a result like like in the screenshot below.
Class name __Namespace - Query result
Let’s be clear here: these are only the namspaces under root\cimv2. Depending on your operating system, installed applications or services, there may be many more. To discover them we need to move “up” to the root.
You might think you could go back to the main window and use the Open Namespace button. But this only opens namespaces from the current location. To change to the root click on Connect and in the Namespace field enter Root. Or \\<computername>\root if you want to connect to a remote computer. Now I can repeat the previous step and list all namespaces as you see in the screenshot below.
Class name __Namespace - Query result root
I can double-click any result to examine it further. Although there’s not much to see except the complete path. But that is helpful because I may want to know what classes are in the namespace.
List classes ^
Because I’m already in the root, I should be able to change to a different child namespace by clicking Open Namespace and entering one of the Namespace names.
The main window should reflect the new focus. Now I’ll click on the Enum Classes button which gives me Figure 6.
Enter Superclass name
I don’t have a particular class in mind so I’ll leave it blank and click OK. WBEMTest should go ahead and list all the classes.
You should be able to ignore any of the system classes that start with a double underscore. Here’s the fun part: double click on one of them. The object editor will display the properties for that class.
Now I know the properties names I could use in a WMI query. But wait, there’s more. See that Instances button? Let’s have WMI find all instances of this particular class.
Instances of the AntiSpywareProduct
The screenshot above shows all instances of the AntiSpywareProduct from the root\securitycenter2 namespace. As before, I can double-click on one of the entries to see actual properties and values as in the next screenshot.
Instances of the AntiSpywareProduct - Properties
Now that I know what to look for and where, I can test a query in WBEMTest.
Test a query in WBEMTest
If it works, I can translate it into PowerShell or whatever.
PS Scripts:\> Get-WmiObject -Namespace root\securitycenter2 AntivirusProduct -filter "displayname='Windows Defender'"
Translate into PowerShell
Don’t forget to specify the correct namespace.
If you know the class name you can click Open Class and enter in the class name like AntiVirusProduct or Win32_LogicalDisk to get the class description (see the “Object Editor” screenshot above). Or if you don’t want to query, you can simply ask for all instances of a class by clicking Enum Instances and enter a class name. This will list all the instances just as if you had run a query. If you just want a quick look, this is a fast way to get to the good stuff.
WBEMTest might appear a bit daunting at first. There are many things that you could click and configure, but for the most part you can accept the defaults. This utility cracks opens the hidden world of WMI. I find it the best tool for verifying connectivity and credentials. It is a decent tool for poking around, although it takes a little work and pre-existing knowledge to retrieve information. If you find yourself in WMI a lot, you will want to find some other type of WMI explorer or navigator tool.