Ошибка при обработке групповой политики windows не удалось применить основанные на данных реестра
Обновлено: 06.07.2024
В этой статье данная статья позволяет решить проблему, из-за которой Windows 7 Клиенты периодически не применяют групповой политики при запуске.
Применяется к: Windows 7 Пакет обновления 1
Исходный номер КБ: 2421599
Симптомы
Windows 7 клиентов периодически не удается обработка групповой политики при запуске или перезагрузке. В журнале событий System регистрируются следующие события:
Ошибка 9/9/2010 2:43:29 PM NETLOGON 5719 Ошибка 9/9/2010 2:43:31 PM GroupPolicy 1055
Причина
Это поведение вызвано состоянием рас между инициализацией сети, поиском контроллера домена и групповой политикой обработки. Если сеть недоступна, контроллер домена не будет расположен, а обработка групповой политики будет неудачной. После загрузки операционной системы и согласований и установленной сетевой связи обновление фонового фона групповой политики будет успешным.
Следующая последовательность событий отражает условие:
Information <DateTime> EventLog 6006 указывает на отключение системы
Информация e1kexpress 33 указывает на то, что установлена связь сетевого <DateTime> подключения с <speed/duplex>
Information <DateTime> EventLog 6005 указывает, что служба журнала событий запущена
Информация Dhcp-Client 50036 указывает на начало клиентской службы <DateTime> dhcp
Ошибка NETLOGON 5719 указывает, что netlogon не может достичь ни одного <DateTime> из контроллеров домена
Ошибка <DateTime> GroupPolicy 1055 указывает на сбой обработки групповой политики
Information <DateTime> GroupPolicy 1503 указывает на успешность обработки групповой политики
Это также можно подтвердить с помощью netlogon журналов:
Решение
Чтобы решить проблему, можно установить значение реестра, чтобы отложить применение групповой политики:
Откройте редактор реестра.
Расширь следующую подкайку: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Щелкните правой Winlogon кнопкой мыши , указать на New, а затем выберите значение DWORD.
Чтобы назвать новую запись, введите GpNetworkStartTimeoutPolicyValue и нажмите кнопку ENTER.
Щелкните правой GpNetworkStartTimeoutPolicyValue кнопкой мыши, а затем выберите Изменение.
В базовой статье выберите десятичной знак.
В поле Данных Значения введите 60 и выберите ОК.
Выйти из редактора реестра и перезапустить компьютер.
Если сценарий запуска групповой политики не работает, увеличите значение GpNetworkStartTimeoutPolicyValue записи реестра.
Дополнительная информация
Указанное значение должно быть достаточно длинным, чтобы обеспечить подключение. В течение периода ожидания Windows каждые две секунды проверяет состояние подключения и будет продолжать работу с запуском системы, как только подключение будет подтверждено. Поэтому рекомендуется перебиваясь на высокой стороне. Если система отключена законно (например, отключенный сетевой кабель, off-line server и так далее), Windows будет приостановлено на весь период ожидания.
Она также может быть определена с помощью групповой политики:
Расположение политики: > политики > шаблоны администратора > System > Group Policy Setting Name: Клавиша времени ожидания ожидания обработки политики запуска: HKLM\Software\Policies\Microsoft\Windows\System!GpNetworkStartTimeoutPolicyValue
Если вы определите параметр групповой политики, он переопределит параметр вручную. Если параметр ручной и групповой политики не определен, значение выбирается из следующего расположения реестра:
Так как не определен период ожидания, система использует собственный алгоритм для вычисления и прибытия в период среднего времени ожидания. Это значение хранится в расположении реестра выше. Она может отличаться от системы к системе и зависит от различных факторов, например предыдущих попыток входа.
Описание групповой политики для "Время ожидания обработки политики запуска" не является многословным и не охватывает все сценарии. Просто потому, что у нас нет политики, настроенной в настоящее время, это не значит, что мы будем использовать значение времени по умолчанию в 30 секунд.
Примененные объекты групповой политики
---------------------------------------
test
Default Domain Policy
Политика локальной группы
В результирующей политике написано
Примечание: этот параметр реестра не хранится в
разделе политики и поэтому имеет более высокий
приоритет. Если объект групповой политики,
использующий этот параметр, будет удален, сам
параметр сохранится.
Обновление политики пользователя завершено успешно.
Обновление политики для компьютера успешно завершено.
При обработке политики компьютера возвращены следующие предупреждения:
Windows не удалось применить параметры "Scripts". Параметры "Scripts" могут имет
ь свой собственный файл журнала. Щелкните ссылку "Дополнительные сведения".
У меня тут другая трабла(
потребовалось создать некоторые GP. ну в общем создал только они не применяются! GP крайне просты - одна содержит только Logon script в виде bat файла для смены основного шлюза и dns сервера ( в сети используется статическая адресация ) и вторая содержит параметры настройки proxy сервера - указывает путь до proxy.pac файла.
так вот ни та ни другая не применяется на клиентах. Пытался писать gpupdate /force и на сервере и на клиенте. Старые политики как работали так и работают, а вот новые не хотят подхватываться. Политики добавлял в раздел GPM -> Group Policy Object и далее делал ссылки в соответствующих OU в том же GPM на существующую политику. Так работают все нынешние политики - по другому у меня не работало.
В логах клиента и сервера ни чего странного.
задела меня мысля гражданина mattveiko по поводу прав. думаю авось и вправду он прав! Ну прикрутил я значится щас к своему скрипту права админа домена и О ЧУДО! он сработал, НО ладно скрипт, а что делать с обычными настройками GP такими как параметры автоматической конфигурации прокси сервера? я конечно могу написать и для его изменения батник, там всё просто - настройки для IE прокси хранятся в известной ветке реестра.
и всё таки мне всю жизнь казалось что GP применяются именно с правами NT AUTHORITY/SYSTEM.
контроллер домена и и сервер на вин сервер 2008 р2 сп1
создаю пользоваелей и назначаю локальные политки. делаю gpupdate,в 1-й раз принменяются
если потом в политике на какого-ниь юзера менять что-то, то эти измененния не применяются, хотя после gpupdate /force типов все успевшно.
Всё о PowerShell в Windows и на Linux. Системное администрирование Windows
В этом руководстве я постараюсь рассказать вам о типичных причинах, по которым объект групповой политики (GPO) не может быть применён к организационном подразделении (OU), конкретному компьютеру или пользователю домена. Думаю, эта статья будет полезна как новичкам, так и IT-специалистам для понимания работы и архитектуры GPO. Прежде всего, я расскажу о возможных проблемах применения GPO, связанных с настройками политики на уровне домена, вместо устранения проблем с GPO на клиентах. Практически все параметры, описанные в статье, настраиваются с помощью Консоли управления групповыми политиками (GPMC.msc).
Управление областью действия GPO
Если параметр политики не применяется к клиенту, проверьте область действия GPO. Если вы настраиваете параметр в разделе Computer Configuration («Конфигурация компьютера»), ваша групповая политика должна быть сопряжена с организационным подразделением (OU) объектов компьютеров. То же самое верно, если вы установите свои параметры в разделе User configuration («Конфигурации пользователя»).
Также убедитесь, что объект, к которому вы пытаетесь применить свой GPO, находится в правильном контейнере AD (OU) компьютеров или пользователей. Если у вас много объектов и вы не можете вспомнить, в каком организационном подразделении находится нужный вам пользователь или компьютер, то вы можете выполнить поиск по объектам в своём домене. После выполнения поиска, чтобы узнать, в какое организационное подразделение (OU) помещён найденный объект, дважды кликните на него, перейдите на вкладку Object («Объект»), где в поле «Каноническое имя объекта» вы увидите полный путь, включающий имя организационного подразделения.
Это означает, что целевой объект должен находиться в подразделении, с которым связана политика (или во вложенном контейнере AD).
Фильтрация безопасности в GPO
Проверьте настройки Security Filtering («фильтрации безопасности») в своей политике. По умолчанию для всех новых объектов GPO в домене включены разрешения для группы Authenticated Users («Прошедшие проверку»). В эту группу входят все пользователи и компьютеры в домене. Это означает, что политика будет применяться ко всем пользователям и компьютерам в пределах её области действия.
Если вы хотите изменить фильтрацию безопасности, чтобы применить политику только к членам определённой группы безопасности (или определенным пользователям/компьютерам), удалите «Authenticated Users» из списка фильтрации безопасности и убедитесь, что целевой объект (пользователь или компьютер) добавлен в нужную вам группу AD. Также убедитесь, что группа, которую вы добавили в фильтр безопасности, имеет разрешения Read и Apply group policy с установленным флажком Allow («Разрешить») в GPO → Delegation → кнопка Advanced (GPO → Делегирование → кнопка «Дополнительно»).
Если вы используете нестандартные фильтры безопасности GPO, убедитесь, что нет явного запрета на использование GPO для целевых групп (Deny).
Фильтрация GPO WMI
В объекте групповой политики можно использовать специальные фильтры WMI. Таким образом, вы можете применить политику к своим компьютерам на основе некоторого запроса WMI. Например, вы можете создать фильтр WMI GPO для применения политики только к компьютерам с определённой версией Windows, к компьютерам в определённой IP-подсети, только к ноутбукам и так далее.
При использовании фильтрации WMI групповой политики убедитесь, что ваш запрос WMI верен. Он должен выбирать только те системы, которые вам нужны, и ни один целевой компьютер не исключается. Вы можете протестировать свой WMI-фильтр на компьютерах с помощью PowerShell:
Если запрос возвращает какие-либо данные, то к этому компьютеру будет применён фильтр WMI.
Статус GPO
Проверьте статус GPO на вкладке Details свойств политики в GPMC.msc. Обратите внимание на значение в раскрывающемся списке GPO Status («Состояние объекта групповой политики»).
Как видите, доступно 4 варианта:
- All settings disabled (Все настройки отключены) — все настройки политики отключены (GPO не применяется);
- Computer configuration settings disabled (Параметры конфигурации компьютера отключены) — параметры только из конфигурации компьютера вашего GPO не применяются;
- User configuration settings disabled (Параметры конфигурации пользователя отключены) — параметры из раздела конфигурации пользователя не применяются;
- Enabled (Включено) — все настройки GPO применяются к целевым объектам AD (значение по умолчанию).
Делегирование групповой политики
Разрешения, настроенные для политики, отображаются на вкладке «Делегирование» объекта групповой политики. Здесь вы можете увидеть, какие члены группы могут изменять параметры этого объекта групповой политики и применяется ли к ним политика. Вы можете предоставить права на управление GPO с этой консоли или с помощью мастера делегирования Active Directory в ADUC. Если есть разрешение на доступ Enterprise Domain Controllers («Контроллеры домена предприятия»), эта политика может быть реплицирована между контроллерами домена Active Directory (обратите внимание на это, если у вас есть какие-либо проблемы репликации политики между контроллерами домена). Обратите внимание, что разрешения на вкладке «Делегирование» соответствуют разрешениям NTFS, назначенным каталогу политики в папке SYSVOL.
Блокирование наследования и принудительное применение в ссылке групповой политики
Наследование — одна из основных концепций GPO. По умолчанию политики высокого уровня применяются ко всем вложенным объектам в иерархии домена. Однако администратор может заблокировать применение всех унаследованных политик к определённому подразделению. Для этого щёлкните правой кнопкой мыши подразделение в консоли управления групповыми политиками и выберите Block inheritance («Заблокировать наследование»).
Подразделения с включённой опцией заблокированного наследования отмечены синим восклицательным знаком в консоли.
Если политика не применяется к клиенту, проверьте, не принадлежит ли он подразделению с заблокированной опцией наследования.
Обратите внимание, что политики домена с включённым свойством Enformed применяются даже к подразделениям с заблокированным параметром наследования (вы можете увидеть унаследованные политики, применённые к контейнеру, на вкладке Group Policy Inheritance).
Область действия GPO и порядок приоритетной обработки (LSDOU)
Чтобы запомнить порядок, в котором групповые политики применяются в домене, запомните аббревиатуру LSDOU. GPO применяются к клиентам в следующем порядке:
- Политики локального компьютера (Local), настроенные в gpedit.msc (Редактор локальной групповой политики);
- GPO уровня сайта (Site);
- GPO уровня домена (Domain).
- Объекты групповой политики с уровня организационного подразделения (Organizational Unit).
Последние политики имеют наивысший приоритет. Это означает, что если вы включите какой-либо параметр Windows на уровне домена, он может быть отключён другой политикой на уровне организационного подразделения (если представить иерархию AD, то чем ближе в этой иерархии групповая политика к объекту, тем выше у неё приоритет).
При использовании опции Forced («Принудительно») приоритет будет отдаваться политике, стоящей выше в иерархии домена (например, если для политики домена по умолчанию включён параметр Forced («Принудительно»), она будет иметь более высокий приоритет, чем любой другой объект групповой политики).
Администратор также может изменить порядок обработки политики с помощью консоли GPMC (Управление групповой политикой). Для этого выберите подразделение и перейдите на вкладку Linked Group Policy Objects («Связанные объекты групповой политики»). Там вы увидите список GPO, применённых к этому OU с указанным приоритетом. Политики обрабатываются в обратном порядке (снизу вверх). Это означает, что в последнюю очередь будет применяться политика с Link Order 1 (Порядком ссылки 1). Вы можете изменить приоритет GPO, используя стрелки в левом столбце, и переместить политику вверх или вниз в списке.
Link Enabled Setting («Связь включена») для GPO
Для любого объекта GPO, связанного с организационным подразделением AD, может быть включена или отключена опция Link Enabled («Связь включена»). Если связь отключена, её значок становится серым. Когда связь отключена, политика не применяется к клиентам, но ссылка на объект GPO не удаляется из иерархии домена. Вы можете включить связь в любое время.
Как включить GPO Loopback Processing Mode (режим обработки замыкания GPO)
Если вы включили Loopback Processing mode («Режим обработки замыкания»), вы можете применить настройки из раздела «Конфигурация пользователя» к объекту компьютера. Вы можете включить режим кольцевой обработки в следующем разделе редактора GPO: Computer Configuration → Policies → Administrative Templates → System → Group Policy → Configure user Group Policy Loopback Processing mode (в русифицированной версии Конфигурация компьютера → Политики → Административные шаблоны → Система → Групповая политика → Настройка режима обработки замыкания пользовательской групповой политики). Например, если вы включите обработку обратной связи политики, зададите некоторые параметры в разделе «Конфигурация пользователя» и свяжете политику с подразделением с объектами компьютеров, эти параметры политики будут применены к выполнившим вход пользователям.
Этот режим обработки замыкания политики имеет два возможных значения:
- Merge («Слияние») – сначала к пользователю применяется объект групповой политики на основе местоположения пользователя, а затем применяется объект групповой политики, связанный с компьютером. В случае конфликта политик OU пользователя и компьютера, политика компьютера будет иметь более высокий приоритет.
В этом режиме политика запускается дважды, обратите внимание на это при использовании сценариев входа в систему. - Replace («Замена») – к пользователю будут применяться только политики, назначенные подразделению, содержащему компьютер, на котором пользователь вошёл в систему.
Устранение неполадок GPO на стороне клиента
Вы можете диагностировать применение GPO на стороне клиента с помощью gpresult, rsop.msc или Просмотра событий Windows (eventvwr.msc).
Чтобы увидеть журнал событий применения групповых политик, откройте Event Viewer («Просмотр событий»), это можно сделать с помощью команды:
В средстве просмотра событий вы можете фильтровать события по источнику для этого нажмите «Создать настраиваемое представление» и в качестве источника выберите GroupPolicy (Microsoft-Windows-GroupPolicy).
Вы увидите журнал событий, связанных с применением групповых политик:
Такого же результата вы можете достичь если в окне Event Viewer («Просмотр событий») перейдёте по пути Applications and Services Logs → Microsoft → Windows → Applications and Services Logs → Group Policy → Operational (в русскоязычной версии это Журналы приложений и служб → Microsoft → Windows → Group Policy → Operational.
Вы также можете прочитать статью «Устранение неполадок, связанных с медленной обработкой GPO и снижением скорости входа в систему», в которой описаны некоторые дополнительные принципы диагностики объектов групповой политики.
Подводя итог, я рекомендую сделать структуру GPO как можно более простой и не создавать ненужных политик. Используйте прозрачную схему именования политик: имя должно чётко указывать, для чего предназначен объект групповой политики.
Наряду с редактором реестра для тонкой настройки Windows можно использовать редактор локальных групповых политик. Его возможности не столь широки, как у Regedit , зато он более удобен и информативен. Но вот вы в очередной раз запускаете редактор политик привычной командой gpedit.msc и к своему удивлению внезапно получаете ошибку «Не удалось открыть объект групповой политики на этом компьютере. Возможно, у вас недостаточно прав» .
После того, как вы жмете в окне с ошибкой «Закрыть», приложение всё же открывается, но его окно оказывается пустым, а те элементы, которые отображаются, отмечены значком с красным крестиком. Очевидно, что права тут ни при чем, поскольку вы и так работаете с правами администратора.
Чаще всего причиной этой неполадки на клиентских компьютерах становится повреждение файла Registy.pol , хранящего в себе настройки политик, административные шаблоны и некоторые другие служебные данные. Что именно способно вызвать повреждение этого файла, сказать трудно. Возможно, на компьютере имел место какой-то сбой, заражение вирусом, применение «левого» твикера, да мало ли что. Для нас главная задача устранить эту неполадку.
А решение очень простое.
Переходим в Проводнике по адресу %WinDir%\System32\GroupPolicy и переименовываем любым способом папку Machine с файлом Registy.pol .
Запускаем редактор политик из окошка «Выполнить» командой gpedit.msc и — о, чудо! — редактор запускается, а в каталоге GroupPolicy появляется новая папка Machine .
Читайте также: