Ошибка при обработке групповой политики wmi

Обновлено 25.11.2019

Доброго времени суток! Уважаемые читатели 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, то можно обнаружить вот такие события:

Имя журнала:   System
Подача:        Microsoft-Windows-GroupPolicy
Дата: 18.04.2018 9:02:12
Код события:   1090
Категория задачи:Отсутствует
Уровень:       Предупреждение
Описание:
Windows не удалось записать информацию результирующей политики (RSoP), которая описывает область применения объектов групповой политики к этому компьютеру или пользователю. Возможные причины: отключение или остановка службы WMI (инструментария управления Windows), иные ошибки WMI. Параметры групповой политики были успешно применены к этому компьютеру или пользователю; однако возможно, что средства управления не дают правильного отчета.

Или

Имя журнала:   Application
Подача:        Microsoft-Windows-WMI
Дата: 18.04.2018 9:02:12
Код события:  24
Категория задачи:Отсутствует
Уровень:       Ошибка
Описание:
Event provider Win32ClockProvider attempted to register query «select * from __InstanceModificationEvent where TargetInstance isa «Win32_LocalTime»» whose target class «Win32_LocalTime» in //./root/CIMV2 namespace does not exist. The query will be ignored.

Пробую обновить принудительно групповую политику, через команду gpupdate /force и видим очередную ошибку.

В логах системы Windows Server 2008 R2 вы можете обнаружить событие с кодом 1065 в журнале Group Policy:

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

Уже стало яснее, что проблема явно связана с фильтром WMI или WMI инструментарием управления Windows. Так как в сообщения об ошибке явным образом указана политика к которой не может примениться WMI фильтр, вы видите ее GUID, то по нему вы можете легко найти нужную политику, как искать групповую политику я уже освещал в отдельной статье, посмотреть можно по ссылке.

В редакторе управления групповой политикой я нашел нужную мне политику, и вижу, что к ней действительно применяется определенный WMI фильтр, по своему опыту я знаю, что если появляется ошибка с кодом 1065, то в большинстве случаев поврежден WMI репозиторий, который следует восстановить или попросту пересоздать, такая вот починка от Microsoft.

Чтобы заново создать (восстановить) WMI инструментарием управления Windows Server, вам необходимо открыть командную строку от имени администратора, и иметь обязательно все права на вашем сервере. Вводим команду для остановки службы winmgmt:

Как видите у нас остановилась служба «Инструментарием управления Windows» и зависимая от нее «Вспомогательная служба IP»

Далее, если кто-то не знал сам инструментарием управления Windows, располагается по пути C:WindowsSystem32wbemrepository.

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

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

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

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

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

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

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

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

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

Создание WMI фильтров для групповых политик (GPO) в домене AD

Технология WMI фильтров в групповых политиках (GPO) позволяет более гибко применять политики на клиентов, за счет использования различных правил, позволяющих указывать WMI запросы для формирования критериев выборки компьютеров, на которые будет действовать групповая политика. К примеру, с помощью WMI фильтров GPO вы можете применить политику, назначенную на OU, только к компьютерам с ОС Windows 10 (на других версиях Windows такая политика с фильтром применяться не будет).

Для чего используются WMI фильтры GPO?

Обычно технология фильтрации групповых политик с помощью WMI (Windows Management Instrumentation) используется в ситуациях, когда объекты домена (пользователи или компьютеры) находятся в плоской структуре AD, а не в выделенном OU, либо если необходимо применить политики, в зависимости от версии ОС, ее сетевых настроек, наличию определенного установленного ПО или любом другом критерии, который можно выбрать с помощью WMI. При обработке такой групповой политики клиентом, Windows будет проверять свое состояние на соответствие указанному WMI запросу на языке WQL (WMI Query Language), и, если условия фильтра выполняются, такая GPO будет применена к компьютеру.

WMI фильтры групповых политик впервые появились еще в Windows XP, и доступны вплоть до последних версий Windows (Windows Server 2019, 2016, Windows 10, 8.1).

Как создать новый WMI фильтр и привязать его к GPO?

Чтобы создать новый WMI фильтр, откройте консоль управления доменными групповыми политиками Group Policy Management (gpmc.msc) и перейдите в раздел Forest -> Domains -> winitpro.ru -> WMI Filters. В этой секции содержатся все WMI фильтры домена. Создайте новый WMI фильтр (New).

В поле Name укажите имя фильтра, в поле Descriptions его описание (не обязательно). Чтобы добавить в фильтр WMI запрос нажмите на кнопку Add, укажите имя пространства имен WMI (по умолчанию rootCIMv2) и укажите код WMI запроса.

WMI запрос имеет следующий формат:

Select * from WHERE

В нашем примере вы хотим создать WMI фильтр, позволяющий применить групповую политику только на компьютеры с Windows 10. Код WMI запроса может выглядеть так:

Select * from Win32_OperatingSystem where Version like «10.%» and ProductType=»1″

Созданные WMI фильтры хранятся в объектах класса msWMI-Som домена Active Directory в разделе DC=…, CN=System, CN=WMIPolicy, CN=SOM их можно найти и отредактировать с помощью консоли adsiedit.msc.

После создания WMI фильтра его можно привязать к конкретному объекту GPO. Найдите нужную политику в консоли GPMC и на вкладке Scope в выпадающем меню секции WMI Filtering выберите созданный ранее WMI фильтр. В этом примере я хочу, чтобы политика автоматического назначения принтеров применялась только к компьютерам с Windows 10.

Дождитесь применения данной политики на клиентов, или обновите ее с помощью gpupdate /force . При анализе примененных политик на клиенте нужно использовать команду gpresult /r. Если политика действует на клиента, но не применяется из-за WMI фильтра, такая политика в отчете будет иметь статус Filtering: Denied (WMI Filter) и указано имя WMI фильтра.

Примеры запросов для WMI фильтров GPO

Рассмотрим различные примеры WMI фильтров GPO, который чаще всего используются.

С помощью WMI фильтра вы можете выбрать тип ОС:

• ProductType=1 – любая клиенская ОС

• ProductType=2 – контроллер домена AD

• ProductType=3 – серверная ОС (Windows Server)

• Windows Server 2016 и Windows 10 — 10.%
• Windows Server 2012 R2 и Windows 8.1 — 6.3%
• Windows Server 2012 и Windows 8 — 6.2%
• Windows Server 2008 R2 и Windows 7 — 6.1%
• Windows Server 2008 и Windows Vista — 6.0%
• Windows Server 2003 — 5.2%
• Windows XP — 5.1%
• Windows 2000 — 5.0%

Вы можете комбинировать условия выборки в WMI запросе с помощью логических операторов AND и OR. Чтобы применить политику только к серверам с Windows Server 2016, код WMI запроса будет таким:

select * from Win32_OperatingSystem WHERE Version LIKE «10.%» AND ( ProductType = «2» or ProductType = «3» )

Выбрать 32 битные версии ОС Windows 8.1:

select * from Win32_OperatingSystem WHERE Version like «6.3%» AND ProductType=»1″ AND OSArchitecture = «32-bit»

Применить политику только к 64-битным ОС:

Select * from Win32_Processor where AddressWidth = «64»

Выбрать Windows 10 с определенным билдом, например Windows 10 1803:
select Version from Win32_OperatingSystem WHERE Version like “10.0.17134” AND ProductType=”1″

Применить политику только к виртуальным машинам VMWare:

SELECT Model FROM Win32_ComputerSystem WHERE Model = “VMWare Virtual Platform”

select * from Win32_SystemEnclosure where ChassisTypes = «8» or ChassisTypes = «9» or ChassisTypes = «10» or ChassisTypes = «11» or ChassisTypes = «12» or ChassisTypes = «14» or ChassisTypes = «18» or ChassisTypes = «21»

WMI фильтр, который применится только к компьютерам, чьи имена начинаются на “msk-pc“(например, для блокировки подключения USB накопителей на этих устройствах):
SELECT Name FROM Win32_ComputerSystem WHERE Name LIKE ‘msk-pc%’

Пример использования WMI фильтра для тонкого нацеливания групповой политики к IP подсетям описывается в статье WMI фильтр для привязки GPO к IP подсети. Например, чтобы применить политику к клиентам в нескольких IP подсетях, используйте фильтр:

Select * FROM Win32_IP4RouteTable WHERE (Mask=’255.255.255.255′ AND (Destination Like ‘192.168.1.%’ OR Destination Like ‘192.168.2.%’))

Применять политику к компьютерам, с количеством оперативной памяти больше 1 Гб:

Select * from WIN32_ComputerSystem where TotalPhysicalMemory >= 1073741824

WMI фильтр проверки наличия на компьютере Internet Explorer 11:

SELECT path,filename,extension,version FROM CIM_DataFile WHERE path=»\Program Files\Internet Explorer\» AND filename=»iexplore» AND extension=»exe» AND version>»11.0″

Тестирование WMI фильтра с помощью PowerShell

При написании WMI запросов иногда нужно получать значения различных параметров на компьютере. Вы помете получить эти данный с помощью командлета Get-WMIObject. Например, выведем атрибуты и значения WMI класса Win32_OperatingSystem:

SystemDirectory : C:WINDOWSsystem32
Organization :
BuildNumber : 17134
RegisteredUser : Windows User
SerialNumber : 00331-10000-00001-AA494
Version : 10.0.17134

Чтобы вывести все доступные параметры класса:

Get-WMIObject Win32_OperatingSystem| Select *

Для тестирования WMI фильтров на компьютерах можно использовать PowerShell. Допустим, вы написали сложный WMI запрос и его хотите проверить (соответствует ли компьютер данному запросу или нет). Например, вы создали WMI фильтр проверки наличия IE 11 на компьютере. На целевом компьютере вы можете выполнить этот WMI запрос с помощью командлета get-wmiobject:

get-wmiobject -query ‘SELECT * FROM CIM_DataFile WHERE path=»\Program Files\Internet Explorer\» AND filename=»iexplore» AND extension=»exe» AND version LIKE «11.%»‘

Если данная команда что-то возвращает, значит компьютер соответствует условиям запроса. Если команда get-wmiobject ничего не вернула — компьютер не соответствует запросу.
Например, запустив указанный запрос на компьютере с Windows 10 и IE 11, команда вернет:
Compressed : False
Encrypted : False
Size :
Hidden : False
Name : c:program filesinternet exploreriexplore.exe
Readable : True
System : False
Version : 11.0.17134.1
Writeable : True

Это значит, что IE 11 установлен на компьютере и GPO с таким WMI фильтром будет применяться к этому компьютеру.

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

Источник

Windows не удалось применить фильтр wmi для объекта групповой политики

RPC работает.

По остальному

Microsoft Windows [Версия 6.0.6002]
(C) Корпорация Майкрософт, 2006. Все права защищены.

Диагностика сервера каталогов

Выполнение начальной настройки:
Выполняется попытка поиска основного сервера.
Основной сервер = serv1
* Идентифицирован лес AD.
Сбор начальных данных завершен.

Выполнение обязательных начальных проверок

Сервер проверки: Default-First-Site-Nameserv1
Запуск проверки: Connectivity
. serv1 — пройдена проверка Connectivity

Выполнение основных проверок

Сервер проверки: Default-First-Site-Nameserv1

Запуск проверки: DNS

Проверки DNS выполняются без зависания. Подождите несколько минут.
. serv1 — не пройдена проверка DNS

Выполнение проверок разделов на: ForestDnsZones

Выполнение проверок разделов на: DomainDnsZones

Выполнение проверок разделов на: Schema

Выполнение проверок разделов на: Configuration

Выполнение проверок разделов на: xxx

Выполнение проверок предприятия на: xxx
Запуск проверки: DNS
Результаты проверки контроллеров домена:

Контроллер домена: serv1.xxx
Домен: xxx

TEST: Basic (Basc)
Error: Can’t read OS version through WMI
Не найдены записи узла (A или AAAA) для данного DC

Отчет по результатам проверки DNS:

Auth Basc Forw Del Dyn RReg Ext
_________________________________________________________________
Домен: xxx
serv1 PASS FAIL n/a n/a n/a n/a n/a

. xxx — не пройдена проверка DNS

Microsoft Windows [Версия 6.0.6002]
(C) Корпорация Майкрософт, 2006. Все права защищены.

C:UsersАдминистратор>rpcping -s serv1.xxx
Завершено вызовов: 1 за 15 мс
66 T/S или 15.000 мс/T

C:UsersАдминистратор>dcdiag /q
За последние 24 часа после предоставления SYSVOL в общий доступ
зафиксированы предупреждения или сообщения об ошибках. Сбои при
репликации SYSVOL могут стать причиной проблем групповой политики.
. serv1 — не пройдена проверка DFSREvent
Возникло событие Error. Код события (EventID): 0x00000429
Время создания: 02/20/2016 13:36:00
Строка события:
Ошибка при обработке групповой политики. Windows не удалось применит
ь фильтр WMI для объекта групповой политики «cn=<01242029-8F13-4BC0-B5BE-EBAA855
D0BA1>,cn=policies,cn=system,DC=xxx». Возможные причины: отключение
RSOP, отключение или остановка службы WMI (Инструментария управления Windows), и
ные ошибки WMI. Проверьте, что служба WMI запущена и задан автоматический запуск
этой службы. Новые параметры или объекты групповой политики не могут быть обраб
отаны, пока не будет исправлена эта ситуация.
Возникло событие Error. Код события (EventID): 0x00000429
Время создания: 02/20/2016 13:41:02
Строка события:
Ошибка при обработке групповой политики. Windows не удалось применит
ь фильтр WMI для объекта групповой политики «cn=<01242029-8F13-4BC0-B5BE-EBAA855
D0BA1>,cn=policies,cn=system,DC=xxx». Возможные причины: отключение
RSOP, отключение или остановка службы WMI (Инструментария управления Windows), и
ные ошибки WMI. Проверьте, что служба WMI запущена и задан автоматический запуск
этой службы. Новые параметры или объекты групповой политики не могут быть обраб
отаны, пока не будет исправлена эта ситуация.
Возникло событие Error. Код события (EventID): 0x00000429
Время создания: 02/20/2016 13:46:04
Строка события:
Ошибка при обработке групповой политики. Windows не удалось применит
ь фильтр WMI для объекта групповой политики «cn=<01242029-8F13-4BC0-B5BE-EBAA855
D0BA1>,cn=policies,cn=system,DC=xxx». Возможные причины: отключение
RSOP, отключение или остановка службы WMI (Инструментария управления Windows), и
ные ошибки WMI. Проверьте, что служба WMI запущена и задан автоматический запуск
этой службы. Новые параметры или объекты групповой политики не могут быть обраб
отаны, пока не будет исправлена эта ситуация.
Возникло событие Error. Код события (EventID): 0x00000429
Время создания: 02/20/2016 13:48:26
Строка события:
Ошибка при обработке групповой политики. Windows не удалось применит
ь фильтр WMI для объекта групповой политики «cn=<01242029-8F13-4BC0-B5BE-EBAA855
D0BA1>,cn=policies,cn=system,DC=xxx». Возможные причины: отключение
RSOP, отключение или остановка службы WMI (Инструментария управления Windows), и
ные ошибки WMI. Проверьте, что служба WMI запущена и задан автоматический запуск
этой службы. Новые параметры или объекты групповой политики не могут быть обраб
отаны, пока не будет исправлена эта ситуация.
Возникло событие Error. Код события (EventID): 0x00000429
Время создания: 02/20/2016 13:51:06
Строка события:
Ошибка при обработке групповой политики. Windows не удалось применит
ь фильтр WMI для объекта групповой политики «cn=<01242029-8F13-4BC0-B5BE-EBAA855
D0BA1>,cn=policies,cn=system,DC=xxx». Возможные причины: отключение
RSOP, отключение или остановка службы WMI (Инструментария управления Windows), и
ные ошибки WMI. Проверьте, что служба WMI запущена и задан автоматический запуск
этой службы. Новые параметры или объекты групповой политики не могут быть обраб
отаны, пока не будет исправлена эта ситуация.
Возникло событие Error. Код события (EventID): 0x00000429
Время создания: 02/20/2016 13:56:08
Строка события:
Ошибка при обработке групповой политики. Windows не удалось применит
ь фильтр WMI для объекта групповой политики «cn=<01242029-8F13-4BC0-B5BE-EBAA855
D0BA1>,cn=policies,cn=system,DC=xxx». Возможные причины: отключение
RSOP, отключение или остановка службы WMI (Инструментария управления Windows), и
ные ошибки WMI. Проверьте, что служба WMI запущена и задан автоматический запуск
этой службы. Новые параметры или объекты групповой политики не могут быть обраб
отаны, пока не будет исправлена эта ситуация.
Возникло событие Error. Код события (EventID): 0x00000429
Время создания: 02/20/2016 14:01:10
Строка события:
Ошибка при обработке групповой политики. Windows не удалось применит
ь фильтр WMI для объекта групповой политики «cn=<01242029-8F13-4BC0-B5BE-EBAA855
D0BA1>,cn=policies,cn=system,DC=xxx». Возможные причины: отключение
RSOP, отключение или остановка службы WMI (Инструментария управления Windows), и
ные ошибки WMI. Проверьте, что служба WMI запущена и задан автоматический запуск
этой службы. Новые параметры или объекты групповой политики не могут быть обраб
отаны, пока не будет исправлена эта ситуация.
Возникло событие Error. Код события (EventID): 0x00000429
Время создания: 02/20/2016 14:06:12
Строка события:
Ошибка при обработке групповой политики. Windows не удалось применит
ь фильтр WMI для объекта групповой политики «cn=<01242029-8F13-4BC0-B5BE-EBAA855
D0BA1>,cn=policies,cn=system,DC=xxx». Возможные причины: отключение
RSOP, отключение или остановка службы WMI (Инструментария управления Windows), и
ные ошибки WMI. Проверьте, что служба WMI запущена и задан автоматический запуск
этой службы. Новые параметры или объекты групповой политики не могут быть обраб
отаны, пока не будет исправлена эта ситуация.
Возникло событие Error. Код события (EventID): 0x00000429
Время создания: 02/20/2016 14:11:14
Строка события:
Ошибка при обработке групповой политики. Windows не удалось применит
ь фильтр WMI для объекта групповой политики «cn=<01242029-8F13-4BC0-B5BE-EBAA855
D0BA1>,cn=policies,cn=system,DC=xxx». Возможные причины: отключение
RSOP, отключение или остановка службы WMI (Инструментария управления Windows), и
ные ошибки WMI. Проверьте, что служба WMI запущена и задан автоматический запуск
этой службы. Новые параметры или объекты групповой политики не могут быть обраб
отаны, пока не будет исправлена эта ситуация.
Возникло событие Error. Код события (EventID): 0x00000429
Время создания: 02/20/2016 14:16:16
Строка события:
Ошибка при обработке групповой политики. Windows не удалось применит
ь фильтр WMI для объекта групповой политики «cn=<01242029-8F13-4BC0-B5BE-EBAA855
D0BA1>,cn=policies,cn=system,DC=xxx». Возможные причины: отключение
RSOP, отключение или остановка службы WMI (Инструментария управления Windows), и
ные ошибки WMI. Проверьте, что служба WMI запущена и задан автоматический запуск
этой службы. Новые параметры или объекты групповой политики не могут быть обраб
отаны, пока не будет исправлена эта ситуация.
Возникло событие Error. Код события (EventID): 0x00000429
Время создания: 02/20/2016 14:21:18
Строка события:
Ошибка при обработке групповой политики. Windows не удалось применит
ь фильтр WMI для объекта групповой политики «cn=<01242029-8F13-4BC0-B5BE-EBAA855
D0BA1>,cn=policies,cn=system,DC=xxx». Возможные причины: отключение
RSOP, отключение или остановка службы WMI (Инструментария управления Windows), и
ные ошибки WMI. Проверьте, что служба WMI запущена и задан автоматический запуск
этой службы. Новые параметры или объекты групповой политики не могут быть обраб
отаны, пока не будет исправлена эта ситуация.
Возникло событие Error. Код события (EventID): 0x00000429
Время создания: 02/20/2016 14:26:20
Строка события:
Ошибка при обработке групповой политики. Windows не удалось применит
ь фильтр WMI для объекта групповой политики «cn=<01242029-8F13-4BC0-B5BE-EBAA855
D0BA1>,cn=policies,cn=system,DC=xxx». Возможные причины: отключение
RSOP, отключение или остановка службы WMI (Инструментария управления Windows), и
ные ошибки WMI. Проверьте, что служба WMI запущена и задан автоматический запуск
этой службы. Новые параметры или объекты групповой политики не могут быть обраб
отаны, пока не будет исправлена эта ситуация.
Возникло событие Error. Код события (EventID): 0x00000429
Время создания: 02/20/2016 14:31:22
Строка события:
Ошибка при обработке групповой политики. Windows не удалось применит
ь фильтр WMI для объекта групповой политики «cn=<01242029-8F13-4BC0-B5BE-EBAA855
D0BA1>,cn=policies,cn=system,DC=xxx». Возможные причины: отключение
RSOP, отключение или остановка службы WMI (Инструментария управления Windows), и
ные ошибки WMI. Проверьте, что служба WMI запущена и задан автоматический запуск
этой службы. Новые параметры или объекты групповой политики не могут быть обраб
отаны, пока не будет исправлена эта ситуация.
. serv1 — не пройдена проверка SystemLog

Источник

В этом руководстве я постараюсь рассказать вам о типичных причинах, по которым объект групповой политики (GPO) не может быть применён к организационном подразделении (OU), конкретному компьютеру или пользователю домена. Думаю, эта статья будет полезна как новичкам, так и IT-специалистам для понимания работы и архитектуры GPO. Прежде всего, я расскажу о возможных проблемах применения GPO, связанных с настройками политики на уровне домена, вместо устранения проблем с GPO на клиентах. Практически все параметры, описанные в статье, настраиваются с помощью Консоли управления групповыми политиками (GPMC.msc).

Управление областью действия GPO

Если параметр политики не применяется к клиенту, проверьте область действия GPO. Если вы настраиваете параметр в разделе Computer Configuration («Конфигурация компьютера»), ваша групповая политика должна быть сопряжена с организационным подразделением (OU) объектов компьютеров. То же самое верно, если вы установите свои параметры в разделе User configuration («Конфигурации пользователя»).

Также убедитесь, что объект, к которому вы пытаетесь применить свой GPO, находится в правильном контейнере AD (OU) компьютеров или пользователей. Если у вас много объектов и вы не можете вспомнить, в каком организационном подразделении находится нужный вам пользователь или компьютер, то вы можете выполнить поиск по объектам в своём домене. После выполнения поиска, чтобы узнать, в какое организационное подразделение (OU) помещён найденный объект, дважды кликните на него, перейдите на вкладку Object («Объект»), где в поле «Каноническое имя объекта» вы увидите полный путь, включающий имя организационного подразделения.

Связанная статья: Поиск по Active Director групп и пользователей с использованием подстановочных знаков

Это означает, что целевой объект должен находиться в подразделении, с которым связана политика (или во вложенном контейнере 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:

gwmi -Query 'select * from Win32_OperatingSystem where Version like "10.%" and ProductType="1"'

Если запрос возвращает какие-либо данные, то к этому компьютеру будет применён фильтр WMI.

Статус GPO

Проверьте статус GPO на вкладке Details свойств политики в GPMC.msc. Обратите внимание на значение в раскрывающемся списке GPO Status («Состояние объекта групповой политики»).

Как видите, доступно 4 варианта:

1. All settings disabled (Все настройки отключены) — все настройки политики отключены (GPO не применяется);
2. Computer configuration settings disabled (Параметры конфигурации компьютера отключены) — параметры только из конфигурации компьютера вашего GPO не применяются;
3. User configuration settings disabled (Параметры конфигурации пользователя отключены) — параметры из раздела конфигурации пользователя не применяются;
4. 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 применяются к клиентам в следующем порядке:

1. Политики локального компьютера (Local), настроенные в gpedit.msc (Редактор локальной групповой политики);
2. GPO уровня сайта (Site);
3. GPO уровня домена (Domain).
4. Объекты групповой политики с уровня организационного подразделения (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 (в русифицированной версии Конфигурация компьютера → Политики → Административные шаблоны → Система → Групповая политика → Настройка режима обработки замыкания пользовательской групповой политики). Например, если вы включите обработку обратной связи политики, зададите некоторые параметры в разделе «Конфигурация пользователя» и свяжете политику с подразделением с объектами компьютеров, эти параметры политики будут применены к выполнившим вход пользователям.

Этот режим обработки замыкания политики имеет два возможных значения:

1. Merge («Слияние») – сначала к пользователю применяется объект групповой политики на основе местоположения пользователя, а затем применяется объект групповой политики, связанный с компьютером. В случае конфликта политик OU пользователя и компьютера, политика компьютера будет иметь более высокий приоритет.
   В этом режиме политика запускается дважды, обратите внимание на это при использовании сценариев входа в систему.
2. Replace («Замена») – к пользователю будут применяться только политики, назначенные подразделению, содержащему компьютер, на котором пользователь вошёл в систему.

Устранение неполадок GPO на стороне клиента

Вы можете диагностировать применение GPO на стороне клиента с помощью gpresult, rsop.msc или Просмотра событий Windows (eventvwr.msc).

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

Чтобы увидеть журнал событий применения групповых политик, откройте Event Viewer («Просмотр событий»), это можно сделать с помощью команды:

eventvwr.msc

В средстве просмотра событий вы можете фильтровать события по источнику для этого нажмите «Создать настраиваемое представление» и в качестве источника выберите 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 как можно более простой и не создавать ненужных политик. Используйте прозрачную схему именования политик: имя должно чётко указывать, для чего предназначен объект групповой политики.

В этом руководстве я постараюсь рассказать вам о типичных причинах, по которым объект групповой политики (GPO) не может быть применён к организационном подразделении (OU), конкретному компьютеру или пользователю домена. Думаю, эта статья будет полезна как новичкам, так и IT-специалистам для понимания работы и архитектуры GPO. Прежде всего, я расскажу о возможных проблемах применения GPO, связанных с настройками политики на уровне домена, вместо устранения проблем с GPO на клиентах. Практически все параметры, описанные в статье, настраиваются с помощью Консоли управления групповыми политиками (GPMC.msc).

Управление областью действия GPO

Если параметр политики не применяется к клиенту, проверьте область действия GPO. Если вы настраиваете параметр в разделе Computer Configuration («Конфигурация компьютера»), ваша групповая политика должна быть сопряжена с организационным подразделением (OU) объектов компьютеров. То же самое верно, если вы установите свои параметры в разделе User configuration («Конфигурации пользователя»).

Также убедитесь, что объект, к которому вы пытаетесь применить свой GPO, находится в правильном контейнере AD (OU) компьютеров или пользователей. Если у вас много объектов и вы не можете вспомнить, в каком организационном подразделении находится нужный вам пользователь или компьютер, то вы можете выполнить поиск по объектам в своём домене. После выполнения поиска, чтобы узнать, в какое организационное подразделение (OU) помещён найденный объект, дважды кликните на него, перейдите на вкладку Object («Объект»), где в поле «Каноническое имя объекта» вы увидите полный путь, включающий имя организационного подразделения.

Связанная статья: Поиск по Active Director групп и пользователей с использованием подстановочных знаков

Это означает, что целевой объект должен находиться в подразделении, с которым связана политика (или во вложенном контейнере 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:

gwmi -Query 'select * from Win32_OperatingSystem where Version like "10.%" and ProductType="1"'

Если запрос возвращает какие-либо данные, то к этому компьютеру будет применён фильтр WMI.

Статус GPO

Проверьте статус GPO на вкладке Details свойств политики в GPMC.msc. Обратите внимание на значение в раскрывающемся списке GPO Status («Состояние объекта групповой политики»).

Как видите, доступно 4 варианта:

1. All settings disabled (Все настройки отключены) — все настройки политики отключены (GPO не применяется);
2. Computer configuration settings disabled (Параметры конфигурации компьютера отключены) — параметры только из конфигурации компьютера вашего GPO не применяются;
3. User configuration settings disabled (Параметры конфигурации пользователя отключены) — параметры из раздела конфигурации пользователя не применяются;
4. 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 применяются к клиентам в следующем порядке:

1. Политики локального компьютера (Local), настроенные в gpedit.msc (Редактор локальной групповой политики);
2. GPO уровня сайта (Site);
3. GPO уровня домена (Domain).
4. Объекты групповой политики с уровня организационного подразделения (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 (в русифицированной версии Конфигурация компьютера → Политики → Административные шаблоны → Система → Групповая политика → Настройка режима обработки замыкания пользовательской групповой политики). Например, если вы включите обработку обратной связи политики, зададите некоторые параметры в разделе «Конфигурация пользователя» и свяжете политику с подразделением с объектами компьютеров, эти параметры политики будут применены к выполнившим вход пользователям.

Этот режим обработки замыкания политики имеет два возможных значения:

1. Merge («Слияние») – сначала к пользователю применяется объект групповой политики на основе местоположения пользователя, а затем применяется объект групповой политики, связанный с компьютером. В случае конфликта политик OU пользователя и компьютера, политика компьютера будет иметь более высокий приоритет.
   В этом режиме политика запускается дважды, обратите внимание на это при использовании сценариев входа в систему.
2. Replace («Замена») – к пользователю будут применяться только политики, назначенные подразделению, содержащему компьютер, на котором пользователь вошёл в систему.

Устранение неполадок GPO на стороне клиента

Вы можете диагностировать применение GPO на стороне клиента с помощью gpresult, rsop.msc или Просмотра событий Windows (eventvwr.msc).

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

Чтобы увидеть журнал событий применения групповых политик, откройте Event Viewer («Просмотр событий»), это можно сделать с помощью команды:

eventvwr.msc

В средстве просмотра событий вы можете фильтровать события по источнику для этого нажмите «Создать настраиваемое представление» и в качестве источника выберите 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 как можно более простой и не создавать ненужных политик. Используйте прозрачную схему именования политик: имя должно чётко указывать, для чего предназначен объект групповой политики.

На одном из компьютеров перестали применяться новые параметры групповых политик. Для диагностики я вручную обновил параметров GPO с помощью команды
gpupdate /force
и увидел такую ошибку в консоли:

Не удалось успешно обновить политику компьютера. Обнаружены следующие ошибки:
Ошибка при обработке групповой политики. Windows не удалось применить основанные на данных реестра параметры политики для объекта групповой политики "LocalGPO". Параметры групповой политики не могут быть применены, пока не будет исправлена эта ситуация. Сведения об имени и пути файла, вызвавшего эту ошибку, содержатся в подробностях об этом событии.

Computer policy could not be updated successfully. The following errors were encountered:
 The processing of Group Policy failed. Windows could not apply the registry-based policy settings for the Group Policy object LocalGPO. Group Policy settings will not be resolved until this event is resolved. View the event details for more information on the file name and path that caused the failure.

При этом в журнале System появляется событие с EvetID 1096 с тем же описанием (The processing of Group Policy failed):

Log Name:     System
Source:       Microsoft-Windows-GroupPolicy
Event ID:     1096
Level:         Error
User:         SYSTEM

Если попробовать выполнить диагностику применения GPO с помощью команды gpresult (
gpresult.exe /h c:\tempt\gpresultreport.html
), видно что не применяется только настройки из раздела Group Policy Registry —
Failed
:

Registry failed due to the following error listed below.
Additional information may have been logged. Review the Policy Events tab in the console or the application event log.

Получается, что к компьютеру не применяются только GPO с настройками клиентских расширений групповых политик CSE (client-side extension), которые отвечают за управление ключами реестра через GPO.

Расширение Registry client-side не смогло прочитать файл registry.pol. Скорее всего файл это поврежден (рекомендуем проверить файловую систему на ошибки с помощью chkdsk). Чтобы пересоздать этот файл, перейдите в каталог c:\Windows\System32\GroupPolicy\Machine и переименуйте его в registry.bak.

Можно переименовать файл из командой строки:

cd "C:\Windows\System32\GroupPolicy\Machine"
ren registry.pol registry.bak

Обновите настройки групповых политик командой:

gpupdate /force

Windows должна пересоздать файл registry.pol (настройки локальных GPO будут сброшены) и успешно применить все настройки GPO.

Если в журнале вы видите событие Event ID 1096 (
The processing of Group Policy failed. Windows could not apply the registry-based policy settings for the Group Policy object LDAP://
) c ErrorCode 13 и описанием “
The data is invalid
”, значит проблема связана с доменной GPO, указанной в ошибке.

Скопируйте GUID политики и найдите имя GPO с помощь команды PowerShell:

Get-GPO -Guid 19022B70-0025-470E-BE99-8348E6E606C7

• Запустите консоль управления доменными GPO (gpmc.msc) и проверьте, что политика существует;
• Проверьте, что в каталоге SYSVOL политики есть файлы registry.pol и gpt.ini и они доступны на чтение (проверьте NTFS права);
• Проверьте, что версия политики на разных контроллерах домена одинакова (проверьте корректность работы домена и репликации в AD);
• Удалите файлы GPO в SYSVOL на контроллере домена, с которого получает политику клиент (
  $env:LOGONSERVER
  ), и дождитесь ее репликации с соседнего DC
• Если предыдущие способы не помогут, пересоздайте GPO или восстановите ее из бэкапа.