Долгая обработка GPP на этапе "Applying Group Policy Drive Maps policy" на клиентах RODC Windows Server 2008 R2

На этапе внедрения RODC на базе Windows Server 2008 R2 была замечена проблема, связанная с увеличением времени входа в систему на клиентских ПК. Проблема была выявлена на всех площадках, где для авторизации в домене и применения групповых политик клиенты использовали RODC. После ввода учетных данных процесс входа в систему на несколько минут «замерзал» на этапе «Applying Group Policy Drive Maps policy». Разумеется, подозрение сразу пало на обработку Group Policy Preferences (GPP) в части обработки подключения сетевых дисков, так как в одной из групповых политик, применяемых в части User Configuration у нас было некоторое количество таких подключаемых дисков через механизмы GPP с использованием для каждого подключения нацеливания (Item-level targeting).

Для подключения разных дисков использовались три вида нацеливания: по членству пользователя в доменной группе, по NetBios имени компьютера и по вхождению пользователя в определенный OU в домене.
Для того, чтобы выяснить то, обработка какого именно подключения являлась корнем проблемы, пришлось прибегнуть к включению трейсов для обработки параметров GPP. Для этого в групповой политике, применяемой к испытуемому клиентскому компьютеру, в разделе Computer Configuration потребовалось активировать и настроить параметр Policies > Administrative Templates > System > Group Policy >Logging and tracing > Drive Maps Policy Processing.

По умолчанию ведение трейсов выключено и параметры для определения размещения лог файлов ссылаются на каталог %COMMONAPPDATA%\GroupPolicy\Preference\Trace.

Как ни странно, мы не обнаружили на своих испытуемых системах Windows 7/Windows Server 2008 R2 переменной окружения %COMMONAPPDATA% и поэтому изменили путь для хранения логов с использованием существующей переменной окружения - %programDATA%. В данном случае нас интересовал параметр User trace и его значение получилось в нашем случае таким: %programDATA%\GroupPolicy\Preference\Trace\User.log

Уровень логирования пришлось использовать максимальный, чтобы получить весь доступный объем информации о происходящем в процессе обработки GPP. И на всякий случай было увеличено значение максимального размера лог-файла.

После того, как новая политика, включающая логирование применения GPP, была применена на клиенте с помощью команды gpupdate, был выполнен logoff/logon, чтобы спровоцировать обработку GPP в части подключения сетевых дисков пользователю. Теперь на испытуемом клиентском компьютере в указанном каталоге (C:\ProgramData\GroupPolicy\Preference\Trace) был обнаружен файл трассировки User.log.

После изучения лога стало понятно, что обработка GPP всех сетевых дисков проходила «на одном дыхании» и заметный провал во времени обработки (более 1 минуты) происходил именно на одном определенном диске - “H:”

Оказалось что это единственный сетевой диск, в котором для нацеливания использовался признак вхождения пользователя в определенный OU в домене. Было принято решение для пробы изменить нацеливание для данного сетевого диска по признаку членства пользователя в доменной группе… Каково же было наше удивление, когда время входа в систему сократилось в разы :). Приведу лог обработки после внесённых изменений, чтобы не быть голословным.

Причем повторюсь, что проблема наблюдалась только на клиентах, которые сидели в сайте с RODC, а на клиентах, имеющих в сайте полноценные DC такой «бяки» замечено не было.
Исходя из этой истории, напрашивается вывод о том, что к применению Item-Level targeting нужно подходить с аккуратностью и предварительной обкаткой разных вариантов, тем более GPP предоставляет нам хороший выбор таких вариантов.