Диагностика групповых политик AD: когда GPO не применяется и как это починить

Семёнов Евгений Сергеевич, директор АйТи Фреш. GPO — инструмент обманчиво простой: накликал политику в gpmc.msc, привязал к OU, и всё должно работать. На практике каждый третий тикет от системного администратора звучит одинаково: «политика не применяется, хотя всё по инструкции». У нас на практике 80% таких ситуаций решаются за 10 минут, если знать, куда смотреть. Эта статья собрала методику диагностики, которой я учу новых инженеров своей команды.

Модель применения GPO: LSDOU и фильтры

Чтобы чинить, надо понимать порядок обработки. Политики применяются по цепочке LSDOU: Local → Site → Domain → OU, от корня OU к листу. Каждая следующая переписывает предыдущую, если явно не стоит Enforced на родителе. Плюс на каждом уровне работает три фильтра: Security Filtering (по группам и пользователям), WMI-фильтр, Block Inheritance на дочерней OU.

• Local GPO применяется первым — настройки gpedit.msc на самой машине.
• Site-уровень задаётся в Active Directory Sites and Services, редко используется.
• Domain-уровень — Default Domain Policy и любая GPO, привязанная к корню домена.
• OU-уровень обрабатывается от внешней OU к внутренней.
• Enforced (Enforced link) переопределяет блокировки и более поздние политики.

Я всегда держу под рукой эту схему. Если клиент жалуется, что у пользователя прокси не тот, который прописан в политике — открываю его OU, смотрю всю цепочку сверху вниз и нахожу, какая GPO применяется позже и перезаписывает значение.

Первая команда диагностики: gpresult

Любая диагностика GPO начинается с трёх вариантов запуска gpresult. Я годами использую именно их:

# Быстрый обзор применённых и отклонённых GPO
gpresult /r /scope:computer
gpresult /r /scope:user

# HTML-отчёт с полной детализацией
gpresult /h C:\Temp\gpo.html /f

# Сохранённый RSoP-отчёт с удалённой машины
gpresult /s WORKSTATION-42 /h \\share\reports\ws42.html /f

HTML-отчёт — самый информативный. В нём видно, какие GPO применены, в каком порядке, какие отклонены и почему (Empty, Filter Denied, Disabled), какие настройки Winning из какой именно политики. Один раз открыв такой отчёт, вы сразу видите все конфликты.

Event Viewer: коды ошибок, которые надо знать

Журналы Windows ведут подробный лог обработки GPO. Нужные ветки — Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational и System-журнал. Вот самые частые коды:

Обычно достаточно открыть Operational-журнал за последние сутки и отфильтровать по уровню Error/Warning. Типичная картина — цепочка событий 4016 → 5312 → 5317 → 5018 → 4017 вокруг проблемной политики.

Security Filtering и Delegation

Самая частая причина «политика не применяется» — удалённая группа Authenticated Users из Security Filtering. После мартовских обновлений 2016 года Microsoft требует, чтобы у аутентифицированных пользователей или компьютеров было право Read на GPO, иначе она не читается с клиента.

# Проверка прав на GPO
Get-GPPermission -Name "Финансы - Прокси и диски" -All

# Вернуть Authenticated Users с Read (без Apply)
Set-GPPermission -Name "Финансы - Прокси и диски" `
  -TargetName "Authenticated Users" `
  -TargetType Group `
  -PermissionLevel GpoRead

# Ограничить применение группой Fin-Users
Set-GPPermission -Name "Финансы - Прокси и диски" `
  -TargetName "Fin-Users" `
  -TargetType Group `
  -PermissionLevel GpoApply

Правило, которое я передаю команде: на любой GPO должно быть минимум две записи — Authenticated Users с Read и целевая группа с Apply Group Policy. Иначе при очередном аудите безопасности, когда кто-то «почистит лишнее», политика перестанет работать.

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

WMI-фильтр — это WQL-запрос, который выполняется на клиенте и решает, применять политику или нет. Очень мощный инструмент для политик «только для ноутбуков» или «только Windows 11». Но у него есть нюансы: медленный запрос замедляет логон на 5–30 секунд, а ошибка в WQL незаметна — политика молча отваливается.

# Проверка фильтра на клиенте
Get-WmiObject -Query "SELECT * FROM Win32_ComputerSystem WHERE PCSystemType=2"
# PCSystemType=2 — ноутбук, =1 — десктоп

# Типовой фильтр "Только Windows 11"
SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "10.0.22%" AND ProductType=1

Однажды в 2024 в офисе клиента после обновления Windows 10 до 11 перестали применяться политики установки корпоративного ПО. Оказалось, фильтр проверял Version LIKE "10.0.19%", а у 11-ки версия 10.0.22xxx. Пять минут — и проблема на 80 машинах снята.

Loopback processing для терминалов и переговорных

Стандартно GPO применяется так: Computer Configuration тянется из политик на OU компьютера, User Configuration — из политик на OU пользователя. Но на RDS-ферме или в переговорной вам нужно, чтобы при логоне любого пользователя применялись настройки «этой конкретной машины», а не его личные.

Включается через Computer Configuration → Administrative Templates → System → Group Policy → Configure user Group Policy loopback processing mode:

• Replace — игнорировать пользовательские настройки из OU юзера, брать только из OU компьютера.
• Merge — взять из OU юзера, затем переопределить из OU компьютера.

Для RDS-фермы я всегда ставлю Replace и создаю отдельную OU «Terminal Servers» с жёсткой политикой: отключённый Control Panel, заблокированный USB, ограниченные меню Пуск. Пользовательские предпочтения с их личной OU туда не попадают, и это правильно.

Реальный кейс: медленный логон на 180 ПК

В июле 2024 пришёл клиент — юридическая компания на 180 рабочих мест в двух офисах. Жалоба: логон занимает 3–5 минут на всех машинах после обновления домена на Server 2022. Доменный контроллер новый, железо мощное, канал между офисами 100 Мбит/с, а пользователи ждут, пока появится рабочий стол.

Первый же gpresult /r на тестовом ПК показал 47 применяемых GPO, из них 12 помечены как медленные (>2 секунды). Открываю HTML-отчёт и вижу три WMI-фильтра с запросами к Win32_Product — это классика ошибки: Win32_Product триггерит пересборку MSI-кеша и выполняется 20–60 секунд. Переписал фильтры на Win32_InstalledWin32Program — время упало до 0.3 секунды.

Дальше — нашёл политику Software Installation с тяжёлым MSI на 480 МБ, который копировался на каждый логон, потому что в SYSVOL путь был указан через DNS-имя удалённого DC. Перевёл на локальный DFS-share, время логона упало с 4 минут до 45 секунд.

Итог: 4 часа работы, стоимость 18 000 руб., клиент сэкономил ориентировочно 360 человеко-часов в месяц на ожидании логона (180 ПК × 4 минуты × 20 рабочих дней). Продолжаем сопровождение на абонентской основе.

Чек-лист диагностики GPO

Когда политика не применяется — иду по этому списку сверху вниз, обычно нахожу причину на 3–5 шаге:

1. gpresult /r /scope:computer и /scope:user — что применилось, что отклонено.
2. Проверка OU: в какой OU находится объект (пользователь или компьютер)?
3. GPO привязана к этой OU или родительской без Block Inheritance ниже?
4. Security Filtering содержит Authenticated Users с Read или нужную группу с Apply?
5. WMI-фильтр — есть и корректен для данной машины?
6. Enabled/Disabled у самой GPO — не отключена ли одна из её частей (Computer/User)?
7. Event Viewer → GroupPolicy/Operational — какие ошибки за последние 24 часа?
8. dcdiag /test:sysvolcheck и repadmin /replsummary — репликация между DC работает?
9. Проверка прав на SYSVOL/Policies/{GUID} — у группы Authenticated Users есть Read.

# Полезные команды для быстрой проверки репликации
dcdiag /test:sysvolcheck /test:frsevent /test:dfsrevent
repadmin /replsummary
repadmin /showrepl

# Проверка конкретной политики
Get-GPO -Name "Политика прокси"
Get-GPOReport -Name "Политика прокси" -ReportType Html -Path "C:\Temp\report.html"

Профилактика: как не доводить до разбора полётов

За 15 лет сопровождения корпоративных доменов я выработал набор правил, которые сильно снижают количество инцидентов с GPO:

• Именуйте GPO по шаблону «OU - Назначение - Область». Например, «ALL - Прокси корпоративный - Computer». Через год сами себе спасибо скажете.
• Не плодите политики ради двух настроек. Если GPO содержит одну строку реестра — объедините с соседней.
• Отключайте неиспользуемую половину GPO через User configuration settings disabled / Computer configuration settings disabled — ускоряет логон.
• Documentation — заполняйте вкладку Comment у каждой GPO: кто, когда, зачем создал.
• Backup раз в месяц: Backup-GPO -All -Path \\fileserver\gpo-backups\$(Get-Date -Format yyyyMM).
• Тестовый OU с парой виртуалок — любая новая GPO сначала туда, через неделю — в прод.

FAQ — частые вопросы по диагностике GPO

Почему GPO не применяется к пользователю?

Чаще всего причина одна из четырёх: пользователь не попадает в OU, на которую привязана политика; в Security Filtering нет его группы или стоит Authenticated Users без Read; работает WMI-фильтр с ложным условием; политика блокируется на уровне выше через Block Inheritance. gpresult /r покажет применённые и отклонённые GPO.

Что такое loopback processing и когда он нужен?

Loopback заставляет применять пользовательские настройки GPO из политик, привязанных к OU компьютера. Пригодится для терминальных серверов, переговорных, кассовых рабочих мест — когда политика должна зависеть от того, на какой машине работает человек, а не от его личной OU.

Как быстро обновить политики на клиенте?

gpupdate /force применяет и машинные, и пользовательские политики немедленно, не дожидаясь цикла обновления в 90 минут. Для пользовательских иногда требуется выход и повторный вход, ключ /logoff делает это автоматически.

Что делать, если Event Viewer показывает ошибку 1030 или 1058?

Это классические ошибки доступа к SYSVOL. Проверьте DFS-репликацию между DC, права на папку Policies, доступность \\domain\SYSVOL с клиента. Помогают команды dcdiag /test:sysvolcheck и repadmin /replsummary.

Почему gpresult показывает Access denied?

Стандартный gpresult требует прав администратора. Запускайте от имени администратора или используйте ключ /user domain\user с правами админа. В PowerShell удобнее Get-GPResultantSetOfPolicy или gpresult /h report.html /f.