Gpo windows 10 wmi

WMI фильтры групповых политики позволяют создать дополнительные условия, в которых определяются параметры компьютеров, к которым нужно нужно применять настройки GPO. Например, с помощью WMI фильтра вы можете применить политику к компьютерам с определенным версией Windows; с определенными настройками; характеристиками оборудования (размеру RAM, HDD); на которых установлена определенная программа; к компьютерам в указанной IP подсети и т.д.

WMI (Windows Management Instrumentation) фильтр в GPO представляет собой запрос на языке WQL (WMI Query Language). Доменный компьютер перед тем, как применить конкретный объект GPO, выполняет такой WMI запрос и опрашивает свое состояние. Если состояние компьютера соответствует условиям выполняются, такая групповая политика будет применена к компьютеру.

Как создать и привязать WMI фильтр к GPO

Для управления WMI фильтрами используется консоль управления доменными групповыми политиками .

1. Откройте консоль
   gpmc.msc
2. Перейдите в раздел WMI Filters и создайте новый фильтр
3. Укажите название фильтра и описание (не обязательно)
   

   Картинка с сайта: winitpro.ru

4. Нажмите Add. Выберите пространство имен WMI (в большинстве случаев используется root\CIMv2). Укажите код WMI запроса в следующем формате:
   Select * from <WMI Class> WHERE <Property> = <Value>
   Например, следующий WMI запрос можно использовать, чтобы применить GPO только к компьютерам с Windows 10 и 11:
   Select * from Win32_OperatingSystem where Version like "10.%" and ProductType="1"
   
   

   Картинка с сайта: winitpro.ru

5. Теперь WMI фильтр можно привязать к GPO. Например, вы хотите, чтоб политика установки принтеров применялась только к компьютерам с Windows 10 и 11. В разделе WMI Filtering групповой политики выберите WMI фильтр, который вы создали.
   

   Картинка с сайта: winitpro.ru

6. Обновите настройки GPO на клиентах. Теперь политика будет применяться только к компьютерам, которые удовлетворяют условиям WMI фильтра. Для анализа примененных политики можно использовать команду gpresult /r. Если политика действует на клиента, но не применяется из-за WMI фильтра, такая политика в отчете gpresult будет иметь статус
   Filtering: Denied (WMI Filter)
   и указано имя WMI фильтра.
   

   Картинка с сайта: winitpro.ru

Примеры WMI запросов для фильтров GPO

Рассмотрим часто используемые примеры WMI запросов для фильтров GPO.

В зависимости от типа ОС:

• ProductType=1 – рабочая станция (клиентская версия Windows)
• ProductType=2 – контроллер домена AD
• ProductType=3 – серверная ОС (Windows Server)

В зависимости от версии Windows:

Version like "X.X%"

• Windows Server 2016/2019/2022 и Windows 10/11 — 10.%
• Windows Server 2012 R2 и Windows 8.1 — 6.3%
• Windows Server 2012 и Windows 8 — 6.2%
• Windows Server 2008 R2 и Windows 7 — 6.1%
• Windows Server 2008 и Windows Vista — 6.0%
• Windows Server 2003 — 5.2%
• Windows XP — 5.1%

С помощью логических операторов AND и OR можно комбинировать несколько условий в WMI запросе. Например, чтобы применить GPO только к серверам с Windows Server 2019:

select * from Win32_OperatingSystem WHERE Caption LIKE "%2019%" AND Version LIKE "10.%" AND ( ProductType = "2" or ProductType = "3")

Компьютеры с 64 битными версиями Windows 10:

select * from Win32_OperatingSystem WHERE Version like "10.%" AND ProductType="1" AND OSArchitecture = "64-bit"

Компьютеры с определенным билдом Windows 11 (например, 23H2, билд 22631):

select * from Win32_OperatingSystem WHERE Caption like "%Windows 11%" AND ProductType="1" AND BuildNumber = "22631"

Применить политику только к виртуальным машинам VMWare:

SELECT Model FROM Win32_ComputerSystem WHERE Model LIKE "%VMware%"

Применить политику только к ноутбукам:

select * from Win32_ComputerSystem where PCSystemType="2"

Только к десктопным компьютерам (рабочим станциям):

select * from Win32_ComputerSystem where PCSystemType="1" or PCSystemType="3"

WMI фильтр для выбора компьютеров, чьи имена начинаются на “msk-pc

SELECT Name FROM Win32_ComputerSystem WHERE Name LIKE "msk-pc%"

Применить политику только к компьютерам в определенных IP подсетях (WMI фильтр для привязки GPO к IP подсети):

Select * FROM Win32_IP4RouteTable WHERE (Mask='255.255.255.255' AND (Destination Like '192.168.1.%' OR Destination Like '192.168.2.%'))

Компьютеры с более чем 4 ГБ RAM:

Select * from WIN32_ComputerSystem where TotalPhysicalMemory >= 4200000000

Компьютеры, на которых установлен архиватор 7ZIP:

Select * From Win32_Product where Name like "%7-Zip %"

На которых установлен Internet Explorer (по умолчанию IE удален в современных версиях Windows):

SELECT path,filename,extension,version FROM CIM_DataFile WHERE path="\\Program Files\\Internet Explorer\\" AND filename="iexplore" AND extension="exe" AND version>"11.0"

Проверка WMI фильтров с помощью PowerShell

WMI фильтры перед применением в GPO можно протестировать на целевых компьютерах. Это позволит понять, будет или не будет политика с таким WMI запросов применяться на определенных компьютерах. Для просмотра всех доступных WMI классов на компьютере выполните PowerShell команду:

Get-WmiObject -List

Вывести доступные атрибуты и значения WMI класса Win32_OperatingSystem:

Get-WMIObject Win32_OperatingSystem| Select *

Картинка с сайта: winitpro.ru

Чтобы проверить ваш WMI запроса на компьютере и понять, соответствует ли компьютер данному запросу или нет, укажите его код в параметре -query. Например, такой WMI запрос проверяет, установлен ли на компьютере Microsoft Office:

Get-WmiObject -query 'Select * From Win32_Product where Name like "%Office 16 Click-to-Run%"'

Если такая команда возвращает в ответ список атрибутов, значит компьютер соотвествует вашему запросу и GPO с таким WMI фильтром будет применена. Если команда get-wmiobject ничего не вернула — компьютер не соответствует запросу.

Картинка с сайта: winitpro.ru

В новых версиях PowerShell Core 7.x, командлет Get-WmiObject является устаревшим и вместо него нужно использовать
Get-CimInstance
.

WMI фильтры GPO позволяют создать динамические правила, в которых определяются характеристики компьютеров, к которым нужно применить групповые политики.

Every now and then during Windows 10 deployments we need to use WMI filters for group policy objects, there are simply no better way of doing this, without a lot of work. WMI is simple to use and demands little maintenance.

There WMI filters may also come handy since there are group policy settings that only applies to one or two builds.

So here are some examples, ready to use for all operating system.

There are three queries for all operating system, 64-bit, 32-bit and both.

Note! Due to performance do NOT use Select * instead use Select Version as in the queries below, Why? See this article Using group policy WMI filters computers booting slow?

Windows 10 1703

select Version from Win32_OperatingSystem WHERE Version like “10.0.15063” AND ProductType=”1″ AND OSArchitecture = “64-bit”
select Version from Win32_OperatingSystem WHERE Version like “10.0.15063” AND ProductType=”1″ AND NOT OSArchitecture = “64-bit”
select Version from Win32_OperatingSystem WHERE Version like “10.0.15063” AND ProductType=”1″

Windows 10 1607

select Version from Win32_OperatingSystem WHERE Version like “10.0.14393” AND ProductType=”1″ AND OSArchitecture = “64-bit”
select Version from Win32_OperatingSystem WHERE Version like “10.0.14393” AND ProductType=”1″ AND NOT OSArchitecture = “64-bit”
select Version from Win32_OperatingSystem WHERE Version like “10.0.14393” AND ProductType=”1″

Windows 10 1511

select Version from Win32_OperatingSystem WHERE Version like “10.0.10586” AND ProductType=”1″ AND OSArchitecture = “64-bit”
select Version from Win32_OperatingSystem WHERE Version like “10.0.10586” AND ProductType=”1″ AND NOT OSArchitecture = “64-bit”
select Version from Win32_OperatingSystem WHERE Version like “10.0.10586” AND ProductType=”1″

Windows 10 1507

select Version from Win32_OperatingSystem WHERE Version like “10.0.10240” AND ProductType=”1″ AND OSArchitecture = “64-bit”
select Version from Win32_OperatingSystem WHERE Version like “10.0.10240” AND ProductType=”1″ AND NOT OSArchitecture = “64-bit”
select Version from Win32_OperatingSystem WHERE Version like “10.0.10240” AND ProductType=”1″

Windows 10 all builds

select Version from Win32_OperatingSystem WHERE Version like “10.%” AND ProductType=”1″ AND OSArchitecture = “64-bit”
select Version from Win32_OperatingSystem WHERE Version like “10.%” AND ProductType=”1″ AND NOT OSArchitecture = “64-bit”
select Version from Win32_OperatingSystem WHERE Version like “10.%” AND ProductType=”1″

Windows 7, 8 and 8.1 (all versions before 10)

select Version from Win32_OperatingSystem WHERE Version like “6.%” AND ProductType=”1″ AND OSArchitecture = “64-bit”
select Version from Win32_OperatingSystem WHERE Version like “6.%” AND ProductType=”1″ AND NOT OSArchitecture = “64-bit”
select Version from Win32_OperatingSystem WHERE Version like “6.%” AND ProductType=”1″

Windows 8.1

select Version from Win32_OperatingSystem WHERE Version like “6.3%” AND ProductType=”1″ AND OSArchitecture = “64-bit”
select Version from Win32_OperatingSystem WHERE Version like “6.3%” AND ProductType=”1″ AND NOT OSArchitecture = “64-bit”
select Version from Win32_OperatingSystem WHERE Version like “6.3%” AND ProductType=”1″

Windows 8

select Version from Win32_OperatingSystem WHERE Version like “6.2%” AND ProductType=”1″ AND OSArchitecture = “64-bit”
select Version from Win32_OperatingSystem WHERE Version like “6.2%” AND ProductType=”1″ AND NOT OSArchitecture = “64-bit”
select Version from Win32_OperatingSystem WHERE Version like “6.2%” AND ProductType=”1″

Windows 7

select Version from Win32_OperatingSystem WHERE Version like “6.1%” AND ProductType=”1″ AND OSArchitecture = “64-bit”
select Version from Win32_OperatingSystem WHERE Version like “6.1%” AND ProductType=”1″ AND NOT OSArchitecture = “64-bit”
select Version from Win32_OperatingSystem WHERE Version like “6.1%” AND ProductType=”1″

In the ever-evolving landscape of Windows enterprise environments, IT administrators continually seek efficient ways to deploy targeted Group Policy settings. Windows Management Instrumentation (WMI) filters provide a powerful mechanism to apply GPOs with surgical precision, ensuring policies reach exactly the right systems at the right time. This post explores both fundamental and creative applications of WMI filters that can transform your Group Policy management strategy.

Understanding WMI Filters: The Basics

WMI filters act as gatekeepers for Group Policy Objects (GPOs), evaluating whether a policy should apply to a particular system. These filters query system properties through WMI classes to make this determination. Before a GPO processes, the system evaluates its associated WMI filter, and only proceeds if the query returns true.

The syntax follows standard WMI Query Language (WQL), which resembles SQL:

Select [properties] from [WMI class] where [conditions]

Real-World Example: Updating Server Version Filters

However, you now need to include older Server 2008 systems. The solution involves adjusting the version number check, as Server 2008 uses version 6.0 and Server 2008 R2 uses 6.1:

Select * from Win32_OperatingSystem WHERE (ProductType = 3) AND ((Version LIKE ’10.%’) OR (Version >= ‘6.0%’))

This modified filter will match all domain controllers running Windows Server 2008 and newer versions.

Operating System Targeting Reference

When creating WMI filters, precisely targeting specific Windows versions is a common requirement. Here’s a comprehensive reference for targeting various Windows operating systems:

Windows Client Operating Systems

Windows 11

Select * from Win32_OperatingSystem WHERE Version LIKE ’10.%’ AND BuildNumber >= 22000

Windows 10

Select * from Win32_OperatingSystem WHERE Version LIKE ’10.%’ AND BuildNumber < 22000

Combination: Windows 10 and 11 Only

Select * from Win32_OperatingSystem WHERE Version LIKE ’10.%’

Combination: Windows 8 and Later (Excluding Server)

Select * from Win32_OperatingSystem WHERE Version >= ‘6.2%’ AND ProductType = 1

Windows Server Operating Systems

Windows Server 2022

Select * from Win32_OperatingSystem WHERE Version LIKE ‘10.0%’ AND BuildNumber >= 20348 AND ProductType > 1

Windows Server 2019

Select * from Win32_OperatingSystem WHERE Version LIKE ‘10.0%’ AND BuildNumber >= 17763 AND BuildNumber < 20348 AND ProductType > 1

Windows Server 2016

Select * from Win32_OperatingSystem WHERE Version LIKE ‘10.0%’ AND BuildNumber >= 14393 AND BuildNumber < 17763 AND ProductType > 1

Windows Server 2012 R2

Select * from Win32_OperatingSystem WHERE Version LIKE ‘6.3%’ AND ProductType > 1

Special Combinations

All Domain Controllers

Select * from Win32_OperatingSystem WHERE ProductType = 2

All Member Servers (Non-DC Server OS)

Select * from Win32_OperatingSystem WHERE ProductType = 3

All Server Operating Systems

Select * from Win32_OperatingSystem WHERE ProductType > 1

All Desktop Operating Systems

Select * from Win32_OperatingSystem WHERE ProductType = 1

Server 2012 and Newer

Select * from Win32_OperatingSystem WHERE ((Version LIKE ’10.%’) OR (Version >= ‘6.2%’)) AND ProductType > 1

Physical Machines Only (No VMs)

Select * from Win32_ComputerSystem WHERE Model NOT LIKE ‘%Virtual%’

Architecture-Based Filters

64-bit Systems Only

Select * from Win32_OperatingSystem WHERE OSArchitecture = ’64-bit’

32-bit Systems Only

Select * from Win32_OperatingSystem WHERE OSArchitecture = ’32-bit’

Performance Considerations: WMI Filters vs. Item-Level Targeting

It’s important to understand the performance implications when deciding between WMI filters and item-level targeting:

Processing Differences

• WMI Filters: Applied at the GPO level before any policy settings are processed. If the filter evaluates to false, the entire GPO is skipped, saving processing time for all contained settings.
• Item-Level Targeting: The GPO itself is always processed, but individual settings within the policy will be applied or skipped based on targeting criteria. This means the Group Policy engine still has to evaluate the entire GPO, even if many settings are ultimately not applied.

Performance Impact

Both mechanisms create a similar overhead in terms of the WMI queries themselves, but they differ in when that overhead is incurred:

• With WMI filters, the overhead happens early in the Group Policy processing cycle, potentially eliminating subsequent processing entirely.
• With item-level targeting, the Group Policy processing happens first, followed by additional overhead for each targeted item.

Best Practice Recommendations

1. For Entire Policy Application: Use WMI filters when an entire GPO should apply (or not apply) to a computer or user.
2. For Granular Control: Use item-level targeting when you need different settings within the same GPO to apply to different subsets of computers or users.
3. Minimize Complexity: Whether using WMI filters or item-level targeting, keep the queries as simple as possible while achieving your goal.
4. Consider Consolidation: Where possible, consolidate GPOs with similar WMI filters to reduce overall processing time.
5. Test and Benchmark: Always test the performance impact of your filters in a non-production environment, especially for large deployments.

By understanding these performance considerations, you can make informed decisions about when to use WMI filters versus item-level targeting to achieve your management goals with minimal impact on system performance.

Creative WMI Filter Scenarios

Let’s explore some innovative applications of WMI filters that can address specific administrative challenges:

Targeting Systems with Limited RAM

Apply resource-conservative settings to machines with constrained memory:

Select * from Win32_ComputerSystem WHERE TotalPhysicalMemory < 8589934592

This targets systems with less than 8GB of RAM, allowing you to disable memory-intensive features.

Systems with Multiple CPUs/Cores

Deploy performance optimization settings only to high-performance workstations:

Select * from Win32_Processor WHERE NumberOfCores > 8

Specific Machine Models

Target policies to particular hardware models, ideal for manufacturer-specific drivers or settings:

Select * from Win32_ComputerSystem WHERE Model LIKE ‘%Razer%’

Apply region-specific policies based on IP subnet:

Select * from Win32_NetworkAdapterConfiguration WHERE IPEnabled = True AND IPAddress LIKE ‘192.168.10.%’

Apply stricter security policies to VPN-connected machines:

Select * from Win32_NetworkAdapter WHERE NetConnectionID LIKE ‘%VPN%’ AND NetEnabled = True

Apply special configurations to newly deployed systems after the date specified:

Select * from Win32_OperatingSystem WHERE InstallDate > ‘20250409000000.000000-000’

Target systems that may need rebooting with a notification policy, before the date spcified:

Select * from Win32_OperatingSystem WHERE LastBootUpTime < ‘20250209000000.000000-000’

Apply enhanced security or specialized settings to executive machines:

Select * from Win32_ComputerSystem WHERE Name LIKE ‘BearWrk-%’

Deploy developer-friendly settings to development machines:

Select * from Win32_ComputerSystem WHERE (Name LIKE ‘Dev-%’) OR (DNSHostName LIKE ‘%.bear.dev’)

Apply database-specific performance tuning only to s SQL server:

Select * from Win32_Service WHERE Name LIKE ‘MSSQL%’ AND State = ‘Running’

Deploy emergency security measures to unprotected systems that have no Defender running:

Select * from Win32_Service WHERE Name LIKE ‘%defender%’ AND State <> ‘Running’

Apply VM-specific optimizations:

Select * from Win32_ComputerSystem WHERE Model LIKE ‘%Virtual%’

Target only battery-powered devices:

Select * from Win32_Battery WHERE BatteryStatus IS NOT NULL

Apply emergency power settings to systems with critically low battery:

Select * from Win32_Battery WHERE EstimatedChargeRemaining < 10

This targets systems with less than 10GB free on the C: drive.

Select FreeSpace from Win32_LogicalDisk WHERE DeviceID=’C:’ AND FreeSpace < 10737418240

Apply policy to SSD-specific devices:

Select * from Win32_DiskDrive WHERE MediaType LIKE ‘%SSD%’

This targets NVIDIA GPUs with more than 4GB VRAM:

Select * from Win32_VideoController WHERE AdapterRAM > 4294967296 AND Name LIKE ‘%NVIDIA%’

Best Practices for WMI Filter Management

1. Test thoroughly: Always validate filters in test environments before deploying to production.
2. Document meticulously: Maintain clear documentation about each filter’s purpose and conditions.
3. Monitor performance: Complex WMI filters can add processing overhead. Use the simplest effective query.
4. Use naming conventions: Adopt a consistent naming scheme for your WMI filters.
5. Validate with PowerShell: Test your queries using PowerShell’s Get-WmiObject or Get-CimInstance before implementing as filters.
6. Understand scope and precedence: Remember that WMI filters are evaluated before a GPO applies, adding an additional layer to Group Policy processing.

Troubleshooting WMI Filters

When WMI filters don’t work as expected, try these steps:

1. Verify the syntax using PowerShell to execute the query directly on target systems
2. Check the WMI event logs for errors
3. Ensure WMI service is running properly on target systems
4. Validate permissions for filter execution

Conclusion

WMI filters represent one of the most flexible tools in an administrator’s Group Policy arsenal. By moving beyond basic OS version filtering to implement creative scenarios like those outlined above, you can achieve unprecedented control over your environment.

The examples provided here just scratch the surface of what’s possible. The real power comes when you combine multiple conditions to create targeted, nuanced policy deployment that adapts to your organization’s specific needs.