Утилита командной строки GPResult.exe используется для получения результирующего набора групповых политик (Resultant Set of Policy, RSOP), которые применяются к пользователю и/или компьютеру в домене Active Directory. Gpresult позволяет вывести список доменных политик (GPO), которые применяются на компьютер и пользователя, настройки политик и ошибки обработки. Это наиболее часто используемый инструмент администратора для анализа настроек и диагностики групповых политик в Windows.
В этой статье мы рассмотрим, как использовать команду GPResult для диагностики и анализа настроек групповых политик, применяющихся к Windows в домене Active Directory.
Использование команды GPResult в Windows
Команда GPResult выполняется на компьютере, на котором нужно проверить применение групповых политик. Синтаксис GPResult:
Чтобы получить подробную информацию о групповых политиках, которые применяются к данном объекту AD (пользователю и компьютеру), и других параметрах, относящихся к инфраструктуре GPO (т.е. результирующие настройки политик GPO – RsoP), выполните команду:
Результаты выполнения команды разделены на 2 секции:
Вкратце пробежимся по основным параметрам/разделам, которые нас могут заинтересовать в выводе GPResult:
В нашем примере видно, что на объект пользователя действуют 4 групповые доменные политики.
Также в отчете будет информацию о локальных параметрах политик, настроенных через локальный редактор GPO (gpedit.msc).
С помощью опции /scope можно вывести только политики пользователя или компьютера:
или только примененные политики компьютера:
gpresult /r /scope:computer
Если вы попробуете получить список GPO, примененных к компьютеру, под пользователем без прав локального администратора, команда gpresult вернет ошибку отказа в доступе:
ERROR: Access Denied.
Для удобства анализа данных RSOP, вы можете перенаправить результаты Gpresult в буфер обмена:
или текстовый файл:
Чтобы вывести сверхподробную информацию RSOP, нужно добавить ключ /z.
Gpresult /r /z
Например, на скриншоте показаны настройки политики паролей в домене, которые применяются к компьютеру.
Экспорт данных RSOP в HTML отчет
Утилита GPResult позволяет сгенерировать HTML-отчет по примененным результирующим политикам (доступно в Windows 7 и выше). Такой отчет содержит подробную информацию обо всех параметрах Windows, которые задаются групповыми политиками и именами GPO, которые внесли изменения. Этот отчет по структуре напоминает вкладку Settings в консоли управления доменными групповыми политиками (
gpmc.msc
). Сгенерировать HTML отчет GPResult можно с помощью команды:
GPResult /h c:gp-report
eport.html /f
Если не указывать полный путь к HTML файлу, то HTML отчет gpresult будет сохранен в каталог
%WINDIR%system32
.
Чтобы сгенерировать отчет и автоматически открыть его в браузере, выполните команду:
GPResult /h GPResult.html & GPResult.html
Например, на скриншоте выше видно, что политика Enforce password history с настройками 24 passwords remember применена политикой Default Domain Policy (столбец Winning GPO).
HTML отчет позволяет представить результирующий набор GPO компьютера в удобном графическом виде.
Получение отчета по политикам GPResult с удаленного компьютера
GPResult может получить информацию о результирующих политик с удаленного компьютера.
В команде gpresult можно указать имя и пароль для подключения к удаленному компьютеру:
Аналогичным образом вы можете удаленно собрать данные как по пользовательским политикам, так и по политиками компьютера.
Если вы не знаете имя пользователя, под которым выполнен вход, можно узнать учетную запись на удаленном компьютере так:
HTML отчет RSOP, аналогичный тому, который формирует команда gpresult можно создать с помощью PowerShell. Для получения результирующих политик с удаленного компьютера используется командлет Get-GPResultantSetOfPolicy из модуля GroupPolicy.
Пользователь не имеет данных RSOP
Также проверьте время (и часовой пояс) на клиенте. Время должно соответствовать времени на PDC (Primary Domain Controller).
Следующие политики GPO не были применены, так как они отфильтрованы
Оснастка результирующих политик RSoP в Windows
Изначально для диагностики применения групповых политик в Windows использовалась графическая консоль
RSOP.msc
. Эта оснастка позволяет получить настройки результирующих политик (доменных + локальных), примененных к компьютеру и пользователю в графическом виде аналогичном консоли редактора GPO. На скриншоте показа вид консоли RSOP.msc в которой видно, что настройки Windows Update на компьютере заданы доменной политикой WSUS_SERVERS.
В современных версиях Windows RSOP.msc не получится использовать для полноценного анализа примененных GPO. Она не отражает настройки, примененные через расширения групповых политик CSE (Сlient Side Extensions), таких как GPP (Group Policy Preferences), не позволяет выполнять поиск, предоставляет мало диагностической информации. В Windows 10 и 11 при запуске
rsop.msc
появилось предупреждение, что основной инструмент для диагностики применения GPO это утилита gpresult.
В этой статье мы рассмотрели, как использовать утилиту GPResult для анализа результирующих групповых политик, которые применяются в Windows. Также для анализа применения GPO в домене рекомендуем использовать инструкции из статьи “Почему групповая политика не применяется к компьютеру или OU”.
Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. В прошлый раз мы с вами подробно разобрали сетевую технологию VLAN и ее применение. В сегодняшней статье я расскажу, как решил вот такую ситуацию на одном из терминальных столов. Нужно мне было проверить применение групповых политик для пользователя, в момент диагностики я, как обычно попытался воспользоваться утилитой GPresult, но в итоге получил ошибку «Пользователь не имеет данных RSOP«. Давайте разбираться в чем дело.
Я подумал, ладно пойду другим путем и попробую проверить применение политик GPO через RSOP, но и тут я получил ошибку:
Не удалось создать данные результирующей политики из-за указанных ниже ошибки. Недостаточно памяти.
Если посмотреть журнал с логами Windows, то вы обнаружите вот такое предупреждение:
Код события 1090: Windows не удалось записать информацию результирующей политики (RSoP), которая описывает область применения объектов групповой политики к этому компьютеру или пользователю. Возможные причины: отключение или остановка службы WMI (инструментария управления Windows), иные ошибки WMI. Параметры групповой политики были успешно применены к этому компьютеру или пользователю, но, возможно, средства управления сообщают неверные данные.
Первым делом проверьте, что у вас в запущенном состоянии служба инструментария управления Windows (Winmgmt). Для этого откройте оболочку PowerShell и введите команду:
Если у вас будет статус «Stop», то введите команду:
Так же вы можете перезапустить сервис, командой:
Следующим шагом я вам советую добавить ключ в реестр Windows. Переходим в ветку:
Создаем ключ dword32
с именем GroupPolicyMinTransferRate и значением 0
И точно такой же в ветке:
Создаем ключ dword32 с именем GroupPolicyMinTransferRate и значением 0. Перезагружаем компьютер или сервер. Данная манипуляция в большинстве случаев исправляет ошибку GPResult пользователь не имеет данных RSOP.
Если первый метод не помог, то пробуем удалить из реестра всю историю объекта групповой политики из профиля пользователя. Перед удалением обязательно сделайте резервную копию ветки реестра.
После чего в командной строке вводим gpupdate /force, а затем gpresult /h. В итоге ошибка «Пользователь не имеет данных RSOP», должна пропасть. Еще одним методом устранения проблемы в обработке результирующей политики, является вывод компьютера из домена Active Directory, и повторный ввод в домен.
Дополнительные решения
Надеюсь мое небольшой опыт окажется вам полезным, а с вами был Иван Семин, автор и создатель IT блога Pyatilistnik.org.
Создаем ключ dword32 с именем GroupPolicyMinTransferRate и значением . Перезагружаем компьютер или сервер. Данная манипуляция в большинстве случаев исправляет ошибку GPResult пользователь не имеет данных RSOP.
Windows не удалось записать информацию результирующей политики rsop
запустить из под администратора, не?
у обычного пользователя может не хватать прав(хотя консоль должна при запуске об этом предупреждать)
в открывшейся оснастке посмотрите детальную ошибку и/или попробуйте выгрести ошибку из gpresult
The opinion expressed by me is not an official position of Microsoft
Причем интересная фишка. R SOP не показывает политики компьютера. А вот GPResult наоборот, не показывает политики пользователя. =)
Доброго времени суток! Уважаемые читатели IT блога pyatilistnik.org. Продолжаем собирать решения для различных проблемных ситуаций связанных со службами удаленных рабочих столов, сегодня я хочу вам осветить такую ситуацию. Есть терминальная ферма на базе Windows Server 2008 R2, в ней для управления настройками сеансов пользователей используется удобная оснастка «Конфигурация узла сеансов удаленных рабочих столов» и вот при попытке ее открыть появляется ошибка, что не удалось получить параметры данного сервера узла сеансов удаленных рабочих столов. После чего оснастка благополучно закрывается, понятно, что можно задать параметры через групповые политики, но сам факт ошибки уже не приятен. давайте я покажу, что я делал, чтобы ее исправить.
Описание проблемы
И так есть терминальная ферма, состоящая из 5 хостов на Windows Server 2008 R2, в качестве посредника подключений используется балансировщик KEMP LpadMaster. Выяснилось, что пользователи не подключаются к одному из хостов. Зайдя на сервер и попытавшись открыть консоль «Конфигурация узла сеансов удаленных рабочих столов» выскочило окно с предупреждением:
Если попытаться раскрыть данный узел настроек, то выскакивало предупредительное окно:
И потом уже со значком фатальной ошибки.
Пробуем перезагрузиться сервер, эта чаще всего самое действенное решение с продуктами компании Microsoft. После перезагрузки я опять увидел ошибку, что не задан режим лицензирования для сервера узла сеансов удаленных рабочих столов.
Щелкаем по нему, нам открывается оснастка «Конфигурация узла сеансов удаленных рабочих столов» и дальше знакомая нам ошибка.
Методы решения проблемы
И так давайте с вами решим эту проблему и вернем вашего участника фермы в рабочее состояние, чтобы пользователи могли спокойно работать. Первым делом я вам советую посмотреть ваши логи в просмотре событий. У себя я в журнале «Система» нашел все тот же код события 1069: Льготный период лицензирования удаленных рабочих столов закончился, а режим лицензирования для сервера, обслуживающего сеансы подключения к удаленному рабочему столу, не настроен. Для постоянной работы необходимо настроить режим лицензирования.
Кодом события 1069 у меня был забит весь журнал, данная ошибка валилась, чуть ли не каждые 5 минут.
Так же можно встречать ошибку: не удалось запустить службу удаленного рабочего стола. Соответствующий код состояния: 0x800706be.
Далее необходимо проверить, все ли в порядке с вашим сервером лицензирования, может быть о не доступен или у него какие либо проблемы с активацией, в моем случае проблем не было.
Иду проверять свой чеклист дальше, так как у меня все настройки на хосты к которым идет подключение применяются посредством групповых политик, благо есть домен Active Directory со всеми плюшками его использования. Для того, чтобы проверить применяются ли политики к данному хосту нужно выполнить результирующую политику с помощью команды RSOP.
Для этого откройте power shell или командную стоку от имени администратора и введите команду rsop. В идеале у вас должна появиться результирующая политика, в которой вы сможете посмотреть все примененные параметры, но у меня выскочило предупреждение.
Если посмотреть логи операционной системы Windows Server 2008 R2, то можно обнаружить вот такие события:
Пробую обновить принудительно групповую политику, через команду gpupdate /force и видим очередную ошибку.
Чтобы диагностировать сбой, просмотрите журнал событий или запустите GPRESULT /H GPReport.html из командной строки просмотра сведений о результатах групповой политики
В логах системы Windows Server 2008 R2 вы можете обнаружить событие с кодом 1065 в журнале Group Policy:
Уже стало яснее, что проблема явно связана с фильтром WMI или WMI инструментарием управления Windows. Так как в сообщения об ошибке явным образом указана политика к которой не может примениться WMI фильтр, вы видите ее GUID, то по нему вы можете легко найти нужную политику, как искать групповую политику я уже освещал в отдельной статье, посмотреть можно по ссылке.
В редакторе управления групповой политикой я нашел нужную мне политику, и вижу, что к ней действительно применяется определенный WMI фильтр, по своему опыту я знаю, что если появляется ошибка с кодом 1065, то в большинстве случаев поврежден WMI репозиторий, который следует восстановить или попросту пересоздать, такая вот починка от Microsoft.
Как пересоздать WMI инструментарием управления Windows
Чтобы заново создать (восстановить) WMI инструментарием управления Windows Server, вам необходимо открыть командную строку от имени администратора, и иметь обязательно все права на вашем сервере. Вводим команду для остановки службы winmgmt:
Как видите у нас остановилась служба «Инструментарием управления Windows» и зависимая от нее «Вспомогательная служба IP»
Далее, если кто-то не знал сам инструментарием управления Windows, располагается по пути C:WindowsSystem32wbemrepository.
Если бы вы не остановили до этого службу, то удалить лежащие тут файлы вам бы не удалось, что требует восстановление репозитория WMI.
После перезагрузки пробуем выполнить команду RSOP и после ее выполнения gpupdate /force. Как видите все отработало успешно и
не появилась, а это значит, что все политики прилетели и применились.
Теперь проверим работоспособность оснастки «Конфигурация узла сеансов удаленных рабочих столов», открываем ее и видим, что ошибок больше нет и все лицензии доступны, об этом нам говорит, два определившихся сервера.
Кстати еще можно определить, что у вас есть проблемы с WMI репозиторием, по свойствам системы, где могут не отображаться данные, о процессорах и оперативной памяти, что должно вас навести на мысль, что с ними что-то не так.
Еще из дополнительных методов, могу вам посоветовать удаление роли удаленных рабочих столов и их переустановка.
Надеюсь вам удалось решить проблему с ошибкой «Не удалось запустить диагностику лицензирования из-за возникшей неполадки. Перезапустите средство настройки сервера узла сеансов.» и ваша оснастка «Конфигурация узла сеансов удаленных рабочих столов» заработала.
Этот форум закрыт. Спасибо за участие!
Лучший отвечающий
С тех пор, как я начал использовать preferences политики (это новый тип политик в 2008 сервере), стали на рабочих станциях Windows Vista и на сервере терминалов Windows 2008 возникать в логах ошибки.
С помощью preferences политики у меня подключаются принтеры в зависимости от доменных групп.
Клиентскому расширению не удалось записать в журнал данные RSoP по причине ошибки с кодом «0x8004401e «.
На Windows Vista изредка отваливаются принтеры.
Подскажите, каким образом возможно решить данную проблему?
Плохо. Потому что вариантов решения очень много ))))
1) Возможно проблема с UAC. Решение тут.
2) Возможно проблема с WMI. Решение тут.
3) И еще хорошая статья о том, как решать проблемы с ГП, которые не желают применяться тут.
Данный форум является бесплатным сервисом Microsoft с целью оказания посильной помощи пользователям и повышения уровня знаний о продуктах Microsoft. Информация, представленная на форуме, распространяется «как есть» без официальной ответственности компании Microsoft.
К сожалению, наверное мой случай и в статье описаны именно те ошибки, которые у меня возникают на рабочих станциях Windows Vista.
Так же в статье указано, что может не доставать два файла.
% SYSTEMROOT% system32 WBEM polprocl.mof
% SYSTEMROOT% system32 WBEM polprocl.mfl
Однако на Висте эти файлы есть и ошибки по прежнему фиксируются.
Установите данное обновление на клиентах.
Данное обновление у меня не ставиться. Выдает, обновление не приемлимо.
Данное обновление касается установки на Windows vista sp1, если я правильно понял.
У меня же на висте все максмально обновленно и стоит sp2.
И принтеры и сетевые диски и ярлыки мапяться с помощью preferences политик.
Однако в логах на Висте на 2008 ошибки.
Но при этом все работает и все автоматом подключается.
Начали сыпаться ошибки в лог:
И ещё парочка. во всех событиях присутствует » //./root/CIMV2 namespace does not exist»
Всё бы ничего но не зайти в оснастку конфигурации служб терминалов. Вижу белый лист и ошибку «Не удалось завершить операцию: Not Found»
Не знаю связано ли это как то с накануне добавленным резервным контроллером домена (на врят ли, с другими серверами всё впорядке). Ошибки начались через 12 часов после добавления.
Подскажите как решить проблему с тем, что в логах серверов в домене появились сообщения (1090):
1. Windows не удалось записать в журнал состояние сеанса RSoP. Попытка подключения к WMI не удалась. Дальнейшее протоколирование RSoP не будет выполняться для этого применения политики.
Сам RSOP. MSC не запускается (завершается с ошибкой «Не удалось создать данные результирующей политики из-за указанной ошибки»). Файервол не стоит. Хотя служба WMI работает. Перегружал сервер ошибка осталась.
2. Вторая ошибка с ID 1104:
Windows не удалось выполнить проверку фильтра для объекта групповой политики cn=,cn=policies,cn=system,DC=contoso,DC=com. Не удалось найти сопоставляемый фильтр. Этот объект групповой политики будет пропущен.
Использование оснастки результирующей политики для просмотра параметров политики Using the Resultant Set of Policy (RSoP) snap-in to review policy settings
После того, как вы развернете настраиваемый пакет Internet Explorer для своих сотрудников, вы можете использовать оснастку результирующей политики (RSoP), чтобы просмотреть созданные параметры политики. After you’ve deployed your custom Internet Explorer package to your employees, you can use the Resultant Set of Policy (RSoP) snap-in to view your created policy settings. Оснастка результирующей политики используется в два этапа. The RSoP snap-in is a two-step process. Сначала запускается мастер результирующей политики, чтобы определить данные для просмотра. First, you run the RSoP wizard to determine what information should be viewed. Затем отдельные элементы открываются в окне консоли для просмотра параметров. Second, you open the specific items in the console window to view the settings. Дополнительные сведения о том, как использовать RSoP, см. в разделе Результирующая политика. For complete instructions about how to use RSoP, see Resultant Set of Policy.
Добавление оснастки результирующей политики To add the RSoP snap-in
На экране Пуск введите MMC. On the Start screen, type MMC.
Откроется консоль управления (MMC). The Microsoft Management Console opens.
Щелкните Файл, а затем щелкните Добавить или удалить оснастку. Click File, and then click Add/Remove Snap-in.
В окне Доступные оснастки перейдите вниз к параметру оснастки Результирующая политика, нажмите кнопку Добавить, а затем— кнопку ОК. In the Available snap-ins window, go down to the Resultant Set of Policy snap-in option, click Add, and then click OK.
Теперь оснастку результирующей политики можно использовать на консоли. You’re now ready to use the RSoP snap-in from the console.
Использование оснастки результирующей политики To use the RSoP snap-in
Щелкните правой кнопкой мыши элемент Результирующая политика, а затем выберите пункт Создать данные RSoP. Right-click Resultant Set of Policy and then click Generate RSoP Data.
Мастер результирующей политики нужно выполнить только при первом запуске оснастки. You’ll only need to go through the resulting RSoP Wizard first time you run the snap-in.
Нажмите кнопку Далее на экране Приветствие. Click Next on the Welcome screen.
AGPM и GPRESULT не работают в Windows Server Core
В этой статье предоставляется решение ошибки, которая возникает, когда AGPM и GPRESULT не работают на установке Windows Server Core.
Применяется к: Windows Server 2012 R2 Исходный номер КБ: 2987708
Симптомы
Предположим, что AGPM Server установлен на компьютере с Windows Server Core (Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2). A GPM устанавливается на клиентский компьютер, на Windows сервере или на Windows клиентской операционной системе с установленными средствами администрирования удаленного сервера. В этой ситуации при попытках администратора взять под контроль объект групповой политики без управления (GPO) возникает следующая ошибка:
Сценарий GPRESULT
На компьютере Windows Server Core, когда администратор выполняет команду gpresult/h для получения параметров GPO для этого компьютера или пользователя, GPRESULT возвращает следующее сообщение об ошибке:
Причина
Эти проблемы возникают из-за того, что компонент AGPM Server и команда GPRESULT/h требуют установки консоли управления групповой политикой (GPMC) в локальной системе. Несколько интерфейсов GPMC будут установлены в системе только после установки GPMC.
Поскольку Windows Server Core не установлен интерфейс GPMC, приложения, которые используют этот интерфейс, не будут работать.
Решение
Разрешение для AGPM
Установите компонент AGPM Server на Windows на сервере с установленным интерфейсом.
Разрешение для GPRESULT
Запустите отчет GPRESULT с удаленного компьютера на Windows server Core.
Утилита GPResult.exe – представляет собой консольное приложение, предназначенное для анализа настроек и диагностики групповых политик, которые применяются к компьютеру и/или пользователю в домене Active Directory. В частности, GPResult позволяет получить данные результирующего набора политик (Resultant Set of Policy, RSOP), список примененных доменных политик (GPO), их настройки и детальную информацию об ошибках их обработки. Утилита входит в состав ОС Windows начиная со времен Windows XP. Утилита GPResult позволяет ответить на такие вопросы: применяется ли конкретная политика к компьютеру, какая именно GPO изменила ту или иную настройку Windows, разобраться с причинами долгого применения GPP/GPO.
В этой статье мы рассмотрим особенности использования команды GPResult для диагностирования работы и отладки применения групповых политик в домене Active Directory.
Изначально для диагностики применения групповых политик в Windows использовалась графическая консоль RSOP.msc, которая позволяла получить настройки результирующих политик (доменных + локальных), примененные к компьютеру и пользователю в графическом виде аналогичном консоли редактора GPO (ниже на примере представления консоли RSOP.msc видно, что настройки обновлений заданы политикой WSUS_SERVERS).
Однако, консоль RSOP.msc в современных версиях Windows использовать нецелесообразно, т.к. она не отражает настройки, примененные различными расширениями групповых политик (client side extensions — CSE), например GPP (Group Policy Preferences), не позволяет выполнять поиск, предоставляет мало диагностической информации. Поэтому на данный момент именно команда GPResult является основным средством диагностики применения GPO в Windows (в Windows 10 даже появляется предупреждение, что RSOP не дает полный отчет в отличие от GPResult).
Использование утилиты GPResult. exe
Команда GPResult выполняется на компьютере, на котором нужно проверить применение групповых политик. Команда GPResult имеет следующий синтаксис:
В нашем примере видно, что на объект пользователя действуют 4 групповые политики.
Если вы не хотите, чтобы в консоль одновременно выводилась информация и о политиках пользователя и о политиках компьютера, вы можете с помощью опции /scope вывести только интересующий вас раздел. Только результирующие политики пользователя:
Т.к. утилита Gpresult выводит свои данные непосредственно в консоль командной строки, что бывает не всегда удобно для последующего анализа, ее вывод можно перенаправить в буфер обмена:
HTML отчет RSOP с помощью GPResult
Кроме того, утилита GPResult может сгенерировать HTML-отчет по примененным результирующим политикам (доступно в Windows 7 и выше). В данном отчете будет содержаться подробная информация обо всех параметрах системы, которые задаются групповыми политиками и именами конкретных GPO, которые их задали (получившийся отчет по структуре напоминает вкладку Settings в консоли управления доменными групповыми политиками – GPMC). Сгенерировать HTML отчет GPResult можно с помощью команды:
GPResult /h c:gp-reportreport.html /f
Получение данных GPResult с удаленного компьютера
GPResult может собрать данные и с удаленной компьютера, избавляя администратора от необходимости локального или RDP входа на удаленный компьютер. Формат команды сбора данных RSOP с удаленного компьютера такой:
GPResult /s server-ts1 /r
Пользователь username не имеет данных RSOP
Итак, в этой статье мы рассмотрели особенности диагностики применения групповых политик с помощью утилиты GPResult и рассмотрели типовые сценарии ее использования.
Gpresult не показывает политики компьютера
dcdiag на двух серверах DC проходит со следующим варнингом.
Starting test: KccEvent
A warning event occurred. EventID: 0x80000B47
Time Generated: 12/28/2015 09:48:05
На хозяине ролей ошибок dcdiag не выдает.
gpupdate /force на всех DC выполнял. На клиенте при выполнении gpresult /h file.html написано что политика не применяется (пусто). В eventvwr на клиенте появляется ошибка 1129 «сбой обработки групповой политики из-за отсутствия сетевого подключения к контроллеру домена». При этом в ipconfig /all указан второй DC в качестве dhcp сервера (один из тех, на котором варнинг есть).
Диагностику в таких случаях надо начинать с конечного устройства, а не с КД.
На ноутбуке есть в системном журнале сообщения об ошибках при обработке групповой политики?
RSOP.msc что показывает? Применяется ли данная политика? Настройки WSUS из нее видны?
Если политика применяется, но настройки WSUS не отображаются, проверяйте, что на SYSVOL на всех КД есть папка, соответствующая этой политике, и ее содержимое везде идентично.
Evgeniy Lotosh // MCSE: Server infrastructure, MCSE: Messaging
Для этого, прежде всего, изучите журнал событий Система на предмет ошибок службы Netlogon («Сетевой вход в систему»).
На другом вновь залитом ноутбукеПК проявляется та же самая проблема, поэтому и начал с КД.
На ноутбуке вышеописанная ошибка появлялась в 16:33:20, а сообщение «параметры групповой политики для этого пользователя обработаны успешно. Были обнаружены и применены новые параметры из 5 объектов групповой политики» появилось в 16:33:40.
В 16:34:21 появилось сообщение «параметры групповой политики для этого компьютера обработаны успешно».
rsop от доменного админа (у доменного пользователя нет прав локального админа) показывает политику, которая указывает сервер wsus и остальные параметры, указанные в этой политике.
SYSVOL проверил, папка есть, содержимое идентично.
сейчас на клиенте выполнил gpupdate. В системном журнале появились 2 записи: «параметры групповой политики для этого пользователя обработаны успешно. Не обнаружено изменений со времени последней успешной обработки групповой политики» и «параметры групповой политики для этого компьютера обработаны успешно. Не обнаружено изменений со времени последней успешной обработки групповой политики»
Политики установки ПО применяются.
После перезагрузки, ошибка NETLOGON 5719 «компьютер не может установить безопасный сеанс связи с контроллером домена»
Посмотрите в службах запущен ли DNS сервер.
Видимо плохо лопатили.
Покажите вывод команды ipconfig /all с сервера.
я пропустил мелочь в настройках и теперь все наперекосяк.
вот по пунктам что есть:1.dhcp авторизован2.scope и исключения созданы2.в dns инсталлирован и запущен3.dns и сервак имеют локальный ip
ЧТО ЖЕ ТОГДА НЕ ТАК.
Это настройки но какие.
Помогите пожалуйста,по пунктам давайте все проверим. И говорите со мной как с равным)))
На диске C: появится файл ip.txt
Скопируйте содержимое файла сюда.
http://pic.ipicture.ru/uploads/081001/Rx96P9ovio.jpgя на хостинг буду скриншоты класть мне так прощечотя можно и так
Windows IP Configuration
Ethernet adapter Local Area Connection:
продолжим завтра если можно.спасибо что откликнулись
Windows не удалось применить параметры group policy local users and groups
Добрый день, проблема с отработкой групповой политики используя GPP. Групповая политика должна изменять пароль локального администратора. После применения ее на доменном ПК возникает ошибка:
В политике указано:
Имя пользователя Администратор (встроенная учетная запись)
Запретить смену пароля пользователем Ложь
Срок действия пароля не ограничен Истина
Учетная запись отключена Ложь
Срок действия учетной записи Никогда
Остановить обработку элементов на этом расширении, если на этом элементе возникает ошибка Нет
Удалить этот элемент, если он больше не применяется Нет
Применить один раз и не применять повторно Нет
Почему не применяется групповая политика к компьютеру или OU?
В этой обзорной статье я постараюсь разобрать типовые причины, из-за которых та или иная групповая политика может не применяться к подразделению (OU) или конкретному компьютеру / пользователю. Я думаю эта статья будет полезна как новичкам, так и профессионалам групповых политик AD для понимания принципов работы и архитектуры GPO. В первую очередь в статье я расскажу о возможных проблемах применения GPO, связанные с настройками самих политик на уровне домена, а не о траблшутинге применения GPO на клиентах. Практически все настройки, описанные в статье, выполняются в консоли редактора доменных групповых политик — Group Policy Management Console (GPMC.msc).
Область действия (scope) GPO
Также проверьте, что объект, к которому вы пытаетесь применить политику находится в нужном OU с компьютерами или пользователями. Можно воспользоваться поиском по домену. O U, в котором находится объект содержится на вкладке Object в консоли ADUC.
Т.е целевой объект должен находится в OU, на который назначена политика (или во вложенном контейнере).
Фильтр безопасности GPO
Если вы используете нестандартные фильтры безопасности политик, проверьте, что для целевых групп нет явного запрета на применение GPO (Deny).
WMI фильтры GPO
В групповых политиках можно использовать специальные WMI фильтры. Это позволяет применить политику к компьютерам на основании некоторого WMI запроса. Например, мы можете создать WMI фильтр GPO для применения политики только к компьютерам с определенной версией Windows, к ПК в определенной IP подсети, только к ноутбукам и т.д.
При использовании WMI фильтров групповых политик вам нужно проверить корректность WMI запроса, который выбирает только те системы, которые вам нужны и не исключаются ваши целевые компьютеры. Вы можете протестировать WMI фильтр на компьютерах через PowerShell
Если запрос возвращает любые данные, значит WMI фильтр применится к этому компьютеру.
Статус групповой политики
Проверьте статус групповой политики, перейдя в консоли GPMC.msc в свойствах политики на вкладку Details. Обратите внимание на значение в поле GPO Status.
Как вы видите, доступно 4 варианта:
Делегирование GPO
На вкладке политики Delegation указаны разрешения, настроенные для данной групповой политики. Здесь можно увидеть каким группам даны права на изменения настроек GPO, а также на разрешение или запрет применения политики. Вы можете предоставить права на управление GPO из этой консоли или с помощью мастера делегирования в ADUC. Кроме того, наличие строки доступа для Enterprise Domain Controllers определяет возможность репликации данной политики между контроллерами домена Active Directory (это нужно иметь в виду при наличии проблем с репликацией политики между DC). Обратите внимание, что права на вкладке Delegation соответствуют NTFS правам, назначенным на каталог политики в папке SYSVOL
Наследование групповых политик
Организационные подразделения с отключенным наследованием политик в консоли отображаются с синим восклицательным знаком.
Если политика не применяются на клиенте, проверьте, не находится ли он в OU с отключенным наследованием.
Имейте в виду, что доменные политики, для которых включено свойства “Enforced”, применяются даже на OU с отключённым наследованием (наследованные политики, которые применяются к контейнеру доступны на вкладке Group Policy Inheritance).
Область действия и порядок применения групповых политик (LSDOU)
Чтобы запомнить особенности порядка применения групповых политик в домене, нужно запомнить аббревиатуру LSDOU. Это аббревиатура позволяет запомнить порядок применения GPO:
Последние политики имеют наивысший приоритет. Т.е. если вы включили некий параметр Windows на уровне политики домена, но на целевом OU данный параметр отключается другой политикой – это означает, что нужный параметр в результате будет отключен на клиенте (выиграет ближайшая политика к объекту в иерархии AD).
При использовании параметра Forced у GPO выигрывает та, политика находится выше в иерархии домена (например, при включении Forced у политики Default Domain Policy, она выигрывает у всех других GPO).
Кроме того, администратор может изменить порядок обработки политик (Link Order) в консоли GPMC. Для этого нужно выбрать OU и перейти на вкладку Linked Group Policy Objects. В списке содержаться список GPO, которые применяются к данной OU с указанием приоритета. Политики обрабатываются в обратном порядке (снизу-вверх). Это означает что политика с Link Order 1 выполнится последней. Вы можете изменить приоритет GPO с помощью стрелок в левом столбце, передвинув ее выше или ниже в списке.
GPO Link Enabled
У каждого объекта GPO, который привязан к организационному контейнеру AD вы можете включить или отключить связь (применение политики). Для этого нужно включить или отключить опцию Связь включена (Link Enabled) в меню политики. Если связь для политики отключена, ее иконка становится бледной. При отключении связи политика перестает применяться к клиентам, но ссылка на объект GPO не удаляется из иерархии. Вы можете активировать данную связь в любой момент.
Замыкание групповой политики
У этой политики есть два возможных значение:
Диагностика применения GPO на стороне клиента
Также можете познакомиться со статей, описывающей принципы диагностики при слишком долгом применении политик на клиентах.
В заключении хочется сказать, что следует держать структуру групповых политик как можно более простым и не создавать лишние политик без необходимости. Используйте единую схему именование политик, имя GPO должно давать однозначное понимание того, для чего она нужна.
Методика диагностики причин долгого применения GPO в Windows
Медленная загрузка компьютера, вызванная долгим применением групповых политик, является одной из частых проблем в домене, на которые жалуются пользователи. С точки зрения пользователя компьютер загружается очень долго, и как будто зависает на несколько минут на этапе «Применение параметров компьютера / пользователя». В этой статье я попробую собрать полезные диагностические инструменты и приемы, позволяющие администратору выявить причины медленного применения GPO на компьютерах домена.
На самом деле причин, из-за которых на компьютере долго применяются групповые политики может быть множество: это и проблемы с DNS, доступностью и скоростью подключения к DC, неправильной настройкой сайтов AD или проблемы с репликацией, неверно настроенные групповых политики и кривые скрипты и т.п. Проблематично описать универсальный алгоритм по диагностике всех этих проблем. При решении таких проблем, как правило, большую роль имеет опыт и навыки специалиста, производящего диагностику. В этой статье мы остановимся только на диагностики проблем, связанных с самими механизмами работы GPO и клиента GPClient.
Блокирование наследования групповой политик
Перезагрузите компьютер и проверьте, сохранилась ли проблема с долгим применением GPO. Если сохранилась, вероятнее всего проблема с самим компьютером или локальными политиками (попробуйте их сбросить на дефолтные).
Вывод подробных сообщений на экране загрузки
В Windows на экране загрузки системы можно включить отображение расширенной статусной информации, позволяющей пользователям и администратору визуально понять на каком этапе загрузки компьютера наблюдается наибольшая задержка. При включении данной политики, в том числе, начинает отображаться информация о применяемых компонентах GPO. Включить эту политику можно в следующем разделе GPO:
Этот же параметр можно активировать через реестр, создав в ветке HKEY_LOCAL_MACHINESOFTWARE Microsoft Windows CurrentVersion PoliciesSystem параметр типа DWORD с именем verbosestatus и значением 1.
В результате на экране в процессе загрузки будут отображаться такие сообщения:
Отчет GPResult
Результирующую политику, которая была применена к компьютеру, стоит проанализировать с помощью HTML отчета gpresult, создать который можно такой командой, запущенной с правами администратора:
gpresult /h c:psgpreport.html
Этот отчет достаточно удобен для анализа и может содержать ссылки на различные ошибки при применении GPO.
В журнале приложений о медленном применении политик может свидетельствовать событие с EventID 6006 от источника Winlogon с текстом:
Для анализа времени применения политик будут полезны следующие EventID:
При анализе журнала стоит также обращать на время, прошедшее между двумя соседними событиями, это может помочь обнаружить проблемный компонент.
Отладочный журнал службы GPSVC
В некоторых ситуациях бывает полезным включить ведение отладочного журнала обработки GPO — gpsvc.log. С помощью временных меток в файле gpsvc.log можно найти компоненты GPO, которые долго отрабатывали.
Отладочные журналы Group Policy Preferences
После сбора логов нужно проанализировать их на ошибки, а также попытаться найти соседние события, время между которыми отличается на несколько минут.
Итак, в этой статье мы рассмотрели основные способы диагностики проблем долгого применения групповых политик на компьютерах домена. Надеюсь, статья будет полезной.
Windows 7 Клиентам периодически не удается применить групповую политику при запуске
В этой статье данная статья позволяет решить проблему, из-за которой 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 EventLog 6006 указывает на отключение системы Информация e1kexpress 33 указывает на то, что установлена связь сетевого подключения с Information EventLog 6005 указывает, что служба журнала событий запущена Информация Dhcp-Client 50036 указывает на начало клиентской службы dhcp Ошибка NETLOGON 5719 указывает, что netlogon не может достичь ни одного из контроллеров домена Ошибка GroupPolicy 1055 указывает на сбой обработки групповой политики Information GroupPolicy 1503 указывает на успешность обработки групповой политики
