На этапе внедрения 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 предоставляет нам хороший выбор таких вариантов.