What if Group Policy could read your mind? WMI Filters can make that possible. They can query your computers and apply GPOs if certain conditions exist. You can install software when a user connects a device, filter GPOs to laptops, or prevent problems when you image computers!

In this post, we are going to create three WMI filters that can make your Group Policy life so much easier! In just 700 words, you will be able to make WMI magic. If you haven’t, read our primer on WMI and how it works before creating a WMI filter.

WMI Filter #1: Installing an Application if Hardware is Connected

Three conditions have to be met before a GPO can be processed. The GPO has to be linked to the object, the object has to be in the security filtering scope, and the WMI filter has to evaluate as true. With most GPOs, you will only edit links and the security scope. The screenshot below shows a GPO configured with a WMI filter.

This GPO will apply to all domain computers in the Domain Sites OU if the Deployment Logs WMI filter is true.

Our first filter will allow an application to install if a particular piece of hardware is connected to the machine. Our GPO has a computer side application in it and it currently scoped to a security group. To create a WMI filter, right click on the WMI Filters node in the GPMC and select New. Name your filter Hardware: SmartBoard and then select Add. We now need a way to filter machines with a Smartboard connected. We can use the class PNPEntity and look for a specific device.

If we look in device manager, we will see that our Smartboard is named SMART HID Device. We could create a WMI filter that looks like:

select * from Win32_PnPEntity where Name like “SMART HID Device”

Because all WMI filters share the same style, you could modify this for any device that you have. Link the GPO to your computers and modify it so that all domain computers can process it. The GPO will not apply until the hardware is connected. Once connected, the GPO will evaluate as true and will install on the next reboot.

If you create a hardware based filter, let me know by leaving a comment below. Be sure to include your filter to help others!

WMI Filter #2: Apply the GPO if the device is a Laptop

Laptops will occasionally require their own special GPOs. In our environment, we scope wireless configuration policies and offline file settings to our laptops. I’ve seen many ways to filter devices into laptops and non-laptops. My personal favorite is to check for the presence of a battery.

Battery information is stored in the Battery class. In that class is a batterystatus member. If a battery isn’t present, batterystatus will return a 0. Knowing that we could filter for anything except for 0. Our query would look like:

Select * from Win32_Battery where BatteryStatus <> 0

The <> means not equal to. If you have another way to query for laptops, let me know below – I am sure someone has a more efficient filter.

WMI Filter #3: Preventing A Dirty Environment was Found in MDT

We are really flying through these filters now! Our final filter addresses Group Policy issues with MDT. Certain policies, like password change, can create a Dirty Environment found message in MDT. To fix this, we just need a way to ensure that the GPOs process after MDT has finished imaging a machine.

The final step that a Task Sequence performs is to copy the log files to C:\Windows\Temp\Deploymentlogs. If our WMI filter checked for the existence of the DeploymentLogs folder, our GPO wouldn’t process until imaging completed. Our filter would look like:

 Select * From CIM_Directory Where Name = ‘C:\\Windows\\Temp\\DeploymentLogs’

This filter is a bit different from our previous two as it uses a different class and has some funky syntax. In our next post, we will cover how you can quickly generate and test queries like the one above.  Hopefully, you’ve learned a good bit from our two WMI posts so far. If you have any questions (or cool filters to share), leave a comment below!