На этапе внедрения 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 предоставляет нам хороший выбор таких вариантов.
Бывало что меняли сетевую карточку на новую, а ОС Windows помнит старые настройки и мешает использовать их на новом устройстве? 
RSS - Записи
Последние комментарии