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

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

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

Чтобы эффективно чинить, нужно сперва понять, как всё устроено. Политики применяются не хаотично, а по строгой цепочке LSDOU: сначала Local, потом Site, затем Domain и в конце OU, двигаясь от корня OU прямо к листу. Каждая следующая политика, кстати, перезаписывает предыдущую, если только на родительской OU не стоит явно Enforced. И, что важно, на каждом уровне есть ещё и три фильтра, которые тоже влияют на процесс.

• 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 рабочих мест в двух офисах. Главная жалоба: после того, как обновили домен до Server 2022, логон стал занимать по 3–5 минут на всех машинах. При этом доменный контроллер новенький, железо мощное, канал между офисами 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.