Как найти проблему в групповой политике

Обновлено 30.07.2021

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org, в прошлый раз я вам показал, как я делал досрочное погашение ипотеки Сбербанка, поделился свои жизненным опытом. Сегодня я хочу вас научить, как находить и диагностировать причины, по которым у вас может не применяться назначенная вами групповая политика к компьютеру или пользователю или целому организационному подразделению. Мы рассмотрим все этапы, через которые проходит происходит взаимодействие с GPO. Разберем утилиты, которыми должен владеть системный администратор в задачи которого входит создание и назначение политик. Уверен, что данный пост будет вам полезен и интересен.

За, что Active Directory от Microsoft получила такую популярность? Одним из ответов на данный вопрос, будет функционал групповой политики. Все администраторы, как и большинство современных людей, существа очень ленивые и любят, когда все централизованно управляется и по возможности автоматизированно. Именно объекты GPO, позволяют производить настройки десятков, сотен и тысяч компьютеров, из одного места и практически по всем направлениям, например добавление принтеров, скриптов входа, профилей WiFi и многое другое.

Очень частые ситуации, что системный администратор создал новую групповую политику, применил ее на нужный ему объект, но эффекта это не дало и нужно понять почему она не применилась и вот тут начинающие системные администраторы попадают в просак, не понимая, где и что нужно искать. Ниже мы с вами разберем алгоритм действий, который поможет вам найти причину и восстановить работу применения групповой политики на нужный объект.

К чему применяется групповая политика (GPO)

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

• что реестр есть как для объекта компьютер
• и реестр есть для объекта пользователь

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

1. Это контейнер — по сути простая папка, важно, что к ней нельзя применять объекты групповой политики.
2. Второй тип, это организационные подразделения (OU) — это специальные папки для объединения объектов AD по принципам. Именно с OU связываются объекты групповой политики, для применения их к компьютерам и пользователям. Внешне контейнер отличается от организационной утилитой, тем что у OU, есть дополнительная лычка на значке, это показано на скриншоте.

Алгоритм устранения проблем с GPO

Предположим, что у меня есть групповая политика, которая применяется на организационное подразделение «Client Computers«. Политика называется «Управление UIPI». По какой-то причине пользователь жалуется, что она у него не применилась.

Из информации, об области действия групповой политики, первое на что нужно обратить свое внимание, это находится ли объект пользователя или компьютера по нужному пути. Сделать, это просто в оснастке «Управление групповой политикой» найдите вашу политику и посмотрите к каким OU она применяется, это видно на вкладке «Область (Scope)», ее еще называют областью действия политики. В моем случае, это путь root.pyatilistnik.org/Client Computers.

Так как Active Directory, это иерархическая структура, то одна OU можете быть часть дерева из других и сама включать в себя большое количество организационных подразделений. Поэтому если у вас есть вложенность, то просто зайдя в нужную OU вы можете сразу не найти нужный объект. В таком случае воспользуйтесь поиском по Active Directory. Например у меня есть рабочая станция с которой идут жалобы на применение объекта GPO. В поиске выбираем в поле «Найти» компьютеры и в имени указываем w10-cl01, после чего нажимаем «Найти». В результатах поиска вы получите выдачу. Щелкаем по нужному объекту и переходим в нем на вкладку «Объект», где смотрим «Каноническое имя объекта«, по сути это его путь расположения в Active Directory. Сравниваем его с тем, что получили из области применения групповой политики и делаем вывод, попадает объект под действие или нет.

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

Следующим моментом необходимо проверить, что политика не отключена на определенный объект. Для этого перейдите на вкладку «Сведения» на нужной GPO. Нас интересует строка «Состояние GPO». По умолчанию там стоит значение «Включено«, означающее, что политика будет пытаться примениться заданные в ней настройки к обоим типам объектов (Пользователю и компьютеру). Но может быть выставлено значение:

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

Выше я вам писал, что структура OU иерархическая, а это означает, что политика прилинкованная с вышестоящего организационного подразделения применяется на нижестоящее. Но вот если у нижестоящей OU отключено наследование сверху, то он не сможет применить данную политику. Проверяется очень просто, найдите нужную вам OU, щелкните по ней правым кликом и удостоверьтесь, что не стоит пункт «Блокировать наследование».

Он кстати будет иметь характерный значок с восклицательным знаком. Данный механизм создан специально, чтобы изолировать данную OU от ненужных политик GPO.

Проверка прав на политику

Объекты групповой политики, так же имеют свой ACL (лист доступа), это означает, что вы можете более тонко настраивать к каким объектам применяется данная политика. В редакторе «Управление групповой политикой» выберите ваш GPO. На вкладке «Область» найдите раздел «Фильтры безопасности«, он отображает к каким объектам применяется политика. Данный фильтр безопасности может включать объекты:

• Пользователь
• Компьютер
• Группа безопасности

Если у вас тут выставлена другая группа или отдельные записи, то убедитесь, что нужный объект состоит в данном ACL. Хочу отметить, что если даже нужный объект присутствует в списке фильтра безопасности, то это не означает, что политика к нему применяется и тут дело все в том, что в 2014 году Microsoft изменила принцип чтения политики, таким образом, что у вас в делегированном фильтре безопасности обязательно должна присутствовать группа «Компьютеры домена» или «Прошедшие проверку» у которой должны быть прав на чтение политики. Вся соль в том, что когда вы удаляете группу «Прошедшие проверку» из фильтра безопасности, она удаляется и из вкладки делегирование.

Поэтому перейдите на вкладку «Делегирование» и проверьте наличие любой из групп «Прошедшие проверку» или «Компьютеры домена» и, что есть права на чтение. Если групп нет, то добавьте любую из них. Для этого нажмите кнопку «Дополнительно», далее добавить и выберите «Прошедшие проверку».

Удостоверьтесь, что выставлена галка «Чтение».

Тут же убедитесь, что нет запретов на нужный вам объект, в моем примере, это W10-CL03. Если есть снимите.

Обратите внимание на группу «КОНТРОЛЛЕРЫ ДОМЕНА ПРЕДПРИЯТИЯ (Enterprise Domain Controllers)» данная группа определяет, будет ли происходить репликация данной политики на другие контроллеры или нет, так что если политика отсутствует в папке SYSVOL на других контроллерах, то проверьте права у данной группы.

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

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

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

Существуют три инструмента, которые вам покажут информацию, о применяемых политиках на объекты:

• Утилита командной строки gpresult
• Утилита rsop
• Моделирование групповой политики в оснастке gpmc.msc
• Результаты групповой политики

Диагностика GPO через gpresult

Gpresult первое средство, которое позволит системному администратору определить на каком этапе есть проблемы с выполнением GPO. Откройте на клиентском компьютере или ноутбуке командную строку от имени администратора и введите команду:

В моем примере у меня есть политика для компьютера «Управление UIPI», поэтому я воспользуюсь gpresult для компьютера. Выполнив gpresult /r /scope:computer я вижу, что моя политика не применилась и числится в списке «Следующие политики GPO не были применены, так как они отфильтрованы». Фильтрация отказано в доступе (Безопасность). Из этого видно, что у компьютера просто нет прав на чтение политики.

Так же в логах Windows вы можете обнаружить событие с кодом ID 5313:

А вот пример 5313, но с уже WMI фильтром:

Я для исключаю его из запрета применения и пробую новую попытку применения политики. Я делаю для начала обновление групповой политики через gpupdate /force и затем снова выполняю команду gpresult /r /scope:computer, где теперь вижу, что политика не применилась из-за WMI фильтра. Теперь уже понятно куда копать.

Получение данных GPResult с удаленного компьютера GPResult /s server01 /r, поможет администратору или технической поддержке собрать диагностические данные. Аналогичные действия вы можете выполнять и для пользователя, тут все аналогично. Теперь воспользуемся утилитой RSOP. Откройте окно выполнить и введите rsop.msc.

Начнется сбор применяемых политик.

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

Но это не удобно и мы можем совместить две утилиты gpresult и Resultant Set of Policies (RSoP), получив выгодный симбиоз. В командной строке введите:

На выходе вы получите удобный html отчет, о всех примененных или отфильтрованных политиках. Открыв отчет, вы легко поймете ,какие политики были применены, а какие нет и можете сразу посмотреть значения настроек.

Результаты групповой политики

В оснастке GPMC есть возможность посмотреть какие политики применяются к нужному объекту групповой политики. Данный мастер называется «Результат моделирования групповой политики». Щелкаем по нему правым кликом и открываем мастер.

Выбираем нужный компьютер, к которому мы хотим проверить применение политики.

Если в момент добавления компьютера у вас выскочит ошибка «Сервер RPC-недоступен», то проверьте, что у вас запущена на нем служба WMI и в брандмауэре открыты порты для подключения к ней.

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

Нажимаем далее. У вас появится отчет. Раскрыв его на вкладке «Сведения» вы увидите, какие политики применены, а какие нет.

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

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

На первом шаге мастера моделирования групповой политики, будет простое уведомление, что к чему, нажимаем далее.

Далее вам будет предложен выбор, дабы указать нужный контроллер домена.

Теперь выбираем нужную OU, для которой мы будем тестировать групповую политику. Делается все через кнопку «Обзор». Я выбрал «Client Computers»

Нажимаем далее.

На следующем шаге мастера моделирования групповой политики, вам предоставят сэмулировать таки параметры:

• Медленное сетевое подключение, меньше 500 кб/с
• Обработка петлевого адреса (Замыкание групповой политики — loopbacl policy) — это опция когда вы применяете для OU в которой находятся компьютеры, например терминальные сервера, политики для пользователя. Делается это для того, чтобы политики применяемые к пользователю на его рабочей станции или другом сервере от тех, что в данной OU. Можете подробно почитать, что такое замыкание групповой политики.
• Выбор сайта.

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

далее вы можете применить любой из фильтров WMI, который вы хотите тестировать.

Нажимаем далее.

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

На этом у меня все. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org. Надеюсь, что статья оказалась полезной.

Как подготовиться к работе с групповыми политиками

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

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

Наиболее характерные типы проблем

Неполадки, которые возникают в процессе использования групповых политик, могут принимать различные формы. Чаще всего они проявляются в виде нарушений работы приложений на компьютерах пользователей. Либо это могут быть проблемы администрирования, возникающие у специалистов, обслуживающих эти компьютеры. Если говорить более определенно, то в большинстве известных мне случаев подобные проблемы были связаны с двумя основными типами политик, а именно с политиками установки ограничений на компьютеры пользователей (desktop lockdown policies) и с политиками безопасности (security policies).

Политики установки ограничений на компьютеры пользователей

В одной из сетей, сопровождением которых я занимаюсь, использование политики скрытия дисков Administrative Templates Hide Drives (User ConfigurationAdministrative TemplatesWindows ComponentsWindows ExplorerHide these specified drives in My Computer) привело к отказу «старых» приложений. В результате начали появляться сообщения об ошибках, не имеющих никакого отношения к групповым политикам. Поэтому даже в тех случаях, когда настройки групповых политик не затрагивают напрямую те и или иные приложения, вносимые ими ограничения могут привести к ряду ошибок, не имеющих должного описания, что может сбить с толку как пользователя, так и администратора. Например, если для запрета запуска некоторых приложений задействовать политику User ConfigurationAdministrative TemplatesSystemDon?t run specified Windows applications, при попытке запуска соответствующего приложения пользователь получит стандартное сообщение об ошибке, показанное на экране 1.

При использовании административных шаблонов политик (Administrative Templates) в реестре устанавливаются соответствующие параметры, относящиеся к пользователям или компьютерам, значения которых будут затем применяться различными компонентами Windows для внесения ограничений и их использования (к подобным компонентам относятся, например, Windows Explorer, Microsoft Internet Explorer (IE) и Windows Media Player (WMP)). Отмечу, что возможность управления работой этих компонентов Windows через групповые политики была заложена изначально, поскольку в процессе их разработки была предусмотрена возможность работы данных приложений с параметрами реестра, относящимися к групповым политикам. Другими словами, для того чтобы можно было управлять работой приложения через групповые политики, его разработчик должен сознательно заложить в него возможность работы с параметрами реестра, относящимися к групповым политикам. Если для блокировки или скрытия тех или иных компонентов программной среды компьютера применяются административные шаблоны политик, то вносимые ими ограничения могут повлиять на работу пользовательских приложений самым неожиданным образом.

Если пользователь видит сообщение, подобное изображенному на экране 1, то не сразу становится ясно, что его появление связано с групповой политикой, и тем более непонятно, как именно. Особенно сложно бывает понять причины возникшей проблемы в тех случаях, когда вы не являетесь администратором, разработавшим данную политику, и не имеете возможности посмотреть, какие именно объекты групповой политики (GPO) применялись к данному пользователю или компьютеру. Далее будет показано несколько примеров тактики распознавания вероятных причин подобных проблем.

В некоторых случаях может вообще не выводиться никаких сообщений об ошибках, особенно если речь идет о взаимодействии приложений независимых компаний с системой, на которой действуют установки политики по ограничению использования тех или иных компонентов. Подобного рода взаимодействия, как правило, бывают недостаточно полными, поскольку разработчики таких приложений не проверяют их на предмет возможности применения в среде с действующими в ней ограничениями и не используют функции прикладного интерфейса API, позволяющие взаимодействовать с параметрами групповых политик. Таким образом, важно знать, придерживаются ли поставщики программного обеспечения спецификаций для приложений от компании Microsoft, в которых, помимо всего прочего, детально описывается, как следует разрабатывать приложения, чтобы они корректно взаимодействовали с механизмами групповых политик. Спецификацию по разработке приложений для Windows XP (Designed for Windows XP Application Specification) можно загрузить по адресу: http://www.microsoft.com/downloads/
details.aspx?FamilyID=44aa70b3-99d9-4529-9117-82cc0845938b&displaylang=en.

Политики безопасности

Предположим, администратору нужно лишить пользователей, не имеющих административных прав, возможности регистрации на некоторых серверах. В этом случае он должен контролировать состав групп, имеющих право локальной регистрации (Logon locally) на соответствующих серверах. И вот наш администратор, по невнимательности, ссылается на объект GPO, отвечающий за политику домена, без установки фильтров безопасности, предписывающих применять данную политику только к тем серверам, на которые необходимо ограничить доступ. В результате после того, как компьютеры компании обработают доменную политику, ни один из пользователей не сможет локально зарегистрироваться на своем компьютере до тех пор, пока администратор не разберется в том, что произошло, и не устранит проблему.

Это только один из примеров проблем, которые могут возникнуть при настройке политик безопасности. Следует понимать, что многие из рассмотренных выше установок ограничений с помощью административных шаблонов не являются настоящими политиками безопасности. Они просто не дают пользователям возможности нарушать работу систем. Настоящая безопасность — в разделе групповой политики Computer ConfigurationWindows SettingsSecurity Settings, где могут устанавливаться ограничения на права пользователей, определяется политика паролей, разрешения на доступ к файлам, реестру, службам и т. д.

Настройки политики безопасности могут порождать проблемы по разным причинам. Допустим, политика безопасности была случайно настроена таким образом, что это повлекло за собой отказ ряда базовых операций. Например, если на сервере или рабочей станции были изменены настройки уровня аутентификации NTLM (что может быть сделано с помощью установки Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options
Network Security: LAN Manager authentication-level). В результате будет получено показанное на экране 2 сообщение об ошибке, а также будет запрещен доступ к сетевым ресурсам для клиентов с более ранними версиями операционных систем (к ним относятся системы Windows 9x без установленного на них клиента службы каталогов, а также системы Windows NT 4.0 с установленным пакетом обновления Service Pack 3 или более ранним). Получаемые при этом сообщения об ошибках никак не отражают суть проблемы, но в то же время отличаются от привычных сообщений, указывающих, например, на неверное имя пользователя или пароль. В статье Microsoft «Client, Service, and Program Incompatibilities That May Occur When You Modify Security Settings and User Rights Assignments» (http://support.microsoft.com/default.aspx?scid=kb;en-us;823659) приведен прекрасный обзор настроек параметров политики безопасности, способных привести к проблемам для различных версий Windows, а также даются рекомендации по выполнению корректных настроек.

В ряде случаев выполнение некоторых настроек политики может привести к тому, что будет заблокирован вход в систему для самого администратора. Рассмотрим пример, когда администратор осуществляет управление локальными группами на рабочих станциях и серверах домена с помощью политики безопасности Restricted Groups. Данная политика часто используется для работы со списками локальной группы «Администраторы» на компьютерах с Windows. Применение политики Restricted Groups может осуществляться двумя способами. В первом случае при выборе варианта Members of this group можно обеспечить членство в локальной группе «Администраторы» только для заданных пользователей и групп, при этом каждый раз, когда компьютер обрабатывает установки групповой политики, все остальные учетные записи из этой группы будут автоматически удаляться. Другой вариант является менее жестким: если используется This group is a member of, это позволяет администратору указать для выбранной группы, членом каких других групп она должна являться. Этот вариант может использоваться, например, в том случае, когда в сети нужно включить в локальную группу «Администраторы» каждой рабочей станции с операционной системой Windows глобальную группу Desktop Admins. Одна из типичных проблем возникает в том случае, когда администраторы используют вариант Members of this group для управления локальными группами «Администраторы», забыв при этом включить в данный список учетную запись локального администратора или группу Domain Admins и, соответственно, блокируя доступ к рабочим станциям для самих себя. Поскольку в результате использования данного параметра происходит полная замена списков членов соответствующих групп, а не дополнение их новыми учетными записями, допустить эту ошибку очень легко.

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

Выявление ненадежных политик

Меня часто спрашивают, можно ли «отключить» групповую политику для пользователя или компьютера и вернуть все установки параметров в состояние по умолчанию. Отмечу, что хотя для конкретного пользователя или компьютера можно отключить обработку GPO, используя для этой цели фильтры безопасности, тем не менее, если до настоящего момента к данному пользователю или компьютеру уже была применена политика, это не приведет к сбросу всех настроек в состояние по умолчанию. Простого пути отключения групповых политик не существует, поэтому каждое изменение, вносимое в групповые политики, должно тщательно тестироваться в пользовательской среде, вне зависимости от того, насколько незначительным оно кажется. Основной подход к решению проблем с компьютерами пользователей, связанных с групповыми политиками, состоит в том, чтобы определить, какие настройки были применены, после чего выделять их одну за другой до тех пор, пока проблема не будет устранена. Данный процесс весьма утомителен и требует значительного времени, и тем не менее существуют средства и техники, позволяющие облегчить выполнение такой работы.

Если вы приступаете к анализу проблем, связанных с групповыми политиками, то первое, что надо сделать, — это запустить на проблемном клиенте отчет Resultant Set of Policy (RSoP). Данный отчет содержит информацию о том, какие именно настройки политики были переданы данному клиенту, что позволит сузить круг рассматриваемых причин возникшей проблемы. Набор используемых программных средств определяется версией операционной системы. Если, например, на клиентском компьютере установлена Windows 2000, следует использовать утилиту командной строки gpresult.exe из комплекта Microsoft Windows 2000 Resource Kit. Здесь необходимо отметить, что система Windows 2000 поддерживает ограниченный набор возможностей RSoP, вследствие чего утилита gpresult.exe не сможет выдать полные результаты по таким категориям, как политики безопасности. Если же мы имеем дело с Windows XP, то в этом случае в нашем распоряжении имеются различные программные средства. Первый и самый простой путь — запустить оснастку rsop.msc, которая имеется в каждой системе Windows XP Professional. С помощью данного средства можно быстро получить отчет RSoP по текущему пользователю в формате, сходном с форматом редактора групповых политик (GPE), как показано на экране 3.

Для того чтобы удаленно создать отчет RSoP по клиенту с Windows XP, можно воспользоваться консолью GPMS (Group Policy Management Console). Имеющийся в GPMS мастер Group Policy Results Wizard генерирует отчет в формате HTML, в котором содержится информация по действующим политикам для пользователя и компьютера, а также указаны объекты GPO, инициировавшие распространение данных политик. Кроме того, в состав систем Windows Server 2003 и Windows XP включена более полная версия утилиты gpresult.exe, с помощью которой можно создавать отчет RSoP из командной строки.

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

Политики, предпочтения и утерянные настройки

Как отмечалось выше, компоненты системы Windows считывают установленные административными шаблонами значения параметров реестра, отвечающие за управление функционированием или блокировку компонентов. Все действующие установки политик сохраняются в четырех подразделах реестра, два из которых относятся к компьютеру и два — к пользователю. Параметры политики, применяемые к компьютеру, хранятся в следующих подразделах реестра:

HKEY_LOCAL_MACHINESoftwarePolicies

HKEY_LOCAL_MACHINESoftwareMicrosoftWindows
CurrentVersionPolicies

Пользовательские параметры политики находятся в подразделах:

HKEY_CURRENT_USERSoftwarePolicies

HKEY_CURRENT_USERSoftwareMicrsoftWindows
CurrentVersionPolicies

Если в любом из этих подразделов реестра имеются данные, касающиеся пользователя или компьютера, тогда к этому пользователю или компьютеру применяется соответствующая политика. За редким исключением все параметры административных шаблонов, поставляемые с современными версиями Windows, имеют возможность работы с политиками и записывают свои данные в один из четырех подразделов реестра.

Microsoft поддерживает возможность создания администратором своих шаблонов (файлов с расширением .adm), что позволяет определять для записи параметров политик подразделы реестра, отличные от перечисленных выше. Шаблоны, разработанные дополнительно, называются предпочтениями (preferences), и с их помощью можно записывать данные в любые разделы реестра. Шаблоны предпочтений могут пригодиться в тех случаях, когда нужно записать в реестр какой-либо параметр, а в стандартной поставке от Microsoft нет необходимого файла .adm (например, в тех случаях, когда необходимо записать данные, не связанные с политиками, или задать настройки Windows, которые нужно разместить в других разделах реестра). В частности, можно создать файл .adm, который активизирует ведение журнала событий по групповой политике на компьютерах с Windows, при этом все параметры реестра, запускающие данный процесс, будут являться предпочтениями. Оборотная сторона использования предпочтений заключается в том, что эти настройки не будут удалены автоматически при отключении применения GPO для данного пользователя или компьютера. Если это происходит, то возникает ситуация, при которой сохраняются старые настройки, что было одной из типичных проблем при работе с системными политиками на Windows NT 4.0 и Win9x.

Необходимо иметь представление о том, как работать с предпочтениями, поскольку именно они вызывают множество трудностей при устранении проблем, связанных с GPO. Поскольку предпочтения нельзя удалить вместе с GPO, нужно быть абсолютно уверенным в том, что, прежде чем будет отменено применение GPO, все настройки предпочтений будут установлены в состояние Not Configured или отключены. Если отменить GPO без предварительного отключения предпочтений, это приведет к ситуации сохранения старых настроек политики.

Файлы .adm используют объекты GPO из тех политик, которые отображаются в GPE в разделах Administrative Templates. Допустим, вы модифицировали какой-либо стандартный .adm файл от Microsoft, для того чтобы с его помощью добавить в реестр необходимые настройки предпочтений. В следующем выпущенном пакете обновлений для Windows разработчики Microsoft обновили этот .adm файл, таким образом, установка пакета привела к потере всех внесенных изменений. А поскольку к данному моменту политика уже была активирована, все эти настройки были сохранены в GPO. Однако вы больше не сможете увидеть эти настройки предпочтений в GPE, равно как и отменить их. Настройки подобного типа называются утерянными. Для того чтобы восстановить возможность управления этими настройками, требуется повторно внести аналогичные изменения в соответствующий .adm-файл. Более предпочтительным подходом в данной ситуации является создание отдельного .adm-файла, описывающего необходимые настройки политики, а не редактирование стандартного файла от Microsoft.

После того как на проблемном клиенте был запущен отчет RsoP, следует идентифицировать те установки параметров групповых политик, которые могли вызывать проблемы. Безусловно, можно выбрать самый легкий путь и просто удалить все GPO для данного пользователя или компьютера, что, возможно, решит проблему, но подобный подход не поможет выяснить, какая именно настройка групповой политики послужила причиной конфликта. К тому же данная методика работает только для политик на базе административных шаблонов, но не для шаблонов предпочтений (по причинам, описанным выше). Данный подход не сработает и по отношению к политикам безопасности, которые могут не менее эффективно перевести систему в состояние сохранения старых настроек, поскольку эти настройки не отменяются при удалении распространившего их GPO. Таким образом, для того чтобы добраться до источника проблемы, нам потребуются другие методики и программные средства.

Программные средства и методики

Если по данным отчета RSoP невозможно сразу же определить, какая настройка политики послужила причиной возникшей проблемы, следует попытаться сузить круг поиска возможных ее причин. В тех случаях когда непонятно, с какой именно категорией политик (политики на базе административных шаблонов или политики безопасности) связана возникшая проблемная ситуация, можно попробовать несколько вариантов дальнейших действий. Следует иметь в виду, что, поскольку ошибки, связанные с применением политик на базе административных шаблонов, в большей степени сбивают с толку, чем ошибки, связанные с применением политик безопасности, первым указателем на возможную причину проблемы может служить характер сообщения об ошибке. Например, если сообщение содержит текст типа Access Denied или Permission Denied, то это довольно явно указывает на связь проблемы с применением политики безопасности, но не политики установки ограничений на компьютеры пользователей, в то время как сообщения об ошибках, подобные приведенному на экране 1, скорее всего, связаны с применением политик на базе административных шаблонов.

Если характер полученного сообщения недостаточно понятен, существует несколько программных средств, способных помочь установить причину неполадок. При исследовании проблем, предположительно связанных с административными шаблонами, моим любимым средством является свободно распространяемая утилита regmon.exe от Sysinternals (http://www.sysinternals.com). В данной утилите можно устанавливать фильтрацию обращений к реестру по его разделам. Таким образом, если при выполнении действий, приводящих к проблемной ситуации, запустить regmon.exe, то можно отследить все обращения к четырем описанным разделам реестра, отвечающим за политики, в результате чего можно выявить параметр политики, порождающий данную проблему. На экране 4 показано, как утилита regmon.exe помогла мне отследить заданное политикой ограничение, запрещающее запуск программы PowerPoint. Приведенный случай, разумеется, является весьма упрощенным (поскольку данную политику можно было бы увидеть и через отчет RSoP, не прибегая к сортировке с помощью regmon.exe), тем не менее на этом примере можно понять идею использования утилиты regmon.exe для отслеживания проблем, связанных с политиками административных шаблонов, в тех случаях, когда отчет RSoP не содержит достаточно информации для идентификации причин проблемы.

Если есть подозрение, что возникшая проблема связана с политикой безопасности, нужно попытаться идентифицировать и отключить данную политику. Как отмечалось выше, применение политики безопасности особенно часто приводит к переходу системы в состояние сохранения старых настроек в тех случаях, когда не были отменены соответствующие настройки перед отключением действующего GPO. Поэтому для исключения подобного рода проблем следует с особой тщательностью выявлять и отменять все специфические настройки безопасности. Если требования норм безопасности, принятых в вашей организации, запрещают отменять политики безопасности в масштабах всего предприятия, следует выделить для тестирования группу из нескольких рабочих станций и попытаться решить проблему на них. Для того чтобы начать анализ проблемы «с чистого листа» (с точки зрения настройки параметров безопасности), лучше всего задействовать файл шаблона безопасности setup security.inf, что позволит привести настройки системы безопасности Windows в соответствие с параметрами по умолчанию, которые имеет операционная система сразу после завершения установки. Во всех системах Windows файл setup security.inf обычно хранится в каталоге %windir%security emplates. Для того чтобы применить данный шаблон, можно использовать утилиту secedit.exe либо импортировать его в локальный объект GPO на компьютере, для чего следует запустить GPE, щелкнуть правой кнопкой на разделе Computer ConfigurationWindowsSettingsSecurity Settings, после чего выбрать пункт Import Policy.

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

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

Проверка, проверка и еще раз проверка

Групповые политики обладают весьма богатыми возможностями. Но если перед применением GPO не будут выполняться тестовые мероприятия, это может привести к ежедневным нарушениям работы.

Следует всегда помнить о том, что перед применением новых настроек групповой политики все внесенные изменения должны быть тщательно протестированы. Если проблемы тем не менее возникли, то такие инструменты, как RSoP от Microsoft и утилита regmon.exe от SysInternals, помогут облегчить процесс устранения неполадок.

Редактор журнала Windows IT Pro (dmarelia@windowsitpro.net)

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

Время на прочтение
6 мин

Количество просмотров 33K

Тема использования PowerShell для администрирования крайне актуальна, и на Хабре появляется все больше и больше статей на эту тему. Предыдущий перевод статьи Джеффри Хикса, который мы опубликовали в прошлую пятницу, вызвал волну интереса. И как тут не вспомнить замечательное выступление того же автора на TechEd North America 2012. Доклад, который Джеффри Хикс проводил вместе с Джереми Московицем (Jeremy Moskowitz), был посвящен анализу объектов групповых политик и формированию отчетов. Оригинальный материал (видео) здесь, мы же приводим крактко содержание + скрипты. В любом случае рекомендуем посмотреть само видео.

В фокусе доклада было два вопроса:

1. Строит отчеты по групповым политикам
2. Проводим анализ групповых политик

Подробности – под катом.

Используем PowerShell в связке с групповыми политиками: что для этого нужно?

Чтобы использовать PowerShell при работе с групповыми политиками, нам необходимы:

• Windows 7 (для запуска PowerShell)
• RSAT для Windows 7
• Собственно сам PowerShell v2.0 или выше
• Опционально: рекомендуется Microsoft Active Directory Provider

Последовательность наших действий:

• Импортируем модуль групповых политик (Import-module GroupPolicy)
• Получаем объект групповых политик с помощью PowerShell (Get a GPO PowerShell Object)
• Строим отчет на основе этого объекта
• Строим HTML/XML-отчеты по объектам групповых политик
• Парсим и осуществляем поиск в XML для целей анализа
• Осуществляем поиск с помощью Select-XML и Xpath

Строим отчеты по групповым политикам

Проблема №1. Необходимо получить информацию о том, что в настоящий момент происходит в групповых политиках

PS C:> Import-Module GroupPolicy
PS C:> Get-GPO JeremyGPO

В данном случае вместо JeremyGPO выступает отображаемое имя (DisplayName) объекта групповых политик. Выводится такая табличка

DisplayName      : JeremyGPO
DomainName       : GLOBOMANTICS.local
Owner            : GLOBOMANTICSDomain Admins
Id               : cd73c562-5bfe-40e2-b81e-28da10da425c
GpoStatus        : ComputerSettingsDisabled
Description      :
CreationTime     : 12/28/2011 2:52:37 PM
ModificationTime : 5/21/2012 11:08:26 AM
UserVersion      : AD Version: 4, SysVol Version: 4
ComputerVersion  : AD Version: 1, SysVol Version: 1
WmiFilter        :

Решение проблемы: создаем отчеты.

Например, перед нами стоит задача получить список всех объектов групповых, которые были изменены за последние 30 дней, отсортированные по убыванию (последние наверху) с тремя значениями (отображаемое имя, время изменения, описание). Полученную информацию необходимо экспортировать в .csv файл (GPOModReport.csv в данном примере). Как это выглядит в PowerShell:

PS C:> get-gpo -all | Where {$_.ModificationTime -gt (Get-Date).AddDays(-30)}

... | Sort ModificationTime -Descending | Where {$_.ModificationTime -ge (Get-Date).AddDays(-30)} | Select Displayname,ModificationTime,Description

... | Export-CSV R:GPOModReport.csv

#Созданные и измененные объекты групповых политик
PS C:>get-gpo -all | Sort CreationTime,Modificationtime | Select Displayname,*Time

#Находим все объекты групповых политик, измененные за последние 30 дней 
PS C:>get-gpo -all | Where {$_.ModificationTime -ge (Get-Date).AddDays(-30)}

#Создаем отчет по отдельному объекту групповых политик (Defaul Domain Policy)
PS C:>Get-GPOReport -name "Default Domain Policy" -ReportType HTML -Path "c:workddp.htm"
invoke-item "c:workddp.htm"

#Создаем отчеты по всем объектам групповых политик
PS C:>Get-GPOReport -All -ReportType HTML -Path "c:workallgpo.htm"
invoke-item "c:workallgpo.htm"

#Создаем для каждого объекта групповых политик свой отчет
#заменяем пробелы на _ в имени GPO
PS C:>Get-GPO -all | foreach { 
 $f="{0}.htm" -f ($_.Displayname).Replace(" ","_")
 $htmfile=Join-Path -Path "C:work" -ChildPath $f
 Get-GPOReport -Name $_.Displayname -ReportType HTML -Path $htmfile
 Get-Item $htmfile 
}

Проблема №2. Слишком много GPO, которые не используются.

Задача: найти пустые GPOs

• Определить объекты групповых политик без настроек
• Ищем XML ExtensionData

PS C:> Import-Module GroupPolicy
PS C:> [xml]$r = Get-GPOReport -Name MyGPO 
-ReportType XML
PS C:> if ((-Not $r.gpo.user.extensiondata) -AND (-not $r.gpo.computer.extensiondata)) {
 "GPO is empty"
 }

#requires -version 2.0

#find empty gpos in the domain

Function Get-EmptyGPO {

Param (
[Parameter(Position=0,ValueFromPipeline=$True,
ValueFromPipelinebyPropertyName=$True)]
[string]$DisplayName
)

Begin {
#import the GroupPolicy Module
Import-Module GroupPolicy

}

Process {
#create an XML report
[xml]$report=Get-GPOReport -Name $displayname -ReportType XML

 #totally empty
 if ((-Not $report.gpo.user.extensiondata) -AND (-not $report.gpo.computer.extensiondata)) {
    #no extension data so write
    Get-GPO -Name $Displayname
}

} #process

End {}

} #function

Function Test-EmptyGPO {

Param (
[Parameter(Position=0,ValueFromPipeline=$True,
ValueFromPipelinebyPropertyName=$True)]
[string]$DisplayName
)

Begin {
#import the GroupPolicy Module
Import-Module GroupPolicy

}

Process {

    #set default values
    $User=$False
    $Computer=$False
    #create an XML report
    [xml]$report=Get-GPOReport -Name $displayname -ReportType XML

    if ($report.gpo.user.extensiondata) {
     $User=$True
    }
    If ( $report.gpo.computer.extensiondata) {
     $Computer=$True
    }
    #write a custom object to the pipeline
    New-Object -TypeName PSObject -Property @{
    Displayname=$report.gpo.name
    UserData=$User
    ComputerData=$Computer
    }

} #Process

End {}

} #function

#Get-GPO -All | Get-EmptyGPO
#Get-GPO -All | Test-EmptyGPO

Проблема №3.
Кто обращался к объекту групповой политики?
Имеются ли GPO, в которых половина политики деактивирована (“Are there any GPOs with ‘half’ the policy disabled?”)
Имеются ли GPO, в которых все политики деактивированы (“Are there any GPOs with ‘all’ the policy disabled?”)

Применяем фильтр по статусу GPO (GPOStatus). Каждому из трех вопросов выше соответствуют три команды:

PS C:> get-gpo -all | Sort GPOStatus | format-table -GroupBy GPOStatus Displayname,*Time
PS C:> get-gpo -all | where {$_.GPOStatus -match "disabled"} | Select GPOStatus,Displayname
PS C:> get-gpo -all | where {$_.GPOStatus -match "AllSettingsDisabled"}

Анализируем объекты групповых политик

Проблема №4. Обнаруживаем GPO без связей

PS C:> Import-Module ActiveDirectory
Get-ADOrganizationalUnit -filter * | select-object
-ExpandProperty DistinguishedName | get-adobject 
-prop gplink | where {$_.gplink} | Select-object 
-expand gplink | foreach-object { 
foreach ($item in ($_.Split("]["))) {
$links+=$regex.match($item).Value
   } 
} 
Get-GPO -All | Where {$links -notcontains $_.id}

#requires -version 2.0

<#
 Find unlinked GPOs. This requires the Active Directory Module
 This version does not query for site links
 #>

Import-Module ActiveDirectory,GroupPolicy

#GUID regular expression pattern
[Regex]$RegEx = "(([0-9a-fA-F]){8}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){12})"

#create an array of distinguishednames
$dn=@()
$dn+=Get-ADDomain | select -ExpandProperty DistinguishedName
$dn+=Get-ADOrganizationalUnit -filter * | select -ExpandProperty DistinguishedName

$links=@()

#get domain and OU links
    
foreach ($container in $dn) {

    #pull the GUID and add it to the array of links

    get-adobject -identity $container -prop gplink | 
    where {$_.gplink} | Select -expand gplink | foreach {
      
      #there might be multiple GPO links so split 
            
      foreach ($item in ($_.Split("]["))) {
        $links+=$regex.match($item).Value
      } #foreach item
    } #foreach
} #foreach container

#$links

<#
 get all gpos where the ID doesn't belong to the array
 write the GPO to the pipeline
#>

Get-GPO -All | Where {$links -notcontains $_.id} 

Проблема 5. Объекты групповых политик с излишними настройками в реестре (“Extra Registry Settings”)

Находим излишние настройки в реестре

#Use Xpath with the XML report data
PS C:> [xml]$report = Get-GPOReport -Name MyGPO 
-ReportType XML
PS C:> $ns = @{q3 = "http://www.microsoft.com/GroupPolicy/Settings/Registry"}
PS C:> $nodes = Select-Xml -Xml $report -Namespace $ns -XPath "//q3:RegistrySetting" | select -expand Node | Where {$_.AdmSetting -eq 'false'}

#requires -version 2.0

#find GPOs with extra registry, ie non-ADM settings

Function Test-GPOExtraRegistry {

Param (
[Parameter(Position=0,ValueFromPipeline=$True,
ValueFromPipelinebyPropertyName=$True)]
[string]$DisplayName
)

Begin {
    #import the GroupPolicy Module
    Import-Module GroupPolicy
}

Process {
#create an XML report
[xml]$report=Get-GPOReport -Name $displayname -ReportType XML
#define the XML namespace
$ns=@{q3="http://www.microsoft.com/GroupPolicy/Settings/Registry"}
$nodes=Select-Xml -Xml $report -Namespace $ns -XPath "//q3:RegistrySetting" | 
select -expand Node | Where {$_.AdmSetting -eq 'false'}

if ($nodes) {
  #extra settings were found so get the GPO and write it to the pipeline
  Get-GPO -Name $Displayname
}

}

End {}

} #function

#Import-Module GroupPolicy
#Get-GPO -all | Test-GPOExtraRegistry 

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

Бонусы:

• Ссылка на скрипты
• Слайды
• Бесплатная книга по Group Policy + PowerShell от одного из авторов доклада [ENG] (необходимо заполнить форму)

Также для построения отчетов по групповым политикам вы можете воспользоваться нашей программой NetWrix Group Policy Change Reporter.

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

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

Распространенные проблемы в работе объектов групповых политик и соответствующие решения

Для более точной диагностики объектов групповых политик обратите внимание на программа FAZAM 2000.