Должен сказать, что консультированию клиентов по проблемам, связанным с групповыми политиками, я посвятил довольно много времени. Я занимаюсь этим уже более восьми лет, и у меня нет ни малейших сомнений в том, что за прошедшее время самым заметным усовершенствованием в управлении групповыми политиками стала реализация в системах Windows Server 2003 и Windows XP функции Resultant Set of Policies (RSoP). Данная функция помогает нам прояснить, какая же, собственно, политика выполняется на наших настольных системах и серверах. Разобравшись с тем, что такое RSoP и как следует интерпретировать представляемые этой оснасткой данные, касающиеся пользователя или компьютера, можно научиться эффективно подбирать и настраивать групповые политики для своей среды. Разумеется, RSoP нельзя назвать универсальным решением всех проблем, связанных с групповыми политиками, но, во всяком случае, эта оснастка может указать направление для дальнейших действий.
Что такое RSoP?
Прежде всего, необходимо усвоить, что реализованная в системе Windows функция RSoP — это технология, интегрированная корпорацией Microsoft в Windows Management Instrumentation (WMI), начиная с версии Windows XP. RSoP несовместима с Windows 2000, поскольку инфраструктура WMI и процессор групповых политик последней не включают в себя необходимые компоненты, которые должны собирать данные для RSoP. Хотя в комплект Windows 2000 Resource Kit входит утилита командной строки gpresult.exe, которая позволяет получать часть данных, отображаемых функцией RSoP. Однако эта первоначальная версия Gpresult не дает столь полной картины обработки политик, как появившаяся позднее функция RSoP.
Когда вышла система Windows XP и более поздние ее версии, специалисты Microsoft разработали два инструмента для обращения к инфраструктуре RSoP на базе WMI. Оснастка Policy Management Console (GPMC) консоли Microsoft Management Console (MMC) оснащена графическим пользовательским интерфейсом для обращения к данным RSoP, а средство Gpresult интегрировано в операционную систему. Не путайте обладающую функциями RSoP версию Gpresult с более ранней версией комплекта Windows 2000 Resource Kit. В двух названных инструментах используются совершенно разные механизмы, так что они могут возвращать неидентичные данные; при этом надо иметь в виду, что версия с функциями RSoP предоставляет более точную информацию.
Так что же такое RSoP? В сущности, это механизм, определяющий, каковы фактические настройки групповых политик для данного компьютера или пользователя службы Active Directory (AD). Дело в том, что в типичной среде AD пользователь или компьютер могут обрабатывать множество объектов групповых политик (GPO), причем возможно, что настройки одних GPO будут отменять настройки других. Объекты GPO обрабатываются в определенном порядке; этот порядок влияет на то, какие именно настройки политик фактически применяются к данному пользователю или компьютеру. Отметим также, что GPO можно подвергать фильтрации с помощью групп безопасности и фильтров WMI. Определить, какие настройки политик фактически применяются к данному пользователю или компьютеру, можно только с учетом всех этих факторов. Неудивительно поэтому, что решить такую задачу порой бывает непросто, особенно в условиях крупной организации. Оснастка RSoP помогает выяснить, что именно происходит с настройками групповых политик.
RSoP Planning или RSoP Logging
В системах Windows Server 2008, Windows Vista, Windows Server 2003 и Windows XP функция RSoP реализована в двух версиях. Первая и, вне всякого сомнения, самая распространенная, известна как RSoP Results Logging или Group Policy Results Logging. Group Policy Results — это название RSoP, используемое чаще других. Функция Group Policy Results Logging, как явствует из ее названия (которое можно перевести как «регистрация результатов групповых политик»), демонстрирует, какие политики были применены к данному компьютеру Windows или пользователю. Она отвечает на вопрос о том, какие настройки политик были обработаны данным компьютером или пользователем в ходе последнего цикла обработки политик. Регистрация осуществляется с помощью процессора групповых политик и всех клиентских модулей Client Side Extension (CSE), которые обрабатывают различные настройки политик для направляемого в инструментарий WMI отчета о том, что конкретно было сделано в ходе обработки групповой политики. При запуске отчета Group Policy Results Logging, показанного на экране 1, или при использовании утилиты Gpresult на системе Windows XP либо Windows Vista пользователь, в сущности, подключается к выбранной им системе — локальной или удаленной — и собирает данные регистрации WMI в отчет.
Вторая версия RSoP — RSoP Planning (известная также как Group Policy Modeling в GPMC) — отвечает на вопрос о том, какую политику следует применять к данному компьютеру или пользователю во время следующего цикла обработки политик. Средство RSoP Planning, как явствует из его названия, позволяет выполнять для политики, которую получит данный компьютер или пользователь, расчеты типа «что, если…». В результате теперь администратор имеет возможность манипулировать изменениями, которые могут быть применены к пользователям или компьютерам, и получать представление о том, как упомянутые изменения будут влиять на реальную политику пользователей или компьютеров.
К примеру, администратор может виртуальным образом переместить пользователя или компьютер в новую организационную единицу (Organizational Unit, OU) или в новую группу безопасности и посмотреть, каким образом это действие отразится на реальной политике. Кроме того, администратор может смоделировать ситуацию применения той или иной политики, если вдруг обнаружится медленное сетевое соединение или будет иметь место циклическое применение политики. Все эти «модификации», выполняемые администратором в ходе фазы моделирования, влияют на то, какие настройки политики получает компьютер или пользователь, и реализованная в GPMC функция Group Policy Modeling позволяет с легкостью моделировать эти изменения. Group Policy Modeling (в отличие от Group Policy Results) не предполагает направления целевому компьютеру запроса для получения сведений о том, что произойдет. С другой стороны, для функционирования Group Policy Modeling необходим доступ к контроллеру домена (Domain Controller, DC) Windows Server 2003 или Windows Server 2008. Мало того, если в сети имеются контроллеры доменов только Windows 2000, при запуске GPMC вы просто не увидите узел Group Policy Modeling, поскольку средства моделирования используют службу Resultant Set of Policy Provider, которая выполняется только на более современных контроллерах доменов. А без этой службы средства моделирования не функционируют.
Использование RSoP Logging
Теперь, когда мы получили некоторое представление о функции RSoP, давайте посмотрим, как можно с ее помощью разобраться в настройках групповых политик. На мой взгляд, работать с реализованной в GPMC функцией Group Policy Results Logging проще, чем с утилитой командной строки Gpresult, поэтому начнем с графической версии.
Но перед тем как мы углубимся в детали, надо сделать одно замечание. Если работа ведется в неоднородной среде, куда входят Server 2008, Windows Vista, Server 2003 и/или Windows XP, нужно следовать проверенному практикой правилу: выполнять Group Policy Results на той системе, где установлена та же (или более новая) версия операционной системы, что и на компьютере, результаты которого мы проверяем. К примеру, чтобы задействовать функцию Group Policy Results для проверки политик на системе Windows Vista, следует выполнять эту функцию на компьютере Windows Vista, а не на системе Windows XP. Так можно будет получить более полный набор результатов.
Здесь важно помнить еще об одном обстоятельстве. Необходимо иметь возможность обращаться к компьютеру, данные по которому вы собираете, со своей управляющей станции. Это означает, что компьютер должен функционировать нормально, а брандмауэр не должен блокировать доступ к его портам и протоколам, необходимым для выполнения функции Group Policy Results. Поскольку для обращения к этим данным Group Policy Results использует удаленные вызовы WMI, администратору обычно приходится принимать меры, чтобы удаленная система допускала применение протокола DCOM. Этот протокол использует порт TCP 135 для первоначальной настройки и произвольные порты с номерами более 1024 для последующего обмена данными. Если целевая система защищена брандмауэром Windows Firewall, разблокирование требуемых портов проще всего проводить с помощью настроек Remote Administration Exception. Если используются системы Windows XP и Server 2003, для обращения к этому средству в консоли GPMC следует выбрать узлы Computer ConfigurationAdministrative Templates NetworkNetwork ConnectionsWindows FirewallStandard (или Domain) ProfileWindows Firewall: Allow Remote Administration Exception. Если же системы работают под управлением операционных систем Windows Vista и Server 2008, нужно выбрать узлы Computer ConfigurationWindows SettingsSecurity Settings Windows Firewall with Advanced Security Inbound Rules и перейти в раздел Predefined Rules.
Ну что ж, за работу. Допустим, нам нужно убедиться в том, что некая рабочая станция получила те или иные настройки политики. Запустим консоль GPMC, правой кнопкой мыши щелкнем на узле Group Policy Results и выберем пункт Group Policy Results Wizard. На первом экране мастера требуется выделить удаленный или локальный компьютер, к которому мы будем подключаться. Если необходимо получить только настройки, применяемые к пользователям, следует установить соответствующий флажок, и тогда в дальнейшем из подготовленного системой отчета будут исключены все настройки, применяемые к компьютерам.
Выбрав целевой компьютер, переходим на следующий экран мастера; здесь можно выбрать пользователя, зарегистрировавшегося на интересующем нас компьютере, если требуется восстановить применяемые к пользователям параметры групповых политик в дополнение к параметрам, применяемым к компьютерам. Пользовательский интерфейс мастера Group Policy Results отобразит учетные записи только тех пользователей, которые зарегистрировались в удаленной системе и сгенерировали данные RSoP. Если в списке не окажется того или иного пользователя, это значит, что он, по всей вероятности, не регистрировался в данной системе. После выбора пользователя мастер Group Policy Results собирает данные WMI по выделенному компьютеру и отображает их на правой панели результатов консоли GPMC, как показано на экране 1.
Интерпретация результатов
Итак, мы провели сеанс работы с мастером Group Policy Results и получили результаты. Пора приступать к их интерпретации. На правой панели результатов имеется три вкладки: Summary, Settings и Policy Events. В таблице описывается назначение каждой из этих вкладок.
Пожалуй, если говорить о том, что именно происходит с групповыми политиками на удаленной системе, самая интересная из вкладок — вкладка Summary, поэтому давайте рассмотрим ее более подробно. На экране 2 показана раскрытая вкладка Summary со всеми ее разделами. Допустим, вы решили отобразить настройки групповых политик как для компьютеров, так и для пользователей. В этом случае сводные данные будут распределены по двум разделам: данным о конфигурации компьютера Computer Configuration Summary и данным о конфигурации пользователя User Configuration Summary. В каждом из этих разделов имеется пять подразделов, в которых содержатся подробные сведения о том, какие политики были обработаны. Самые интересные подразделы — объекты групповых политик Group Policy Objects и состояние компонентов Component Status.
Подраздел Group Policy Objects, в свою очередь, разделяется на подразделы примененных объектов групповых политик Applied GPOs и отброшенных объектов групповых политик Denied GPOs. В первом перечисляются объекты групповых политик, обработанные компьютером или пользователем, а также указывается, с каким контейнером AD были связаны эти объекты, а также приводятся их номера версий AD и SYSVOL. Эти сведения важны, поскольку они дают возможность администратору удостовериться, что тот или иной объект GPO, который, по мнению администратора, должен быть обработан компьютером или пользователем, в действительности обрабатывается. Номера версий важны потому, что они всегда должны быть постоянными для данного объекта. Если номера версий AD и SYSVOL не идентичны, может быть нарушено согласование обрабатываемого объекта GPO с соответствующим объектом на контроллере домена, который компьютер использует при обработке политики. А это может свидетельствовать о проблеме репликации (или просто о том, что вы инициировали обработку результатов применения групповых политик, не выделив достаточного времени для того, чтобы изменения в GPO были реплицированы на данном контроллере домена).
Не меньший интерес представляет и раздел Denied GPOs; он дает точное представление о том, почему тот или иной объект групповой политики не был обработан (хотя этот объект, возможно, связан с контейнером AD, который сдержит данные по компьютеру или пользователю). К числу самых типичных причин, по которым объекты GPO отбрасываются — или, точнее сказать, не обрабатываются, — можно отнести следующие: фильтры WMI, препятствующие обработке объектов, отключение ссылки или то обстоятельство, что объект пуст (т. е. не содержит настроек). В разделе Denied GPOs можно почерпнуть ценные сведения о том, как применяются политики, а также выяснить, где расположены «мертвые» объекты GPO, которые пытаются, но не могут обработать компьютеры или пользователи.
Весьма любопытен и раздел Component Status. В нем отображается та часть отчета, где речь идет о том, произошла ли на самом деле обработка групповых политик для данного компьютера или пользователя. Этот раздел отчета подразделяется на части по числу этапов цикла обработки групповой политики. Компонент Group Policy Infrastructure представляет ту фазу обработки групповых политик, которая именуется базовой. Во время этой фазы учетная запись компьютера или пользователя считывает список объектов GPO, которые она должна обработать, определяет, к каким из них она имеет доступ, и создает список клиентских модулей (CSE), которые должны обрабатывать настройки политик в этих объектах. Если эта часть цикла обработки заканчивается неудачей, не будут успешно завершены и остальные фазы цикла.
Последующие компоненты в списке — это разнообразные клиентские модули, выполнявшиеся для компьютера или пользователя в течение последнего цикла обработки. К ним относятся различные аспекты политики, такие как Registry, Security и Software Installation. Отчет показывает, был ли успешно выполнен каждый из элементов списка, а если нет — он часто отображает соответствующую информацию об ошибке. На экране 2 элемент Software Installation обозначен как ожидающий выполнения, Pending. Дело здесь вот в чем. Для выполнения клиентского модуля установки программного обеспечения необходимо, чтобы произошло первоочередное событие обработки — например, перезагрузка системы или регистрация в системе пользователя, — поэтому до тех пор, пока компонент не дал сбой, считается, что он еще не запускался. Отмечу также, что в разделе Component Status реализована визуальная подсказка — символ X красного цвета для завершившихся сбоем событий и желтый восклицательный знак, предупреждающий о таких ситуациях, как ожидание выполнения модулем установки программного обеспечения.
Показанная на экране 3 вкладка Settings отчета Group Policy Results представляет срез настроек реальных политик, которые были применены к компьютеру или пользователю, а также имена объектов GPO, через которые были переданы эти настройки. В отчете на экране 3 показаны детали некоторых настроек Administrative Template Windows Firewall, которые были обработаны клиентом. Для административных шаблонов отчет содержит объяснительный текст по той или иной политике; в нем разъясняется назначение этой политики. Отмечу, кстати, что в системах Vista и Server 2008 этот отчет извещает пользователя о том, что описания политик административных шаблонов получены из центрального хранилища, расположенного на сервере каталога файловой системы, где можно хранить файлы ADMX и ADML.
Перейдя на вкладку Events отчета Group Policy Results, мы видим список связанных с групповыми политиками событий, произошедших на удаленной системе. Они напоминают события, регистрируемые программой Windows Event Viewer, что неудивительно, поскольку в обоих случаях используется одна и та же технология. Часто наиболее интересными следует считать события с ошибками или предупреждениями, однако, на мой взгляд, от них не так уж много пользы: событий регистрируется множество, а подробных сведений о них отображается недостаточно. Впрочем, с этими сообщениями все же стоит ознакомиться, когда у вас возникают проблемы из-за невозможности получить те или иные важные данные.
Чтобы сохранить информацию с вкладок Summary или Settings, нужно щелкнуть правой кнопкой мыши в области интересующей нас вкладки и в раскрывшемся меню выбрать пункт Save Report. Отчет будет передан в файл HTML или XML. Форматом XML стоит пользоваться лишь в тех случаях, когда планируется применить необработанные данные для достижения какой-либо иной цели в другой программе.
Можно просмотреть пятиминутный демо-ролик о том, как работать с мастером Group Policy Results и просматривать выходные данные. Ролик размещается в Internet по адресу wms18.streamhoster.com/pentonmedia/windows/winscreencasts/RSOPMarElia.wmv.
Внутренние механизмы
GPMC и Gpresult скрывают от пользователя сложные внутренние механизмы, с помощью которых данные RSoP собираются системой WMI, но если вы знакомы с WMI и знаете, как составлять запросы к содержимому инструментария, то сможете напрямую обращаться к данным WMI, которые лежат в основе отчетов RSoP. Данные RSoP хранятся в особом пространстве имен, выделенном внутри WMI специально для этой цели. Возможно, некоторые знакомы с составлением запросов к данным, хранящимся в пространстве имен rootCIMv2. Так вот, данные RSoP хранятся в пространстве имен rootRSOP. Эти данные распределяются по целому ряду классов, каждый из которых представляет различные области политик (такие как реестр, перенаправление папок и безопасность). На экране 4 показано, каким видится это пространство имен пользователю средства просмотра WMI, именуемого WMIX (это средство можно загрузить в Internet по адресу www.pjtec.com/WMIX).
На экране изображен ряд контейнеров в пространстве имен RSoP. Контейнеры, начинающиеся с символов NS, за которыми следует группа буквенно-цифровых символов, именуются сеансами RSoP (RSoP Sessions). Они показывают, как я запускал с удаленного компьютера отчеты по этой системе, именуемой XP3. На экране 4 я добрался до одного из упомянутых сеансов. Здесь показан ряд классов WMI. Они представляют различные области политик, которые, как правило, находят отражение в отчетах RSoP. Если бы я просматривал экземпляры этих классов, то увидел бы необработанные данные по настройкам групповых политик, возвращенные консолью GPMC.
Данные RSoP представляют собой мощный механизм, позволяющий судить о том, как групповые политики влияют на работу удаленных систем Windows. С помощью GPMC или Gpresult администратор может как моделировать поведение групповой политики в случае применения ее к данному пользователю или компьютеру, так и получать представление о том, что произошло на самом деле. При этом можно не только увидеть фактические параметры, подвергшиеся обработке, но и уточнить, не возникали ли в процессе обработки ошибки, из-за которых параметры не были переданы. Разработчики этого важного инструментального средства многое сделали для того, чтобы групповые политики надежно выполняли свою задачу — защищать наши системы и ограждать их от посягательств со стороны лиц, не имеющих прав доступа.
Даррен Мар-Элиа (dmarelia@windowsitpro.net) — редактор журнала Windows IT Pro