 TechNet Magazine January 2008

TechNet Magazine January 2008

Системный центр: Технология Real Control в применении к Virtual Machine Manager 2007

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

Edwin Yuen Системный центр: Создание усовершенствованных архивов с помощью Data Protection Manager 2007

Последняя версия диспетчера защиты данных, предлагая много новых возможностей, является мощным и гибким решением задачи управления архивами. В данной статье дается обзор возможностей DPM по защите разнообразных данных — от узлов Exchange и SQL Server до узлов филиалов компании и SharePoint.

Calvin Keaton Системный центр: Интерактивные службы позволяют упростить инвентаризацию программного обеспечения

Управление лицензиями – важная задача для любого предприятия независимо от размера. Но при количестве программного обеспечения, приобретаемого и развертываемого сегодня предприятиями, управление этими активами кажется практически невозможным. Узнайте, как новая служба Asset Inventory Service корпорации Майкрософт может помочь в решении этой проблемы.

Paul Bourgeau Групповая политика: Шаблоны ADM и ADMX для групповой политики

Файлы ADM использовать сложно, но делать это приходится. Нельзя допускать снижения эффективности групповой политики. Руководство, представленное в статье, поможет вам разобраться в тонкостях работы файлов ADM и нового формата ADMX. В статье рассказывается о том, какие средства понадобятся для работы с ними, и приводятся рекомендации по их применению.

Jeremy Moskowitz Групповая политика: Оптимизация производительности групповых политик

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

Darren Mar-Elia Групповая политика: Углубленное рассмотрение расширенного управления групповыми политиками

AGPM, или расширенное управление групповыми политиками, является удобным средством, предоставляющим уникальные методы работы с объектами групповой политики. И теперь оно доступно участникам программы Microsoft Software Assurance. Узнайте о способах использования AGPM для автономного внесения изменений в объекты GPO, делегирования административных полномочий, отслеживания изменений и многого другого.

Derek Melber От редактора: Завоевать доверие скептика

Joshua Hoffman Письма в редакцию: Мнения читателей

Инструментарий: Новые продукты для специалистов по информационным технологиям

Greg Steen Exchange – очередь за ответами: Добавление голосовых приглашений, выбор УАТС и другое

Есть вопросы по поводу единой системы обмена сообщениями Exchange? Мы знаем ответы. В этом выпуске «Exchange – очередь за ответами» мы уделяем особое внимание единой системе обмена сообщениями, рассказывая о том, как можно применить возможности, связанные с телефоном и факсом, предложить высокую доступность, установить голосовые приглашения и о многом другом.

Seema Rahman Обзор служебных программ: Средство переноса Windows Easy Transfer Companion

Это бесплатное средство может упростить перенос ключевых приложений с Windows XP на Windows Vista.

Lance Whitney Кабельщик: Усовершенствования в Windows Server 2008, относящиеся к DNS.

Windows Server 2008 включает в себя многочисленные усовершенствования сервера DNS. Познакомьтесь поближе с тем, как эти обновления ускоряют разрешение имен, улучшают поддержку IPv6 и увеличивают гибкость администрирования DNS.

Joseph Davies Windows PowerShell: Перехват вредоносных программных кодов

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

Don Jones Эй, сценарист!: Регулярные выражения невозможно не узнать

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

The Microsoft Scripting Guys На страже безопасности: От острова к острову: заразительная скачка промо-материалов поставщика

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

Jesper M. Johansson Материалы о рабочей среде: Общее пользование компьютерами при помощи Windows SteadyState

Новый инструментарий Windows SteadyState помогает улучшить безопасность и упростить управление системами Windows XP в среде общего пользования. Воспользуйтесь этой статьей, чтобы узнать, как именно это происходит.

Wes Miller Заметки разъездного инженера: Самая важная задача

При работе над проектом не следует недооценивать важность выделения времени на обдумывание, планирование и расстановку приоритетов.

Eric N. Bush Конфиденциально о Windows : Напомните мне никогда больше этого не делать

Обнаружение оборудования до появления настоящих устройств Plug and Play было весьма пугающим занятием. Узнайте, почему.

Raymond Chen


 Системный центр: Технология Real Control в применении к Virtual Machine Manager 2007
Системный центр Эдвин Юэн

Технология Real Control в применении к Virtual Machine Manager 2007
Краткий обзор:
  • Основные характеристики System Center Virtual Machine Manager 2007
  • Установка VMM
  • Преобразование физических и виртуальных компьютеров в VM

System Center Virtual Machine Manager 2007 является новым решением, обеспечивающим объединенный интерфейс для управления всей виртуальной инфраструктурой. Диспетчер виртуальных машин (VMM)
управляет существующими установками Microsoft® Virtual Server 2005 и позволяет установить Virtual Server 2005 R2 с пакетом обновления 1 (SP1) на новых узлах виртуальных машин (VM). С помощью VMM выполнение административных задач Virtual Server 2005 осуществляется гораздо эффективнее благодаря наличию централизованного интерфейса, обеспечивающего доступ к нескольким установкам виртуального сервера в целях управления.
Кроме этого, VMM предоставляет виртуальному серверу новые возможности, включая преобразования «физический-виртуальный» (P2V), преобразование «виртуальный-виртуальный» (V2V) для дисков формата VMDK (VMDKVMware Virtual Machine Disk Format) в диски формата VHD (VHDVirtual Server Virtual Hard Disks) и быстро реализуемые развертывания VM на основе шаблонов и предварительно настроенных дисков VHD посредством централизованной библиотеки объектов виртуальной инфраструктуры.
Следующие страницы будут посвящены обсуждению VMM и мощному набору средств, которые он предоставляет ИТ-администраторам. Затем будут рассмотрены необходимые условия и этапы создания установки VMM. В конце я детально опишу некоторые из наиболее захватывающих возможностей VMM и сообщу некоторые полезные советы по началу работы с диспетчером.

Знакомство с Virtual Machine Manager 2007
System Center Virtual Machine Manager 2007 является автономным приложением, предоставляющим средства централизованного управления на уровне предприятия виртуальными машинами, работающими под управлением Microsoft Virtual Server 2005. Будучи частью семейства System Center, диспетчер виртуальных машин предусматривает интеграцию с другими программными продуктами System Center с целью обеспечения всеобъемлющего управления физической и виртуальной инфраструктурой. На рис. 1 показаны различные компоненты диспетчера виртуальных машин, и проводится сопоставление диспетчера виртуальных машин и узла виртуального сервера.
Прямоугольник, находящийся слева, представляет сервер VMM, а находящийся справа — узел виртуальной машины. При желании, с целью повышения производительности и масштабируемости, компоненты VMM можно устанавливать на отдельных серверах. В данной статье будет использоваться модель, представленная на рис. 1, в которой основные компоненты VMM установлены на одном компьютере. Самым существенным компонентом VMM является служба диспетчера виртуальной машины, находящаяся в центре левой части. Над ней находятся три разных интерфейса, входящие в эту службу: интерфейс Windows PowerShellTM, консоль администратора и портал самообслуживания со средствами управления Delegated Provision. Поддержка VMM осуществляется базой данных Microsoft SQL Server® 2005 (можно использовать как полную установку SQL Server, так и версию SQL Server 2005 Express) и централизованной библиотекой, которая является общим файловым ресурсом для компонентов виртуальной инфраструктуры.
Рис. 1 Архитектура System Center Virtual Machine Manager 2007
Рис. 1 Архитектура System Center Virtual Machine Manager 2007
Правая сторона рис. 1 представляет узел виртуальной машины Virtual Server 2005 R2, которым управляет VMM. Внизу представлена основная операционная система — в данном случае это Windows Server® 2003 R2. VMM устанавливает на узле виртуальной машины агента, который способствует обмену данными между VMM и Virtual Server 2005 R2. Это единичная установка на физическом узле, не сопровождаемая установкой виртуальных машин или гостевой операционной системы. Если на компьютере не установлен виртуальный сервер, VMM автоматически выполняет установку при добавлении компьютера к списку управляемых серверов.
Будучи частью семейства программных продуктов System Center, диспетчер виртуальных машин использует новый интерфейс System Center (или интерфейс в стиле Outlook®) для работы с консолью администратора (в противоположность традиционной оснастке MMC). Консоль администратора VMM (см. рис. 2) разработана с применением технологии Microsoft .NET Framework 2.0 и является надстройкой на Windows PowerShell 1.0. Фактически, любое действие, выполняемое в консоли администратора, вызывает соответствующую команду Windows PowerShell. Результатом этого является то, что к любой команде или функции, вызываемой в консоли администратора, можно обратиться также напрямую из Windows PowerShell с помощью интерфейса командной строки.
Рис. 2 VMM Admin UI показывает управляемые виртуальные машины
Рис. 2 VMM Admin UI показывает управляемые виртуальные машины
Каждый мастер консоли администратора снабжен кнопкой «Просмотр сценария», позволяющей отобразить сценарий, соответствующий запускаемой на выполнение команде. Эта возможность является прекрасной отправной точкой для изучения среды Windows PowerShell и ее соотношения с VMM. Освоившись с совместным использованием Windows PowerShell и VMM, вы сможете создавать сценарии для выполнения пакетных операций посредством VMM.
Диспетчер виртуальных машин разработан с целью предоставления ИТ-администраторам трех основных преимуществ: он позволяет использовать максимальное число ресурсов, добиться динамичности и использовать имеющиеся навыки. Эти преимущества VMM обеспечивает посредством нескольких компонентов и функций. Во-первых, VMM позволяет использовать максимальное число ресурсов, предоставляя метод преобразования физических серверов в виртуальные машины. Этот процесс известен под названием преобразования P2V и позволяет, не прибегая к переустановке машин, объединить имеющиеся физические машины в виде виртуальных машин. Это особенно существенно при преобразовании машин с низким показателем использования оборудования, поскольку несколько таких машин можно поместить на один компонент физического оборудования. Это может оказать особенно полезным, скажем, в случае редко используемых машин с устаревшим программным обеспечением, которые, тем не менее, необходимо поддерживать из-за единственного в течение года запуска программ (например, регулирующее бухгалтерское программное обеспечение). При использовании совместно с System Center Operations Manager 2007, VMM облегчает создание отчетов о кандидатах на объединение серверов с целью просмотра машин физической инфраструктуры, являющихся вероятными кандидатами для преобразования P2V.
Если уже имеются виртуальные машины формата VMware's VMDK, VMM предоставляет возможность выполнить преобразование V2V с целью перевода существующих VMDK в формат VHD. Это позволяет быстро настроить и запустить на выполнение среду Virtual Server 2005.
В процессе любого развертывания, нового или запущенного в рамках преобразования, VMM использует для развертывания машин VM на узлах виртуальных машин процесс с названием Intelligent Placement. С помощью Intelligent Placement VMM опрашивает все управляемые им узлы виртуальных машин, получает несколько параметров, относящихся к доступности ресурсов этих узлов, после чего возвращает взвешенный список узлов, на которых рекомендуется развернуть VM. Как видно из рис. 3, администратор может сделать выбор в пользу принятия этих рекомендаций, настроить алгоритм в соответствии с конкретными потребностями, либо развернуть VM на сервере по собственному выбору. Предоставляя объединенный просмотр виртуальной инфраструктуры и рекомендаций по ее размещению, Intelligent Placement значительно сокращает нагрузку, связанную с развертыванием VM.
Рис. 3 Intelligent Placement обеспечивает рекомендации для лучшего узла Virtual Server
Рис. 3 Intelligent Placement обеспечивает рекомендации для лучшего узла Virtual Server
К другим компонентам VMM, дающим существенные преимущества, относится централизованная библиотека и портал самообслуживания для обеспечения делегированной подготовки. Библиотека, показанная на рис. 4, предоставляет централизованное хранилище для всех компонентов, необходимых для создания виртуальной инфраструктуры, включая предварительно созданные и готовые для развертывания диски VHD, шаблоны с параметрами ОС и конфигурацией оборудования, файлы ISO, сценарии и профили. На основе этих компонентов можно создавать и развертывать новые машины VM, а с помощью шаблонов и профилей стандартизировать параметры аппаратного и программного обеспечения для всех машин VM. VMM поддерживает также распределенные библиотеки, что позволяет хранить компоненты в удаленных местоположениях и поддерживать передачу больших файлов в пределах удаленного местоположения, продолжая осуществлять централизованное управление компонентами.
Рис. 4 Библиотека VMM содержит все блоки для создания виртуальной инфраструктуры
Рис. 4 Библиотека VMM содержит все блоки для создания виртуальной инфраструктуры
Портал самообслуживания представляет собой веб-узел, объединенный со службой VMM и установкой IIS. Портал предоставляет доступ к машинам VM авторизованным пользователям и группам Active Directory®. Функции, к которым разрешен доступ, зависят от политики, предусмотренной для конкретного пользователя или группы. Набор этих функций простирается от возможности просмотра машин VM и получения к ним доступа до возможности запуска и отключения VM, создания новых VM на основе конкретных делегированных ресурсов.
Администратор создает политику самообслуживания, предоставляющую конкретные функции пользователям и группам Active Directory, конкретным узлам виртуальных машин или группам узлов, а также конкретным машинам VM и шаблонам. Портал самообслуживания дает администраторам возможность безопасного делегирования функций конечным пользователям. В отсутствие этой функции администратору пришлось бы либо предоставлять пользователям доступ к консоли администратора для управления их машинами VM, либо вынуждать пользователей обращаться с запросом по поводу каждой функции, что приводило бы к обременительному использованию электронной почты и телефонных звонков для выполнения всего лишь таких операций, как запуск и перезагрузка VM.

Установка диспетчера виртуальной машины
В настоящее время VMM управляет установками Virtual Server 2005 (и более поздних версий) в среде Window Server 2003 с пакетом обновления 1 (SP1) (и следующими) в пределах домена Active Directory (или доверенного домена), а также компьютерами вне домена с помощью обеспечиваемой диспетчером VMM поддержки пограничной сети. Не поддерживаются установки виртуального сервера в операционных системах настольных компьютеров, таких как Windows® XP. Операции P2V доступны только для физических машин, расположенных в том же домене (или доверенном домене), что и сервер VMM.
Хотя в производственной среде я рекомендовал бы устанавливать все компоненты VMM на отдельных серверах, инструкции, приведенные в данной статье, относятся к установке на одном сервере. Для установки сервера VMM рекомендуется использовать сервер с процессором x86 или x64, работающий с частотой 2,8 ГГЦ или более высокой и имеющий ОЗУ объемом не менее 2 Гбайт. Поскольку мы рассматриваем установку на одном сервере с локальной базой данных SQL Server, на жестком диске необходимо наличие 7 Гбайт свободного пространства. Если же используется удаленная база данных, для установки VMM требуется только 1 Гбайт. Рекомендуется обеспечить дополнительные 80 Гбайт дискового пространства для установки локальной библиотеки.
Дополнительно для VMM требуется установить WinRM 1.1 на сервере VMM, всех узлах виртуальных машин и всех серверах библиотек, которые будут управляться диспетчером виртуальных машин. WinRM представляет собой реализацию протокола WS-Management. WinRM — это совместимый с брандмауэром протокол на основе SOAP, позволяющий взаимодействовать и осуществлять взаимное управление аппаратному и программному обеспечению от разных поставщиков. VMM использует WinRM для выполнения операций по взаимодействию серверов, узлов виртуальных машин и серверов библиотек. WinRM 1.1 можно загрузить с веб-страницы по адресу go.microsoft.com/fwlink/?LinkId=103610.
Для установки необходимо также наличие .NET Framework 2.0 и 3.0, Windows PowerShell 1.0 и IIS для портала самообслуживания. Во время установки VMM проверяется наличие всех необходимых дополнительно программ, и предоставляются ссылки на соответствующие установщики. Если какие-либо программы отсутствуют, выполнение процедуры установки приостанавливается.
При запуске процедуры установки VMM в главном меню предлагается выбор из трех возможностей: сервер диспетчера виртуальных машин, консоль администратора и портал самообслуживания. Мы будем устанавливать все три компонента на одной машине, начиная с сервера. После начала процедуры установки на первых экранах отображается процесс проверки выполнения необходимых условий; для продолжения процедуры установки необходимо обеспечить выполнение всех этих условий.
Убедившись в том, что необходимые условия выполнены, следует просмотреть варианты установки, в особенности имеющие отношение к базе данных SQL Server. В случае VMM можно либо установить версию SQL Server 2005 Express, либо использовать существующую базу данных SQL Server 2005. В данном примере будет использоваться версия SQL Server 2005 Express.
На следующем этапе работы мастера установки VMM указывается местоположение централизованной библиотеки. Это может быть локальный каталог на сервере VMM (и для этого каталога будет создан общий ресурс), либо можно использовать существующий общий файловый ресурс. Местоположением по умолчанию является C:\Documents and Settings\All Users\Shared Documents\Virtual Machine Manager Library Files.
На следующем этапе выполняется назначение портов. Выполняется настройка портов, используемых для обмена данными между консолью администратора и основной службой сервера VMM (порт 8100), порта, используемого WinRM для выполнения функций управления (порт 80, стандартный порт HTTP) и порта, используемого службой BITS (Background Intelligent Transfer Service) для перемещения файлов на узлы виртуальных машин (порт 443, стандартный порт HTTPS). По окончании сбора всех данных отображается заключительный экран и установку сервера можно завершать.
Обратимся теперь к установке консоли администратора. Необходимые условия, предъявляемые к системе, подобны условиям в случае сервера VMM, требующего наличия .NET Framework 2.0 и 3.0, а также Windows PowerShell 1.0. Единственный режим настройки заключается в подтверждении порта, используемого для подключения к основной службе сервера VMM. Это может быть порт 8100, настроенный во время установки сервера VMM. В конце процедуры установки предлагается создать ярлык рабочего стола для консоли администратора и открыть консоль по завершении установки. Я рекомендую выбрать обе возможности. При первом открытии консоли администратора запрашиваются сведения о соединении с сервером. В случае установки на одном сервере следует соединиться с localhost через порт 8100 и нажать клавишу Enter для запуска консоли.
И, наконец, перейдем к установке на этом сервере портала самообслуживания. Для этого необходимо наличие IIS, .NET Framework 2.0 и 3.0 и Windows PowerShell 1.0. В ходе установки запрашиваются только те параметры, которые относятся к портам, используемым порталом самообслуживания. Первым является порт для соединения с основной службой VMM, порт 8100, тот же самый, что для консоли администратора. Вторым является порт, обеспечивающий работу портала. По умолчанию это порт 80, но во многих конфигурациях этот порт, возможно, уже используется. При необходимости замените этот порт другим открытым портом, например, портом 81.
Установщик создает веб-узел с именем Microsoft System Center Virtual Machine Manager 2007 Self-Service Portal, и в диспетчере служб IIS изменяются настройки. Один совет для облегчения установки: перейдите в диспетчер служб IIS и откройте свойства Microsoft System Center Virtual Machine Manager 2007 Self-Service Portal. Ознакомьтесь с конфигурацией ASP.NET для данного веб-узла и подтвердите использование версии ASP.NET 2.0. Портал самообслуживания не будет работать, если для ASP.NET задана версия 1, а, в зависимости от порядка установки версий IIS и .NET Framework, эти параметры могут различаться.
По завершении установки IIS можно открыть веб-узел, перейдя в обозревателе Internet Explorer® по адресу http://localhost:81. Появление при открытии веб-узла запроса на прохождение проверки подлинности обусловлено настройками безопасности Internet Explorer. Портал самообслуживания должен работать в Internet Explorer в контексте интрасети; возможно, в локальной конфигурации сервер VMM потребуется добавить в список узлов интрасети. После внесения этих изменений все готово для создания и использования в VMM политик самообслуживания.

Возможности диспетчера виртуальной машины
Хотя у VMM имеется много вдохновляющих функций, две возможности, P2V («физический-виртуальный») и V2V («виртуальный-виртуальный»), вызовут, вероятно, наибольший интерес. Обе функции поддерживаются в рамках консоли администратора. Поскольку консоль администратора построена поверх Windows PowerShell, все команды можно запускать также с помощью самой Windows PowerShell. В наших целях процесс P2V будет рассматриваться с помощью консоли администратора, а процесс V2V — с помощью Windows PowerShell.

Преобразование «физический-виртуальный»
Для выполнения преобразования P2V используем консоль администратора VMM. Физическая машина, подвергаемая преобразованию, должна удовлетворять нескольким требованиям. Во-первых, эта машина должна входить в текущий домен или доверенный домен. VMM соединяется с этой машиной для установки агента P2V и передачи необходимой информации. Во-вторых, на исходной машине должна работать поддерживаемая операционная система. Для преобразования P2V поддерживаются операционные системы Windows Server 2003, Windows 2000 Server и Windows XP Professional. Если на исходной машине работает Windows Server 2003 или Windows XP, VMM использует службу теневого копирования томов (VSS — Volume Shadow Copy Service ) для объединения жестких дисков и направления потока данных на виртуальные жесткие диски. Это позволяет выполнять преобразование машины без простоев, поэтому при создании образа P2V нет необходимости планировать простои сервера. В случае Windows 2000 создается загрузочный диск Windows PE, чтобы облегчить создание образа P2V. В данном примере будет рассматриваться случай использования Windows Server 2003.
Процесс P2V начинается с выбора режима «Преобразование физического сервера» в пункте «Действия» в верхней части консоли администратора. При этом запускается мастер P2V, показанный на рис. 5. Первая страница соответствует этапу «Выбор источника», где указывается участвующая в преобразовании машина. Введите DNS-имя этой машины и соответствующие учетные данные домена, чтобы выполнить соединение и приступить к управлению машиной. На следующем этапе предоставляется возможность задать имя результирующей машины VM.
Рис. 5 Фунцкия VMM P2V основана на работе мастера и встроена в интерфейс пользователя администратора
Рис. 5 Фунцкия VMM P2V основана на работе мастера и встроена в интерфейс пользователя администратора
Затем мастер запускает процесс сбора данных на исходной машине. После выбора пункта «Сбор системной информации» VMM устанавливает агента P2V, который выполнит сбор необходимой информации, относящейся к операционной системе машины, жесткого диска и сетевых адаптеров. Щелчком кнопки «Далее» осуществляется переход к экрану проверки, чтобы убедиться в отсутствии известных проблем, препятствующих преобразованию. В случае обнаружения таких проблем представляются возможные варианты их разрешения.
После того, как получены данные о конфигурации, можно выбрать разделы жесткого диска, подлежащие преобразованию. По умолчанию выбирается загрузочный раздел, и все остальные имеющиеся разделы становятся доступными. Предоставляется возможность выбрать разделы, участвующие в преобразовании. Преобразование P2V является «интеллектуальным» процессом копирования; это означает, что извлекаются данные только указанных разделов, в противоположность фиксированной передаче всего образа и объема жесткого диска.
Наконец, мастер переходит к стандартным этапам развертывания VMM, включая конфигурации загрузки и процесс Intelligent Placement, описанный ранее. По окончании работы мастера открывается окно «Задания», в котором отображается весь процесс преобразования P2V и ход его выполнения.
По умолчанию новые VM, полученные в результате преобразования, не запускаются автоматически (после преобразования они находятся в остановленном состоянии). Точно так же процесс P2V не отключает исходную машину и не изменяет ее статуса. Процесс P2V является недеструктивным. Поскольку у новой машины VM такое же имя, IP-адрес и даже MAC-адрес, как у исходного сервера, прежде чем запускать VM, исходную машину необходимо отключить. Предусмотрено автоматическое отключение исходной машины или запуск новой, полученной в результате преобразования VM — это можно сделать с помощью интерфейса командной строки Windows PowerShell. В рамках этого процесса имеет смысл выполнить преобразование P2V, а затем, убедившись в успешном завершении преобразования, запустить полученную VM в тестовой среде.

Преобразование «виртуальный-виртуальный»
Для выполнения преобразования V2V необходимо наличие как виртуальной машины VMW (в формате файла VMDK), так и допустимой установки VMM с целевым узлом виртуальных машин. Командлет VMM V2V Windows PowerShell с именем new-v2v поддерживает следующие четыре формата файлов VMDK: monolithicSparse, monolithicFlat, twoGbMaxExtentSparse и twoGbMaxExtentFlat. Большинство существующих файлов VMDK относятся к одной из этих категорий.
Процесс V2V работает только с автономными файлами VMDK. Однако процесс P2V можно использовать для преобразования виртуальных машин VMware, работающих в текущий момент. Виртуальные машины VMware состоят из двух основных компонентов — файлов VMDK, представляющие собой виртуальные жесткие диски, на которых хранятся данные, и файла VMX, в котором заключена информация о конфигурации виртуальной машины. Файлы VMDK и соответствующий файл VMX можно поместить по месту нахождения библиотеки, что обеспечивает возможность доступа и преобразования виртуальной машины VMware без необходимости предоставления доступа к файлу с исходного сервера.
В ходе преобразования V2V файл VMDK преобразуется в файл VHD, гостевая операционная система удаляется, чтобы уступить место виртуальному серверу, и создается новая виртуальная машина, максимально возможно соответствующая исходной конфигурации, с внесением необходимых изменений в виртуальное оборудование, поддерживаемое виртуальным сервером. Отметим, что с помощью среды Windows PowerShell можно управлять каждым этапом процесса преобразования по отдельности, что позволяет провести пакетные преобразования формата до выделения узлов новых виртуальных машин. В этом примере мы собираемся преобразовать и развернуть VHD.
Хотя преобразование V2V можно выполнить как с помощью консоли администратора, так и с использованием среды Windows PowerShell, для данного примера будет использоваться Windows PowerShell. Чтобы запустить процесс V2V, откроем окно Windows PowerShell с загруженными командлетами VMM. Для этого щелкнем последовательно Пуск | Все программы | Microsoft System Center | Virtual Machine Manager 2007 | Windows PowerShell—Virtual Machine Manager.
Открывшееся окно должно иметь заголовок Windows PowerShell—Virtual Machine Manager. Если заголовок выглядит не так, возможно, не загружены командлеты VMM. После того, как откроется окно Windows PowerShell, можно ознакомиться с командой new-v2v, выполнив следующую команду:
get-help new-v2v –full | more
Будет выведена информация о синтаксисе и примеры выполнения V2V. В примере, приведенном в этой статье, наш сервер VMM называется vmmserver.contoso.com, узел, предназначенный для виртуальной машины, называется vshost1.contoso.com, а доступ к VMDK осуществляется с сервера библиотеки vmmserver.contoso.com.
Сначала, с помощью команды get-vmmserver, указывается контекст для сервера VMM, который будет использоваться для выполнения преобразования V2V. Как и во всех командах Windows PowerShell, в команде get-vmmserver используется формат глагол-существительное, а для указания параметров используются дефисы. В следующей строке показана команда, которая будет использоваться для указания сервера VMM:
get-vmmserver –computername "vmmserver.contoso.com"
Здесь в качестве контекста сервера VMM, которому должны следовать команды, задается vmmserver.contoso.com. Результатом работы приведенной выше команды является подробный список со сведениями о vmmserver.contoso.com. В случае неправильной команды или ошибки в синтаксисе отображается сообщение красного цвета с описанием проблемы.
На следующем этапе указывается узел, предназначенный для виртуальной машины — узел виртуального сервера, которому назначается преобразованный VMDK или VHD. Продолжим, присвоив значение узла виртуальной машины переменной $vmhost с помощью следующей команды Windows PowerShell:
$vmhost = get-vmhost –computername
"vshost1.contoso.com"
Эта команда не выводит никакой информации в окне команд, но правильность задания переменной легко проверить, введя в командной строке Windows PowerShell «$vmhost» и нажав клавишу Enter. Отобразится информация, хранящаяся в $vmhost (подробная информация о vshost1.contoso.com, подобная информации, полученной выше для сервера VMM).
Кроме узла виртуальной машины необходимо указать сервер библиотеки, на котором находится файл VMDK. Команда аналогична команде для узла виртуальной машины, использованной ранее:
$library = get-libraryserver –computername
"vmmserver.contoso.com"
Как и в случае $vmhost, ввод «$library» в командной строке приводит к отображению информации о сервере библиотеки.
Наконец, вводится команда для выполнения преобразования V2V. Для этого используется команда new-v2v command с функцией get-help. В этой команде указывается сервер библиотеки для VMX/VMDK, назначенный компьютер, имя результирующей VM и путь для преобразованного файла VHD.
Для командной строки большинство ссылок дается относительно компьютера назначения. В нашем случае это vshost1.contoso.com. А путь для установки дается в виде локальной ссылки для VSHOST1. Путь для VMX дается относительно сервера библиотеки. Итоговая командная строка в Windows PowerShell выглядит следующим образом:
new-v2v –LibraryServer $library –vmxpath
"\\vmmserver.contoso.com\MSCVMMLibrary\VMDKS\ConvertMe.vmx"
–vmhost $vmhost -name "DemoV2V"
–path "C:\VHDs"
Как видно, в данном случае осуществляется преобразование VMX/VMDK для \\vmmserver.contoso.com\MSCVMMLibrary\VMDKS\ConvertMe.vmx на сервере библиотеки $library (VMMSERVER), разворачиваемом на узле, указанном в переменной $vmhost (VSHOST1), с именем DemoV2V и использованием пути C:\VHDs на VSHOST1.
После запуска команды на выполнение имеет смысл вернуться в окно «Задания» консоли администратора VMM, чтоб следить за ходом выполнения преобразования. VMX/VMDK преобразуется и затем копируется на VSHOST1, где итоговый VHD в виде DemoV2V добавляется к списку машин VM. После полного завершения процесса преобразования VMM можно использовать для запуска новой виртуальной машины и просмотра результатов.

Заключение
Как видно из вышесказанного, System Center Virtual Machine Manager 2007 привносит в виртуальную инфраструктуру несколько замечательных новых компонентов и возможностей. Я надеюсь, что, рассмотрев процессы преобразования P2V и V2V, мне удалось показать, насколько легко они выполняются с помощью диспетчера виртуальных машин.
VMM предназначен для облегчения работы ИТ-администраторов в процессе создания, развертывания и обслуживания VM. С выходом System Center Virtual Machine Manager 2007 я настойчиво рекомендую администраторам Virtual Server 2005 рассмотреть возможность использования диспетчера виртуальных машин для обслуживания компьютеров с виртуальными машинами. Для пользователей новой виртуализации Windows Server в Windows Server 2008 Майкрософт предоставит поддержку виртуализации Windows Server в следующей версии System Center Virtual Machine Manager, которая будет доступна после выхода окончательной версии виртуализации Windows Server 2008.
Для получения дополнительных сведений о VMM и загрузки демо-версии обратитесь на веб-узел по адресу microsoft.com/SCVMM. Подробнее обо всех продуктах Майкрософт для виртуализации см. на веб-узле по адресу microsoft.com/virtualization.

Эдвин Юэн является техническим руководителем программного продукта System Center Virtual Machine Manager в подразделении управления предприятием Windows. Эдвин пришел в Майкрософт вместе с компанией Softricity, приобретенной корпорацией в июле 2006 г. За плечами Эдвина 13 летний опыт работы в качестве технического консультанта по решениям для коммерческих и государственных структур. Степень бакалавра электротехнических наук он получил в университете Johns Hopkins.
© 2007 Корпорация Майкрософт и компания CMP Media, LLC. Все права защищены; полное или частичное воспроизведение без разрешения запрещено.


 Системный центр: Создание усовершенствованных архивов с помощью Data Protection Manager 2007
Системный центр Кэлвин Китон

Создание усовершенствованных архивов с помощью Data Protection Manager 2007
Краткий обзор:
  • Уход от ленточных архивов
  • Непрерывная защита данных
  • Архивы на основе дисков
  • Повышение детальности контроля с помощью DPM

В последнее время на рынке решений для защиты данных появилось множество разнообразных предложений. После многолетнего господства решений для архивирования на основе магнитных лент и использования универсального приема ежедневного ночного копирования в относительно короткий период времени был представлен целый ряд новых
технологий и методов. В перечень этих новых технологий входит создание архивов на дисках, непрерывная защита данных (CDP — Continuous Data Protection) и даже такие кажущиеся простыми методы, как шифрование данных. Некоторые из этих подходов стали возможны и даже необходимы в силу недавнего снижения стоимости дисковых накопителей, повышения производительности сетей и процессоров, а также новых нормативных требований.
Майкрософт давно занимается созданием решений в этой области на уровне платформ и приложений. Средства архивирования, входящие в NTBackup, Exchange Server и SQL ServerTM — всего лишь некоторые из таких решений.
На рынке решений для защиты данных первым автономным программным средством производства Майкрософт стал продукт System Center Data Protection Manager (DPM) 2006. Это был один из первых программных продуктов, предлагавших защиту данных на основе дисков, и он остается одним из редких решений, с самого начала создававшихся с идеей использования архивов на дисках. В большинстве других предложений применялись и по-прежнему применяются адаптированные для случая дисков идеи, использовавшиеся для архивов на магнитных лентах.
DPM входит в семейство программных продуктов System Center. Программные продукты семейства System Center разработаны для совместного использования с целью облегчения и удешевления повседневного управления сложной информационно-технической инфраструктурой. Решения System Center основаны на автоматизации и практических рекомендациях, ведущих свое происхождение от платформы Microsoft® Operations Framework (MOF) и библиотеки Information Technology Infrastructure Library (ITIL), и их можно использовать на всех уровнях организации.
DPM — это только один из программных продуктов семейства System Center. System Center Configuration Manager предоставляет средства управления конфигурацией и распространения программного обеспечения. System Center Operations Manager предоставляет средства профилактического текущего контроля и автоматизации системы. System Center Capacity Planner служит для планирования развертываний инфраструктуры и анализа возможного развития событий. (Подробнее см. на веб-странице по адресу microsoft.com/systemcenter.)
System Center Data Protection Manager 2006 обеспечивает создание архивов на дисках для файловых серверов и серверов печати, а также создание дисковых архивов филиалов компании с использованием глобальной сети (WAN). Этот программный продукт был разработан с целью защиты файловых серверов в центре обработки данных и для удаления из филиала оборудования для локальных архивов на магнитных лентах. Но в нем отсутствует встроенная поддержка приложений Майкрософт, и для долговременных архивов на магнитных лентах используются программные продукты независимых поставщиков.
Новая версия DPM, System Center Data Protection Manager 2007, создана на этой основе и по-прежнему обеспечивает надежную защиту с использованием дисков для файловых серверов и серверов печати, а также филиалов компании. Но, помимо этого, добавлена поддержка для приложений Майкрософт, которые важны для работы предприятий, таких как Exchange, SQL Server и SharePoint®, а также встроенная поддержка для архивов на магнитных лентах. Для новых версий характерно наличие существенных изменений, и это особенно верно в случае DPM. Во вторую версию, наряду со значительными усовершенствованиями существующих функций, введено большое число новых возможностей. В данной статье разбираются несколько из этих новых и усовершенствованных функций, и дается широкий обзор возможностей, на которые можно рассчитывать при использовании этой новой вдохновляющей версии.

Поддержка приложений и платформ
Многие поставщики программ создания архивов решают вопрос поддержки приложений методом «размазывания». Они распределяют вложения на проектирование решений между большим числом приложений, стремясь обеспечить поддержку как можно большему числу источников данных. В результате большому числу приложений обеспечивается элементарная поддержка. Вместо того, чтобы пытаться предоставить ограниченную поддержку для широкого набора приложений и платформ, в Майкрософт был выбран путь концентрации усилий на защите нескольких специализированных приложений на платформе Windows®. Такой подход позволил направить инженерно-технические усилия на эти приложения, чтобы создать объединенную среду для архивирования и восстановления данных, в которую входят компоненты, не часто встречающиеся в других программах архивирования.
Первоочередным запросом пользователей DPM 2006 была поддержка Microsoft Exchange. С учетом этого запроса в DPM 2007 введена поддержка как для Exchange Server 2003, так и для Exchange Server 2007. Защита осуществляется на уровне групп хранения, и в пользовательском интерфейсе DPM отдельные группы хранения выступают в качестве объектов, которые при необходимости можно добавлять в группы защиты с целью создания регулярных архивов, управление которыми осуществляется с помощью политик. Кластерные группы хранения выступают в виде одного объекта, что избавляет от необходимости следить за отдельными членами кластера и вручную синхронизировать их защиту. Восстановление может осуществляться на уровне группы хранения, базы данных или почтового ящика. Детализированное восстановление после ошибок достигается посредством автоматизации, использующей стандартные инструменты Exchange для восстановления данных в группу хранения для восстановления и последующего извлечения менее масштабных объектов, таких как почтовые ящики, опять же с использованием стандартных инструментов Exchange (см. рис. 1).
Figure 1 Exchange support in DPM
Figure 1 Exchange support in DPM
В отличие от других решений Exchange для архивирования, DPM при извлечении объектов, которые потом восстанавливаются, не прибегает к использованию инструментов, не входящих в Exchange, или реконструированию базы данных Exchange. Поэтому все почтовые ящики, восстановленные с использованием DPM, поддерживаются Exchange в полной мере.
DPM 2007 является первым программным продуктом, полностью поддерживающим кластеры, создаваемые в Exchange 2007 средствами непрерывной репликации кластера (CCR) и локальной непрерывно репликации (LCR). Поддерживаются также кластеры Exchange 2003.
DPM 2007 поддерживает SQL Server 2000 и SQL Server 2005; создание архива и восстановление происходят на уровне базы данных. Включена также поддержка перенаправленных и переименованных восстановленных данных, а также полная поддержка кластеризованных, зеркальных баз данных и баз данных доставки журналов.
Так же, как в Exchange, кластеризованные базы данных выступают в пользовательском интерфейсе в виде одного объекта, что избавляет от необходимости настраивать защиту на нескольких кластерных серверах по отдельности (см. Figure 2). Поддержку SQL Server в DPM можно использовать для защиты приложений независимых поставщиков, использующих серверные базы данных SQL Server. Поддержка таких приложений осуществляется посредством защиты файлов, а база данных SQL Server защищается посредством встроенной в DPM поддержки для SQL Server. Гибкий механизм планирования, имеющийся в DPM, позволяет добавлять к одной и той же группе защиты как архив файлов, так и архив SQL Server, чтобы эти архивы создавались одновременно, и для планирования и управления ими использовался общий интерфейс.
Figure 2 Clustering backups
Figure 2 Clustering backups
Рабочие нагрузки, возникающие при совместной работе, защищаются с помощью SharePoint 2007, при этом поддерживается как версия Windows SharePoint Services (WSS) 3.0, так и Microsoft Office SharePoint Server (MOSS) 2007. Поддержка осуществляется на уровне фермы, даже если ферма охватывает больше одного сервера. Так, например, ферма, состоящая из трех серверов веб-интерфейса, двух серверов коллекций узлов и одного сервера базы данных, т.е. всего из шести серверов, выступает в пользовательском интерфейсе DPM в виде одного объекта и DPM восстанавливает ее также как один объект.
Помимо поддержки восстановления фермы как единого целого, в DPM входит также поддержка восстановления узлов, коллекций узлов и отдельных документов, списков или элементов. Старые версии SharePoint, безусловно, можно защищать как базы данных SQL Server посредством имеющихся в DPM функций защиты SQL Server.
В DPM 2007 по-прежнему поддерживаются файловые рабочие нагрузки и рабочие нагрузки печати. Поддержка для Open File предоставляется без дополнительной оплаты. Была добавлена поддержка для исключений папок и файлов, а также поддержка архивирования состояния системы. Важно отметить, что поддержка File получила дальнейшее развитие, и теперь в нее включены Windows Vista® и Windows XP. Но эти клиентские операционные системы поддерживаются в относительно ограниченном объеме, поскольку поддержка направлена, главным образом, на системы, используемые в качестве файловых серверов. Пользователям DPM, по мере необходимости, разрешено защищать небольшое число клиентов, но эту поддержку трудно распространить на большое число настольных компьютеров.
Встроенная поддержка для серверов Exchange Servers, SQL Server, SharePoint и файловых серверов позволяет поддерживать в DPM обширное множество рабочих нагрузок, встречающихся в средах Windows. Для менее распространенных типов нагрузок в DPM 2007 включена также поддержка этапа, предшествующего выполнению сценария и этапа, следующего после выполнения сценария. Предусмотрен автоматический запуск этой поддержки при выполнении архивирования. Эти функциональные возможности позволяют DPM поддерживать широкий ряд других приложений и рабочих нагрузок. Поддержка этого рода интегрирована в DPM не в такой степени, как поддержка, предлагаемая для Exchange, SQL Server и SharePoint, но она обеспечивает существенную гибкость с точки зрения поддержки источников данных. Технические документы с подробными сведениями о поддержке некоторых основных программных продуктов, произведенных не в Майкрософт, например, Oracle, будут представлены на веб-узле DPM TechCenter по адресу technet.microsoft.com/dpm.
Еще одним интересным нововведением в DPM 2007 является поддержка виртуальных серверов конкретных узлов. Хотя большинство программ архивирования в состоянии поддерживать виртуальных гостей сервера, немногие, если они вообще есть, в состоянии предоставить такую защиту на уровне узла посредством одной установки лицензии и агента. В DPM преимущества рекурсивных модулей записи службы теневого копирования томов (VSS) используются для защиты всех гостей, размещенных на данном узле виртуального сервера, посредством одного развернутого на узле агента. Эти рекурсивные модули записи VSS могут вызывать модули записи VSS, работающие в гостевой среде, или даже в приложениях, выполняющихся в гостевой среде, независимо от того, какое приложение или операционная система установлена в гостевой среде. Это позволяет DPM защищать любую платформу или приложение, выполняющееся в качестве гостя, независимо от его поставщика. Такие архивы виртуальных серверов конкретных узлов являются согласованными с точки зрения приложения и состоят из одного образа виртуального жесткого диска (VHD), который, по мере необходимости, можно восстанавливать на существующем или новом узле.
Эти архивные образы конкретных узлов не обеспечивают восстановление с той же детальностью, как архивы, созданные посредством агента DPM, установленного на гостевом или изолированном сервере, но они предлагают другие эффективные возможности, включая удобное восстановление системы в виртуализированных средах.

Скорость, надежность и эффективность
Помимо усовершенствований, обеспечивающих углубленную и расширенную поддержку приложений по сравнению с предыдущей версией, DPM 2007 позволяет увеличить детализацию полных и добавочных архивов. Хотя DPM 2006 позволял выполнять даже ежечасную синхронизацию, новая версия DPM предоставляет возможность создавать добавочный архив каждые 15 минут, а полный архив — каждый час. Для клиентов, имеющих менее строгие соглашения об уровне обслуживания (SLA), может потребоваться всего лишь еженедельное проведение полного архивирования. Таким образом, эти клиенты могут уменьшить частоту архивирования на менее важных серверах, предусмотрев интенсивные графики защиты для наиболее важных серверов. Несмотря на то, что синхронизация с сервером DPM осуществляется каждые 15 минут, в промежутке между синхронизациями агент DPM по-прежнему активно отслеживает изменения на защищенном сервере.
Этот новый агент DPM непрерывно отслеживает изменения на уровне блоков, возникающие на защищенном сервере. Это стало возможным благодаря совершенно новому фильтру томов, разработанному для DPM 2007. Он состоит из побитового отображения, находящегося в памяти выгружаемого страничного пула, и содержит по одному биту для каждого блока защищенного тома.
Каждый раз, когда блок записывается на том, значение бита в битовом отображении меняется на противоположное. Этот процесс оказывает меньшее влияние на процессор и память, чем в случае обычного антивирусного фильтра, и он не предъявляет никаких требований к дисковому пространству, возрастающих в зависимости от частоты изменений. По сути, связанная с этим фильтром нагрузка вообще не возрастает в зависимости от частоты изменений. Это очень важно, так как большинство схем отслеживания изменений на уровне блоков приводит, как правило, к перегрузке процессора и требует много дополнительной памяти и дискового пространства, возрастающего в зависимости от частоты изменений. Поэтому высокая частота изменений приводит к расширению последствий, и, в некоторых случаях, крайне высокая частота изменений может привести к нехватке дискового пространства. В DPM 2007 влияние, оказываемое фильтром томов на процессор, память и диск, не зависит от частоты изменений. Будет ли это один процент или 1000 процентов, частота изменений попросту не сказывается на низких издержках, связанных с фильтром.
Однако, отслеживание изменяющихся данных — это только часть происходящих событий. DPM 2007 использует также службу VSS на защищенном сервере для создания архивного образа, согласованного с приложениями, который обеспечивает надежное восстановление. Служба VSS была разработана в Майкрософт с целью обеспечения инфраструктуры для архивирования в среде Windows XP и Windows Server® 2003, а также для ее использования в качестве механизма создания копий данных, соответствующих определенным моментам времени (теневые копии). VSS создает согласованные теневые копии, согласовывая операции чтения и записи с производственными приложениями, службами файловых систем, приложениями архивирования, решениями для быстрого восстановления после ошибок и устройствами хранения. В результате на современном рынке служба VSS является, вероятно, наиболее согласованным и надежным механизмом создания архивов, согласованных с приложениями. В Windows Server 2003 службу VSS используют несколько компонентов, включая теневое копирование для общих папок.
Большинство программных продуктов, использующих VSS для архивов приложений, создают реплику VSS и оставляют ее на защищенном сервере для отслеживания изменений и получения согласованного с приложением образа для архивирования. К сожалению, постоянное присутствие реплики на защищенном сервере существенно сказывается на производительности, поскольку каждый раз, когда приложение выполняет запись на диск, осуществляется копирование при записи с целью поддержания актуального состояния реплики VSS. Это может привести к 25-процентной перегрузке процессора и оказывает существенное влияние на время записи.
Поскольку DPM отслеживает изменения посредством фильтра томов, ему не требуется постоянно поддерживать реплику VSS. Вместо этого DPM создает реплику VSS в случае выполнения полного архивирования, затем использует наложение битового образа фильтра томов для выявления в реплике только тех данных, которые подверглись изменению. Эти измененные данные перемещаются на сервер DPM, который используется для создания точки восстановления. Затем на защищенном сервере удаляется реплика VSS и сбрасывается фильтр томов. После этого отслеживание изменений на уровне блоков продолжается с небольшими затратами ресурсов и без необходимости использования реплики VSS или соответствующего ей ресурса.
Это решение гарантирует, что точки восстановления обеспечат создание допускающего восстановление образа приложения, и сокращает объем данных, перемещаемых между защищенным сервером и сервером DPM.
В случае DPM 2007 при полном архивировании не происходит перемещения полной копии данных с защищенного сервера на сервер DPM. Вместо этого перемещаются только измененные данные. Поэтому для группы хранения Exchange, имеющей объем 100 Гбайт и 10-процентную частоту изменений в течение дня, ежедневный полный архив будет иметь объем всего лишь 10 Гбайт.
Если для создания точки восстановления делается мгновенный снимок, такое снижение объема полных архивов обеспечивает очень эффективное хранение на сервере DPM. Каждый мгновенный снимок состоит из измененных данных, образующих последний полный архив, и при выполнении полного архивирования он создается автоматически. При работе с приложениями эти мгновенные снимки содержат также результаты всех промежуточных добавочных архивирований.
Добавочные архивы являются, в основном, архивами журналов DPM, поэтому при каждом полном архивировании приложения измененные данные перемещаются на сервер DPM и присоединяются к любому промежуточному архиву журналов с целью создания одного мгновенного снимка, содержащего несколько точек восстановления. Если взять случай 100 Гбайтной группы хранения Exchange с 10-процентной ежедневной частотой изменений, которая описывалась ранее, и считать, что полное копирование выполняется ежедневно с 15-минутным интервалом, то мгновенный снимок будет содержать 10 Гбайт измененных данных и примерно 5-10 Гбайт журналов приложений. Но важно осознавать, что в мгновенном снимке объемом от 15 до 20 Гбайт будет содержаться до 97 точек восстановления!
Полные архивирования должны выполняться по меньшей мере еженедельно, а общее количество мгновенных снимков ограничено числом 512 для серверов приложений и 64 для файловых серверов. Поэтому еженедельное выполнение полных архивирований и проведение добавочных архивирований каждые 15 минут приведет к созданию 673 точек восстановления на один мгновенный снимок и более чем 340 000 точек восстановления в случае использования всех 512 мгновенных снимков. Хотя вряд ли кому-нибудь понадобится так много точек восстановления на диске, этот пример демонстрирует гибкость и масштабируемость DPM с точки зрения планирования заданий и восстановления данных на конкретный момент времени.
Вместе архивы журналов и полные архивы дают DPM возможность эффективно хранить очень большое число точек восстановления в крайне небольшом объеме дискового пространства. Но этот процесс приводит к некоторым издержкам, и с технической точки зрения он не является сжатием или даже хранилищем единственной копии (SIS), хотя в процессе участвуют некоторые компоненты, устраняющие дублирование данных, а именно средства отслеживания изменений на уровне блоков. Однако, независимо от его определения, DPM, используя для хранения каждой созданной точки восстановления малый объем внешней памяти, очень хорошо справляется с этой задачей. Еще важнее то, что, поскольку в DPM для выполнения этой задачи не используется традиционное сжатие, хранилище единственной копии или устранение дублирования, остается пространство для увеличения эффективности в том случае, если платформа сжатия, SIS, или устранения дублирования используется для предоставления хранилища серверу DPM.

Восстановление после ошибок без потерь данных и CDP
Возможно, одним из наиболее вдохновляющих изменений в DPM 2007 является его способность выполнять восстановление приложений Майкрософт после ошибок, которое не сопровождается потерями данных. Это стало возможным благодаря отслеживанию изменений на уровне блоков и архитектуре VSS, а также глубокой интеграции с журналами приложений, имеющимися на защищенном сервере.
Говоря обобщенно, на современном рынке существуют два подхода к защите данных и восстановлению после ошибок:
Решения, использующие репликацию Большинство клиентов обычно полагают, что это средства непрерывной защиты данных (CDP — Continuous Data Protection). Защита данных с использованием репликации вызывает перемещение изменений, по мере их возникновения, с защищенного сервера на резервный сервер. Это решение на основе дисков, что означает возможность восстановления после ошибок в любой момент времени и без потерь данных.
Хотя это звучит неотразимо, с этим подходом связано несколько вполне реальных недостатков. Первое и самое главное заключается в том, что в решении с использованием репликации отсутствует концепция состояния приложения, и оно совершенно не учитывает наличия «находящихся в пути» составляющих приложения. Поэтому в нем не очищаются буферы и не учитываются данные, которые в момент архивирования могут находиться в памяти или подвергаться перемещению. Это означает, что точки восстановления после ошибок, созданные с использованием репликации, зачастую не в полной мере согласованы с приложениями. Вы сможете выполнить восстановление, но, фактически, приложение не будет возвращено в работоспособное состояние. Этот недостаток настольно серьезен, что некоторые поставщики средств CDP, основанных на репликации, сообщают в своей документации, что в случае сбоя в работе текущей точки восстановления следует попытаться использовать другую точку.
Помимо этих проблем, относящихся к согласованности с приложением, решения CDP на основе репликации, как правило, отличаются высокой стоимостью, ведут к существенным перегрузкам сети и процессора и требуют больших объемов в хранилище, которое, вполне возможно, располагается на оборудовании, находящемся в частной собственности. Решения для защиты данных на основе репликации не слишком хороши в случае создания архивов или резервных копий на магнитных лентах, находящихся вне предприятия. Большинству клиентов требуются обе эти возможности.
Решения, использующие мгновенные снимки Это традиционный подход к созданию архива на магнитных лентах, в котором мгновенные снимки на определенный момент времени создаются на внешнем носителе, который впоследствии используется для восстановления состояния на определенный момент времени. Целевая точка восстановления (RPO) определяется частотой выполнения мгновенных снимков, поэтому ежедневное архивирование сопровождается потерей данных за 24 часа. Преимуществом мгновенных снимков является их невысокая стоимость, простота управления, ограниченное влияние на работу сети и хорошая приспособленность для создания архивов на дисках и магнитных лентах. Они также близки к созданию образов, согласованных с приложением, поскольку можно подготовить приложение к моменту получения мгновенного снимка, что уменьшает риск утраты компонентов приложения, «находящихся в пути» во время архивирования.
Одним из последних направлений в создании мгновенных снимков являются решения, близкие к CDP. Это решения, использующие мгновенные снимки, в которых увеличивается частота создания снимков, и значение RPO становится очень низким. В настоящее время для некоторых программных продуктов характерны значения RPO, исчисляемые минутами, и мгновенные снимки создаются настолько часто, что они полностью попадают под определение близких к средствам CDP и стали называться программными продуктами CDP. Однако при восстановлении по-прежнему теряются данные, соответствующие интервалу в несколько минут.
DPM 2006, безусловно, находился в лагере близких к CDP средств создания мгновенных снимков, но в DPM 2007 используется уникальный подход к CDP. Новая версия DPM делает мгновенные снимки каждые 15 минут, используя VSS и его технологию отслеживания изменений на уровне блоков с целью переноса из мгновенного снимка VSS на защищенный сервер только измененных данных. В результате отдельные мгновенные снимки на определенный момент времени имеют крайне небольшой размер, поскольку они содержат только изменения на уровне блоков. По существу, это самый совершенный подход к использованию мгновенных снимков. Нововведением в DPM является глубокая интеграция приложений для Exchange, SQL и SharePoint. Это сделано на таком глубоком уровне, что у DPM имеется информация о журналах приложений, и он в состоянии выполнить накат этих журналов в случае восстановления после ошибки. До тех пор, пока доступны журналы приложений (это обеспечивается при следовании оптимальным методикам и размещении журналов на отдельном носителе), DPM будет в состоянии выполнить их накат из последнего мгновенного снимка на определенный момент времени и обеспечить восстановление без потерь (см. Figure 3).
Figure 3 Recovery options in the Data Protection Manager Administrator Console
Figure 3 Recovery options in the Data Protection Manager Administrator Console
Во многих отношениях такой смешанный подход к CDP является лучшим по сравнению с обоими исходными. В нем обеспечивается поддержка согласованности приложения и долговременного архива, характерная для решения с использованием мгновенных снимков, наряду с отсутствием потерь данных, свойственным продуктам на основе репликации. Кроме этого, отсутствуют многие из недостатков обоих решений.

Поддержка архивирования с использованием дисков и магнитных лент
Обсуждение новых возможностей DPM 2007 было бы неполным без упоминания о добавленной в продукт поддержки магнитных лент. DPM 2006 поддерживал только архивирование типа диск-диск (D2D), при котором данные перемещаются с диска защищенного сервера на диск сервера DPM. В DPM 2007 включена поддержка как дисковых носителей, так и носителей на магнитных лентах. Следовательно, данные можно перемещать с диска защищенного сервера на диск, подключенный к серверу DPM (D2D), на магнитную ленту, подключенную к серверу DPM (D2T), или можно защищенные данные разместить на диске сервера DPM перед их перемещением на магнитную ленту для длительного хранения (D2D2T).
DPM 2007 поддерживает широкий набор библиотек и автозагрузчиков для магнитных лент, а также широкий набор типов накопителей на магнитных лентах.
Поддержка магнитных лент в DPM включает в себя множество усовершенствованных функций, таких как программное шифрование для накопителя на магнитной ленте, не требующее дополнительных затрат, а также базовое управление ключом шифрования и отслеживание хранения на магнитной ленте и местоположения ленты.

Заключение
В статье были подробно рассмотрены несколько новых компонентов и усовершенствований, появившихся в System Center Data Protection Manger 2007. Эти компоненты разработаны с целью обеспечения согласованности, надежности и удобства управления защитой данных для платформ и приложений Майкрософт. Они задают новый стандарт защиты данных в приложениях и платформах Windows.
Помимо компонентов, описанных в этой статье, в программный продукт внесено много других усовершенствований, например, внедренное в Windows восстановление данных конечного пользователя, гибкая регулировка полосы пропускания и усовершенствованный интерфейс командной строки. Я призываю вас загрузить вторую бета-версию Data Protection Manager 2007, чтобы ознакомиться с работой этих и других компонентов. Для получения дополнительных сведений и обзора всех программных продуктов семейства System Center посетите веб-узел по адресу microsoft.com/systemcenter. На нем предусмотрен переход к любому решению семейства System Center, включая диспетчер защиты данных.

Кэлвин Китон в настоящее время является специалистом по планированию программного продукта DPM. Ранее он руководил подразделением Майкрософт, занимающимся защитой компьютерных данных. До прихода в корпорацию Майкрософт Кэлвин в течение шести лет занимался технологическими процедурами и оборудованием центра обработки данных, включая управление группами, эксплуатирующими узлы центра данных для Compaq и впоследствии HP Services.


 Системный центр: Интерактивные службы позволяют упростить инвентаризацию программного обеспечения
Системный центр Пол Буржо (Paul Bourgeau)

Интерактивные службы позволяют упростить инвентаризацию программного обеспечения
Краткий обзор:
  • Основы интерактивных служб
  • Настройка агента инвентаризации
  • Получение отчетов инвентаризации

Финансовый директор вашей компании отправил вам простое сообщение электронной почты с «небольшой просьбой»: ему необходима полная инвентаризация компьютеров в вашей компании, включая сведения о местонахождении компьютеров и о
программном обеспечении, установленном на каждом компьютере. К концу недели. Это необходимо по следующей причине (выберите одну или несколько).
  • Пришло время планирования бюджета на следующий год, и необходимо определить размеры средств, выделяемых на лицензирование программного обеспечения.
  • Было получено уведомление аудита программного обеспечения, и теперь необходимо подтвердить соответствие требованиям, предоставив сведения о достаточном количестве лицензий определенного продукта.
  • Генеральный директор дал указание снизить расходы на информационную инфраструктуру, и он полагает, что стандартизация приложений является одним из способов достижения этой цели.
Что же вам делать?
Управление информационно-техническими активами развивалось в течение последних десяти лет, и сейчас организации основное внимание стали уделять эффективному управлению программными активами. Основной причиной этого является то, что теперь программное обеспечение является значительно большим капиталовложением, чем раньше, кроме того, необходимо уделять внимание растущим проблемам, связанным с безопасностью, политиками и юридическими вопросами. Возможность признания несоответствия требованиям и необходимость уплаты больших платежей или штрафов по принципу «true-up» еще больше увеличили потребность в точном управлении лицензиями.
В больших организациях обычно используются средства и ресурсы для управления программным обеспечением. Эти средства часто являются большими комплексными решениями, предназначенными не только для отслеживания аппаратных и программных ресурсов, но также для управления установкой программного обеспечения на рабочие станции, наблюдения за производительностью и других производственных функций. Что же остается организациям, которые не могут использовать подобные решения или у которых отсутствуют ресурсы и опыт для реализации таких сложных решений и управления ими?
Соответствие потребностям как крупного, так и малого бизнеса было одной из основных идей концепции «программа как служба» (SaaS). Стратегия «Программные продукты плюс службы» (Software plus Services) корпорации Майкрософт объединяет усилия по разработке решений на основе услуг для эффективного управления программными активами. Одна из первых таких служб, Microsoft® Asset Inventory Service, будет выпущена для клиентов программы Software Assurance как часть набора Desktop Optimization Pack for Software Assurance в этом году.
Служба Asset Inventory Service (AIS), показанная на рис. 1, является простой в развертывании и использовании размещенной службой для сбора сведений о программном обеспечении, установленном на компьютерах организации. Доступ к этим сведениям осуществляется с помощью отчетов через обозреватель, а в следующую версию службы планируется включить возможность анализа развертывания корпоративных лицензионных соглашений Майкрософт.
Рис. 1 Microsoft Asset Inventory Service
Рис. 1 Microsoft Asset Inventory Service

Природа интерактивных служб
Каковы причины использования интерактивного решения? Существует несколько веских причин, включая немедленную доступность обновлений и новых версий, простоту внедрения и уменьшение затрат на развертывание и управление.
Интерактивные службы являются динамическими: как и веб-страница, содержимое и функциональные возможности могут постоянно обновляться поставщиками для улучшения взаимодействия с пользователем и отражения текущих изменений в области технологии. Это обеспечивает исключительный уровень гибкости и позволяет поставщикам программного обеспечения предоставлять самые современные функции, решения и знания, позволяющие администраторам осуществлять управление настольными системами с гораздо большим опережением событий.
Преимуществом интерактивных служб является повсеместная доступность. Современные информационно-технические среды могут быть различными, от полностью сетевых компьютеров с непосредственным подключением к сетевым ресурсам до удаленных пользователей и филиалов с доступом к ресурсам через Интернет из самых различных мест. Добавьте сюда мобильных пользователей, которые почти всегда подключаются к вашей сети через почтовые программы с веб-интерфейсом, и полная инвентаризация информационно-технических активов вашей компании становится очень трудной задачей. Это исторически является основной проблемой средств инвентаризации, в особенности локальных решений, в которых отсутствовала поддержка удаленных/не сетевых случаев.
Однако на большинстве, если не на всех ваших компьютерах имеется возможность подключения к Интернету, поэтому для управления ими можно использовать интерактивные службы без реализации специальных мер для обеспечения доступа к собственным решениям клиент-сервер. Доступ к службе для осуществления функций управления осуществляется через безопасное подключение к Интернету, поэтому управление компьютерами с помощью вашей управляемой учетной записи может осуществляться из любого места с доступом к Интернету.
Развертывание осуществляется очень просто, для начала работы необходимо только создать учетную запись в интерактивной системе. Вам не понадобятся серверы для вашей среды и инвестиции в новую сетевую инфраструктуру и программные платформы. Все это означает снижение капиталовложений и административных расходов. Техническая поддержка также упрощается, поскольку организации не нужно беспокоиться об обслуживании и обновлении, так как новые версии службы теперь являются частью соглашения об обслуживании.

Использование службы
Содействие развитию сетевого сообщества
Службы Asset Inventory Service и System Center Online содействуют развитию успешного сообщества пользователей, которые могут повлиять на эволюцию интерактивных служб. Каталог программного обеспечения (в стиле вики) – это отличный пример того, чему может способствовать сообщество пользователей; пользователи службы могут предлагать предложения, исправления и давать советы.
В будущем сам каталог также может стать ценным источником сведений для конечных пользователей, изучащих варианты приобретения программного обеспечения. В службе может быть собрано множество анонимных статистических данных для определения темпов внедрения программного обеспечения и оборудования; собранные сведения будут полезны для конечных пользователей, участвующих в этой работе.
Сообщество также будет определять общую направленность службы, предоставляя отзывы о приоритете областей для решения определенных потребностей бизнеса.

Для предоставления интерактивных служб управления настольными системами группа Microsoft System Center Online занимается расширением платформы, которая будет не только кратковременно поддерживать службу Asset Inventory Service, но также и будущие службы. Служба разработана с учетом безопасности, масштабируемости и надежности. AIS – это полное размещенное решение, все серверы которого находятся в компьютерных центрах корпорации Майкрософт. Для развертывания решения клиентам необходимо установить небольшую программу на всех клиентских компьютерах, которые должны быть включены в управляемую инвентаризацию.
Управление службой Asset Inventory Service осуществляют специалисты, отвечающие за работу веб-узла Microsoft.com. Это веб-приложение с несколькими владельцами, использующее веб-службы для обеспечения конфиденциальности и безопасности данных отдельных пользователей; для хранения данных клиентов используется сочетание клиентских и веб-приложений. Агенты, работающие на узле клиента, загружают опись программного обеспечения в веб-службу IIS Microsoft. SSL со взаимной проверкой подлинности защищает данные клиентов, связь между клиентом и службой и веб-узел AIS; для целей хранения на узле используется сервер SQL Server™.
Вход пользователей в службу для управления учетными записями и просмотра отчетов осуществляется с помощью учетных записей Windows Live™ ID. На веб-узле клиента также используется SSL для защиты данных клиента, а для создания отчетов используются службы отчетов SQL Server. Базы данных SQL Server зеркалированы, а для высокой доступности веб-узлов используется балансировка нагрузки. Кроме того, для обеспечения еще большей доступности данные инвентаризации разделены на масштабируемые блоки.
Подписка на службу Asset Inventory Service осуществляется путем приобретения лицензий на набор Microsoft Desktop Optimization Pack по вашему корпоративному лицензионному соглашению Microsoft. Затем можно активировать подписку на службу Asset Inventory Service на веб-узле Microsoft Volume Licensing services по адресу licensing.microsoft.com. Для успешной проверки подлинности и регистрации в службе AIS необходимо действительное удостоверение Windows Live ID.
Во время активации администратор лицензий назначает администратора подписки Asset Inventory Service, указывая удостоверение Windows Live ID. Администоратор подписки регистрируется в службе AIS с помощью удостоверения Windows Live ID и завершает процесс активации службы AIS. После этого администратор может добавлять к службе других пользователей, указывая их удостоверения Windows Live ID.

Агент инвентаризации
Клиент, установленный на всех компьютерах, – это простой в развертывании агент небольшого размера, упакованный как пакет установщика Windows® (MSI). Загрузка установщика агента и управление развертыванием клиента осуществляются из интерактивной службы. (На рис. 2 показан интерфейс управления и поддержки.) Работа агента сходна с работой агента обновления Windows в том, что он так же регулярно связываеится с серверами System Center Online. Целью этого является обновление профиля инвентаризации с определенной частотой и самостоятельное обновление при наличии новой версии агента.
Рис. 2 Управление учетной записью и развертывание клиента
Рис. 2 Управление учетной записью и развертывание клиента
Планируется автоматический запуск инвентаризации, вмешательство пользователя не требуется. Также доступна возможность запуска инвентаризации вручную в случае такой необходимости. При первом обращении агента к службе используются учетные данные сертификата инфраструктуры открытых ключей (PKI) для предоставления идентификатора пользователя службе и создания уникального идентификатора для компьютера, на котором выполняется агент. Сам агент, запускаемый только по расписанию, не требует вмешательства пользователя, поэтому для него требуется минимальное количество ресурсов, и он работает в фоновом режиме. Размер загружаемых файлов невелик, чтобы не вызвать «всплески» сетевого трафика.
Сам процесс инвентаризации является простым и эффективным. Агент выполняет поиск информации об установке в записях реестра, базе данных MSI и других источниках в отличие от традиционных систем управления, снижающих производительность пользователей, выполняя поиск и разрешение всех исполняемых файлов на компьютере. Этот процесс возвращает данные инвентаризации программного обеспечения с понятными именами и метаданными для определения и классификации элементов, чтобы они могли использоваться в различных действиях по управлению лицензиями.

Службы отчетов
После загрузки данных инвентаризации выполняется процесс их идентификации и каталогизации для подготовки к отображению данных в отчетах. Данные инвентаризации сопоставляются с центральным каталогом программного обеспечения, в котором выполняется распределение данных по категориям. Это одна из самых важных возможностей службы: данные инвентаризации всех клиентов предоставляют центральному каталогу программного обеспечения уникальные сигнатуры. Группа разработчиков корпорации Майкрософт проверяет неконфиденциальные и неклассифицированные сигнатуры программного обеспечения и, используя структурированную таксономию категорий и семейств программного обеспечения, классифицирует приложения, представляемые сигнатурами, в соответствии с их типом и функциями. Целью этих категорий является предоставление отчетов более высокого уровня осведомленности, что позволит пользователям быстро выбирать нужные типы программного обеспечения, например, только антивирусные приложения.
Сигнатуры программного обеспечения также используются для консолидации отображаемых в отчетах данных. Например, может существовать ряд версий названия издателя — одно приложение может сообщить название издателя как Contoso Software, а другое – как Contoso, поэтому в отчете могут присутствовать два названия. Консолидация названий издателей и приложений улучшает точность отчетов по этим критериям и значимость отображаемых данных.
После отбора пользователем нужного набора данных с помощью фильтров и групп содержимое отчета может быть экспортировано в различные поддерживаемые форматы с помощью службы отчетов SQL Server, включая файлы CSV, документы Microsoft Word, таблицы Microsoft Excel® и файлы PDF (см. рис. 3). Это позволяет произвести дополнительный внешний анализ и обработку или использовать отчет в качестве входных данных для других систем управления предприятия.
Рис. 3 Отчет по инвентаризации
Рис. 3 Отчет по инвентаризации
Будущая функция службы улучшит способ обработки лицензий Microsoft, значительно упрощая этот процесс для пользователей. Пользователям будет предоставлена возможность загрузки пар корпоративных лицензионных соглашений, которые затем будут использоваться для получения сведений о видах лицензий из хранилища сведений о лицензиях клиентов Microsoft. Затем эти данные о лицензионных правах будут использованы для создания отчета, в котором будут содержаться сведения о всем установленном лицензируемом программном обеспечении Microsoft и количестве соответствующих лицензий.
С помощью идентификатора продукта, который также получается во время инвентаризации, установленное программное обеспечение может быть классифицировано по каналу: корпоративная лицензия, розничная лицензия и лицензия для изготовителей олборудования. Эту функцию планируется включить в следующую версию службы Asset Inventory Service.

Перспективы
Служба Asset Inventory Service – это первый продукт System Center Online, но ни в коем случае не последний. Как упомяналось ранее, группа System Center Online имеет долгосрочную цель предоставления всеобъемлющих служб управления настольными системами, полностью доступных в качестве интерактивных услуг.
В настоящий момент возможные продукты, выпуск которых рассматривается, включают в себя управление информационно-техническими активами для инвентаризации и отслеживания оборудования и программного обеспечения, распространение и выпуск программного обеспечения с предоставлением возможностей, сходных с возможностями служб обновления программного обеспечения Windows через Интернет, а также гибридные интерактивные/локальные службы. Кроме того, изучается возможность работы в этом типе ситуации других служб управления настольными системами.
Для получения дополнительных сведений о службе Microsoft Asset Inventory Service загляните на веб-узел microsoft.com/windows/products/windowsvista/enterprise/ais.mspx.

Пол Буржо (Paul Bourgeau) работает руководителем программы в группе System Center Online, присоединенной к корпорации Майкрософт в результате приобретения компании Assetmetrix.


 Групповая политика: Шаблоны ADM и ADMX для групповой политики
Групповая политика Джереми Московиц

Шаблоны ADM и ADMX для групповой политики
Краткий обзор:
  • Типы шаблонов групповой политики.
  • Допустимые и недопустимые разделы политики.
  • Просмотр шаблонов ADM.
  • Преобразоывание ADM в ADMX.

Файлы ADM. Иногда они вызывают любовь, иногда ненависть. А иногда и то, и другое. А все из-за того, что применять AMD сложно, но без них никуда. Теперь появились еще и файлы ADMX — это новый формат, который, на первый взгляд, только запутывает дело. Похоже, пришло время пролить свет на эту туманную область.

Зачем нужны файлы ADM?
Групповая политика охватывает ряд различных объектов. Если вы загляните в редактор объектов групповой политики, вы найдете в нем множество штуковин — это то, что умеет групповая политика. Например, в нем есть политика программных ограничений, групповая политика установки программ, перенаправление папок и, кстати, административные шаблоны — их мы используем чаще всего. Узел административных шаблонов существует и в части пользователей, и в части компьютера. Как вы, наверное, догадались, параметры политик, указанные на стороне пользователя, относятся к пользователям, а на стороне компьютера — к компьютеру.
Откуда берутся все эти чудные параметры административных шаблонов? В момент создания нового поколения существует несколько параметров, которыми теоретически можно управлять. Вот тут на сцену и выходят файлы ADM. Они описывают те области приложения, которые могут использовать параметры, задаваемые администратором. К сожалению, файлы ADM ограничиваются лишь параметрами реестра для конкретного приложения, а приложение может сохранять параметры не только в реестре: в файлах INI, JS, XML, в базах данных.

Готовые файлы ADM
Откуда вообще берутся готовые политики для административных шаблонов в конфигурации компьютера и конфигурации пользователей? Если щелкнуть правой кнопкой мыши сслыку «Административные шаблоны» в редакторе объектов и выбрать пункт «Добавление и удаление шаблонов» либо на стороне компьютера, либо на стороне пользователя, вы увидите стандартные шаблоны, на основе которых создается стандартная конфигурация (как показано на рис. 1).
Рис. 1 Административные шаблоны по умолчанию
Рис. 1 Административные шаблоны по умолчанию
Схема файлов следующая:
  • Conf.adm — параметры NetMeeting®.
  • Inetres.adm — параметры Internet Explorer®, в том числе подключения, панели инструментов и параметры панелей. Это те же настройки, к которым можно получить доступ через пункт меню «Свойства обозревателя» в Internet Explorer.
  • System.adm — изменения и параметры операционной системы. Большая часть параметров административных шаблонов компьютера и пользователей содержится в этом шаблоне ADM.
  • Wmplayer.adm — параметры проигрывателя Windows Media® 9.
  • Wuau.adm — управление доступом клиентов к серверам служб обновления Windows® и Windows Server®.

Добавление нового файла шаблона ADM
Преодоление ограничений при помощи средств Майкрософт и сторонних разработчиков
Файлы ADM и ADMX невероятно полезны. С их помощью вы можете упаковать ту или иную информацию в файл определения и контролировать целевые приложения. Но и для файлов ADM и ADMX существуют ограничения, связанные со следующими действиями:
  • Они могут обращаться только к кустам реестра, расположенным в разделах HKEY_LOCAL_MACHINE и HKEY_Current_User. Если вам что-то нужно от других кустов реестра, файлы ADM и ADMX вам не помогут.
  • Они не могут ничего добавлять в значения раздела REG_Binary.
  • Их нельзя настроить так, чтобы они применялись лишь однажды.
  • Их нельзя настроить так, чтобы они всегда применялись повторно при обновлении групповой политики.
  • Если файлы ADM и ADMX что-то записывают в недопустимые разделы, эти изменения остаются в реестре навсегда. То есть, даже если пользователь выдет из области управления или объект групповой политики будет удален, значение все равно сохранится.
Указанные ограничения можно преодолеть. У Майкрософт и у некоторых других разработчиков существуют решения, призванные помочь вам в этом. Корпорация Майкрософт недавно приобрела DesktopStandard и выпустила новую версию расширения DesktopStandard Registry Extension — уже под новой маркой. Это средство при помощи мастера для редактора объектов позволит вам указать, какими именно значениями реестра вы намерены управлять на данной конкретной машине.
Технологии DesktopStandard PolicyMaker (к которым относится и средство Registry Extension) теперь существуют под названием Group Policy Preferences (предпочтения групповых политик). Они включены в систему Windows Server 2008. Предпочтения групповых политик позволяют администратору настраивать приложения и компоненты Windows, которые обычно с помощью групповой политики не настраиваются, а также применять их к группам пользователей или компьютеров на основании разнообразнейших правил выбора целевых объектов. Новое средство полностью интегрировано в консоль управления групповыми политиками и в модуль расширенного управления групповыми политиками в Windows Server 2008.
Подробнее узнать о предпочтениях групповых политик вы можете в статье Дерека Мелбера (Derek Melber) «Погружение в управление групповыми политиками», опубликованной в этом выпуске журнала TechNet Magazine.

Делается это совершенно просто. Нужно взять шаблон ADM, который вы хотите использовать. Млжно загрузить один из шаблонов, размещенных на веб-узле GPanswers.com (там немало интересных примеров), или ADM-файл для Office 2003 или Office 2007 на веб-узле Майкрософт.
Щелкните правой кнопкой мыши ссылку «Административные шаблоны» и выберите пункт «Добавить», как показано на рис. 1. По умолчанию Windows ищет шаблоны в каталоге \Windows\inf, но это не означает, что в другом месте их хранить нельзя. Учтите следующий момент: как только шаблон ADM будет добавлен из исходного хранилища, он добавляется в сам объект групповой политики.
Например, когда я писал эту статью, я зашел на веб-узел GPanswers.com и загрузил файл nopassport.adm. Я сохранил его в папке c:\temp. Этот шаблон ADM позволяет убрать вопрос о добавлении паспорта, который появляется при первом входе пользователя в Windows XP.
Еще я загрузил шаблоны ADM для Office 2003 и сохранил их там же, в папке c:\temp. Но я их там не оставил. На рис. 2 показано, что я добавил шаблоны nopassport.adm и Word11.adm. Они появились в списке стандартных шаблонов в окне «Добавление и удаление шаблонов».
Figure 2 Additional ADM files in the GPO
Figure 2 Additional ADM files in the GPO
Теперь взгляните на файлы, относящиеся к самому объекту групповой политики (они лежат в папке \\domaincontroller\SYSVOL\domainname\Policies\GUID\ADM). Как вы вилите, теперь шаблоны nopassport.adm и Word11.adm являются частью объекта групповой политики (см. рис. 2).
Зачем шаблоны добавляются в объект групповой политики? Делается это для того, чтобы параметры, содержащиеся в этих файлах, были видны, если вы решите изменить объект групповой политики в другой системе управления.

Почему загруженные файлы не видны?
Иногда добавленные файлы ADM видны, иногда нет. Такое поведение нередко приводит администраторов в растерянность. На веб-узле GPanswers.com этот вопрос задают очень часто, так что давайте прямо сейчас все и проясним.
По крайней мере, результаты добавления двух файлов, которые мы рассматривали выше, вы должны видеть (см. рис. 3). Появляются два новых узла: узел Nuisances в конфигурации компьютера (его добавляет файл nopassport.adm) и узел Microsoft Office Word 2003 в конфигурации пользователя (его добавляет файл Word11.adm). Если как следует покопаться в параметрах Microsoft® Word 2003, вы обнаружите довольно большое число настраиваемых величин — они показаны на рис. 3.
Рис. 3 Настраиваемые параметры групповой политики
Рис. 3 Настраиваемые параметры групповой политики
Так почему же их нет в узле Nuisances? Чтобы это понять, нужно сначала разобраться, что такое «допустимые» и «недопустимые» разделы политики с точки зрения шаблонов ADM.

Допустимые и недопустимые разделы политики
Согласно документации Майкрософт, существуют четыре утвержденных области реестра, в которых можно создавать политики на основании взломов реестра:
  • HKLM\Software\Policies (параметры компьютера, предпочтительный раздел);
  • HKLM\Software\Microsoft\Windows\CurrentVersion\Policies (параметры компьютера, альтернативный раздел);
  • HKCU\Software\Policies (параметры пользователя, предпочтительный раздел);
  • HKCU\Software\Microsoft\Windows\CurrentVersion\Policies (параметры пользователя, альтернативный раздел).
Параметры, содержащиеся в файле ADM для Word 2003, записываются как раз в эти разделы, а вот параметры из файла nopassport.adm — нет. Они записываются в раздел HKLM\Software\Microsoft\MessengerService\PassportBalloon.
Редактор объектов групповой политики предпочитает перестраховаться и не сразу делает эти параметры видимыми, поскольку они записаны в недопустимый раздел политики, а вносимые изменения останутся в реестре навсегда. Даже если вы угрохаете объект групповой политики, отменить изменения не получится. Возьмем, к примеру, такую ситуацию. Вы добавили файл nopassport.adm и решили, что вопрос о добавлении паспорта не должен задаваться ни на одном компьютере в вашем домене. А потом ваш начальник ненароком заметил, что именно этот вопрос его особенно радовал. Вот тут-то вам придется повозиться, прежде чем вы вернете эту настройку к прежнему виду, потому что вы отменили подсказку на всех компьютерах — и в общем случае это делается навсегда. Конечно, можно создать новый файл ADM, который вернет подсказку обратно, но на это тоже уйдет немало сил.
Обычные же параметры политики, напротив, имеют значения, используемые по умолчанию. Если уничтожить объект групповой политики, для таких параметров будут восстановлены стандартные значения. Например, если вы запретите доступ к панели управления при помощи встроенных шаблонов ADM, а потом передумаете, вам нужно будет просто удалить соответствующий объект групповой политики — и панель управления вернется. Это относится практически ко всем параметрам, содержащимся в стандартных шаблонах ADM (за редким исключением).
Еще раз напомню, что в случае с вопросом о паспорте групповой политике не удавалось восстановить прежнюю конфигурацию после удаления объекта, потому что параметры из файла ADM были сохранены в недопустимом разделе. Майкрософт позаботился о том, чтобы вы не подпилили сук, на котором сидите, — не рванули использовать подобные параметры, изменяющие реестр навсегда.

Просмотр шаблонов ADM
Итак, увидеть шаблон совсем не сложно. По умолчанию редактор не показывает параметры, но это можно исправить. Щелкните ссылку «Административные шаблоны» (либо в части компьютера, либо в части пользователей) и выберите «Вид» > «Фильтрация». Наконец, снимите (все верно, снимите) флажок «Показывать только управляемые парметры политики» (см. рис. 4). Когда вы это сделаете, в столбце «Парметр» появится строчка Passport Solicitation (запрос паспорта) — она тоже есть на рис. 4.
Рис. 4 Фильтрация GPO
Рис. 4 Фильтрация GPO

Работа с редактором в Windows XP и в Windows Vista
Вы заметили небольшое отличие только что появившегося параметра политики? Взгляните на значки параметров, содержащихся в стандартных файлах ADM, показанные на рис. 5. А теперь на значок параметра шаблона ADM, вносящего изменения в недопустимый раздел политики в реестре на рис. 6.
Рис. 5 ADM-файлы со значками
Рис. 5 ADM-файлы со значками
Рис. 6 Значки для недопустимого использования реестра
Рис. 6 Значки для недопустимого использования реестра
По синим и красным значкам можно отличить параметр, вносящий обратимые изменения, от параметра, вносящего изменения в реестр навсегда. Но это, опять же, зависит от того, куда записывается параметр.
В Windows Vista®, надо сказать, ситуация несколько меняется, если использовать файлы ADM в управляющей станции Windows Vista. В таком случае файлы ADM добавляются в отдельный узел под названием «Классические административные шаблоны (ADM)», как показано на рис. 7. Параметры, которые раньше отмечались красной точкой, теперь обозначаются свитком со стрелкой вниз (а во время редактирования самого параметра у него стоит маленький значок «Вход воспрещен»).
Рис. 7 Узел классических административных шаблонов
Рис. 7 Узел классических административных шаблонов
Параметры, которые раньше отмечались синей точкой (то есть те, которые записывались в допустимые разделы политики) обозначаются просто маленьким свитком, как показано на рис. 8.
Рис. 8 Значки промотки с действительными реестрами
Рис. 8 Значки промотки с действительными реестрами

А что за шумиха вокруг ADMX?
И Windows Vista, и Windows Server 2003 включают встроенную консоль управления групповами политиками. А она, в свою очередь, включает в себя новую возможность — возможность избавиться от старых файлов ADM и перейти на файлы ADMX, если вам так удобнее. Зачем это нужно?
Давайте вспомним, что файл ADM помещается в шаблон групповой политики, который является частью объекта групповой политики (эта часть хранится в SYSVOL). Когда это происходит, вы теряете примерно 4 МБ на каждом контроллере домена при каждом создании объекта групповой политики. Также вспомним, что файл ADM размещается в шаблон групповой политики, потому что это необходимо на случай попытки отредактировать объект политики на другой управляющей станции. Если файла ADM в нем не будет, вы не сможете изменить параметры, содержащиеся в ADM.
Формат ADMX позволяет избежать всех этих неприятностей. В объекты групповой политики напрямую ничего не записывается, поэтому проблема «раздутого SYSVOL», которому приходится хранить в себе объекты групповой политики, кучу файлов ADM, да еще и выполнять репликацию на все контроллеры домена, отпадает сама собой. Для этого стандарт ADMX использует преимущества так называемого центрального хранилища. Задача его состоит в том, чтобы предоставить единое место хранения новых файлов ADMX — тогда их не придется копировать в каждый объект групповой политики. Прощай, раздутый SYSVOL. Пока-пока! Еще один плюс центрального состоит в том, что если в одном из файлов ADMX обновляется определение, все управляющие станции Windows Vista незамедлительно начинают использовать обновленный ADMX.
Если вам хочется побольше узнать о файлах ADMX, и в частности о создании и использовании центрального хранилища, могу предложить вам два источника. Во-первых, это подробная статья Даррена Мар-Элиа (Darren Mar-Elia) в февральском выпуске журнала Technet Magazine за 2007 г. (technetmagazine.com/issues/2007/02/Templates), в которой он рассматривает формат ADMX и дает краткое разъяснение по поводу центрального хранилища. Во-вторых, можно загрузить целую главу из моей будущей книги под названием «Групповая политика: управление, устранение неполадок и безопасность». Она есть в разделе Book Resources (книги) на веб-узле GPanswers.com.
Как я уже упоминал, шаблоны ADM по-прежнему поддерживаются управляющими станциями Windows Vista, но вот центральное хранилище использовать для них не получится. Это порой может сбить с толку, так что рассмотрим подробнее один пример.
Допустим, я создал объект групповой политики в управляющей станции Windows Vista, а затем настроил некоторые стандартные параметры (скажем, запретил доступ к панели управления). Затем я добавил свой собственный шаблон ADM. Теперь заглянем в шаблон объекта групповой политики и попробуем разобраться в том, что произошло.
Чтобы добавить шаблон ADM, вы можете повторить действия, которые я выполнял чуть ранее. Откройте редактор объектов групповой политики, щелкните правой кнопкой мыши ссылку «Административные шаблоны» для компьютера или пользователя и выберите пункт «Добавление и удаление шаблонов». Добавленный шаблон показан на рис. 9.
Рис. 9 Просмотр добавленного шаблона
Рис. 9 Просмотр добавленного шаблона
Чтобы увидеть параметры, содержащиеся в нашем шаблоне ADM, нужно проделать то, что показано на рис. 4. То есть, щелкнуть «Просмотр» > «Фильтрация» и снять флажок «Показывать только управляемые парметры политики». После этого нужно закрыть редактор объектов и вернуться в консоль управления групповыми политиками. На рис. 10 показана вкладка свойств объекта, который я только что создал в управляющей станции Windows Vista. (Смотрите, какое удобное имя я ему придумал!) На вкладке всойств можно узнать идентификатор GUID для данного объекта групповой политики — это упростит его поиск в SYSVOL.
Рис. 10 Административные шаблоны по умолчанию
Рис. 10 Административные шаблоны по умолчанию
Найдя (по идентификатору GUID) шаблон групповой политики, соответствующий моему объекту, я могу вскрыть папку с файлами ADM для данного объекта групповой политики. Сделав это, я обнаруживаю, что в ней есть ровно один шаблон ADM — тот самый, который я импортировал вручную ( см. рис. 11). Причина этого в том, что машины под управлением Windows Vista не зависят от ADM. Поскольку они изначатьно не используют ADM, они ничего в объект групповой политики по умолчанию не добавляют. Впрочем, если импортировать ADM вручную (как мы и сделали), он будет применяться точно так же, как применялся в предыдущих версиях Windows.
Рис. 11 ADM-файл, испортированный вручную
Рис. 11 ADM-файл, испортированный вручную
Описанное выше поведение коренным образом отличается от, скажем, поведения объекта, показанного на рис. 12, который создавался в Windows XP или Windows Server 2003. Если объекты групповой политики создаются в управляющих станциях версий Windows, предшествующих Windows Vista, исходные файлы ADM добавляются в объекты групповой политики, как я описывал выше. Приведенный здесь объект создан в управляющей станции Windows XP. Это можно определить по обилию файлов ADM, которые Windows Vista не использует за ненадобностью.
Рис. 12 GPO, созданный в Windows XP
Рис. 12 GPO, созданный в Windows XP

Преобразоывание ADM в ADMX с помощью средства ADMX Migrator
Итак, в Windows XP используются файлы ADM, а в Windows Vista — файлы ADMX (хотя ADM поддерживается — на случай, если ничего другого под руками нет). Однако мы не можем записывать файлы ADM в центральное хранилище: управляющие странции Windows Vista так их использовать не будут.
Чтобы иметь возможность применять параметры, содержащиеся в файлах ADM, лежащих в центральном хранилище, необходимо преобразовать файлы ADM в ADMX или создать их аналоги в формате AMDX. К счастью, существует программа, которая выполняет оба действия. Это средство ADMX Migrator (которое фактически состоит из двух частей, одна из которых преобразует ADM в ADMX, а вторая — создает ADMX). Его можно загрузить на веб-узле go.microsoft.com/fwlink/?LinkId=103774.
Средство ADMX Migrator устанавливается на Windows Server 2003, Windows XP и Windows Vista. Установленные приложения лежат в папке C:\Program Files\FullArmor\ADMX Migrator. Программа командной строки, которой я воспользуюсь, называется faAdmxConv.exe. Поскольку папка, в которой установлена программа, к числу стандартных путей не относится, нам придется переходить в нее, и только после этого мы сможем запустить приложение, поэтому, когда я его использую, я добавляю папку приложения в набор путей Windows. Как это сделать, описано в статье на странице www.computerhope.com/issues/ch000549.htm.
Обычно я создаю временный каталог, к примеру C:\ADMtemp, и копирую в него исходные файлы ADM. В программе faAdmxConv.exe есть множество параметров. Самый простой способ преобразовывать файл ADM — задать его имя и указать папку, в которой будет сохранен новый файл. Если вы уже сложили исходный файл ADM в папку ADMtemp и добавили faAdmxConv.exe в список путей, вы можете просто запустить команду faAdmxConv nopassport.adm . (точка в конце означает, что новый файл будет создан в том же каталоге). Если вы не поставите точку и не укажете каталог для нового файла явным образом, он будет создан во временной папке в профиле вашей учетной записи. На рис. 13 показаны три команды:
Рис. 13 Средство переноса ADMX
Рис. 13 Средство переноса ADMX
  • команда dir — для просмотра файла ADM;
  • команда faAdmxConv с именем файла ADM и с точкой, означающей текущий каталог;
  • команда dir для просмотра файлов, полученные в результате преобразоывания: nopassport.admx и nopassport.adml.
Прежде чем копировать полученные файлы в центральное хранилище, попробуйте протестировать их на компьютере, отключенном от сети. Перейдите в автономный режим, скопируйте файл ADMX в папку C:\Windows\PolicyDefinitions, файл ADML — в каталог соответствующего языка. В США это будет папка C:\Windows\PolicyDefinitions\en-us. Пример процедуры копирования приведен на рис. 14.
Рис. 14 Копирование ADMX-файлов в центральное хранилище
Рис. 14 Копирование ADMX-файлов в центральное хранилище
Средство преобразования ADM в ADMX недавно обновили до версии 1.2. В ней было исправлено несколько ошибок, происходящих при преобразоывании, и добавлено несколько полезных предупредительных сообщений. Если когда-то вы пытались использовать средство преобразоывания, но из-за какой-то ошибки забросили это дело, обязательно испытайте версию 1.2.
Наконец, обратите внимание, что файл ADM фактически преобразовывается в два файла: файл ADMX (не зависящий от языка) и файл ADML (зависящий от языка системы). После этого вы можете либо отправить их в центральное хранилище, либо протестировать на локальной машине. Как бы там ни было, чтобы увидеть параметры, содержащиеся в шаблоне ADMX, вам все равно придется проделать то, что показано на рис. 4. То есть, выбрать пункт «Просмотр» > «Фильтрация» и снять флажок «Показывать только управляемые параметры политики». Это связано с тем, что параметры, содержащиеся в файле ADMX, записываются в недопустимый раздел политики.

Подведем итоги
В идеальном случае, конечно, нужно использовать только файлы ADMX и задействовать центральное хранилище. Однако для этого придется преобразовать все имеющиеся файлы ADM, перевести все управляющие станции на Windows Vista (или Windows Server 2008) и условиться не редактировать объекты групповой политики в предыдущих версиях Windows.
Если вы все это сделаете, вы практически избавитесь от файлов ADM. Пока что файлы ADM в объектах групповой политики лишь занимают лишнее место в SYSVOL на контроллерах доменов. Когда вы достигнете нирваны под названием ADMX, вы сможете просто удалить файлы ADM из шаблонов объектов групповой политики, лежащих в SYSVOL. Именно так. ADM — пережиток прошлого, червеобразный отросток. Когда-то он был полезен, но теперь он никакой роли не играет. Вы можете удалить их вручную, а можете написать сценарий. Но прежде чем вы это сделаете, обратите внимание: если перечисленные выше этапы не выполнения полностью, вы совершаете величайшую ошибку. Сначала убедитесь, что вы и впрямь можете распрощаться с ADM навсегда.
Дополнительные сведения о файлах ADM, ADMX и ADML см. в пошаговом руководстве по управлению файлами ADMX в групповой политике (go.microsoft.com/fwlink/?LinkId=105019) и в обзоре технологии ADMX (go.microsoft.com/fwlink/?LinkId=105032). И обязательно подпишитесь на новостной бюллетень GPanswers.com на странице GPanswers.com/newsletter и на промежуточные выпуски новостей в блоге GPanswers.com/blog.

Джереми Московиц — MCSE (сертифицированный системный инженер Майкрософт) и самый ценный специалист по групповой политике, осуществляет техническую поддержку GPanswers.com, форума сообщества по групповой политике. Ведет серию семинаров интенсивного обучения групповым политикам. Последняя книга Джереми — Group Policy: Management, Troubleshooting, and Security (Групповые политики: управление, устранение неполадок и безопасность) (изд. Sybex, 2007). Обратиться к Джереми и получить дополнительные сведения можно на форуме www.GPanswers.com.


 Групповая политика: Оптимизация производительности групповых политик
Групповая политика Даррен Мак-Элиа

Оптимизация производительности групповых политик
Краткий обзор:
  • Монолитные объекты GPO против функциональных
  • Как обрабатывать записи групповых политик
  • Что происходит при изменении групповой политики

Мне часто задают вопрос: «Что лучше с точки зрения производительности: иметь несколько крупных объектов групповой политики (GPO) или много мелких?». Этот вопрос, вместе с другими вопросами, относящимися к разработке групповых политик и их производительности и является темой данной статьи И, как и для большинства общих вопросов,
я могу назвать ответ заранее: «Это зависит от конкретной ситуации». Хотя он и может показаться уклончивым, моя цель здесь заключается в освещении механизмов, лежащих в основе обработки групповых политик, чтобы позволить читателям принимать информированные решения по поводу разработки собственных групповых политик, вне зависимости от того, начинают ли они с нуля, или стремятся оптимизировать среду с сотнями существующих объектов GPO.

Монолитные объекты GPO против функциональных
Начать стоит с описания различных способов применения объектов GPO. Термины «монолитный» и «функциональный» относятся к их схемам. Монолитные объекты GPO содержат параметры из множества различных областей. Для примера, монолитный объект GPO может содержать параметры из политик административных шаблонов, обслуживания Internet Explorer и установки программного обеспечения – все в едином объекте GPO. По контрасту, функциональные объекты GPO обычно выполняют только одну задачу. Для примера, функциональный объект GPO может заниматься только установкой программного обеспечения или применением параметров безопасности. Я встречал даже функциональные объекты GPO, которые содержали только один параметр политики! Но это, вероятно, редкий случай. На рис. 1 показаны некоторые из преимуществ и недостатков каждого подхода.
Figure 1 Comparing monolithic and functional GPOs (Close Figure 1)

Проблема | Монолитные объекты GPO | Функциональные объекты GPO
Делегирование/изоляция | Проблематичны, поскольку каждый объект GPO может содержать параметры из нескольких областей, делегирование же возможно лишь на уровне объекта GPO, а не отдельных параметров. | Просты: каждый объект GPO содержит единственную область политики, так что можно делегировать, скажем, объект GPO установки программного обеспечения администратору развертывания, объект GPO безопасности специалисту по безопасности, и т.д.
Управляемость и сложность | Потенциально проще, поскольку каждый объект GPO содержит все параметры в одном месте. | Потенциально сложнее, поскольку большее число объектов GPO означает большее число мест, где может возникнуть проблема и повышенную сложность при определении итогового набора политик для конкретного пользователя или компьютера.
Производительность | Потенциально ниже, поскольку при изменении одного объекта GPO в клиентском расширении всем расширениям придется проверить все объекты GPO в охваченной области. | Зависит от числа используемых объектов GPO и частоты их изменения. По сравнению с монолитными объектами GPO, производительность может быть лучше в динамических средах.
Как можно убедиться, готового ответа на все случаи жизни по поводу того, является ли лучшим монолитный или функциональный подход, не существует. Вероятно, что могут понадобиться оба. Например, вполне возможно, что функциональный подход будет предпочтительным при создании политики безопасности для всего домена. Наличие единственного объекта GPO, содержащего только параметры безопасности, упрощает делегирование полномочий по управлению этим объектом GPO администраторам безопасности, чтобы никто другой не мог бы до него добраться. С другой стороны, передача полномочий на администрирование групповой политики администраторам подразделений, а затем создание одного монолитного объекта GPO для каждого подразделения дает этим администраторам возможность управлять всеми своими параметрами политики из одного места. Это может уменьшить сложность их работы и умерить число объектов GPO, созданных для пользователей и компьютеров того или иного отдела.
Как все эти высокоуровневые проектные решения влияют на производительность обработки групповых политик, и что помогает в принятии решений по разработке таких политик, сводящих к минимуму негативное влияние на производительность? Первым шагом к оптимизации производительности инфраструктуры групповой политики является понимание механизмов обработки групповых политик.

Знакомство с обработкой групповых политик
Обработка групповых политик – это сложный набор взаимодействий, включающий в себя многие элементы инфраструктуры Windows® и Active Directory®. Если рассматривать ее в целом, обработка групповой политики состоит из двух частей. Первая именуется основной, или обработкой инфраструктуры групповой политики. На этой стадии клиент групповой политики Windows запрашивает свой ближайший контроллер домена, чтобы определить скорость подключения к нему, его местонахождение в иерархии Active Directory (то есть членом какого сайта, домена и подразделения является клиент) и то, какие объекты GPO применяются к компьютеру или находящемуся в системе на данный момент пользователю. (Важно отметить, что в этом контексте клиент может быть сервером или рабочей станцией, входящей в домен Active Directory.) После создания списка объектов GPO начинается следующая фаза – обработка клиентского расширения (Client-Side Extension – CSE). В ходе фазы CSE каждое зарегистрированное расширение CSE обрабатывает список объектов GPO, устанавливающих параметры в его области. Например, расширение CSE реестра или административного шаблона сперва обрабатывает все объекты GPO, прилагающиеся к определенному компьютеру или пользователю и применившие к ним политику реестра.
В приведенном ниже списке подробно описаны действия, выполняемые циклом обработки групповой политики, включая сетевые взаимодействия между клиентом и контроллером домена. Важно помнить, что групповая политика применяется и к компьютерам, и к пользователям. Следовательно, при каждой обработке групповой политики, скажем, в ходе ее фонового обновления, перечисленные мною ниже действия будут повторены как для компьютера, так и для учетной записи находящегося в системе пользователя для каждой системы, поскольку к ним могут применяться различные наборы политик. Когда это происходит, Windows выполняет цикл обработки одновременно для компьютера и пользователя, причём эти циклы работают в различных потоках внутри процесса механизма групповой политики. (Процесс Winlogon для Windows 2000, Windows XP и Windows Server® 2003, либо служба клиента групповой политики в Windows Vista® и Windows Server 2008.)
Обработка групповой политики состоит из шести этапов.
  1. Клиент выполняет обнаружение медленных подключений по протоколу Internet Control Message Protocol (ICMP) к контроллеру домена в своем сайте, чтобы определить скорость подключения. В Windows Vista использование ICMP для обнаружения медленных подключений заменяется работой службы сетевого расположения (NLA).
  2. Клиент считывает информацию о состоянии расширения CSE из своего локального реестра, чтобы определить, какие объекты GPO обрабатывались последними.
  3. Клиент использует протокол LDAP для поиска по атрибуту gpLink в Active Directory на каждом объекте-контейнере внутри своего местоположения в иерархии Active Directory – сперва на уровне подразделений (включая все вложенные подразделения), затем в домене и, наконец, на уровне сайта Active Directory. Из результатов поиска он выстраивает список объектов GPO, которые необходимо рассмотреть на предмет обработки.
  4. Затем выполняется поиск каждого из GPO в Active Directory, чтобы определить, есть ли у клиента (пользователя или компьютера) необходимые разрешения для его обработки. Также рассматриваются номер его версии, путь к шаблону групповой политики (GPT), часть объекта GPO в SYSVOL и то, какие расширения CSE применяются в этом объекте GPO.
  5. Затем клиент использует протокол SMB для чтения содержимого шаблона групповой политики и получения номера версии GPO из файла gpt.ini. Номера версий в контейнере групповой политики (Group Policy Container – GPC) и шаблон групповой политики используются для определения, менялся ли объект GPO со времени последнего цикла обработки.
  6. Каждое расширение CSE запускается в порядке, зарегистрированном в HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions и обрабатывает объекты GPO, которые применяют это расширение CSE, если объект GPO изменился со времени последнего цикла обработки (как было определено в ходе основной обработки). Каждое расширение CSE также вносит данные результирующего набора политик пользователя (Resultant Set of User Policy – RSOP) в инструментарий управления Windows (WindowsManagement Instrumentation – WMI) при каждом обновлении, если они доступны.
Давайте разберем этот процесс и посмотрим, что может сказаться на производительности. В первую очередь следует понять, что между фоновой обработкой и обработкой переднего плана есть разница. Обработка переднего плана происходит в ходе перезапуска системы для компьютеров и входа в систему для пользователей. Фоновые обновления по умолчанию происходят на рабочих станциях и рядовых серверах каждые 90 минут плюс случайное значение, могущее достигать 30 минут. Фоновые обновления на контроллерах доменов по умолчанию происходят каждые 5 минут. В Windows Vista могут также происходить обновления на основе NLA, которые по сути являются событиями фонового обновления, вызванными предшествовавшим сбоем обработки групповой политики, произошедшим из-за отсутствия доступа к контроллеру домена (как если бы клиент был отключен в момент окончания интервала между фоновыми обновлениями). Почему эти различия важны? В основном потому, что определенные расширения CSE (например, расширения CSE установки программного обеспечения и перенаправления папок) не запускаются в ходе фоновых обновлений Точно так же сценарии входа в систему/выхода из нее или запуска/выключения не будут работать в ходе фонового обновления.
Аналогично, в этапе 1 данного процесса я упомянул обнаружение медленных подключений. В системах, предшествовавших Windows Vista, этот процесс зависел от использования клиентом ICMP для проверки связи с контроллером домена, чтобы определить его доступность и скорость связи. В случае падения расчетной скорости связи ниже определенного значения (500 кб/с по умолчанию), связь считается медленной, и, опять таки, некоторые расширения CSE, такие как расширения установки программного обеспечения, перенаправления папок, обслуживания Internet Explorer и другие, отказываются работать. Все эти условия могут повлиять на производительность, равно как и на ожидаемую доставку политики.
Наибольшее влияние на производительность из всех аспектов цикла обработки политики вероятно оказывает логика, определяющая, изменились ли объекты GPO, применяющиеся к компьютеру или пользователю. Механизм групповой политики имеет встроенный механизм оптимизации, указывающий, что если изменений со времен последней обработки не произошло, то обработку проводить не надо. Очевидно, что это может оказать громадное влияние на объем времени, уходящий у клиентов на обработку политики, особенно если среда групповых политик довольно статична. Рассмотрим подробнее, что считается изменением.

Когда происходит изменение групповой политики
Итак, что считается изменением с точки зрения обработки групповой политики? Несколько факторов определяют это, но наиболее явным из них является то, что в случае внесения изменения в объект GPO клиенты, обрабатывающие этот объект GPO, обнаружат это изменение и повторно обработают объект GPO. Как клиент узнает, что объект GPO изменился? Путем сравнения номера версии объекта GPO с имеющимся у него.
Объект GPO состоит из двух частей – контейнера GPC, сохраненного в Active Directory внутри имеющегося в каждом домене контейнера CN=Policies, CN=System, и шаблона GPT, сохраненного в SYSVOL в папке Policies. Обе части содержат номер версии. У контейнера GPC номер версии хранится в атрибуте versionNumber на объекте контейнера GPC. У шаблона GPT он хранится внутри файла gpt.ini в корневой папке данного шаблона GPT. Клиент также сохраняет записи номеров версии обработанных им объектов GPO (как для компьютеров, так и для пользователей) в своем реестре. Информация о версии содержится в HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\History, если речь идет об объекте GPO для компьютера, и в HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\<Идентификатор безопасности пользователя>, если об объекте GPO для пользователя.
Когда происходит обработка групповой политики, одной из ее частей является проверка номеров версий всех объектов GPO, которые относятся к компьютеру или пользователю, и сравнение их с сохраненными в реестре номерами тех, что были обработаны в ходе последнего цикла. Если номер версии любого из существующих объектов GPO не совпадает (отметьте, что несовпадения достаточно – номер может быть меньше или больше), то такой объект GPO будет обработан в ходе текущего цикла обработки. В противном случае он не будет обработан, если не соответствует одному из других критериев изменения. Эти другие критерии таковы:
  • Изменение в списке объектов GPO, применяющихся к пользователю или компьютеру (объект GPO добавлен или удален)
  • Изменение состава членов группы безопасности пользователя или компьютера
  • Изменение в фильтре WMI, связанном с объектом GPO (фильтр WMI добавлен или удален)
Если любое из этих условий выполнено, клиент выполнит повторную обработку политики в ходе этого цикла, однако в этом процессе есть свои тонкости, про которые стоит знать из-за их значительного влияния на производительность. Если для какого-либо расширения CSE изменяется 1 объект GPO из 10, то все объекты GPO для этого расширения CSE должны быть обработаны. Помните, что «обрабатываемой единицей» является расширение CSE. Однако расширения CSE должны обрабатывать политики в определенном порядке (сперва локальные объекты GPO, затем объекты GPO, связанные с сайтом, затем связанные с доменом и с подразделением). Приняв это требование, предположим, к примеру, что к пользователю применимы 10 объектов GPO, привязанных на различных уровнях Active Directory. Предположим также, что каждый из этих 10 объектов GPO применяет какой-либо параметр политики административного шаблона. На сцену выступает администратор, изменяющий объект GPO, связанный с доменом, – добавляя новый параметр политики административного шаблона. Теперь компьютер или пользователь начинают обрабатывать политики и замечают, что номер версии измененного объекта GPO выше, чем в прошлый раз, следовательно, его нужно обработать снова. Но чтобы сохранить порядок обработки политик, при этом будет необходимо обработать все параметры административного шаблона, которые прилагаются ко всем объектам GPO. Таким образом, простое изменение объекта GPO может нанести сильный удар по производительности клиента.

Сравнение производительности монолитных и функциональных объектов GPO
Теперь, когда цикл обработки и влияние изменений среды групповых политик на производительность рассмотрены, стоит вернуться к обсуждению противостояния монолитных и функциональных объектов GPO, а также тому, как эти подходы влияют на производительность.
Монолитные объекты GPO могут давать скрытое снижение производительности из-за особенностей контроля версий групповых политик. Причины этого очевидны не сразу. Они связаны с отсутствием в механизме обработки групповых политик концепции контроля версий на основе расширений CSE. Допустим, к пользователю применяются три объекта GPO. Каждый объект GPO монолитен в том, что он реализует политику в нескольких областях. Для примера, предположим, что каждый объект GPO реализует политики административного шаблона, установки программного обеспечения и перенаправления папок. Теперь предположим, что администратор изменяет политику административного шаблона в одном из этих объектов GPO. Это изменение увеличивает номер версии. Затем на сцену выходит пользователь и начинает обработку групповых политик. Расширение CSE административного шаблона запускается, замечает, что один из объектов GPO изменился, и обрабатывает все три объекта GPO снова.
При запуске расширений CSE установки программного обеспечения и перенаправления папок они также замечают изменение номера версии одного из объектов GPO. Но поскольку номер версии не говорит им, какая из областей политики изменилась в этом объекте GPO, они обрабатывают его опять, на всякий случай. Как следствие, изменение одной области политики в монолитном объекте GPO может привести к затрате ресурсов на обработку в другой области.
Конечно, расширения CSE, относящиеся к установке программного обеспечения или перенаправлению папок, могут и не выполнить никакой реальной работы, поскольку, например, однажды установленное приложение не будет переустанавливаться. Но смысл в том, что такое поведение может произойти с любым расширением CSE, и это следует учитывать при создании монолитных объектов GPO. Если какая-либо область политики часто меняется, стоит задуматься над созданием объекта GPO, применяющего эту область отдельно от остальных.
С точки зрения функциональных объектов GPO соображения производительности более очевидны. Чем больше объектов GPO приходится на пользователя или компьютер (функциональный подход обычно подразумевает большее число объектов GPO по отношению к числу параметров политики), тем больше времени механизм групповой политики тратит на перечисление этих объектов GPO в ходе основной фазы обработки групповых политик. Однако, как можно будет увидеть в следующем разделе, это не обязательно снижает производительность.

Измерение производительности групповых политик
В конечном счете, для принятия правильных решений, затрагивающих производительность инфраструктуры групповых политик, необходима способность измерять производительность этих политик в реальной среде. Смоделировать или предсказать производительность групповой политики почти невозможно в силу большого числа факторов, могущих повлиять на цикл обработки. По этой причине лучшим методом обнаружения проблем с производительностью групповых политик является экспериментальное измерение. Что делает производительность низкой? О низкой производительности можно говорить в любой ситуации, когда обработка групповых политик влияет на качество обслуживания пользователей. Ситуация может быть разной в разных организациях, но важно осознавать наличие проблемы.
Итак, как можно измерить продолжительность цикла обработки групповых политик? Ответ опять непрост. Если используется Windows Vista или Windows Server 2008, можно воспользоваться новыми рабочими журналами просмотра событий. Рабочий журнал групповой политики средства просмотра событий, который можно найти в «Журналы приложений и служб»\Microsoft\Windows\«Групповая политика»\«Действующая», предоставляет превосходный инструментарий для каждого этапа цикла обработки групповой политики (см. рис. 2).
Рис. 2 Событие рабочего журнала групповой политики, где показано время обработки политики
Рис. 2 Событие рабочего журнала групповой политики, где показано время обработки политики
Однако для тех, кто не работает в среде Windows Vista или Windows Server 2008, механизмы измерения времени обработки политик куда менее прямолинейны. В этом случае остается включить подробное ведение журнала userenv (поддержку обеспечивает статья базы знаний Майкрософт support.microsoft.com/kb/221833) и просматривать временные метки внутри файла для выбранного цикла обработки, или использовать параметры в реестре клиента, указывающие время начала и завершения обработки политики. Эти значения для компьютера хранятся здесь
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\Machine\Extension-List\
{00000000-0000-0000-0000-000000000000}
а для пользователя – здесь:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\<SID of User>\Extension-List\
{00000000-0000-0000-0000-000000000000}
Значения хранятся в формате FILETIME, и их необходимо преобразовать в обычную дату и время. Можно также использовать написанную мной бесплатную служебную программу GPTime.exe (доступную на gpoguy.com/tools.htm#GP_Time_Utility) для получения той же информации.
В отсутствие среды Windows Vista или Windows Server 2008, но при наличии доступа к журналу userenv все же можно получить ценную информацию о том, сколько времени ушло на каждый цикл обработки политики. Например, на рис. 3 изображен фрагмент журнала userenv, показывающий часть основной фазы обработки групповой политики.
Рис. 3 Часть журнала userenv
Рис. 3 Часть журнала userenv
Обратите внимание, что в каждой строке файла журнала есть метка времени. Основная часть цикла обработки групповой политики начинается с события, сообщающего что-нибудь вроде: "ProcessGPOs: Starting user Group Policy (Background) processing ..." Часть цикла обработки, связанная с расширением CSE, начинается со строки: "ProcessGPOs: Processing extension Registry." Этот журнал и метки времени в нем можно использовать для определения продолжительности каждой части цикла обработки политики.

Общие наблюдения по поводу производительности
Проведя достаточно времени за рассмотрением файлов журнала userenv, начинаешь различать тенденции, и, хотя предсказать, сколько времени займет обработка политики, все еще нельзя, можно сформулировать некоторые общие наблюдения по поводу того, куда девается время в цикле обработки. Например, в ходе обработки политики, когда обрабатываются изменения, и расширения CSE в силу этого загружены работой, время, уходящее на основную часть обработки групповых политик, обычно намного меньше времени, уходящего на расширение CSE.
Это верно для большинства областей политики, поскольку большинству расширений CSE необходимо выполнять задачи, работающие дольше, чем основная часть их обработки, наиболее ресурсоемкими операциями которой являются запросы к Active Directory и SYSVOL. Например, нельзя и сравнить время, проведенное в основной части обработки, с тем временем, которое расширение CSE установки программного обеспечения может потратить на установку Microsoft® Office. Однако для большинства фоновых обновлений политики, когда изменений со времени последнего цикла нет, основная часть цикла занимает примерно то же время, что и работа расширения CSE. Исключением является обработка политики реестра – которая на самом деле довольно быстра, если пользователь или компьютер не отягощен десятками и сотнями параметров политики реестра.
Кроме того, отключение компьютера или пользовательской стороны объекта GPO по причине неиспользования почти не влияет на производительность обработки политик. Если же не используется сторона политики, все издержки будут заключаться в запросе к Active Directory, чтобы определить это. Запрос, идентичный тому, который происходит для определения того, реализованы ли расширения CSE для той стороны объекта GPO, должен быть выполнен, чтобы просмотреть вариант отключения. Эффект отключения стороны несущественен.

Рекомендации по достижению оптимальной производительности групповых политик
Теперь когда многие аспекты производительности обработки групповых политик рассмотрены, стоит привести несколько рекомендаций по планированию, которые могут прямо повлиять на производительность. Они сведены в четыре основных пункта.
  1. Если в объекты GPO вносятся частые изменения, не забывайте вышеупомянутые эффекты – изменение в одном расширении CSE может повлиять на обработку всех расширений CSE. В силу этого, если планируется частое внесение изменений, например в политику реестра, имеет смысл поместить данную политику в функциональный объект GPO (объект GPO, занимающийся только политикой реестра), поскольку это изолирует другие расширения CSE от изменений, вызывающих новую обработку.
  2. При обдумывании того, сколько объектов GPO стоит иметь, не забывайте, что обработка политики происходит только после изменений, и «затратные» расширения CSE, такие как установка программного обеспечения или перенаправление папок, а также обработка большого числа политик реестра или установка разрешений на больших деревьях файлов либо реестра, занимают большую часть времени. Время, потраченное на запросы списка объектов GPO у Active Directory в ходе основной обработки, часто является самой малой частью цикла обработки. Так, 30 объектов GPO, применяющихся к какому-либо пользователю и отличающиеся минимальным числом изменений реестра, могут занять меньше времени на обработку, чем 5 объектов GPO, которые часто подвергаются изменениям и из-за этого постоянно используют затратные расширения CSE.
  3. Избегайте моделей поведения, явно снижающих производительность обработки политик. Например, можно установить политику, заставляющую расширения CSE вести обработку, даже если объект GPO не изменен (в «Конфигурация компьютера»\«Административные шаблоны»\«Система»\«Групповая политика»). Но в этом случае стоит ожидать, что циклы обработки станут дольше.
  4. Не забывайте о последствиях отключения оптимизации быстрого входа в систему в Windows XP и Windows Vista (это можно сделать, включив политику в «Конфигурация компьютера»\«Административные шаблоны»\«Система»\«Вход в систему»\«Всегда ждать ответа сети при запуске компьютера и входе пользователя в систему»). Когда эта политика включена, обработка переднего плана переключается с асинхронной на синхронную. Это значит, что политика компьютера и пользователя должна быть выполнена полностью, прежде чем пользователь сможет управлять компьютером и рабочим столом. Однако это также может быть полезно, поскольку позволяет обойти проблему необходимости двух и более перезапусков или входов в систему для ввода в действие политик установки программного обеспечения и перенаправления папок.

Заключение
Хотя производительность обработки групповых политик – это не точная наука, представление о ней, привнесенное в процесс проектирования, может смягчить проблемы с производительностью.
Знакомство с тем, как функционирует цикл обработки и на что уходит время, является большим шагом к определению источников этих проблем. Используйте рабочие журналы Windows Vista или Windows Server 2008 (или журналы userenv в предыдущих версиях Windows) для получения практической информации о цикле обработки. Не забывайте о превратностях обработки расширений CSE и о том, что является изменением политики с точки зрения расширения CSE. Наконец, помните, что в динамических средах с большим числом изменений функциональные объекты GPO могут быть предпочтительнее монолитных. Итог же состоит в том, что групповая политика – это технология, разработанная для помощи в управлении средой Windows. Важно чтобы потребности бизнеса двигали проектирование групповых политик, а не наоборот. Достижению этой цели поможет учет описанных выше моделей поведения производительности.

Даррен Мак-Элиаявляется обладателем звания Microsoft MVP по групповым политикам, создателем популярного веб-узла, посвященного групповым политикам — www.gpoguy.com — и соавтором руководства Microsoft Windows Group Policy Guide («Руководство по групповым политикам Microsoft Windows») (изд-во Microsoft Press, 2005 г.). Он также является техническим директором и основателем компании SDM Software, Inc. С ним можно связаться по адресу Darren@gpoguy.com.


 Групповая политика: Углубленное рассмотрение расширенного управления групповыми политиками
Групповая политика Дерек Мелбер

Углубленное рассмотрение расширенного управления групповыми политиками
Краткий обзор:
  • Установка и архитектура средства AGPM
  • Автономное внесение изменений в объекты GPO
  • Управление изменениями с помощью AGPM
  • Аварийное восстановление

Совсем недавно корпорация Майкрософт приобрела DesktopStandard, компанию, создавшую продукт, который делает возможным полное управление объектами групповой политики. По моему мнению, каждому предприятию, использующему Active Directory, следует применять данное средство расширенного управления групповыми политиками (Advanced Group Policy Management – AGPM).
AGPM обеспечивает автономное внесение изменений в объекты групповой политики (GPO), управление изменениями, рабочий процесс обновления политик, делегирование и многое другое. В данной статье я углублюсь во внутренние механизмы работы этого отличного, исключительно полезного средства и предоставлю его подробное рассмотрение.
Для начала немного истории. AGPM первоначально было известно как GPOVault. После приобретения DesktopStandard Майкрософт переименовала этот продукт в AGPM и добавила его к пакету оптимизации рабочей среды Microsoft® Desktop Optimization Pack (MDOP). На данный момент MDOP можно получить при условии охвата лицензий на настольные системы Windows Vista® программой Microsoft Software Assurance.
Основываясь на собственном опыте работы с входящими в него средствами, я считаю MDOP одним из наиболее впечатляющих предложений Майкрософт за последнее время. В MDOP входят пять различных средств, каждое из которых интересно само по себе, вместе же они составляют примечательнейший и полезнейший наборов. Дополнительные сведения о MDOP можно найти на веб-узле MDOP: windowsvista.com/optimizeddesktop.

Установка и архитектура средства AGPM
Для AGPM был создан гладкий и быстрый процесс установки – он состоит из серверного компонента и клиентского (административного) компонента. Серверный компонент устанавливается на сервере, являющемся членом домена, и не изменяет Active Directory®, схему или любую другую службу каталога. AGPM можно установить на контроллере домена, если этого требует ситуация.
При установке сервера устанавливается служба, требующая учетную записи доменной службы, от которой AGPM получает доступ от имени пользователя к динамическим рабочим объектам групповой политики . Установка также требует наличия администратора AGPM, который будет контролировать все параметры внутри AGPM, такие как делегирование и управление первоначальными GPO.
Клиент должен быть установлен на компьютере, использующем Windows Vista, где уже выполняются нормальные административные функции, вероятнее всего на компьютере администраторов сети и Active Directory. После этого клиенту необходимо указать параметры AGPM серверу AGPM, чтобы установить подключение к архиву. Клиент AGPM использует интерфейс консоли управления групповыми политиками (Group Policy Management Console – GPMC) и отображается в виде узла Change Control (Контроль изменений), как показано на рис. 1.
Рис. 1 AGPM полностью интегрирован в GPMC для простоты использования
Рис. 1 AGPM полностью интегрирован в GPMC для простоты использования
Файлы, к которым будет получать доступ клиент AGPM, хранятся в базовом формате файлов на сервере AGPM. Это простейший метод хранения данных файлов, обеспечивающий простоту резервного копирования всего архива AGPM. Большинство функций AGPM используют встроенный интерфейс API GPMC, что, опять же, обеспечивает бесшовную интеграцию и использование продукта. AGPM не использует базу данных, а хранит объекты GPO в единой папке, причем манифест контролирует соотнесение всех GPO с родительским GPO внутри архива. Это обеспечивает наличие у каждого GPO уникального идентификатора GUID и связь верного GUID с развертываемым GPO при помещении последнего в рабочую среду.

Автономное внесение изменений в файлы AGPM
Самой простой возможностью AGPM является возможность вносить изменения в объекты GPO автономно, вне рабочей среды. Хорошо известно, что внесение изменений в объекты GPO с использованием GPMC по умолчанию может привести к немедленному помещению ошибочных параметров в рабочую среду с потенциально катастрофическими результатами.
APGM проделывает автономное внесение изменений в объекты GPO, «контролируя» их. Контролируемый объект GPO, как показано на рис. 2 – это объект GPO, в который можно внести изменения автономно, безо всякого вмешательства в рабочую среду.
Рис. 2 Контролируемые GPO хранятся в архиве AGPM, и в них можно внести изменения автономно
Рис. 2 Контролируемые GPO хранятся в архиве AGPM, и в них можно внести изменения автономно
Установить контроль над GPO очень просто. Неконтролируемые объекты GPO, как показано на рис. 3, составляют список всех объектов GPO, которые пока не связаны с AGPM. Щелкнув правой кнопкой мыши любой из этих объектов GPO, можно вывести меню, включающее в себя пункт «Контроль» (Control). При выборе этого пункта объект GPO копируется из рабочего местоположения (системного тома, или SYSVOL, общей папки на контроллере домена) и помещается в архив AGPM. Возможен контроль и над несколькими объектами GPO, просто удерживайте клавишу Shift или Control при выборе объектов GPO для получения правильного списка объектов GPO, которые нужно контролировать, и затем щелкните правой кнопкой мыши для доступа к пункту «Контроль» в меню. В контролируемые объекты GPO по-прежнему можно вносить изменения, используя редактор объектов групповых политик (Group Policy Object Editor – GPOE). Это лишь еще один способ полной интеграции AGPM в GPMC.
Figure 3 Uncontrolled GPOs are placed in the archive by selecting the Control menu option
Figure 3 Uncontrolled GPOs are placed in the archive by selecting the Control menu option

Делегирование административных прав в AGPM
Давайте взглянем, как AGPM справляется с делегированием, для начала изучив, как можно делегировать административные права для объектов GPO, используя GPMC. Внутри GPMC имеются пять различных задач делегирования, которые можно предоставить пользователю: Создание объекта GPO, связывание объекта GPO, внесение изменений в объект GPO, управление GPO и чтение GPO.
Все эти делегирования выполняются внутри интерфейса GPMC. Все они управляются пользователями и группами, перечисленными на вкладках делегирования, связанных с различными узлами внутри GPMC. Нас интересуют делегирования, позволяющие создание новых объектов GPO, а также внесение изменений в существующие GPO и управление ими.
Создание объектов GPO внутри GPMC управляется вкладкой делегирования, связанной с узлом объектов групповой политики, как показано на рис. 4. После установки AGPM появляется возможность удалить всех пользователей и все группы из списка имеющих доступ к созданию объектов GPO. (Для создания объектов GPO нет нужды удалять систему, компьютеры или группы компьютеров из вкладки делегирования.) Создание объектов GPO теперь будет осуществляться учетной записью службы, контролирующей службу AGPM. Этой учетной записи будет делегировано право создания объектов GPO от имени всех пользователей и групп, имеющих права на создание объектов GPO и развертывание делегирований из AGPM.
Рис. 4 Создание GPO контролируется списком учетных записей на вкладке делегирования на узле объектов групповой политики GPMC
Рис. 4 Создание GPO контролируется списком учетных записей на вкладке делегирования на узле объектов групповой политики GPMC
Эта новая способность создавать объекты GPO позволяет выполнить разделение обязанностей и защищает рабочую сеть. В идеале объекты GPO создаются, настраиваются и проверяются перед развертыванием из среды AGPM в рабочую среду. Выпуск ошибочных конфигураций, подобный происходящему без AGPM, должен быть редок.
Аналогично выполняется и делегирование, относящееся к правке объектов GPO или управлению ими. Внутри GPMC эти делегирования настраиваются на вкладке делегирований, связанной с каждым объектом GPO, как показано на рис. 5.
Рис. 5 Изменение и управление GPO связано с каждым объектом GPO по отдельности
Рис. 5 Изменение и управление GPO связано с каждым объектом GPO по отдельности
После установки AGPM эти делегирования следует удалить из каждого объекта GPO, указанного в списке узла объектов групповой политики. Это ограничит внесение изменений в объекты GPO извне AGPM для всех администраторов. По сути, это передает все администрирование объектов GPO средству AGPM, в котором возможно выполнение таких задач, как автономное внесение изменений, управление изменениями и аварийное восстановление.
Исключение пользователей и групп из числа допущенных до внесения изменений в объекты GPO извне AGPM – процесс, выполняемый вручную. Установка и настройка AGPM сама по себе не мешает пользователям и группам вносить изменения в объекты GPO в рабочей среде. Поскольку учетная запись службы, контролирующая службу AGPM, будет выполнять действия от имени пользователей, изменяющих рабочие объекты GPO из AGPM, вкладка делегирования для каждого объекта GPO может и не содержать каких-либо пользователей и их групп. (Удалять из вкладок делегирования компьютеры и группы компьютеров не следует.)
После удаления всех делегированных полномочий на внесение изменений в объекты GPO внутри GPMC все администраторы лишатся способности вносить изменения в объекты GPO из GPMC, как показано на рис. 6.
Рис. 6 После удаления всех делегированных полномочий на внесение изменений в объекты GPO внутри GPMC все администраторы лишатся способности вносить изменения в объекты GPO
Рис. 6 После удаления всех делегированных полномочий на внесение изменений в объекты GPO внутри GPMC все администраторы лишатся способности вносить изменения в объекты GPO
Чтобы завершить настройку, всех администраторов, которым нужна возможность вносить изменения в объекты GPO, следует добавить в соответствующие списки управления доступом (ACL) внутри AGPM. Если администратор нуждается в возможности вносить изменения во все объекты GPO, имеющиеся в архиве, его учетную запись пользователя следует добавить к группе, которой были даны возможности внесения изменений на уровне домена внутри AGPM, как показано на рис. 7. Если администратору следует позволить вносить изменения лишь в часть объектов GPO внутри архива AGPM, эту возможность придется настраивать отдельно для каждого из нужных объектов GPO (см. рис. 8).
Рис. 7 Вкладка делегирования внутри домена позволяет изменять все GPOв архиве
Рис. 7 Вкладка делегирования внутри домена позволяет изменять все GPOв архиве
Figure 8 Editing of individual GPOs needs to be configured on the ACL of that GPO
Figure 8 Editing of individual GPOs needs to be configured on the ACL of that GPO

Управление изменениями объектов GPO посредством AGPM
Одним из величайших достоинств AGPM является способность отследить все изменения, внесенные в объекты GPO внутри архива. Это автоматизированный процесс, не нуждающийся в установке, настройке или управлении. Отслеживание всех изменении осуществляется в фоновом режиме, при работе с объектами GPO через клиентский интерфейс AGPM.
Это является значительным улучшением по сравнению тем, как GPMC по умолчанию обрабатывает управление объектами GPO. Внутри GPMC по умолчанию нет автоматических или даже просто встроенных возможностей для отслеживания изменений объектов GPO. Это вызывало серьезные претензии со стороны большинства администраторов групповых политик, теперь же проблема устранена.
Возможность управления изменениями в AGPM отслеживает все существенные изменения, которые могут произойти с объектом GPO. Помимо изменений, внесенных в объект GPO, система управления изменениями также помогает при аудите и вообще при отслеживании действий администраторов. Система управления изменениями пронаблюдает, отследит и задокументирует следующие сведения о каждой правке и изменении объекта GPO: дату и время изменения объекта GPO, пользователя, внесшего изменения, изначальные параметры объекта GPO и изменения параметров объекта GPO.
Поскольку отслеживание всех изменений выполняется гладко, важно знать, какие действия активируют автоматическое отслеживание. Внутри клиентского интерфейса AGPM можно щелкнуть правой кнопкой мыши объект GPO под вкладкой Controlled (Контролируемые) и выбрать в меню пункт Check-out (Взять для изменения), как показано на рис. 9.
Рис. 9 Проверка GPO помогает узнать, какие действия активируют автоматическое отслеживание
Рис. 9 Проверка GPO помогает узнать, какие действия активируют автоматическое отслеживание
Этой же процедуре необходимо следовать для внесения изменений в объект GPO, о чем я расскажу в следующем разделе. Даже если объект GPO взят для изменения и тут же возвращен обратно безо всяких изменений, это действие оставит запись в архиве. Поскольку объекты GPO крайне важны для предприятия, средство отслеживает даже возможность внесения изменений.
Процедура взятия для изменения выполняется принудительно внутри AGPM из-за необходимости механизма, отслеживающего, кто из администраторов внес изменения в объект GPO. Два администратора не могут взять для изменения один и тот же объект GPO одновременно. На случай, если администратор возьмет объект GPO для изменения и затем не возвратит его после внесения изменений, имеется встроенный механизм, позволяющий администратору AGPM возвратить объект.

Внесение изменений в объект GPO посредством AGPM
Пока клиент AGPM установлен, сохраняется доступ к архиву AGPM. У тех, кому внутри средства AGPM делегированы полномочия на внесение изменений или полный доступ, появляется возможность вносить изменения в сохраненные объекты GPO. После взятия объекта GPO для изменения в него можно вносить изменения, щелкнув правой кнопкой мыши и выбрав в меню пункт «Правка». (Примечание: если получается вносить изменения лишь в часть объектов GPO, находящихся в архиве AGPM, то вам, вероятно, были предоставлены делегированные возможности лишь для этих объектов GPO, а не для всех объектов GPO в архиве.)
С приобретением DesktopStandard корпорация Майкрософт также приобрела программу PolicyMaker, теперь именуемую средством установки предпочтений групповых политик (Group Policy Preferences). Этот набор возможностей групповых политик включен в GPMC, который будет поставляться в составе Windows Server® 2008. Предпочтения групповых политик позволяют администратору настраивать приложения и компоненты Windows, которые обычно не могут быть настроены с помощью групповой политики, а также применять их к группам пользователей или компьютеров на основании разнообразнейших правил выбора целевых объектов. Средство установки предпочтений групповых политик полностью интегрировано в GPMC и AGPM, входящие в Windows Server 2008.

Развертывание объектов GPO посредством AGPM
Средство AGPM было разработано для повышения эффективности и ускорения рабочего процесса. Поскольку при использовании AGPM управление объектами GPO теперь более стабильно и контролируемо, имеет смысл давать некоторым администраторам лишь возможность вносить изменения в объект GPO, но не возможность развертывать его в рабочей среде. Внутри AGPM это контролируется очень гладко с помощью интерфейса, диалоговых окон и рабочих механизмов. Например, если администратор, имеющий только права на внесение изменений, попытается развернуть объект GPO, система заблокирует это. После этого администратору будет показано диалоговое окно для связи с администратором, у которого есть право на развертывание. Эта функция рабочего процесса отправит сообщение электронной почты получателям из разделов «Кому:» и «Копия:» , в то же время помещая объект GPO в уникальное состояние. Это уникальное состояние можно найти на вкладке ожидающих в интерфейсе AGPM. Объект GPO помечен здесь как «ожидающий развертывания», что дает администраторам быстрый обзор состояния каждого объекта GPO, в отношении которого выполнялись действия.
Для развертывания ожидающего объекта GPO администратор AGPM, имеющий на это право, может просто щелкнуть правой кнопкой мыши объект GPO и выбрать пункт Approve (Одобрить) в меню. Если объект GPO нуждается в развертывании и указан во вкладке контролируемых, а не ожидающих объектов, тому же администратору достаточно щелкнуть его правой кнопкой мыши и выбрать Deploy (Развернуть). Поскольку нужные разрешения уже даны, объект GPO немедленно будет развернут в рабочей среде.

Отчет о параметрах объекта GPO и сравнение объектов GPO посредством AGPM
Интерфейс GPMC располагает обладающим широкими возможностями диалогом Settings (Параметры), доступ к которому возможен через одноименную вкладку. Этот диалог предоставляет исчерпывающий обзор всех параметров, которые можно установить в объекте GPO, помогая понять, какие из почти 3000 параметров групповой политики уже настроены.
Поскольку AGPM предоставляет архив измененных объектов GPO, вкладка Settings (Параметры) в GPMC не даст возможности просматривать параметры, выставленные в измененных объектах GPO. Вместо этого интерфейс AGPM предоставляет альтернативное решение для этой функции, а также многое другое.
Для просмотра параметров в любом объекте GPO в первую очередь полезно просмотреть журнал изменений. Для этого дважды щелкните любой объект GPO на вкладке Controlled (Контролируемые) в AGPM. В этом интерфейс можно щелкнуть правой кнопкой мыши любую версию объекта GPO и выбрать отчет о параметрах (Settings Report). Будет создан отчет о всех параметрах, настроенных в данной версии объекта GPO. Отчет представляет из себя удобный файл HTML, но может быть создан и в формате XML.
Это весьма полезно, но еще более удобной является возможность сравнить две версии одного объекта GPO. С помощью этой возможности можно увидеть, что изменилось между версиями, или сравнить два совершенно разных варианта одного объекта GPO. (Это также очень полезно при наличии объекта GPO, ожидающего развертывания, поскольку позволяет увидеть различия между ожидающим объектом GPO и объектом GPO в рабочей среде.) Чтобы увидеть этот отчет, выделите два разных объекта GPO в журнале изменений, затем щелкните один из этих объектов правой кнопкой мыши.
Цветная маркировка в отчете о различиях исключительно полезна, особенно когда необходимо проверить, что изменилось в ожидающем объекте GPO, прежде чем его развертывать. Параметры, выделенные красным, были удалены из рабочего объекта GPO и более недоступны в ожидающем объекте GPO. Параметры, выделенные синим, были изменены, а зеленым выделяются новые элементы, существующие в ожидающем объекте GPO, но не в рабочем.
Эта возможность AGPM может сэкономить много часов трудоемкого ручного сравнения параметров объектов GPO. Она также является идеальным способом документирования изменений объектов GPO, позволяя составить и распечатать отчет по каждой из версий.

Аварийное восстановление объектов GPO посредством AGPM
Единственное изменение в объекте GPO может посеять хаос на одном или нескольких компьютерах сети. При использовании GPMC по умолчанию подобную ошибочную настройку можно исправить – если были вручную приняты нужные меры по созданию резервных копий объекта GPO как до, так и после внесения изменений в рабочий объект GPO. Если резервные копии не были созданы, аварийное восстановление будет не таким простым, как можно подумать.
А AGPM справляется с ним без труда. В силу наличия полных резервных копий всех объектов GPO в журнале GPO, можно просто открыть этот журнал и выбрать версию объекта GPO, которую следует развернуть заново.
Использование AGPM делает управление групповыми политиками почти идеально гладким. Администраторы годами желали иметь возможность контролировать объекты GPO и управлять ими в автономном режиме. AGPM предоставляет элегантное решение для этого. AGPM также предоставляет очень устойчивое решение по управлению изменениями, которое не только отслеживает ключевые области измененного объекта GPO, но также обеспечивает простоту при сравнении и аварийном восстановлении объектов GPO. Модель делегирования полномочий, встроенная в AGPM, позволяет направлять всех администраторов в AGPM для внесения изменений в объекты GPO, что обеспечивает автоматические резервные копии изменений в объектах GPO и устраняет любые поломки в рабочих объектах GPO. Эта служба имеет столько возможностей, что рассказать здесь о всех просто невозможно, но руководство по AGMP предоставляет массу информации о шаблонах, восстановлении связей узлов, настройке SMTP и многом другом.

Дерек Мелбер является независимым консультантом, преподавателем и автором. Он преподает технологии Майкрософт и специализируется на Active Directory, групповой политике, безопасности и управлении рабочей средой. Дерек регулярно публикует статьи в бумажных и электронных изданиях и написал свыше десятка книг, посвященных технологиям, включая The Microsoft Windows Group Policy Guide («Руководство по групповым политикам Microsoft Windows») (изд-во Microsoft Press, 2005 г.). Связаться с Дереком можно по адресу derekm@braincore.net.


 От редактора: Завоевать доверие скептика
От редактора
Завоевать доверие скептика
Джошуа Хоффман

Я скептик. Да, это так. Я знаю, мы, нью-йоркцы, обычно известны своей доверчивостью и наивностью, но время от времени битый жизнью человек проскальзывает через туннель Линкольна и портит всю картину. Будучи скептиком, я склонен сомневаться во всем. Завоевать мое доверие бывает непросто.
Возможно, моим коллегам в Редмонде не понравится то, что я сейчас напишу, но был настроен скептически, когда корпорация Майкрософт представила марку System Center несколько лет назад. Не поймите меня неверно – я целиком за SMS. На моей предыдущей работе специалиста по развертыванию настольных систем и управлению ими Systems Management Server (во всяком случае, после выхода версии 2.0) был важным средством в моем арсенале. Но по мере эволюции марки System Center и роста серии продуктов проснулась моя природная склонность к сомнениям.
Было ли это действительно необходимо? Поможет ли это в итоге пользователям? Окажет ли разностороннее развитие серии продуктов негативное влияние на ведущие продукты для управления, которые мы успели узнать и полюбить?
Но я должен признать, что несмотря на мои первоначальные дурные предчувствия, System Center завоевал мое доверие. SMS и MOM (теперь известные как Configuration Manаger и Operations Manager) эволюционировали в продукты для управления мирового класса, обзаводясь новыми, широкими (и даже неожиданными) возможностями с каждым выпуском.. Их значение не только не понизилось с появлением новых продуктов, но наоборот, существенно возросло.
В последние месяцы мы изучили новые продукты Configuration Manager и Operations Manager, а также некоторые из прочих ранних дополнений к номенклатуре продуктов System Center (таких как Capacity Planner, Desired Configuration Monitor и Essentials). Как читатели смогут увидеть, в этом месяце мы подробно рассмотрим ряд новых и весьма богатых возможностями дополнений.
Эдвин Юэн (Edwin Yuen) начинает наш обзор, показывая, как диспетчер виртуальных машин Virtual Machine Manager 2007 помогает не только централизовать управление виртуализированной инфраструктурой, но и преодолеть докучливые барьеры на пути переноса, позволяя консолидировать старое оборудование в новых виртуальных машинах. Кальвин Китон (Calvin Keaton) знакомит читателей с новой версией диспетчера защиты данных Data Protection Manager, которая делает возможными новые и обладающие широкими возможностями решения резервного копирования не только для стандартных данных пользователей (вроде документов), но и для корпоративных данных, таких как важная информация, сохраненная в Exchange Server. Наконец, Пол Буржо (Paul Bourgeau) представляет первое размещенное решение System Center – службу инвентаризации программного обеспечения Asset Inventory Service.
Поделитесь своим мнением о новых добавления к номенклатуре продуктов System Center. Отправляйте мне сообщения электронной почты по адресу tnmag@microsoft.com. Джошуа Хоффман (Joshua Hoffman)

Мы хотели бы поблагодарить следующих технических специалистов корпорации Майкрософт: Карандипа Ананда (Karandeep Anand), Джозефа Дадзи (Joseph Dadzie), Рея Хейеса (Ray Hayes), Кей Си Лемсона (KC Lemson), Билла Шейделя (Bill Scheidel), Джефри Сноувера (Jeffrey Snover), Майка Стефенса (Mike Stephens), Кевина Салливана (Kevin Sullivan), Джима Труэра (Jim Truher) и Вини Верхофа (Winni Verhoef).


 Письма в редакцию: Мнения читателей
Письма в редакцию
Мнения читателей

Проблемы VMRCplus
Я загрузил VMRCplus, как было описано в рубрике «Обзор служебных программ» в выпуске за октябрь 2007 г. (technetmagazine.com/issues/2007/10/UtilitySpotlight). Но при попытке подключения к удаленному компьютеру происходят ошибки RPC. Поскольку интерфейс администратора виртуального сервера является веб-интерфейсом, я предположил, что это приложение также использует веб-интерфейс, просто расширяя возможности клиента существующей веб-технологии. К сожалению, приложение использует интерфейс API модели COM.
— из блога blogs.technet.com/tnmag.

VMRCPlus в действительности использует тот же сетевой путь, что и клиент удаленного управления VMRC, поставляемый вместе с Virtual Server (который является клиентским приложением, а не веб-интерфейсом). Это означает, что необходим доступ к следующим портам:
  • порт 5900 – порт сервера VMRC по умолчанию;
  • порт 1024 – порт веб-узла администрирования по умолчанию;
  • порты 137 и 138 – порты протокола UDP для центра предоставления билетов Kerberos V5;
  • порт 135 – используется сопоставителем конечных точек RPC.
Дополнительные сведения приведены на веб-узле microsoft.com/technet/prodtechnol/virtualserver/2005/proddocs/vs_operate_using_VMRC_manageVMs.mspx.

Использование Windows PE
Я прочитал статью «Знакомство с Windows PE» (сентябрь 2006 г., technetmagazine.com/issues/2006/09/WindowsPE). Я пытаюсь запустить Windows® PE в среде рабочей станции VMWare с сетевой поддержкой, но никак не удается предоставить Windows PE доступ к сети с помощью драйвера сетевого адаптера. Я выполняю загрузку из VMWare при помощи файла ISO образа Windows PE. Система Windows PE запускается, и появляется командная консоль, но при вводе команды ipconfig IP-адрес не отображается. Разрешение адреса с моего сервера DHCP также невозможно.
— Джон С.

Проблема заключается в том, что устанавливаемый VMware сетевой адаптер по умолчанию не поддерживается системой Windows Vista® (на которой основана система Windows PE 2.0). Необходимо указать другой тип сетевого адаптера в файле настройки виртуальной машины (файл VMX) следующим образом:
ethernet0.virtualDev = "e1000"
Это необходимо выполнить вручную, исправив файл VMX в текстовом редакторе, например, «Блокнот» — его правка в каком-либо графическом интерфейсе пользователя невозможна. Существующий встроенный виртуализованный сетевой адаптер будет заменен гигабитным адаптером Intel, поддерживаемым системой Windows Vista. Что самое главное, изменение этого значения означает отсутствие необходимости добавления каких-либо сетевых драйверов.

Оптимизация производительности запросов в SQL Server
В статье «Оптимизация производительности запросов SQL Server» (ноябрь 2007 г., technetmagazine.com/issues/2007/11/SQLQuery) автором был приведен пример SQL Server™ 2005 для поиска 20 самых дорогих выполняющихся запросов. Однако он не работает в SQL Server 2000. Можете ли вы привести пример, работающий в старой версии?
— Арун Н.

К сожалению, эти сведения невозможно получить в SQL Server 2000 — SQL Server 2000 не выполняет сбор и предоставление такой информации для запросов в кэше процедур. Эти сведения становятся доступными только в новом наборе динамических административных представлений, представленном в SQL Server 2005.

Приложение MIISWorkflow не работает
После прочтения статьи «Построение процесса одношаговой подготовки» (май 2007 г., technetmagazine.com/issues/2007/05/Workflow) у меня возникло несколько вопросов. Поддерживается ли приложение MIISWorkflow? Совместимо ли оно с платформой .NET Framework 2.0? При попытке открытия приложения не в Visual Studio® появляется сообщение об ошибке «Service Unavailable» (Служба недоступна). Приложение успешно запускается в режиме отладки, но при закрытии Visual Studio и попытке открытия приложения напрямую появляется это сообщение об ошибке. Что вызывает остановку пула приложений и/или возникновение ошибки «Service Unavailable»?
— Клифф С.

Приложение MIISWorkflow не является официально поддерживаемым продуктом Майкрософт. Оно предоставляется в качестве образца кода только для целей обучения.
Наилучшим местом для обсуждения проблем, относящихся к управлению удостоверениями, является веб-узел форумов TechNet по управлению удостоверениями по адресу forums.microsoft.com/TechNet/ShowForum.aspx?ForumID=540&SiteID=17. Эти форумы, управление которыми осуществляют члены групп продуктов Microsoft и эксперты сообщества, являются одним из лучших источников для решения подобных проблем.


 Инструментарий: Новые продукты для специалистов по информационным технологиям
Инструментарий
Новые продукты для специалистов по информационным технологиям
Грег Стин

Управление Windows PowerShell
PowerGUI
powergui.org
Те, кто еще не начал использовать Windows PowerShellTM, вероятно, начнут в скором времени ее использовать. Windows PowerShell превращается в основное средство администрирования Windows Server®. Прежде всего, она стала основой для управления через сценарии в Exchange Server 2007.
Чтобы оптимально использовать Windows PowerShell в ее собственном формате, необходимо запомнить изрядный объем синтаксиса, командлетов и общих структур. Само собой, не у всех на это есть время (или лишние нервы). Помочь могла бы централизованная графическая административная консоль управления сценариями, а также интерфейс пользователя, который предоставлял бы настраиваемые шаблоны, возможности правки по образцу IntelliSense® и базу сетевого сообщества для обмена сценариями. С помощью среды такого рода можно было бы быстро создавать сценарии для необходимых задач и всегда знать, где они находятся, на случай повторного использования или сверки с ними.
Не беспокойтесь – все это теперь уже не просто мечты. Основанную на графическом интерфейсе пользователя среду для Windows PowerShell обещает предоставить PowerGUI, бесплатный программный продукт, спонсируемый компанией Quest Software. Хотя на момент написания этой статьи существует только бета-версия данного приложения, оно предлагает простой в использовании, расширяемый графический интерфейс пользователя, производящий впечатление намного улучшенной версии консоли управления Microsoft® Management Console (MMC).
Внутри данного графического интерфейса можно запустить любой из поставляемых с ним сценариев или собственных сценарий пользователя посредством двойного щелчка и получить возвращенный им набор данных в виде таблицы. Для отбора нужной информации можно применять фильтры столбцов и значений. Кроме того, можно добавлять специальные пользовательские столбцы, поставляющие расчетные значения или специальные результаты соответствующие конкретным нуждам.
Из графического интерфейса можно запустить командную строку Windows PowerShell или встроенный редактор сценариев приложения. Редактор сценариев предоставляет базовую среду, напоминающую IntelliSense, которая демонстрирует синтаксис доступных командлетов, а также стандартные возможности файлов и правки, такие как поиск и замена, печать, вырезка, копирование и вставка. Здесь также можно помечать нужные действия закладками.
Вдобавок, PowerGUI предоставляет набор настраиваемых и расширяемых действий, которые можно применить к набору данных. Например, сценарий локальных системных служб позволяет запускать, останавливать, приостанавливать определенную службу и определять ее свойства. Другой полезной возможностью является добавление связей между сценариями, что позволяет создать цепь из общих элементов сценариев для получения необходимой информации. Например, можно получить список пользователей от определенной группы, а затем привязать его к сценарию, отображающему объем данных в их домашнем каталоге. В дополнение к этим возможностям PowerGUI располагает несколькими встроенными сценариями типовых действий для отчетов и проверок, позволяющих выводить данные в форматы XML, CSV, HTML и буфер обмена.
Как действия отдельных сценариев, так и общие действия можно разворачивать, добавляя собственные действия или правя один из предоставленных шаблонов. Вызов окна свойств для сценария позволяет заменять этот сценарий или просто смотреть, как он работает.
Ценные возможности также предоставляет библиотека сообщества веб-узла PowerGUI, где пользователи могут выкладывать и загружать сценарии, помогающие в системном администрировании. Здесь можно найти сценарии и действия для управления Active Directory® или сервером Exchange, задач Microsoft Operations Manager или общих задач Windows Server и многого другого. PowerGUI является хорошей основой для основанного на графическом интерфейсе расширяемого административного средства под Windows PowerShell.

Цена: бесплатно
Simplify Windows PowerShell with a graphical UI
Simplify Windows PowerShell with a graphical UI

Помните об экологии при покупках
Средство оценки воздействия электронного продукта на окружающую среду
epeat.net
Если смотреть на вещи с точки зрения экологии, необходима оценка общей стоимости компьютера в течении всего срока службы. Она включает в себя всю энергию, потраченную на производство, использование и утилизацию компьютера (не говоря уже о таких факторах, как использованные материалы и образовавшиеся отходы). Рассчитанная таким образом, общая стоимость получается довольно ошеломляющей. (Обзор финансовых и природоохранных издержек приведен в статье Дейва Охары (Dave Ohara) в выпуске журнала TechNet Magazine, за октябрь 2007 г., доступном на technetmagazine.com/issues/2007/10/Green.)
К счастью, все большее число пользователей и корпораций осознают издержки и воздействие на окружающую среду, связанные с их инфраструктурой. Как следствие, они начинают искать продукты, уменьшающие энергопотребление. Новое средство для специалистов по ИТ, пытающихся помочь компаниям решить эту проблему, создано организацией Green Electronics Council (greenelectronicscouncil.org ).
Это средство, названное EPEAT (сокращение от Electronic Product Environmental Assessment Tool – «Средство оценки воздействия электронного продукта на окружающую среду»), оценивает электронные продукты по 51 различному критерию воздействия на окружающую среду – 23 из этих критериев обязательны, а 28 добавляются по желанию. Продукт предусматривает следующие нормативы: Бронзовый (подразумевающий, что продукт отвечает обязательным критериям), Серебряный (продукт отвечает также 50% необязательных критериев) и Золотой (продукт соответствует обязательным и 75% либо большему проценту необязательных критериев).
Критерии охватывают все факторы жизненного цикла продукта –– от материалов, выбранных для производства, до потребления мощности при использовании и того, что с ним происходит по окончании срока. Требуемые критерии стандарта в основном охватывают декларации о воздействии продукта на среду, такие как указание на то, насколько широко в продукте применяется повторно используемая пластмасса; перечень содержащихся в продукте материалов, требующих специальной переработки, и указание на то, насколько широко повторно используемые материалы применяются в упаковке продукта. (Все продукты, внесенные в реестр EPEAT на данный момент, соответствуют стандартам ENERGYSTAR 3.0 и с конца января 2008 г. будут соответствовать стандарту ENERGYSTAR 4.0.)
Вдобавок, сертифицированные продукты должны располагать службой возврата как для самого продукта, так и для его аккумуляторов (если последние используются). Другим интересным требованием является доступность трехлетней гарантии или соглашения на обслуживание, что в теории помогает продлить срок службы устройства, понижая общее негативное влияние частой замены устройств.
Некоторые необязательные стандарты охватывают устранение их конструкции определенных тяжелых металлов (таких как кадмий), модульную конструкцию, сертификацию природоохранных практик компании сторонними организациями и различные уровни пригодности к переработке.
В настоящий момент есть четыре категории доступных продуктов: переносные и настольные компьютеры, мониторы и интегрированные системы. Число категорий продолжит расти, так, появление стандартов для серверов запланировано на 2009 год.
Большинство крупных производителей участвует в этой программе. Этому помог указ президента США номер 13423 за январь 2007, оговаривающий, что при приобретении федеральными органами электронных продуктов в рамках выполнения его требований не менее 95% приобретаемых продуктов должны быть продуктами, входящими в реестр EPEAT (whitehouse.gov/news/releases/2007/01/20070124-2.html).
Так что тем, кто пока не обращает внимания на воздействие своих покупок на окружающую среду, стоит озаботиться знакомством со средством оценки EPEAT, позволяющим указать продукты, покупка которых может свести к минимуму это воздействие (и собственные затраты).

Цена: бесплатно
Use EPEAT to assess the environmental impact of your hardware puchases
Use EPEAT to assess the environmental impact of your hardware puchases

Рецензия на книгу
Windows Vista Administrator's Pocket Consultant
microsoft.com/MSPress/books/9588.aspx
Тем, кто готовится к внедрению Windows Vista® в своей организации, может помочь в быстром ознакомлении с новыми возможностями и функциями книга Windows Vista Administrator's Pocket Consultant («Карманный консультант администратора Windows Vista») (изд-во Microsoft Press, 2006 г.). Формат книги и глубина изложения материала будут привычны тем, кто читал другие книги из серии «Карманный консультант администратора». Она не охватывает всех тонкостей, но дает качественный, широкий обзор возможностей и функций, описание выполнения конкретных задач администратора и памятки, касающиеся работы Windows Vista. Содержимое книги явно нацелено на системных администраторов, а не на конечных пользователей.
Книга начинается с вводной информации о версии 2.0 среды предустановки Windows, а также краткого обзора служебных программ, которыми можно воспользоваться в ходе автоматической или интерактивной установки. Затем книга переходит к управлению системами Windows Vista, показывая использование таких средств, как msconfig, для отладки или подгонки установок, а также новые возможности, такие как Previous Versions («Предыдущие версии»), позволяющие вернуть папку или файл в их прежнее состояние. Кроме того, книга представляет средства, помогающие в управлении оборудованием и устройствами компьютеров.
Затем книга охватывает подгонку манеры работы, предоставляемой Windows®, под требования пользователей путем настройки интерфейса и рабочего стола. Например, в ней рассказывается, как уменьшить потребление ресурсов экранной заставкой, изменить запуск и подбор программ в меню «Пуск», а также настроить боковую панель Windows. В книге также приведено описание создания собственных панелей инструментов для предоставления конечным пользователям быстрого доступа к общим папкам и файлам из панели задач.
В разделе по установке и обслуживанию программ и возможностей Windows Vista рассказывается о таких средствах, как проводник по программам, который делает возможным быстрый просмотр автоматически запускающихся программ, работающих в настоящий момент программ, подключенных к сети программ и поставщиков услуг Winsock. Затем излагается управление пользователями, профили, проблемы мобильности, политики компьютера и пользователя, а также управление дисками, безопасность файлов и использование общих ресурсов. Говоря конкретнее, объясняется, как создавать пользователей, управлять входом в систему Windows посредством групповой политики и создавать записи архива ключей, которые облегчают пользователям доступ к защищенным паролями ресурсам.
В разделе, посвященному мобильности, рассказывается о том, как новая альтернативная конфигурация сети позволяет указать отдельные конфигурации для «офиса» и «поездки». Пользователи могут легко переключаться между ними.
В главе "Managing File Security and Resource Sharing" («Управление безопасностью файлов и использованием общих ресурсов») излагаются основы настройки разрешений для доступа к файлам и папкам NTFS, а также работы специальных разрешений Windows (и управления ими). В ней также можно узнать о том, как создавать общие ресурсы, подключаться к ним и сохранять подключения.
В области управления дисками в книге содержится введение в настройку выделенного дискового пространства, в котором рассказано не только о том, как создавать, просматривать, обновлять и удалять выделенные дисковые пространства, но и как экспортировать и импортировать их параметры для последующего использования.
Книга содержит довольно подробное рассмотрение работы двойного сетевого стека IPv4/IPv6 в Windows Vista. В ней также можно увидеть, как настраивать сетевые адаптеры для среды.
Завершают книгу раздел о оптимизации Windows Vista с целью обеспечения наилучшего обслуживания пользователей и короткая глава по основным методикам устранения неполадок. В ней можно найти способы установки удаленного помощника, поддержания работоспособности системы посредством проверки и дефрагментации диска по расписанию, а также создания резервных копий. В целом, книга является удобочитаемым кратким справочником по администрированию Windows Vista.

Цена: 29,99 долларов США при прямых поставках.

Наблюдение за веб-узлом
Pingdom.com
pingdom.com
Я уже говорил об этом ранее и буду говорить всегда: профилактичекий подход к системному администрированию экономит нервы и помогает избегать неловких моментов вроде получения сообщения электронной почты от босса с заголовком «Знаете ли вы о том, что веб-узел вышел из строя?»
Для такого подхода крайне важно хорошее средство наблюдения за сетью. Если не все системные администраторы, то большинство, вероятно, уже применяют какой-либо сервер наблюдения за внутренней сетью. Но как насчет тех, кто озабочен глобальным присутствием, для которого нужно обеспечить доступность выходящих в Интернет служб?
Pingdom.com, поставщик прикладных услуг (ASP), предоставляет простую, но эффективную автоматическую службу наблюдения. Серверы ASP распределены по всему земному шару и дают гораздо лучшее представление о том, что реально испытывают пользователи, по сравнению с использованием одного внешнего средства наблюдения за службами.
Чтобы приступить к работе, подпишитесь на учетную запись и установите свое местонахождение, установив нужные часовой пояс, страну, формат даты и числовой формат. Затем установите информацию о контактных лицах, предоставив имена, телефонные номера SMS и адреса электронной почты для уведомлений. После этого создайте новую задачу наблюдения, определив имя, разрешение задачи, тип задачи наблюдения, выполняемой при разрешении, а также тип, интервалы уведомлений и адреса, на которые их следует отправлять, для этой задачи.
Стандартный пакет учетной записи дает проверки, которые могут разрешаться с интервалом от 1 до 60 минут, позволяя подогнать запросы под наблюдаемую службу. Уведомления могут отсылаться по предоставленному адресу электронной почты или через SMS. Кроме того, можно определить число оставшихся без ответа запросов, после которого отсылается уведомление, вместе с числом циклов отказа, после которого уведомление отсылается снова (пока не будут отосланы четыре напоминания). Вдобавок, можно также указать компании pingdom отсылать уведомление при возобновлении работы службы – это очень полезно при проверке времени обслуживания веб-узла или службы. Говоря об обслуживании, можно также приостановить или прекратить проверки, чтобы избежать ложных срабатываний при запланированных процедурах.
Служба предоставляет пользователям четыре основных типа проверок: датчик HTTP, датчик порта TCP, датчик запросов и датчик UDP. Датчик HTTP позволяет установить URL/IP, производится ли запрос через SSL, порт, имя пользователя и пароль для обычной проверки подлинности или базовую строку проверки содержимого на наличие или отсутствие образца. Датчик порта TCP позволяет определить служебный порт и IP/домен для проверки. Датчик запросов позволяет установить IP или домен для проверки через ICMP. Датчик же UDP определяется через IP/домен, порт, строку, которую следует послать этому сочетанию, и ожидаемую сроку ответа. По сути, это позволяет проверять доступность веб-узлов, серверов FTP, серверов SMTP и многого другого из различных географических точек.
Служба также предоставляет несколько отчетов, помогающих сделать архивные данные наглядными. Эти отчеты показывают процент времени, в течение которого указанная служба оставалась работоспособной в указанном месяце, и среднее время ответа за указанный период. Можно также получить подробное представление для каждого случая проверки, отображающее метку времени, состояние, время ответа и сервер, с которого выполнялась проверка. Дополнительно представляются уведомления – показывается, когда, сколько, кому и какими способами их было отправлено за указанный период времени. Эти отчеты можно сделать общедоступными, чтобы другие сотрудники организации могли смотреть статистику работы служб. При наличии у заказчика собственного сетевого операционного центра (NOC) pingdom.com также предоставляет интерфейс API веб-службы, у которой можно запрашивать эту информацию, что позволяет интегрировать службу в текущие представления приборной панели.

Цена: 9,95 долларов США в месяц.
Pingdom.com monitors your Web services with a global perspective
Pingdom.com monitors your Web services with a global perspective

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


 Exchange – очередь за ответами: Добавление голосовых приглашений, выбор УАТС и другое
Exchange – очередь за ответами
Добавление голосовых приглашений, выбор УАТС и другое
Сима Рахман

В: Я слышал, что единая система обмена сообщениями Exchange не предлагает высокую доступность или кластеризацию Так ли это?
О: Хотя единая система обмена сообщениями не поддерживается в кластерах или сетях с балансировкой нагрузки, решение высокой доступности вполне может быть достигнуто из определенных шлюзов. Ключевым действием здесь является назначение нескольких серверов единой система обмена сообщениями для циклического перебора трафика. Можно также организовать маршрутизацию нужного трафика на определенный сервер единой система обмена сообщениями при условии, что у шлюза есть необходимые дополнительные возможности по маршрутизации. Например, задачей одного сервера единой система обмена сообщениями можно сделать обеспечение доступа абонентов, а другого – вызовы автосекретаря. Это позволяет балансировать трафик единой система обмена сообщениями соответственно имеющейся инфраструктуре и требованиям среды.

В: Можно ли добавить голосовые приглашения к телефонному номеру моей компании с помощью единой система обмена сообщениями Exchange?
О: Да можно, равно как и установить автосекретарь. В статье «Управление настраиваемыми голосовыми приглашениями» на technet.microsoft.com/aa998818 подробно описаны действия по настройке этой возможности.

В: Как узнать, совместима ли моя учрежденческая автоматическая телефонная станция (УАТС) с единой система обмена сообщениями Exchange?
О: Некоторые шлюзы протестированы Майкрософт и рекомендованы для использования с единой системой обмена сообщениями Exchange. Поставщики, создающие такие шлюзы, предоставляют список УАТС, работающих с их шлюзом. Если используемая УАТС внесена в список одним из поставщиков, она совместима с единой системой обмена сообщениями Exchange.
В статье «Советник по телефонии для Exchange Server 2007», доступной на microsoft.com/technet/prodtechnol/exchange/telephony-advisor.mspx, имеется список поддерживаемых шлюзов и много другой существенной информации.

В: Требует ли использование единой системы обмена сообщениями Exchange добавления специального оборудования к телефонной системе?
О: Сервер единой системы обмена сообщениями Exchange служит поставщиком услуг голосовой почты. Для работы с системой телефонии он может потребовать установки нового оборудования.
При использовании поддерживаемой УАТС, работающей по протоколу IP, дополнительного оборудования не нужно, но может понадобиться настройка некоторых параметров УАТС для работы с единой системой обмена сообщениями.
При использовании чего-либо, кроме поддерживаемой УАТС, работающей по протоколу IP, необходимо сперва определить, совместимо ли это оборудование с одним из поддерживаемых шлюзов. Также необходим поддерживаемый шлюз VoIP.
В число сведений на microsoft.com/technet/prodtechnol/exchange/telephony-advisor.mspx входит список поддерживаемого оборудования, включая УАТС, работающие по протоколу IP, и шлюзы. Не забывайте сверяться с ней регулярно, поскольку список часто обновляется по мере сертификации нового оборудования корпорацией Майкрософт. Кроме того, можно получить консультацию у местного специалиста по единой системе обмена сообщениями, чтобы определить требования к оборудованию для своей среды.

В: Как единая система обмена сообщениями поддерживает факс?
О: В настоящий момент единая система обмена сообщениями предоставляет возможность обработки входящих факсов – факс, отправленный пользователю единой системы обмена сообщениями, окажется в папке «Входящие» пользователя как сообщение электронной почты, в которое вложено факсимильное сообщение в виде файла TIFF. Подробный обзор доступен на technet.microsoft.com/ bb232022.

В: У меня есть УАТС, работающая по протоколу IP, марки Nortel CS1000, и я хочу использовать единую систему обмена сообщениями в Exchange Server 2007. Но я не знаю, как заставить эти две системы работать вместе. Могу ли я использовать УАТС Nortel CS1000 как шлюз, или только Intel с Audio Codes поддерживаются как шлюзы? Также необходимо обеспечить прохождение системой Exchange проверки подлинности на сервере CS1000.
О: Nortel CS1000 является поддерживаемой УАТС, работающей по протоколу IP, при условии, что используется версия 5.0 микропрограммного обеспечения для УАТС, работающих по протоколу IP. Для работы с ней не нужно дополнительного оборудования. На веб-узле Nortel имеются заметки по настройке УАТС, работающих по протоколу IP: support.nortel.com/go/main.jsp?cscat=docdetail&id=626197&poid=14261. Поддерживаемые шлюзы, УАТС и версии микропрограммного обеспечения можно найти на microsoft.com/technet/prodtechnol/exchange/pbx-partners.mspx.

Сима Рахман работает в Майкрософт шесть лет. Как инженер по улучшению поддержки, она помогает пользователям решать сложные проблемы с Exchange Server. Сима особенно тепло вспоминает о своем участии в работе над бета-версией Exchange 2007, где она занималась единой системой обмена сообщениями.


 Обзор служебных программ: Средство переноса Windows Easy Transfer Companion
Обзор служебных программ
Средство переноса Windows Easy Transfer Companion
Ланс Уитни
Эта статья написана с использованием предварительной версии средства переноса Windows Easy Transfer Companion. Любые содержащиеся в ней сведения могут быть изменены.

Настало время переносить своих пользователей с их старых систем Windows® XP на новые машины Windows Vista®. Наибольшую часть трудов при любом переносе составляет переустановка приложений пользователей на их новых ПК – и обеспечение работы этих приложений. Теперь бесплатное средство от Майкрософт может избавить от этих бесконечных переустановок. Windows Easy Transfer Companion (WETC) может копировать ключевые программы с Windows XP на Windows Vista.
Существующий сейчас в бета-версии, WETC отличается от мастера переноса данных Windows в Windows Vista. В то время как мастер копирует файлы данных, параметры программ и профили пользователей, WETC копирует целые приложения, хотя и только с Windows XP SP2 в Windows Vista. Использование переноса требует учетной записи администратора.
WETC устанавливается и на исходном, и на целевом компьютерах. ПК могут сообщаться друг с другом по сети или с помощью кабеля передачи данных для USB. Драйвер для этого кабеля включен вWindows Vista; в Windows XP его понадобится установить с компакт-диска продукта.
WETC provides a categorized list of transferable apps
WETC provides a categorized list of transferable apps
После подключения кабеля запустите WETC на компьютере с Windows XP. Служебная программа проверяет жесткий диск, собирает основную информацию о системе и анализирует все установленное ПО. По завершении этого процесса запустите WETC на компьютере с Windows Vista. Программа свяжется с компьютером, использующим Windows XP, чтобы отобразить список всех обнаруженных приложений, разделенный на три категории (см. снимок экрана выше):
  1. Хорошо переносимые программы – ПО, которое будет перенесено и начнет работать на Windows Vista без проблем.
  2. Программы, переносимые с возможными ограничениями – ПО, котое может быть перенесено, но без гарантии правильной работы на новом месте.
  3. Программы, которые не будут перенесены – ПО, которое не будет работать на Windows Vista и не включается в перенос.
Для каждой из программ, успешный перенос которой невозможен, WETC дает краткое объяснение, почему. Как правило, приложения могут быть непригодными к копированию из-за отсутствия ключевой информации, такой как информация установщика, несовместимости Windows Vista или оттого, что они уже имеются на компьютере с Windows Vista. Кроме того, WETC не копирует некоторые типы программ, такие как антивирусы и служебные программы системы. Также он не передает платформы операционных систем, такие как Microsoft .NET – их нужно будет установить на Windows Vista перед копированием приложений, которым они требуются.
Выберите из списка программ те, которые нужно скопировать. Экран справки может помочь в принятии решения и устранении проблем. Можно также сохранить предшествующий переносу отчет, перечисляющий все программы, которые будут и не будут перенесены.
Затем произойдет перенос, копирование данных, относящихся к каждой программе. В конце сообщение о состоянии покажет, какие программы были скопированы и произошли ли ошибки. Подробный отчет о переносе можно сохранить. После выхода из WETC перезагрузите компьютер с Windows Vista, войдите в систему и запустите перенесенные программы, чтобы убедиться в их работоспособности
Какие то проблемы? Папка WETC Programs в Windows Vista включает ярлык для средства Resources («Ресурсы») с функцией отмены, которая может удалить все приложения, скопированные на Windows Vista, но информация, на которой это основано, хранится только три дня. Получить дополнительные сведения о Windows Easy Transfer Companion и загрузить последнюю версию можно на support.microsoft.com/kb/931696.

Ланс Уитни — консультант по информационным технологиям, преподаватель и разработчик технической документации. Он провел бессчетные часы за настройкой рабочих станций и серверов Windows. Журналист по профессии, 15 лет назад он перешел на изучение информационных технологий.


 Кабельщик: Усовершенствования в Windows Server 2008, относящиеся к DNS.
Кабельщик
Усовершенствования в Windows Server 2008, относящиеся к DNS.
Джозеф Дэвис
Эта статья основана на предварительной версии Windows Server 2008. Любые приведенные в ней сведения могут быть изменены.

Корпорация Майкрософт помещала сервер службы доменных имен (DNS) во все версии Windows Server со времен Windows NT 4.0. DNS – это иерархическая, распределенная база данных, содержащая сопоставления доменных имен DNS с различными типами данных, например IP-адресами. В Windows Server 2008 в состав службы сервера DNS входят
новая фоновая загрузка зон, улучшенная поддержка IPv6, поддержка контроллера домена «только для чтения» (RODC) и возможность размещать глобальные однокомпонентные имена.

Фоновая загрузка зон
Служба сервера DNS в Windows Server® 2008 ускоряет получение данных, применяя фоновую загрузку зоны. Ранее предприятия с зонами, содержащими большое число записей в Active Directory®, испытывали задержки длиной до часа, когда служба сервера DNS в Windows Server 2003 при перезапуске пыталась получить данные DNS из Active Directory. В течение этих задержек сервер DNS не мог выполнять запросы клиентов DNS для всех своих размещенных зон.
Чтобы решить эту проблему, служба сервера DNS в Windows Server 2008 получает данные о зоне из Active Directory в фоновом режиме после своего запуска, что дает возможность отвечать на запросы данных из других зон. При запуске службы она создает один или несколько потоков исполнения для загрузки зон, сохраненных в Active Directory. Благодаря наличию отдельных потоков для загрузки основанных на Active Directory зон служба сервера DNS может отвечать на запросы по ходу загрузки зон. Если клиент DNS запрашивает данные из уже загруженной зоны, сервер DNS отвечает соответственно. Если запрос относится к данным из зоны, которая еще не получена полностью, сервер DNS вместо этого извлекает конкретные данные из Active Directory.
Возможность получения конкретных данных из Active Directory в ходе загрузки зоны предоставляет дополнительное преимущество перед хранением информации о зонах в файлах – а именно возможность службы сервера DNS отвечать на запросы немедленно. Когда зона сохранена в файлах, службе приходится последовательно читать файл, пока данные не будут найдены.

Улучшенная поддержка IPv6
IPv6, о котором было рассказано в предыдущих выпусках данной рубрики – это новый набор стандартных протоколов Интернета. IPv6 разработан для решения ряда проблем текущей версии (IPv4), включая истощение запаса адресов, необходимость расширяемости, а также проблемы безопасности и автоматической настройки.
Одно из преимуществ IPv6 заключается в 128-разрядной длине адресов, адреса же в IPv4 имеют длину всего 32 бита. Адреса в IPv6 записываются в виде шестнадцатеричных чисел, разделенных двоеточиями. Каждая цифра в шестнадцатеричном числе – это 4 бита адреса в IPv6. Полный адрес в IPv6 состоит из 32 шестнадцатеричных цифр в 8 блоках, разделенных двоеточиями. Вот пример полного адреса в IPv6 – FD91:2ADD:715A:2111:DD48:AB34:D07C:3914.
Прямое разрешение имен для адресов в IPv6 использует запись DNS узла IPv6, известную как запись AAAA. Для обратного разрешения имен IPv6 использует домен IP6.ARPA, и каждая шестнадцатеричная цифра из 32, составляющих адрес IPv6, становится отдельным уровнем в обратной иерархии домена в обратном порядке. Например, при обратном просмотре имя домена для адреса FD91:2ADD:715A:2111:DD48:AB34:D07C:3914 будет таким – 4.1.9.3.C.7.0.D.4.3.B.A.8.4.D.D.1.1.1.2.A.5.1.7.D.D.A.2.1.9.D.F.IP6.ARPA.
Служба сервера DNS в Windows Server 2003 поддерживает прямое и обратное разрешение имен для IPv6; однако поддержка интегрирована не полностью. Например, для создания адресной записи IPv6 (записи AAAA, о которой я только что рассказал) в оснастке диспетчера DNS для Windows Server 2003 необходимо щелкнуть правой кнопкой мыши зону, щелкнуть Other New Records («Прочие новые записи») и затем дважды щелкнуть узел IPv6 (AAAA) как тип записи ресурса. Чтобы добавить запись AAAA в оснастку диспетчера DNS для Windows Server 2008, щелкните правой кнопкой мыши имя зоны, а затем щелкните New Host («Новый узел») (A или AAAA). В диалоговом окне New Host («Новый узел») можно ввести адрес IPv4 или IPv6. Рис 1 показывает пример этого.
Рис. 1 Диалоговое окно «Новый узел»
Рис. 1 Диалоговое окно «Новый узел»
Другим примером улучшенной поддержки IPv6 является поддержка обратных зон IPv6. Чтобы создать обратную зону просмотра в оснастке диспетчера DNS для Windows Server 2003, необходимо вручную ввести ее имя на странице Reverse Zone Lookup Name («Имя просмотра обратной зоны») мастера создания новых зон. Вот пример имени обратной зоны DNS – 1.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa (для подсети IPv6, префикс 2001:db8:0:1::/64, полностью выражается как 2001:0db8:0000:0001::/64).
Обратные зоны IPv6 в оснастке диспетчера DNS для Windows Server 2008 теперь полностью интегрированы в мастер создания новых зон. В мастере теперь имеется новая страница, предлагающая выбрать зону обратного просмотра IPv4 или IPv6. Для зоны обратного просмотра IPv6 достаточно ввести префикс подсети IPv6 и мастер автоматически создаст такую зону. На рис. 2 приведен соответствующий пример.
Рис. 2 Именование зоны обратного просмотра IPv6
Рис. 2 Именование зоны обратного просмотра IPv6
Дополнительным усовершенствованием для обратных зон является способ, которым оснастка DNS Manager отображает записи указателя (PTR) IPv6. На рис. 3 показано, как запись PTR отображается в оснастке диспетчера DNS для Windows Server 2003.
Рис. 3 Запись указателя PTR для IPv6 в Windows Server 2003
Рис. 3 Запись указателя PTR для IPv6 в Windows Server 2003
При этом верно отражается структура пространства имен DNS для обратных имен доменов IPv6, но управление записями PTR для адресов IPv6 усложняется. На рис. 4 показано, как запись PTR отображается в оснастке диспетчера DNS для Windows Server 2008.
Рис. 4 Запись указателя PTR для IPv6 в Windows Server 2003
Рис. 4 Запись указателя PTR для IPv6 в Windows Server 2003
Служба сервера DNS в Windows Server 2003 поддерживает работу IPv6, но ее необходимо включить вручную посредством команды dnscmd /config /EnableIPv6 1. Напротив, Windows Server 2008 поддерживает работу через IPv6 по умолчанию. Средство командной строки Dnscmd.exe в нем обновлено, чтобы принимать адреса IPv6 в параметрах командной строки. Вдобавок, служба сервера DNS теперь может отправлять рекурсивные запросы серверам, работающим только на IPv6, а список сервера пересылки может содержать как адреса IPv4, так и IPv6.
Для получения дополнительных сведений о IPv6 и его поддержке в Windows® посетите страницу microsoft.com/ipv6.

Поддержка контроллера домена «только для чтения»
Windows Server 2008 также предлагает пользователям RODC, новый тип контроллера домена, который содержит копию информации Active Directory, предназначенную только для чтения, и может выполнять функции Active Directory, но не может быть настроен напрямую. Контроллеры RODC менее уязвимы для атак и могут быть размещены там, где физическую безопасность контроллера домена нельзя гарантировать, или там, где сеть может содержать потенциально вредоносные узлы.
Для контроллеров RODC служба сервера DNS в Windows Server 2008 поддерживает новый основной тип зоны «только для чтения». Когда компьютер становится контроллером RODC, он реплицирует полную копию «только для чтения» всех разделов каталога приложений, используемых DNS, включая раздел домена, ForestDNSZones и DomainDNSZones. Это гарантирует, что служба сервера DNS, работающая на контроллере RODC, будет располагать полной и предназначенной только для чтения копией всех зон DNS, сохраненных в разделах каталога контроллера домена, не являющегося контроллером RODC. Содержимое основной зоны «только для чтения» можно просматривать на контроллере RODC, но нельзя на нем изменять. Изменения необходимо производить на контроллере домена, не являющемся контроллером RODC.

Зона GlobalNames
Разрешение имен с помощью зоны GlobalNames
После того, как зона GlobalNames развернута, при попытке работающего на Windows Vista клиента DNS разрешить однокомпонентное имя она прикрепляет основной суффикс DNS к этому имени и направляет запрос об этом имени своему серверу DNS.
Если имя не найдено, клиент DNS отправляет дополнительные запросы о сочетании однокомпонентного имени с суффиксами в своем списке суффиксов DNS (если он настроен). Если ни одно из этих имен не разрешается, клиент запрашивает разрешения, используя однокомпонентное имя.
Сервер DNS ищет однокомпонентное имя в своей зоне GlobalNames. Если оно там оказывается, сервер DNS отсылает разрешенный адрес IPv4 или FQDN клиенту DNS. В противном случае компьютер клиента DNS преобразует имя в имя NetBIOS и использует методики разрешения имен NetBIOS, включая WINS. Разрешение однокомпонентных имен в зоне GlobalNames не требует изменений в службе клиента DNS.

Windows Server 2008 и Windows Vista® поддерживают протокол NetBIOS через TCP/IP (NetBT). NetBT использует имена NetBIOS для определения приложений NetBIOS уровня сеанса. Хотя разрешение имен NetBIOS с помощью WINS необязательно для текущих версий Windows, которые используют DNS и сетевые приложения на основе сокетов Windows для разрешения имен, многие клиенты Майкрософт развертывают WINS в своих сетях для поддержки старых приложений NetBT и разрешения однокомпонентных имен в своих организациях. Однокомпонентные имена обычно обозначают важные, хорошо известные и широко используемые организацией серверы, такие как серверы электронной почты, центральные веб-серверы или серверы бизнес-приложений.
Чтобы позволить этим однокомпонентным именам разрешаться в организации, использующей только DNS, может понадобиться добавление записей типа A к нескольким доменам DNS, принадлежащим организации, что позволит работающим на Windows клиентам DNS разрешать имена вне зависимости от назначенного им суффикса или списка суффиксов домена DNS.
Предположим для примера, что у организации contoso.com есть центральный веб-сервер, именуемый CWEB и являющийся членом домена central.contoso.com. Чтобы реализовать однокомпонентное имя для сервера CWEB, тогда как клиенты DNS могут получить суффиксы домена DNS wcoast.contoso.com, central.contoso.com или ecoast.contoso.com, сетевой администратор должен создать две дополнительные записи типа A: для cweb.wcoast.contoso.com и для cweb.ecoast.contoso.com. Однако не забудьте, что вручную созданные записи для однокомпонентных имен необходимо сохранять на случай изменений в распределении адресов IPv4 или появления новых имен.
Если contoso.com уже использует WINS для старых приложений NetBT, сетевой администратор может применить разрешение имен для однокомпонентного имени CWEB, добавив одну статическую запись WINS к своей инфраструктуре WINS. Если адрес IPv4 изменяется, достаточно изменить единственную статическую запись WINS. Поскольку в WINS проще управлять однокомпонентными именами, многие сети, основанные на Windows, используют статические записи WINS для однокомпонентных имен.
Чтобы предоставить разрешение однокомпонентных имен в DNS, с которым так же просто работать, как и со статическими записями WINS, служба сервера DNS в Windows Server 2008 поддерживает новую зону для хранения однокомпонентных имен под названием GlobalNames. Областью репликации этой зоны обычно является лес, что обеспечивает разрешение однокомпонентных имен в целом лесе Active Directory. Кроме того, зона GlobalNames может поддерживать разрешение однокомпонентных имен в организации, содержащей несколько лесов, при использовании записей расположения служб (SRV) для публикации местонахождения зоны GlobalNames.
В отличие от WINS, зона GlobalNames предназначена для предоставления разрешения однокомпонентных имен ограниченному набору узлов, обычно центральным и особо важным серверам организации, управляемых ее отделом ИТ. Зона GlobalNames не предназначена для хранения имен настольных компьютеров или других серверов, адреса IPv4 которых могут меняться, и она ни в коем случае не поддерживает динамические обновления DNS. Она обычно используется для хранения псевдонимов (CNAME) записей ресурсов с целью сопоставления однокомпонентного имени с нужным полным доменным именем (FQDN). В сетях, которые используют WINS, зона GlobalNames обычно содержит записи ресурсов для имен, управляемых отделом ИТ, которые уже статически настроены в WINS.
Зона GlobalNames предоставляет разрешение однокомпонентных имен только в случае, если все полномочные серверы DNS используют Windows Server 2008. Однако прочие серверы DNS, не являющиеся полномочными для какой-либо зоны, могут использовать предыдущие версии Windows или другие операционные системы. В лесе должна быть только одна зона GlobalNames.
Для обеспечения максимальной производительности и масштабируемости зону GlobalNames следует интегрировать с Active Directory, а каждый из полномочных серверов DNS настроить с помощью ее локальной копии. Это необходимо для поддержки развертывания зоны GlobalNames в нескольких лесах.
Для получения дополнительных сведений о поддержке DNS в Windows и о развертывании зоны GlobalNames посетите веб-страницу Майкрософт, посвященную DNS: microsoft.com/dns.

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


 Windows PowerShell: Перехват вредоносных программных кодов
Windows PowerShell
Перехват вредоносных программных кодов
Дон Джонс

Помнит ли кто-нибудь времена бета-тестирования Windows Vista и слухов о самых первых версиях новой оболочки командной строки под кодовым названием «Monad»? (Последняя, само собой, теперь известна нам как Windows PowerShell.) В то время многие из крупнейших СМИ сообщали о «первом вирусе для Windows Vista». На
самом деле «вирус» был всего лишь опытно-экспериментальным вредоносным сценарием, атаковавшим «Monad». Для выполнения сценария «Monad» надо было специально настроить – он не работал при параметрах по умолчанию. Более того, к моменту появления этих сообщений корпорация Майкрософт уже объявила о том, что «Monad» не будет поставляться как часть Windows Vista®. В общем, весь этот шум возник из ничего (или, по крайней мере, из сущей мелочи).
Но по мере того, как Windows PowerShellTM становится более популярной (она уже была загружена более миллиона раз), возрастает вероятность ее использования для создания вредоносных сценариев. Возможность использования Windows PowerShell для написания потенциально вредоносного сценария – очевидный факт; любое средство администратора, хоть Windows PowerShell, хоть cmd.exe и VBScript, может быть использовано во вред. Поэтому нельзя автоматически считать, что файлы PS1 безвредны.
К счастью, параметры Windows PowerShell по умолчанию запрещают запуск сценариев, так что вредоносному сценарию для запуска нужна помощь пользователя. В этом месяце я хотел бы предсказать, как он попытается ее получить. Это не критика Windows PowerShell – я думаю, что в Майкрософт успешно справились с созданием оболочки сценариев, избегающей многих факторов риска. Тем не менее, я полагаю, что мой рассказ может помочь читателям быть готовыми к отражению возможных атак.

Безопасная по умолчанию
Стоит отметить, что Windows PowerShell – первый язык, разработанный корпорацией Майкрософт после появления известной инициативы по доверенным вычислениям. Эксперт по безопасности Майкл Говард (Michael Howard) (автор книги Writing Secure Code («Написание безопасного кода»)) работал вместе с группой Windows PowerShell. Он помог обеспечить наивысшую возможную безопасность кода, и, что наиболее важно, установку параметров оболочки по умолчанию на наивысший возможный уровень безопасности.
Для начала стоит кратко напомнить о первоначальных параметрах безопасностиWindows PowerShell. По умолчанию, оболочка не запускает файлы с расширением PS1 двойным щелчком. Это расширение связано с Блокнотом. На практике по умолчанию оболочка вообще не запускает сценарии благодаря встроенной возможности, именуемой политикой выполнения, которая описывает условия, при которых сценарий будет работать. «Заводские» параметры предусматривают установку политики ограниченного выполнения (Restricted), при которой выполнение сценариев запрещено, а оболочку можно использовать лишь интерактивно. Политику выполнения можно изменить, используя командлет Set-ExecutionPolicy или административный шаблон групповой политики (файл ADM) от Майкрософт. (Файл ADM можно загрузить по адресу go.microsoft.com/fwlink/?LinkId=102940.) На рис. 1 показаны возможные политики выполнения.
Рис. 1 Выбор безопасной политики выполнения
Рис. 1 Выбор безопасной политики выполнения
Из политики выполнения есть лишь считанные исключения. Если конкретнее, даже если установлена политика Restricted, оболочке позволено импортировать несколько конкретных файлов настройки в формате XML, предоставляемых Майкрософт и устанавливаемых вместе с оболочкой. Эти файлы используются для предоставления специальных функций, таких как расширения для типов Microsoft® .NET Framework и макетов форматирования по умолчанию для большинства типов объектов .NET. Очевидно, что оболочке стоит загружать эти файлы при запуске.
Хотя эти файлы и содержат исполняемый код, они снабжены цифровой подписью Майкрософт. Любые манипуляции с ними делают подпись бесполезной, и в таком случае оболочка не будет импортировать файлы при загрузке. Такая схема делает попытки внедрить в файлы вредоносный программный код не лучшей из идей.
Само собой, при политике выполнения Restricted сценарии профиля Windows PowerShell также не будут выполняться при запуске. Windows PowerShell не создает сценарий профиля по умолчанию, а ищет файлы с определенными именами в четырех определенных местах и, если они найдены, пытается выполнить их при каждом запуске. (Документация, устанавливаемая вместе с Windows PowerShell, предоставляет сведения о именах папок и файлов, используемых для сценариев профиля.) Профиль является основой уязвимости, о которой я собираюсь рассказать.

Изменение политики выполнения
Командлет месяца
К Set-AuthenticodeSignature прилагается Get-AuthenticodeSignature. Данный командлет разработан для изучения сценариев с цифровой подписью и предоставления сведений о подписи. Достаточно нацелить его на нужный файл, и можно будет увидеть, подписан ли файл, с помощью какого сертификата он подписан, цела ли подпись и так далее. Помимо работы со сценариями Windows PowerShell, данный командлет также работает с подписанными исполняемыми файлами:
PS C:\Program Files\Microsoft Office\Office12>
Get-AuthenticodeSignature excel.exe | Format-List *
Применив эту команду, я могу увидеть, был ли исполняемый файл подписан корпорацией Майкрософт с использованием сертификата центра сертификации Майкрософт.
Результаты применения команды
Результаты применения команды

Следует особо отметить, что при параметрах по умолчанию Windows PowerShell очень сложно, если вообще возможно, заставить выполнить любой код вообще, а уж тем более вредоносный. Вредоносные сценарии становятся угрозой лишь в случае изменения политики выполнения. Стоит прояснить, что эта статья не является предупреждающим сигналом о дырах в безопасности Windows PowerShell; ее цель – поделиться рекомендациями по укреплению безопасности систем.
Низшей из возможных политик выполнения является политика неограниченного выполнения (Unrestricted), которая позволяет всем сценариям запускаться без ограничений и вопросов – практически та же нежелательная ситуация, что знакома много лет по работе VBScript и пакетных файлов. Установка политики Unrestricted – это приглашение к действию для вредоносных сценариев. Если политика была установлена на Unrestricted, а потом до системы добрался вредоносный сценарий, будьте готовы доказать необходимость такой политики и сознаться в собственном решении, когда будете объяснять, почему вирус стер всю среду!
Следует все же отметить, что Windows PowerShell по-прежнему будет пытаться обнаружить загрузку сценариев из Интернета и предупредить пользователя перед их запуском, даже если установлена политика Unrestricted. Но смысл в том, что установка политики Unrestricted – дурная идея.

Подписывание сценариев
Наиболее безопасная политика выполнения, которая допускает выполнение сценариев – это политика выполнения всех подписанных сценариев (AllSigned). При ее установке выполняются только сценарии с целой цифровой подписью, которая была создана с использованием доверенного сертификата (а не просто любой старой подписью). Для подписывания сценариев необходимо приобрести цифровой сертификат класса III – конкретнее, сертификат для подписывания кода Microsoft Authenticode. Такие сертификаты можно получить от внутренней инфраструктуры открытых ключей (PKI) по месту работы или приобрести в коммерческом центре сертификации вроде CyberTrust, Thawte и VeriSign.
Если необходимо узнать, установлены ли на компьютере какие-то сертификаты, которые можно использовать для подписывания сценариев, следующий командлет покажет это:
Get-ChildItem CERT: -recurse –codeSigningCert
После установки сертификата на компьютере Windows® используйте командлет Set-AuthenticodeSignature для создания и применения цифровой подписи, которая будет выглядеть как набор бессмысленных строк в конце сценария. Некоторые из редакторов сценариев могут предлагать возможность добавления подписи к сценарию, включая удобную возможность автоматически подписывать сценарии при сохранении.
Политика AllSigned является лучшей для рабочей среды. Хотя она и не предотвращает полностью выполнение вредоносных сценариев, она гарантирует, что вредоносный сценарий будет подписан, то есть возможность отследить его автора (предполагая, что система Windows настроена принимать сертификаты только от доверенных центров сертификации, но этот вопрос несколько выходит за рамки статьи). Что любопытно, в Windows Script Host (WSH) 5.6 и более поздние версии можно установить похожий параметр TrustPolicy («Политика доверия»), также требующий цифровых подписей, но мне редко встречались использующие его администраторы.
Кратко обобщаем вышесказанное. При установке политики Restricted невозможно применять как вредоносные, так и полезные сценарии. Если установлена политика выполнения AllSigned, оболочка допускает выполнение подписанных сценариев, что довольно безопасно, поскольку у большинства авторов вредоносных сценариев нет желания прикреплять к своим произведениям подтвержденное, отслеживаемое удостоверение. С другой стороны, политика Unrestricted крайне небезопасна, и при ее использовании можно считать, что поражение вредоносным сценарием – лишь вопрос времени. (Обратите внимание, что я не считаю ее особенной уязвимостью, поскольку она и не претендует на надежное обеспечение безопасности – предполагается, что пользователи, устанавливающие эту политику, должны знать, что делают.)

Прокрадываясь с черного хода
Есть еще одна политика выполнения, требующая подпись от удаленных сценариев (RemoteSigned). Именно ее, как я полагаю, используют сейчас большинство администраторов, просто потому, что она считается более безопасной, чем Unrestricted, и требующей меньше хлопот, чем AllSigned. RemoteSigned не требует подписи от локальных сценариев. Файлы PS1, находящиеся на локальных дисках, будут работать, не будучи подписанными. Удаленные сценарии – в первую очередь, загруженные из Интернета с помошью Internet Explorer® или Outlook® (эти приложения помечают загруженные файлы специальным флагом) – не будут запускаться, если они не подписаны.
Однако параметр RemoteSigned может дать ложное чувство безопасности. Начнем с того, что специальный флаг может запросто оказаться не добавлен к загруженному сценарию. Например, произведенные не корпорацией Майкрософт обозреватели обычно не устанавливают его, как и большинство произведенных сторонними изготовителями клиентов электронной почты. Важно отметить, что без этого флажкаWindows PowerShell считает загруженные сценарии локальными и не требует от них подписи. Тем не менее, я не считаю это существенной уязвимостью. Пользователю необходимо загрузить сценарий, открыть Windows PowerShell и вручную запустить его, чтобы он сработал. Обычно заставить выполнить все эти действия хитростью довольно сложно – администраторы, которые обычно являются единственными пользователями в сети с установленной Windows PowerShell, не должны быть настолько просты.
Однако RemoteSigned предлагает существенный «черный ход», через который может прокрасться вредоносное приложение. Помните сценарии профиля Windows PowerShell? Если они существуют – созданы ли они пользователем или вирусом – они будут исполняться при каждом запуске Windows PowerShell. А при политике выполнения RemoteSigned сценарии профиля (которые являются локальными) не нуждаются в подписи.
Возьмем пример ситуации:
  1. Некая вредоносная программа пробирается в систему и создает сценарий профиля оболочки либо включает вредоносный код в существующий. Вредоносные программы обычно работают под учетной записью находящегося в системе пользователя, как правило, имеющей полномочия на изменение сценария профиля.
  2. Пользователь открывает Windows PowerShell, не осознавая, что сценарий профиля был создан или изменен с целью включения вредоносного кода. Код выполняется, и наносится ущерб. Ущерб будет еще хуже в случае наличия у пользователя привычки открывать Windows PowerShell, используя учетные данные администратора, – такая практика обычна, поскольку для выполнения многих задач в оболочке нужны администраторские права.
Таким образом, профиль создает возможность выполнения произвольного и вредоносного кода без ведома пользователя, а политика выполнения RemoteSigned позволяет это.

Защита профиля
Есть лишь один надежный способ защитить профиль: использование политики выполнения AllSigned. Под AllSigned даже сценарии профиля должны иметь цифровую подпись, иначе Windows PowerShell не выполнит их при запуске. Кроме того, если сценарии профиля подписаны, внесение в них вредоносных изменений повредит их цифровые подписи, делая их выполнение невозможным – Windows PowerShell даже предупредит пользователя о проблемах при запуске. На самом деле, AllSigned – это единственная безопасная политика выполнения для рабочих сред, которым необходима возможность выполнять сценарии.
Есть еще один подход, но он более сложен и менее надежен. Можно создать незаполненные файлы сценария профиля взамен каждого из четырех файлов, которые ищет Windows PowerShell. Используйте новую учетную запись пользователя (я назову ее «редактор профилей») для создания этих файлов и установки параметров NTFS, позволяющих только учетной записи редактора профилей изменять их. Другие учетные записи могут иметь лишь право доступа на чтение.
После этого никогда не входите в систему, используя учетную запись редактора профилей, кроме как ради изменения профиля. Такой подход не позволит обычной учетной записи (или записям) пользователя изменять сценарии профиля. Кроме того, любое вредоносное программное обеспечение, запускающееся при входе в систему с нормальной учетной записью, не сможет их изменить. Что будет, если вредоносное ПО запустится в тот момент, когда вход в систему произведен с записью редактора профилей? Учитывая то, что пользователь в этот момент в любом случае будет заниматься правкой сценариев профилей, он должен заметить изменения.
Можно также развернуть собственную сеть безопасности посредством создания сценария профиля для всех пользователей, контролируемого аккуратно выдаваемыми разрешениями для файлов, как я только что описал. Внутри этого сценария напишите код, использующий командлет Get-AuthenticodeSignature для изучения цифровых подписей на прочих профилях, которые ищет оболочка. Это, по сути, позволяет требовать подписи от сценариев профиля, но не от других сценариев.
Однако политика исполнения AllSigned – куда более основательный способ защиты профиля. Я рекомендую устанавливать на каждом компьютере, подключенном к сети, политику выполненияRestricted, предпочтительно применяемую групповой политикой. Это отменяет любые локальные параметры и гарантирует автоматическую установку новых компьютеров домена на запрет выполнения сценариев. Компьютеры, на которых следует допустить выполнение некоторых сценариев, должны иметь альтернативную групповую политику, устанавливающую политику выполнения AllSigned. На каждый сценарий необходимо ставить цифровую подпись, но при этом можно спать спокойно, зная, что в среде исполняются только доверенные сценарии от известных авторов.

Дон Джонс — ведущий специалист по написанию сценариев компании SAPIEN Technologies, соавтор книги «Windows PowerShell: TFM» (изд-во. SAPIEN Press, 2007 г.). С ним можно связаться по адресу www.ScriptingAnswers.com.


 Эй, сценарист!: Регулярные выражения невозможно не узнать
Эй, сценарист!
Регулярные выражения невозможно не узнать
Microsoft Scripting Guys
Загрузить исходный код для этой статьи: HeyScriptingGuy2008_01.exe (150KB)

Все мы делаем ошибки. (Что, вы думали, группа Scripting Guys была создана намеренно?) Но если из ошибок и можно извлечь что-то полезное, то... что именно? Вы думали, мы собираемся сказать, что если из ошибок и можно извлечь что-то полезное, так это возможность чему-нибудь научиться на них? Да ничего подобного: если чему-то и можно научиться на сделанной ошибке, так это тому, насколько лучше было бы ее не делать.
Примечание. Шуток про Microsoft Bob сегодня не будет. Мы уже сделали однажды ошибку, высмеивая Microsoft Bob, и в данном случае она нас кое-чему научила. Когда речь идет о Microsoft Bob, мы немы, как рыбы.
Честно говоря, Scripting Guys не могут сказать об ошибках ничего хорошего; именно поэтому мы посвятили свои жизни сокращению числа своих ошибок. (Надо признать, что единственный способ, которым мы можем сократить число своих ошибок – это меньше работать. Но это уже другая история.)
Само собой, замечательно, что мы постарались сократить свои ошибки, однако это может не принести нам особой пользы, если ошибаться продолжат наши коллеги. (Нет, мы уже сказали: шуток о Microsoft Bob не будет!) Те, кто когда-либо писал средство приема данных, скажем, для программы базы данных или Active Directory® (а мы знаем, что многие из читателей писали), уже знают, о чем именно мы говорим: программа приема и предварительной обработки данных хороша ровно настолько, насколько хороши те, кто проводит ввод данных.
Предположим, программа предполагает ввод имен следующим образом: «Иван», с первой буквой в верхнем регистре и всеми последующими в нижнем. Что произойдет, если пользователь введет это имя так: ИВАН? Предположим, программа предполагает ввод дат следующим образом: 23.01.2007. Что произойдет, если пользователь введет дату так: 23 января 2007? Предположим... в общем, все понятно. Как мы уже сказали, программа приема и предварительной обработки данных хороша ровно настолько, насколько хороши те, кто выполняет ввод данных. И, что об этом ни думай, люди, вводящие данные, будут совершать ошибки. Если, конечно, не позаботиться о том, чтобы они этого не делали.

Убедиться в том, что данные допустимы
Пусть закончится чемпионат
Кто-нибудь когда-либо задумывался, какого события Scripting Guys ждут весь год? Те кто посещал центр сценариев в феврале за последние пару лет, могут предположить, что это событие – "The Winter Scripting Games" («Зимний чемпионат по сценариям»). Они ошибутся. Scripting Guys с нетерпением ждут окончания чемпионата по сценариям, когда после двух недель непрерывного веселья им предоставится возможность погреться в лучах славы после очередного успешного выступления и проспать весь следующий месяц.
Так что в качестве подготовки к нашему любимому событию года, то есть окончанию чемпионата Scripting Games, самое время начать зимний чемпионат Scripting Games 2008 года! Присоединяйтесь к нам с 15 февраля по 3 марта 2008 года в центре сценариев, чтобы поучаствовать в лучшем на свете состязании по написанию сценариев.
Чемпионат по сценариям Scripting Games – это отличный способ проверить и улучшить свое мастерство в их написании. А поскольку в этом году Scripting Guys хотят проспать несколько лишних дней по его окончании, мы постараемся сделать состязание еще больше и лучше, чем в прошлом! Как и раньше, у нас будет два раздела: для начинающих и специалистов. Это значит, что и полные новички в написании сценариев, и старые (или молодые) специалисты и все, кто находится между этими двумя полюсами, смогут поучаствовать в состязании.
Итак, что нового в этом году? Мы добавляем очередной язык сценариев. Теперь можно состязаться в VBScript, Windows PowerShell или – новинка – Perl. (Мы знаем, что Perl не новинка, но он впервые в нашем состязании.) Вероятно, веселье не будет этим исчерпываться, но поскольку нам пришлось составить эту врезку несколько месяцев назад, мы и понятия не имеем, что именно будет добавлено. Посетите центр сценариев и узнайте.
Если кто-то сомневается, призы будут! Какие именно? Нет, сюрприза мы здесь портить не будем – посетите центр сценариев и узнайте сами! microsoft.com/technet/scriptcenter/funzone/games/default.mspx.

Многие из читателей, вероятно, уже используют элементарные виды проверки вводимых данных. И во многих отношениях такое простое подтверждение ввода данных работает без проблем. Нужно убедиться, что длина строкового значения strName не превышает 20 символов? Сойдет этот крохотный кусок кода:
If Len(strName) > 20 Then
    Wscript.Echo "Invalid name; a " & _
    "name must have 20 or fewer characters."
End If
Но предположим, что strName является новым артикулом, а артикулы должны соответствовать конкретному шаблону: четыре цифры, за которыми следуют две заглавные буквы (что-нибудь вроде 1234AB). Можно ли проверить, что strName следует требуемому шаблону, при помощи простого VBScript? Да, можно. Но, поверьте нам, не нужно. Вместо этого стоит использовать регулярное выражение.

Убедитесь, что в значении появляются только числа
Регулярные выражения впервые появились в 50-х годах XX века, когда они были впервые описаны как форма математических обозначений. В 60-е эта математическая модель была включена в текстовый редактор QED как способ поиска сочетаний символов в текстовом файле. Спустя какое-то время... что такое? А, да. Похоже, не все считают историю регулярных выражений такой захватывающей, как мы. Никаких проблем. В таком случая, мы просто покажем, о чем идет речь.
Желаете убедиться, что переменная (в данном случае, переменная strSearchString) содержит только числа? На рис. 1 показан один из способов.
Figure 1 Numbers only, please (Close Figure 1)
Set objRegEx = _
  CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "\D"

strSearchString = "353627"

Set colMatches = _
  objRegEx.Execute(strSearchString)

If colMatches.Count > 0 Then
    Wscript.Echo "Invalid: a " & _
      "non-numeric character was found."
Else
    Wscript.Echo "This is a valid entry."
End If
Как можно заметить, сценарий начинает с создания экземпляра объекта VBScript.RegExp, объекта который... да, догадка правильная, того самого объекта, который позволяет использовать регулярные выражения в сценарии. (Эх, а мы хотели объяснить это сами.) После этого мы назначаем значения двум ключевым свойствам обычного объекта выражений: Global и Pattern.
Свойство Global определяет, должен ли сценарий искать все случаи употребления шаблона или остановиться на первом найденном. Как правило, лучше дать ему значение «истина», что означает поиск всех экземпляров шаблона. (По умолчанию используется «ложь».) Чаще всего будет необходимо найти все случаи употребления шаблона. Даже если не так, единственным преимуществом обнаружения лишь первого найденного случая является более быстрая работа сценария, которому не надо обыскивать все до конца. В теории это полезно. Но на практике поиск обычно заканчивается так быстро, что нельзя заметить особой разницы.
А вот главное: в Pattern мы указываем символы (и шаблон символа), которые нам нужны. В нашем примере сценария мы ищем любые символы, которые не являются цифрами от 0 до 9. При обнаружении такого символа (буквы, знака пунктуации, чего угодно) мы знаем, что значение, присвоенное strSearchString, недопустимо. При использовании регулярных выражений синтаксис \D используется для поиска совпадения с любым символом, не являющимся цифрой, так что мы присваиваем свойству Pattern значение \D.
Примечание: Откуда нам знать, что \D будет совпадать с любым символом, не являющимся цифрой? Ну, это долгая история. Видите ли, несколько лет назад... ой, вспомнили. Мы узнали это в справочном материале по языку VBScript на MSDN® at msdn2.microsoft.com/1400241x.
После присваивания значений свойствам Global и Pattern следующим шагом является присваивание значения переменной strSearchString:
strSearchString = "353627"
Так как же можно узнать, есть ли в этой строке символы, не являющиеся цифрами? Это просто. Достаточно вызвать метод Execute («Исполнить»), ищущий такие символы в нашей переменной:
Set colMatches = _
objRegEx.Execute(strSearchString)
При вызове метода Execute любые совпадения, то есть любые экземпляры Pattern, обнаруживаются и сохраняются в коллекции Matches («Совпадения»). (В нашем примере сценария эта коллекция названа colMatches.) Если нужно узнать, содержит ли переменная что-то кроме цифр (а нам нужно), достаточно лишь проверить значение свойства коллекции Count, сообщающего нам, сколько в ней находится элементов:
If colMatches.Count > 0 Then
    Wscript.Echo "Invalid: a " & _
      "non-numeric character was found."
Else
    Wscript.Echo "This is a valid entry."
End If
Если значение Count выше 0, это может значит только одно: в переменном значении был найден символ, не являющийся цифрой. (Если все символы в значении являются цифрами, коллекция будет пустой, соответственно имея Count равным 0.) В нашем примере сценария мы получаем факт обнаружения символа, не являющегося цифрой. В реальном сценарии или средстве приема данных базы данных, вероятно, надо отобразить подобное сообщение и вернуть все к началу, чтобы пользователя попытался снова. Но это уже заботы читателей; у нас, парней из Scripting Guys, хватает других проблем.
Каких именно? Скажем, таких, что в один прекрасный день работники TechNet Magazine могут и вправду начать читать статьи, которые мы им присылаем каждый месяц. Мы бы предпочли, чтобы они не учились на своих ошибках.
А, вот очень хороший вопрос: нельзя ли просто использовать функцию IsNumeric для определения, содержит ли strSearchString число или нет? Конечно, если strSearchString может быть любым числом. Но что если strSearchString должен быть положительным целым числом? Это может быть проблемой: IsNumeric опознает оба приведенных ниже числа как допустимые:
-45
672.69
Почему они определяются как допустимые числа? Потому что они являются допустимыми числами, вот только не положительными целыми числами. С другой стороны, наше регулярное выражение пометит их как неверные, поскольку регулярное выражение улавливает нецифровые символы минуса (–) и точки (.). Если вы читаете эту статью и думаете: «Зачем я читаю эту статью?», то вот вам и причина ее читать.
Что-что? Этого недостаточно? Да, публика в этом месяце недоверчива. Хорошо, давайте взглянем на несколько других способов проверки вводимых данных, возможных благодаря регулярным выражениям.

Убедитесь, что в значении не появляется цифр
Мы только что показали, как обеспечить появление в значении одних цифр. Что, если надо сделать обратное и убедиться в отсутствии цифр в значении? Ну, например, можно использовать такой шаблон поиска:
objRegEx.Pattern = "[0-9]"
Что он делает? Ну, в безумном мире регулярных выражений знаки квадратных скобок ([ и ]) позволяют указать набор, или, как мы сделали здесь, диапазон символов. Что значит Pattern [0-9]? Это значит, что мы ищем любой символ в диапазоне от 0 до 9, другими словами, любое числовое значение. Если б нам были нужны только четные цифры (т.е, нужно было бы убедиться, что значение не включает чисел 1, 3, 5, 7 и 9), то можно было бы использовать этот шаблон:
objRegEx.Pattern = "[13579]"
Заметьте, что, поскольку мы не используем дефис, выполняется поиск отдельных символов, а не диапазона, то есть только символов 1, 3, 5, 7 и 9.
Само собой, шаблон [0-9] выискивает только цифры, он не найдет знаков препинания или других символов, не являющихся ни буквами, ни цифрами Можно ли создать шаблон, ищущий все символы, кроме букв? Конечно, можно. С помощью регулярных выражений можно сделать практически все, что угодно:
objRegEx.Pattern = "[^A-Z][^a-z]"
В данном случае, мы совмещаем два критерия для нашего шаблона: ищем как [^A-Z], так и [^a-z]. Как несложно догадаться, A-Z обозначает диапазон символов от заглавной A до заглавной Z. Что значит знак ^? Ну, при включении внутрь квадратных скобок знак ^ значит: «Искать любой символ, не входящий в данный набор символов». То есть [^A-Z] значит: «Искать любой символ, не являющийся заглавной буквой». В то же время [^a-z] значит: «Искать любой символ, не являющийся строчной буквой». Сухой остаток: данный шаблон значит, что мы ищем всё, что не является заглавными или строчными буквами. В этот набор входят цифры, знаки препинания и прочие странные символы, которые можно найти на клавиатуре.
Как вариант, можно установить значение «истина» для свойства IgnoreCase:
objRegEx.IgnoreCase = True
В этом случае при поиске будет игнорироваться регистр буквы. А затем можно будет использовать данный Pattern, который в сочетании с IgnoreCase будет искать все, что не является заглавной или строчной буквой:
objRegEx.Pattern = "[^A-Z]"

Убедитесь, что артикул допустим
Давайте теперь дадим немного воли фантазии. (И, можете нам поверить, регулярные выражения позволяют развернуться фантазии, достаточно посмотреть веб-узел regexlib.com, чтобы найти примеры этого.) Выше по тексту мы сказали примерно следующее: Предположим, что strName является новым артикулом, а артикулы должны соответствовать конкретному шаблону: четыре цифры, за которыми следуют две заглавные буквы (например, 1234AB). Как можно подтвердить соответствие переменной этому шаблону? А вот так:
objRegEx.Pattern = "^\d{4}[A-Z]{2}"
Что значит этот шаблон? Какое совпадение: мы как раз собирались объяснить, что он значит. В данном случае, мы ведем поиск по трем критериям:
^\d{4}
\d значит, что мы ищем цифры (символы в пределах между 0 и 9). Что значит {4}? Это значит, что нужно найти совпадение ровно для четырех символов (то есть, ровно для четырех цифр). Таким образом, мы ищем последовательность из четырех цифр.
А как же знак ^? Ну, вне квадратных скобок знак ^ указывает, что значение должно начаться с последующего шаблона, то есть AA1234AB не будет помечено как совпадение. (Почему? Потому, что значение начинается с AA, не с последовательности из четырех цифр.) При желании можно было бы использовать знак $, чтобы указать, что нужно искать совпадение с концом строки. Но у нас такого желания нет. (По крайней мере, в этом примере.)
[A-Z]{2}
Мы уже говорили, что значит компонент [A-Z] – это любая заглавная буква. А {2}? Верно: за четырьмя цифрами должны следовать ровно две заглавные буквы.
Довольно просто, да? Между прочим, в этом случае, если Count равен 0, то на руках имеется недопустимое значение. Почему? Потому что в данном случае мы ищем не единственный символ, делающий строку неверной, а точное совпадение шаблона. Если совпадений нет, то значение недопустимо. И при этом свойство Count коллекции будет равно 0.
Примечание: Существует еще пара полезных конструкций: {3,} и {3,7}. {3,} значит, что нужно искать минимум 3 последовательных символа (или выражения); однако при минимуме в 3 максимум не обозначен. Таким образом, шаблону \d{3,} соответствует 123, 1234, а также 123456789. {3,7} значит, что нужно искать минимум 3 последовательных символа (или выражения) при максимуме в 7. То есть 123456 будет соответствием, а 123456789 (более чем 7 последовательных цифр) – нет.
Вот еще один полезный шаблон. Предположим, что артикул начинается с 4 цифр, за которыми следуют буквы US, за которыми следуют два последних символа (которые могут быть буквами, цифрами или чем угодно). Вот один из способов обозначить это:
objRegEx.Pattern = "^\d{4}US.."
Как можно заметить, шаблон начинается с четырех цифр (\d), за которыми должны последовать буквы US (и только US; все прочее не будет совпадением). После букв US, необходимы еще два символа неопределенного рода. Как обозначить любой символ в регулярном выражении? Погодите секунду, мы знаем это... о, вспомнили: любой отдельный символ обозначается точкой (.). Логично, что два символа можно обозначить двумя точками:
..
Хорошо, это было просто. Попробуем задачку посложнее. Предположим, что эти два внутренних символа указывают страну, где произведена деталь. Если заводы имеются в США, Великобритании и Испании, любой из этих двузначных кодов будет верен: US, UK, ES. Как справиться с ситуацией множественного выбора в регулярном выражении?
Ну, может быть так:
objRegEx.Pattern = "^\d{4}(US|UK|ES).."
Ключом здесь является следующая маленькая конструкция: (US|UK|ES). Мы поместили три приемлемых значения (US, UK и ES) в скобки, разделив их символом «|». Вот так в регулярном выражении и указывается на наличие множественного выбора.
Но подождите: разве мы не сказали, что выбор из несколько вариантов можно поместить и в квадратные скобки? Не для того ли предназначен весь фокус с [13579]? Да, для этого. Однако он работает лишь для отдельных символов; [13579] всегда будет интерпретироваться как 1, 3, 5, 7 и 9. Чтобы искать135 и 79, нужно использовать следующий синтаксис: (135|79). При помощи скобок можно также отграничить единственное слово, которое следует искать:
objRegEx.Pattern = "(scripting)"
Можно и обойтись и без скобок:
objRegEx.Pattern = "scripting"
Примечание. Хорошо, все это полезно знать, но что если скобки нужно включить в предмет поиска, что если нужно найти «(scripting)»? Ну, поскольку как открытые, так и закрытые скобки являются зарезервированными символами в регулярных выражениях, перед каждой из них потребуется поставить \. Другими словами:
objRegEx.Pattern = "\(scripting\)"

Свобода выражения
Наше время в этом месяце истекает. Тем, кто хочет получить дополнительные сведения о регулярных выражениях, можно заглянуть в веб-трансляцию String Theory for System Administrators («Теория строк для системных администраторов»): An Introduction to Regular Expressions («Введение в регулярные выражения») (microsoft.com/technet/scriptcenter/webcasts/archive.mspx). И, начиная изучать и использовать регулярные выражения, не забывайте бессмертные слова Софи Лорен: «Ошибки – это часть нашей платы за полноценную жизнь».
Ничего себе! Похоже, Scripting Guys прожили куда более полноценные жизни, чем когда-либо предполагали!

Головоломка-сценарий доктора Скрипто.
Ежемесячная задача для проверки навыков читателей по части не только головоломок, но и сценариев.

Январь 2008 г.: извилистые существительные
В этом месяце доктор Скрипто решил поработать с Windows PowerShell. Само собой, с Windows PowerShell нельзя работать, или, по крайней мере, нельзя работать правильно (а доктор Скрипто всегда все делает правильно) без использования командлетов. Для этой головоломки доктор Скрипто вплел некоторые командлеты в таблицу. Найдите их.
Должны признаться, эта головоломка была бы несколько более запутанной, если бы мы использовали целые командлеты. Поскольку командлеты состоят из глагола и существительного, десятки из них начинаются с Get-, Set- и так далее. Так что мы опустили глагольные части командлетов cmdlet (и тире), оставив только существительные. (Но мы можем сказать, что все эти глаголы были "Get-".)
Задача этого месяца – распутать существительные командлетов. Ниже приведен список существительных, спрятанных в головоломке. (Ну не щедры ли мы?) Каждое слово может изгибаться вертикально и горизонтально, вперед и назад, но не по диагонали. Мы привели первое слово (Location) в качестве примера. Удачи.

Список слов
Alias
ChildItem
Credential
Date
EventLog
ExecutionPolicy
Location
Member
PSSnapin
TraceSource
Unique
Variable
WMIObject

Головоломка-сценарий доктора Скрипто.
Ответ: извилистые существительные, январь 2008 г.

Microsoft Scripting GuysСотрудники группы Microsoft Scripting Guys работают... ну хорошо, получают зарплату в корпорации Майкрософт. Когда они не играют в бейсбол, не тренируют бейсбольную команду, не смотрят бейсбол и не занимаются другими делами, они ведут проект Script Center в журнале TechNet Magazine. Веб-узел проекта находится по адресу www.scriptingguys.com.


 На страже безопасности: От острова к острову: заразительная скачка промо-материалов поставщика
На страже безопасности
От острова к острову: заразительная скачка промо-материалов поставщика
Йеспер M. Йоханссон

Методика «скачков от острова к острову», то есть проникновения в сеть через ее уязвимое место и скачков между системами в этой сети, применяется уже не первый год. Но она продолжает приобретать новые грани. В современных информационных средах с высокой безопасностью уязвимым местом часто являются люди и злонамеренные пользователи
находят способы обратить это себе на пользу (вспомним о фишинге и других формах «социальной инженерии»). Такое сочетание мозга и чипа может стать фатальным для сети.
Одним из своих любимых примеров использования человеческого элемента я обязан действиям Стива Стазиукониса (Steve Stasiukonis) из компании Secure Network Technologies в ходе его испытания сети корпорации-клиента на проникновение. Он разбросал флэш-накопители для USB с троянскими программами на них по автостоянке этой корпорации. Когда сотрудники утром прибыли на работу, их немало порадовали ничьи устройства, валяющиеся в разных местах стоянки. Сотрудники охотно собрали флэш-накопители и подключили их к первым же компьютерам, которые им попались: собственным рабочим станциям.
Возможно, некоторым сотрудникам хватило ума проигнорировать эти флэш-накопители, возможно, некоторые из накопителей были выброшены, но оказалось достаточно и одного пользователя с одним устройством, чтобы предоставить шлюз в сеть. Само собой, Стазиуконис проделал это в рамках приближенных к реальности испытаний, но эта же методика использовалась настоящими преступниками для проникновения в сети крупных корпораций.
В наше время флэш-накопители для USB встречаются везде. Почти на любой конференции кто-нибудь из поставщиков раздает их, как конфеты. Они могут быть невелики по объему, но для захвата целой сети большой объем и не нужен. В этой статье из двух частей я исследую этот тип атаки и покажу способы снижения риска. В данном выпуске я покажу, что именно можно сделать с помощью флэш-накопителя для USB, а также что можно сделать, чтобы установить контроль над ними. А в следующем номере журнала TechNet Magazine я расскажу, как сдержать атаку на одну систему в сети или на небольшую их группу.
Техническая сторона атаки, на самом деле, довольно проста. Все начинается со вставления зараженного флэш-накопителя для USB в единственный компьютер. Что происходит затем, зависит от содержимого этого устройства и, само собой, от легковерности пользователя.

В начале
За портативным компьютером на трибуне никто не следил. Выступающий был слишком занят, ища расположения публики, прежде чем начать свою презентацию. Сам компьютер был закрыт, но это едва ли имело значение. Злоумышленник поднялся на трибуну и задержался там на некоторое время, словно ожидая возвращения выступающего. Поскольку эти трибуны спроектированы так, чтобы скрывать некрасивые вещи, вроде компьютеров, порты USB и руки злоумышленника были скрыты от глаз. После того, как флэш-накопитель для USB был вставлено в компьютер, на завершение атаки потребовались считанные секунды.
Встречается несколько очевидных вариантов этой схемы. Например, когда я ездил по свету, устраивая еженедельные презентации, почти каждый раз по их окончании находились люди, просившие у меня копию моих слайдов. Я неизменно давал им мою визитку и предлагал послать мне сообщение по электронной почте. Зачем было это делать, когда каждый из них с нетерпением протягивал мне накопитель для USB? Потому что я знаю о средствах вроде USB Hacksaw и Switchblade. (Если вы не знакомы с ними, загляните на wiki.hak5.org.)
По сути, эти средства позволяют практически кому угодно воспользоваться неосторожностью людей, оставляющих свои порты USB незащищенными. Например, Switchblade может скопировать следующее:
  • Сведения о системе
  • Все сетевые службы
  • Список слушающих портов
  • Все ключи программных продуктов Майкрософт на компьютере
  • Локальную базу паролей
  • Пароли для любых используемых компьютером беспроводных сетей
  • Все пароли для сети, сохраненные на компьютере находящимся в системе на данный момент пользователем
  • Пароли Internet Explorer®, Messenger, Firefox и электронной почты
  • Секреты локального администратора безопасности (Local Security Authority – LSA), в которые входят пароли всех учетных записей служб, записанные открытым текстом
  • Список установленных исправлений
  • Журнал работы обозревателя за последнее время
Все это переносится в файл журнала на устройстве памяти примерно за 45 секунд.
Hacksaw – это несколько модифицированная версия, устанавливающая троянскую программу, которая отслеживает все события вставки флэш-накопителей для USB. Затем онаотправляет злоумышленнику по электронной почте все документы со всех флэш-накопителей, вставленных в компьютер впоследствии.
Эти средства используют U3 (u3.com), технологию, разработанную чтобы позволить пользователям приносить программы с собой на флэш-накопителе. По сути, флэш-накопитель, использующий U3, врет о себе. Оно сообщает операционной системе, что на самом деле является концентратором USB, к которому подключены флэш-накопитель и компакт-диск. Версии Windows®, предшествовавшие Windows Vista®, по умолчанию запускают программы, указанные в файле autorun.inf на компакт-дисках, но не на накопителях для USB. Сообщая ложную информацию о себе, флэш-накопитель для USB, использующий U3, обманывает операционную систему, делая возможным автоматический запуск средства запуска U3. Средство запуска U3, в свою очередь, может запускать программы, выдавать меню и делать практически все, из того, что можно делать с самим компьютером.
Средства использования уязвимостей просто заменяют средство запуска кодом для использования уязвимости. Последний автоматически срабатывает при вставке флэш-накопителя в порт системы под управлением Windows XP. На Windows Vista поток принятия решения AutoPlay работает иначе. Автоматический запуск для съемных устройств включен, точно так же, как для компакт-дисков. Это значит, что при вставке устройства произойдет какое-то действие. По умолчанию это будет появление диалога автовоспроизведения, как показано на рис. 1.
Рис. 1 Диалог автовоспроизведения появляется, кода пользователь вставляет съемное устройство с изображениями
Рис. 1 Диалог автовоспроизведения появляется, кода пользователь вставляет съемное устройство с изображениями
Обратите внимание, что в диалоге на Рис. 1 имеется вариант «Всегда поступать так с изображениями». В результате устанавливается режим автовоспроизведения, который можно настроить с помощью панели управления, показанной на рис. 2.
Рис. 2 Настройка автовоспроизведения в Windows Vista
Рис. 2 Настройка автовоспроизведения в Windows Vista
Настройка автовоспроизведения особенно интересна для пункта «Программы и игры». По умолчанию, это значит, что у съемного устройства имеется файл autorun.inf, указывающий какие-то программы для выполнения. Параметры на Рис. 2, относящиеся к «Программам и играм», хранятся в следующем разделе реестра:
Hive:    HKEY_CURRENT_USER
Key:    \Software\Microsoft\Windows\CurrentVersion\Explorer\AutoplayHandlers\
UserChosenExecuteHandlers\AutorunINFLegacyArrival
Value: (Default)
Data:
MSAutoRun – automatically executes the program specified in the autorun.inf file

MSPromptEachTime – prompts the user, using strings specified in the autorun.inf file, if available
Поскольку для изменения этих параметров не нужно быть администратором, пользователи могут устанавливать их на что захотят, включая автоматический запуск любых вредоносных программ с устройства, найденного ими на автостоянке. На практике, они могут сделать это, установив соответствующий флажок в диалоге автовоспроизведения.

Управление автовоспроизведением в сети
У администратора есть несколько способов управления автовоспроизведением в масштабах сети. Во-первых, можно не дать пользователю возможности включения автовоспроизведения на съемных устройствах и компакт-дисках посредством изменения параметра NoDriveTypeAutoRun, контролирующего типы дисков, для которых включено автовоспроизведение. Windows XP поставляется с NoDriveTypeAutoRun, установленным на 0x95, что отключает автовоспроизведение для неизвестных типов дисков, сетевых дисков и съемных устройств. Начиная с Windows XP SP2, параметр NoDriveTypeAutoRun по умолчанию установлен на 0x91. Это допускает работу автовоспроизведения на съемных устройствах хранения данных. При использовании групповой политики имеется параметр «Конфигурация пользователя»\«Административные шаблоны»\«Компоненты Windows»\«Политики AutoPlay», позволяющий управлять параметром NoDriveTypeAutoRun. Выбрав «Отключить параметр автовоспроизведения и выбрать компакт диск и съемные диски» можно отключить автовоспроизведение для обоих типов дисков.
Но, как следствие, пользователь не получит диалога автовоспроизведения с рис. 1. На деле, при вставке диска вообще ничего не произойдет. Это решение не всегда идеально, поскольку может привести в замешательство пользователя, не уверенного, как получить доступ к нужной информации на диске.
Что, вероятно, нужно, так это контроль над тем, какие типы содержимого могут воспроизводиться автоматически. До некоторой степени это возможно в Windows Vista, поскольку у этой операционной системы на практике есть два уровня элементов управления автоматически запускаемым ПО. Другой элемент управления в групповой политике, показанный на рис. 3, позволяет отключить автовоспроизведение для программного обеспечения, использующего файлы autorun.inf, в прочем оставляя поведение автовоспроизведения в Windows Vista неизменным.
Рис. 3 Отключение файлов autorun.inf files с помощью групповой политики
Рис. 3 Отключение файлов autorun.inf files с помощью групповой политики
Поток решения в момент прихода в автовоспроизведение несколько замысловат, и, вероятно, его проще всего показать с помощью блок-схемы. На рис. 4 изображен поток решения, используемый при определении, выполнять ли файл на съемном носителе автоматически либо нет.
Рис. 4 Поток решения автовоспроизведения
Рис. 4 Поток решения автовоспроизведения

Другие подходы
Само собой, это лишь некоторые из средств, которые можно использовать для взлома компьютера с помощью флэш-накопителя для USB. Все типы средств могут быть использованы в этой ситуации, такие как средство, копирующее хэш-код пароля Windows NT® находящегося в системе пользователя (см. microsoft.com/technet/community/columns/secmgmt/sm1005.mspx).
Многие контроллеры USB на деле являются устройствами прямого доступа к памяти (DMA). Это значит, что они могут обходить операционную систему, напрямую ведя чтение и запись в память компьютера. Обход ОС – это обход элементов предоставляемых ею средств безопасности и получение полного доступа к оборудованию. Это делает контроль за устройствами, применяемый ОС, совершенно неэффективным. Мне неизвестны средства взлома, использующие эту методику на данный момент, но я очень сильно сомневаюсь, что они до сих пор не существуют в реальности.
Другим способом использовать сочетание пользователь/съемное устройство, является банальное представление заманчивой возможности. Например, какая часть пользователей щелкнет диалог на рис. 5? Не все, но, вероятно, многие. Смысл в том, что состряпать диалог, который будет слишком заманчив для пользователей, чтобы его проигнорировать, достаточно просто.
Рис. 5 Для какого количества пользователей этот диалог будет заманчив?
Рис. 5 Для какого количества пользователей этот диалог будет заманчив?

Блокирование устройств
Новинка Windows Vista, групповая политика, теперь предоставляет набор политик для управления установкой устройств (см. рис. 6). Как показано, администратор может заблокировать установку любых новых съемных устройств, если драйвер указывает, что они съемные. Но если драйвер заявляет, что это не так, политика не вступает в силу. Таким образом, ее можно обойти, используя специальные драйверы.
Рис. 6 Политики управления установкой устройств Windows Vista
Рис. 6 Политики управления установкой устройств Windows Vista
Для более детального контроля администратор может использовать политики для воздействия на конкретные классы установки устройств. Однако это требует знания GUID для конкретного класса устройств, который необходимо заблокировать (или допустить), делая такой подход заметно более сложным в управлении.

Минимальные права имеют значение
Если на минуту забыть про ситуацию с DMA, успех атак, о которых я рассказа, а также успех контрмер зависят от уровня прав пользователя, использующего компьютер. Если пользователь является обычным пользователем, атака может нанести лишь ограниченный ущерб. Данные и вообще все, к чему есть доступ у этого пользователя, могут быть украдены. Но атака, вероятно, не повредит сети в целом.
Однако, если ставший жертвой пользователь – администратор, последствия могут быть намного хуже. В худшем возможном случае, пользователь является администратором домена, и тогда захват управления всей сетью тривиален. Например, злоумышленник сможет извлечь хэш-код пароля пользователя из памяти. Система кэширует хэш-код внутри пространства процесса LSA при входе в систему, что позволяет его использовать для незаметной пользователю организации доступа к сетевым ресурсам от его имени. Злоумышленник с административными привилегиями может извлечь этот хэш-код и получить доступ к любым ресурсам сети с его помощью. Другими словами, при успешной атаке на администратора домена нарушается безопасность всего домена.
Здесь мы подходим к теме зависимостей. Пока что я описал конкретную атаку на рабочие станции, но пока что я не разобрал последствия атаки в масштабе сети. В следующем выпуске этой рубрики я разберу концепцию зависимостей, показывая, что они значат для среды в целом и, что более важно, что можно сделать для их укрепления.

Йеспер M. Йоханссон является инженером группы безопасности программного обеспечения и пишущим редактором журнала TechNet Magazine. Он защитил диссертацию по информационным системам управления и более 20 лет работает в области обеспечения компьютерной безопасности.


 Материалы о рабочей среде: Общее пользование компьютерами при помощи Windows SteadyState
Материалы о рабочей среде
Общее пользование компьютерами при помощи Windows SteadyState
Уэс Миллер

Всякий, кто хоть раз за последние лет десять переступал порог компьютерной лаборатории, знаком с этой проблемой. Я впервые столкнулся с ней, будучи в колледже. В то время лаборатории были открыты весь день (тем, у кого имелся студенческий билет), причем за теми, кто был в библиотеке, практически никто не следил. Любители компьютерных игр той эпохи
пользовались этим, чтобы вносить полезные для работы своих игр изменения в ключевые файлы Windows® и MS-DOS®. В результате их игры могли работать хорошо, а вот Windows работала плохо, если работала вообще. Нам всем приходилось когда-нибудь сталкиваться с этим – компьютер общего пользования, который доведен до такого состояния, что работа на нем является потерей времени.
Недавно я провел отпуск в городе Саут Падре Айленд, здесь в Техасе. В «гостевой компьютерной комнате» отеля, где я остановился, имелось три компьютера, работающих под Windows XP. Все работающие на этих системах Windows имели права администратора, что при отсутствии установленных политик привело к тому, что каждый из этих несчастных компьютеров немало пострадал от посетителей, устанавливающих что попало и удаляющих либо изменяющих основные приложения – результат, на который отель вряд ли рассчитывал. Будь это лаборатория или отель, компьютеры, находящиеся в общем пользовании, подвергаются суровым испытаниям, порой превосходящим те, которые выпадают на долю некоторых домашних компьютеров.

Решения проблемы
Как получить и использовать SteadyState
Средство Windows SteadyState доступно как бесплатная загрузка по адресу go.microsoft.com/fwlink/?LinkId=104721. Дополнительные сведения о SteadyState имеются на странице microsoft.com/windows/products/winfamily/sharedaccess.
Windows SteadyState работает только на системах, которые могут использовать Windows XP. Наиболее существенным улучшением по сравнению с SCT является то, что SteadyState, в отличие от SCT, не требует для работы второго раздела для защиты диска Windows.
Нижеследующая таблица предоставляет обзор системных требований для SteadyState. Отметьте, что SteadyState нуждается в файловой системе формата NTFS, но при этом поддерживается любая версия Windows XP. SteadyState в настоящий момент не работает с Windows Vista®.

Компонент | Требование
Процессор | 300 МГц или более (минимум 233 МГц).
Память | 128 МБ ОЗУ или более (минимум 64 МБ; при объеме ниже рекомендованного может ухудшиться производительность и некоторые возможности).
Жесткий диск | Минимум 1,5 ГБ свободного пространства на жестком диске без защиты диска Windows, или минимум 4,0 ГБ свободного пространства на жестком диске с защитой диска Windows.
Операционная система | Windows XP Home Edition, Windows XP Professional или Windows XP Tablet PC Edition. Должен быть установлен пакет обновления 2 (SP2) для Windows XP.
Поддерживаемые языки | Английский, голландский, французский, итальянский, испанский, бразильский португальский, китайский (упрощенный) и японский.
Файловая система | Файловая система NTFS
Доступ | Доступ уровня администратора.

Те, кто читал мою рубрику в течение последнего года или знаком с развертыванием Windows в целом, может подумать: «Невелика проблема – достаточно восстановить образы систем». Но те, у кого вдобавок есть опыт в этой области, знают, что не всегда все так просто. Нажатие большой красной кнопки восстановления образа каждый день или каждую неделю не является решением, пригодным к масштабированию.
Несколько лет назад мы с одним из моих друзей обдумывали организацию киберкафе. Это было в 1995 году, когда такая идея еще оставалась необычной. Больше всего меня беспокоило реальное обеспечение надежности и доступности системы. Увы, варианты тогда ограничивались восстановлением образа или несколько более устойчивыми решениями; средства автоматического решения проблем просто отсутствовали.
Если выделить основные компоненты проблемы, то обеспечение безопасности компьютеров общего пользования выдвигает три требования:
  • Обеспечение отсутствия прав администратора у пользователей. Это обязательно для всех общих компьютеров.
  • Установка политики максимальной безопасности. Это понижает вероятность внесения пользователями изменений в части системы, доступ к которым им не положен.
  • Возможность отменить любые случайные изменения, внесенные пользователями. Даже если пользователи не имеют прав администраторов, они все равно могут вносить несанкционированные изменения в меню, списки избранного, и т.д.
К счастью, корпорация Майкрософт уже несколько лет назад начала работу над набором средств, специально предназначенным для помощи в такой ситуации.

История SteadyState
Чуть больше года назад, корпорация Майкрософт выпустила инструментарий для компьютеров общего пользования Windows Shared Computing Toolkit (SCT). Доступный как бесплатная загрузка для систем, сертифицированных в рамках программы Windows Genuine Advantage, инструментарий был разработан специально для библиотек, лабораторий, киберкафе и прочих мест общего пользования компьютерами. Обзор SCT можно было встретить в выпуске TechNet Magazine за июль 2006 года (technetmagazine.com/issues/2006/07/UtilitySpotlight).
Поставки его новой версии, переименованной в Windows SteadyStateTM (microsoft.com/windows/products/winfamily/sharedaccess), начались в июне 2007. Одной из причин переименования набора средств стали значительные изменения по сравнению с предыдущей версией. Он выполняет все те же задачи, о которых я подробно расскажу чуть ниже, но на этот раз группа разработчиков сосредоточилась на общей простоте использования. Как следствие, SteadyState тесно интегрирован в новую консоль и более прост в установке и управлении. Он более мощен и гибок, а также поддерживает интеграцию Active Directory® для одного из своих ключевых компонентов – что означает еще большую гибкость в нескольких новых случаях для корпораций. Теперь он также поддерживает интеграцию обновления Windows, благодаря чему SteadyState сам может разобраться, когда следует отключить защиту диска Windows для внесения обновлений. Это понижает затраты и усилия, связанные с управлением, для систем, управляемых SteadyState.

Возможности SteadyState
Windows SteadyState состоит из четырех ключевых компонентов: ограничения для компьютеров (Computer Restrictions) фиксируют параметры безопасности и настройки для отдельных компьютеров; защита диска Windows кэширует(и отменяет) изменения системного раздела Windows; диспетчер учетных записей пользователей (User Account Manager ) создает, изменяет, импортирует или экспортирует эти записи и, наконец, ограничения и параметры для пользователей (User Restrictions and Settings ) фиксируют параметры безопасности и настройки на уровне пользователей.
Одним из сразу заметных улучшений по сравнению с Shared Computing Toolkit является справка для пользователя. Руководство по запуску помогает в подготовке SteadyState к работе. Далее SteadyState предлагает четыре ключевые задачи, в которые можно углубиться (соответствующие четырем описанным выше ключевым возможностям).
  • Установить ограничения для компьютеров (ограничения для компьютеров).
  • Создать расписание обновлений программного обеспечения (Позволяет указать, следует ли SteadyState автоматически применять обновления Windows. Рекомендуется указать, что следует, поскольку в этом случае средство само будет работать с защитой диска Windows, а также обновлять сигнатуры нескольких популярных антивирусных программ.)
  • Защитить жесткий диск (защита диска Windows).
  • Добавить пользователя (диспетчер учетных записей пользователей)
В пункте «Добавить пользователя» можно найти ограничения и параметры для пользователей, позволяющие проводить настройку на уровне пользователей.

Ограничения и параметры для компьютеров и пользователей.
Те, кто знаком с групповой политикой Windows, уже знакомы с такими аспектами SteadyState, как установка ограничений для компьютеров, а также ограничения и параметры для пользователей . Вместо того, чтобы принуждать администраторов SteadyState использовать редактор объектов групповой политики (GPEdit.msc), отсутствующий в Windows XP Home Edition (поддерживающей SteadyState), SteadyState выводит несколько ключевых возможностей безопасности и настройки, часто встречающихся при общем пользовании компьютерами.
На рис. 1 показан экран настройки установки ограничений для компьютеров. Обратите внимание, что все приведенные там параметры являются общими и применяются ко всему компьютеру. Эти параметры в первую очередь служат уменьшению угроз безопасности системы – а в случае доступа к накопителю для порта USB еще и понижению возможности удаления чего-либо из системы. (При взгляде на параметры, относящиеся к пользователям, там также можно заметить способ заблокировать доступ к чтению некоторых или всех дисков.)
Figure 1 Computer restrictions in SteadyState
Figure 1 Computer restrictions in SteadyState
Важно отметить, что параметр USB активен только при работе на системе Windows, где установлено и настроено SteadyState. Чтобы защититься от автономных атак, следует настроить BIOS на блокирование загрузки с устройств USB или компакт-дисков, а также защитить паролем сам BIOS.
Само собой, это не дает идеальной защиты. Помните третий закон из «10 непреложных законов безопасности» (microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx): «если у злоумышленника есть неограниченный физический доступ к вашему компьютеру – это уже не ваш компьютер». Серьезно настроенный человек, у которого есть достаточно времени и нужные средства, часто может обойти пароль BIOS.

Защита диска Windows
Тем, кто когда-либо использовал Windows XP с компакт-диска или Windows PE 2.0, многое из того, что написано мною дальше, покажется знакомым, и не удивительно – у нас есть общий опыт. Защита диска Windows предоставляет возможность полной отмены изменений для системного раздела Windows, сохраняя все изменения, внесенные в системный раздел, в кэше на этом же разделе . Этот компонент SteadyState крайне важен, поскольку именно он позволяет отменить все изменения, внесенные пользователями с течением времени.
Защита диска Windows Disk Protection полезна в первую очередь в тех случаях, когда необходимо обеспечить возможность быстрого отката (после незапланированного перезапуска или через установленный интервал) к изначальному развернутому состоянию системы. Она имеет четыре режима, которые можно установить в диалоге, показанном на Рис. 2:
Figure 2 Configuring Windows Disk Protection
Figure 2 Configuring Windows Disk Protection
Отключена Защита диска Windows полностью отключена, и все изменения записываются на диск как обычно.
Включена – отмена изменений при перезагрузке Защита диска Windows Disk Protection включена и отменяет изменения при каждой перезагрузке компьютера. По сути, это означает, что система возвратится к точно такому же состоянию, в котором она была в момент установки этого режима.
Включена – отмена изменений в определенное время Этот режим почти идентичен предыдущему, но изменения отменяются в определенный момент времени, а не при следующем перезапуске. Логично, что его стоит использовать при необходимости ежедневной или еженедельной отмены изменений.
Включена – постоянное сохранение изменений Этот решим легко спутать с режимом отключения, но он концептуально отличен своей временностью. Например, этот режим можно использовать при необходимости установить обновления к приложениям или новые приложения, либо настроить систему. Его не стоит использовать в течении продолжительных промежутков времени.
Отметьте, что защита диска Windows требует перезагрузки для смены режимов.

Создать расписание обновлений программного обеспечения
Установка расписания обновлений программного обеспечения полезна тем, что дает SteadyState возможность автоматически отключать и включать защиту диска Windows. При использовании SteadyState для установки обновлений он устанавливает защиту диска Windows Disk Protection на сохранение данных в ходе обновления, а затем возвращает ее в ранее установленный режим. Я однозначно рекомендую этот режим, поскольку он избавляет администратора от выполнения лишней задачи.
Нижеследующее ПО обеспечения безопасности поддерживается функцией обновления программного обеспечения: Computer Associates eTrust 7.0, McAfee VirusScan, Windows Defender и TrendMicro 7.0.

Диспетчер учетных записей пользователей
Функция «Добавить пользователя» позволяет настраивать параметры для новых пользователей системы. На рис. 3 показано, какие атрибуты можно настроить для нового пользователя: имя, пароль, представляющее его изображение и местонахождение его профиля. После создания пользователей можно установить ограничения и параметры для пользователей каждой из локальных учетных записей. Приятно то, что после добавления и настройки учетной записи на своей системе ее можно экспортировать на другие системы по мере необходимости (или сохранить в архиве).
Рис. 3 Добавление учетных записей
Рис. 3 Добавление учетных записей
Полезным аспектом диспетчера учетных записей пользователей является возможность создания профилей пользователей на вторичном разделе, через меню местонахождения пользователя, показанное на рис. 3. Обычно профили необходимо создавать в разделе Windows, если в ходе установки не указать вручную альтернативное местонахождение папки Documents and Settings в файле unattend.txt. Этот подход особенно полезен при использовании SteadyState, поскольку он отменяет изменения, внесенные в системный раздел Windows, когда защита диска Windows включена. Если необходимо, чтобы на профиле пользователя не сказывалась очистка кэша защиты диска Windows, при создании пользователя с помощью диспетчера учетных записей пользователей можно просто указать профиль пользователя, который следует хранить на другом локальном разделе.
Этот процесс работает посредством перезагрузки для очистки кэша защиты диска Windows, применения обновлений и повторной перезагрузки для перезапуска защиты диска Windows. В дополнение к работе центра обновления Windows, SteadyState также обновит файлы сигнатур для поддерживаемых им популярных антивирусных приложений (см. боковую панель «Как получить и использовать SteadyState»). Если приложение не поддерживается или необходимо запустить другое средство обновления, можно провести обновление и вручную – просто удостоверьтесь, что защита диска Windows отключена, или обновление сигнатуры пропадет.

Ограничения и параметры для пользователей
После выбора пользователя SteadyState делит ограничения для пользователей на четыре категории. Они выводятся из настроек групповой политики и уже знакомы большинству читателей.
Общие параметры контролируют профили пользователей и настройки принудительного выхода из системы. В их число входят параметры блокирования профиля и продолжительность времени ожидания для выхода из системы после окончания определенного времени работы или определенного периода простоя.
Параметры ограничений Windows, показанные на рис. 4, управляют специфическими для Windows элементами настройки. В число примеров входят лишение доступа к элементам интерфейса пользователя Windows, таким как компоненты меню «Пуск», или функции проводника Windows. Также доступны возможность блокировать доступ к дискам, обозначенным определенной буквой, и возможность отключить запись компакт-дисков.
Рис. 4 Параметры ограничений пользователей, специфичные для Windows
Рис. 4 Параметры ограничений пользователей, специфичные для Windows
Вкладка ограничений возможностей, приведенная на рис. 5, подробно контролирует доступ к большей части функций Internet Explorer®, позволяет установить домашнюю страницу Internet Explorer и до некоторой степени контролирует функции Microsoft® Office – главным образом те, что касаются выполнения сценариев Visual Basic® for Applications (VBA).
Рис. 5 Ограничение функций
Рис. 5 Ограничение функций
Параметры блокировки программ (см.рис. 6) контролируют возможность запуска конкретных приложений – по сути, это черный список. В него изначально внесены несколько распространенных приложений, и к ним можно добавлять новые. Обратите внимание, что блокировка этих элементов производится на основе определения их пути. Если пользователю позволено перемещать приложения с места на место, он может обойти ее. Чтобы не допустить этого, следует верно применять списки ACL для файлов и каталогов, а также прочие способы ограничения доступа к системе.
Рис. 6 Блокировка программ от выполнения
Рис. 6 Блокировка программ от выполнения
Другая важная новая возможность SteadyState основана на предварительно настроенных шаблонах, которые указывают уровни ограничений, относящиеся как к ограничениям Windows, так и к ограничениям возможностей. Шаблоны упрощают получение базовой настройки, работающей в зависимости от желаемого уровня блокировки возможностей и функций. Само собой, также есть возможность создавать собственные шаблоны.

Пределы возможностей SteadyState
SteadyState отлично справляется со стабилизацией общедоступных компьютерных систем организаций. Для продаваемого средства оно было бы хорошим. Для бесплатного средства оно замечательно. Но помните, что оно не всемогуще.
Общедоступные компьютерные системы уязвимы для атак и даже ненамеренного причинения ущерба. Необходимо обеспечивать изоляцию этих систем от ненужной им информации. Хотя у SteadyState также существует возможность блокировать доступ к приложениям, это осуществляется посредством политик ограниченного использования программ. И, как несколько лет назад заметил Марк Руссинович (Mark Russinovich), существуют методики, при помощи которых грамотный пользователь может создать приложение, которое выглядит безобидным, но может позволить обойти эти политики даже пользователю с ограниченными правами (blogs.technet.com/markrussinovich/archive/2005/12/12/circumventing-group-policy-as-a-limited-user.aspx). Эту уязвимость, которую можно устранить только блокированием любого доступа к устройствам или Интернету, следует постоянно иметь в виду. Всегда помните третий закон...
Очевидно, что SteadyState является лишь одним компонентом грамотно настроенной общедоступной компьютерной системы. Помните о важности регулярного применения обновлений через центр обновления Windows и правильной настройки брандмауэра Windows (или другого брандмауэра). Кроме того, не забудьте про установку и настройку антивирусов, антишпионских программ и прочих мер безопасности, на необходимость которых указывает анализ угроз. Подобным же образом контролируйте доступ к компьютеру – если это невозможно, контролируйте возможность компьютера «видеть» те или иные данные. И не храните конфиденциальные данные на локальной системе.
Наконец, проверяя свою платформу, убедитесь в том, что тестирование охватывает SteadyState (со включенной защитой диска Windows, если планируется ее использовать) и все дополнительное ПО, которое планируется использовать в системе. Необходимо удостовериться в оптимальной совместной работе программного обеспечения и SteadyState.

Поддержка для SteadyState
Виденные мною отзывы пользователей о SteadyState весьма положительны. Пока что слышал лишь о нескольких мелких сбоях, часть из которых затрагивает необходимый порядок добавления пользователей. Многие из этих сбоев (вместе с прочими советами и рекомендациями) освещаются в весьма активном сообществе Windows SteadyState (ссылка на которое дается в нескольких местах самого SteadyState и его документации), расположенном на forums.microsoft.com/windowstoolsandutilities.
Перед началом работы я бы также порекомендовал ознакомиться с руководством по SteadyState, доступном на go.microsoft.com/fwlink/?LinkId=104722. Оно предоставляет немало советов и рекомендаций для успешного использования SteadyState.

Заключение
SteadyState предоставляет отличный пакет функций для любой системы Windows XP, доступ к которой необходимо контролировать – и оно бесплатно! Радикально улучшенная функция защиты диска Windows и усовершенствования в интерфейсе пользователя означают более простое развертывание и, в целом, более простое управление системами с общим доступом.
Идет ли речь о системах компьютерных лабораторий, центрах интерактивной информации для посетителей либо персонала, или о каких либо еще вариантах совместного использования компьютеров, SteadyState помогает в устройстве подобных систем и их обслуживании. И оно избавляет от необходимости восстанавливать образ системы каждую неделю только для того, чтобы начать работу «с чистого листа». По моему мнению, это огромное улучшение.

Уэс Миллерработает управляющим выпуском технической продукции в компании Initiate Systems (InitiateSystems.com), расположенной в городе Остин, штат Техас. Ранее Уэс работал в компании Winternals Software, а также руководителем программы в корпорации Майкрософт. Связаться с Уэсом Миллером можно по адресу technet@getwired.com.


 Заметки разъездного инженера: Самая важная задача
Заметки разъездного инженера
Самая важная задача
Эрик Н. Буш

Билл Гейтс выбирается из офиса дважды в год, беря себе «неделю на размышления». Он изолирует себя от сотрудников, телефонных звонков и электронной почты, посвящая это время чтению. Он обдумывает состояние технологий в корпорации Майкрософт и в мире. Он пытается понять, над чем работает его корпорация и все остальные и какова при этом лучшая стратегия продвижения вперед. Гейтс знает, насколько важны обдумывание и планирование.
Каждый из нас может выиграть от ежедневного выделения некоторого количества времени на простое размышление и планирование – времени на формулировку идей, решение проблем, расстановку приоритетов и задач, наконец, просто на мечты. Попробуйте выполнять это упражнение в одно и то же время и в том же месте каждый день, избегая при этом взаимодействия с кем-либо. Самой важной задачей для нас является планирование и расстановка приоритетов на начинающийся день. Те, кто работает на управленческой должности, вообще могут провести большую часть своего времени, планируя чужую работу и расставляя для нее приоритеты.
Управляет ли сотрудник корпоративной сетью, администрирует ли незаменимую для работы базу данных или занимается разработкой корпоративных информационных систем и управлением ими, каждый день перед ним встают проблемы, которые могут отвлечь его внимание от выполнения действительно важной работы. К концу дня ему зачастую сложно сказать, вырвался ли он вперед или отстал еще более.
Целью всякого специалиста по ИТ должна быть лучшая организация работы, способность предвосхищать события и быстрее реагировать на экстренные ситуации. Планирование позволяет перейти от ответов на события к их опережению, однако для этого перехода необходимы обдумывание, планирование и расстановка приоритетов. Полезным может быть ведение списка задач, разбитого на три категории, и начало каждого дня с их проверки: «В работе», «При первой же возможности» и «Хорошо бы». Используя эти списки, можно выгадать время для создания решений, предотвращающих кризисы.
Список «В работе» особенно важен. Продвигаться к завершению этих ключевых задач необходимо каждый день. Сосредоточьтесь на основных целях компании и группы. Задачи, которые не сказываются на них прямо, можно перевести в категорию менее срочных. Тем, кто работает на управленческой должности, следует организовать процесс, помогающий всем сотрудникам оставаться в курсе основных приоритетов.
Категории «При первой же возможности» и «Хорошо бы» обычно предназначены для тех стратегических планов, которые сэкономят компании время и деньги, делая ее более конкурентоспособной. Определите эти задачи и работайте над их выполнением неторопливо и методично, перемещая те, которые становятся более приоритетными, в категорию «В работе».
Однако не забудьте: наличие списка приоритетов еще не означает, что работа идет. Несколько советов, помогающих в ее выполнении:
  • Сперва разбирайтесь с простыми и быстро выполнимыми задачами.
  • Затем беритесь за те, выполнять которые не слишком охота.
  • К увлекательным задачам приступайте в конце.
  • Избегайте смены контекста. Последовательно выполняйте похожие задачи, если это возможно.
  • Однако, зайдя в тупик, переходите к следующей задаче, пока не сможете переключиться обратно.
  • Отказывайтесь от выполнения задач, для выполнения которых являетесь неудачным кандидатом, передавайте их другим или предлагайте альтернативы.
  • Определите, когда работаете наиболее продуктивно. Отводите это время для важных задач.
Понимание того, как распорядиться своим временем, поможет работать хорошо. Люди, которые плывут по течению жизни без всякого плана, никогда не бывают довольны тем, к чему их это приводит, поскольку никогда толком сами не знали, к чему стремятся.

Эрик Н. Буш является ведущим специалистом по разработке программного обеспечения в группе Engineering Excellence корпорации Майкрософт. Он выполняет роль внутреннего консультанта и преподавателя, работающего над инженерными и организационными улучшениями в областях навыков персонала, процедур и технологий. С ним можно связаться по адресу ericbush@microsoft.com.


 Конфиденциально о Windows : Напомните мне никогда больше этого не делать
Конфиденциально о Windows
Напомните мне никогда больше этого не делать
Раймонд Чен

Существует старое средство для серии операционных систем Windows® 95, известное как Automatic Skip Driver («драйвер автоматического пропуска»). Одной из первых мыслей об этом средстве обычно является удивление по поводу его странного имени и даже подозрение, что аббревиатура ASD поначалу имела иное значение. Данное подозрение верно.
Windows 95 приходилось иметь дело со множеством устройств без возможности Plug and Play, поскольку подавляющее большинство систем того времени появились до выхода спецификаций Plug and Play. Обнаружение оборудования в отсутствии настоящих устройств Plug and Play было весьма пугающим занятием.
Например, обнаружение модема осуществлялось путем отправки запросов значений десятков регистров модема. Несмотря на наличие достаточно стандартного базового набора команд для модема, в темных углах программного языка возникали существенно отличающиеся варианты реализации. Неудивительно, что возникавшее отсутствие единообразия создавало помехи для программ связи, поскольку требовало дополнения специальных случаев для различных моделей модемов, учитывающих их индивидуальные особенности; однако, все то же отсутствие единообразия стало нечаянным подарком для Windows: поскольку в поведении каждого модема были мелкие различия, Windows могла исследовать эти темные углы и сравнивать поведение модема с таблицей известных модемов и их ответов.
В группе разработчиков Windows 95 был человек, работа которого заключалась в установке чуть ли не каждого доступного когда-либо модема и запуске маленькой программы, всесторонне испытывавшей модем, проверявшей все темные углы и собиравшей результаты для создания исчерпывающей базы данных модемов. Те, у кого еще есть доступ к машине, использующей Windows 95, могут заглянуть в каталог Windows\Inf и полюбоваться на множество файлов, имена которых начинаются с MDM. Это свыше мегабайта информации о устройствах, посвященной модемам. Это несколько лет чьей-то жизни, сжатые в мегабайт нечитаемых шестнадцатеричных цифр.
Обнаружение модемов было достаточно безопасным делом, поскольку все модемы вели себя, в целом, примерно одинаково, вся радость заключалась в мелочах. Гораздо страшнее были устройства, использовавшие порты ввода/вывода. Например, для обнаружения, установлена ли конкретная видеокарта, модуль обнаружения видеокарт диспетчера настройки Windows 95 посылал тщательно выбранные значения нужным портам ввода/вывода и ждал ответов от устройства. Если устройство отвечало верно, диспетчер предполагал, что искомое устройство найдено. Если нет, он переходил на поиск следующей модели видеокарты.
Само собой, если устройство, установленное на этом порте ввода/вывода, не было той видеокартой, которую искал диспетчер настройки, оно могло быть весьма возмущено приходом бессмысленных значений. В зависимости от степени своей обидчивости оно могло вызвать зависание или перезагрузку компьютера. Это не сулило ничего хорошего диспетчеру настройки. Поэтому и появился на свет модуль, известный как ASD.
Перед выполнением этих потенциально опасных прощупываний оборудования диспетчер настройки создавал файл, говоривший, по сути: «О нет! Я собираюсь выполнить опасное действие N!» Это была компьютерная версия классического конверта «Вскрыть в случае моей смерти», который герой боевика оставляет своей девушке перед отправкой на смертельную схватку со злодеем.
Если опасное действие N действительно вызывало зависание или перезагрузку, то при следующем запуске системы он видел этот волшебный файл и «открывал конверт», чтобы увидеть, что сбой системы был вызван опасным действием N. Из этого система заключала, что попытка обнаружить устройство N оказалась катастрофической и понимала, что больше этого делать не стоит!
Модуль, выполнявший эту работу, был назван ASD. Аббревиатура ASD была сокращением от "Attempting Something Dangerous" («Попытка сделать нечто опасное»).

Раймонд Ченна своем веб-узле The Old New Thing (Хорошо забытое старое) и в одноименной книге (изд-во Addison-Wesley, 2007 г.) рассказывает об истории развития Windows и касается вопросов программирования в среде Win32. Он осторожен, поскольку плита уж очень горяча.