Из практики админа 01. Медленный вход в систему: групповые политики и принтеры

Один удалённый офис жаловался: вход в Windows занимает несколько минут. Компьютеры там исправные, с SSD, а в главном офисе тот же вход был заметно быстрее. Организация с главным и несколькими удалёнными офисами; файловый сервер и сервер печати стоят в главном офисе. Дальше вместо реальных имён — среда нашей лаборатории: домен lab.example, контроллеры DC1 и DC2, сервер FS1 и рабочая станция PC1.

Разбор интересен порядком действий: сначала измерение, потом гипотеза, и первая гипотеза не подтвердилась. Мы найдём по журналу медленное расширение групповой политики, разберём, почему опция «Remove this item when it is no longer applied» может дорого стоить в удалённом офисе, и разделим политику WMI-фильтрами, с копиями, пилотом и откатом. Это рассказ об одном случае, а не рецепт на все случаи: у такого же симптома в другой сети может быть другая причина.

Что нужно знать заранее

• Основы GPO и gpresult — Windows Server с нуля 06; печать — Windows Server с нуля 09 и Поддержка пользователей 07.
• GPO (Group Policy Object) — объект групповой политики, а GPMC (Group Policy Management Console) — консоль для работы с ними. Расширение на стороне клиента (CSE, client-side extension) — модуль, который на компьютере применяет свою часть политики: параметры реестра, скрипты, предпочтения. Нас интересует расширение «Group Policy Printers».
• Предпочтения (Group Policy Preferences) — настройки, которые политика разворачивает на клиенте, но пользователь может их изменить. Каждый принтер в них — отдельный элемент с действием Create, Replace, Update или Delete. Таргетинг на уровне элемента (item-level targeting) решает, применять ли элемент к данному пользователю или компьютеру.
• Обработка политики при входе бывает синхронной: вход не завершается, пока не применена пользовательская политика. Поэтому медленное расширение прямо удлиняет вход.
• Среда: главный офис — 192.168.10.0/24, шлюз 192.168.10.1; удалённые офисы — условные 198.51.100.0/24 и 203.0.113.0/24 со шлюзами 198.51.100.1 и 203.0.113.1. Принтеры \\FS1.lab.example\PRN-MAIN1, \\FS1.lab.example\PRN-REM1 и GPO USR-Printers-Main названы условно. Команды — для Windows PowerShell 5.1; пункты консоли даны по-английски, в русской консоли они переведены.

Симптомы

• Вход в одном удалённом офисе занимает несколько минут, в главном офисе заметно быстрее.
• Медленно у разных компьютеров этого офиса, а не у одного. Картина «весь офис, а не одна машина» уводит подозрение от дисков и антивируса к среде: сети, серверам, политикам (практика автора).

Как искали причину

Шаг 1. Один цикл обработки — один ActivityId

Начинаем с журнала Microsoft-Windows-GroupPolicy/Operational (Просмотр событий: Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational) на медленном компьютере, сразу после медленного входа. Каждый цикл обработки получает уникальный идентификатор ActivityId. Обработка пользователя и компьютера идёт под разными идентификаторами, а новое обновление создаёт новые.

Внутри цикла каждое расширение оставляет парные записи: событие 4016 (информационное) означает, что расширение начало работу, 5016 (успех) — что завершило. Предупреждение или ошибку вместо 5016 сообщают 6016 и 7016. Номера событий начала и конца всего цикла зависят от того, что запустило обработку (загрузка, вход, ручное обновление), поэтому читайте текст события, а не запоминайте номера. Если у начала нет конца, возможны тайм-аут, сбой службы или очень долгая работа расширения.

Время работы лежит в данных события завершения; поле показано в документации на примере события 7016, поэтому имена полей в «Подробностях» вашего 5016 проверьте. Скрипт собирает время по всем расширениям и показывает самые долгие циклы.

$log = 'Microsoft-Windows-GroupPolicy/Operational'
$rows = Get-WinEvent -FilterHashtable @{
    LogName = $log; Id = 5016, 6016, 7016
    StartTime = (Get-Date).AddDays(-1)
} | ForEach-Object {
    $d = @{}
    ([xml]$_.ToXml()).Event.EventData.Data |
        ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{
        Time     = $_.TimeCreated
        Activity = $_.ActivityId
        Id       = $_.Id
        CSE      = $d['CSEExtensionName']
        Seconds  = [math]::Round(
            [double]$d['CSEElaspedTimeInMilliSeconds'] / 1000, 1)
        Error    = $d['ErrorCode']
    }
}
# самые долгие циклы обработки (сумма по расширениям)
$rows | Group-Object Activity | Select-Object Name, Count,
    @{ n = 'TotalSec'; e = { ($_.Group | Measure-Object Seconds -Sum).Sum } } |
    Sort-Object TotalSec -Descending | Select-Object -First 3
# внутри одного цикла: что тормозит
$id = [guid]'11111111-2222-3333-4444-555555555555'   # из колонки Name выше
$rows | Where-Object { $_.Activity -eq $id } |
    Sort-Object Seconds -Descending |
    Format-Table Time, Id, CSE, Seconds, Error -AutoSize

Пример вывода последней команды (значения вымышлены):

Time                 Id CSE                       Seconds Error
----                 -- ---                       ------- -----
10.11.2026 8:47:09 5016 Group Policy Printers       287.5     0
10.11.2026 8:42:19 5016 Group Policy Drive Maps       3.4     0
10.11.2026 8:42:15 5016 Registry                      0.3     0

У нас картина была такой: из нескольких сотен секунд пользовательской обработки около четырёх пятых занимало расширение «Group Policy Printers».

Шаг 2. Что делает расширение принтеров

Расширение обрабатывает элементы по очереди: проверяет, не отключён ли элемент и выполняется ли его таргетинг, затем делает действие. Create создаёт подключение, если его нет; Update меняет существующее или создаёт; Replace удаляет и создаёт заново; Delete удаляет, а если подключения нет, не делает ничего и ошибки не даёт, но перед этим перебирает установленные принтеры. Страницы расходятся: по описанию предпочтений элементы применяются заново при каждом обновлении, по странице об обработке политик — только при изменении GPO. В нашем случае вход был медленным каждый раз (практика автора).

Ключевая деталь — опция Remove this item when it is no longer applied. Она меняет действие на Replace, то есть результат элемента пересоздаётся, а когда элемент выходит из области действия (из-за таргетинга на уровне элемента, WMI-фильтра или фильтра безопасности), результат удаляется и заново не создаётся. Опция удобна: сменил пользователь офис, и «чужие» принтеры исчезли сами. Но платить приходится операциями: для неприменимого элемента — попыткой удаления (по документации, перебором локальных принтеров), для применимого — удалением и созданием заново на каждом цикле.

Шаг 3. Сравнили офисы

Один и тот же набор политик в главном офисе обрабатывался заметно быстрее. Различие — путь до сервера печати FS1. Подключение общего принтера — сетевая операция (расширение вызывает API AddPrinterConnection). Мы объясняем разницу так: операции дольше выполняются через канал между офисами, и время растёт примерно как число операций × время одной операции. Задержку канала мы не измеряли, а документация не описывает обращений к серверу при удалении отсутствующего подключения: это вывод из замеров, а не цитата.

Определение медленного канала (slow link detection) тяжёлое расширение не отсекло. Оно опирается на два порога: скорость передачи (политика Configure Group Policy slow link detection, по умолчанию 500 килобит в секунду) и, при включённом или ненастроенном кэшировании политик, время ответа контроллера на входе (по умолчанию 500 миллисекунд). Цена множества мелких операций внутри расширения ни в один порог не входит (наше предположение), поэтому канал, быстрый по обоим порогам, может быть медленным для такой работы.

Шаг 4. Посчитали операции

У всех элементов принтеров (их было несколько десятков) стояла опция «Remove this item when it is no longer applied». Для типичного пользователя большинство элементов не применялось, и на каждом цикле расширение выполняло по ним удаление. Вручную от имени пользователя замерили: удаление несуществующего подключения занимает около секунды, добавление нескольких «своих» принтеров — заметно дольше. Условный пример: сорок неприменимых элементов по секунде и ещё несколько десятков секунд на добавление своих принтеров (в основном на один из них, см. выше) — это около полутора минут, то есть заметная доля, но не всё. Замер подключения можно повторить так (принтер условный, подключения ещё нет; тестовое подключение потом удалите штатными средствами Windows):

$p = '\\FS1.lab.example\PRN-REM1'
(Measure-Command { Add-Printer -ConnectionName $p }).TotalSeconds

Это объясняет заметную долю времени, но не всё; остальное мы отнесли на накладные расходы обработки каждого элемента. Подробная трассировка предпочтений включается ключами реестра и требует перезапуска службы групповой политики (практика автора: в документации ключи не описаны). Файлы пишутся в %ProgramData%\GroupPolicy\Preference\Trace; включать её нужно временно и только для нужного расширения. На боевой машине это неудобно, поэтому мы ограничились измерениями.

Что не помогло

Первая гипотеза касалась имени. Один элемент ссылался на имя общего ресурса, а принтер на сервере называется иначе. На клиенте подключение хранится под именем принтера, и мы решили, что политика не находит «своё» и каждый раз подключает заново. Подкрепляло гипотезу то, что подключение именно этого принтера занимало от имени пользователя на порядок дольше остальных. Вероятно, почти всё время добавления «своих» принтеров из шага 4 уходило на него (наше предположение): тогда правка имени могла сэкономить лишь эту долю, незаметную в общем времени. Кроме того, расширение сопоставляет подключение и по имени ресурса, и по имени принтера, так что «потеря» не обязательна.

Мы исправили путь в элементе. Перед этим сделали копии файлов Printers.xml (настройки принтеров) и GPT.ini (там хранится версия политики), после правки подняли версию политики и проверили, что изменения добрались до всех контроллеров. Время обработки почти не изменилось. Вывод: имя было не главной причиной.

Одинаковость GPT.ini на контроллерах проверяют так (только чтение; GUID политики свой):

$guid = '{GPO-GUID}'
foreach ($dc in 'DC1', 'DC2') {
    $p = "\\$dc.lab.example\SYSVOL\lab.example\Policies\$guid\GPT.ini"
    '{0}: {1}' -f $dc, ((Get-Content $p) -match 'Version')
}

Расхождение сразу после правки нормально: идёт репликация. Если оно держится, смотрите репликацию каталога и SYSVOL (Из практики админа 04).

Что сработало

Решение: отдельная GPO для удалённых офисов

Решение принимал владелец инфраструктуры: для удалённых офисов — отдельная GPO только с их принтерами, основная — для остальных. Клиент удалённого офиса обрабатывает несколько элементов вместо всего набора, и число операций через канал падает. Возможны и другие пути: отключить опцию «Remove this item…» там, где она не нужна (тогда Update или Create не пересоздают подключение, но и не снимут его при выходе из области); привязать GPO к сайту Active Directory; задать таргетинг по сайту или диапазону адресов. Но таргетинг без снятия этой опции не отменяет попыток удаления для неприменимых элементов. Мы выбрали разделение политик.

Как отличать офис: WMI-фильтр по маршруту

Признак «компьютер в удалённом офисе» мы определяли по сети, а не по группе безопасности: группу пришлось бы вести вручную, и она ошибётся при переезде компьютера (практика автора). WMI-фильтр — запрос на языке WQL (WMI Query Language) к WMI (Windows Management Instrumentation), который вычисляется на клиенте при обработке политики. На одну GPO ссылается один фильтр, а политика применяется, если запрос вернул хотя бы один объект; если не вернул ни одного, GPO считается отклонённой.

Фильтры создают в GPMC: Group Policy Management → домен → WMI Filters → New → Add, пространство имён root\CIMv2, затем в свойствах GPO выбирают фильтр в разделе WMI Filtering. Класс Win32_IP4RouteTable отражает таблицу маршрутов IPv4 (как route print). Запросы составлены по описанию класса (условие Mask = "0.0.0.0" отбирает именно маршрут по умолчанию — практика автора); проверьте их, как описано ниже:

WMI-RemoteOffices:
SELECT * FROM Win32_IP4RouteTable
  WHERE Destination = "0.0.0.0" AND Mask = "0.0.0.0"
  AND (NextHop = "198.51.100.1" OR NextHop = "203.0.113.1")

WMI-NotRemoteOffices:
SELECT * FROM Win32_IP4RouteTable
  WHERE Destination = "0.0.0.0" AND Mask = "0.0.0.0"
  AND NOT (NextHop = "198.51.100.1" OR NextHop = "203.0.113.1")

Зеркальные фильтры не всегда взаимоисключающие. Если у компьютера нет маршрута по умолчанию (сеть ещё не поднялась), оба запроса пусты, и не применится ни одна GPO. Если маршрутов по умолчанию два (например, ещё и VPN), оба фильтра могут быть истинными, и применятся обе. Проверьте ноутбуки.

Подготовка и пилот: без влияния на пользователей

Копии. Резервная копия основной GPO, файловая копия её Printers.xml и GPT.ini, запись текущих привязок и имени фильтра основной GPO (для отката). Контроллер указывайте явно: без -Server командлет по документации обращается к эмулятору PDC (контроллеру с ролью основного контроллера домена), а у нас без явного контроллера по сети были ошибки доступа (практика автора).

New-Item -ItemType Directory -Force -Path C:\Backup\GPO | Out-Null
Backup-GPO -Name 'USR-Printers-Main' -Path C:\Backup\GPO `
    -Comment 'before split' -Server DC1.lab.example

Копию, лежащую только на контроллере, перенесите на другой сервер (Windows Server с нуля 11).

Новая GPO USR-Printers-Remote. В GPMC создайте её непривязанной, перенесите в неё элементы принтеров удалённых офисов вместе с настройками (в том числе принтера по умолчанию) и отключите неиспользуемую половину политики: так обработка быстрее. Нужна ли новым элементам опция «Remove this item…», решите осознанно.

Пилот. Создайте оба WMI-фильтра, но к боевым GPO пока не привязывайте.

Шаг 1. Привяжите USR-Printers-Remote к тестовому подразделению с тестовыми пользователем и компьютером удалённого офиса и выберите ей фильтр WMI-RemoteOffices. В рабочие контейнеры её пока не привязывайте.

Шаг 2. До смены фильтра боевой GPO проверьте оба запроса на компьютерах каждого офиса (команда только читает данные):

$base = "SELECT * FROM Win32_IP4RouteTable WHERE Destination = '0.0.0.0'" +
    " AND Mask = '0.0.0.0' AND "
$gw = "NextHop = '198.51.100.1' OR NextHop = '203.0.113.1'"
'Remote:    ' + @(Get-CimInstance -Query ($base + "($gw)")).Count
'NotRemote: ' + @(Get-CimInstance -Query ($base + "NOT ($gw)")).Count

Для компьютера удалённого офиса ожидается Remote: 1 и NotRemote: 0. Два нуля означают, что маршрута по умолчанию нет; обе величины не меньше единицы — маршрутов по умолчанию несколько: такие машины остаются без GPO или получают обе.

Шаг 3. WMI-NotRemoteOffices проверьте на копии основной GPO (копирование есть в GPMC), привязанной к тому же тестовому подразделению, и только потом меняйте фильтр боевой GPO.

Переключение вечером

Новая GPO подготовлена заранее, поэтому в окне только ссылки и фильтры, а откат прост. Пользователи согласны на однократное переподключение принтеров; по описанию опции удаления оно ожидаемо: основная GPO для удалённого офиса выходит из области, её элементы снимают подключения, а новая GPO создаёт нужные заново.

1. Привяжите USR-Printers-Remote к тому же контейнеру, что и основную GPO, и выберите ей фильтр WMI-RemoteOffices.
2. Замените фильтр основной GPO на WMI-NotRemoteOffices. Ссылка на фильтр у GPO одна, поэтому всё, что делал прежний фильтр основной GPO, перенесите в новый запрос или убедитесь, что оно не нужно.
3. Проверьте результат для тестового пользователя в удалённом офисе: надёжнее всего Group Policy Results в GPMC (выберите тестовые компьютер и пользователя; среди применённых должна быть USR-Printers-Remote, основная — отклонена). gpresult /h gp.html годится в сеансе самого тестового пользователя, иначе пользовательская часть отчёта будет про администратора. Повторите проверку в главном офисе.
4. Снова запустите скрипт из шага 1 и сравните время «Group Policy Printers» с прежним.

В нашем случае переключение было назначено на вечер, а результат после него в разбор не вошёл, поэтому мы его не приводим: сравнивайте сами, по тому же скрипту, до и после.

Откат

1. Удалите ссылку новой GPO (GPMC: Delete Link(s)). Удаление ссылки не удаляет саму политику.
2. Верните основной GPO прежний WMI-фильтр.
3. Если в окне правились и файлы политики, восстановите Printers.xml из копии и поднимите версию, как описано выше (в нашем плане отката этот шаг был предусмотрен). Если менялись только ссылки и фильтры, шаг не нужен.

Подключения, которые успела создать новая GPO, после отката исчезнут или останутся в зависимости от опции удаления на её элементах: проверьте результат на тестовом пользователе.

Выводы и чек-лист

Состояние на ноябрь 2026 года (проверьте актуальность). Описание расширения принтеров, общих опций предпочтений и создания WMI-фильтров — архивные страницы (Windows Server 2012 R2 и 2012): в новых версиях поведение могло измениться. Поле времени выполнения расширения показано на примере события 7016, а набор событий зависит от сборки и триггера обработки (учебный модуль Learn). Названия пунктов даны по английской документации; в русской консоли они переведены.

Типичные ошибки и недоразумения

• Исправить по первой гипотезе и не замерить. Правка имени выглядела логичной, но общего времени не изменила.
• Опция «Remove this item…» на всех элементах «для порядка». Она не бесплатна: каждый цикл — попытка удаления или пересоздание, и в удалённом офисе, по нашему предположению, это минуты.
• Править Printers.xml вручную и забыть про версию. Изменившиеся GPO клиент определяет по версии.
• Считать, что фильтр и его «зеркало» покрывают всех. Пустой результат запроса — отказ, поэтому возможны компьютеры без единой GPO.
• Считать, что определение медленного канала само отсечёт тяжёлое расширение. Оно смотрит на скорость передачи и (при кэшировании) на время ответа контроллера, а не на число мелких операций внутри расширения.
• Не указывать контроллер. Без -Server командлеты идут к эмулятору PDC, и по сети это может закончиться ошибками доступа.
• Считать, что «политика применилась» значит «все элементы отработали». Ошибки отдельных элементов ищите в журнале «Приложение» (события расширения предпочтений) и в журнале расширения.

Проверьте себя

1. Как по журналу найти, какое расширение групповой политики замедляет вход? Выделить цикл по ActivityId, сопоставить начало (4016) и завершение (5016, 6016, 7016) каждого расширения и сравнить время из данных события.
2. Что меняет опция «Remove this item when it is no longer applied»? Переводит действие в Replace: элемент пересоздаётся на каждом цикле, а при выходе из области действия (таргетинг, WMI-фильтр, фильтр безопасности) его результат удаляется и заново не создаётся.
3. Когда применяется GPO с WMI-фильтром и почему зеркальные фильтры нужно проверять? Когда запрос вернул хотя бы один объект; пустой результат — отказ. Без маршрута по умолчанию оба зеркальных фильтра ложны, при двух маршрутах оба могут быть истинными.
4. Что нужно сделать, если пришлось править файл политики вручную? Сделать копии файла и GPT.ini, поднять версию в GPT.ini и в Active Directory, проверить репликацию и подготовить откат; проще править через GPMC.
5. Почему определение медленного канала не объясняет нашу проблему? Его пороги — скорость передачи (по умолчанию 500 килобит в секунду) и время ответа контроллера (по умолчанию 500 миллисекунд при кэшировании политик); суммарная цена множества мелких операций расширения в них не входит.

Что дальше

• Windows Server с нуля 06. Групповые политики (GPO) — основы, порядок применения, фильтры и пилотные подразделения.
• Windows Server с нуля 09. Сервер печати и принтеры — как устроена печать и раздача принтеров политиками.
• Поддержка пользователей 07. Принтеры и сканеры — диагностика принтера на стороне пользователя.
• Из практики админа 04. Обслуживание AD: SYSVOL, DFSR и «сироты» — если политика не доезжает до всех контроллеров.

Источники

• Group Policy processing — синхронная и асинхронная обработка, порядок расширений, WMI-фильтр и фильтр безопасности, оптимизация GPO
• Group Policy Management Console — создание непривязанной GPO, привязка и удаление ссылки, копирование и восстановление GPO, отключение половины политики, Group Policy Results
• Working with Group Policy Preference Items Using the GPMC (архив, WS 2012 R2) — общие опции элемента, «Remove this item when it is no longer applied» и действие Replace, таргетинг
• Printers (Group Policy Preferences) (архив, WS 2012 R2) — действия Create, Replace, Update, Delete, API AddPrinterConnection, порядок обработки элементов, сопоставление принтеров, версия GPO
• Applying Group Policy troubleshooting guidance — ActivityId, события 4016 и 5016, gpresult /h, журнал Operational
• Interpret event logs and client-side extension failures (учебный модуль) — фазы обработки, парные события, 6016 и 7016, журнал «Приложение», версии, сравнение путей SYSVOL, временная трассировка предпочтений
• Group Policy error events logged when unknown environment variable is used — пример события 7016 с полями времени выполнения расширения
• Get-CimInstance — параметр -Query, запрос на языке WQL
• [MS-GPOL]: WMI Filter Evaluation — фильтр истинен, если запрос вернул хотя бы один объект
• Create WMI Filters for the GPO (архив, WS 2012) — создание фильтра в GPMC, пространство имён root\CIMv2, привязка к GPO
• Win32_IP4RouteTable class (архив) — свойства Destination, Mask и NextHop, таблица маршрутов IPv4
• WHERE Clause (WQL) — операторы AND, OR, NOT и скобки
• ADMX_GroupPolicy Policy CSP — определение медленного канала: порог скорости 500 килобит в секунду и порог времени ответа контроллера при кэшировании политик, расширения в медленной сети
• Backup-GPO — копия GPO, параметры -Path, -Comment, -Server, по умолчанию эмулятор PDC
• Add-Printer — параметр -ConnectionName для подключения общего принтера