Управление групповой политикой Windows Vista (часть 3)

Опубликовано: 11 Апреля, 2023

Введение

Windows Vista включает некоторые важные изменения по сравнению с более ранними операционными системами Windows в отношении групповой политики ( GP ). В этой статье рассказывается о том, как неожиданно стало намного проще устранять неполадки с помощью нового средства просмотра событий, как повысилась стабильность приложения политик за счет выделения обработки GP в отдельную службу и почему Network Location Awareness ( NLA ) — это такая замечательная вещь.

Добро пожаловать в постоянно расширяющуюся вселенную Microsoft Group Policy.

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

Если вы когда-либо пробовали устранять неполадки при обработке групповой политики на компьютере с Windows 2000, XP или 2003, вы, вероятно, скажете, что у вас были трудности с поиском сообщений об ошибках, анализом событий и т. д., которые в конечном итоге помогли вам понять, что происходит. Дело в том, что в этих операционных системах сообщения об ошибках можно было найти в средстве просмотра событий и в нескольких других файлах, особенно в файле Userenv.log (находится в каталоге %WINDIR%DebugUsermode ), но этот файл содержит информацию и ведение журнала из нескольких разных процессов, таких как загрузка и выгрузка профиля пользователя и т. д., потому что мы полагались на ведение журнала трассировки, найденное в «userenv.dll». Дополнительные сведения см. в статьях Microsoft Technet «Устранение неполадок групповой политики с помощью файлов журнала» и «Интерпретация файлов журнала Userenv». Скажем так, администратору или службе поддержки не всегда было легко со всеми загадочными сообщениями об ошибках и различными местами, которые ему приходилось искать.

С Windows Vista процесс устранения неполадок стал намного проще! Теперь существует только два журнала для групповой политики в Windows Vista, и к обоим можно получить доступ с помощью нового и улучшенного средства просмотра событий (и API ведения журналов) под кодовым названием « Crimson » (рис. 1)!

Изображение 25229
фигура 1

Этот новый «интерфейс» для управления событиями представляет собой объединенный интерфейс для устранения неполадок и создания отчетов, основанный на Microsoft Management Console ( MMC ) версии 3. Журналирование основано на XML, поддерживает «Каналы приложений», подписки — и теперь вы можете связать «Действия»/ Задачи к событиям (отправить электронное письмо, выполнить скрипт и т. д.).

Доступ к средству просмотра событий по-прежнему можно получить через «Панель управленияАдминистрирование», открыв «Управление компьютером» и введя команду « EVENTVWR » в командной строке или диалоговом окне «Выполнить».

Если щелкнуть событие правой кнопкой мыши (см. рис. 1) и выбрать «Свойства события» или просто дважды щелкнуть событие, событие откроется, как показано на рис. 2. Это немного похоже на предыдущие версии средства просмотра событий, но обратите внимание на подробности. вкладка

Изображение 25230
фигура 2

Вкладка Details содержит всю информацию о событии в мельчайших подробностях. У вас есть два разных представления этих сведений — дружественное представление (рис. 3) и XML-представление (рис. 4). Последний показывает событие таким, какое оно есть на самом деле — XML, как и все остальное в наши дни. Итак, почему именно XML, спросите вы? Что ж, простой ответ — гибкость, поскольку вы можете без особых проблем импортировать/экспортировать эти события в любую систему или базу данных.

Изображение 25231
Рисунок 3

Изображение 25232
Рисунок 4

Теперь у нас есть два типа событий: административные и операционные события:

Административные события — это обычные события, какими мы их знаем, с некоторыми изменениями. Как вы, возможно, помните, источником событий приложения GP был очень общий « Userenv », и эти события были расположены в журнале событий приложения. В Vista источником событий теперь является « GroupPolicy », он перемещен в системный журнал и работает только с GP, что делает фильтрацию намного более точной (у вас не будет сочетания выгрузки реестра/профиля и событий, связанных с GP).

Говоря о фильтрации… Фильтрация событий также основана на XML и может быть сохранена в виде пользовательских представлений (см. рис. 5).

Изображение 25233
Рисунок 5

Каждое событие («Информация», «Предупреждение» или «Ошибка») теперь должно содержать соответствующую ссылку на статьи базы знаний ( KB ) на веб-сайте Microsoft — а так как все написано с нуля, информационный уровень должен быть лучше, чем раньше — покажет время (эта статья написан на основе бета-версий Vista). События «GroupPolicy» в основном будут состоять из основных сообщений о событиях, сообщающих об успешной или неудачной обработке GP.

Операционные события можно найти в средстве просмотра событий в разделе « Журналы приложений и служб » > Microsoft > Windows > GroupPolicy — щелкните журнал «Операция» (см. рис. 6).

Изображение 25234
Рисунок 6

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

Теперь это намного проще, чем в системах Windows нижнего уровня, и вам не нужно открывать какие-либо текстовые журналы в Блокноте или любом другом инструменте, который вы могли использовать для диагностики проблем обработки GP. Другими словами, это очень «удобная для администратора» замена Userenv.log!

Стабильность

С Windows Vista мы получаем повышенную стабильность и более надежное приложение и обработку GP. Служба защищена за счет изоляции сторонних расширений на стороне клиента ( CSE ), требующих повышенных привилегий для остановки службы (даже локальные администраторы не могут остановить службу по умолчанию), а конфигурация перезапуска службы обеспечивает восстановление в случае непредвиденных сбоев. Все это будет на 100% прозрачно для пользователя.

Обработка GP в Windows Vista теперь выполняется на узле общей службы ( SVCHOST ) и больше не является просто частью процесса Winlogon — новая служба называется « Клиент групповой политики » (или GPSVC ). Эта специальная служба теперь отвечает за применение параметров, настроенных администраторами для компьютера и пользователей.

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

Осведомленность о сетевом расположении

Надежность сети была серьезной проблемой для Windows 2000/XP/2003. Без очень стабильной политики сетевой среды обработка стала работать несколько хуже. В сценариях с клиентскими VPN-подключениями, изменением сетевого подключения или плохой пропускной способностью/задержкой дела обстояли не всегда хорошо. Вам должно было повезти, чтобы политики применялись правильно в таких ситуациях — то же самое с ноутбуками, выходящими из режима гибернации или ожидания — очень часто перезагрузка или выход из системы были единственным решением, если политики применялись правильно.

До появления Vista политики применялись к клиентам только при запуске машины (параметры компьютера), при входе пользователя в систему (параметры пользователя) и каждые 90 минут, плюс смещение до 30 минут, также известное как интервал фонового обновления (который можно изменить в значение по умолчанию).

Еще одна проблема заключалась в том, что обнаружение медленного соединения ( SLD ) основывалось на протоколе управляющих сообщений Интернета ( ICMP ), поэтому запросы PING/ECHO отправлялись для определения состояния сети между клиентом и контроллером домена ( DC ). Когда администраторы отключали/фильтровали протокол ICMP в маршрутизаторах или брандмауэрах, часто из соображений безопасности, политики никогда не применялись, поскольку SLD определял скорость сети ниже 500 Кбит/с (значение по умолчанию).

Решением всех этих проблем является Network Location Awareness ( NLA) версии 2.0. NLA встроен в операционную систему и постоянно отслеживает состояние сети и обеспечивает реагирование на изменения в сети и доступность ресурсов (подписывается на уведомление о доступности DC).

NLA, среди прочего, знает о наличии контроллеров домена, и если предыдущий цикл применения политики был пропущен или завершился неудачей, Vista повторит попытку обработки GP, когда контроллер домена будет доступен. Усовершенствованный механизм GP даже инициирует фоновое обновление через VPN-подключение, обновляя политику компьютера и пользователя. Таким образом, больше нет необходимости перезагружаться или выходить из системы и снова входить в нее перед подключением к корпоративной сети через VPN-подключение.

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

NLA также может определить, отключен или отключен адаптер, что позволяет GP сократить время ожидания для сценариев, в которых сеть недоступна — это поможет Windows Vista загружаться/запускаться быстрее!
Использование NLA повышает уровень безопасности компьютеров за счет более быстрого и надежного применения изменений GP, особенно мобильных пользователей, число которых, кстати, постоянно растет, теперь обрабатываются более безопасным и эффективным способом.

Нет необходимости полагаться на протокол ICMP с новым определением пропускной способности/подключения NLA, поэтому нет никаких сомнений в том, что NLA улучшит применение и обработку политик. Однако для сетей сетевого карантина ( NAC/NAQ ) требуется дополнительная настройка.

Что принесет будущее?

Microsoft уже предоставила некоторую информацию о том, что они ожидают включить в будущие операционные системы и/или пакеты обновлений (такие как Windows Vista Service Pack 1 и Windows Longhorn Server). Одной из замечательных возможностей, которые они предоставят, является возможность оставлять комментарии к GPO и настройкам GPO; это может быть очень полезно для документирования и управления изменениями.

Еще одна замечательная вещь, которую мы, скорее всего, получим, — это возможности поиска (конкретные ключевые слова) и параметры фильтрации (например, «управляемые», «комментарированные», «настроенные», «требования к ОС» и т. д.). Таким образом, примерно через несколько месяцев мы сможем выполнять поиск в файлах ADMX, загруженных в редактор объектов групповой политики ( GPOE ). Если вы когда-либо пытались найти конкретную политику, вы, вероятно, согласитесь, что это может быть сложно, поскольку в Vista/Longhorn имеется более 800 политик (на самом раннем этапе, еще до того, как они были запущены), возможности поиска станут жизненно важными в ближайшее время.

«Шаблоны руководств» будут поддерживаться консолью управления групповыми политиками ( GPMC ). Эти шаблоны будут включать рекомендуемые параметры политики и значения (известные как «лучшие методы»), и затем мы можем создавать новые объекты групповой политики на основе шаблонов, а также настраивать наши собственные шаблоны.

Было бы неплохо иметь автономный инструмент с графическим интерфейсом для редактирования файлов ADMX и ADML (см. первую статью). Microsoft еще не обещала такой инструмент, но если они его не создадут, я уверен, что это сделают другие. Формат XML является хорошим стандартом, но чтобы по-настоящему насладиться его плодами и гибкостью, было бы неплохо использовать «интеллектуальный» (поддерживающий схему ADMX) редактор.

Вывод

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

В этой части, третьей (последней) из этой серии статей, «Управление групповой политикой Windows Vista», были рассмотрены основные способы устранения неполадок, повышенная стабильность и осведомленность о сетевом расположении.

В первой части из трех статей мы рассказали о различиях между файлами ADM и ADMX/ADML и о том, что такое центральное хранилище.

Во второй части этой серии статей мы рассмотрели наличие нескольких объектов локальной групповой политики.

Ссылки по теме

Групповая политика на Microsoft.com

Вики групповой политики

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

Чат по групповой политике Windows Vista (28 сентября 2006 г.) с Марком Уильямсом, Джудит Херман, Дэвидом Пауэром, Майком Стивенсом и Джеффом Кларком

Управление групповой политикой с помощью чата Windows Vista (1 июня 2006 г.) с Джудит Херман, Рахулом Гуптой, Марком Уильямсом и Марком Лоуренсом