Справочник системных ошибок и решений

Windows Server, Active Directory, 1С:Предприятие, СУБД, Linux, Cisco, MikroTik, Asterisk.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты на сайте предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, программного обеспечения, баз данных, сетевого оборудования и других компонентов инфраструктуры. Перед выполнением действий создайте резервную копию и по возможности протестируйте изменения в безопасной среде. Пользователь самостоятельно оценивает риски и несет ответственность за результат. При отсутствии необходимых знаний обратитесь к квалифицированному ИТ-специалисту.

Event ID 5314 Windows Server, AD и Роли

Медленное применение WMI фильтров в GPO: оптимизация и исправление

Обновлено: 28.08.2026 · Официальная документация ↗

Симптомы медленной обработки WMI-фильтров

При входе пользователя или загрузке компьютера применение групповых политик занимает от 2 до 10 минут. В журнале Group Policy > Operational фиксируется предупреждение Event ID 5314 или Event ID 5016 с указанием длительного времени вычисления WMI-фильтра (WMI Filter Evaluation).

СимптомГде наблюдаетсяПричина
Экран применения параметров висит минутамиКлиентские станцииТяжелые запросы к Win32_Product / Win32_Directory
Высокая загрузка CPU процессом WmiPrvSE.exeДиспетчер задачWMI выполняет полный перебор реестра или файловой системы
Таймаут применения политикиgpresult /h report.htmlФильтр WMI возвращает ошибку по таймауту

Пошаговая оптимизация и исправление WMI-фильтров

  1. Никогда не используйте класс Win32_Product в WMI-фильтрах: опрос этого класса запускает процедуру самовосстановления Windows Installer (MSI) для каждого установленного пакета в системе, что вызывает колоссальные задержки. Замените его на чтение реестра.
  2. Оптимизируйте определение версии операционной системы: используйте точные условия по номеру билда вместо длинных строковых сравнений:
    SELECT Version, ProductType FROM Win32_OperatingSystem WHERE Version LIKE "10.0.19045%" AND ProductType = "1"
  3. Проверьте скорость выполнения WQL-запроса на клиенте:
    Measure-Command { Get-CimInstance -Query "SELECT Version, ProductType FROM Win32_OperatingSystem WHERE Version LIKE '10.0%'" }
  4. Восстановите поврежденный репозиторий WMI на клиенте при сбоях:
    winmgmt /verifyrepository; winmgmt /salvagerepository

Золотое правило GPO: Назначайте не более одного WMI-фильтра на объект политики и избегайте фильтрации через WMI там, где можно применить фильтрацию безопасности (Security Filtering) по группам Active Directory.

💡 Практика специалистов: Если на сервере терминалов RDS зависает вход пользователей, в 90% случаев это виноват WMI-фильтр с проверкой Win32_OperatingSystem Caption. Перепишите фильтры на строгое соответствие BuildNumber или перейдите на OU-структурирование.

Частые вопросы (FAQ)

Почему класс Win32_Product так сильно замедляет работу?

Обращение к Win32_Product вызывает событие MSIInstaller Event 1035 и запускает валидацию каждого установленного в системе MSI-пакета, что может занимать до 60 секунд на опрос.

Как заменить опрос Win32_Product на быстрый аналог?

Используйте нацеливание на уровне элементов (Item-Level Targeting) в Group Policy Preferences с проверкой ключа реестра HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall.

Как посмотреть время обработки каждого фильтра в отчете GPO?

Сгенерируйте отчет командой gpresult /h report.html и откройте раздел 'Сведения о фильтрах WMI'.

Где физически хранятся WMI-фильтры в домене Active Directory?

Они хранятся в контейнере CN=SOM,CN=WMIPolicy,CN=System,DC=домен,DC=local.

Полезные материалы
Рекомендуем