Using security filtering to apply GPOs only to particular groups of users or computers is an extremely powerful capability, and I find that it is typically the lowest level of filtering that the average Group Policy administrator takes in most domains. I would completely understand if you stopped here and did not read this last section of the chapter. However, at some point, you may discover a need to filter the scope of a GPO even further, or perhaps all of this group creation just for the purposes of filtering a GPO sounds like unnecessary work (after all, you do then have to administer those groups and group membership on an ongoing basis).
WMI filters are a way to narrow the focus of your GPO filtering even further. This is a way to look at the WMI information that exists on Windows computers, query on that information, and then filter GPO settings based on the results of that WMI query. Using WMI filters is essentially a way to tell Group Policy to only apply the associated GPO settings if the computer meets particular criteria, and those criteria are determined through WMI.
Now, WMI is an enormous topic and we certainly can't cover it all here. We can get our feet wet with an example, and instruct you on exactly how to put WMI filters into place so that you know how to use them within Group Policy, but piecing together the WMI queries themselves will take some legwork. Thankfully, they just invented the internet and these things called search engines, and you will be able to easily find sample queries of all shapes and sizes.
The list of specific criteria that you can search for inside WMI is huge, and is potentially different depending on your computer manufacturers and model numbers. Just to give a very basic overview of some of the things you can pull out of WMI: operating system version numbers, operating system names, the kind of CPU the machine has, how much RAM it has, the amount of available disk space, whether or not particular KB/hotfixes are installed, whether or not certain third-party software is installed; the list goes on and on and on. You can query against hardware, software, and sometimes even firmware (BIOS) on your machines. Then, once WMI has sucked in those results, you utilize those results to determine whether or not a particular GPO should apply to that device.
Thinking this through, WMI filters enable you not only to do things such as "only install this huge piece of software if there is at least 5 GB of available disk space" but can even be used for a decision such as "only implement these firewall settings on machines that are running a Windows Server operating system".
One real-world example that I encounter often is a WMI filter that flags remote access settings only to "mobile hardware". The Microsoft Remote Access Management Console is a tool used to configure VPN and DA settings on a Windows Server, and when it rolls around DA settings, you have the option to enforce a WMI filter that only allows those GPO settings to apply to any hardware that comes back at the WMI level as a laptop or tablet. Any systems that WMI identifies as traditional desktop or server hardware will not receive those GPO settings, because you only need remote access settings on your mobile hardware.
When WMI queries against a machine, it comes back with basically a "true" or "false" response, based on whether or not the WMI criteria have been met. If a machine tests "true", that GPO will apply to the machine. If a machine tests "false", that GPO will not apply to the machine, or in some cases will actively remove those GPO settings if they already exist on the machine. It is important to note that you cannot flag only some settings inside a GPO to be used by this WMI filter. Just like with security filtering based upon AD groups, a computer will either receive or not receive the entire GPO based on whether or not it passes the WMI filter test.