The purpose of WMI filtering is to allow more control over the Active Directory objects that Group Policy is applied. WMI filtering can be very powerful when used correctly, and can prevent the complex tree of Organization Units created to try and separate the Active Directory objects correctly. Microsoft recommended best practice is to leverage filtering and item level targeting (for preferences) to avoid large and complex Active Directory structure. While OUs can be used to filter, it is also a manual process and requires the interaction of an administrator. With WMI filtering, if a workstation is upgraded to another operating system, WMI will automatically acknowledge that change, where in the OU structure, the account would have to be moved to a new OU manually. So WMI filtering can reduce management overhead and prevent errors in policy application.
A couple of things to note when designing Group Policy using WMI filters:
- The WMI query syntax is similar to an SQL query
- Complex syntax can be written, but the more complex it becomes the more difficult it will be to manage
- The more filters are used and the more complex the queries, the greater the length of the logon time
- Per Microsoft recommended best practice, if a user / computer configuration if it is not being used, it should be disabled. Every configuration that is processed will add time to the logon process even if it is not being used
By default no WMI filters exist in Active Directory. The WMI filter container can be found in the Group Policy Management MMC under the Group Policy Objects container.
To create a new filter, right click the WMI Filters container and select “new” from the list.
This will open the WMI filter dialog window. (shown below)
Type a name and description, and then click the “Add” button to add the query to run (to determine OS version in this case)
This will open a new dialog window and it will prompt for the namespace (which should already be populated and unless you are doing something really strange should not be changed). It should be defaulted to root\CIMv2. It will also have a big box to type the query you want to run in. This is where you put the following:
select * from Win32_OperatingSystem where Version like "6.%" and ProductType = "1"
When you click “OK” on the WMI dialog window you will see the following:
Additional queries can be run (like checking for the presence of a battery, or this query can be modified to include the check for the existence of a battery. Remember the notes from above, more complexity will lead to more difficulty managing them and it will increase logon times. Click the “Save” button to save your new filter.
If everything worked out, you will now see something similar to the following:
Where a new filter will be listed under the WMI Filters container. The last step before testing is associating the filter with the GPO. To do this, click on the GPO you want to filter, and under the scope tab look for the WMI Filtering section toward the bottom of the window. Select your newly created filter and you will now be filtering based on OS and only Windows 7 workstations will be affected by this policy. (for this example).
There really isn’t too much that can go wrong with these. A couple of things that should be verified are the following:
- Make sure the scope is set accurately, if the computer is a part of a security group, make sure that security group has read and apply rights to the Group Policy Object
- Make sure that the group policy is applied to the correct OU and that it is enabled
- Make sure no inheritance blocking is set, or an enforcement rule applied to another GPO that will prevent the settings of this GPO from applying correctly
- Run the following command from a command prompt to verify that the GPO is applied as expected
This is a quick way to set Group Policy using a variety of conditions providing the ability to maintain a more “flat” Active Directory structure so less manual processes need to be completed reducing time requirements and avoiding errors.