Долгая обработка 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 у меня было n-ное количество таких подключаемых дисков через механизмы GPP с использованием для каждого подключения нацеливания (Item-level targeting)

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

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

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

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

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

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

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

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