Ошибка 6006 winlogon

Upon starting a Server running 2012 R2 standard I get errors 6005 & 6006.  I feel that this is caused by a service that needs to be made to have a delayed start.  It is caused by Winlogin however I do not know what services to look at for this.
 Most issues I have found on google is for the <Gpclient>, but this service is not my issue. The server does seem a bit sluggish on a reboot. Below is the information from the logs.  Any help would be very appreciated.

Event id 6006

The winlogon notification subscriber <TrustedInstaller> took 77 second(s) to handle the notification event (CreateSession).

Details

Event id 6005 

The winlogon notification subscriber <TrustedInstaller> is taking long time to handle the notification event (CreateSession).

Details

— System 

  — Provider 

   [ Name]  Microsoft-Windows-Winlogon 
   [ Guid]  {DBE9B383-7CF3-4331-91CC-A3CB16A3B538} 
   [ EventSourceName]  Wlclntfy 

 
  — EventID 6005 

   [ Qualifiers]  32768 

 
   Version 0 

 
   Level 3 

 
   Task 0 

 
   Opcode 0 

 
   Keywords 0x80000000000000 

 
  — TimeCreated 

   [ SystemTime]  2014-12-12T05:35:50.000000000Z 

 
   EventRecordID 70848 

 
   Correlation 

 
  — Execution 

   [ ProcessID]  0 
   [ ThreadID]  0 

 
   Channel Application 

 
   Computer CLC-PDC01.CLC.local 

 
   Security 

— EventData 

   TrustedInstaller 
   CreateSession 
   00000000 

———————————————————————————

Binary data:

In Words

0000: 00000000    

In Bytes

0000: 00 00 00 00               ….

Медленная загрузка компьютера, вызванная долгим применением групповых политик, является одной из частых проблем в домене, на которые жалуются пользователи. С точки зрения пользователя компьютер загружается очень долго, и как будто зависает на несколько минут на этапе «Применение параметров компьютера / пользователя». В этой статье я попробую собрать полезные диагностические инструменты и приемы, позволяющие администратору выявить причины медленного применения 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_MACHINESOFTWARE Microsoft Windows CurrentVersion PoliciesSystem параметр типа DWORD с именем verbosestatus и значением 1.

В результате на экране в процессе загрузки будут отображаться такие сообщения:

Отчет GPResult

Результирующую политику, которая была применена к компьютеру, стоит проанализировать с помощью HTML отчета gpresult, создать который можно такой командой, запущенной с правами администратора:

gpresult /h c:psgpreport.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 <GPClient> потратил 3594 сек. на обработку события уведомления (CreateSession).

The winlogon notification subscriber <GPClient> 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 есть данные о времени применения политик при периодическом обновлении.

  Завершена обработка политики загрузки компьютера для CORPpc212333$ за 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%ProgramDataGroupPolicyPreferenceTraceUser.log
• Трейс файл политик компьютера %SYSTEMDRIVE%ProgramDataGroupPolicyPreferenceTraceComputer.log

Совет. В том случае, если у вас в консоли gpedit/ GPMC в разделе Group Policy отсутствует подраздел Logging and Tracing, нужно будет скачать и установить шаблоны Group Policy Preferences ADMX и скопировать GroupPolicyPreferences.admx из %PROGRAMFILES%Microsoft Group Policy в локальный каталог PolicyDefinitions либо в централизованный каталог PolicyDefinitions на SYSVOL.

После сбора логов нужно проанализировать их на ошибки, а также попытаться найти соседние события, время между которыми отличается на несколько минут.

Итак, в этой статье мы рассмотрели основные способы диагностики проблем долгого применения групповых политик на компьютерах домена. Надеюсь, статья будет полезной.

Довольно часто пользователи домена жалуются на медленный запуск компьютера и время входа в систему, вызванные длительной обработкой групповых политик (GPO). С точки зрения пользователя, компьютер долго загружается и, кажется, зависает на несколько минут на этапе «Применение настроек компьютера/пользователя». В этой статье я постараюсь собрать полезные средства диагностики и методы, позволяющие администратору определять причины медленного применения GPO на компьютерах домена.

На самом деле, существует ряд причин, по которым групповые политики требуют много времени для применения: это могут быть проблемы с DNS, доступность DC и скорость подключения к нему, неправильная конфигурация сайтов AD или проблемы репликации, неправильно настроенные групповые политики, неправильные скрипты и так далее. Трудно описать универсальный алгоритм для диагностики всех этих проблем. При решении подобных задач, как правило, важную роль играет опыт и навыки администратора, проводящего диагностику. В этой статье мы сосредоточимся только на диагностике проблем с механизмами GPO и GPClient.

Как заблокировать наследование групповой политики

Чтобы убедиться, что проблема связана с GPO домена, создайте в домене отдельную OU и переместите на неё проблемный компьютер. Затем с помощью консоли управления групповыми политиками (GPMC.msc) включите блокировку наследования политики для этого контейнера (Block Inheritance). Таким образом, все политики домена перестанут применяться к этому контейнеру (за исключением политик с включённым принудительным режимом).

Перезагрузите компьютер и проверьте, сохраняется ли проблема с медленным применением GPO. Если проблема не исчезнет, скорее всего, проблема в самом компьютере или в локальных групповых политиках (попробуйте сбросить их до значений по умолчанию).

Как отобразить подробную информацию на экране загрузки

В Windows можно включить отображение подробной информации о состоянии, что позволяет пользователям и администратору наглядно понять, на каком этапе загрузки компьютера наблюдается наибольшая задержка. Если вы включите эту политику, также отображается информация о применяемых компонентах GPO.

Вы можете включить эту политику в Group Policy Management Editor («Редакторе управления групповыми политиками»). Для этого откройте откройте Group Policy Management («Управление групповой политикой»), например, это можно сделать в командной строке:

GPMC

Выберите групповую политику, которую вы хотите изменить, кликните по ней правой кнопкой мыши и нажмите Edit («Изменить»).

Вы найдёте нужную настройку следующем разделе GPO:

• в Windows 7/Vista: Computer Configuration → Policies -> System → Verbose vs normal status messages = Enabled (в русскоязычной версии это Конфигурация компьютера → Политики → Система → Подробные и обычные сообщения о состоянии = Включено)
• в Windows 8/10: Computer Configuration → Policies → Administrative Templates → System → Display highly detailed status messages = Enabled (в русскоязычной версии это Конфигурация компьютера → Политики → Административные шаблоны → Система → Выводить очень подробные сообщения о состоянии системы = Включено)

Этот же параметр можно активировать через реестр. Для этого создайте параметр DWORD с именем verbosestatus и значением 1 в разделе реестра HKEY_LOCAL_MACHINESOFTWARE Microsoft Windows CurrentVersionPoliciesSystem.

В результате во время загрузки вы увидите на экране следующие сообщения:

Отчёт GPResult

Лучше проанализировать результирующую политику, применённую к компьютеру, с помощью HTML-отчета GPResult, который можно создать с помощью следующей команды, запущенной с правами администратора:

gpresult /h c:scriptsgpreport.html

Смотрите также: Использование инструмента GPResult для проверки того, какие объекты групповой политики применяются

Этот отчёт довольно удобен для анализа и содержит ссылки на ошибки при применении GPO.

Кроме того, в разделе Computer Details → Component Status (на русском это «Сведения о компьютере» → «Состояние компонента») отчёта содержатся полезные данные о времени затраченное на применение (в мс) различных компонентов GPO, которые выглядят следующим образом:

Group Policy Files (N/A) 432 Millisecond(s) 19.02.2017 11:10:01 View Log
Group Policy Folders (N/A) 188 Millisecond(s) 19.02.2017 11:10:00 View Log
Group Policy Local Users and Groups (N/A) 338 Millisecond(s) 19.02.2017 11:10:00 View Log
Group Policy Registry (N/A) 171 Millisecond(s) 19.02.2017 11:10:01 View Log
Group Policy Scheduled Tasks (N/A) 353 Millisecond(s) 19.02.2017 11:10:01 View Log
Scripts (N/A) 156 Millisecond(s) 19.02.2017 11:09:04 View Log
Security (N/A) 3 Second(s) 495 Millisecond(s) 19.02.2017 11:09:08 View Log
Registry (N/A) 18 Second(s) 814 Millisecond(s) 19.02.2017 11:10:00 View Log

Анализ событий групповой политики в системных журналах Windows

В журнале приложения идентификатор события 6006 из Winlogon со следующим сообщением может свидетельствовать о медленном применении политики:

The winlogon notification subscriber <GPClient> took 3104 seconds to handle the notification event (CreateSession).

Перевод: Подписчику уведомления winlogon <GPClient> потребовалось 3104 секунды для обработки события уведомления (CreateSession).

Согласно этому событию, пользователю приходилось ждать применения групповых политик при загрузке почти час…

В Windows 7 / Windows 2008 R2 или выше все события, связанные с обработкой групповой политики на клиенте, доступны в Event Viewer («Просмотр событий»), его можно открыть в командной строке:

eventvwr.msc

В окне Event Viewer («Просмотр событий») перейдите по пути Applications and Services Logs → Microsoft → Windows → Applications and Services Logs → Group Policy → Operational (в русскоязычной версии это Журналы приложений и служб → Microsoft → Windows → Group Policy → Operational).

В Event Viewer («Просмотр событий») вы также можете фильтровать события по источнику для этого нажмите «Создать настраиваемое представление» и в качестве источника выберите GroupPolicy (Microsoft-Windows-GroupPolicy).

Вы увидите журнал событий, связанных с применением групповых политик:

Примечание. В системном журнале остаются только события, связанные с работой самого Клиента групповой политики (gpsvc).

Для анализа времени применения политики будут полезны следующие EventID (Коды событий):

• События с идентификаторами 4016 и 5016 показывают время начала и окончания обработки расширений приложения GPO. Последний также указывает общее время обработки расширения. Например, на скриншоте ниже была включена фильтрация Group Policy → Operational по EventID 4016 и 5016. В сообщении EventID 5016 вы можете увидеть время обработки этого компонента GPO.

Завершена обработка расширения Security за 266 мс.

• EventID 5312 содержит список применённых политик, а EventID 5317 показывает список отфильтрованных GPO.
• EventID 8000 и 8001 содержат время обработки политик компьютера и пользователя во время загрузки соответственно. А в EventID 8006 и 8007 есть данные о времени применения политики при регулярных обновлениях.

Завершена обработка политики загрузки компьютера для DSHACKWARE-WIN$ за 28 с.
Завершена обработка политики входа пользователя для DSAdministrator за 5 с.

Анализируя журнал, обратите внимание на время между двумя соседними событиями. Это может помочь найти проблемный компонент.

Журналы отладки предпочтений групповой политики

Расширения предпочтений групповой политики также могут регистрировать загрузку каждого компонента CSE (клиентских расширений). Журналы отладки CSE можно включить в следующем разделе GPO: Computer Configuration -> Policies -> Administrative Templates->System->Group Policy -> Logging and tracing (в русскоязычной версии это путь Конфигурация компьютера → Политики → Административные шаблоны → Система → Групповая политика → Ведение журнала и трассировка).

Как видите, индивидуальные настройки доступны для каждой каждого Client-Side Extensions (CSE). В настройках политики вы можете указать тип регистрируемого события Informational, Errors, Warnings (Информационное, Ошибки, Предупреждения) или все, максимальный размер журнала и путь к его расположению:

• Файл трассировки политики пользователя %SYSTEMDRIVE%ProgramDataGroupPolicyPreferenceTraceUser.log
• Файл трассировки политики компьютера %SYSTEMDRIVE%ProgramDataGroupPolicyPreferenceTraceComputer.log

Подсказка: Если у вас нет подраздела «Ведение журнала и трассировка» в разделе «Групповая политика» консоли gpedit.msc / GPMC, загрузите и установите шаблоны ADMX предпочтений групповой политики и скопируйте GroupPolicyPreferences.admx из %PROGRAMFILES%Microsoft Group Policy в локальную папку PolicyDefinitions. или в центральный каталог PolicyDefinitions в SYSVOL.

Собрав логи, нужно проанализировать их на наличие ошибок, а также попытаться найти ближайшие события, время между которыми отличается на несколько минут.

Итак, в этой статье мы рассмотрели основные способы диагностики медленной обработки групповой политики на компьютерах домена. Надеюсь, статья будет полезной.

Hi guys,

I am having trouble with my own work comp here — however it seems to be more related to my profile or something. My logons in the morning take approx 15-25mins to logon, logoffs are slightly shorter at around 15-20mins. Event Viewer shows me the following;

The winlogon notification subscriber <Profiles> took 1473 second(s) to handle the notification (Logon).

Event ID is 6006 for this.

And then for logoff I get the same, except the second(s) count, this particular time, was at 1712 seconds.

I have tried logging onto a laptop, which I have never logged onto before with my profile, and am getting the exact same error. My profile isn’t overly large, but once logged on, it should save my server-downloaded documents so further logins should be no more than a minute. Some google searches brought up resutls about possible problems with GPOs or that maybe Windows is looking for printer drivers on logon, but I can’t see why.

The problem seems to just apply to me, regardless of where I log on.

I am running Windows 7 Professional 32-bit and the domain server is Windows Server 2003 Standard. Note, that I have also tried logging onto Windows XP Pro clients as that’s what the bulk of users here are on, same problem.

Thanks very much in advance guys.

Mark