👋 Привет, админы!
Словил интересную ситуацию: на одном из Windows Server 2019 начали резко тормозить GPO. Логин пользователей стал занимать по 2-3 минуты, и первая мысль — сетевые проблемы. Но всё оказалось глубже.
🔍 Настоящий виновник — расширенные параметры в GPO, в частности, WMI-фильтры.
Если WMI-запрос в фильтре сложный или сервер работает под нагрузкой — он тормозит применение политики. Проверить, что творится, можно через Event Viewer:
📁 Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational
А вот так можно посмотреть, какие именно фильтры работают дольше всего:
Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" |
Where-Object { $_.Id -eq 5312 } |
Select-Object TimeCreated, Message
🛠️ В моем случае помогло:
- упростить WMI-фильтр (не проверять версию ОС через LIKE "%10.%")
- заменить фильтр на секцию Item-level targeting в GPP
- и... кэширование политики тоже не помешало 😉
Словил интересную ситуацию: на одном из Windows Server 2019 начали резко тормозить GPO. Логин пользователей стал занимать по 2-3 минуты, и первая мысль — сетевые проблемы. Но всё оказалось глубже.
🔍 Настоящий виновник — расширенные параметры в GPO, в частности, WMI-фильтры.
Если WMI-запрос в фильтре сложный или сервер работает под нагрузкой — он тормозит применение политики. Проверить, что творится, можно через Event Viewer:
📁 Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational
А вот так можно посмотреть, какие именно фильтры работают дольше всего:
Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" |
Where-Object { $_.Id -eq 5312 } |
Select-Object TimeCreated, Message
🛠️ В моем случае помогло:
- упростить WMI-фильтр (не проверять версию ОС через LIKE "%10.%")
- заменить фильтр на секцию Item-level targeting в GPP
- и... кэширование политики тоже не помешало 😉
_.Id