- SmartDeploy: Rethinking software deployment to remote workers in times of a pandemic - Thu, Jul 30 2020
- Outlook attachments now blocked in Office 365 - Tue, Nov 19 2019
- PolicyPak MDM Edition: Group Policy and more for BYOD - Tue, Oct 29 2019
Group Policy allows for some pretty serious scoping! GPOs can be linked to sites, domains, or Organizational Units (with the vast majority being linked here). With the use of Security Groups, filtering can be granularly scoped through a manual process—manual meaning an Administrator either linking a GPO or changing membership in a Security Group.
Filtering based on Active Directory hierarchy or security isn’t always practical, however. If you have ever tried to use OUs or Security Groups to scope a policy down to only laptops or a certain operating system, you will know what I mean. Sometimes, a GPO needs to be applied based on a dynamic factor. This is where WMI filters will make your day!
Prior reading
Timothy Warner wrote an excellent post on WMI filters. If you are not familiar with the basic steps of creating and using them, take a few minutes to read that post before we start digging into some cool filters!
Filter 1: MDT deployment logs
The Microsoft Deployment Toolkit (MDT) is one of the best deployment options around! Certain Group Policy settings can kill a deployment in progress, though. The most notable are policies that change the local Administrator password and policies that mandate the acceptance of a usage policy. To ensure that GPOs containing these settings do not apply until the imaging process is finished, we can add this WMI filter to the offending GPOs:
Select * From CIM_Directory Where Name = 'C:\\Windows\\Temp\\DeploymentLogs'
Because MDT doesn’t write the deployment logs to %TEMP% until the deployment has finished, this GPO won’t apply if the deployment is in progress. Our MDT task sequence contains a final action to reboot the computer. When it reboots, it will apply the GPO.
The GPO above will change the local Administrator password if the machine was successfully imaged using MDT.
Filter 2: Installing software based on detected hardware
Spend ten minutes in an IT shop and a user will hit you with a request to install software required for a piece of hardware. In the Education sector alone, we have more types of hardware than I care to count. Using Group Policy software installation and a WMI filter, we can deploy software if a specific piece of hardware is detected.
For example, we have a GPO that deploys the SmartBoard software and drivers. It is linked to an OU containing teacher computers. Every teacher computer could potentially have a SmartBoard, so our security filtering is set to Authenticated Users. When a new SmartBoard is plugged into a computer, the teacher simply reboots the machine to install the software. This is accomplished with the following WMI filter:
Select * from Win32_PnPEntity where PNPDeviceID like "%M06030577%"
To modify this WMI filter for another piece of hardware, simply plug the hardware into a computer. Then, open Device Manager, find your device, and select Properties. Finally, select the Details tab and the Hardware Ids property. Using this as an example, we could configure a GPO to deploy iTunes if an iPhone is detected.
Device Manager shows us that the hardware ID for an iPhone 4 is “%VID_05AC%.”
If multiple devices used the same piece of software, you can change the query to apply to these devices. Let’s say that an iPhone 4S has a hardware ID of “%VID_06AC-4S%” and we still wanted the filter to apply to a computer with an iPhone 4 attached. Our new filter would read:
Select * from Win32_PnPEntity where PNPDeviceID like "%VID_05AC%" OR PNPDeviceID like "%VID_06AC-4S%"
As you can see, applying software based on attached hardware is a particularly powerful combo!
Filter 3: Day of the week
Our final filter restricts GPOs to apply only on certain days. Our environment has a GPO that denies faculty from logging on to computers in a lab. However, we wanted this GPO to only apply on the weekend. To do this, we add our faculty group to the “Deny log on locally” setting.
We then link the GPO to the lab OU and leave the Security Filtering set to Authenticated Users. Finally, we add this WMI filter:
Select * from Win32_LocalTime where DayofWeek = '6' OR DayofWeek = '7'
Day 6 is Saturday, and Day 7 is Sunday. Because WMI filters are processed every time the GPO runs, we do not have to worry about a machine “keeping” this policy around on Monday.
I hope this post has shown you some pretty cool WMI tricks to use in your environment. At the beginning of this article, I mentioned filtering a GPO based on the OS and when the device was a laptop. Here are those two queries:
Filtering based on OS:
Select * from Win32_OperatingSystem Where Caption = 'Microsoft Windows 7 Enterprise'
Filtering based on battery status:
Select * from Win32_Battery where BatteryStatus <> 0
If you have a more efficient way of accomplishing any of these tasks, please let us know in the comments section. If you know of another cool WMI filter, please share that as well!
I used string: select * from Win32_NTDomain where ClientSiteName = “Site2” and other.
I’m using url https://technet.microsoft.com/en-us/library/cc779036
Good link Alexander! Thank you for sharing!
Good post. I like the filter for checking if the MDT logs are still there.
I’ve used several different filters over the years. The most recent one was to check if Windows Defender is the only installed anti-virus solution. You query against the root\securitycenter2 namespace with the following query: SELECT * FROM AntiVirusProduct WHERE displayName = “Windows Defender” AND productState = 397568
That productState property value represents an up-to-date and active instance of Windows Defender.
Very nice filter Daniel! I’ll have to add that one to my stash!
Hi, Joseph! Thank you for your article!
What about selecting not just all attributes, but only the one you need:
“select Version,ProductType from Win32_OperatingSystem where Version like “6.1%” and ProductType = “1”” instead of “select * from Win32_OperatingSystem where Version like “6.1%” and ProductType = “1””
In first case it will execute faster and because of this, client computer won’t become much slower if you have a lot of GPOs with WMI filtering which it needs to compute.
That is a more efficient way of doing this and I need to re-work my filters for that! Thank you for the tip.