Методика диагностики причин долгого применения GPO в Windows
Медленная загрузка компьютера, вызванная долгим применением групповых политик, является одной из частых проблем в домене, на которые жалуются пользователи. С точки зрения пользователя компьютер загружается очень долго, и как будто зависает на несколько минут на этапе «Применение параметров компьютера / пользователя». В этой статье я попробую собрать полезные диагностические инструменты и приемы, позволяющие администратору выявить причины медленного применения GPO на компьютерах домена.
На самом деле причин, из-за которых на компьютере долго применяются групповые политики может быть множество: это и проблемы с DNS, доступностью и скоростью подключения к DC, неправильной настройкой сайтов AD или проблемы с репликацией, неверно настроенные групповых политики и кривые скрипты и т.п. Проблематично описать универсальный алгоритм по диагностике всех этих проблем. При решении таких проблем, как правило, большую роль имеет опыт и навыки специалиста, производящего диагностику. В этой статье мы остановимся только на диагностики проблем, связанных с самими механизмами работы GPO и клиента GPClient.
Блокирование наследования групповой политик
Чтобы убедиться, что проблема связана именно с доменными GPO, создайте в домене отдельную OU, перенесите в нее проблемный компьютер и с помощью консоли Group Policy Management Console (GPMC.msc) включите блокирование наследование политик для данного контейнера (Block Inheritance). Таким образом на компьютер перестанут действовать все доменные политики (исключение — политики, для которых включен режим Enforced) .
Перезагрузите компьютер и проверьте, сохранилась ли проблема с долгим применением GPO. Если сохранилась, вероятнее всего проблема с самим компьютером или локальными политиками (попробуйте их сбросить на дефолтные).
Вывод подробных сообщений на экране загрузки
В Windows на экране загрузки системы можно включить отображение расширенной статусной информации, позволяющей пользователям и администратору визуально понять на каком этапе загрузки компьютера наблюдается наибольшая задержка. При включении данной политики, в том числе, начинает отображаться информация о применяемых компонентах GPO.
Включить эту политику можно в следующем разделе GPO:
- в Windows 7 / Vista : Computer Configuration -> Policies -> System ->Verbose vs normal status messages = Enabled
- в Windows 8/10 : Computer Configuration -> Policies -> System ->Display highly detailed status messages = Enabled
Этот же параметр можно активировать через реестр, создав в ветке HKEY_LOCAL_MACHINE\SOFTWARE Microsoft \Windows \CurrentVersion\ Policies\System параметр типа DWORD с именем verbosestatus и значением 1.
В результате на экране в процессе загрузки будут отображаться такие сообщения:
Отчет GPResult
Результирующую политику, которая была применена к компьютеру, стоит проанализировать с помощью HTML отчета gpresult, создать который можно такой командой, запущенной с правами администратора:
gpresult /h c:\ps\gpreport.html
Этот отчет достаточно удобен для анализа и может содержать ссылки на различные ошибки при применении GPO.
Кроме того, в разделе отчета Computer Details -> Component Status присутствуют полезные данные о времени (в мс) применения различных компонентов GPO в виде:
Group Policy Files (N/A) 453 Millisecond(s) 18.01.2017 14:10:01 View Log
Group Policy Folders (N/A) 188 Millisecond(s) 18.01.2017 14:10:00 View Log
Group Policy Local Users and Groups (N/A) 328 Millisecond(s) 18.01.2017 14:10:00 View Log
Group Policy Registry (N/A) 171 Millisecond(s) 18.01.2017 14:10:01 View Log
Group Policy Scheduled Tasks (N/A) 343 Millisecond(s) 18.01.2017 14:10:01 View Log
Scripts (N/A) 156 Millisecond(s) 18.01.2017 14:09:04 View Log
Security (N/A) 3 Second(s) 495 Millisecond(s) 18.01.2017 14:09:08 View Log
Реестр (N/A) 18 Second(s) 814 Millisecond(s) 18.01.2017 14:10:00 View Log
Анализ событий от Group Policy в системных журналах Windows
В журнале приложений о медленном применении политик может свидетельствовать событие с EventID 6006 от источника Winlogon с текстом:
Судя по данному событию, пользователю пришлось ждать применения групповых политик при загрузке компьютера в течении почти часа…
В Windows 7 / Windows 2008 R2 и выше все события, касающиеся процесса применения групповых политик на клиенте доступны в журнале событий Event Viewer (eventvwr.msc) в разделе Applications and Services Logs –> Microsoft -> Windows -> Applications and Services Logs -> Group Policy -> Operational.
Для анализа времени применения политик будут полезны следующие EventID:
- События 4016 и 5016 показывают время начала и завышения процесса обработки расширений применения GPO, причем в последнем указано общую длительность обработки расширения.К примеру, на скриншоте ниже был включен фильтр журнала Group Policy -> Operational по событиям 4016 и 5016. По тексту события 5016 можно увидеть время обработки этого компонента GPO
При анализе журнала стоит также обращать на время, прошедшее между двумя соседними событиями, это может помочь обнаружить проблемный компонент.
Отладочный журнал службы GPSVC
В некоторых ситуациях бывает полезным включить ведение отладочного журнала обработки GPO — gpsvc.log. С помощью временных меток в файле gpsvc.log можно найти компоненты GPO, которые долго отрабатывали.
Отладочные журналы Group Policy Preferences
Расширения Group Policy Preferences также могут вести подробные лог загрузки каждого компоненте CSE (Client-Side Extensions). Отладочные журналы CSE можно включить в разделе GPO: Computer Configuration -> Policies -> Administrative Templates->System->Group Policy -> Logging and tracing
Как вы видите, доступные индивидуальные настройки для каждого CSE. В настройках политики можно указать тип событий, записываемых в журнал (Informational, Errors, Warnings или все), максимальный размер журнала и местоположение лога:
- Трейс файл пользовательских политик %SYSTEMDRIVE%\ProgramData\GroupPolicy\Preference\Trace\User.log
- Трейс файл политик компьютера %SYSTEMDRIVE%\ProgramData\GroupPolicy\Preference\Trace\Computer.log
После сбора логов нужно проанализировать их на ошибки, а также попытаться найти соседние события, время между которыми отличается на несколько минут.
Итак, в этой статье мы рассмотрели основные способы диагностики проблем долгого применения групповых политик на компьютерах домена. Надеюсь, статья будет полезной.
Долгая обработка 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 предоставляет нам хороший выбор таких вариантов.
Разбираемся, почему могут медленно применяться групповые политики в Windows
Медленная загрузка компьютера, вызванная долгим применением групповых политик, является одной из частых проблем в домене, на которые жалуются пользователи. С точки зрения пользователя компьютер загружается очень долго, и как будто зависает на несколько минут на этапе « Применение параметров компьютера / пользователя ». В этой статье я попробую собрать полезные диагностические инструменты и приемы, позволяющие администратору выявить причины медленного применения GPO на компьютерах домена.
На самом деле причин, из-за которых на компьютере долго применяются групповые политики может быть множество: это и проблемы с DNS, доступностью и скоростью подключения к DC, неправильной настройкой сайтов AD или проблемы с репликацией, неверно настроенные групповых политики и кривые скрипты и т.п. Проблематично описать универсальный алгоритм по диагностике всех этих проблем. При решении таких проблем, как правило, большую роль имеет опыт и навыки специалиста, производящего диагностику. В этой статье мы остановимся только на диагностики проблем, связанных с самими механизмами работы GPO и клиента GPClient.
Блокирование наследования групповой политик
Чтобы убедиться, что проблема связана именно с доменными GPO, создайте в домене отдельную OU, перенесите в нее проблемный компьютер и с помощью консоли Group Policy Management Console (GPMC.msc) включите блокирование наследование политик для данного контейнера ( Block Inheritance ). Таким образом на компьютер перестанут действовать все доменные политики (исключение — политики, для которых включен режим Enforced) .
Перезагрузите компьютер и проверьте, сохранилась ли проблема с долгим применением GPO. Если сохранилась, вероятнее всего проблема с самим компьютером или локальными политиками (попробуйте их сбросить на дефолтные).
Вывод подробных сообщений на экране загрузки
В Windows на экране загрузки системы можно включить отображение расширенной статусной информации, позволяющей пользователям и администратору визуально понять на каком этапе загрузки компьютера наблюдается наибольшая задержка. При включении данной политики, в том числе, начинает отображаться информация о применяемых компонентах GPO.
Включить эту политику можно в следующем разделе GPO:
- в Windows 7 / Vista : Computer Configuration -> Policies -> System ->Verbose vs normal status messages = Enabled
- в Windows 8/10 : Computer Configuration -> Policies -> System ->Display highly detailed status messages = Enabled
Этот же параметр можно активировать через реестр, создав в ветке HKEY_LOCAL_MACHINE\SOFTWARE Microsoft \Windows \CurrentVersion\ Policies\System параметр типа DWORD с именем verbosestatus и значением 1.
В результате на экране в процессе загрузки будут отображаться такие сообщения:
Отчет GPResult
Результирующую политику, которая была применена к компьютеру, стоит проанализировать с помощью HTML отчета gpresult , создать который можно такой командой, запущенной с правами администратора:
gpresult /h c:\ps\gpreport.html
Этот отчет достаточно удобен для анализа и может содержать ссылки на различные ошибки при применении GPO.
Кроме того, в разделе отчета Computer Details -> Component Status присутствуют полезные данные о времени (в мс) применения различных компонентов GPO в виде:
Group Policy Files (N/A) 453 Millisecond(s) 18.01.2017 14:10:01 View Log
Group Policy Folders (N/A) 188 Millisecond(s) 18.01.2017 14:10:00 View Log
Group Policy Local Users and Groups (N/A) 328 Millisecond(s) 18.01.2017 14:10:00 View Log
Group Policy Registry (N/A) 171 Millisecond(s) 18.01.2017 14:10:01 View Log
Group Policy Scheduled Tasks (N/A) 343 Millisecond(s) 18.01.2017 14:10:01 View Log
Scripts (N/A) 156 Millisecond(s) 18.01.2017 14:09:04 View Log
Security (N/A) 3 Second(s) 495 Millisecond(s) 18.01.2017 14:09:08 View Log
Реестр (N/A) 18 Second(s) 814 Millisecond(s) 18.01.2017 14:10:00 View Log
Анализ событий от Group Policy в системных журналах Windows
В журнале приложений о медленном применении политик может свидетельствовать событие с EventID 6006 от источника Winlogon с текстом:
Подписчик уведомлений winlogon потратил 3594 сек. на обработку события уведомления (CreateSession).The winlogon notification subscriber took 3594 seconds to handle the notification event (CreateSession).
Судя по данному событию, пользователю пришлось ждать применения групповых политик при загрузке компьютера в течении почти часа…
В Windows 7 / Windows 2008 R2 и выше все события, касающиеся процесса применения групповых политик на клиенте доступны в журнале событий Event Viewer (eventvwr.msc) в разделе Applications and Services Logs –> Microsoft -> Windows -> Applications and Services Logs -> Group Policy -> Operational .
Примечание. В журнале System остались только события, относящиеся к функционирования самой службы Group Policy Client (gpsvc) .
Для анализа времени применения политик будут полезны следующие EventID:
События 4016 и 5016 показывают время начала и завышения процесса обработки расширений применения GPO, причем в последнем указано общую длительность обработки расширения.К примеру, на скриншоте ниже был включен фильтр журнала Group Policy -> Operational по событиям 4016 и 5016. По тексту события 5016 можно увидеть время обработки этого компонента GPOЗавершена обработка расширения Group Policy Local Users and Groups за 1357 мс.
- Событие 5312 содержит список применённых политик, а в событии 5317 есть список отфильтрованных GPO.
В событиях 8000 и 8001 содержится, соответственно, время обработки политик компьютера и пользователя при загрузке компьютера. А в событиях 8006 и 8007 есть данные о времени применения политик при периодическом обновлении.Завершена обработка политики загрузки компьютера для CORP\pc212333$ за 28 с.
При анализе журнала стоит также обращать на время, прошедшее между двумя соседними событиями, это может помочь обнаружить проблемный компонент.
Отладочный журнал службы GPSVC
В некоторых ситуациях бывает полезным включить ведение отладочного журнала обработки GPO — gpsvc.log . С помощью временных меток в файле gpsvc.log можно найти компоненты GPO, которые долго отрабатывали.
Отладочные журналы Group Policy Preferences
Расширения Group Policy Preferences также могут вести подробные лог загрузки каждого компоненте CSE (Client-Side Extensions). Отладочные журналы CSE можно включить в разделе GPO: Computer Configuration -> Policies -> Administrative Templates->System->Group Policy -> Logging and tracing
Как вы видите, доступные индивидуальные настройки для каждого CSE. В настройках политики можно указать тип событий, записываемых в журнал (Informational, Errors, Warnings или все), максимальный размер журнала и местоположение лога:
- Трейс файл пользовательских политик %SYSTEMDRIVE%\ProgramData\GroupPolicy\Preference\Trace\User.log
- Трейс файл политик компьютера %SYSTEMDRIVE%\ProgramData\GroupPolicy\Preference\Trace\Computer.log
Совет . В том случае, если у вас в консоли gpedit/ GPMC в разделе Group Policy отсутствует подраздел Logging and Tracing, нужно будет скачать и установить шаблоны Group Policy Preferences ADMX и скопировать GroupPolicyPreferences.admx из %PROGRAMFILES%\Microsoft Group Policy в локальный каталог PolicyDefinitions либо в централизованный каталог PolicyDefinitions на SYSVOL .
После сбора логов нужно проанализировать их на ошибки, а также попытаться найти соседние события, время между которыми отличается на несколько минут.
Итак, в этой статье мы рассмотрели основные способы диагностики проблем долгого применения групповых политик на компьютерах домена. Надеюсь, статья будет полезной