Ошибка при обработке групповой политики windows не удалось применить фильтр wmi

Обновлено: 08.01.2025

В этой статье мы поговорим о технологии WMI (Windows Management Interface) фильтрации в групповых политиках. Данная технология позволяет создать различные правила, на основании которых можно выбрать к каким объектам домена AD или конкретного OU будет применяться групповая политика, а к каким не будет.

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

Напомню, что WMI фильтры групповых политик впервые появились в Windows XP, и в последующих версиях Windows (Windows Server 2003, Windows 7 Windows Server 2008), эта технология продолжала применяться и развиваться. WMI фильтрация GPO не работает для ОС семейства Windows 2000, так что придется обновится! ( я думаю 12 лет это достаточный срок для того, чтобы обновить старую версию ОС на более новую).

Попробуем попрактиковаться в применении WMI фильтров групповых политик. Тестовое задание будет следующим: необходимо применить групповую политику на все сервера, на которых установлена ОС Windows Server 2008 R2

WMI запрос, позволяющий выбрать все сервера на Windows Server 2008 R2, будет выглядеть так:

Если вас интересуют другие версии ОС Windows, воспользуйтесь следующим значениями WMI параметра Version:

В зависимости от того, является ли целевой компьютер клиентом или сервером, нужно указать следующее значение параметра ProductType:

Клиент: ProductType=1

Контроллер домена: ProductType=2

Сервер: ProductType=3

Чтобы отфильтровать все компьютеры с Windows 8, WMI запрос будет таким:

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

На тестовых клиентах необходимо дождаться применения политик или же запустить принужительное обновление командой gpupdate /force. И проверить, что политика применяется только на серверас с Windows Server 2008 R2 (для просмотра примененных политик воспользуйтесь командой gpresult /r).

Приведу еще рад WMI запросов, которые можно использовать для создания WMI фильтров групповых политик:

Выбрать все машины, на которых установлен Internet Explorer 8

Компьютеры, с количество оперативной памяти на которых больше 1 Гб

WMI запрос, позволяющий выбрать все сервера на Windows Server 2008 R2, будет выглядеть так:

Если вас интересуют другие версии ОС Windows, воспользуйтесь следующим значениями WMI параметра Version:

Клиент: ProductType=1

Контроллер домена: ProductType=2

Сервер: ProductType=3

Чтобы отфильтровать все компьютеры с Windows 8, WMI запрос будет таким:

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

Приведу еще рад WMI запросов, которые можно использовать для создания WMI фильтров групповых политик:

Описание проблемы

И так есть терминальная ферма, состоящая из 5 хостов на Windows Server 2008 R2, в качестве посредника подключений используется балансировщик KEMP LpadMaster. Выяснилось, что пользователи не подключаются к одному из хостов. Зайдя на сервер и попытавшись открыть консоль "Конфигурация узла сеансов удаленных рабочих столов" выскочило окно с предупреждением:

Не удалось запустить диагностику лицензирования из-за возникшей неполадки. Перезапустите средство настройки сервера узла сеансов.

Если попытаться раскрыть данный узел настроек, то выскакивало предупредительное окно:

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

И потом уже со значком фатальной ошибки.

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

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

Методы решения проблемы

И так давайте с вами решим эту проблему и вернем вашего участника фермы в рабочее состояние, чтобы пользователи могли спокойно работать. Первым делом я вам советую посмотреть ваши логи в просмотре событий. У себя я в журнале "Система" нашел все тот же код события 1069: Льготный период лицензирования удаленных рабочих столов закончился, а режим лицензирования для сервера, обслуживающего сеансы подключения к удаленному рабочему столу, не настроен. Для постоянной работы необходимо настроить режим лицензирования.

Кодом события 1069 у меня был забит весь журнал, данная ошибка валилась, чуть ли не каждые 5 минут.

Так же можно встречать ошибку: не удалось запустить службу удаленного рабочего стола. Соответствующий код состояния: 0x800706be.

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

Иду проверять свой чеклист дальше, так как у меня все настройки на хосты к которым идет подключение применяются посредством групповых политик, благо есть домен Active Directory со всеми плюшками его использования. Для того, чтобы проверить применяются ли политики к данному хосту нужно выполнить результирующую политику с помощью команды RSOP.

Для этого откройте power shell или командную стоку от имени администратора и введите команду rsop. В идеале у вас должна появиться результирующая политика, в которой вы сможете посмотреть все примененные параметры, но у меня выскочило предупреждение.

Не удалось создать данные результирующей политики из-за указанной ниже ошибки. Not Found

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

Чтобы диагностировать сбой, просмотрите журнал событий или запустите GPRESULT /H GPReport.html из командной строки просмотра сведений о результатах групповой политики

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

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

В редакторе управления групповой политикой я нашел нужную мне политику, и вижу, что к ней действительно применяется определенный 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 <Инструментарий управления Windows>, иные ошибки WMI. Проверьте, что служба WMI запущена и задан автоматический запуск этой службы. Новые параметры или объекта групповой политики не могут быть обработаны, пока не будет исправлена эта ситуация."

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

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

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

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

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

21.03.2019

Active Directory, Групповые политики

комментариев 8

Область действия (scope) GPO

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

Также проверьте, что объект, к которому вы пытаетесь применить политику находится в нужном OU с компьютерами или пользователями. Можно воспользоваться поиском по домену. OU, в котором находится объект содержится на вкладке Object в консоли ADUC.

Т.е целевой объект должен находится в OU, на который назначена политика (или во вложенном контейнере).

Фильтр безопасности GPO

Если вы решили изменить этот фильтр безопасности, чтобы политика применялась только к членам определенной группы безопасности домена (или конкретным пользователям/ компьютерам), удалив группу Authenticated Users, убедитесь, что целевой объект (пользователь или компьютер) добавлен в эту группу AD. Также проверьте, что для группы, которую вы добавили в Security Filtering на вкладке GPO -> Delegation -> Advanced в списке разрешений присутствуют права Read и Apply group policy с полномочиями Apply.

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

WMI фильтры GPO

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

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

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

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

Статус групповой политики

Проверьте статус групповой политики, перейдя в консоли GPMC.msc в свойствах политики на вкладку Details. Обратите внимание на значение в поле GPO Status.

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

All setting disabled – все настройки политики отключены (не применяются);
Computer configuration settings disabled – не применяются настройки из параметров GPO компьютера;
User configuration settings disabled – не применятся настройки пользовательских политик;
Enabled – все настройки политики применяются к целевым объектам AD (значение по –умолчанию).

Делегирование GPO

На вкладке политики Delegation указаны разрешения, настроенные для данной групповой политики. Здесь можно увидеть каким группам даны права на изменения настроек GPO, а также на разрешение или запрет применения политики. Вы можете предоставить права на управление GPO из этой консоли или с помощью мастера делегирования в ADUC. Кроме того, наличие строки доступа для Enterprise Domain Controllers определяет возможность репликации данной политики между контроллерами домена Active Directory (это нужно иметь в виду при наличии проблем с репликацией политики между DC). Обратите внимание, что права на вкладке Delegation соответствуют NTFS правам, назначенным на каталог политики в папке SYSVOL

Наследование групповых политик

Наследование это одна из основных концепции групповых политик. Политики верхнего уровня по-умолчанию применяются ко всем вложенным объектам в иерархии домена. Однако, администратор может заблокировать применение всех наследованных политик на определенный OU. Для этого в консоли GPMC нужно щелкнуть ПКМ по OU и выбрать пункт меню Block inheritance.

Организационные подразделения с отключенным наследованием политик в консоли отображаются с синим восклицательным знаком.

Если политика не применяются на клиенте, проверьте, не находится ли он в OU с отключенным наследованием.

Имейте в виду, что доменные политики, для которых включено свойства “Enforced”, применяются даже на OU с отключённым наследованием (наследованные политики, которые применяются к контейнеру доступны на вкладке Group Policy Inheritance).

Область действия и порядок применения групповых политик (LSDOU)

Чтобы запомнить особенности порядка применения групповых политик в домене, нужно запомнить аббревиатуру LSDOU. Это аббревиатура позволяет запомнить порядок применения GPO:

Локальные политики компьютера (Local), настроенные через gpedit.msc (при некорректной настройке их можно сбросить);
Групповые политики уровня сайта (Site);
Групповые политики уровня домена (Domain);
Групповые политики уровня организационного подразделения (Organizational Unit).

Последние политики имеют наивысший приоритет. Т.е. если вы включили некий параметр 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 не удаляется из иерархии. Вы можете активировать данную связь в любой момент.

Замыкание групповой политики

При включении опции Режим замыкания групповой политики (Loopback Processing mode) вы можете применить к компьютеру настройки, которые содержаться в секции GPO с настройками пользователями. Например, если вы примените к OU с компьютерами политику, в которой настроены параметры в секции User Configurations, эти политики не будут применены к пользователю бзз использования замыкания. Режим Loopback Processing включается в разделе Computer Configuration -> Administrative Templates -> System -> Group Policy -> Configure user Group Policy Loopback Processing mode.

У этой политики есть два возможных значение:

В этом режиме политика отрабатывает дважды, об этом нужно помнить при использовании; logon скриптов.

Диагностика применения GPO на стороне клиента

Вы можете провести диагностику применения групповых политик на стороне клиента с помощью утилит gpresult, rsop.msc и журнала событий Windows. При использовании Event Viewer нужно использовать фильтр по источнику GroupPolicy (Microsoft-Windows-GroupPolicy), а также в журнале Application and Services Logs -> Microsoft -> Windows -> Group Policy -> Operational.

Также можете познакомиться со статей, описывающей принципы диагностики при слишком долгом применении политик на клиентах.

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

Примененные объекты групповой политики
---------------------------------------
test
Default Domain Policy
Политика локальной группы

В результирующей политике написано

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

Обновление политики пользователя завершено успешно.
Обновление политики для компьютера успешно завершено.

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

Windows не удалось применить параметры "Scripts". Параметры "Scripts" могут имет
ь свой собственный файл журнала. Щелкните ссылку "Дополнительные сведения".

У меня тут другая трабла(
потребовалось создать некоторые GP. ну в общем создал только они не применяются! GP крайне просты - одна содержит только Logon script в виде bat файла для смены основного шлюза и dns сервера ( в сети используется статическая адресация ) и вторая содержит параметры настройки proxy сервера - указывает путь до proxy.pac файла.
так вот ни та ни другая не применяется на клиентах. Пытался писать gpupdate /force и на сервере и на клиенте. Старые политики как работали так и работают, а вот новые не хотят подхватываться. Политики добавлял в раздел GPM -> Group Policy Object и далее делал ссылки в соответствующих OU в том же GPM на существующую политику. Так работают все нынешние политики - по другому у меня не работало.
В логах клиента и сервера ни чего странного.

задела меня мысля гражданина mattveiko по поводу прав. думаю авось и вправду он прав! Ну прикрутил я значится щас к своему скрипту права админа домена и О ЧУДО! он сработал, НО ладно скрипт, а что делать с обычными настройками GP такими как параметры автоматической конфигурации прокси сервера? я конечно могу написать и для его изменения батник, там всё просто - настройки для IE прокси хранятся в известной ветке реестра.

и всё таки мне всю жизнь казалось что GP применяются именно с правами NT AUTHORITY/SYSTEM.

контроллер домена и и сервер на вин сервер 2008 р2 сп1
создаю пользоваелей и назначаю локальные политки. делаю gpupdate,в 1-й раз принменяются

если потом в политике на какого-ниь юзера менять что-то, то эти измененния не применяются, хотя после gpupdate /force типов все успевшно.

Всё о PowerShell в Windows и на Linux. Системное администрирование Windows

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

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

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

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

Это означает, что целевой объект должен находиться в подразделении, с которым связана политика (или во вложенном контейнере AD).

Фильтрация безопасности в GPO

Проверьте настройки Security Filtering («фильтрации безопасности») в своей политике. По умолчанию для всех новых объектов GPO в домене включены разрешения для группы Authenticated Users («Прошедшие проверку»). В эту группу входят все пользователи и компьютеры в домене. Это означает, что политика будет применяться ко всем пользователям и компьютерам в пределах её области действия.

Если вы хотите изменить фильтрацию безопасности, чтобы применить политику только к членам определённой группы безопасности (или определенным пользователям/компьютерам), удалите «Authenticated Users» из списка фильтрации безопасности и убедитесь, что целевой объект (пользователь или компьютер) добавлен в нужную вам группу AD. Также убедитесь, что группа, которую вы добавили в фильтр безопасности, имеет разрешения Read и Apply group policy с установленным флажком Allow («Разрешить») в GPO → Delegation → кнопка Advanced (GPO → Делегирование → кнопка «Дополнительно»).

Если вы используете нестандартные фильтры безопасности GPO, убедитесь, что нет явного запрета на использование GPO для целевых групп (Deny).

Фильтрация GPO WMI

В объекте групповой политики можно использовать специальные фильтры WMI. Таким образом, вы можете применить политику к своим компьютерам на основе некоторого запроса WMI. Например, вы можете создать фильтр WMI GPO для применения политики только к компьютерам с определённой версией Windows, к компьютерам в определённой IP-подсети, только к ноутбукам и так далее.

При использовании фильтрации WMI групповой политики убедитесь, что ваш запрос WMI верен. Он должен выбирать только те системы, которые вам нужны, и ни один целевой компьютер не исключается. Вы можете протестировать свой WMI-фильтр на компьютерах с помощью PowerShell:

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

Статус GPO

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

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

All settings disabled (Все настройки отключены) — все настройки политики отключены (GPO не применяется);
Computer configuration settings disabled (Параметры конфигурации компьютера отключены) — параметры только из конфигурации компьютера вашего GPO не применяются;
User configuration settings disabled (Параметры конфигурации пользователя отключены) — параметры из раздела конфигурации пользователя не применяются;
Enabled (Включено) — все настройки GPO применяются к целевым объектам AD (значение по умолчанию).

Делегирование групповой политики

Разрешения, настроенные для политики, отображаются на вкладке «Делегирование» объекта групповой политики. Здесь вы можете увидеть, какие члены группы могут изменять параметры этого объекта групповой политики и применяется ли к ним политика. Вы можете предоставить права на управление GPO с этой консоли или с помощью мастера делегирования Active Directory в ADUC. Если есть разрешение на доступ Enterprise Domain Controllers («Контроллеры домена предприятия»), эта политика может быть реплицирована между контроллерами домена Active Directory (обратите внимание на это, если у вас есть какие-либо проблемы репликации политики между контроллерами домена). Обратите внимание, что разрешения на вкладке «Делегирование» соответствуют разрешениям NTFS, назначенным каталогу политики в папке SYSVOL.

Блокирование наследования и принудительное применение в ссылке групповой политики

Наследование — одна из основных концепций GPO. По умолчанию политики высокого уровня применяются ко всем вложенным объектам в иерархии домена. Однако администратор может заблокировать применение всех унаследованных политик к определённому подразделению. Для этого щёлкните правой кнопкой мыши подразделение в консоли управления групповыми политиками и выберите Block inheritance («Заблокировать наследование»).

Подразделения с включённой опцией заблокированного наследования отмечены синим восклицательным знаком в консоли.

Если политика не применяется к клиенту, проверьте, не принадлежит ли он подразделению с заблокированной опцией наследования.

Обратите внимание, что политики домена с включённым свойством Enformed применяются даже к подразделениям с заблокированным параметром наследования (вы можете увидеть унаследованные политики, применённые к контейнеру, на вкладке Group Policy Inheritance).

Область действия GPO и порядок приоритетной обработки (LSDOU)

Чтобы запомнить порядок, в котором групповые политики применяются в домене, запомните аббревиатуру LSDOU. GPO применяются к клиентам в следующем порядке:

Политики локального компьютера (Local), настроенные в gpedit.msc (Редактор локальной групповой политики);
GPO уровня сайта (Site);
GPO уровня домена (Domain).
Объекты групповой политики с уровня организационного подразделения (Organizational Unit).

Последние политики имеют наивысший приоритет. Это означает, что если вы включите какой-либо параметр Windows на уровне домена, он может быть отключён другой политикой на уровне организационного подразделения (если представить иерархию AD, то чем ближе в этой иерархии групповая политика к объекту, тем выше у неё приоритет).

При использовании опции Forced («Принудительно») приоритет будет отдаваться политике, стоящей выше в иерархии домена (например, если для политики домена по умолчанию включён параметр Forced («Принудительно»), она будет иметь более высокий приоритет, чем любой другой объект групповой политики).

Администратор также может изменить порядок обработки политики с помощью консоли GPMC (Управление групповой политикой). Для этого выберите подразделение и перейдите на вкладку Linked Group Policy Objects («Связанные объекты групповой политики»). Там вы увидите список GPO, применённых к этому OU с указанным приоритетом. Политики обрабатываются в обратном порядке (снизу вверх). Это означает, что в последнюю очередь будет применяться политика с Link Order 1 (Порядком ссылки 1). Вы можете изменить приоритет GPO, используя стрелки в левом столбце, и переместить политику вверх или вниз в списке.

Link Enabled Setting («Связь включена») для GPO

Для любого объекта GPO, связанного с организационным подразделением AD, может быть включена или отключена опция Link Enabled («Связь включена»). Если связь отключена, её значок становится серым. Когда связь отключена, политика не применяется к клиентам, но ссылка на объект GPO не удаляется из иерархии домена. Вы можете включить связь в любое время.

Как включить GPO Loopback Processing Mode (режим обработки замыкания GPO)

Если вы включили Loopback Processing mode («Режим обработки замыкания»), вы можете применить настройки из раздела «Конфигурация пользователя» к объекту компьютера. Вы можете включить режим кольцевой обработки в следующем разделе редактора GPO: Computer Configuration → Policies → Administrative Templates → System → Group Policy → Configure user Group Policy Loopback Processing mode (в русифицированной версии Конфигурация компьютера → Политики → Административные шаблоны → Система → Групповая политика → Настройка режима обработки замыкания пользовательской групповой политики). Например, если вы включите обработку обратной связи политики, зададите некоторые параметры в разделе «Конфигурация пользователя» и свяжете политику с подразделением с объектами компьютеров, эти параметры политики будут применены к выполнившим вход пользователям.

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

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

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

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

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

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

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

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

Вы также можете прочитать статью «Устранение неполадок, связанных с медленной обработкой GPO и снижением скорости входа в систему», в которой описаны некоторые дополнительные принципы диагностики объектов групповой политики.

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

Читайте также: