Windows не удалось записать информацию результирующей политики rsop

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. В прошлый раз мы с вами подробно разобрали сетевую технологию VLAN и ее применение. В сегодняшней статье я расскажу, как решил вот такую ситуацию на одном из терминальных столов. Нужно мне было проверить применение групповых политик для пользователя, в момент диагностики я, как обычно попытался воспользоваться утилитой GPresult, но в итоге получил ошибку «Пользователь не имеет данных RSOP«. Давайте разбираться в чем дело.

Я первый раз получил такую ошибку в своей практике. Мое окружение, это RDS хост с Windows Server 2012 R2. Командная строка работает в режиме администратора. Напоминаю, что GPresult — это утилита показывающая подробный отчет по примененным или отклоненным групповым политикам пользователя и компьютера, чтобы системный администратор имел представление и знал, где диагностировать проблему. Вот так вот выглядит ошибка «gpresult /r Пользователь не имеет данных RSOP (The user does not have RSoP data)»

Я подумал, ладно пойду другим путем и попробую проверить применение политик GPO через RSOP, но и тут я получил ошибку:

Если посмотреть журнал с логами Windows, то вы обнаружите вот такое предупреждение:

Первым делом проверьте, что у вас в запущенном состоянии служба инструментария управления Windows (Winmgmt). Для этого откройте оболочку PowerShell и введите команду:

Если у вас будет статус «Stop», то введите команду:

Так же вы можете перезапустить сервис, командой:

Следующим шагом я вам советую добавить ключ в реестр Windows. Переходим в ветку:

Создаем ключ dword32

с именем GroupPolicyMinTransferRate и значением 0

И точно такой же в ветке:

Создаем ключ dword32 с именем GroupPolicyMinTransferRate и значением 0. Перезагружаем компьютер или сервер. Данная манипуляция в большинстве случаев исправляет ошибку GPResult пользователь не имеет данных RSOP.

Если первый метод не помог, то пробуем удалить из реестра всю историю объекта групповой политики из профиля пользователя. Перед удалением обязательно сделайте резервную копию ветки реестра.

После чего в командной строке вводим gpupdate /force, а затем gpresult /h. В итоге ошибка «Пользователь не имеет данных RSOP», должна пропасть. Еще одним методом устранения проблемы в обработке результирующей политики, является вывод компьютера из домена Active Directory, и повторный ввод в домен.

Я наблюдал ошибку «The user does not have RSoP data», когда люди пытались удаленно выполнять команду результирующей политики, для еще не вошедшего в систему пользователя, или наоборот у них командная строка запущена от имени другого пользователя, например с большими правами, но он так же не вошел интерактивно на сервер. Тут два варианта, либо вы заходите под ним на сервер или же в в выводе gpresult вы используете его данные, простой пример:

Windows не удалось записать информацию результирующей политики rsop

Доброго времени суток! Уважаемые читатели 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:\Windows\System32\wbem\repository.

Если бы вы не остановили до этого службу, то удалить лежащие тут файлы вам бы не удалось, что требует восстановление репозитория WMI.

После этих действий вам необходимо выполнить команду и перезагрузить Windows Server 2008 R2 .

После перезагрузки пробуем выполнить команду RSOP и после ее выполнения gpupdate /force. Как видите все отработало успешно и

«Ошибка при обработке групповой политики. Windows не удалось применить фильтр WMI для объекта групповой политики «GUID название». Возможные причины: отключение RSOP, отключение или остановка службы WMI , иные ошибки WMI. Проверьте, что служба WMI запущена и задан автоматический запуск этой службы. Новые параметры или объекта групповой политики не могут быть обработаны, пока не будет исправлена эта ситуация.»

не появилась, а это значит, что все политики прилетели и применились.

Теперь проверим работоспособность оснастки «Конфигурация узла сеансов удаленных рабочих столов», открываем ее и видим, что ошибок больше нет и все лицензии доступны, об этом нам говорит, два определившихся сервера.

Кстати еще можно определить, что у вас есть проблемы с WMI репозиторием, по свойствам системы, где могут не отображаться данные, о процессорах и оперативной памяти, что должно вас навести на мысль, что с ними что-то не так.

Еще из дополнительных методов, могу вам посоветовать удаление роли удаленных рабочих столов и их переустановка.

Надеюсь вам удалось решить проблему с ошибкой «Не удалось запустить диагностику лицензирования из-за возникшей неполадки. Перезапустите средство настройки сервера узла сеансов.» и ваша оснастка «Конфигурация узла сеансов удаленных рабочих столов» заработала.

Windows не удалось записать информацию результирующей политики rsop

Общие обсуждения

• Изменен тип Petko Krushev Microsoft contingent staff, Moderator 2 сентября 2019 г. 7:37

Все ответы

запустить из под администратора, не?

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

запустить из под администратора, не?

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

Это делалось по CMD — ПКМ «Запустить от имени администратора»

в открывшейся оснастке посмотрите детальную ошибку и/или попробуйте выгрести ошибку из gpresult

пользователь является админом? В политиках пк есть разрешения на чтение для authenticated users?

The opinion expressed by me is not an official position of Microsoft

в открывшейся оснастке посмотрите детальную ошибку и/или попробуйте выгрести ошибку из gpresult

пользователь является админом? В политиках пк есть разрешения на чтение для authenticated users?

The opinion expressed by me is not an official position of Microsoft

Я запускаю CMD из под домнного админа и от туда уже RSOP — результат тот же.

Причем интересная фишка. RSOP не показывает политики компьютера. А вот GPResult наоборот, не показывает политики пользователя. =)