Welcome to the final post in our Wonderful World of WMI series! So far, you have learned how WMI is organized, how to query it, and how it works with Group Policy. Now, let’s use two great tools to make WMI a bit more user friendly and learn potential pitfalls with WMI.
How to Use the WMI Code Creator
Our first tool makes exploring WMI easier and can even help you write your queries! To start, download the Microsoft Code Creator. Extract the files to an IT share and launch WMICodeCreator.exe. After it loads the WMI classes, select the second drop down menu and start exploring!
Remember our laptop WMI query from the last post? The WMI Code Creator can let you see the query in a GUI format. Select the Win32_Battery class and then choose BatteryStatus as your properties. To see results, press the Search for Property Values button. You should now see your computer’s batterystatus!
On the right hand side, you can see what your WMI query would look like in VB Script. The syntax in the script (Select * From….) shows you how to organize your query. A very similar tool for PowerShell can be downloaded here.
How to Use the WMI Tester to Troubleshoot Group Policy
Need to see if your new WMI query will work? Our second tool allows you to import WMI queries and test them against remote machines! Download the WMI Filter Validation Utility here. It does require you to register first but the this tool is well worth that hassle. This tool will also run from a network share so place it in a UNC and pin an icon to your taskbar.
Launch the tool and press the retrieve button. It will take a second to search the WMIPolicy container in Active Directory and to populate the list of WMI queries. Right click on any query and select validate. Type in the name of a computer and press Validate Now. The wizard will remotely query the machine. When the query completes, you will see if it evaluated as True or False. You will see how long the query took to process. In the picture below, we are testing a filter that checks for a piece of hardware.
WMI Queries and Group Policy Issues
In the screenshot above, you will notice that it took just over a second to process our WMI filter. Potentially, this could be bad. WMI Filters make Group Policy dynamic! You can do some amazing things with it. The downside is that a WMI filter has to process every time Group Policy processes. If you have ten GPOs with ten separate WMI filters that take 2 seconds a piece, your startup times are delayed by 20 seconds.
You can mitigate this problem. Always test a WMI filter first before deploying it to see the average run time. If your computers are starting automatically, startup times might not be a big deal for you. You can also substitute Item Level Targeting (ILTs) for some WMI filters (OS level, OU/group membership/time of day/etc).
If you do use WMI filters and ILTs, remember that the WMI filter applies first. It determines if the GPO is even applicable to the machine. If the WMI filter evaluates as true, then the ILTs can be evaluated. We are going to really dive into ILTs in a future post.
So what do you think about WMI? How are you using it in your environment? Any lingering questions?