# GPO WMI Filters: 15 Queries for Windows 11 and Server 2025

Source: https://srvscripts.com/guides/gpo-wmi-filters/
Updated: 2026-10-03
Publisher: srvScripts (https://srvscripts.com/)

GPO WMI filters let a Group Policy Object apply only to computers that match a WMI query, such as Windows 11 workstations, laptops, virtual machines or member servers, even when they sit in the same OU as machines that should be left alone. The client runs the query when it processes policy; if the query returns at least one result, the GPO applies, and if it returns nothing, the GPO is skipped. This guide shows how to create and link filters, gives 15 ready-made queries, and covers testing, performance and troubleshooting.

**Short answer:** In GPMC, right-click **WMI Filters** under your domain, choose **New**, add a query such as `SELECT * FROM Win32_OperatingSystem WHERE ProductType = "1" AND BuildNumber >= "22000"` in namespace `root\CIMv2` and save. Select the GPO, and on the **Scope** tab choose the filter under **WMI Filtering**. Test the query first with `Get-CimInstance -Query` on a target machine: any output means the GPO will apply.

In short: In GPMC, right-click WMI Filters under your domain, choose New, add a query such as SELECT * FROM Win32_OperatingSystem WHERE ProductType = “1” AND BuildNumber >= “22000” in namespace root\CIMv2 and save.

## Which targeting method to use

WMI filtering is one of four ways to narrow where a GPO applies. Pick the lightest method that does the job.

| Method | Targets by | Applies to | Pros | Cons |
| --- | --- | --- | --- | --- |
| OU design and links | Where the object sits in AD | Whole GPO | No client cost, easy to read | One OU per object; mixed OUs need more |
| Security filtering | User or computer group membership | Whole GPO | Fast, explicit, easy to audit | Someone must maintain group membership |
| WMI filters | OS version, hardware, model, edition, memory | Whole GPO | Follows the machine automatically as it changes | Query runs on every refresh; one filter per GPO |
| Item-level targeting | OS, battery, IP range, group, registry, WMI and more | Single preference items | Very granular, many built-in tests | Group Policy Preferences only |

Use GPO WMI filters when the deciding attribute is a property of the machine that nobody wants to track by hand, such as the OS build or whether it is a laptop.

## Prerequisites

- Domain-joined clients running Windows 11 Pro, Enterprise or Education, or Windows Server 2016 to 2025.

- Group Policy Management Console (RSAT on Windows 11).

- Rights to create WMI filters: Domain Admins by default, or users delegated on the **WMI Filters** node’s **Delegation** tab.

- The Windows Management Instrumentation service running on clients (it is by default).

- A test machine for each class of target so you can run the query locally before linking.

## How GPO WMI filters work

- A filter is an AD object that stores a name, a description and one or more WQL queries, each with a namespace (normally `root\CIMv2`).

- A GPO can have **one** WMI filter. One filter can be linked to many GPOs.

- The filter evaluates to true when every query in it returns at least one instance. Multiple queries in one filter therefore behave as AND; use `OR` inside a single query when you need either condition.

- The client evaluates the filter on each processing cycle: at startup, at sign-in and at every background refresh.

- If the filter is false, `gpresult` lists the GPO as filtered out with `Denied (WMI Filter)`.

- Filters combine with security filtering: a GPO applies only when the account holds Apply and the WMI filter is true.

## Create a WMI filter in GPMC

- Open **Group Policy Management** (`gpmc.msc`) and expand Forest » Domains » your domain.

- Right-click **WMI Filters** and choose **New…**.

- Enter a clear **Name** (for example WMI – Windows 11 workstations) and a **Description** that states the exact condition.

- Click **Add**, leave **Namespace** set to `root\CIMv2`, paste the query and click **OK**.

- Click **Save**. GPMC checks the syntax but not whether the class and properties exist, so a typo is only caught when you test.

## Link the filter to a GPO

- Select the GPO under Group Policy Objects.

- On the **Scope** tab, in the **WMI Filtering** section, pick the filter from the drop-down list.

- Confirm with **Yes**. The link takes effect at the next refresh on each client.

You can check which filter a GPO uses from PowerShell:

```
(Get-GPO -Name 'CFG - Windows 11 Start Menu').WmiFilter
Get-GPO -All | Where-Object WmiFilter | Select-Object DisplayName, @{n='Filter';e={$_.WmiFilter.Name}}
```

The `GroupPolicy` module has no cmdlets to create or link WMI filters; use GPMC for that.

## 15 ready-made WMI filter queries

All queries use the `root\CIMv2` namespace. Build and product type values come from the `Win32_OperatingSystem` class: `ProductType` is 1 for workstations, 2 for domain controllers and 3 for other servers.

| # | Target | Query |
| --- | --- | --- |
| 1 | All workstations (any client OS) | SELECT * FROM Win32_OperatingSystem WHERE ProductType = "1" |
| 2 | Windows 11 only | SELECT * FROM Win32_OperatingSystem WHERE ProductType = "1" AND BuildNumber >= "22000" |
| 3 | Windows 10 only | SELECT * FROM Win32_OperatingSystem WHERE ProductType = "1" AND Version LIKE "10.%" AND BuildNumber < "22000" |
| 4 | Windows 11 24H2 or later | SELECT * FROM Win32_OperatingSystem WHERE ProductType = "1" AND BuildNumber >= "26100" |
| 5 | All servers, including DCs | SELECT * FROM Win32_OperatingSystem WHERE ProductType  "1" |
| 6 | Member servers (not DCs) | SELECT * FROM Win32_OperatingSystem WHERE ProductType = "3" |
| 7 | Domain controllers | SELECT * FROM Win32_OperatingSystem WHERE ProductType = "2" |
| 8 | Windows Server 2025 | SELECT * FROM Win32_OperatingSystem WHERE ProductType  "1" AND BuildNumber = "26100" |
| 9 | Laptops (has a battery) | SELECT * FROM Win32_Battery |
| 10 | Hyper-V and Azure VMs | SELECT * FROM Win32_ComputerSystem WHERE Model = "Virtual Machine" |
| 11 | VMware VMs | SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "VMware%" |
| 12 | 64-bit Windows | SELECT * FROM Win32_Processor WHERE AddressWidth = 64 |
| 13 | 8 GB of RAM or more | SELECT * FROM Win32_ComputerSystem WHERE TotalPhysicalMemory >= 7516192768 |
| 14 | Enterprise edition | SELECT * FROM Win32_OperatingSystem WHERE OperatingSystemSKU = 4 |
| 15 | Computer name prefix | SELECT * FROM Win32_ComputerSystem WHERE Name LIKE "LAB-%" |

### Notes on the queries

- **Build numbers:** `BuildNumber` is a string, so the comparison is alphabetical. That works here because every Windows 10 and 11 build has five digits (Windows 10 ends at 19045, Windows 11 starts at 22000, 24H2 is 26100 and 25H2 is 26200). Keep the value in quotes and test after each new release.

- **Servers vs Windows 11:** Windows Server 2025 and Windows 11 24H2 share build 26100, which is why query 8 also checks `ProductType`. For Windows Server 2022 use build `20348`, for 2019 `17763` and for 2016 `14393`.

- **Laptops:** query 9 is true on any machine that reports a battery, which can include a desktop with a USB-connected UPS. `SELECT * FROM Win32_ComputerSystem WHERE PCSystemType = 2` (Mobile) is an alternative that relies on the firmware’s own classification.

- **Memory:** `TotalPhysicalMemory` is in bytes and reports memory available to Windows, which is slightly less than the installed amount. The threshold in query 13 is 7 GiB so that 8 GB machines still match.

- **64-bit:** avoid `OSArchitecture = "64-bit"`; Microsoft documents that property as localised, so it can differ on non-English installs.

- **Edition:** `OperatingSystemSKU` 4 is Enterprise and 48 is Pro. Check the value on a sample machine for other editions.

## Test a query before you link it

A wrong query silently stops a GPO from applying everywhere, so test every one of your GPO WMI filters on a machine that should match and on one that should not.

### With PowerShell

```
Get-CimInstance -Namespace root\CIMv2 -Query 'SELECT * FROM Win32_OperatingSystem WHERE ProductType = "1" AND BuildNumber >= "22000"'
# Any output = filter TRUE; no output = filter FALSE; an error = bad class or property name
Get-CimInstance Win32_OperatingSystem | Select-Object Caption, Version, BuildNumber, ProductType, OperatingSystemSKU
Get-CimInstance Win32_ComputerSystem | Select-Object Manufacturer, Model, PCSystemType, TotalPhysicalMemory
```

The last two lines show the values you can build a query from. To test several machines at once over WinRM:

```
$q = 'SELECT * FROM Win32_ComputerSystem WHERE Model = "Virtual Machine"'
Invoke-Command -ComputerName PC01, PC02, SRV01 -ScriptBlock {
    param($q) [bool](Get-CimInstance -Query $q)
} -ArgumentList $q
```

### With wbemtest

- Run `wbemtest` as administrator and click **Connect…**.

- Enter `root\cimv2` as the namespace and click **Connect**.

- Click **Query…**, paste the query and click **Apply**. One or more objects in the result list means the filter is true.

## Performance cost

Each linked filter runs on every client at startup, sign-in and every background refresh (every 90 minutes plus a random offset by default). Most queries against `Win32_OperatingSystem` or `Win32_ComputerSystem` return in milliseconds, but a few habits keep GPO WMI filters cheap:

- **Never query `Win32_Product`.** Enumerating it makes Windows Installer check every installed MSI package, which is slow and can trigger repairs. Test for a file, registry value or service with item-level targeting instead.

- Prefer one filter shared by many GPOs over many near-identical filters.

- Use simple equality or `LIKE` tests on small classes; avoid classes that enumerate files, event logs or network connections.

- Measure a new query: `Measure-Command { Get-CimInstance -Query '...' }`. Anything above a fraction of a second on a normal client deserves a rethink.

- Where the attribute rarely changes, a computer group maintained by a scheduled script can replace the filter and remove the client-side cost completely.

## Item-level targeting as an alternative

If the GPO only contains Group Policy Preferences (drive maps, printers, registry items, shortcuts), item-level targeting is often the better tool. It lets each item decide for itself, it has ready-made tests for operating system, portable computer, battery present, IP address range, security group and registry match, and it also offers a WMI Query item when nothing else fits.

- Open the preference item, go to the **Common** tab and tick **Item-level targeting**.

- Click **Targeting…**, add items from **New Item** and combine them with **And**/**Or** and **Is Not**.

Administrative Templates, security settings and scripts cannot use item-level targeting; they need GPO WMI filters, security filtering or a separate OU. Our [drive mapping guide](/guides/map-network-drives-group-policy/) shows item-level targeting in practice.

## List, export and import WMI filters

GPO WMI filters are stored in AD as `msWMI-Som` objects. To list them with their queries:

```
$dn = (Get-ADDomain).DistinguishedName
Get-ADObject -SearchBase "CN=SOM,CN=WMIPolicy,CN=System,$dn" -Filter 'objectClass -eq "msWMI-Som"' -Properties 'msWMI-Name','msWMI-Parm1','msWMI-Parm2' |
    Select-Object 'msWMI-Name', 'msWMI-Parm1', 'msWMI-Parm2'
```

`msWMI-Parm1` holds the description and `msWMI-Parm2` the namespace and query in a packed string. In GPMC, right-click a filter and choose **Export…** to save it as a `.mof` file; right-click **WMI Filters » Import…** to load it in another domain. A GPO backup contains only the link to its WMI filter, not the filter, so export filters as part of your GPO backup routine.

## Design tips for GPO WMI filters

- **Name the condition, not the GPO.** WMI – Windows 11 workstations can be reused by ten GPOs; WMI – Start menu GPO cannot.

- **Put the full query in the description.** The GPMC Scope tab shows only the filter name, and the description is the quickest way for a colleague to see what it tests.

- **Keep one condition per filter where possible.** Combining OS, model and memory in one filter makes a false result hard to explain.

- **Review GPO WMI filters after each feature update.** New Windows builds and new hardware models are the usual reason a filter stops matching.

- **Do not use a filter to exclude a handful of named machines.** A Deny Apply group is clearer for that job.

## Verify it works

- On a machine that should match, run `gpresult /r /scope computer`. The GPO appears under Applied Group Policy Objects.

- On a machine that should not match, the GPO appears under filtered out with `Filtering: Denied (WMI Filter)`.

- `gpresult /h C:\Temp\rsop.html` shows the filter name and its result per GPO.

- In Microsoft » Windows » GroupPolicy » Operational, event 5313 lists GPOs that were filtered out during processing.

## Troubleshooting

| Symptom | Likely cause | Fix |
| --- | --- | --- |
| GPO filtered out on every machine | Typo in class or property, wrong namespace, or missing quotes around a string value | Run the exact query with Get-CimInstance; an error points to the bad part |
| Windows 11 filter misses new builds | Numeric-looking comparison without quotes, or an equality test on one build | Use BuildNumber >= "22000" with quotes |
| Servers receive a Windows 11 GPO | Build-only query matches Server 2025 (build 26100) | Add ProductType = "1" |
| Desktops treated as laptops | UPS reports a battery | Use PCSystemType = 2 or item-level targeting |
| Slow startup or sign-in | Expensive class such as Win32_Product | Replace the filter; check processing time in the GroupPolicy Operational log |
| Filter correct but GPO still not applied | Security filtering, link or inheritance problem | Check gpresult for Denied (Security) or a missing link |
| WMI errors on the client | Damaged WMI repository | Run winmgmt /verifyrepository; repair only if it reports an inconsistency |

## Remove a filter

To stop filtering a GPO, select it and set **WMI Filtering** on the Scope tab to **<none>**. Before deleting a filter from the **WMI Filters** node, check which GPOs use it with the `Get-GPO -All` command above and unlink it from each, then export a copy in case you need it back. Well-named GPO WMI filters with clear descriptions, tested on real machines and shared across GPOs, stay reliable for years.

## GPO WMI filters at a glance

**Official documentation:** [Create WMI filters for the GPO](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj717288(v=ws.11)), [Win32_OperatingSystem class](https://learn.microsoft.com/en-us/windows/win32/cimwin32prov/win32-operatingsystem), [Win32_ComputerSystem class](https://learn.microsoft.com/en-us/windows/win32/cimwin32prov/win32-computersystem).

**Related guides:** [GPO security filtering: target or exclude users and computers](/guides/group-policy-security-filtering/) · [Map Network Drives Group Policy: 2026 Item-Level Targeting Made Easy](/guides/map-network-drives-group-policy/) · [Troubleshoot Group Policy not applying: gpresult, RSoP and Events 1058/1030](/guides/group-policy-not-applying/).

## Frequently asked questions

### How many WMI filters can a GPO have?

One. A single filter can contain several queries, which must all return results for the filter to be true, and one filter can be linked to many GPOs.

### How do I target only Windows 11 with a WMI filter?

Use SELECT * FROM Win32_OperatingSystem WHERE ProductType = “1” AND BuildNumber >= “22000”. ProductType 1 excludes servers, and every Windows 11 build is 22000 or higher.

### How do I test a WMI filter before linking it?

Run the query on a target machine with Get-CimInstance -Query or in wbemtest against root\cimv2. Any returned object means the filter is true on that machine.

### Do WMI filters slow down Group Policy?

Simple queries on classes like Win32_OperatingSystem cost milliseconds. Avoid Win32_Product and other classes that enumerate large data sets, because the query runs at every startup, sign-in and background refresh.

### Are WMI filters included in a GPO backup?

No. A GPO backup stores only the link to the filter. Export filters from GPMC as .mof files, or list them from AD, as part of your backup routine.