 TechNet Magazine March 2008

TechNet Magazine March 2008

Специальная статья: Windows Server 2008: Изменения внутреннего устройства ядра Windows Server 2008

Подробное рассмотрение основных изменений ядра Windows Server 2008, повышающих надежность, производительность и масштабируемость. Знакомство с применяемыми в Windows Server 2008 методами, позволяющими более эффективно использовать пулы потоков, упростить восстановление после сбоев оборудования, усовершенствовать виртуализацию с помощью Hyper-V и многое другое.

Mark Russinovich Специальная статья: Windows Server 2008: Новые возможности служб доменов Active Directory

В Windows Server 2008 появился ряд существенных изменений слжуб доменов Active Directory. В данное статье подробно рассматривается, каким образом контроллеры доменов только для чтения и вариант установки Windows Server Core (ядро сервера) позволяют укрепить безопасность среды, каким образом новый диспетчер серверов и обновленные функции резервного копирования позволяют упростить упрваление, каким образом новые средства аудита помогают гарантировать соблюдение всех норм и требований.

Gil Kirkpatrick Специальная статья: Windows Server 2008: Начало работы с IIS 7.0

В состав IIS 7.0 входят новые функции — их слишком много, чтобы можно было рассмотреть в одной статье. Новая версия основана на надежной и ориентированной на безопасность структуре IIS 6.0, предоставляя улучшения, значительно повышающие управляемость и расширяемость платформы. В данной статье содержится обзор некоторых наиболее важных изменений IIS 7.0.

Isaac Roybal Специальная статья: Windows Server 2008: Сетевой доступ в Windows Server 2008 на основе политик

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

Ian Hameroff and Amith Krishnan Специальная статья: Windows Server 2008: Настройка ролей с помощью диспетчера серверов

Сервер службы доменных имен (DNS) не обязан быть сервером печати. Одним из подходов Windows Server 2008 к улучшению безопасности и управляемости является упрощение ролей сервера, позволяющее без труда установить лишь необходимые средства и службы и ничего более. Данная статья является введением в использование диспетчера серверов для настройки ролей и упрощения развертываний.

Byron Hynes Специальный репортаж: Windows Server 2008: Развертывание Windows Server 2008 с помощью System Center

В свое время администраторам серверов приходилось устанавливать Windows Server вручную, используя компакт-диски или DVD, а затем проводя по нескольку часов за настройкой сервера. С выпуском System Center Configuration Manager 2007 и нового набора средств развертывания Microsoft Deployment Toolkit (MDT) у них появилась возможность использовать средства, которые администраторы настольных систем использовали для автоматизации развертываний уже несколько лет.

Tim Mintner Специальный репортаж: Windows Server 2008: Аудит и соответствие нормативным требованиям в Windows Server 2008

Аудит изменений теперь является центральной задачей для отделов ИТ. Это важная часть знакомства с системами и данными и управления ими в распределенной среде. В данной статье рассказывается про обычные задачи, про сферу соответствия нормативным и регулятивным требованиям, про некоторые из основ аудита и про то, как можно создать всеохватывающую стратегию аудита.

Rob Campbell and Joel Yoker От редактора: За здоровье Windows Server 2008

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

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

Greg Steen Обзор служебных программ: Сертификация торгового знака Windows Server

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

Venkat Krishnamachari Кабельщик: Перенос интрасети на IPv6 с помощью ISATAP

Готовитесь к переходу на IPv6? Кабельщих объясняет, как использовать технологию перехода IPv6 для устройства подключения по IPv6 и переноса в поддерживающую IPv6 интрасеть.

Joseph Davies Windows PowerShell: Отчет о ходе выполнения

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

Don Jones Эй, сценарист!: Игры в наперстки с помощью оболочки

Scripting Guys демонстриуют, как можно изменить дату последнего изменения файла при помощи небольшого сценария и объекта Shell.

The Microsoft Scripting Guys На страже безопасности: Использование SCW в Windows Server 2008

Читатели, без сомнения, уже слышали о новом средства диспетчера серверов в Windows Server 2008. Но мастер настройки безопасности (Security Configuration Wizard – SCW) также остается доступным. Узнайте, почему SCW все еще стоит использовать.

Jesper M. Johansson Документы о рабочей среде: Нельзя быть слишком толстым или слишком тонким

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

Wes Miller Полевые заметки: Подготовка к «ИТ 2.0»

Мой взгляд на то, как важно усваивать уроки прошлого для ответа на вызовы будущего ИТ.

Romi Mahajan О Windows из первых рук: Как бета-версии становятся версиями-кандидатами

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

Raymond Chen


 Специальная статья: Windows Server 2008: Изменения внутреннего устройства ядра Windows Server 2008
Специальная статья: Windows Server 2008 Марк Руссинович (Mark Russinovich)

Изменения внутреннего устройства ядра Windows Server 2008
Краткий обзор:
  • Управление памятью и SMB 2.0
  • Автоматическое устранение неполадок файловой системы NTFS, система обработки ошибок Windows Hardware Error Architecture и инструмент проверки драйверов
  • Обеспечение масштабируемости посредством портов завершения ввода-вывода, пулов потоков и организации памяти по принципу NUMA
  • Виртуализация Hyper-V

Windows Server 2008 — новейшая версия серверной платформы Майкрософт, в которую внесены на уровне системы изменения, охватывающие все функциональные участки операционной системы, от управления памятью
до планирования потоков, и от поддержки работы в сети до обеспечения безопасности, причем это только часть внесенных изменений.
Поскольку в операционной системе Windows Server® 2008 используется то же ядро, что и в Windows Vista® SP1, в нее включены многие усовершенствования, уже обсуждавшиеся в моих предыдущих статьях, опубликованных в TechNet Magazine: «Внутреннее устройство ядра ОС Windows Vista» (в трех частях – в февральском, мартовском и апрельском выпусках за 2007 г.) и «Управление учетными записями пользователей Windows Vista: взгляд изнутри» (июнь 2007 г.). Только небольшая часть средств, описанных в этих статьях и реализующих характерные для клиентов возможности, не включена в операционную систему Windows Server 2008 — например SuperFetch, ReadyBoost, ReadyDrive, ReadyBoot и служба планировщика классов мультимедиа MMCSS.
Вместо того, чтобы повторно обсуждать появившиеся в Windows Vista важные изменения ядра, которые присутствуют также и в Windows Server 2008, например, назначение приоритетов операциям ввода-вывода, новая архитектура загрузки, BitLockerTM, целостность кода и необходимые уровни целостности, я сосредоточусь на важнейших изменениях, не обсуждавшихся в этих статьях, включая те, которые относятся к надежности, эффективности, масштабируемости, а также на Hyper-VTM — новой технологии Майкрософт для виртуализации компьютера гипервизора.
Подобно предыдущим статьям, в данной статье содержание ограничено обсуждением ядра операционной системы, Ntoskrnl.exe, а также тесно связанными с ним компонентами. Например, в статье не обсуждаются изменения, относящиеся к установке (WIM, или Windows® Imaging Format, и Component-Based Servicing), управлению (групповая политика и усовершенствования в Active Directory®), общие средства текущего контроля и диагностики (диагностическая инфраструктура Windows), сетевые возможности ядра (реализация нового брандмауэра и TCP/IP), ядро сервера и серверные роли.
Работа в среде многопроцессорных систем
Одно из изменений на низком уровне системы состоит в том, что в Windows Server 2008 входит только версия ядра, предназначенная для работы в среде многопроцессорных систем. Раньше в Windows использовалась версия, ориентированная на однопроцессорные системы, установленные на машинах с единственным ЦПУ, поскольку такая версия обеспечивала несколько большую производительность за счет отсутствия кода для синхронизации, необходимого только в многопроцессорных средах. В связи с тем, что оборудование стало работать быстрее, повышением производительности за счет оптимизации можно пренебречь, и в настоящее время большинство серверных систем содержит несколько процессоров, что избавляет от потребности в однопроцессорной версии.
На рис. 1 показаны варианты ядра Windows Server 2008. Версия ядра, используемая в системе, зависит от того, является ли версия операционной системы отладочной (Checked) или розничной, от варианта установки — в 32- или 64-разрядной архитектуре (Itanium, Intel 64 или AMD64) и, в случае установки в 32-разрядной среде, от того, имеется ли в системе более 4 ГБ физической памяти, и поддерживается ли предотвращение выполнения данных (DEP — Data Execution Prevention). Кроме этого, предполагается, что Windows Server 2008 — последняя система, поддерживающая 32-разрядную версию.
Figure 1 Варианты ядра Windows Server 2008 (Close Figure 1)

Ядро | 32-разрядная архитектура | 64-разрядная архитектура
Многопроцессорная архитектура | Да | Да
Установлен флажок «Многопроцессорная архитектура» | Да | Да
Расширение физических адресов (PAE) многопроцессорной архитектуры | Да | Нет
Установлен флажок «PAE многопроцессорной архитектуры» | Да | Нет
Каждый выпуск Windows Server нацелен на повышение производительности основных серверных операций, таких как операции с файлами, сетевые операции ввода-вывода и управление памятью. Кроме этого, в Windows Server 2008 вошло несколько изменений и новых компонентов, позволяющих системе Windows использовать преимущество новых архитектур оборудования, настраивать систему на работу с сетями, имеющими большую задержку и устранить факторы, ограничивавшие производительность в предыдущих версиях Windows. В данном разделе обсуждаются усовершенствования в диспетчере памяти, системе ввода-вывода и новая сетевая файловая система, SMB 2.0.

Управление памятью
Эксперимент: обзор объемных дисковых операций ввода-вывода
В системе Windows Server 2008 для просмотра объемных файловых операций ввода-вывода предусмотрен такой инструмент текущего контроля файловой системы, как TechNet Sysinternals Process Monitor (technet..microsoft.com/sysinternals/bb896645.aspx).
Существует несколько способов работы с операциями ввода-вывода большого объема. Если имеется вторая система, работающая под управлением пакета обновлений 1 для Windows Vista или под управлением Windows Server 2008, на сервере можно запустить Process Monitor и следить за копиями файлов во второй системе. Также распространенным вариантом работы с операциями объемного ввода-вывода для файла подкачки является выполнение программы, интенсивно использующей память, которая вынуждает диспетчер памяти записывать страницы в файл подкачки.
На рис. A показан Process Monitor после выполнения в среде Windows XP программы с большой потребностью в памяти. В меню параметров Process Monitor установлен флажок «Включить расширенный вывод» и установлен фильтр для отображения только операций записи в файл подкачки, pagefile.sys. В столбце «Подробные сведения» видно, что выполняются операции записи объемом 64 КБ.
Рис. А
При выполнении этих же действий в среде Windows Server 2008, скорее всего, сложится ситуация, похожая на ту, которая показана на рис. B и где видно, что большинство операций записи имеют объем приблизительно 1 Мбайт.
Рис. Б

В диспетчер памяти системы Windows Server 2008 внесено несколько усовершенствований для повышения производительности. Например, при доставке данных из файла подкачки или выполнении упреждающих операций ввода-вывода с отображенными файлами генерируются дисковые операции ввода-вывода как меньшего, так и большего объема. Выполнение объемного файлового ввода-вывода облегчается благодаря изменениям в системе ввода-вывода, освободимшим ее от ограничения в 64 КБ на объем операций ввода-вывода, существовавшего начиная с первого выпуска Windows NT®.
Кроме этого, важно отметить, что при упреждающем чтении из отображенных файлов, выполняемом диспетчером кэша, объем данных в системе Windows Server 2008, как правило, в два раза больше, чем в системе Windows Server 2003, и эти операции попадают напрямую в список ожидания (код системы и кэш данных). Такое поведение возникает вместо требования к диспетчеру кэша отображать виртуальную память и считывать данные в рабочий набор системы (память, приписанная системе диспетчером памяти), что может вызвать не обусловленное необходимостью вытеснение из рабочего набора используемого кода или данных.
Диспетчер памяти выполняет объемные операции ввода-вывода также и при записи данных в файл подкачки. Хотя Windows Server 2003 часто выполняет операции записи даже меньшего, чем 64 КБ, объема, в среде Windows Server 2008 диспетчер памяти обычно генерирует операции записи объемом 1 МБ.
Помимо повышения производительности за счет сокращения числа операций записи в файл подкачки, объемные операции записи позволяют также уменьшить фрагментирование файла подкачки. Это, в свою очередь, приводит к сокращению числа операций чтения и поиска на диске, необходимых для извлечения нескольких страниц, поскольку, скорее всего, они будут смежными.
Диспетчер памяти пытается также записывать другие измененные страницы, находящиеся поблизости от той, которая записывается в адресное пространство процесса, которому они принадлежат. При этом диспетчер выполняет запись в тот участок файла подкачки, где уже находятся другие соседние страницы. Это также минимизирует фрагментацию и позволяет повысить производительность, поскольку страницы, которые со временем могут быть записаны в файл подкачки, уже записаны. Дополнительно это сокращает число операций чтения страниц, необходимых для извлечения смежных страниц процесса. Дополнительные сведения об использовании диспетчером памяти объемных операций ввода-вывода см. на боковой панели «Эксперимент: обзор объемных дисковых операций ввода-вывода».

SMB 2.0
Протокол удаленной файловой системы Server Message Block (SMB), известный также под названием Common Internet File System (CIFS), служил основой для файловых служб Windows с момента появления в Windows средств по обслуживанию файлов. В течение последних нескольких лет проектные ограничения протокола SMB ограничивали производительность файловых служб и возможности использования преимуществ новых функций локальных файловых систем. Например, максимальный размер буфера, который можно передать в одном сообщении, составляет приблизительно 60 КБ, и в SMB 1.0 не предусмотрена работа с символическими ссылками клиентской стороны NTFS, которые были добавлены в Windows Vista и Windows Server 2008.
В Windows Vista и Windows Server 2008 появилась версия SMB 2.0, нового протокола удаленного обслуживания файлов, который используется Windows в случае, когда его поддерживает и клиент, и сервер. Помимо правильной обработки символических ссылок и других усовершенствований NTFS, протокол SMB 2.0 использует пакетирование данных для минимизации числа сообщений, которыми обмениваются клиент и сервер. Пакетная обработка позволяет повысить пропускную способность в сетях с высокой задержкой, таких как глобальные сети (WAN), поскольку она дает возможность передавать больший объем данных в один прием.
В то время как SMB 1.0 инициирует операции ввода-вывода для одного файла последовательно, SMB 2.0 реализует операции ввода-вывода в конвейерном режиме, позволяя инициировать для одного файла несколько параллельно выполняющихся операций ввода-вывода. С целью определения глубины конвейеризации измеряется объем серверной памяти, используемой клиентом для ожидающих выполнения операций ввода-вывода.
Благодаря изменениям в диспетчере памяти системы ввода-вывода и системе ввода-вывода Windows, автоматической настройке окна получения TCP/IP и усовершенствованиям механизма копирования файлов, SMB 2.0 обеспечивает значительные усовершенствования и сокращение времени копирования файлов при объемной передаче данных. Поскольку в обеих операционных системах реализован протокол SMB 2.0, развертывание файловых серверов Windows Server 2008 с помощью клиентов Windows Vista дает возможность использовать SMB 2.0 и добиться этих преимуществ в производительности.

Надежность, обеспечиваемая автоматическим устранением неполадок в NTFS
Надежность является важнейшей характеристикой сервера, и операционная система Windows Server 2008 предоставляет разнообразные усовершенствования, облегчающие администраторам поддержку бесперебойной работы серверов, включая интерактивное восстановление согласованности NTFS, новую инфраструктутру для создания отчетов о сбоях оборудования и расширения инструмента проверки драйверов.
Объем современных накопительных устройств достигает нескольких терабайт, и перевод тома в автономный режим для проверки согласованности может привести к многочасовому перерыву в обслуживании. Определив, что многочисленные повреждения диска локализованы в одном файле или части метаданных, Windows Server 2008 применяет новый компонент NTFS для автоматического устранения неполадок и исправляет повреждение, не переводя том в автономный режим.
Если NTFS обнаруживает повреждение, она перекрывает доступ к поврежденному файлу или файлам и создает системный рабочий поток, вносящий в поврежденные структуры данных исправления, аналогичные исправлениям Chkdsk, и обеспечивающие доступ к восстановленным файлам по завершении работы потока. В течение этой операции доступ к другим файлам обеспечивается в обычном режиме, что минимизирует нарушения обслуживания.

Инфраструктура WHEA
Инфраструктура WHEA, входящая в Windows Server 2008, обещает упростить управление сбоями оборудования и обеспечить упреждающий отклик на ошибки, не являющиеся неустранимыми. Зачастую серверы должны обеспечивать строгие гарантии бесперебойной работы, поэтому в таких системах жизненно важной является своевременная идентификация ошибок и отклик на их возникновение.
Анализ сбоев, предоставленный корпорации Майкрософт посредством OCA (Online Crash Analysis), показывает, что приблизительно 10 процентов сбоев операционных систем является реакцией на сбой оборудования, но определение глубинной причины этих сбоев оказывается сложным или невозможным из-за того, что оборудование предоставляет недостаточно информации для фиксации сбоя. Кроме этого, до появления Windows Server 2008, в системе Windows отсутствовали встроенная поддержка для текущего контроля за работоспособностью устройств и средства исправления или уведомления о грозящем сбое. Причина этого заключается в том, что не существует общего формата ошибок устройств и не поддерживается программное обеспечение, управляющее обработкой ошибок.
WHEA предоставляет единый механизм обнаружения источника ошибки и формирования отчетов для устройств платформы, включая процессоры, память, кэши и такие шины, как PCI и PCI Express. Это достигается посредством реализации архитектуры, показанной на рис. 2, основой которой является интерфейс API ядра, к которому обращаются источники ошибок с отчетами о возникших ошибках. API требует предоставления информации об ошибках в общем формате и регистрирует ошибки с помощью подсистемы отслеживания событий для Windows (ETW) (информация о неустранимых ошибках регистрируется после перезагрузки).
Рис. 2 Инфраструктура WHEA для создания отчетов об ошибках
Рис. 2 Инфраструктура WHEA для создания отчетов об ошибках
Подсистема ETW появилась в Windows 2000, и использование ETW в архитектуре WHEA облегчает производителям оборудования и поставщикам программного обеспечения разработку управляющих диагностикой устройств приложений, которые работают с событиями WHEA. При возникновении события, грозящего сбоем системы, WHEA гарантирует сохранение записи о неустранимой ошибке в файле аварийной копии памяти, чтобы администраторы могли определить основную причину сбоя.
Другой важной частью архитектуры WHEA является драйвер аппаратных ошибок, специфичных для платформы (PSHED), находящийся в библиотеке %Systemroot%\System32\Pshed.dll. Ядро скомпоновано с PSHED, и драйвер взаимодействует с оборудованием платформы и оборудованием с микропрограммным обеспечением, выполняя, по существу, роль транслирующего слоя между интерфейсом уведомлений об ошибках и интерфейсом API архитектуры WHEA, обеспечивающим отчеты об ошибках. Майкрософт поставляет PSHED для всех архитектур платформы (x86, x64, Itanium), а драйвер PSHED разработан по модели подключаемого модуля, чтобы производители и поставщики оборудования могли переопределять поведения по умолчанию на поведения, характерные для их платформ.
Наконец, в компоненты системы, взаимодействующие с другими источниками ошибок (включая драйверы устройств, слой абстрагирования оборудования (HAL) и ядро), можно внедрить обработчики ошибок оборудования низкого уровня (LLHEL), обрабатывающие состояние ошибки на начальном этапе. Задача обработчика LLHEL заключается в извлечении из устройства информации об ошибке, уведомлении драйвера PSHED, чтобы он мог собрать дополнительную информацию об ошибке, характерную для платформы, и затем обратиться к интерфейсу API архитектуры WHEA, обеспечивающему отчеты об ошибках.

Инструмент проверки драйверов
Driver Verifier, мощный инструмент для отслеживания драйверов устройств, содержащих ошибки, и сбойного оборудования, входит во все копии Windows, начиная с Windows 2000. Как правило, администраторы настраивают Driver Verifier (%Systemroot%\System32\Verifier.exe) на тщательный текущий контроль драйверов устройств, на которые падает подозрение в связи со сбоями системы. Driver Verifier перехватывает недопустимые операции драйверов, так что файл аварийной копии памяти указывает непосредственно на виновную сторону.
Недостаток предыдущих реализаций Driver Verifier заключался в том, что большая часть изменений конфигурации требует перезагрузки системы, что очевидно является нежелательным для производственного сервера. В реализации Driver Verifier в Windows Server 2008 эта процедура усовершенствована посредством устранения требования перезагрузки для большинства практичных проверок, что позволяет устранять неполадки на проблемном сервере без необходимости его перезагружать.
Кроме этого, в инструменте Driver Verifier появились три новых проверки, которые видны на рис. 3. Проверки безопасности гарантируют, что драйверы устройств устанавливают безопасные разрешения на объектах, которые они используют для взаимодействия с приложениями. Принудительное выполнение ожидающих запросов на операции ввода-вывода осуществляет проверку устойчивости драйвера к асинхронным операциями ввода-вывода, которые выполняются незамедлительно, а не после задержки. Проверки «Разные» выполняют поиск драйверов, которые освобождают используемые ресурсы не надлежащим образом, неправильно используют интерфейсы API инструментария WMI и пропускают дескрипторы ресурсов.
Рис. 3 В инструменте Driver Verifier установлены флажки для Windows Server 2008
Рис. 3 В инструменте Driver Verifier установлены флажки для Windows Server 2008

Масштабируемость
Под масштабируемостью имеется в виду способность операционной системы или приложения эффективно использовать несколько процессоров и большие объемы памяти. В каждом выпуске Windows возможности масштабируемости расширяются за счет минимизации или устранения использования блокировок, сокращающих степень параллелизма в многопроцессорных средах. В Windows Server 2008 эта тенденция сохранена.
Относительно небольшое, но значимое усовершенствование внесено в код, реализующий завершение срока действия таймера, который более не запрашивает блокировки диспетчера — блокировки планировщика в рамках всей системы, используемой всеми низкоуровневыми операциями синхронизации. Результирующее сокращение непроизводительных издержек на синхронизацию ЦПУ позволяет системам серверов терминалов Windows Server 2008 поддерживать приблизительно на 30 процентов больше параллельно работающих пользователей, чем в среде Windows Server 2003.
К другим усовершенствованиям возможностей масштабирования в среде Windows Server 2008 относятся усовершенствования портов, новая реализация пула потоков, более эффективное использование оборудования с архитектурой NUMA и динамическое создание системных разделов.

Усовершенствованная обработка порта завершения ввода-вывода
Большинство серверных приложений Windows, включая IIS, SQL Server® и Exchange Server, для минимизации переключений между несколькими потоками выполнения при выполнении операций ввода-вывода опираются на интерфейс API синхронизации Windows, называемый портом завершения. Для этого сначала устанавливается соответствие между уведомлениями о прибытии новых запросов, например, клиентских подключений веб-сервера, и портом завершения и назначается пул потоков для ожидания уведомлений. По прибытии запроса Windows предусматривает поток, который затем, как правило, выполняет другие операции ввода-вывода, такие как чтение веб-страницы с диска и отправка ее клиенту для выполнения запроса.
Чтобы этот же поток мог вернуться к ожиданию дополнительных клиентских запросов как можно быстрее, поток инициирует операции ввода-вывода асинхронно и устанавливает соответствие между завершениями ввода-вывода и портом завершения. Затем поток возвращается к ожиданию на порте завершения, который планирует поток, когда прибывает новый запрос или завершается одна из операций ввода-вывода. Таким образом один и тот же поток остается активным на ЦПУ, попеременно переходя от обработки клиентских запросов к ожиданию на порте завершения и обратно.
Недостатком реализации порта завершения в предыдущих версиях Windows являлось то, что когда операция ввода-вывода завершалась, система ввода-вывода порождала поток, инициировавший операцию ввода-вывода для незамедлительного выполнения небольшой обработки завершения, независимо от того, какие еще действия выполнялись в это время. Если в это время были активны другие потоки, это зачастую приводило к тому, что планировщик отдавал предпочтение активному потоку, и контекст переключался на поток, инициировавший операцию.
Windows Server 2008 избегает таких переключений контекста, откладывая обработку завершения до следующего потока, чтобы продолжить ожидание на порте завершения, с которым связана операция ввода-вывода. Таким образом, даже если другой поток является следующим, который должен находиться в ожидании на порте завершения, он будет выполнять обработку завершения, прежде чем исполнять другой код, и планировщику не потребуется переключаться на поток, инициировавший ввод-вывод. Эта минимизация переключений контекста позволяет радикально расширить масштабируемость серверных приложений, работающих с большой нагрузкой.

Повышение эффективности пулов потоков
Написание приложений, использующих преимущества наличия нескольких процессоров, может оказаться сложной задачей, поэтому в Windows XP введены рабочие пулы потоков, инфраструктура и соответствующий интерфейс API, позволяющий абстрагироваться от подробных сведений о выполнении небольших порций работы процессорами. Приложение указывает рабочие элементы для API пула потоков, который затем выполняет их на одном из ряда потоков, создаваемых им для каждого ЦПУ системы и которыми он управляет.
Назначение пула потоков состоит в минимизации переключений контекста посредством использования одних и тех же потоков для выполнения нескольких рабочих элементов подряд. Если это невозможно вследствие того, что один из его потоков уже занят выполнением другой работы, он выполняет рабочий элемент с использованием другого потока на другом ЦПУ.
Реализация пула потоков в Windows Server 2008 повышает эффективность использования процессоров опосредованно, используя преимущества усовершенствований порта завершения, и непосредственно, оптимизируя управление потоками, чтобы рабочие потоки динамически поступали и уходили, по мере необходимости в них для манипулирования рабочей нагрузкой приложения. Далее, центральная часть инфраструктуры была переведена в режим ядра, что минимизирует количество обращений к системе, осуществляемых использующими API приложениями. Наконец, новый API облегчает приложениям выполнение некоторых операций, например вывод из очереди единиц работы во время закрытия приложения.

Оптимизации NUMA
В Windows Server 2003 появились оптимизации для компьютеров NUMA в планировщике потоков и диспетчере памяти, а в Windows Server 2008 оптимизации NUMA добавлены в диспетчер операций ввода-вывода и расширены оптимизации NUMA диспетчера памяти.
Системы NUMA, как правило, являются многопроцессорными системами, в которых память обладает различной задержкой, зависящей от того, который процессор обращается к ней (см. рис. 4). Память делится на узлы, при этом задержки между процессорами и узлами могут иметь разное значение, и каждый ЦПУ считается частью того узла, к которому он имеет самый быстрый доступ.
Рис. 4 Пример системы NUMA
Рис. 4 Пример системы NUMA
Системы NUMA, в особенности имеющие более восьми ЦПУ, зачастую оказываются более рентабельными и производительными, чем системы с единообразным доступом к памяти. В то время как в системах с единообразным доступом к памяти память должна быть доступна всем ЦПУ в одинаковой мере, в системе NUMA можно реализовать высокоскоростное внутреннее взаимодействие для памяти, подключенной непосредственно к ЦПУ, и более дешевое взаимодействие с большой задержкой для процессоров и памяти, удаленных друг от друга.
Для эффективного масштабирования в системе NUMA операционная система или приложение должны иметь информацию о топологии узлов, чтобы вычисления выполнялись поблизости от памяти, содержащей участвующие в вычислениях данные и код. Например, планировщик Windows назначает каждому потоку так называемый идеальный процессор, представляющий собой ЦПУ, на котором планировщик всегда пытается выполнять поток. Такой подход повышает вероятность того, что данные, помещенные потоком в кэш ЦПУ, будут доступны потоку всякий раз при его выполнении.
В планировщике Windows Server 2003 эта концепция расширена. Узел, содержащий идеальный процессор, считается идеальным узлом потока, и планировщик пытается запланировать этот поток на другом ЦПУ идеального узла, если идеальный процессор занят выполнением другого потока. Диспетчер памяти в Windows Server 2003 также поддерживает концепцию NUMA и, по мере возможности, запрашивает выделение памяти для потока в памяти узла, на котором поток выполняется.
В Windows Server 2008 диспетчер памяти делит невыгружаемые буферы памяти ядра (память, используемая ядром и драйверами устройств для хранения данных, которая постоянно находится в ОЗУ) между узлами, чтобы эти участки памяти выделялись на узле, на котором инициировано выделение памяти. Системные записи таблицы страниц (PTE) выделяются на узле, инициирующем выделение, если для выделения памяти требуется новая страница таблицы страниц для удовлетворения потребности в памяти, вместо того, чтобы делать это на любом другом узле, как это происходит в среде Windows Server 2003.
В Windows Server 2003, когда поток распределяет память, диспетчер памяти отдает предпочтение узлу, на котором в момент выделения памяти выполняется поток. Если поток сразу же планируется на не идеальный узел, все распределения, выполняемые в это время, будут осуществляться на не идеальном узле. Поэтому, когда поток, в конечном счете, выполняется на своем идеальном узле, он будет не настолько близок, как это могло бы быть, к данным или коду, хранящимся в выделенной памяти.
Для разрешения этой проблемы диспетчер памяти в Windows Server 2008 отдает предпочтение идеальному узлу потока для всех выделение памяти для потока, даже если поток выполняется поблизости от другого узла. Кроме этого, диспетчер памяти автоматически определяет задержки между процессорами и узлами, поэтому, если на идеальном узле недостаточно памяти, диспетчер переходит к проверке узла, ближайшего к идеальному. Дополнительно, если поток ссылается на код или данные, диспетчер памяти перемещает страницы в свой список ожидания идеального узла потока.
Приложения, стремящиеся управлять местонахождением своих участков выделенной памяти, теперь могут использовать новые интерфейсы API памяти NUMA, что позволяет им указывать предпочтительный узел для выделения памяти, представления сопоставления файлов и объекты сопоставления файлов. Для выделения, связанного с сопоставлением файлов, диспетчер памяти проверяет, указывает ли операция сопоставления узел, затем проверяет, указан ли узел объектом сопоставления файлов, и, наконец, если ничего не остается делать, обращается к идеальному узлу потока.
До появления системы Windows Server 2008 прерывание и соответствующий отложенный вызов процедуры (DPC) для хранения или сетевых операций ввода-вывода мог выполняться на любом ЦПУ, включая процессоры с другого узла, а не того, на котором инициирован ввод-вывод. Это могло стать причиной того, что данные, считанные или записанные операцией ввода-вывод, окажутся в памяти другого узла, а не того, на котором был получен к ним доступ.
Чтобы избежать этого, система ввода-вывода операционной системы Windows Server 2008 направляет выполнение DPC на ЦПУ того узла, где был инициирован ввод-вывод, а системы, в которые входят устройства, поддерживающие формат MSI-X шины PCI (расширение стандарта MSI), могут расширить возможности размещения выполнения операций ввода-вывода с помощью драйверов устройств, которые используют преимущества интерфейсов API операционной системы Windows Server 2008 для направления прерывания ввода-вывода на процессор, инициировавший ввод-вывод.

Динамическое создание разделов
Одним из способов увеличения масштабируемости системы является поддержка ею динамического добавления ресурсов оборудования, например центральных процессоров и памяти. Эта же поддержка может увеличить также доступность системы, если такие ресурсы могут быть заменены без требования перезагрузки системы.
В Windows Server 2003 появилась возможность оперативного добавления памяти, что позволяет серверам с поддержкой динамической памяти использовать ОЗУ по мере ее добавления администратором. В Windows Server 2008 расширена поддержка динамической памяти, и допускается замена памяти.
Участки ОЗУ, в которых возрастает количество исправлений ECC (Error Correcting Code), подвержены риску полного отказа, поэтому на серверах с поддержкой оперативной замены операционная система может прозрачным образом переместить данные из сбойных банков памяти в замещающую их память. При этом сначала перемещаются данные, находящиеся под управлением операционной системы, затем устройства эффективно отключаются посредством перемещения их в состояние низкого энергопотребления, перемещаются оставшиеся в памяти данные, после чего возобновляется подача питания на устройства, чтобы они продолжили работу в обычном режиме.
Windows Server 2008 поддерживает также оперативное добавление и замещение процессоров. Для осуществления оперативного замещения оборудование должно поддерживать концепцию запасных ЦПУ, которые могут быть либо введены в рабочем режиме, либо добавлены динамически, когда существующий ЦПУ генерирует сигналы о сбое, что в настоящее время доступно только в самых современных системах. Планировщик Windows Server 2008 замедляет операции на сбойном ЦПУ и перемещает работу на замещающий процессор, после чего сбойный ЦПУ можно удалить и заменить новым запасным процессором.
В Windows Server 2008 поддержка оперативного добавления процессоров позволяет администраторам модернизировать вычислительные возможности сервера, избегая простоев системы. Однако планировщик и системы ввода-вывода обеспечат доступность нового ЦПУ только тем драйверам устройств и приложениям, которые запрашивают уведомление о появлении ЦПУ через новые интерфейсы API, поскольку некоторые приложения разработаны исходя из предоположения фиксированности числа ЦПУ в рамках сеанса загрузки. Например, приложение может выделить память для массива рабочих очередей, соответствующих каждому ЦПУ, при этом поток использует очередь, связанную с ЦПУ, на котором он выполняется. Если планировшик помещает один из потоков приложения на новый ЦПУ, этот поток будет пытаться сослаться на несуществующую очередь, что может привести к разрушению данных приложения и высокой верятности аварийного отказа приложения.
Серверные приложения Майкрософт, такие как SQL Server и Exchange Server, выдерживают добавление ЦПУ, так же, как и некоторые основные процессы Windows, включая системный процесс, процесс диспетчера сеансов (%SystemRoot%\System32\Smss.exe,) и процессы размещения универсальных служб (%Systemroot%\System32\Svchost.exe). Другие процессы также могут запрашивать посредством интерфейса Windows API уведомление о появлении нового ЦПУ. При появлении нового ЦПУ Windows уведомляет драйверы устройств о предстоящем появлении процессора, запускает ЦПУ, после чего уведомляет драйверы устройств и приложения, созданные с расчетом на использование преимуществ новых ЦПУ, чтобы они, если это небходимо, размещали структуры данных для отслеживания операций на новом ЦПУ.

Виртуализация машин
До появления Windows Server 2008 обеспечивающие виртуализацию продукты Майкрософт, включая Virtual Server 2005, реализовывались посредством виртуализации с размещением, как показано на рис. 5. В случае виртуализации с размещением виртуальные машины реализуются посредством монитора виртуальных машин (VMM), работающего наряду с основной операционной системой, как правило, в качестве драйвера устройств. VMM опирается на управление ресурсами и драйверы устройств основной операционной системы. Когда монитор выполняется в соответствии с графиком операционной системы, он распределяет интервалы времени ЦПУ между активными виртуальными машинами (VM).
Рис. 5 Виртуализация машин с размещением
Рис. 5 Виртуализация машин с размещением
Технология Hyper-V, ранее имевшая кодовое название «Viridian», реализуется с использованием виртуализации гипервизора. Гипервизор полностью управляет всеми аппаратными ресурсами, и даже операционная система Windows Server 2008, которая загружает систему и посредством которой осуществляется управление виртуальными машинами, работает, по существу, на виртуальной машине, как видно из рис. 6.
Рис. 6 Архитектура Hyper-V
Рис. 6 Архитектура Hyper-V
Гипервизор может разделить систему на несколько VM и рассматривать загрузочный экземпляр Windows Server 2008 как главный или корневой раздел, предоставляя ему непосредственный доступ к таким устройствам, как диск, сетевые адаптеры и графический процессор. Гипервизор предполагает, что корневой раздел осуществляет управление питанием и реагирует на события, связанные с автоматическими конфигурируемым оборудованием. Он перехватывает операции ввода-вывода устройств, инициированные в дочерних разделах, и направляет их в корневой раздел, который для доступа к оборудованию использует стандартные драйверы устройств Windows Server 2008. Таким образом серверы, на которых работает Hyper-V, могут воспользоваться преимуществом, обеспечиваемым поддержкой устройств операционной системой Windows.
Если Windows Server 2008 настраивается для выполнения серверной роли Hyper-V, Windows для параметра hypervisorimagelaunchtypeboot Boot Configuration Database (BCD) задает значение auto и настраивает драйвер устройств, Hvboot.sys для запуска на начальном этапе процесса загрузки. Если настроен этот режим, Hvboot.sys готовит систему для виртуализации, после чего загружает в память либо %Systemroot%\System32\Hvax64.exe, либо %Systemroot%\System32\Hvix64.exe, в зависимости от того, реализует система расширения виртуализации AMD-V или Intel VT CPU соответственно.
После загрузки гипервизор использует расширения виртуализации, чтобы внедриться ниже уровня операционной системы Windows Server 2008. Приложения пользовательского режима используют уровень привилегий Ring 3 процессора x64, а код режима ядра работает с привилегиями Ring 0, поэтому гипервизор работает на концептуальном уровне привилегий Ring минус 1, поскольку он может управлять средой выполнения кода, работающего на уровне Ring 0.
Если консоль управления Hyper-V используется для создания или запуска дочернего раздела, она взаимодействует с гипервизором посредством драйвера %Systemroot%\System32\Drivers\Winhv.sys, который использует открыто документированный интерфейс API гипервызова для создания нового раздела с указанными объемом физической памяти и характеристиками выполнения. Служба VM (%Systemroot%\System32\Vmms.exe) из корневого раздела создает рабочий процесс VM (%Systemroot%\System32\Vmwp.exe) для каждого дочернего раздела с целью управления его состоянием.
Один из способов, которым Windows повышает эффективность операционных систем дочерних VM, состоит в реализации как в Windows Server 2008, так и в Windows Vista «просветлений», представляющих собой последовательности кода, которые активируются только если операционная система работает на гипервизоре, реализующем интерфейс API Майкрософт для гипервызова. Запрашивая напрямую службы гипервызова, дочерняя VM избегает дополнительного кода виртуализации, который потребовался бы, если бы гипервизору пришлось угадывать намерения дочерней операционной системы.
Например, гостевая операционная система, в которой не реализованы «просветления» для спин-блокировок, выполняющих низкоуровневую синхронизацию нескольких процессоров, попросту вошла бы в цикл ожидания спин-блокировки, чтобы быть освобожденной другим виртуальным процессором. Такое ожидание может захватить один из физических ЦПУ до тех пор, пока гипервизор не предусмотрит второй виртуальный процессор. В «просветленных» операционных системах код спин-блокировки, если в противном случае он вошел бы в цикл, уведомляет гипервизор посредством гипервызова чтобы гипервизор мог незамедлительно предусмотреть другой виртуальный процессор и сократить непроизводительное использование ЦПУ.
Другой способ, которым Windows Server 2008 повышает производительность VM, заключается в ускорении доступа VM к устройствам. Производительность повышается за счет установки в дочерней операционной системе набора компонентов под общим названием «Компоненты интеграции VM».
Если VM работает без установки компонентов интеграции, дочерняя операционная система настраивает драйверы для тех эмулируемых устройств, которые ей представляет гипервизор. Гипервизор должен вступить в игру, когда драйвер устройства пытается вступить во взаимодействие с аппаратным ресурсом, чтобы предоставить информацию корневому разделу, который выполняет операции ввода-вывода с помощью стандартных драйверов устройств Windows от имени операционной системы дочерней VM. Поскольку одна высокоуровневая операция ввода-вывода, например чтение с диска, может повлечь много отдельных обращений к оборудованию, это может вызвать много операций передачи, называемых перехватами, в гипервизор и корневой раздел.
В Windows Server 2008 перехваты минимизируются с помощью трех компонентов: драйвера шины виртуальной машины (%Systemroot%\System32\Drivers\Vmbus.sys), клиентов виртуальных служб (VSC) и поставщиков виртуальных служб (VSP). Если на VM с поддерживаемой операционной системой устанавливаются компоненты интеграции, VSC берут на себя роль драйверов устройств и используют службы драйвера Vmbus.sys в дочерней VM для отправки запросов на операции ввода-вывода высокого уровня драйверу шины виртуальной машины в корневом разделе, используя для этого гипервызов и службы гипервизора, совместно использующие память. В корневом разделе Vmbus.sys перенаправляет запрос соответствующему VSP, который затем инициирует запросы стандартных операций ввода-вывода Windows I/O посредством драйверов устройств корневого раздела.
Очевидно, что Windows Server 2008, в которой появилась виртуализация Hyper-V на основе гипервизора, играет решающую роль в стратегии Майкрософт по виртуализации машин. Для получения дополнительных сведений об этих и других компонентах см. следующее издание моей книги «Microsoft Windows Internals» (Внутренняя структура Microsoft Windows), публикация которого запланирована на этот год.

Марк Руссинович (Mark Russinovich) является членом технического совета подразделения платформ и служб корпорации Майкрософт. Он является одним из авторов книги Microsoft Windows Internals (Внутренняя структура ОС Microsoft Windows), вышедшей в издательстве Microsoft Press в 2004 г., и часто выступает на конференциях для специалистов по информационным технологиям и разработчиков, в частности на конференции Microsoft TechEd и конференции специалистов-разработчиков. Марк стал сотрудником Майкрософт в результате приобретения корпорацией компании Winternals Software, одним из основателей которой он являлся. Он создал также веб-ресурс Sysinternals, на котором опубликовал многие популярные служебные программы, такие как Process Explorer, Filemon и Regmon.
© 2007 Корпорация Майкрософт и компания CMP Media, LLC. Все права защищены; полное или частичное воспроизведение без разрешения запрещено.


 Специальная статья: Windows Server 2008: Новые возможности служб доменов Active Directory
Специальная статья: Windows Server 2008 Джил Киркпатрик (Gil Kirkpatrick)

Новые возможности служб доменов Active Directory
Краткий обзор:
  • Новый диспетчер серверов и службы ADDS.
  • Работа служб домена в варианте установки Server Core (ядро сервера).
  • Контроллеры доменов только для чтения.
  • Смена паролей, резервное копирование, аудит.

Вместе с Windows 2000 Майкрософт дала миру Active Directory. В следующей версии системы, Windows Server 2003, в Active Directory были снесены изменения, однако
особых потрясений они не произвели. На сегодняшний день Active Directory® превратилась в полноценную, надежную службу каталогов. И несмотря на это в последней версии системы специалисты по разработке Active Directory добавили еще несколько существенных функций, способных укрепить безопасность и упростить управление службой каталогов.
На пороге второго тысячелетия служба Active Directory отвечала за проверку подлинности пользователя, входящего в операционную систему, применение политик к компьютерам и пользователям и всячески помогала пользователю (находила нужный принтер, к примеру). Уже пару лет спустя Майкрософт выпустила отдельный вариант службы каталогов — Active Directory Application Mode (ADAM).
К 2006 году все полностью изменилось. Служба Active Directory перестала быть какой-то конктерной технологией. Теперь под этим названием объединяется несколько служб управления удостоверениями и доступом, встроенных в Windows®. На рис. 1 приведена небольшая схема составляющих марки Active Directory.
Figure 1 Компоненты службы каталогов Active Directory (Close Figure 1)

Текущая технология Active Directory | Старое название | Описание
Службы доменов Active Directory (ADDS) | Active Directory | Раньше этот компонент назывался службой каталогов Active Directory. Он обеспечивает проверку подлинности пользователей и компьютеров домена при помощи механизмов Kerberos и NTLM, управляет подразделениями, пользователями, группами, групповыми политиками и т. д.
Службы Active Directory облегченного доступа к каталогам (AD LDS) | ADAM | Высокомощный сервер LDAP на базе того же исходного кода, что и службы ADDS.
Службы сертификации Active Directory (AD CS) | Служба сертификатов | Надежная проверка подлинности на основе сертификатов X.509.
Службы управления правами Active Directory (AD RMS) | Сервер управления правами | Защита цифровых активов (документов, электронной почты) от несанкционированного доступа пользователей путем создания файлов и контейнеров, защищенных определенными правами.
Службы федерации Active Directory (AD FS) | Службы федерации Active Directory | Единый вход и федерация идентификации для WS-совместимых веб-служб.
То есть, правильно говорить, что эта статья посвящена службам домена, но на самом деле это все та же старая добрая служба Active Directory, которая известна нам с 2000 года.

Диспетчер серверов в Windows Server 2008
Первые два улучшения в Active Directory, которые я собираюсь обсудить, в действительности не являются изменениями в доменных службах Active Directory Domain Services (ADDS); это, скорее, изменения в Windows, которые повлияют на способ управления Active Directory. Первое, новый диспетчер серверов, появляется при первой загрузке сервера Windows Server® 2008. (Второе –– установка Server Core, о которой я расскажу чуть позже.)
Диспетчер сервера, возможно, покажется вам похожим на мастер настройки сервера, который появлялся по умолчанию сразу после установки Windows Server 2003. Впрочем, он был не слишком полезен для повседневного администрирования: у всех, кого я знаю, флажок «Не показывать эту страницу при входе в систему» был установлен.
А вот диспетчер сервера в Windows Server 2008, напротив, весьма полезен (краткий обзор функций диспетчера есть в статье Байрона Ханза (Byron Hynes) в этом выпуске журнала TechNet Magazine). Вопервых, как видно из рис. 2, диспетчер сервера из HTML-приложения (HTA) превратился в консоль управления (MMC). В результате он обрел знакомый полнофункциональный, настраиваемый пользовательский интерфейс. Диспетчер сервера позволяет управлять установкой серверных ролей (крупных служб вроде DNS, ADDS, IIS) и функций (компонентов программного обеспечения, например платформы Microsoft .NET Framework, функции шифрования дисков BitLockerTM, оболочки Windows PowerShellTM). Диспетчер не только позволяет устанавливать и удалять программы — он представляет собой единый пульт управления, позволяющий запускать средства диагностики (срество просмотра событий, PerfMon) и служебные программы для настройки системы (диспетчер устройств, брандмауэр Windows). Если добавить в консоль управления оснастки Active Directory, например «Пользователи и компьютеры», «Домены и доверие», «Сайты и службы», получится неплохой интерфейс, позволяющий выполнять повседневные операции, связанные с обслуживанием контроллера домена Windows Server 2008.
Рис. 2 Диспетчер серверов в Windows Server 2008
Рис. 2 Диспетчер серверов в Windows Server 2008

Windows Server 2008 Server Core
Windows Server Core — это новый режим установки Windows, дающий в результате урезанную версию системы, в которой содержатся только те компоненты, которые необходимы для установки и исполнения определенных серверных ролей, в частности для работы служб доменов Active Directory. (На рис. 3 перечислены роли, включенные в вариант установки Server Core.) Хотя в режиме Server Core имеется графический интерфейс, оболочка рабочего стола Windows в нем отсутствует, равно как и многие графические средства настройки Windows (см. рис. 4). Вместо них вам обеспечена командная строка и отвратительное чувство где-то в глубинах желудка, подтверждающее тот факт, что вы понятия не имеете, что же делать дальше. Как изменить имя компьютера? Как настроить статический IP-адрес?
Рис. 4 Интерфейс в режиме Server Core разнообразием не блещет
Рис. 4 Интерфейс в режиме Server Core разнообразием не блещет
Первые несколько минут перед экраном в режиме Server Core кого угодно могут выбить из колеи, но как только вы вспомните WMIC, NETSH и NETDOM, вы сможете без труда выполнить все стандартные операции по установке и настройке. А тягу к графическим средствам отчасти облегчают Regedit и Блокнот.
Главным преимуществом режима Server Core является то, что вы избавляетесь от большей части кода, включенного в стандартный вариант установки Windows, который иногда вовсе и не нужен. Тем самым сужается потенциальный фронт атак вредоносного программного обеспечения (что уже хорошо) и снижается количество исправлений и перезагрузок контроллеров доменов (что просто великолепно). Кроме того, уменьшается размер места, занимаемого системой на диске, и снижаются требования к оборудованию — обычно это не очень важно, но в виртуализованных серверных средах может пригодиться.
Усложняется ли управление службами ADDS в отсутствие графических средств? Отнюдь. Практически все операции по управлению можно выполнять удаленно: вы подключаетесь к контроллеру домена через сеть, а служебные программы запускаете на своей рабочей станции. Смею предположить, что через некоторое время подавляющее большинство контроллеров доменов будет работать в режиме Server Core.

Изменения в DCPROMO
Первое изменение, которое вы обнаружите в самих службах ADDS, — это новый мастер DCPROMO. Работает он точно так же, как мастер DCPROMO в Windows Server 2003, но он был полностью переписан, и теперь им удобнее пользоваться. Например, не нужно вводить учетные данные администратора домена — DCPROMO способен при повышении роли сервера использовать данные, которые были введены при входе в систему. Не приходится прибегать к команде DCPROMO /ADV, если нужен расширенный режим DCPROMO: в первом диалоговом окне DCPROMO есть флажок, активирующий соответсвующие функции. В расширенном режиме можно также выбрать контроллер домена, с которого будет выполняться репликация. Это означает, что всю работу по репликации, выполняемую DCPROMO, можно провести без дополнительной загрузки производственных контроллеров доменов.
При переводе контроллера в другой домен или в другой лес DCPROMO предлагает настроить сразу настроить функциональный уровень соответствующего домена или леса, чтобы не делать это после. В ходе перевода можно указать, в какой сайт Active Directory нужно поместить контроллер домена, что очень удобно при работе DCPROMO без участия пользователя. DCPROMO даже предложит наиболее подходящий сайт исходя их IP-адреса контроллера домена.
В новом DCPROMO все параметры собраны на одной странице, и вы сразу можете определить, какую роль будет играть новый контролер домена: глобального каталога, DNS-сервера или контроллера домена только для чтения. И чтобы сделать контроллер глобальным каталогом, не нужно продираться сквозь дебри сайтов и служб Active Directory.
Но, пожалую, лучшей особенностью нового DCPROMO является возможность сохранить все параметры DCPROMO в файле ответа непосредственно перед запуском процесса перевода. Это гораздо проще — и намного надежнее — чем стряпать файл ответа вручную. Файл ответа можно использовать при выполнении процедуры DCPROMO без участия пользователя на других серверах. И еще радостная весть для фанатов сценариев: все параметры DCPROMO теперь доступны при работе в командной строке.

Контроллеры доменов только для чтения
На заре существования Active Directory в компаниях контроллеры домена развертывались в каждом подразделении, сотрудники которого должны были входить в систему. Ярким примеров являются банки: у них контроллеры доменов были в каждом филиале. Обоснование выглядело так: даже если произойдет сбой WAN, сотрудники филиала смогут войти в систему и использовать ресурсы локальной сети.
В те времена физической безопасности контроллеров особого значения не придавали. Мне доводилось видеть контроллеры доменов, просто задвинутые под рабочий стол — и любой проходящий мимо мог без труда ими воспользоваться. Лишь спустя несколько лет специалисты по архитектуре Active Directory осознали всю степень риска и ИТ-организации взялись за объединение контроллеров доменов в центрах обработки данных. Сотрудники филиалов при таком раскладе вынуждены проходить проверку подлинности, но это разумная цена повышения безопасности данных.
Active Directory в Windows Server 2008 внесла разнообразие в развертывание систем филиалов: появились контроллеры доменов только для чтения (RODC). Это самое главное изменение, внесенное в службах доменов Windows Server 2008.
При создании RODC группа разработки Active Directory все внимание сосредоточила на требованиях, предъявляемых к системам филиалов; их девизом стало: «Что в филиале произойдет, то в филиале и останется». Дело в том, что если нет возможности обеспечить физическую безопасность контроллеров, установленных в филиале, то вы, в общем-то, никак не сможете предотвратить взлом контроллера (и компьютеров, на которых установлено доверие данному контроллеру), однако вы в силах сделать так, чтобы этот взлом не сказался на остальной части домена.
Контролеры RODC, хотя и являются главным нововведением, связанным со службами ADDS, довольно просты в использовании. Домен должен находится на функциональном уровне леса Windows Server 2003, и в домене должен быть хотя бы один контроллер под управлением Windows Server 2008. Контроллеры RODC можно использовать не только в филиалах; их также имеет смысл устанавливать в средах, имеющих выход в Интернет, и на периферии сети.

Если контроллер сделал ноги
Есть несколько категорий угроз, с которыми приходится считаться при развертывании систем филиалов. Первая ситуация — контроллер домена украден. Кто-то просто унес контроллер или его диск. Кроме того что локальные службы не могут работать, существует вероятность того, что злодей в конце концов получит доступ ко всем именам и паролям пользователей в домене, сможет повысить уровень собственных привилегий и воспользоваться ресурсами компании или вызвать отказ в обслуживании. В целях борьбы с такого типа угрозами в RODC по умолчанию хэшированные пароли не хранятся в дереве DIT. Когда пользователсь в первый раз проходит проверку подлинности на данном контроллере RODC, контроллер передает запрос полному контроллеру домена (FDC). FDC обрабатывает запорс и, если все проходит удачно, контроллер RODC отправляет запрос репликации для получения хэшированного пароля.
Если контроллер RODC взломан, он теоретически может запросить хэшированный пароль к учетной записи, дающей доступ к конфиденциальной информации. Чтобы предотвратить такую ситуацию, администратор может настроить политику репликации паролей для каждого контроллера RODC. Политика репликации представляет собой два атрибута объекта-компьютера контроллера RODC. Атрибут msDS-RevealOnDemandGroup содержит различающиеся имена групп, пользователей, компьютеров, пароли к учетным записям которых можно хэшировать на контроллере RODC (обычно это пользователи и компьютеры, входящие в тот же сайт, что и сам контроллер RODC). Атрибут msDS-NeverRevealGroup содержит различающиеся имена групп, пользователей, компьютеров, пароли которых хэшировать на контроллере RODC нельзя (например, пароль администратора ни в коем случае не следует хэшировать на контроллере RODC). Когда RODC запрашивает хэшированный пароль к той или иной учетной записи, FDC оценивает запрос согласно политике репликации паролей и определяет, можно создать реплику пароля на RODC или нельзя. В случае кражи контроллера домена это позволяет снизить уязвимость тех паролей, которые были хэшированы на RODC в момент его отключения от сети, и устранить риск взлома важных паролей.
Объект-компьютер контроллера RODC имеет еще два атрибута, позволяющие определить, какие именно пароли нужно хэшировать. Атрибут msDS-AuthenticatedAtDC содержит список учетных записей, прошедших проверку подлинности на контроллере RODC, а атрибут msDS-RevealedList — список учетных записией, пароли которых в данный момент хранятся на контроллере RODC.
Хэшированные пароли пользователей и компьютеров — не единственный секрет контроллера домена. Учетная запись KrbTGT содержит ключи Центра распространения ключей Kerberos — службы, работающей на каждом контроллере домена. Обычно все службы KDC в домене используют одну и ту же учетную запись KrbTGT, поэтому есть опасность, что злоумышленник сможет извлечь ключи из украденного контроллера и взломать оставшуюся часть домена. Контроллеры RODC используют собственные учетные записи KrbTGT и собственные ключи, поэтому такая возможность отпадает.
Кроме всего прочего, приложения нередко хранят пароли и другую секретную информацию в DIT. Если злоумышленник украдет контроллер домена, он может воспользоваться сохраненными паролями и получить доступ к приложениям. Чтобы снизить риск такого развития событий, службы доменов в Windows Server 2008 позволяют администраторам определить набор атрибутов контроллеров доменов только для чтения (RO-FAS). Атрибуты, входящие в набор RO-FAS, не реплицируются на контроллеры RODC, и поэтому не могут быть обнаружены на украденном контроллере домена. Атрибуты RO-FAS назначаются путем настройки 9 бита (0x0200) в атрибуте searchFlags, в соответствующем объекте attributeSchema.

Варвары в городе
Еще одна категория опасностей, с которыми сталкиваются контроллеры доменов в филиалах, выглядит следующим образом: администратор локального сервера несанкционированно расширяет собственные права, пользуясь привилегиями контроллера домена, и получает доступ к дополнительным ресурсам домена или пытается провести атаку типа «отказ в обслуживании». Опять же, если локальный администратор физически имеет доступ к контроллеру, вы вряд ли сможете ему помешать, однако вы можете не позволить ему взломать остальные контроллеры домена.
На полном контроллере домена контроллеры RODC не указываются как доверенные. С точки зрения доверительных отношений, контроллер FDC относится к контроллерам RODC так же, как к прочим серверам, входящим в домен. Контроллеры RODC не входят ни в группу «Контроллеры домена предприятия», ни в группу «Контроллеры домена». При помощи учетной записи RODC вообще мало что можно обновить в каталогах, поэтому даже если злоумышленник взломает учетную запись RODC, он практически никаких полезных для себя привилегий не получит.
Контроллеры RODC даже не включаются в обычную топологию репликации DS. Поскольку RODC внешне ничем не отличается от остальных серверов домена, средство проверки согласованности знаний (или KCC — этот процесс имеется на каждом контроллере домена, отвечающем за расчет топологии репликации DS) не создает для контроллеров RODC объектов соединений. Ни полный контроллер домена, ни контроллер RODC не станет проводить репликацию на основе контроллера домента тольео для чтения. С другой стороны, контроллер RODC создает объект соединения, представляющий собой соглашение о входящей репликации с полного контроллера домена, но этот объект хранится только в реплике самого контроллера RODC — на другие контролеры домена он не копируется. С точки зрения репликакции, контроллер RODC сродни ловушкам для тараканов: всех впускать, никого не выпускать.

Делегирование прав администратора на контроллере RODC
В офисах филиалов контроллером домена нередко управляет местный администратор серверов: он сам все делает, и резервные копии контроллера создает, и клавиатуры тряпочкой протирает. Однако было бы опасным предоставлять администратору удаленного офиса права, необходимые для всех операций по обслуживанию контроллера домена, поскольку администратор теоретически может расширить собственные привилегии в домене. Контроллеры RODC позволяют бороться и с этой угрозой: они предлагают два способа делегированя прав администратора.
В первом варианте администратор домена может либо перевести контроллер RODC обычным способом (при помощи DCPROMO), либо воспользоваться двухчастной процедуров и безопасно делегировать права, необходимые для перевод контроллера, администратору офиса филиала, не предоставляя ему прав администратора домена. Администратор домена создает заготовку учетной записи RODC в домене при помощи оснастки «Пользователи и компьютеры Active Directory», как показано на рис. 5.
Рис. 5 Создание заготовки учетной записи компьютера RODC
Рис. 5 Создание заготовки учетной записи компьютера RODC
При выборе варианта «Создать заранее учетную запись контроллера домена только для чтения» запускается урезанная версия мастера DCPROMO, которые выполняет все действия, требующие наличия прав администратора домена: создает учетную запись компьютера, привязывает RODC к сайту, назанчает роли контроллеров домена, задает политику репликации паролей и определяет пользователя или группу, которым понадобятся права, необходимые для завершения работы мастера DCPROMO на контроллере RODC. Выбранный администратор или группа изписываются в атрибут managedBy объекта компьютера RODC.
Затем администратор, получивший права, может запустить мастер DCPROMO непосредственно на сервере. DCPROMO обнаружит заготовку учетной записи и преобразует сервер в контроллер домена только для чтения. При таком запуске мастера DCPROMO права администратора домена не требуются.
Во втором варианте делегирования прав администратора роли администратора создаются на самом контроллере RODC. Внешне эти роли ничем не отличаются от локальных групп: они хранятся в реестре контроллера RODC и оцениваться могут только данным контроллером. Для управления локальными ролями RODC администратор использует не оснастку «Управление компьютером», а программу NTDSUTIL. На рис. 6 приведен список локальных ролей администратора, используемых на контроллерах RODC. Роли эти один в один совпадают со встроенными группами Windows.
Figure 6 Локальные административные роли на контроллере домена только для чтения (Close Figure 6)

Операторы учета
Администраторы
Операторы архива
Доступ к службе сертификатор DCOM
Операторы шифрования
Пользователи DCOM
Читатели журнала событий
Гости
IIS_IUSRS
Создатели входящего доверия леса
Операторы настройки сети
Пользователи журнала производительности
Пользователи системного монитора
Пред-Windows 2000 доступ
Операторы печати
Пользователи удаленного рабочего стола
Репликаторы
Операторы сервера
Серверы лицензий сервера терминалов
Пользователи
Группа авторизации доступа Windows

Странности RODC
Из-за того что контролеры RODC предназначены только для чтения и на другие контроллеры данные с них не реплицируются, контроллеры RODC иногда ведут себя странно. Взять, к примеру, устаревшие объекты — объекты, которые были удалены везде кроме данного контроллера домена, поскольку ему не удавалось выполнить репликацию в течение переода времени, превышающего время жизни захоронения в лесу — обычно такие объекты удаляются в момент исходящей репликации на партнеров данного контроллера домена. Но поскольку контроллеры RODC на такую репликацию не способны, устаревшие объекты в них не обнаруживаются.
Контроллеры RODC не проводят операции по обновлению LDAP (добавление, изменение, удаление, переименование, перемещение). Вместо этого контроллер RODC возвращает обычному контроллеру домена (способному выполнять такие операции) сообщение об ошибке с указанием ссылки на LDAP. Если приложение, запросившее обновление LDAP, некорректно работает со сслыками, оно может дать сбой.
Наконец, чтобы выполнить проверку подлинности пользователя другого домена, входящего в тот же лес, контроллер RODC должен иметь доступ к полному контроллеру собственного домена для получения пароля доверия и передачи запроса на проверку подлинности контроллеру того домена, к которому относится пользователь. Если сетевое подключение между контроллером RODC и полным контроллером домена, в который он входит, недоступно, провести проверку подлинности не удастся.

Подробные политики паролей
Возможность настроить сразу несколько политик паролей в одном домене была, пожалуй, самым востребованным нововведением Windows Server 2008 ADDS. Как известно служба Active Directory в Windows 2000 и Windows Server 2003 допускала не более одной политики паролей на каждый домен, применявшейся ко всем участникам ситемы безопасности. Если для какой-то группы пользователей нужно было настроить отдельную политику, приходилось создавать отдельный домен. В Windows Server 2008 ADDS появилась новая функция — «Подробные политики паролей» — позволяющая настроить несколько политик в одном домене.
В новой стратегии для применения разных политик используются группы. Вы сначала определяете политику паролей — создаете новый объект msDS-PasswordSettings в контейнере CN=Password Settings Container, CN=System, DC=<домен>. Объект msDS-PasswordSettings (сокращенно PSO) имеет атрибуты, отождествляющие политику паролей с определенными настройками групповой политики (см. рис. 7).
Figure 7 Атрибуты объекта mSDS-PasswordSettings (Close Figure 7)

Атрибут | Описание
mSDS-PasswordReversibleEncryptionEnabled | Индикатор со значениями логического типа; показывает, обратимо ли шифрование паролей.
mSDS-PasswordHistoryLength | Допустимое количество записей в историипаролей.
mSDS-PasswordComplexityEnabled | Индикатор со значениями логического типа; показывает, включено ли ограничение сложности пароля.
mSDS-MinimumPasswordLength | Целое число; указывает минимальную длину пароля.
mSDS-MinimumPasswordAge | Число типа INTEGER8; указывает минимальный срок существования пароля, по истечении которого пароль можно изменять.
mSDS-MaximumPasswordAge | Число типа INTEGER8; указывает максимальный срок существования пароля, по истечении которого пароль обязательно нужно изменить.
mSDS-LockoutThreshold | Целое число; показывает количество неудачных попвыток входа в систему, после которого система будет заблокирована.
mSDS-LockoutObservationWindow | Число типа INTEGER8; показывает длину периода (в наносекундах), в течение которого не могут быть выполнены две неудачные попытки входа (иначе система будет заблокирована).
mSDS-LockoutDuration | Число типа INTEGER8, показывающее продолжительность блокировки учетной записи (в наносекундах).
Затем вы включаете созданную политику для пользователей и групп путем добавления имени пользователя или группы в атрибут mDS-PSOAppliesTo объекта PSO (атрибут может иметь несколько значений одновременно). Если смириться с мыслью, что политики паролей применяются не к подразделениям, все довольно просто. Правда, некоторые трудности все же встречаются.
Пользователи обычно входят сразу в несколько групп. Что произойдет, если к двум группам, в которые входит пользователь, применить разные политики паролей, противоречащие друг другу? В таком случае службы ADDS для выбора политики применяют анализ очередности. Происходит это следующим образом:
  1. Если политика паролей привязана к объекту пользователя напрямую (а не посредством членства в группе), применяется эта политика.
  2. Если к объекту пользователя напрямую привязано несколько политик, используется политика с наименьшим значением очередности (оно определяется значением атрибута msDS-PasswordSettingsPrecendence в объекте PSO).
  3. Если существует несколько объектов PSO с одним и тем же значением очередности, используется объект, имеющий самый маленький идентификатор objectGUID.
  4. Если нет объектов PSO, привязанных к пользователю напрямую, службы ADDS анализируют объекты PSO, привязанные к группам, в которых состоит пользователь. Если существует несколько объектов PSO, используется объект с наименьшим значением атрибута msDS-PasswordSettingsPrecedence.
  5. Если существует несколько объектов PSO с одним и тем же значением очередности, используется объект, имеющий самый маленький идентификатор objectGUID.
  6. Если к пользователю не привязано ни одного объекта PSO, применяется политика паролей, настроенная для домена.
У объектов пользователей появился новый атрибут msDS-ResultantPSO, помогающий точно определить, какой объект PSO должен применяться к пользователю. Этот атрибут содержит различающееся имя объекта PSO, определяющего политику паролей для данного пользователя.
Подробные политики паролей дают запас гибкости на все случаи жизни, однако обращаться с этими политиками следует осторожно и лучше слишком их не усложнять. Специальной служебной программы для управления подробными политиками паролей нет — для этого используется либо программа ADSIEdit, либо программы сторонних разработчиков.

Возможность перезапуска службы Active Directory
При каждом отключении контроллера домена на время обслуживания DIT вы так или иначе нарушаете уровни обслуживания сети. В Windows Server 2008 появилась новая функция, позволяющая остановить службу каталогов, не отключая контроллер домена полностью.
Команда NET STOP NTDS останавливает работу служб ADDS на контроллере домена под управлением Windows Server 2008. При этом процесс LSASS на контроллере не останавливается — он выгружает все библиотеки DLL, связанные с работой служб ADDS, и служба каталогов становится недоступна. После этого LSASS на контроллере домена дествует так, как дествовал бы, быдь он установлен на обычном сервере: пересылает запросы на проверку подлинности в домене на другой контроллер домена. Поскольку библиотеки DLL, участивующие в работе служб ADDS, выгружены, вы можете установить исправления для служб домена или дефрагментировать DIT в автономном режиме. Чтобы запустить службы ADDS, нужно использовать команду NET START NTDS. А вот для восстановления DIT из резервной копии состояния системы все же придется загрузить службу каталогов в режиме восстановления.
Важно понимать, что служба каталогово по сути своей не является службой Windows. Это неотделимый компонент процесса LSASS, а его невозможно остановить, не выключая компьютер. И все же возможность остановливать и запускать служюбу каталогов в Windows Server 2008 весьма удобна.

Резервное копирование и восстановление
В Windows Server 2008 механизм резервного копирования и восстановления был полностью пересмотрен. Все изменения мы здесь перечислять не будем — коснемся тех, которые имеют отношение к службам ADDS.
«Система архивации данных Windows Server» позволять создать резервную копию всего тома сразу. Кроме того, она обслуживает только диски (и устройства, идентичные им) — ленточные носители не поддерживаются.
Для команды WBADMIN, используемой в версии средства архивации с интерфейсом командной строки, существует параметр, который позволяет создать резервную копию состояния системы. При помощи команды WBADMIN START SYSTEMSTATEBACKUP создается образ резервной копии, содержащий все важные системыные файлы, необходимые для восстановления службы Active Directory на контроллере домена. Теоретически набор резервных копий может содержать до пяти томов, однако включить в них можно те файлы, которые будут нужны для восстановления состояния системы. Еще больше огорчает тот факт, что в Windows Server 2008 (по крайней мере в сборке RC0) резервную копию состояния системы нельзя сохранить на сетевом ресурсе. Должен обязательно быть том токального диска, на котором будут храниться образы резервных копий, причем этот том не должен входить в набор томов, участвующих в резервном копировании состояния системы. Иногда приходится добавлять по одному тому на каждый контроллер домена, на которых выполняется резервное копирование состояния системы.
В самом процессе восстановления состояния системы ничего сложного нет. Контроллер домена загружается в режиме восстановления службы каталогов, и задается команда WBADMIN START SYSTEMSTATERECOVERY. В результате имеем неполномочно восстановленное дерево каталогов, в котором нужно полномочно восстановить конкретные объекты при помощи программы NTDSUTIL, точно так же как в Windows Server 2003.
Одну особенность системы архивации данных Windows Server стоит отметить особо: образы резервных копий сохраняются в формате VHD (виртуальный жесткий диск). Этот же формат используется в Microsoft Virtual Server 2005 для хранения образов виртуальных дисков. Из этого следует, что образ резервной копии, созданный системой архивации, можно монтировать в качестве жесткого диска на виртуальную машину под управлением Microsoft Virtual Server. Содержимое резервной копии можно будет просмотреть, как будто это обычный жесткий диск.
Еще одно изменение, коснувшееся резервного копирования служб ADDS, — это возможность при помощи службы теневого копирования томов созждавать снимки службы каталогов Active Directory на конкретный момент времени. Снимок создается при помощи программы NTDSUTIL; служба теневого копирования томов сохраняет предварительный образ каждого блока дерева каталогов, прежде чем заменить его в процессе обновления. Если объединить предварительный образ и текущую версию дерева каталогов при помощи службы теневого копирования, можно без особых усилий получить полный моментальный снимок дерева каталогов. Обычно на создание снимка уходит пара секунд — независимо от размера дерева каталогов.
Возможность эта сама по себе любопытна, но не очень полезна. Однако в Windows Server 2008 службы ADDS включают в себя программу командной строки под названием DSAMAIN. Она позволяет монтировать образ мгновенного снимка в режиме «только для чтения». При этом создается самостоятельный сервер LDAP наподобие экземпляра ADLDS, в котором хранится все содержимое каталога на момент создания мгновенного снимка. Содержимое каталога можно просматривать при помощи служебной программы LDP или иного средства LDAP; кроме того, вы можете получить предыдущую версию объектов каталога.

Репликация SYSVOL с использованием механизма DFS-R
Распределенная файловая система (DFS) в Windows Server 2003 R2 была полностью пересмотрена; в ней появился совершенно новый механизм репликации файлов DFS-R. Этот механизм использует удаленное разностное сжатие, что значительно сокращает трафик репликации файлов: указываются блоки целевых файлов, требующие репликации для синхронизации с исходными файлами. А вот в Windows Server 2003 R2 для репликации SYSVOL между контроллерами домена по-прежнему используется служба репликации файлов (а не DFS-R). По этой причине репликация SYSVOL, как и прежде, вызывает немало проблем у администраторов Active Directory.
Если система Windows Server 2008 работает на функциональном уровне домена, она позволяет выполнить репликакцию SYSVOL с использованием механизма DFS-R, что повышает скорость и надежность репликации SYSVOL. Кроме того, имеет смысл разместить объемные файлы в SYSVOL, чтобы сделать их доступными для всех контроллеров доменов. Прежде чем применять механизм DFS-R к SYSVOL, необходимо перенести данные из старого SYSVOL при помощи служебной программы DFSRMIG. Процесс этот проходит в четыре этапа:
  • Создание объектов Active Directory, необходимых для DFS-R.
  • Создание новой структуры файлов каталога SYSVOL на каждом контроллере домена.
  • Переключение всех контроллеров домена на новый SYSVOL.
  • Удаление старого каталога SYSVOL.
В некоторых случаях (в зависимости от размера каталога SYSVOL и количества контроллеров доменов) этот процесс может занять определенное время, но в конечном итоге повышение производительности и надежности стоит этого.

Изменения в функциях аудита
Система аудита в Active Directory для Windows Server 2003 — и счастье, и несчастье. С одной стороны, это достаточно полное, гибкое и надежное средство отслеживания изменений в каталоге. С другой, у него есть несколько существенных недостатков в сфере удобства использования.
Включение аудита изменений каталогов на контроллере домена Windows Server 2003 — штука довольно прямолинейная: аудит дибо включен, любо нет. При определенной активности использования контроллера домена в организации объем трафика аудита может сделать его малоэффективным. Настроить систему аудита так, чтобы она выдавала действительно полезные сообщения, сложно и рискованно. Сами сообщения аудита временами непросто расшифровать, и в большинстве случаев они не содержат нужной информации (то есть старых и новых значений измененных атрибутов). Кроме всего прочего, собрать, связать и заархивировать сообщения, полученные с нескольких контроллеров доменов, при помощи собственных средств Windows не представляется возможным.
В Windows Server 2008 часть этих проблем была решена. Во-первых, появиличь четыре новые подкатегории аудита службы каталогов: «Доступ к службе каталогов», «Изменения службы каталогов», «Репликация службы каталогов» и «Подробная репликация службы каталогов». Если нужно проверить только изменения каталогов, не нужно просматривать все события стения и репликации. Если случаи удаления объектов тоже нужно включить в журнал аудита, придется включить еще и категорию «Доступ к службе каталогов». При этом создается большое количество сообщений, связанных с доступом объектов службы каталогов, то есть мы, по сути, возвращаемся к прежним огромным объемам ненужных сообщений. Также вы по-прежнему можете настраивать дескрипторы системы безопасности, чтобы получать сообщения только о тех объектах, которые вас интересуют.
Сообщения аудита были в значительной степени подправлены: они стали более удобочитаемыми, и в них появилась полезная информация. В частности, при использовании категории «Изменения службы каталогов» в журнал аудита заносятся сообщения, содержащие старое и новое значение измененных атрибутов. Это действительно огромное достижение. Единственное, что огорчает: старое и новое значение указываются в разных записях, и их приходится сопоставлять, чтобы выявить изменение. Многие дополнительные средства для работы с журналом аудита, в том числе и службы ACS, умеют сопоставлять такие записи.

Изменения пользовательского интерфейса
Оснастки консоли управления «Пользователи и компьютеры», «Узлы и службы», «Домены и доверие» с самого момента появления были достаточно удобными для управления службой каталогов Active Directory. В Windows Server 2008 были подправлены основные средства администрирования, в них появились новые функции. Если включить «Дополнительные возможности», в диалоговм окне свойств для каждого объекта отображается еще одна вкладка — «Редактор атрибутов». Эту же самую вкладку использует программа ADSIEdit, позволяющая проверять и изменять любые атрибуты объектов. На вкладке улучшена функция декодирования кодированных атрибутов, таких как атрибут userAccountControl. На рис. 8 показано, насколько тесно интегрирован редактор атрибутов.
Рис. 8 Редактор атрибутов в оснастке «Пользователи и компьютеры Active Directory»
Рис. 8 Редактор атрибутов в оснастке «Пользователи и компьютеры Active Directory»

Заключение
Кроме самых основных изменений, которых мы коснулись в данной статье, службы ADDS в Windows Server 2008 содержат много других улучшений. Например, в центре KDC используется стандарт шифрования AES-256, если домен расположен на функциональном уровне домена Windows Server 2008. Для любого объекта служб домена можно включить защиту от случайного удаления, установив соответствующий флажок на вкладке «Объект». Был улучшен расширенный обработчик хранилищ, предоставляющий службу управления: в нем используется механиз исправления одноразрядных ошибок памяти, благодаря чему сокращается вероятность сбоя обороудования и программного обеспечения подсистемы диска по причине нарушения дерева каталогов. Служба DNS начинает обработку запросов еще до того, как база данных DNS загрузится полностью. Модуль локатора был усовершенствован: если он не находит контроллер домена в выбранном узле, он пытается найти контроллер в ближайшем узле, а не просто любой контролер, имеющийся в домене. Программа NTDSUTIL поддерживает мгновенные снимки контроллеров RODC и службы теневого копирования томов.
Очевидно, что в Windows Server 2008 появился ряд существенных изменений служб доменов Active Directory. В сумме они серьезно повышают безопасность и управляемость служб ADDS. Но самой лучшей, на мой взгляд, особенностью Windows Server 2008 является то, что при его интеграции в среду Active Directory не приходится устраивать массовые миграции: процесс проходит просто и незаметно.

Джил Киркпатрик (Gil Kirkpatrick) — руководитель технологического отдела компании NetPro и разработчик программного обеспечения для Active Directory с 1996 г. Вместе с Гвидо Грилленмайером (Guido Grillenmeier) из компании HP он поставляет популярные средства для аварийного восстановления Active Directory. Джил также является основателем конференции Directory Experts (www.dec2008.com).


 Специальная статья: Windows Server 2008: Начало работы с IIS 7.0
Специальная статья: Windows Server 2008 Айзек Ройбал (Isaac Roybal)

Начало работы с IIS 7.0
Краткий обзор:
  • Изменения архитектуры IIS 7.0
  • Управление IIS 7.0
  • Обратная совместимость
  • Устранение неполадок в IIS 7.0

Все отделы ИТ различны; каждый имеет собственный уникальный набор потребностей и целей, особенно относительно размещения веб-узлов или служб. Для веб-серверов могут требоваться различные сочетания компонентов для удовлетворения требований организации, а, кроме того, существует задача
репликации этого набора для нескольких серверов с одновременным обеспечением эффективного управления ими. Некоторые существенные отличия в IIS 7.0 предназначены специально для того, чтобы отделы ИТ осуществляли именно это при создании веб-сервера или веб-фермы.
После перечисления всех замечательных возможностей IIS 7.0 мне не терпелось поделиться этими сведениями с вами. Когда я понял, что не смогу рассмотреть все функции, я решил уделить основное внимание наиболее значительным возможностям и существенным изменениям в IIS 7.0. Для получения дополнительных сведений посетите веб-узел сообщества IIS, находящийся по адресу IIS.net.

Новая архитектура
Основные изменения IIS 7.0 относятся к архитектуре, обработке запросов, поддержке платформы приложений PHP и хранилищу настроек. В IIS 6.0 функции по большей части носили характер «все или ничего». Необходимо было установить все функции, а настройка IIS осуществлялась только с помощью интерфейса ISAPI.
Идея IIS состоит в том, что веб-администратору необходимо начать с базового набора функций, а затем добавлять только те дополнительные функции, которые необходимы для его среды. Вы знаете свою среду лучше всего, поэтому IIS 7.0 предоставляет стандартные блоки для создания собственного пользовательского веб-сервера. Это ведет к снижению административных расходов благодаря уменьшению количества возможных направлений атак на сервер и устранению необходимости обновления неиспользуемых компонентов. Ключевым моментом этого нового подхода является модульная архитектура IIS 7.0.
Новая модель IIS 7.0 позволяет выбрать устанавливаемые на сервере функции, называемыми модулями. Эти модули встраиваются непосредственно во встроенный конвейер обработки запросов. Эта новая модульная конструкция имеет несколько преимуществ, включая уменьшение количества возможных направлений атак и размера веб-сервера.
В данный момент в состав IIS входит 40 модулей по умолчанию — например, обычная, анонимная проверка подлинности и проверка подлинности Windows® теперь выделены в отдельные модули, которые могут добавляться к конвейеру обработки запросов независимо. Для упрощения классификации модули сгруппированы в восемь подкатегорий (см. рис. 1).
Рис. 1 Модули IIS 7.0 разделены на восемь функциональных областей
Рис. 1 Модули IIS 7.0 разделены на восемь функциональных областей
Это означает, что теперь возможно создание веб-сервера, точно настроенного в соответствии с вашей средой. Но если необходимы функциональные возможности, не предоставляемые 40 модулями по умолчанию, скажем, определенная настраиваемая проверка подлинности или модификатор содержимого? Нет проблем. Можно написать модуль для восполнения этой потребности на машинном или управляемом коде и подключить его непосредственно к конвейеру. Это также позволяет корпорации Майкрософт создавать и выпускать новые модули по отдельности, избавляя от необходимости ожидания следующего пакета обновления или основного выпуска. IIS 7.0 также позволяет переписывать любой из 40 стандартных модулей собственными пользовательскими модулями. Дополнительные сведения о создании собственных модулей приведены на веб-узле IIS.net.

Встроенный конвейер обработки запросов
Встроенный конвейер обработки запросов можно рассматривать как необходимый набор линейных действий, которые должны выполняться при каждом предоставлении страницы (как показано на рис. 2). Обычно этот набор состоит из определенной проверки подлинности и последующей авторизации для получения содержимого, определения и выполнения обработчика, необходимого для этого содержимого, выполнения необходимой регистрации, и, наконец, отправка запроса. Встроенный конвейер обработки запросов предоставляет IIS 7.0 гибкость одновременного выполнения различных платформ приложений. Например, можно выполнить проверку подлинности на основе форм на содержимом PHP с пользовательским модулем ведения журнала в одном конвейере.
Рис. 2 Интегрированный конвейер и модули IIS 7.0
Рис. 2 Интегрированный конвейер и модули IIS 7.0
Каждый веб-узел на сервере имеет встроенный конвейер обработки запросов и может быть запущен в одном из двух режимов – встроенном или классическом. Встроенный режим, режим по умолчанию, позволяет подключать к конвейеру определенные функциональные возможности, обеспечивая настраиваемый контроль над обработкой запроса. Для обеспечения совместимости классический режим воспроизводит функции IIS 6.0/ISAPI с помощью модуля ISAPI в конвейере. Это очень полезно при переносе приложений в IIS 7.0.

Установка по умолчанию
Рассмотрим настройку нового модульного веб-сервера. Если взглянуть на установку IIS 7.0 по умолчанию, можно заметить, что включены только 10 модулей (если включена служба активации процессов Windows). Настройка IIS 7.0 предоставляет базовую функциональность IIS при установке роли веб-сервера, в частности, только модули, необходимые для предоставления статического содержимого, например, обычного кода HTML или классических страниц ASP. Последующая установка дополнительных компонентов на сервере определяется только вами. Ниже приведены функциональные возможности, включенные в установку по умолчанию:
  • Основные функции HTTP, включая статическое содержимое, документ по умолчанию, обзор каталога и ошибки HTTP
  • Функции работоспособности и диагностики, такие как ведение журнала HTTP и монитор запросов
  • Функции безопасности, такие как фильтрация запросов
  • Функции повышения производительности, такие как сжатие статического содержимого
  • Средства управления, в том числе консоль управления IIS
  • Служба активации процессов Windows
Как видите, это сервер с минимально необходимым количеством компонентов, в состав включающий ASP.NET и другие новые функции IIS 7.0, такие как функции диагностики и устранения неисправностей. Добавление на сервер дополнительных функциональных возможностей, таких как возможность передачи динамического содержимого, например, ASP.NET и FastCGI (PHP), осуществляется очень просто. Выберите необходимый для установки набор модулей в разделе «Add Role Services» (Добавление служб роли) роли веб-сервера в диспетчере Windows Server® 2008 Server Manager.

Новое хранилище настроек
Другим ключевым изменением в IIS 7.0, упрощающим вашу работу, является новое хранилище настроек. Метабаза, теперь являющаяся дополнительным устанавливаемым компонентов для обеспечения обратной совместимости, заменена системой настроек на основе XML. Я уже слышу, как вы говорите: «Но метабаза была в формате XML!» Да, была. Но она была громоздкой и не простой для чтения (по крайней мере, человеческого). Она заменена более гибкой системой XML. Подобно ASP.NET, IIS 7.0 использует файлы .config — простые, ясные, переносимые и простые для чтения файлы.
Переход на этот формат означает, что теперь система настроек независима от компьютера, в отличие от метабазы, которая была прикреплена к отдельному компьютеру. Как следствие, теперь система настроек может быть просто перенесена на другие серверы с помощью обычного перетаскивания или команды xcopy.
Эта новая система настроек также замечательно работает для веб-ферм, используя новую функцию IIS 7.0, называемую настройкой общего пользования. Поскольку эта система настроек является переносимой, один главный файл .config можно использовать на всех узлах фермы. Настройка общего пользования позволяет экспортировать известную удачную настройку сервера подготовки, а затем совместно использовать ее в рабочей или производственной среде.
При экспорте файла .config необходимо указать пароль ключа шифрования для него. Это защищает файл .config от попыток незаконного веб-сервера имитировать файл .config сервера без авторизации.
Включение настройки общего пользования осуществляется очень просто. На узле сервера диспетчера служб IIS выберите пункт «Shared Configuration» (Настройка общего пользования), который находится в разделе «Управление» на панели задач. Просто установите флажок «Enable shared configuration» (Включить настройки общего пользования), укажите физический путь к файлу настройки для совместного использования (обычно это общая папка UNC), введите учетные данные, необходимые для доступа к физическому пути, и нажмите кнопку «Применить». После нахождения файла .config появится запрос на ввод пароля шифрования. После завершения процесса перезапустите диспетчер служб IIS, чтобы он выбрал новый файл .config.
Поскольку структура новой системы настроек отличается от той, к которой вы привыкли, рассмотрим ее основы. Как показано на рис. 3, настройка IIS 7.0 разделена на две категории – параметры уровня сервера и параметры узла. Все параметры уровня сервера хранятся в файле applicationhost.config, который находится в папке %systemroot%\windows\system32\inetsrv\config. К ним относятся параметры всех установленных модулей, узлов на сервере и т.д. Параметры узла хранятся в отдельных файлах web.config.
Рис. 3 Существует один файл .config для параметров уровня сервера и отдельные файлы для каждого веб-узла на этом сервере
Рис. 3 Существует один файл .config для параметров уровня сервера и отдельные файлы для каждого веб-узла на этом сервере
Если вы использовали ASP.NET, вы, наверное, знакомы с файлами web.config. Службы IIS 7.0 используют файлы web.config для хранения параметров отдельных веб-узлов, таких как документ узла по умолчанию и параметры приложений, а также параметры ASP.NET. Это означает, что для каждого узла на сервере существует файл web.config.
Файл web.config узла находится в физическом пути к узлу, например, %systemroot%\inetpub\wwwroot. Такая модель предоставляет такие же преимущества переносимости, которые были описаны ранее, но на уровне узла. Например, можно просто разработать узел на тестовом сервере, а затем перенести файл web.config и файлы приложения на рабочий сервер с помощью перетаскивания или функции xcopy.
При переносе или совместном использовании файлов .config следите за сведениями, зависящими от компьютера, такими как IP-адрес и буквы дисков. Службы IIS 7.0 предоставляют решение для возможных ошибок в подобных параметрах, поддерживая переменные среды операционной системы (например, %systemroot%). Кроме того, убедитесь, что на тестовых и рабочих серверах установлен одинаковый набор модулей. Это поможет избежать появления непредвиденных ошибок приложений. Ошибки также могут возникать, если в файле web.config содержится ссылка на неустановленный модуль или в случае конфликта стандартного модуля с пользовательским.

Управление веб-сервером
Теперь в вашем распоряжении этот новый, замечательный, настраиваемый, гибкий и переносимый веб-сервер. Как вы собираетесь управлять им? Управление было важной частью планирования и создания служб IIS 7.0, и существует несколько способов администрирования.
Обычно предпочтения в области управления относятся по крайней мере к одной из трех категорий: администрирование «укажи и щелкни» из пользовательского интерфейса, ввод команд в командной строке и написание сценариев для максимальной автоматизации. Начнем с пользовательского интерфейса.
В IIS 6.0 пользовательский интерфейс оснастки консоли управления Microsoft® (MMC) имеет два основных знакомых представления, представление в виде дерева и представление в виде вкладок. Для перехода к определенному параметру необходимо щелкнуть его правой кнопкой мыши и выбрать «Properties» (Свойства), после чего появится набор вкладок, не говоря уж о переключателях и флажках.
К счастью, пользовательский интерфейс в IIS 7.0 полностью переработан. Этот пользовательский интерфейс, называемый диспетчером служб IIS, задумывался для реализации подхода, ориентированного на задачи, как показано на рис. 4. Также существует диспетчер Remote Manager для клиентов нижнего уровня, таких как Windows XP и Windows Server 2003. Его можно загрузить с веб-узла IIS.net/downloads.
Рис. 4 Новый пользовательский интерфейс в IIS 7.0
Рис. 4 Новый пользовательский интерфейс в IIS 7.0
Новый пользовательский интерфейс состоит из панели «Подключения» слева, панели «Действия» справа и панели задач или рабочей области в центре. Дерево диспетчера подключений слева сходно с представлением в виде дерева IIS 6.0 с родительскими и дочерними узлами. В представлении в виде дерева появилась возможность создания новых подключений, сохранения текущих подключений и удаления существующих подключений. Панель задач – самое важное улучшение пользовательского интерфейса с двумя представлениями для работы. В представлении функций все настраиваемые свойства IIS, которые ранее были доступны на представлении «вкладки», сгруппированы по областям администрирования, таким как IIS, управление и безопасность.
В диспетчер служб IIS также интегрированы свойства ASP.NET, избавляя от необходимости использовать дополнительную оснастку MMC. Каждое настраиваемое свойство имеет собственный значок, что упрощает поиск свойств. А поскольку диспетчер служб IIS создавался как приложение Windows Forms, можно легко добавлять значки подключаемых модулей для любых созданных пользовательских модулей или функций.
Просмотр содержимого – второе представление панели задач, сходное с IIS 6.0 тем, что можно просмотреть, что находится в каталоге содержимого узла, и выполнять действия с этим содержимым. Новой является возможность выбора определенной части содержимого, например, веб-страницы, с последующим переключением к представлению функций для вызова параметров только для определенного содержимого, что обеспечивает настраиваемый контроль до уровня страницы.

Другие способы управления
Для тех, кто предпочитает командную строку, доступно новое многостороннее средство APPCMD.exe, позволяющее выполнять простые задачи, такие как остановка узла или резервное копирование текущего файла .config, а также более сложные задачи, например, поиск схемы настройки. Синтаксис очень простой:
APPCMD (command) (object-type) <identifier> </parameter1:value1 ...>.
Для получения списка всех объектов, доступных для APPCMD, введите:
APPCMD /?
Чтобы просмотреть все команды, доступные для определенного типа объекта, введите:
APPCMD (object-type) /?
В IIS 7.0 добавлены новый интерфейс API управляемого кода под названием Microsoft.Web.Administration и новый поставщик WMI (инструментария управления Windows), которые будут полезны всем программистам. Эти два метода предоставляют массу возможностей для создания сценариев, автоматизации и написания средств для управления IIS 7.0. Оба метода могут использоваться при помощи Windows PowerShell®, а поставщик WMI – также при помощи VBScript и JScript®. Дополнительные сведения имеются в блоге blogs.msdn.com/carlosag/archive/2006/04/17/MicrosoftWebAdministration.aspx.

Удаленное управление и делегированное администрирование
Службы IIS 7.0 предоставляют новые способы удаленного управления сервером, узлами, веб-приложениями и безопасно делегированные права администрирования для пользователей, не являющихся администраторами. Сначала рассмотрим новые средства удаленного управления и то, как они могут упростить вашу работу.
Раньше существовало два способа удаленного управления сервером IIS: с помощью веб-узла удаленного управления или удаленного рабочего стола/служб терминалов для доступа к пользовательскому интерфейсу. Но при нахождении с внешней стороны брандмауэра или не на узле эти способы были не особо полезны. В службах IIS 7.0 эта проблема устраняется благодаря созданию способов удаленного управления непосредственно в пользовательском интерфейсе, работающем через совместимое с брандмауэром подключение HTTPS.
Удаленное управление в IIS 7.0 упрощает работу несколькими способами. Во-первых, работа осуществляется с таким же пользовательском интерфейсом, как и при локальном входе в систему. Во-вторых, не требуется открывать порты на брандмауэре, поскольку связь осуществляется через HTTPS. Наконец, теперь из одного пользовательского интерфейса можно управлять несколькими серверами. Не требуется, чтобы одновременно были открыты несколько окон подключения к удаленному рабочему столу или удаленному веб-узлу.
Служба удаленного управления в IIS 7.0 фактически представляет собой небольшое веб-приложение, работающее как отдельная служба под учетной записью локальной службы Windows NT® с именем NT Service\WMSVC. Такая модель обеспечивает сохранение возможности удаленного управления, даже если сам сервер IIS не отвечает.
Как и большинство функций IIS 7.0, удаленное управление в целях безопасности не установлено по умолчанию. Для установки функций удаленного управления добавьте службы ролей для роли веб-сервера в диспетчере сервера Windows Server 2008, который находится в разделе «Management Tools» (Средства управления). После установки функции необходимо включить удаленные подключения и запустить службу WMSVC, поскольку по умолчанию она остановлена.
Параметр запуска службы WMSVC по умолчанию – вручную. При необходимости автоматического запуска службы после перезагрузки необходимо изменить значение параметра на автоматический запуск. Это можно сделать, введя следующее в командной строке:
sc config WMSVC start=auto
При включении удаленных подключений через службы управления появится список параметров, таких как «Удостоверяющие учетные данные», «Подключения» и «Ограничения для IPV4-адреса». В данный момент только одно решение является важным – определение набора удостоверяющих учетных данных для предоставления полномочия на подключение к IIS 7.0: только учетные данные Windows или учетные данные Windows и диспетчера IIS.
Первый вариант, указывающий на разрешение только учетных записей пользователей Windows, локальных или доменных, является довольно очевидным. По второму варианту проходят как пользователи Windows, так и тип учетной записи, являющийся совершенно новым в IIS 7.0 и не связанным с учетными записями пользователей Windows: пользователи диспетчера IIS. Учетные записи пользователей диспетчера IIS позволяют администраторам создавать учетные записи пользователей, известные только в контексте IIS 7.0 и не имеющие прав доступа к операционной системе. Наконец, службы IIS по умолчанию предоставляют самоподписанный сертификат, чтобы можно было начать работу, но рекомендуется добавить действительный подписанный сертификат SSL. Теперь необходимо просто применить параметры и запустить службу.
Для повышения безопасности и увеличения возможностей управления администраторы ИТ могут безопасно делегировать задачи администрирования отдельных узлов или веб-приложений пользователям, не имеющим прав администраторов.
Делегированное администрирование в сущности является удаленным администрированием, но оно ограничивает область доступа отдельными узлами или веб-приложениями. Функция пользователей диспетчера IIS особенно полезна здесь. Можно создать пользователей IIS для этих разовых владельцев узлов и делегировать им полномочия на администрирование собственного узла или приложения. У них отсутствует доступ к параметрам уровня сервера, и они ограничены только параметрами определенного узла или веб-приложения.
Кроме того, можно указать функции и параметры, изменяемые пользователями или даже отображаемые в пользовательском интерфейсе. Например, если тип проверки подлинности, используемый для данного узла, не должен никем изменяться, можно указать, что эта функция только для чтения или не наследуется. Функция только для чтения доступна для пользователей, и они могут определять ее параметр, но не могут вносить изменения; значок ненаследуемой функции отсутствует в представлении диспетчера IIS делегированного пользователя. Такой вид делегирования функции позволяет предоставлять другим пользователям строго контролируемый доступ без предоставления административного управления веб-сервером.

Переход на IIS 7.0
При создании служб IIS 7.0 группа разработчиков стремилась к тому, чтобы переход на них осуществлялся как можно более плавно, позволяя использовать некоторые существующие вложения в средства управления и сценарии для IIS 6.0. Была тщательно продумана обратная совместимость служб IIS 7.0, чтобы они могли работать со сценариями IIS 6.0. На узле совместимости управления IIS 6.0 программы установки можно установить весь набор средств — от совместимости метабазы IIS 6.до самой консоли управления IIS 6.0.
В инфраструктуре совместимости метабазы IIS 6.0 используется компонент с названием ADOMapper. Он позволяет выполнять сценарии метабазы объектов на основе администратора (ABO) и интерфейса ADSI IIS 6.0 в новой системе настроек, ограничивая ее только возможностями IIS 6.0. Поэтому чтение и запись новых свойств IIS 7.0, доступ к новым данным выполнения, чтение и запись свойств ASP.NET или файлов web.config невозможны.

Устранение неполадок и диагностика
Устранение неполадок и диагностика всегда были длительными процессами. Изучение журналов и попытка воспроизведения проблемы в большой веб-ферме или даже на одном сервере могут быть тяжелыми задачами. В состав служб IIS 7.0 входит средство, называемое отслеживанием сбойных запросов, которое позволяет упростить этот процесс и ускорить его выполнение. Средство может быть полезным во многих случаях, включая зависание запроса или его ошибок, а также для изучения проблем проверки подлинности и авторизации.
Отслеживание сбойных запросов использует правила отслеживания в качестве критерия поиска ошибок. Правила отслеживания могут быть созданы для поиска типов поведения или ошибок путем указания типа содержимого для отслеживания (например, все содержимое сервера, только содержимое ASP.NET или пользовательское содержимое, такое как PHP) и условий для начала отслеживания (например, определенный возвращенный код состояния, время предоставления страницы, серьезность события или сочетание условий).
Например, предположим, что пользователи сообщают о том, что загрузка узла длится слишком долго. В любом случае эту ситуацию трудно воспроизвести, особенно при наличии тысяч обращений в час. С помощью отслеживания неудачно завершенных запросов можно просто добавить правило отслеживания для начала ведения журнала в том случае, если загрузка страницы длится дольше необходимого времени — например, две секунды для этого примера — и подождать, пока сервер самостоятельно воспроизводит проблему (см. рис. 5).
Рис. 5 Использование отслеживания сбойных запросов для устранения неисправностей
Рис. 5 Использование отслеживания сбойных запросов для устранения неисправностей
Разница между отслеживанием сбойных запросов и традиционным ведением журнала состоит в том, что при использовании первого ведение журнала начинается только при обнаружении определенного критерия сбойного запроса. Сам файл журнала – это документ XML с таблицей стилей XML, что делает его простым и ясным для чтения. Как и большинство других функций IIS 7.0, отслеживание сбойных запросов не устанавливается по умолчанию и находится в разделе работоспособности и устранения неисправностей программы установки. Его также необходимо включить в диспетчере IIS.
Службы IIS 7.0 – большой шаг вперед для всех администраторов. Новая архитектура и возможности обеспечивают гибкость и динамичность, необходимые для адаптации к непрерывно меняющейся среде. Благодаря возможностям управления, средствам обратной совместимости и возможностям устранения неполадок службы IIS 7.0 готовы к развертыванию уже сегодня и работе с существующей средой.

Айзек Ройбал (Isaac Roybal) - менеджер по продуктам в группе Windows Server корпорации Майкрософт. Он занимается всеми веб-компонентами Windows Server. Айзек работает в группе Windows Server с момента выпуска Windows NT 3.51 и IIS 4.0. До этого он работал в качестве ответственного за программу эксплуатации в группе Office Internet Platoform & Ops. Он имеет сертификат MCSE по Windows NT 4.0, Windows 2000 и Windows Server 2003.


 Специальная статья: Windows Server 2008: Сетевой доступ в Windows Server 2008 на основе политик
Специальная статья: Windows Server 2008 Ян Хамеров (Ian Hameroff) and Амитх Кришнан (Amith Krishnan)

Сетевой доступ в Windows Server 2008 на основе политик
Краткий обзор:
  • Баланс между свободой доступа к сети и безопасностью.
  • Сетевой доступ на основе политик.
  • Новые технологии обеспечения безопасности в Windows Server 2008.

Сейчас много пишут о том, что традиционные границы сетей размываются: появляется все больше мобильных сотрудников, самые разнообразные пользователи и устройства требуют
доступа к ИТ-ресурсам организации. И пользователи, и владельцы компаний хотят, чтобы работа в сети была бесперебойной и не требовала особо сложных процедур — это должно повысить производительность. Эта и без того непростая ситуация дополняется все более суровыми требованиями законодательства, ширящейся армией сетевых угроз и рисками, связанными с децентрализацией данных.
При таком раскладе перед администраторами Windows® встает непростая задача из области безопасности: как обеспечить простоту доступа к ресурсам и при этом соблюсти все требования к безопасности сетей и информации?
Единого решения, разумеется, не существует, однако в распоряжении администратора Windows имеется целый ряд средств, позволяющих усилить контроль безопасности, например граничные брандмауэры. Большим шагом в сторону искомого равновесия будет переход от традиционной модели сетевого взаимодействия к модели новой, больше опирающейся на логику и политики.

Сетевой доступ на основе политик
Материалы по сетям
  • IPsec
  • Брандмауэр Windows в режиме повышенной безопасности
  • Изоляция серверов и доменов
  • Защита доступа к сети (NAP) для Windows Server 2008

Задача применения политик в управлении доступом к сети — устранить ограничения, возникающие тогда, когда доверие основывается в первую очередь на топологии сети. К примеру, можно ли с уверенностью сказать, что устройсву можно доверять (и разрешать подключаться к серверу, на котором работает CRM-приложение) лишь на том основании, что оно подключено к одному из портов коммутатора Ethernet, расположенного за корпоративным брандмауэром?
В новой модели решения, касающиеся предоставления или запрета доступа, опираются на результаты проверки как безопасности устройства, так и пользователя, запрашивающего доступ, вне зависимости от того, в какой точке сети он пытается подключиться. После проверки подлинности та же самая схема может использоваться для определения набора ресурсов, к которому может быть получен доступ.
Для перехода от такого «позиционного» подхода к подходу, больше ориентрированному на доступ, требуется ряд ключевых ингредиентов, в том числе механизмы, способные проверять подключающиеся узлы на предмет правильности удостоверений и соответствия политикам, выпускать доверенные удостоверения пользователей и динамически контролировать доступ к сети на основании упомянутых атрибутов. Важно также иметь централизованное хранилище политик — оно позволит упростить управление различными изменяющимися составляющими.
Подход на основе политик позволяет избавиться от целого ряда разрозненных средств управления узлами и доступом к сети, внедрив единое комплексное решение. А оно, в свою очередь, позволяет настроить правила доступа к сети на уровне логики, над уровнем подключений, и тем самым расширить традиционные методики глубокой защиты.
Например, при подключении портативного компьютера к беспроводной сети организации компьютер может проверяться на предмет соблюдения всех требований к настройке системы безопасности. После того как сеть определит, что на компьютере установлены все обновления антивирусного программного обеспечения и критические исправления системы безопасности, включены все элементы системы безопасности конечной точки — в частности брандмауэр узла — компьютер получает доступ к сети. Затем, если пользователь пытается подключиться к бизнес-приложению, система использует сочетание данных о текущей работоспособности портативного компьютера и сетевое удостоверение пользователя, чтобы определить, имеет он право пользоваться ресурсами приложения или нет. Политики, работающие на уровне логики (он расположен над уровнем физической инфраструктуры сети) могут применяться непрерывно, даже если пользователь закрывает беспроводное подключение и переходит на проводное или даже на удаленный доступ.
Сетевой доступ на основе политик упрощает работу пользователя в сети, не нарушая при этом безопасности процессов. Для администраторов нивелировка элементов управления сетевым доступом, от портов коммутаторов для шлюзов удаленного доступа, упрощает процедуры управления. В обоих случаях конечным результатом будет рост производительности и вообще повышение работоспособности сети организации, даже если в сетях размещаются участники с разными правами доступа, скажем гости (неважно, приглашены они или нет), поставщики, партнеры, сотрудники самой организации.
Как и в любом проекте системы безопасности, при реализации сетевого достура на основе политик первым шагом является разработка набора обобщенных политик. Обычно в них включаются рекомендации по следующим вопросам:
  • Соблюдение требований к безопасности устройств: что такое работоспособное устройство?
  • Логическое зонирование сети: как отделить неработоспособные устройства от устройств, прошедших проверку подлинности?
  • Управление информационными рисками: как классифицировать конфиденциальную информацию и защитить ее от взлома?
Существует большой набор ресурсов по разработке политик в центре безопасности Microsoft® TechNet Security Center (microsoft.com/technet/security).
После разработки политик доступа нужно выбрать технологии, позволяющие как распространить политики, так и гарантировать их соблюдение. Для этого вполне достаточно системы Windows Server® 2008: это не только самая безопасная серверная система на сегодняшний день, это еще и укрепленная платформа средств безопасности, способная стать краеугольным камнем решения по обеспечению доступа к сети на основе политик. В огромном списке новых функций, появившихся в Windows Server 2008, есть немало ингредиентов, необходимых для реализации безопасных средств обеспечения доступа к сети на основе политик, — они ползволяют обеспечить защиту конфиденциальной информации от взлома.

Сети нового поколения
В основе улучшений системы безопасности сети в Windows Server 2008 лежит новый стек TCP/IP — немаловажное обновление сетевых функций платформы и связанных с ними служб. Windows Server 2008 не только повышает производительность и стабильность сети, но и укрепляет систему безопасности за счет набора интегрированных сетевых функций, создающих мощнейшее основание, на котором можно создать решение по обеспечению доступа к сети на основе политик.
Безопасность IPsec — одна из функций, претерпевших значительные изменения в Windows Server 2008. Она может сыграть весьма важную роль в организации доступа к сети на основе политик. Теперь все вопросы сводятся не к использованию IPsec в качестве протокола туннелирования и шифрования, а к применению имеющихся у него функций проверки подлинности в сетях типа «узел–узел». Кроме того, поскольку IPsec работает в слое 3, его можно использовать для обеспечения применения политик доступа к сети в сетях различных типов.
В целях облегчения внедрения элементов управления доступом к сети на основе IPsec в Windows Server 2008 вводятся новые функции, целью которых является упрощение создания, внедрения и обслуживания политик. Например, увеличилось число методов проверки подлинности в IPsec. Этого добились путем внедрения компонента Authenticated IP (AuthIP) — расширения протокола IKE. AuthIP дает возможность самостоятельно создавать правила безопасности подключений (это еще одно название политик IPsec в Windows Server 2008), согласно которым партнеры по подключению должны пройти проверку подлинности, предоставив не только учетные данные компьютера, но и учетные данные пользователя или данные о работоспособности устройства. Это дает дополнительный запас гибкости, позволяющий разрабатывать двольно сложные логические сети без обновления инфраструктуры коммутаторов и маршрутизаторов.

Брандмауэр Windows в режиме повышенной безопасности
Режим повышенной безопасности, который появился у брандмауэра, строется на базе функций IPsec, описанных выше. Объединяя правила безопасности подключения IPsec и фильтры брандмауэра в одну политику, новый брандмауэр Windows создает новое измерение в сфере доступа к сети на основе политик: расширяются возможности интеллектуальной проверки подлинности.
Как показано на рис. 1, теперь есть три варианта реакции фильтра сходящих или исходящих подключений: позволить подключение, блокировать подключение и позволить подключение, только если оно безопасно. В последнем варианте брандмауэр Windows задействует функции проверки подлинности в сети типа «узел–узел», предоставляемые протоколом IPsec, и с их помощью определяет, разрешить запрашивающему узлу (пользователю) подключение или нет — на основе заданной политики. В правилах брандмауэра можно указать, какие пользователи, компьютеры и группы имеют право устанавливать подключение. Нужно отметить, что тем самым создается дополнительный уровень безопасности, дополняющий элементы управления доступом, работающие на уровне системы и на уровне приложений.
Рис. 1 Создание правил проверки подлинности брандмауэром
Рис. 1 Создание правил проверки подлинности брандмауэром
Уже сейчас должно быть видно, каким образом элементы управления системой безопасности сети можно объединить при помощи централизованной политики, создав тем самым более эффективное и масштабируемое средствано управления доступом к сети.
Возвращаясь к примеру с CRM: администратор может создать входящее правило для серверов, обслуживающих CRM-приложение в организации и установить флажок «Разрешить безопасное подключение». В той же самой политике администратор может указать, что подключаться к данному сетевому приложению могут только пользователи, входящие в группу «Пользователи приложения CRM», как показано на рис. 2. Если таким же образом настроить правила доступа для всех подключений между всеми управляемым компьютерами, входящими в сеть, получится уровень изоляции доменов и серверов — составляющая стратегии организации доступа к сети на основе политик.
Рис. 2 В политике администратор может определить набор участников, имеющих право подключения
Рис. 2 В политике администратор может определить набор участников, имеющих право подключения

Изоляция серверов и доменов
Сейчас все больше гостей и прочих неуправляемых устройств подключается к корпоративным сетям, и для компаний становится все более важным найти способ ограничить и защитить доверенные узлы. К счастью, существует много способов изолировать доверенные управляемые компьютеры от других устройств, входящих в сеть. Но следует помнить и о том, что многие из них требуют больших затрат (организация отдельных кабельных систем, например) и становятся сложными в обслуживании (скажем, сети VLAN на коммутаторах) при определенном размере сети.
Изоляция серверов и доменов может стать более экономичным и управляемым способом сегментации среды на логически изолированные, безопасные подсети. На рис. 3 показано, что при этом используются в основном те же правила безопасности подключений (то есть политики IPsec), что были упомянуты ранее, но сопоставляются они со всеми управляемыми компьютерами через групповую политику Active Directory®. В результате мы получаем политику доступа к сети, при использовании которой все участники должны успешно пройти проверку подлинности, прежде чем им будет разрешено начать обмен данными. Посольку изоляция происходит в слое 3, действие данных элементы управления доступом распространяется на шины, коммутаторы и маршрутизаторы независимо от их филического и географического положения.
Рис. 3 Определение требований к проверке подлинности в соответствии с потребностями в доступе
Рис. 3 Определение требований к проверке подлинности в соответствии с потребностями в доступе
Чтобы можно было создать изолированную сеть, компьютеры в сети должны быть поделены по типу доступа. Можно задать политики, позволяющие компьютерам, находящимся в изолированной подсети, обмениваться данными со всеми компьютерами, подключенными к сети компании, в том числе и к неизолированному сегменту. Компьютеры же, не входящие в изолированную подсеть, не могут инициировать обмен данными с компьютерами, входящими в нее. Компьютеры изолированного сегмента будут просто игнорировать такие попытки.
Для внедрения сетевых политик используется домен Active Directory и членство в домене. Компьютеры, являющиеся членами домена, разрешают другим компьютерам подключаться, только есди те прошли проверку подлинности и обеспечили безопасность соединения. Дополнительно можно в обязательном порядке использовать шифрование при обмене данными в пределах изолированного домена.
Изоляция серверов и доменов очень выгодна с финансовой точки зрения, поскольку кардинально перестраивать сетевую инфраструктуру не приходится. Такое решение позволяет создать своеобразный барьер из политик, который не только позволяет защитиь от сетевых атак, порой оказывающихся весьма дорогостоящими, и несанкционированного доступа к доверенным ресурсам сети, но и не требует текущего обслуживания, связанного с изменениями топологии сети.

Защита доступа к сети
Как упоминалось ранее, изоляция серверов и доменов обеспечивает логическое разделение компьютеров и серверов, подключенных к сети. Она защищает от несанкционированного доступа, но не дает никаких гарантий, что компьютер, прошедший проверку подлинности, не станет угрозой системы безопасности.
Защита доступа к сети (NAP) — это платформа, встроенная в Windows Server 2008. Она позволяет гарантировать работоспособность (а именно безопасность и соблюдение политик) системы компьютера, подключающегося к сети или обменивающегося данными внутри нее.
Даже пользователи, прошедшие проверку подлинности, нередко становятся распространителями вирусов и шпионского программного обеспечения. Например, пока пользователь в отпуске, его компьютер может перестать соответствовать требованиям к безопаности, установленным администратором. Если не установить на компьютере обязательное исправление или подпись, выпущенную во время отсутсвия пользователя, это может привести к весьма неприятным последсвиям.
Администратор, разумеется, не способен отслеживать всех пользователей, подключенных к сети. Здесь необходимо автоматическое средство, которое бы проверяло работоспособность каждого компьютера и предлагало решения в случае несоответствия, опираясь при этом на централизованные политики. NAP как раз это и делает — в решении доступа к сети на основе политик появляется еще один уровень.
Агент NAP — либо встроенный в систему клиентского компьютера (как в случае с Windows Vista®), либо установленный отдельно (как в предыдущих версиях Windows и в системах сторонних разработчиков) — передает отчеты о соблюдении установленных требований серверу сетевых политик (NPS), который представляет собой механизм обработки политик, встроенный в Windows Server 2008. Именно в NPS задаются политики, которым должны соответствовать все устройства.
Подключения устройств, не прошедшие проверку на соответствие требованиям, конечно, нужно ограничивать, но не менне важно предоставить им возможность уйти на карантин и исправить те моменты, которые политикам не соответствуют. NAP позволяет в некоторых случаях автоматически исправить устройство (например когда отключен брандмауэр или антивирус) или предлагает перейти в режим карантина и исправить ошибки вручную. Во втором случае устройству дается доступ к серверу исправления, на котором хранятся все последние исправления, обновления и подписи. Как только пользователь вручную исправит компьютер, ему будет разрешен доступ к сети (проверка на соответствие проводится повторно).
При сегодняшней доступности информации доступ к сети стал значительно проще, но при этом появились дополнительные заботы по обеспечению работоспособности устройств независимо от используемого механизма доступа. Компьютеры могут подключаться к сети через стандартный коммутатор или беспроводную точку доступа (802.1X), а могут подключаться удаленно с использованием VPN или служб терминалов. NAP не только позволяет проверить соответствие компьютеров, подключающихся с применением различных механизмов доступа, всем установленным требованиям, но и обеспечивает соблюдение требований на серверах DHCP, коммутаторах 802.1X, шлюзах VPN и служб терминалов, беспроводных точек доступа стандарта 802.1X.
На рис. 4 приведена сеть, в которой используется изоляция серверов и доменов. Применение NAP в такой изолированной сети дает дополнительные преимущества: обеспечивается соответствие компьютеров, подключающихся к ней, всем установленным требованиям. При запуске клиент отправляет заявление о работоспособности (SoH) в центр регистрации работоспособности (HRA), представляющий собой сервер сертификатов. HRA передает SoH в NPS на проверку. Если SoH проверку проходит, центр HRA передает клиенту NAP сертификат работоспособности и клиент получает разрешение инициировать безопасное подключение к защищенным ресурсам на основе IPsec. Если SoH не проходит проверку, центр HRA сообщает клиенту NAP, какие изменения требуются для достижения работоспособного состояния, и сертификат не выдает. Клиент NAP не сможет инициировать обмен данными с другими компьютерами, если им требуется сертификат работоспособности для проверки подлинности по IPsec. Однако клиент NAP сможет подключиться к серверу исправлений и восстановить работоспособное состояние.
Рис. 4 Защита доступа к сети при помощи IPsec
Рис. 4 Защита доступа к сети при помощи IPsec

Подводя итоги
Хотя новых функций Windows Server 2008 мы коснулись лишь поверхностно, нужно отметить, что каждый из новых компонентов построен на базе предыдущей версии. От традиционного подхода к защите информации новый подход отличает схема политик, лежащая в его основе: в Windows Server 2008 она реализуется, к примеру, на основе групповых политик Active Directory.
Благодаря интеграции всех средств созадется прочное основание, позволяющее сформировать и размернуть решение для доступа к сети на основе политик без потери уже существующих средств. Поскольку решение о предоставлении доступа выносится на логическом уровне, опирающемся на политики, вы можете создать баланс между простотой доступа и безопасностью сети, который ьудет работать вам на пользу.
Специалисты Майкрософт опубликовали немало руководств по технологиям, которые были упомянуты в данной статье. Мы рекомендуем для начала просмотреть предложенные материалы и пошаговые руководства, чтобы ознакомиться с различными функциями. (Ссылки в боковой панели «Материалы по сетям» помогут вам сделать первые шаги в их освоении.) Затем постарайтесь проводить работу поэтапно, чтобы кажды сделанный шаг становился надежным основанием для следующих действий.
Например, начните с создания набора правил проверки подлинности для бандмауэра, как описано в разделе «Брандмауэр Windows в режиме повышенной безопасности», — они будут применяться в случае доступа к приложениям, критическим для функционирования компании. Когда вы будете довольны результатом, переходите к изоляции сетевого домена и надстройке NAP. Стратегия доступа к сети на основе политик может иметь значительные преимущества, в частности она поможет вам уследить за постоянно меняющимся миром по имени корпоративная сеть.

Ян Хамеров (Ian Hameroff) — старший менеджер по продуктам Майкрософт в группе продвижения систем безопасности и управления доступом. Он отвечает за управление разработкой и продвижение сетевых технологий платформы Windows Server. Ян проводит в жизнь стратегию вывода на рынок сетевых компонентов и решений для платформы Windows Server, сконцентрированных вокруг ключевых инициатив, таких как изоляция домена и сервера, масштабируемые сети, внедрение IPv6.
Амитх Кришнан (Amith Krishnan) — старший менеджер по продуктам Майкрософт в группе продвижения систем безопасности и управления доступом, отвечает за управление разработкой и продвижение инициатив, связанных с безопасностью Windows Server и работой в сети (защита сетевого доступа, защита беспроводных сетей). Он также занимается разработкой стратегии вывода этих решений на рынок и распространения информации о них.


 Специальная статья: Windows Server 2008: Настройка ролей с помощью диспетчера серверов
Специальная статья: Windows Server 2008 Байрон Хайнз (Byron Hynes)

Настройка ролей с помощью диспетчера серверов
Краткий обзор:
  • Разница между ролями и компонентами
  • Что можно сделать с помощью диспетчера серверов
  • Работа с мастерами
  • Управление ролями и компонентами из командной строки

Одна из сквозных тем Windows Server 2008 – «чем меньше, тем лучше». Это не означает вырезание компонентов без нужды. Это означает стратегию упрощения и прояснения ролей и средств, позволяющую установить именно то, что нужно – и ничего более. Диспетчер серверов
является важной частью этой концепции Windows Server® 2008.
Это выражается в двух аспектах. Первый – это крайне важная концепция ролей и компонентов серверов, являющихся базовыми блоками Windows Server 2008. Второй – это само средство диспетчера серверов. Это средство не только заменяет несколько средств, использовавшихся в Windows Server 2003, но также сосредотачивает гораздо больше функций в одном месте, так что занятые администраторы могут выполнять больше работы, причем быстрее и проще.

Роли и компоненты
Те, кто читал о Windows Server 2008, вероятно уже сталкивались с некоторыми терминами, не употреблявшимися в контексте Windows® ранее, такими как «рабочие нагрузки» и «роли». Я начну с объяснения того, что эти термины значат для специалистов по ИТ.
В начале цикла разработки Windows Server 2008 мы потратили массу времени, пытаясь выяснить, как именно пользователи используют наши серверные продукты. (Собственно, и продолжаем пытаться.) В целом, мы обнаружили, что пользователи развертывают наши серверы для выполнения конкретных задач. Возможно, это не выглядит великим открытием, но для некоторых из нас статистика, показывающая, что пользователи не покупают наши серверы, просто чтобы иметь сервер, стала откровением. Что более важно, они не развертывают серверы для выполнения множества задач. Вместо этого они требуют от сервера чего-то конкретного. Конечно, бывают и исключения, но в большинстве случаев сервер выделяется для выполнения определенной функции.
В ответ на эти откровения мы сгруппировали эти «определенные функции» в широкие категории, именуемые рабочими нагрузками. Например, рабочую нагрузку базы данных и рабочую нагрузку сервера приложений. Поскольку рабочие нагрузки широки и порой туманны, мы создали подкатегории внутри них, именуемые ролями. Роль – это простая, четко определенная функция, выполнение которой ожидается от сервера. Подумайте о том, как вы (и знакомые вам пользователи) называете серверы в вашей сети. Большинство пользователей думает о них как о файловом сервере, контроллере домена, сервере печати, веб-сервере и так далее. Поскольку пользователи склонны думать о серверах в таком духе, Windows Server 2008 и использует такой же подход для работы с ролями.
Грубо говоря, в Windows Server 2008 существуют три широких категории ролей: управления идентификационными данными и доступом (эти роли помечены как часть Active Directory®), инфраструктуры (это включает файловые серверы, серверы печати, DNS и так далее) и приложений (такие как роль веб-сервера и службы терминалов).
В комплекте Windows Server 2008 будет поставляться примерно 17 ролей (включая такие роли, как службы сертификации Active Directory, службы сетевой политики и доступа и службы виртуализации Windows Server). Дополнительные роли, такие как роль служб потокового мультимедиа, скорее всего, будут доступны для загрузки.
По большому счету, каждая роль заслуживает собственной статьи. О некоторых из них рассказывается более подробно в этом выпуске TechNet Magazine, некоторые уже были освещены, а некоторым это еще предстоит. Каждую из них стоит изучить, начиная с информации, предоставленной на technet2.microsoft.com/windowsserver2008/en/servermanager/default.mspx.
В начале развертывания Windows Server 2008 необходимо выбрать, какие роли будут установлены на каждом сервере. Это развертывание на основе ролей является важным элементом эффективного использования Windows Server 2008 и гибкости при развертывании имеющихся ресурсов.
В список ролей не входят такие элементы, как шифрование диска BitLockerTM и балансировка сетевой нагрузки (Network Load Balancing – NLB). Это вызвано тем, что они являются компонентами – их присутствие желательно, но пользователь не будет покупать систему только ради них. Роли, с другой стороны, представляют именно задачи, для выполнения которых система и покупается. Для примера, пользователи не покупают серверы, чтобы применить балансировку сетевой нагрузки. Они покупают их с целью, скажем, обслуживания веб-узла. NLB может быть весьма существенным аспектом, скажем, веб-сервера, но не целью, ради которой сервер существует.
Вместо установки и включения всех компонентов сервера администратор выбирает, какие из них следует установить. (Список компонентов, входящих в Windows Server 2008, показан на рис. 1.) Включение только необходимых ролей и компонентов позволяет улучшить стабильность и безопасность. Если компонент или роль не установлены, то не надо и беспокоиться о потребляемых ими ресурсах. Аналогично, не надо беспокоиться об устранении неполадок компонентов или обеспечении безопасности ролей, если они не установлены.
Figure 1 Компоненты, поставляемые в комплекте с Windows Server 2008 (Close Figure 1)

Возможности Microsoft .NET Framework 3.0
Технология шифрования диска BitLocker
Серверные расширения BITS
Пакет администрирования диспетчера подключений
Темы рабочего стола
Управление групповой политикой
Клиент печати через Интернет
Сервер службы имен хранилищ Интернета (iSNS)
Монитор портов LPR
Очередь сообщений
Многопутевой ввод/вывод
Протокол однорангового разрешения имен
qWave
Удаленный помощник
Средства удаленного администрирования сервера
Диспетчер съемных носителей
Прокси RPC через HTTP
Службы для NFS.
Сервер SMTP
Диспетчер хранилища для сетей SAN
Простые службы TCP/IP
Службы SNMP
Подсистема для приложений на основе UNIX
Клиент Telnet
Сервер Telnet
Клиент протокола TFTP
Отказоустойчивая кластеризация
Балансировка сетевой нагрузки
Система архивации Windows Server
Диспетчер системных ресурсов Windows
Сервер службы WINS (дополнительно)
Служба беспроводной локальной сети
Внутренняя база данных Windows
Windows PowerShell
Служба активации процессов Windows
Воплощением этой концепции является вариант установки Server Core. Описание Server Core выходит за рамки этой статьи, но читатель может представить себе логическое завершение идеи, согласно которой неиспользуемые роли и компоненты не следует даже копировать на жесткий диск или делать доступными. Ключевое различие между обычной установкой и установкой Server Core заключается в том, что в нормальную установку входят все необходимые ресурсы для установки дополнительных ролей в любое время и поддерживаются все роли. Server Core же не имеет даже графического интерфейса для своей оболочки и поддерживает лишь ограниченный набор ролей.

Диспетчер серверов
Новая консоль диспетчера серверов в Windows Server 2008 облегчает управление несколькими серверными ролями в организации и обеспечение их безопасности. По сути являясь расширенным вариантом консоли управления Microsoft® (MMC), диспетчер серверов позволяет просматривать практически всю информацию и средства, влияющие на производительность сервера, и управлять ими. Он предоставляет единый источник управления идентификационной и системной информацией сервера, отображения состояния сервера, определения проблем в настройке серверных ролей и управления установленными ролями. (Отметьте, что он также заменяет несколько функций, входивших в Windows Server 2003, таких как управление данным сервером, настройку данного сервера и добавление или удаление компонентов Windows.)
В некоторых случаях диспетчер серверов может также уменьшить потребность администратора в выполнении мастера настройки безопасности (SCW) перед развертыванием серверов. Диспетчер серверов настраивает сервер таким образом, чтобы все установленные роли были функциональны – например, автоматически настраивая брандмауэр Windows. В тех же случаях, когда роли добавлены, а затем удалены, или когда пользователю нужен более строгий контроль над конкретными параметрами безопасности, SCW все равно является ценным средством. Дополнительные сведения приведены в статье Джеспера Йоханссона (Jesper Johansson) «Использование SCW в Windows Server 2008» («Using SCW on Windows Server 2008») из рубрики «На страже безопасности в этом выпуске нашего журнала (microsoft.com/technet/technetmag/issues/2008/03).
При работе над Windows Server 2008 мы тщательно рассмотрели способы выполнения задач, которыми должны пользоваться администраторы согласно нашим ожиданиям. Мы нашли способы, которыми средства и мастера упрощали их работу, и случаи, где требовалось слишком много перескакивания от одного средства к другому. Мы поставили важную цель при разработке Windows Server 2008 в целом и диспетчера серверов в частности – сделать администрирования сервера более эффективным путем предоставления администраторам возможности выполнять многие типы задач в одном месте. Как следствие, с помощью диспетчера серверов можно:
  • Просматривать роли и компоненты, установленные на сервере, и вносить в них изменения.
  • Выполнять управленческие задачи, касающиеся сервера, такие как запуск или остановку служб либо управление локальной учетной записью пользователя.
  • Выполнять управленческие задачи, касающиеся ролей, установленных на сервере.
  • Проверять состояние сервера, определять важные события и анализировать проблемы настройки.
  • Устанавливать или удалять роли, службы ролей и компоненты, используя графический интерфейс или командную строку.
Консоль диспетчера сервера представляет массу информации и функций на небольшом пространстве. На рис. 2 показана роль узла файловых служб на консоли диспетчера сервера. Основное окно консоли содержит четыре свертываемых раздела: сводку по серверу, сводку по ролям, сводку по компонентам, а также материалы и поддержку.
Рис. 2 Консоль управления сервером, отображающая роль файловых служб.
Рис. 2 Консоль управления сервером, отображающая роль файловых служб.
В сводке по серверу имеются два подраздела: сведения о компьютере и сведения о безопасности. В подразделе сведений о компьютере отображаются имя компьютера, домен, имя учетной записи локального администратора, сетевые подключения и код продукта операционной системы. Для изменения этой информации можно использовать команды. Подраздел сведений о безопасности отображает, включены ли автоматическое обновление Windows и брандмауэр Windows, а также включена ли настройка усиленной безопасности Windows Internet Explorer® (либо для администраторов, либо для прочих пользователей). Аналогично, здесь доступны команды для изменения этих параметров и для просмотра всех дополнительных вариантов.
В разделе сводки по ролям имеется таблица, указывающая, какие роли установлены на сервере. Команды в этом разделе позволяют добавлять или удалять роли или перейти в более подробную консоль, через которую можно управлять отдельной ролью.
Раздел сводки по компонентам предоставляет таблицу, указывающую, какие компоненты установлены на сервере. Как и ожидалось, что здесь можно добавлять и удалять компоненты.
Наконец, в разделе материалов и поддержки указывается, принимает ли сервер участие в программе повышения удобства работы заказчика и отчетах об ошибках Windows, а также позволяет настроить участие сервера в программах обратной связи. Здесь также можно быстро обнаружить дополнительные разделы по справке и исследованиям, доступные в технических центрах TechCenter и технических библиотеках Windows Server.

Сведения о ролях
Каждая установленная роль имеет собственную главную страницу внутри диспетчера серверов. Для каждой из этих главных страниц ролей раздел материалов и поддержки предлагает меню из рекомендованных настроек или случаев, в которых работает эта роль или части роли. Каждая рекомендованная настройка связана с контрольным списком справки, проводящим пользователя через задачи, которые необходимо выполнить для обеспечения наибольшего удобства работы для данной роли.
Особенно удобной стороной диспетчера серверов является то, что он поднимает наверх важную информацию и команды, помещая их прямо там, где они нужны пользователю. Если, например, пользователь просматривает главную страницу роли файловых служб, он может немедленно увидеть любые события, относящиеся к этой роли; ему не нужно запускать для этого средство просмотра событий и строить фильтр.
Однако, некоторые роли могут создавать сотни событий, так что у пользователя также есть возможность создавать собственные фильтры прямо с главной страницы роли. Он можно выбрать «Фильтровать события» в боковом меню и еще более сузить категории отображаемых событий. Данный диалог не предоставляет всех возможностей фильтрации, доступных в средстве просмотра событий, но он позволяет быстро сосредоточить внимание только на событиях, относящихся к данной конкретной роли, не утруждая себя фильтрацией прочих.
Аналогично, имеется возможность увидеть состояние системных служб (службы, требуемые данной ролью, но являющиеся частью общей системы) и служб ролей (службы, относящиеся к данной конкретной роли). Для некоторых служб можно выбирать, какие части роли доступны ,и устанавливать различные наборы служб ролей. Прямо с главной страницы роли можно запускать и останавливать службы, а также указывать, какие службы следует отслеживать как системные для данной роли.

Работа с мастерами
Основательно разработанный мастер может сэкономить время пользователя и помочь ему в предотвращении ошибок, особенно при работе с задачами, выполняемыми лишь время от времени. В предыдущих версиях Windows Server для изменения установленных на сервере компонентов требовалось использовать мастера управления данным сервером, настройки данного сервера и добавления или удаления компонентов Windows. Проверки зависимости были ограничены, и мастер добавления или удаления компонентов Windows требовал завершения установки одной роли перед добавлением следующей.
Теперь использование мастеров диспетчера ролей позволяет устанавливать или удалять по нескольку ролей, служб ролей и компонентов за один сеанс. Но, что более важно, в ходе работы с мастерами диспетчера серверов выполняются проверки зависимости, обеспечивающие установку всех необходимых ролей и служб ролей. И роли устанавливаются с рекомендованными параметрами безопасности по умолчанию – впрочем, их можно изменить, используя мастер настройки безопасности. Единственного сеанса одного из мастеров диспетчера серверов реально достаточно, чтобы полностью подготовить сервер к развертыванию.
В диспетчере серверов имеется набор мастеров, в том числе мастера добавления ролей, добавления служб ролей, добавления компонентов, удаления ролей, удаления служб ролей и удаления компонентов.
Мастер добавления ролей, который, как несложно догадаться, используется для добавления ролей к серверу, автоматически проверяет зависимости между ролями и убеждается в том, что установлены все роли, а также службы ролей, требуемые для работы каждой выбранной роли. Для некоторых ролей, таких как службы терминалов и службы сертификации Active Directory, мастер добавления ролей также предоставляет страницы настройки, позволяющие пользователю указать желаемую настройку роли в процессе установки. Рис. 3 демонстрирует страницу выбора ролей сервера мастера добавления ролей.
Рис. 3 Использование мастера добавления ролей для выбора ролей сервера
Рис. 3 Использование мастера добавления ролей для выбора ролей сервера
Большинство ролей состоят из нескольких элементов, которые диспетчер серверов именует службами ролей. После установки сложной роли можно использовать мастер добавления служб роли для добавления к ней служб.
Подобно мастеру добавления ролей, мастер добавления компонентов позволяет устанавливать компоненты. За один сеанс можно добавить один или несколько компонентов.
Мастер удаления ролей, согласно своему названию, позволяет удалять роли с сервера. Мастер автоматически проверяет зависимости, чтобы убедиться, что роли или службы ролей, необходимые другим ролям не удалены и остаются установленными. Также можно удалять службы ролей из установленной роли, используя мастер удаления служб ролей. В то же время мастер удаления компонентов позволяет удалять компоненты системы.

Командная строка
Порой я встречаю специалистов по ИТ, которые просто ненавидят мастера. Хотя лишь немногие испытывают настолько бурные чувства, многие специалисты по ИТ любят иметь возможность использования командной строки. Это может быть более удобным, поскольку делает возможным простую повторяемость и использование сценариев. Диспетчер серверов предоставляет средство командной строки ServerManagerCmd.exe, которое заметно проще в использовании, чем прежние средства ocsetup и pkgmgr. ServerManagerCmd.exe можно использовать для установки и удаления ролей, служб ролей и компонентов. Также можно использовать простые параметры для отображения списка всех ролей, служб ролей и компонентов – включая как установленные, так и доступные для установки.
Эта командная строка дает возможность выполнять автоматическую установку и удаление ролей, служб ролей и компонентов, что весьма удобно. Командную строку можно использовать для установки или удаления единственной роли, службы ролей или компонента в экземпляре команды; либо можно использовать файл ответов XML при помощи команды диспетчера серверов для установки или удаления нескольких ролей, служб ролей и компонентов единственным экземпляром команды. Также можно просматривать журналы и запускать запросы для отображения списков ролей, служб ролей и компонентов, включая как уже установленные, так и доступные для установки.
Изюминкой этого средства командной строки является параметр whatif, позволяющий увидеть какие именно изменения будут внесены в сервер установкой указанной роли. Например, на рис. 4 показаны результаты запуска следующей команды:
ServerManagerCmd -install Web-Server
-allsubfeatures -whatif
Само собой, эти выходные данные можно сохранить в файл для дальнейшего анализа.
Рис. 4 Использование параметра whatif для просмотра изменений, которые были бы внесены в сервер
Рис. 4 Использование параметра whatif для просмотра изменений, которые были бы внесены в сервер
Более углубленное рассмотрение деталей и синтаксиса ServerManagerCmd.exe имеется в документе "Server Manager Technical Overview Appendix" («Приложении к техническому обзору диспетчера серверов») по адресу go.microsoft.com/fwlink/?LinkId=107113.
Я хотел бы поблагодарить Гэби Каплан (Gaby Kaplan) за ее вклад в эту статью.

Байрон Хайнз (Byron Hynes) – специалист по разработке стратегий в области корпоративных технологий в группе по работе с партнерами и корпоративными клиентами корпорации Майкрософт. Ранее он работал в отделе Windows Server в качестве консультанта и инструктора. Связаться с ним можно по адресу bhynes@microsoft.com.


 Специальный репортаж: Windows Server 2008: Развертывание Windows Server 2008 с помощью System Center
Специальный репортаж: Windows Server 2008 Тим Минтер (Tim Mintner)

Развертывание Windows Server 2008 с помощью System Center
Краткий обзор:
  • Возможности развертывания, предлагаемые диспетчером конфигураций
  • Создание и настройка последовательности задач сервера
  • Добавление ролей сервера
  • Установка переменных, относящихся к отдельным компьютерам.

С выпуском System Center Configuration Manager 2007, администраторы серверов могут воспользоваться теми же средствами развертывания операционных систем, которые были у администраторов клиентов
уже в течение нескольких лет. В свое время, администраторам серверов часто приходилось выполнять ручную установку Windows Server®, используя компакт-диски или DVD, а затем часами занимаясь настройкой сервера. Некоторые администраторы брали на себя труд создания автоматических процедур установки, используя файлы unattend.txt и, возможно, службы удаленной установки (RIS) для автоматизации процесса установки и устранения необходимости физически присутствовать за консолью сервера. Те, кто занимался этим углубленно, пользовались службами автоматического развертывания для Windows Server 2003, чтобы полностью автоматизировать весь процесс создания сервера. Теперь, благодаря Windows Server 2008, процесс установки для серверов существенно изменен впервые с момента появления Windows NT® 4.0.
Развертывание Windows Server 2008 использует те же базовые средства и технологии развертывания, что и Windows Vista®. В силу этого, средства, которыми администраторы серверов пользовались в прошлом, будет необходимо обновить или заменить. RIS заменен на службы развертывания Windows® (Windows Deployment Services – WDS), а ADS не поддерживает развертывание Windows Server 2008. Дополнительную информацию о технологиях и средствах, изменившихся вместе с развертыванием сервера и клиента можно найти в статье "10 Things You Need to Know about Deploying Windows Vista" («10 вещей, которые надо знать о развертывании Windows Vista» на technetmagazine.com/ issues/2006/11/Deployment.
Поскольку базовые технологии развертывания Windows Server 2008 и Windows Vista одинаковы, было бы удобно использовать одинаковые средства и знания для развертывания обеих ОС, не так ли? Диспетчер конфигураций System Center Configuration Manager и Microsoft® Deployment теперь предоставляют такой интегрированный набор средств. В этой статье описано, как можно использовать диспетчер конфигураций вместе с Microsoft Deployment, чтобы приступить к развертыванию Windows Server 2008.

Развертывание операционных систем с помощью Configuration Manager
Прежде чем приступать к развертыванию Windows Server 2008, давайте рассмотрим возможности диспетчера конфигураций, связанные с развертыванием операционных систем. При запуске консоли диспетчера конфигураций и открытии окна управления компьютером, можно заметить новую зону для развертывания операционной системы, как показано на рис. 1.
Рис. 1 Страница развертывания операционной системы
Рис. 1 Страница развертывания операционной системы
На этой странице можно просмотреть краткую сводку развертываний операционных систем, происходивших в данной среде, и с нее можно перейти на другие узлы развертывания операционных систем, такие как управление последовательностями задач и управление образами загрузки. Там можно найти и список веб-отчетов для просмотра состояния развертываний и работоспособности среды развертываний. Также имеется краткая справочная ссылка под «Ресурсами», которая ведет к справочной документации для развертывания операционных систем.
Если заглянуть под узлы в область навигации, то можно найти все элементы, которые необходимо настраивать для выполнения развертывания ОС. Вот список этих элементов.
Образы загрузки Содержит список образов загрузки, основанный на Windows PE 2.0, который будет использован в процессе развертывания.
Сопоставления компьютеров Используется в первую очередь при развертывании клиентов для сопоставления существующего компьютера с новой машиной, чтобы дать возможность безопасного управления состоянием пользователя. Также содержит мастер для импорта неизвестных учетных записей компьютеров в базу данных диспетчера конфигураций, делая возможным развертывание серверов с нуля на чистый компьютер.
Образы операционной системы. Содержит список пакетов, содержащих индивидуализированные изображения в формате образов Windows (WIM) для серверного и клиентского развертывания.
Пакеты установки операционной системы Содержит пакеты, в которых находится полный набор исходных файлов для развертывания операционной системы, таких как исходные файлы для Windows Server 2008.
Последовательности задач Содержит несколько этапов, каждый их которых определяет действия командной строки, которые будут запущены без взаимодействия с пользователем. Последовательности задач являются двигателем процесса развертывания операционной системы и могут предоставить все необходимые действия по развертыванию и настройке операционной системы.
Драйверы Центральный репозиторий для управления всеми драйверами, необходимыми различным моделям серверных и клиентских компьютеров.
Пакеты драйверов Содержит один или более набор драйверов, которые могут быть переданы точкам распределения диспетчера конфигураций и используются в ходе развертывания серверных или клиентских компьютеров.
Теперь, когда возможности развертывания операционных систем с помощью диспетчера конфигураций понятны, давайте сведем воедино все, что необходимо для развертывания Windows Server 2008.

Подготовка к развертыванию Windows Server 2008
Что такое Microsoft Deployment?
Microsoft Deployment – это следующая версия средства Business Desktop Deployment (BDD) 2007. Она соединяет средства и процедуры, необходимые как для настольного, так и для серверного развертывания в общую консоль развертывания и собрание руководств. Данный продукт добавляет новые возможности про развертыванию и созданию последовательностей задач, для настольных систем и серверов, использующих диспетчер конфигураций System Center Configuration Manager 2007.
Средство Microsoft Deployment доступно в Центре загрузки Майкрософт, а руководства для него присутствуют в сети, в технических центрах TechCenters, по развертыванию настольных систем и серверов на Microsoft TechNet. Дополнительные сведения, а также ссылки на вышеупомянутые загрузки и другие материалы по этой теме, можно найти на microsoft.com/deployment.

Для развертывания Windows Server 2008 с помощью диспетчера конфигураций необходимы следующие элементы.
Набор средств развертывания Microsoft Deployment Toolkit (MDT) Предоставляет средства и рекомендации для развертывания серверных и клиентских операционных систем. Интегрируется напрямую с консолью диспетчера конфигураций, для упрощения процесса развертывания. Загрузить Microsoft Deployment Toolkit можно по адресу microsoft.com/deployment.
Настраиваемый образ загрузки Диспетчер конфигураций предоставляет 32-битные и 64-битные образы загрузки, основанные на Windows PE 2.0 и включает поддержку VBScript, инструментария управления Windows (WMI), а также приложений HTML (HTA). Однако, если необходимо, чтобы процесс развертывания запрашивал информацию от отдельной базы данных SQL Server®, то для этого нужен настраиваемый образ загрузки с поддержкой ADO.
Пакет установки операционной системы Содержит исходные файлы с DVD Windows Server 2008.
Пакет MDT Содержит все сценарии и поддерживающие файлы, необходимые для работы набора средств развертывания Microsoft Deployment Toolkit.
Клиентский пакет диспетчера конфигураций Содержит файлы установки для клиента диспетчера конфигураций.
Пакет параметров Содержит файл unattend.xml, используемый для автоматической установки Windows Server 2008, а также файл customsettings.ini, используемый вместе с набором средств развертывания Microsoft Deployment Toolkit.
Пакет Sysprep Используется только при развертывании Windows Server 2003 или Windows XP и предоставляет файлы sysprep, необходимые для подготовки компьютера к созданию образа операционной системы.
Драйверы Содержит все драйверы, необходимые для конкретных моделей серверов.
Общие сетевые ресурсы для источников пакета и записанных файлов WIM Местоположения в формате UNC, где будут храниться вышеперечисленные пакеты, вместе с модифицированным образом WIM.
Может показаться, что для создания всех этих пакетов необходимо много работы. Но у меня есть хорошая новость: с помощью набора средств развертывания Microsoft Deployment Toolkit, один-единственный мастер может создать их все.
Чтобы использовать Microsoft Deployment Toolkit с диспетчером конфигураций, необходимо установить его на том же компьютере, что и консоль управления диспетчера конфигураций. После того, как это сделано, перейдите на «Пуск» | «Программы» | Microsoft Deployment Toolkit, выберите настройку интеграции диспетчера конфигураций и укажите имя своего сервера узла диспетчера конфигураций, а также код узла и нажмите кнопку «Далее». Это добавляет к консоли диспетчера конфигураций разрешения, предоставляемые набором средств развертывания Microsoft Deployment Toolkit. Теперь при запуске консоли диспетчера конфигураций и правом щелчке на «Последовательности задач» можно будет увидеть новую возможность, как показано на рис. 2.
Рис. 2 Импорт последовательности задач Microsoft Deployment
Рис. 2 Импорт последовательности задач Microsoft Deployment
Выберите импорт последовательности задач Microsoft Deployment и выполните указанные ниже действия для создания необходимых пакетов и последовательности задач Windows Server 2008:
  1. На экране выбора шаблона выберите «Последовательность задач сервера» и нажмите кнопку «Далее».
  2. Предоставьте имя последовательности задач, а также комментарии, описывающие последовательность задач и нажмите кнопку «Далее».
  3. Введите информацию, необходимую для присоединения к домену или рабочей группе, включая учетные данные пользователя для присоединения сервера к домену. Введите также информацию о организации и ключ продукта и предоставьте путь UNC и имя файла для настраиваемого образа WIM, который будет создан. Предоставьте учетные данные пользования для подключения к общему сетевому ресурсу, где будет храниться файл WIM и нажмите кнопку «Далее».
  4. На экране образа загрузки выберите создание нового образа загрузки, предоставьте точку в сети, которую следует исполнить как исходный каталог пакета для пакета образа загрузки и нажмите кнопку «Далее».
  5. Предоставьте имя пакета, информацию о версии и комментарии для пакета образа загрузки и нажмите кнопку «Далее».
  6. Выберите платформу (x86 или x64), поддержку ADO, дополнительные шрифты, если они требуются, специальный фон для образа загрузки, если он необходим, а также дополнительные папки, которые стоит включить в образ Windows PE и нажмите кнопку «Далее».
  7. На экране пакета Microsoft Deployment Toolkit выберите создание нового пакета файлов Microsoft Deployment Toolkit, предоставьте путь UNC для использования в качестве источника пакета и нажмите кнопку «Далее».
  8. Предоставьте имя, версию, производителя и комментарии для пакета Microsoft Deployment Toolkit и нажмите кнопку «Далее».
  9. Для образа ОС выберите создание нового пакета установки ОС, предоставьте путь к исходным файлам Windows Server 2008 и местонахождение UNC для использования в качестве каталога источника пакета, после чего нажмите кнопку «Далее».
  10. Для клиентского пакета выберите создание нового клиентского пакета диспетчера конфигураций и нажмите кнопку «Далее».
  11. Для пакета параметров выберите создание нового пакета параметров, предоставьте местонахождение UNC для использования в качестве источника пакета параметров и нажмите кнопку «Далее».
  12. Для пакета Sysprep выберите «Файлы Sysprep не требуются» и нажмите кнопку «Далее».
Теперь мастер создаст образ загрузки и все пакеты. Если развернуть «Пакеты», «Образы загрузки», «Пакеты установки операционной системы» и «Последовательности задач», можно будет увидеть все пакеты и последовательность задач, которые были созданы. После создания всех пакетов их следует развернуть на точках распространения.
В дополнение к этим пакетам часто будет необходимо добавлять драйверы для конкретного серверного оборудования. Это делается путем добавления драйверов к хранилищу драйверов диспетчера конфигураций и создания пакета драйверов, который будет использован в ходе развертывания.
Для импорта драйверов в каталог драйверов и создания пакета драйверов, перейдите в консоль диспетчера конфигураций, щелкните правой кнопкой мыши «Драйверы» и выберите «Импорт». Выберите импорт всех драйверов в указанном пути UNC, затем введите путь UNC, содержащий все драйверы, собранные для конкретных моделей серверов. По завершении этого, нажмите кнопку «Далее».
На странице сведений о драйверах выберите, какие файлы INF необходимо импортировать и, при желании, определите драйверы в какую-либо категорию. (Категория может быть основана на определенном типе модели сервера.) Нажмите кнопку «Далее», а затем, на странице добавления драйверов к пакету, выберите «Новый пакет». Укажите имя, комментарий и путь UNC, который будет использоваться как источник для пакета драйвера и нажмите кнопку ОК. Выберите обновление точек распределения после завершения и нажмите кнопку «Далее».
На странице добавления драйвера к образу загрузки, выберите ранее созданный образ загрузки и выставьте флажок «Обновить точки распределения после завершения». Нажмите кнопку «Далее», затем на странице сводки нажмите кнопку «Далее» снова, чтобы завершить работу мастера, импортировать драйверы и создать пакет драйверов.

Редактирование последовательности задач
Теперь, когда создание всех необходимых пакетов и последовательность задач для установки Windows Server 2008 завершены, большинство пользователей, вероятно, пожелает изменить некоторые из действий в последовательности задач по умолчанию. Чтобы изменить последовательность задач, щелкните ее правой кнопкой мыши и выберите «Редактировать». Отобразится шаблон последовательности задач сервера развертывания Microsoft Deployment Server, как показано на рис. 3.
Рис. 3 Возможно изменение последовательности задач по умолчанию
Рис. 3 Возможно изменение последовательности задач по умолчанию
На высшем уровне последовательность задач – это серия элементов командной строки, известных как задачи, каждая из которых выполняет определенные операции. Каждая задача может иметь определенные свойства, которые могут быть настроены и может также обладать условиями, установленными на вкладке параметров, определяющими, следует ли выполнять определенные задачи. Например, условия первой задачи в последовательности задач установлены, как показано на Рис. 4.
Рис. 4 На вкладке «Параметры» можно отключить задачу или установить условия для нее
Рис. 4 На вкладке «Параметры» можно отключить задачу или установить условия для нее
В данном примере задача отключена по умолчанию, поскольку выставлен флажок "Пропустить данный этап". Если бы задача была включена, она бы выполнялась лишь на условиях, указанных в настоящий момент.
Некоторые из более распространенных задач, изменение которых может потребоваться перед развертыванием Windows Server 2008, включают форматирование и разделение диска, проверку, применение образа операционной системы и применение параметров сети.
Задача форматирования и разделение диска позволяет определить, какой должна быть структура разделения диска для серверных развертываний. При установках по умолчанию создается один раздел, использующий все пространство на первом диске. Развертывание серверов в этой конфигурации может быть нежелательным, так что можно изменить эти установки, указывая схему разметки диска, которую следует использовать.
Задача проверки позволяет удостовериться в соответствии некоторым из базовых требований, таким как память и скорость процессора. Если, для примера, стандартом компании для серверных развертываний являются 2 ГБ памяти, это можно установить как требование и при несоответствии ему установка не состоится.
Задача применения образа операционной системы позволяет настраивать конкретный образ, который следует развернуть. Например, при использовании исходных файлов для Windows Server 2008, имеется возможность развернуть Server Standard, Server Enterprise, Server Datacenter, Server Standard Core, Server Enterprise Core и Server Datacenter Core. Пользователю необходимо выбрать нужный образ, а это зависит от того, какую версию Windows Server 2008 он хочет развернуть.
Задача применения параметров сети позволяет настраивать статические IP-адреса для сетевых карт, а также менять параметры для присоединения к домену или рабочей группе. Хотя с помощью этой задачи и можно установить статический IP-адрес, это сделает данную последовательность задач работающей лишь на одном сервере. Ниже показано, как устанавливать статические IP-адреса с помощью переменных, что позволяет использовать единственную последовательность задач для нескольких серверов.

Установка и настройка ролей сервера
К этому моменту я уже показал, как можно изменить последовательность задач для настройки элементов, относящихся к установке операционной системы. Однако набор средств развертывания Microsoft Deployment Toolkit дает также и возможность устанавливать и настраивать роли сервера. Например, пользователь может настроить последовательность задач для развертывания Windows Server 2008 на сервере филиала, где будут работать лишь контроллер домена только для чтения и файловый сервер.
Чтобы успешно выполнить это, перейдите к задаче установки программного обеспечения в редакторе последовательностей задач и выберите Add («Добавить») | MDT | Install Roles and Features («Установка ролей и компонентов»). Затем, в свежесозданной задаче установки ролей и компонентов, отметьте контроллер домена Active Directory и файловый сервер, как показано на рис. 5.
Рис. 5 Установка ролей и компонентов
Рис. 5 Установка ролей и компонентов
Теперь необходимо настроить параметры для контроллера домена только для чтения. В редакторе последовательности задач выберите Add («Добавить») | MDT | Configure ADDS («Настроить ADDS»). В свежесозданной задаче Configure ADDS выберите создание новой реплики контроллера домена только для чтения и укажите значения для следующих свойств.
  • Имя DNS существующего домена
  • Контроллер домена источника репликации
  • Учетная запись
  • Пароль восстановления (безопасного режима)

Работа с переменными
Важно осознать, что одна из наиболее широких возможностей, предоставляемых пользователям последовательностями задач – это возможность устанавливать, в ходе развертывания, почти любое свойство в последовательности задач динамически, как переменную. Как диспетчер задач, так и Microsoft Deployment предоставляют несколько механизмов для установки и использования переменных.
Диспетчера задач позволяет устанавливать переменные как переменные Computer («Компьютер»), переменные Collection («Коллекции») или напрямую внутри последовательности задач. Microsoft Deployment позволяет устанавливать переменные через файл customsettings.ini, серверную базу данных или веб-службу. Список переменных, которые могут быть установлены, можно найти на technet.microsoft.com/bb632442.aspx.
Давайте используем пример установки статичного IP-адреса на определенном сервере. Ранее в статье было показано, что статичный IP-адрес можно установить напрямую внутри последовательности задач, в задаче применения параметров сети. Однако это решение не идеально, поскольку делает данную последовательность задач полезной только для определенного сервера.
Вместо этого стоит оставить последовательность задач в покое и установить IP-адресе через переменную. Ниже приведен пошаговый процесс установки статичного IP-адреса как переменной Computer («Компьютер»):
  1. В консоли диспетчера задач, перейдите на System Center Configuration Manager («Диспетчер задач System Center») | Site Database («База данных веб-узла») | Computer Management («Управление компьютерами») | Collections («Коллекции»).
  2. Чтобы назначить компьютеру индивидуальную переменную, найдите и разверните коллекцию, к которой принадлежит компьютер, щелкните компьютер правой кнопкой мыши, щелкните «Свойства» и затем вкладку переменных.
  3. Для указания настроенных пользователем переменных и связанных с ними значений щелкните значок «Создать», чтобы открыть диалоговое окно <New> Variable (<Новая> переменная»).
  4. В этом диалоговом окне необходимо указать имя для переменной и будет ли это имя видимо в консоли диспетчера конфигураций Configuration Manager 2007. Для статического IP-адреса следует добавить следующие переменные:
  • OSDAdapter0IPAddressList
  • OSDAdapter0SubnetMask
  • OSDAdapter0Gateways
  • OSDAdapter0DNSServerList
Настроенные переменные должны напоминать показанные на рис. 6.
Рис. 6 Использование переменных компьютера для установки статического IP-адреса
Рис. 6 Использование переменных компьютера для установки статического IP-адреса

Развертывание последовательности задач
Теперь, когда последовательность задач полностью настроена а переменные установлены, можно приступать к развертыванию Windows Server 2008. Диспетчер конфигураций предлагает несколько механизмов развертывания операционной системы, таких как среда предзагрузочного выполнения (PXE), загружаемые последовательностью задач носители, независимые носители, а также стандартные объявления для существующих машин.
Чтобы упростить понимание, я обрисую, как создать последовательность задач для загружаемого носителя. В консоли менеджера конфигураций перейдите к окну последовательности задач, затем выберите «Создать носитель последовательности задач» из меню действий. На странице выбора типа носителя выберите загружаемый носитель и нажмите кнопку «Далее». На странице типа носителя укажите компакт-диск в качестве типа и имя для медиа-файла. На странице безопасности можно указать пароль для защиты носителя или самоподписывающийся сертфикат. После этого указывается образ загрузки. После завершения этого пользователь окажется на странице подтверждения, где ему следует нажать «Готово». Подробные инструкции по развертыванию с помощью этого и других механизмов приведены в документации по адресу technet.microsoft.com/bb681029.aspx.

Заключение
В этой статье было показано, как использовать диспетчер конфигураций System Center и набор средств развертывания Microsoft Deployment для развертывания Windows Server 2008, добавления таких ролей, как файловый сервер и контроллер домена, установки относящихся к определенному компьютеру переменных и развертывания операционной системы с помощью загружаемых последовательностью задач носителей. Хотя на практике развертывание серверов может быть куда более сложным, данная статья может помочь в начале объединения средств развертывания серверов и клиентов.

Тим Минтер (Tim Mintner) работает старшим разработчиком программного обеспечения в группе Microsoft Solutions Accelerator, специализируясь на наборе средств развертывания Microsoft Deployment Toolkit. Он обладает более чем 14 годами опыта работы с клиентами по развертыванию операционных систем Майкрософт. С Тимом можно связаться по адресу tmintner@microsoft.com.


 Специальный репортаж: Windows Server 2008: Аудит и соответствие нормативным требованиям в Windows Server 2008
Специальный репортаж: Windows Server 2008 Джоэл Йокер и Роб Кэмпбелл (Rob Campbell, Joel Yoker)

Аудит и соответствие нормативным требованиям в Windows Server 2008
Краткий обзор:
  • Возрастающее значение соответствия нормативным требованиям
  • Ознакомление с изменениями в своей среде.
  • Проблемы и задачи аудита событий безопасности
  • Технические аспекты аудита

В мире информационных технологий изменение непрерывно. От типичной организации ИТ все в большей степени требуется знать изменения, происходящие в ее среде. Вместе с размером и сложностью информационных сред возрастает негативное воздействие
административных ошибок и случайного раскрытия данных. Современное общество требует ответственности за такие случаи, и в силу этого организации теперь несут юридическую ответственность за безопасность хранимой у них информации.
Как следствие, стал важным аудит изменений в среде. Почему? Аудит предоставляет средства определения сути изменений и управления ими в современных крупных и высокораспределенных информационных средах. В этой статье мы рассмотрим обычные задачи, с которыми сталкивается большинство организаций, сферу соответствия нормативным и регулятивным требованиям в информационных технологиях, основы аудита в Windows®, а также то, как функции Windows Server® 2008 и служб Audit Collection Services (ACS) в Microsoft® System Center Operations Manager 2007 могут дополнить всеохватывающую стратегию аудита.

Задачи аудита
Быстрый взгляд на заголовки новостей показывает, что раскрытие данных становится повседневной проблемой. Многие из подобных случаев ведут к судебным разбирательствам, финансовым потерям и ущербу для репутации ответственных за них организаций. Способность объяснять, какие изменения произошли, или быстро определять проблемы является ключевой для снижения ущерба от случаев раскрытия данных.
Для примера, предположим, что некая организация ответственна за управление личными сведениями (personally identifiable information – PII) для определенной клиентской базы. Хотя и существует множество способов защитить информацию, хранящуюся на управляемых системах, нарушение безопасности все же возможно. Адекватный аудит позволяет организации знать, безопасность каких именно систем была нарушена и, возможно, какие данные были утеряны. Без аудита последствия потери данных могут быть намного выше, в первую очередь потому, что невозможно будет определить ее пределы.
Так почему же организации ИТ не применяют его уже сейчас? Факт в том, что в большинстве организаций не полностью разбираются в технических аспектах аудита. Хотя старшие руководящие сотрудники обычно понимают такие концепции, как резервное копирование и восстановление, сложность, неизбежно присущая аудиту изменений в среде, делает его таким новшеством, которое сложно довести до других. Как следствие, вопросы об аудите часто возникают только после серьезных происшествий. Например, базовый аудит может быть включен, но если система из-за пробела в планировании не настроена проводить аудит определенного изменения, то информация о нем не будет собрана.
Кроме того, аудит событий безопасности связан с несколькими неизбежными проблемами, с которыми приходиться разбираться специалистам по ИТ. Одна из таких сложностей – это распределение систем внутри современных крупных компьютерных сред, которая связана с непростыми задачами в области сбора и объединении данных, поскольку изменение может произойти на любой системе или наборе систем в любой момент. Это ведет к следующей сложной задаче – корреляции. Преобразование взаимоотношений между событиями на одной системе и нескольких системах часто необходимо, чтобы передать истинный смысл происходящего.
Еще одна проблема состоит в том, что аудит обычно выходит за рамки обычных организационных границ. Различные структуры организаций или групп существуют по различным причинам и их не всегда просто связать. Многие организации имеют рабочую группу служб каталога, группу инфраструктуры обмена сообщениями и группу настольных систем, но, вероятно, лишь одну группу безопасности, отвечающую за эти области. Более того, подготовленных специалистов в области безопасности может физически не быть во всех местах, где они нужны. Например, офисы филиалов часто полагаются на единственного сотрудника или маленькую группу для выполнения всех задач, включая управление журналом событий безопасности.
Наконец, количество событий может само по себе составить сложности. Подвергающиеся аудиту события безопасности происходят в гораздо больших объемах, чем прочие типы ведения журнала событий. Число собираемых событий делает непростым эффективное сохранение и просмотр журналов. Более того, текущие и предлагаемые нормативы, устанавливая условия хранения информации, не облегчают эту ношу в современных вычислительных инфраструктурах.
В прошлом аудит доступа к информации можно было кратко выразить как желание знать и попытку обезопасить. Теперь, по мере того как организации и их старшие руководящие сотрудники становятся ответственными перед законом за потерю информации или отсутствие надлежащих мер безопасности, для администраторов отделов ИТ крайне важно ознакомиться с нормативами, которые могут быть применимы к их средам. Для корпораций международного уровня задачи еще более сложны, поскольку каждая страна имеет свои нормативы, касающиеся информации и ее защиты. Некоторые примеры законодательных предписаний и норм перечислены на рис. 1 вместе со связанными с ними требованиями к организациям ИТ.
Figure 1 Правовые нормы и что они означают для специалистов ИТ (Close Figure 1)

Правовая норма | Ожидания
Закон Сарбейнса-Оксли, 2002 г. (SOX) | Раздел 404 признает роль информационных систем и требует от компаний, акции которых обращаются на рынке, предоставлять ежегодный обзор их внутреннего управления финансовой отчетностью.
Закон об отчетности в области медицинского страхования (HIPAA), 1996 г. | Затрагивает вопросы безопасности и конфиденциальности данных о здоровье; «Правило безопасности» охватывает административные, физические и технические меры защиты таких данных.
Электронное обнаружение (eDiscovery) | Определяет стандарты хранения документов и доступа к ним, включая ответственность за то, кто и как получает доступ к документам.
Федеральный закон об обеспечении безопасности информации (FISMA), 2002 г. | Федеральный мандат на предоставление исчерпывающей среды информационной безопасности (INFOSEC) для систем правительства США, координации с различными правоохранительными органами, установки систем контроля, признание коммерческих продуктов и программных возможностей. Раздел 3544 охватывает ответственность агентств, включающую контроль за ИТ.
Федеральные стандарты обработки информации (FIPS), выпуск 200 | Определяет минимальные требования к безопасности информации для федеральной информации и информационных систем и очерчивает область использования рекомендаций, содержащихся в специальном выпуске (SP) NIST 800-53. В NIST SP800-53 раздел AU-2 (Подлежащие аудиту события) указывает, что информационные системы должны предоставлять возможность компиляции записей аудита с нескольких компонентов в единый, охватывающий всю систему, коррелированный по времени аудиторский след; возможность управления подвергшихся аудиту событий отдельными компонентами; а также обеспечивать регулярную проверку подлежащих аудиту событий организацией.
Что же делать специалисту по ИТ, учитывая все это юридическое давление? Ответственным лицам и техническим специалистам отделов ИТ необходимо создавать ясное и краткое изложение событий, которое можно будет предъявить как внутри, так и за пределами организации. Сюда входит разработка адекватной стратегии аудита, что требует профилактических мер и вложений. Ключевая мысль здесь в том, что аудит не может быть второстепенной областью при разработке, каковой он слишком часто является.
Подобные информационно-технические задачи обычно могут быть разрешены сочетанием сотрудников, процессов и технологий. Что касается аудита, это в первую очередь процедура, что существенно. Следовательно, первым шагом должно стать освоение основ, позволяющее отвечать на запросы и требования своей организации в плане соблюдения нормативных требований. Сначала мы раскроем некоторые из основ аудита в Windows, а затем углубимся в изменения в Windows Server 2008 и Windows Vista®.

Аудит событий безопасности
Все подвергшиеся аудиту события записываются в журнале событий безопасности Windows. Эти события обычно не требуют немедленных действий и часто являются информационными по природе. Каждое событие записывает успешное выполнение или сбой аудита для определенного типа произошедшего доступа. Это отличается от журналов событий приложений или системы, где проблемы можно определить через цветовое кодирование (подсказка: ищите «красные» события, чтобы найти проблему).
Журнал событий безопасности отличается тем, что подвергшиеся аудиту события часто скрыты своим объемом и, как уже было замечено выше, коррелирование данных о безопасности может стать непростой задачей. Даже простое нарушение данных на единственной системе представляет проблему. Потребуется анализ журнала событий безопасности, чтобы определить, какие учетные записи использовались для доступа к каким данным и администратору придется перебирать журнал, чтобы найти нужную учетную запись. Увы, серьезные атаки в наше время часто бывают скоординированными и распределенными, весьма затрудняя для жертвы анализ такого рода.
Учитывая это, важно разбираться в ключевых элементах, делающих возможной запись информации в журнале событий безопасности в Windows: политике аудита и системных списках управления доступом (SACL). Политики аудита настраиваются на локальных машинах через групповую политику или локальную политику безопасности и определяют сбор событий успеха или сбоя для определенных типов доступа. В Windows уже много лет представлены следующие основные категории политик аудита (ниже будет подробнее рассказано о новой политике детализированного аудита в Windows Server 2008):
  • Аудит событий входа в систему под учетными записями
  • Аудит управления учетными записями
  • Аудит доступа к службе каталога
  • Аудит событий входа в систему
  • Аудит доступа к объектам
  • Аудит изменений политики
  • Аудит использования привилегий
  • Аудит отслеживания процессов
  • Аудит системных событий
Необходимость определения политики аудита и этих связанных с нею категорий обычно осознается большинством организаций, работающих с информационными технологиями, но политика аудита представляет лишь часть решения. Списки SACL также играют важную роль в реализации целостного плана аудита. Две конкретные категории политики аудита – аудит доступа к службе каталога и аудит доступа к объектам – полностью полагаются на списки SACL в плане возвращения информации журналу событий безопасности. Так что такое списки SACL?
Каждый объект, будь это файл, реестр или служба каталога, имеет свой список управления доступом (ACL) с одной или несколькими записями управления доступом (ACE), разделенный на два типа: список управления доступом на уровне пользователей (DACL) и SACL (последний определяет параметры записи попыток доступа к защищенным объектам). Каждая ACE в SACL определяет типы попыток доступа указанным доверенным лицом, которые следует записывать в журнал событий безопасности. ACE определяют запись в журнал успешных и/или сбойных попыток доступа к указанным объектам. На рис. 2 показано использование списка SACL на объекте для создания событий для конкретных типов доступа.
Рис. 2 Использование списка SACL на объекте
Рис. 2 Использование списка SACL на объекте
Знать отношения между политикой аудита и SACL крайне важно, поскольку для фиксации «верных» подвергшихся аудиту событий необходима настройка, относящаяся к изменениям в среде. Как уже упоминалось, политики аудита доступа к службе каталога и аудита доступа к объектам делают возможным создание аудитов в журнале событий безопасности лишь для этих конкретных категорий, но событий создаются, только если у объекта есть запись ACE для аудита, настроенная в его списке SACL. После того, как все эти элементы расставлены по своим местам, локальный центр безопасности Windows (Local Security Authority – LSA) создает события безопасности, и они записываются в журнал событий безопасности.
События состоят из двух различных областей: заголовка, являющегося статическим и заранее определенным для каждого идентификатора события (Event ID), и тела, являющегося изменяемым и содержащим различные детали для различных событий. На Рис. 3 показаны эти два элемента в примере события безопасности Windows Server 2008. Знание этих компонентов событий важно для фазы анализа любого проекта аудита и особенно интересно в отношении возвращения информации в таких средствах, как ACS.
Рис. 3 Заголовок и тело подвергшегося аудиту события
Рис. 3 Заголовок и тело подвергшегося аудиту события

Windows Eventing 6.0
Теперь, когда проблема знакома, можно спросить о том, как Windows Server 2008 помогает организациям решать эти задачи. Windows Server 2008 – первый выпуск серверной ОС, содержащий подсистему событий Windows Eventing 6.0, которая радикально улучшает положение дел в сфере управления событиями безопасности. Отметьте, что хотя в этой статье основное внимание уделено Windows Server 2008, 95% нового набора возможностей также существует в Windows Vista.
Первое, что многие пользователи заметят в Windows Eventing 6.0, – это новый интерфейс пользователя. Новая оснастка средства просмотра событий консоли управления Microsoft (Microsoft Management Console – MMC) предлагает отличную страницу обзора и сводки, гибкие настраиваемые представления и намного улучшенную функцию текста описания. Эти интерфейсы могут помочь конечному пользователю или системному администратору найти информацию о событиях и настроить важные параметры журнала событий прямо из самого средства просмотра.
Ключевой проблемой, часто воздействовавшей на данные безопасности внутри журнала событий, было хранение данных. Ранее подсистема журнала событий (включая все журналы) сталкивалась с ограничениями масштабируемости. При выходе за рамки этих ограничений подсистема в целом переставала записывать события. Однако в Windows Eventing 6.0 это не так, и организации теперь ограничены только объемом доступного пространства на диске. Однако обратите внимание, что очень большие журналы событий могут быть неудобными для анализа, поскольку при фильтрации необходимо оценить каждую отдельную запись, так что размер журнала определенно стоит сохранять в управляемых пределах.
Само собой, это по-прежнему возлагает на администратора ИТ задачу разработки плана архивирования для журналов событий на многих системах. Чтобы помочь в этом на уровне локального сервера, в Windows Eventing 6.0 введена новая функция, а именно возможность «Архивировать журнал при заполнении, не перезаписывать события». В предыдущих версиях Windows эту возможность можно было установить только через прямое изменение значения реестра AutoBackupLogFiles. Это предоставляет механизм для создания локального архива журналов, но не предоставляет решения для управления этими файлами с течением времени, а также не затрагивает проблемы объединения, возникающей при работе с несколькими системами. Службы сбора аудита (Audit Collection Services – ACS) предоставляют законченное решение для этого, которого мы коснемся чуть ниже.
Новый интерфейс – это только начало. Настоящие возможности Windows Eventing 6.0 заключаются в новой службе журнала событий Windows и лежащем в ее основе механизме на базе XML. Эти компоненты и предоставляют улучшенные возможности масштабируемости, доступности и управления. События теперь хранятся в гибком формате XML, делающем возможным нестандартные решения, со встроенной возможностью доступа к этой информации.
Windows Eventing 6.0 также предоставляет возможность связывать административные действия с конкретными событиями. Это достигается путем интеграции службы сбора событий Windows с планировщиком задач для предоставления событий на основе задач. Это новая парадигма для планировщика задач, которые ранее был ограничен запуском событий на основе времени. Мастер «Привязать задачу к событию» (доступный в контекстном меню любого события в обозревателе событий Windows Server 2008) предоставляет простой способ запустить программу, отправить письмо по электронной почте или отобразить сообщение при каждой записи в журнал определенного события. Это может быть очень полезно при попытке определить конкретные действия, происходящие в среде и могущие быть локализованными в определенном событии безопасности. Например, при аудите изменений в разделе реестра "Schema Update Allowed" на контроллерах домена можно создать задачу, отправляющую сообщение электронной почты определенным администраторам безопасности, чтобы уведомить их об изменении данного раздела реестра.
Вдобавок к новой возможности сбора и хранения большого числа записей о событиях, теперь можно лучше контролировать, какие события записываются в журнал. Это достигается через новую возможность, именуемую политикой детализированного аудита (Granular Audit Policy – GAP). В предыдущих версиях Windows девять широких категорий аудита часто приводили к перегрузке событиями. Эти категории верхнего уровня теперь могут контролироваться 50 детализированными подкатегориями, каждая их которых представляет подмножество связанных друг с другом событий.
Это дает возможность отфильтровывать маловажную информацию из журнала событий, не теряя видимости на уровне категории. Например, если на определенной системе необходимо отслеживать только изменения в реестре, но не в файловой системе, раньше можно было выбрать лишь сообщение об успехах или сбоях в категории доступа к объектам. С помощью GAP теперь можно отфильтровывать такие подкатегории, как файловая система, службы сертификации и общий файловый ресурс, сообщая лишь о событиях в подкатегории реестра. Чтобы исследовать подкатегории GAP на системе Windows Server 2008, необходимо выполнить команду Auditpol из командной строки с повышенными полномочиями. Чтобы перечислить все доступные подкатегории GAP, введите следующее:
auditpol /list /subcategory:*
Для получения списка подкатегорий GAP, настроенных на вашей системе, введите следующее:
auditpol /get /category:*
Обратите внимание, что GAP не настраивается через стандартный интерфейс пользователя групповой политики, и им необходимо управлять через auditpol.exe. В статье базы знаний по адресу support.microsoft.com/kb/921469 имеется руководство по развертыванию параметров GAP через групповую политику для систем Windows Server 2008 и Windows Vista.
Windows Server 2008 также может фиксировать как старые, так и новые значения конкретных типов в журнале событий безопасности. В предыдущих версиях Windows подсистема аудита заносила в журнал только имя атрибута объекта Active Directory® или параметр реестра, которые были изменены, но не предыдущее или текущее значения атрибута. Эта новая возможность применима к доменным службам Active Directory, службам Active Directory облегченного доступа к каталогу и реестру Windows. Посредством включения аудита успехов или сбоев на подкатегориях «Реестр» или «Изменения в службе каталогов» и установки связанных списков SACL в журнал событий будут записаны подробные события для действий на этих объектах: Это можно сделать, используя следующие команды auditpol:
auditpol /set /subcategory:"Registry" /success:enable
auditpol /set /subcategory:"Directory Service
    Changes" /success:enable
Для изменений в реестре они появляются как события с идентификатором 4657, что показано на рис. 4.
Рис. 4 До и после изменения в реестре
Рис. 4 До и после изменения в реестре
Эта функция особенно полезна при попытке отследить изменения на объектах Active Directory. Для изменений в службе каталога эти изменения появляются как пара событий с идентификатором 5136, что показано на Рис. 5. В теле каждого события имеются объект, атрибут и операция службы каталога. Для изменений атрибутов с существующими данными можно увидеть две операции: Value Deleted («Значение удалено») и Value Added («Значение добавлено»). Для атрибутов, не содержавших значения, можно увидеть только операцию Value Added при записи данных в этот атрибут. Например, при успешном выполнении операции изменения на атрибуте или объекте пользователя, таком как telephoneNumber, Active Directory записывает в подробных записях журнала предыдущее и текущее значения атрибута.
Рис. 5 До и после события изменения службы каталога
Рис. 5 До и после события изменения службы каталога
Если создан новый объект, то записываются в журнал значения атрибутов, заполненные во время его создания. Если объект перемещен внутри домена, записываются его старое и новое местоположения (в форме различающегося имени). Эта возможность «старое и новое» включается по умолчанию при установке соответствующих параметров политики аудита. Если существует атрибут, который необходимо сохранить закрытым, такой как изменения идентификационного номера сотрудника, то можно специально исключать атрибуты посредством простого изменения в схеме. Если изменить свойство searchFlags атрибута в схеме на 0x100 (значение 256 -NEVER_AUDIT_VALUE), как показано на Рис. 6, событие изменения служб каталога не возникнет в случае изменений в этом атрибуте.
Рис. 6 Исключение атрибута из изменения в службе каталога
Рис. 6 Исключение атрибута из изменения в службе каталога
Наконец, в Windows Eventing 6.0 есть еще одна выдающаяся новая возможность – подписка на события. Как упоминалось ранее, доступ к журналу событий и его просмотр являются ключевыми задачами системного администрирования. Новая возможность подписки на события предоставляет способ пересылать события напрямую между системами. Подписка на события состоит из службы сбора событий и службы источников событий, настроенной на направление событий указанным узлам. Способность получения событий предоставляется службой сбора событий Windows (новой для Windows Eventing 6.0), а функции подписки встроены в службу журнала событий Windows. Службу сбора можно настроить на сбор событий из многих источников, которыми могут быть системы Windows Server 2008 или Windows Vista.
Все данные, собранные из источников событий, находятся в отдельном журнале событий, именуемом «Пересланные события» (ForwardedEvents.evtx) и управляются службой журнала событий на службе сбора. Настройка обеих конечных точек (служб источника и сбора) необходима и может быть автоматизирована (winrm quickconfig –q на источнике; wecutil qc /q на сборщике). Важно отметить, что эта возможность подписки на события не была разработана для предприятий или для замены систем, доставляющих события внешней базе данных.
Один из примеров ситуации, где удобно использовать эту возможность, – небольшая веб-ферма. Предположим, что имеется небольшой набор систем, связанных с определенным веб-узлом (включая веб-серверы и серверы SQL). Эти системы могут консолидировать свою информацию журнала событий безопасности, используя новую функцию подписки на события. Более крупным средам обычно необходим более широкий набор средств консолидации журнала событий.

Службы ACS
Если учесть все новые возможности Windows Server 2008, реальное решение для долгосрочного управления информацией журнала событий безопасности и ее архивации лежит в создании централизованной базы данных информации аудита. Службы ACS (Audit Collection Services) являются центральным компонентом System Center Operations Manager 2007. ACS предоставляют механизм для пересылки, сбора, хранения и анализа данных событий безопасности. События безопасности собираются почти в реальном времени и сохраняются в центральном репозитории SQL. Службы ACS также дают организациям метод предоставления доступа с минимальными полномочиями к информации аудита, поскольку не требуют физического доступа к системам, подвергающимся аудиту. Давайте рассмотрим, как работают службы ACS.
У ACS имеются три основных компонента. В—первых, служба пересылки, являющаяся частью агента диспетчера операций, передающей данные журнала событий от клиента инфраструктуре служб ACS. Служба пересылки передает данные второму компоненту, службе сбора, являющейся прослушивателем на стороне сервера. Службы пересылки ACS подключаются через порт 51909 TCP для безопасного сообщения с назначенной им службой сбора. Перед пересылкой данные журнала событий нормализуются в XML, что значит избавление от лишней информации и сведение информации о событии в размеченные поля, основанные на заголовке конкретного события и информации в его теле. После того, как информация достигает службы сбора, она отсылается третьему и последнему компоненту – базе данных служб ACS. Она становится хранилищем для долговременного хранения информации о событиях безопасности. Сохраненную информацию можно извлекать напрямую через запросы SQL или визуализировать при помощи отчетов HTML, использующих службы отчетов SQL Server®. Службы ACS предоставляют три представления по умолчанию, как показано на Рис. 7.
Figure 7 Представления ACS (Close Figure 7)

Имя представления ACS | Цель
AdtServer.dvHeader | Информация заголовков с собранных событий.
AdtServer.dvAll | Информация заголовков и вся информация тел собранных событий.
AdtServer.dvAll5 | Информация заголовков и первые пять строк информации тел собранных событий.
С точки зрения производительности, единственная служба сбора ACS может обработать максимум 100 000 событий в секунду на пике и 2 500 событий в секунду постоянно. С точки зрения планирования, единственная служба сбора ACS может поддерживать до 150 контроллеров доменов, 3000 серверов доменов или 20 000 рабочих станций, основываясь на параметрах политики аудита по умолчанию. В одном из реально протестированных случаев около 150 контроллеров домена продемонстрировали максимум в примерно 140 событий в секунду с пиковым средним значением 500 000 событий в час. Всего лишь за 14 дней (время сохранения по умолчанию для служб ACS) в базе данных SQL Server было сохранено свыше 150 ГБ данных событий безопасности. Более агрессивная политика аудита и связанная с ней настройки SACL, будут, естественно, создавать еще больше данных (в час, в день и в целом).
Здесь важно осознать, что при таком объеме данных ни один человек никогда не сможет проверить каждое событие в типичной среде крупной корпорации. С другой стороны, организации не должны бояться приведенных здесь чисел. Знание изменений, происходящих в среде, достигается за счет анализа больших объемов данных.
Именно здесь службы ACS и находятся в своей стихии. С помощью служб отчетов SQL Server и ACS можно превратить проблемы, обычно похороненные в журнале событий безопасности, в нечто, опознаваемое так же легко, как и выделенные условными цветами события в журнале событий приложений. Поскольку в состав служб ACS входит набор отчетов по умолчанию, их несложно расширить для соответствия нуждам конкретной среды.
Возьмем следующий случай: из-за важности внешних доверий в среде руководство затребовало разработку отчета, подробно излагающего создание доверий Active Directory. После небольшого исследования отдел ИТ выясняет, что объект trustedDomain создается в контейнере cn=System внутри определенного контекста именования домена в Active Directory при создании доверия. После изменения списка SACL на этом контейнере для проведения аудита успешного создания любого объекта доверенного домена мы получаем возможность фиксировать события безопасности при каждом создании объекта этого типа. Это обрабатывается в событии 566 в журнале событий безопасности на DC, где было выполнено создание доверия. Теперь можно написать простой запрос SQL для извлечения этой информации из служб ACS:
select * from AdtServer.dvAll
where EventID = '566' and
String05 like '%trustedDomain%'
order by CreationTime desc
Чтобы внести это в отчет, используйте версию Visual Studio® 2005, входящую в состав служб отчетов SQL Server 2005 специально для создания отчетов. После завершения работы мастера создавать отчеты, подобные показанному на Рис. 8, будет просто. Более того, любое изменение в среде, которое может быть представлено в журнале событий безопасности, может быть сведено в подобный красивый отчет.
Рис. 8 Пример отчета служб ACS
Рис. 8 Пример отчета служб ACS

Разработка плана аудита
Теперь, когда задачи и проблемы аудита, а также его технические и юридические аспекты понятны, встает вопрос: как администраторам ИТ следует подходить к разработке «плана аудита» для своей организации? Подобно большинству процессов, процесс разработки всеохватывающей политики аудита является многоэтапным. Первый этап – определение того, что следует подвергнуть аудиту. В него входит анализ среды и определение типов событий и изменений, которые должны вызывать аудит. Сюда могут входить простые элементы, такие как блокировка учетных записей, изменения важных групп, создания доверий; либо сложные изменения, такие как изменение элементов настройки внутри приложений в среде. Крайне важно, чтобы руководство организации участвовало в определении того, что должен охватывать план аудита. Это необходимо делать на бумаге и повторять через регулярные промежутки времени – а не только после значительных происшествий.
Во второй этап входит определение того, как информация аудита, затрагивающая конкретные изменения, возвращается в форме событий безопасности. Информация аудита часто загадочна и трудночитаема. Перед реализацией необходимо установить взаимосвязи между событиями безопасности и различными действиями, позволяющие узнавать, что действительно значат события безопасности. После серьезного происшествия на выяснение соотношений событий с действиями уже нет времени.
Третий этап – это собственно попытка завести всю машину, то есть реализация политики аудита и поисков SACL. Как рассказано выше, будет необходимо определить параметры политики аудита (чтобы позволить создание политик безопасности), а также списки SACL (чтобы создавать аудиторские следы для связанных действий) в каталоге, файловой системе и реестре для получения полной картины изменений в этих областях.
Все это приводит к четвертому и последнему этапу – сбору, триггерам и анализу. В зависимости от размера и потребностей организации с этим могут справиться встроенные возможности Windows Server 2008 или расширенные решения, такие как функции служб ACS в System Center Operations Manager. Обычной ошибкой большинства организаций является установка политики аудита без определения SACL. Последний этап целиком связан с реализацией технологического решения для отчетов и обмена данными с заинтересованными пользователями внутри организации. Как упомянуто выше, у большинства организаций имеется организованное подразделение, ответственное за безопасность, и план аудита должен быть структуризован с учетом существующих элементов организации, чтобы быть эффективным. Ключевым на этом заключительном этапе является сбор информации и ее представление в осмысленной форме всем ответственным за осознание изменений в среде.
Для большинства организаций ИТ раздумья о всеохватывающем плане аудита отделены от реальной потребности в нем всего одной серьезной неприятностью. Windows Server 2008 предоставляет усовершенствованные по сравнению с предыдущими платформами механизмы сбора и анализа данных событий безопасности. Усовершенствованные технологии сбора и отчетов, такие как службы ACS, раскрывают проблемы, ранее скрытые объемом событий и распределением, делая эти изменения немедленно очевидными.
Как и для большинства проблем сферы ИТ, основной сложностью является организация процесса. Для обнаружения того, что ожидают руководители отделов ИТ, всегда требуется дополнительная настройка и анализ, так что выработка глубокого знания требований среды и возможностей платформы Windows позволит встретить эти сложности лицом к лицу. Доброй охоты.

Джоэл Йокер и Роб Кэмпбелл (Rob Campbell, Joel Yoker) Роб Кэмпбелл (Rob Campbell) – старший технический специалист рабочей группы подразделения Microsoft Federal, а Джоэл Йокер (Joel Yoker) – старший консультант в этой группе. Джоэл и Роб занимаются разработкой и развертыванием решений в сфере безопасности для органов федерального правительства США.


 От редактора: За здоровье Windows Server 2008
От редактора
За здоровье Windows Server 2008

Продукты запускаются постоянно. Ну а когда в вашем портфеле сотни продуктов (тысячи, на самом деле, если учитывать сетевые), то запуск продукта может стать чем-то обыденным. Но не в этот раз.
В феврале этого года корпорация Майкрософт отмечает запуск Windows Server 2008, и мы взбудоражены до предела. Без сомнения, этот выпуск заставил нас ждать, но я думаю, что результат окупает ожидания. Число существенных улучшений, равно как и объем новых функций, просто ошеломляют. Из них определенно стоит рассказать о IIS 7.0 (мы и рассказываем) и о защите доступа к сети (и о ней тоже). Также, безусловно, стоит осветить диспетчер сервера, новые методики развертывания и функции обеспечения соответствия (сделано, сделано и сделано). В общем, список может тянуться долго, но, по правде говоря, что большей всего поражает меня в этом в выпуске, так это усилия, потраченные на улучшении управляемости Windows Server.
Мы тут потратили немало времени, пытаясь сосредоточиться на том, что нам под силу сделать для упрощения жизни ИТ-специалиста. Учитывая это, нельзя не испытать удовлетворение, увидев продукт, обращающий такое внимание на помощь ИТ-специалисту в улучшении его работы. Возьмем, для примера, инфраструктуру событий в Windows Server 2008, которую Роб Кэмпбелл (Rob Campbell) и Джоэл Йокер (Joel Yoker) обсуждают в этом номере. Это не та тема, которая может разжечь энтузиазм даже среди наших ребят, наиболее помешанных на компьютерах, но я должен сказать, что значение изменений в этом выпуске просто сразило меня. Данные XML, настраиваемые представления, более детальные описания, упрощенные отчеты... изменений столько, что с ними сложно совладать.
Если без шуток, то крупные улучшения в хлебе насущном нашего бизнеса, внесенные эти выпуском, – хорошая причина для волнения. Усовершествования Active Directory, IIS, работы с сетью, безопасности, виртуализации и многого другого делают этот запуск продукта одним из наиболее значимых в нашей истории, так что данный номер посвящен всему, что следует знать о Windows Server 2008.
И особенно приятная новость: мы рады вновь приветствовать в наших рядах Марка Руссиновича (Mark Russinovich), члена технического совета подразделения платформ и служб в корпорации Майкрософт и создателя неизменно популярных средств Sysinternals. Марк был автором некоторых наиболее популярных статей за всю историю журнала TechNet Magazine, в первую очередь цикла «Внутри изменений ядра Windows Vista» (из наших номеров за февраль, март и апрель 2007 года). В этом месяце Марк создает пару данному циклу в виде глубокого технического обозрения изменений в ядре Windows Server 2008. Удачи!
—Джошуа Хоффман (Joshua Hoffman)

Мы бы хотели поблагодарить следующих технических специалистов корпорации Майкрософт: Брэндона Бейкера (Brandon Baker), Мэй-Иэна Томсена Буковеца (Mai-lan Tomsen Bukovec), Брайса Когсвелла (Bryce Cogswell), Нильса Дюссарта (Nils Dussart), Грегуара Гуэтата (Gregoire Guetat), Бретта Хилла (Brett Hill), Гэби Каплан (Gaby Kaplan), Джейсона Лезнека (Jason Leznek), Пола Мэйфилда (Paul Mayfield), Натана Маггли (Nathan Muggli), Мег Мерэн (Meg Muran), Майкла Мерголо (Michael Murgolo), Майкла Нихауса (Michael Niehaus), Раджа Перумала (Raja Perumal), Дэвида Соломона (David Solomon), Эрика Траута (Eric Traut), Джима Трухера (Jim Truher) и Лэнди Ванга (Landy Wang).


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

Технологии полного резервного копирования Windows Vista
Спасибо за отличную статью в вашем сентябрьском выпуске 2007 года, посвященную Windows Vista® Complete PC Backup («Руководство по технологиям резервного копирования Windows Vista») technetmagazine.com/issues/2007/09/Backup). Однако, я не могу заставить себя опробовать это средство на практике, поскольку оно при запросе, куда поместить резервный образ, сообщает, что разместит его на моем внешнем жестком диске (куда я бы и хотел его разместить). Но при этом оно не дает возможности выбрать определенную папку для размещения файла, что заставляет меня опасаться, что оно сотрет все прочие файлы на моем внешнем жестком диске. Обоснованы ли мои опасения?
—Бен Б.

Мы передали ваш вопрос автору, Кристине Фок (Christine Fok), которая ответила, что Complete PC Backup автоматически создает папку на целевом диске для хранения образа и для опасений нет оснований – существующие данные не будут стерты.

Ошибочная ссылка на ключ реестра
Статья за декабрь 2007 г., «Выявление скрытых неполадок в сети» (technetmagazine.com/issues/2007/12/Network) содержит мелкую ошибку в ссылке на ключ реестра для настройки стека TCP/IP в Windows®. На странице 70 автор, Кристофер Стонеф (Christopher Stoneff), упоминает, что подправить значения можно в ключе HKLM\System\CurrentControlSet\Services\TCPIP, тогда как в действительности верный ключ – HKLM\System\CurrentControlSet\Services\TCPIP\ Parameters (должно быть, он забыл добавить "Parameters").
—Ингмар К.

Кристофер Стонеф подтвердил, что вы действительно правы. Ключ включает \Parameters на конце. Наши извинения за пропуск необходимой части пути реестра. Мы исправили это в электронной версии статьи.

Шифрование файлов.
Меня очень интересует шифрованная файловая система (Encrypting File System – EFS) и я прочел вашу статью в рубрике «На страже безопасности» за март 2007 «Развертывание EFS: часть 2» (technetmagazine.com/issues/2007/03/SecurityWatch). У меня есть среда домена, и некоторые пользователи уже взялись за шифрование файлов. После этого я внедрил шаблоны центра сертификации (CA) и EFS. Мой вопрос состоит в следующем: если пользователям, которые уже зашифровали файлы, используя собственные самоподписывающиеся сертификаты, потребуется зашифровать новые файлы, следует ли им шифровать их с использованием старых сертификатов или подать заявку на новый из моего CA? Также, если все мои пользователи используют перемещаемые профили, где будут храниться закрытые ключи пользователей?
—Аммар Х..

Джон Морелло (John Morello), написавший статью о развертывании EFS, прислал ответ на ваш вопрос.
После того как пользователи подают заявку на новый сертификат EFS, они будут использовать его для новых операций. Однако существующие зашифрованные файлы останутся зашифрованными с помощью старой пары ключей, пока они не обновлены. Так что после того, как все пользователи подали заявки, можно запустить cipher /u, что обновит все эти файлы на новую пару ключей.
При использовании перемещаемых профилей пары ключенй перемещаются вместе с ними. Я рекомендую использовать перемещение учетных данных, отнимающее меньше ресурсов, чем перемещение профилей. Дополнительные сведения можно найти по следующему адресу: go.microsoft.com/fwlink/?LinkId=107469.

Ошибочные регулярные выражения
Относительно выпуска рубрики «Эй, сценарист!» за январь 2008 г. «Регулярные выражения ни с чем не спутаешь» (technetmagazine.com/issues/2008/01/HeyScriptingGuy): пример, использующий
objRegEx.Pattern = "[^A-Z][^a-z]"
, может быть не тем, что намеревались написать авторы. Он был предназначен для поиска любого знака, не являющегося строчной или прописной буквой. Однако этот шаблон предназначен для строчной буквы, за которой следует прописная. Он не срабатывает для строки вроде «aBcde». Возможно, он должен был бы выглядеть так:
objRegEx.Pattern = "[^A-Z^a-z]"
—Роджер Р.

Мы передали ваш вопрос Scripting Guys и вот что они могут сказать:
Привет, Роджер. Спасибо за то, что указали на это. Похоже, что мы внесли изменение в статью и не привели сценарий в соответствие с ним. В первоначальном черновике (который все еще лежит где-то на моем компьютере), мы действительно говорили, что этот сценарий предназначен для поиска строчной буквы, за которой следует прописная. Мы, должно быть, решили затем, что это не так полезно, как поиск знаков, не являющихся буквами, но, изменив текст, забыли изменить пример кода. Мы исправим это в электронной версии статьи. Просим прощения за ошибку.


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

Управление базами данных SQL
SQL Sentry Event Manager
sqlsentry.net/event-manager/standard-sql-server.asp
Чем больше и сложнее инфраструктура, тем больше внимания приходится уделять взаимным помехам обслуживания и эксплуатационных задач. Это может вызвать хаос в технологической схеме для конечных пользователей. К счастью, администраторам систем и баз данных доступно несколько средств, помогающих координировать построение расписаний в сложных средах.
Одно из таких средств, которое стоит принять во внимание для серверных сред с несколькими базами данных, – SQL Sentry Event Manager («Диспетчер событий оповещения SQL»), серверное приложение Microsoft® .NET Framework, использующее экземпляр SQL Server® 2000 или SQL Server 2005 на серверном компоненте. Пользователь подключается к серверному приложению через интерфейс пользователя консоли SQL Sentry, дающее единое представление управляемых серверов в его среде. У серверного приложения нет агента, но это, как и обычно, предполагает, что ему нужно работать в контексте пользователя, имеющего права на подключение к компьютерам и серверам, которыми нужно управлять.
Одно из снискавших наибольшую похвалу возможностей приложения заключается в том, что пользовательский интерфейс консоли предоставляет возможность изменения расписания серверных задач с помощью простого перетаскивания, что помогает во взаимном расположении обслуживания и обычной работы, позволяющем избежать конфликтов и простоев. Хотя с первого взгляда этот интерфейс может показаться несколько замысловатым, он позволяет быстро замечать потенциальные проблемы и находить интервал времени, на который можно сдвинуть конфликтную задачу. Он даже предлагает представление заданий агента SQL и назначенных заданий Windows® для серверов, за которыми пользователь решил наблюдать, в стиле Microsoft Outlook®. А календарное представление выделяет долгосрочные и окончившиеся сбоем задания, помогая отслеживать и разрешать проблемы по дороге.
В дополнение к функциям составления расписания, SQL Sentry также предоставляет надежную систему уведомления, устраняющую необходимость в SQL Mail, MAPI, xp_sendmail и sp_send_dbmail. Он также маршрутизирует все уведомления о событиях с управляемых серверов через свою подсистему, давая централизованный контроль над типами, частотой и распределением этих уведомлений.
Уведомления могут быть настроены на глобальном уровне либо уровне серверов, задач или заданий, предлагая детализацию, которую большинство администраторов ожидает от такого типа событий. Можно установить набор различных типов условий событий, вызывающих уведомление, например случай, когда на завершение работы уходит слишком много или слишком мало времени, когда индикатор производительности, такой как индикатор использования ЦП, достигает определенного порога, или когда задание агента SQL блокируется по какой-либо причине. Также возможно настроить SQL Sentry на уведомление в случае изменений настройки, позволяющее узнать, когда кто-то изменяет расписание, приостанавливает работу монитора и т. п.
Однако SQL Sentry обрабатывает не только задания агента SQL и события планировщика задач Windows. Это приложение также поддерживает события от планов обслуживания, пакетов DTS, задач SSIS и журнала агентов SQL.
Начальство обычно желает видеть, насколько хорошо работают системы, а администратор, который может гордиться соотношением рабочего времени своих систем к простоям, обычно желает продемонстрировать также и это. SQL Sentry обладает набором встроенных возможностей отчетности как раз для такой задачи, позволяя создавать статистические графики времени исполнения и производительности. Данные отчетов также можно экспортировать в форматы XML, CSV или HTML для включения в собственные отчетные документы и средства.
Обратите внимание, что профессиональная версия этой программы добавляет также возможность управлять серверами Oracle, а также такие функции, как наблюдение за работой служб отчетов, создание очереди заданий агента SQL, организация цепочек не относящихся к SQL событий сервера и ведение календаря для общих ресурсов.

Цена: стандартная версия стоит начиная от 395 долларов.
Создание расписания обслуживания с помощью SQL Sentry
Создание расписания обслуживания с помощью SQL Sentry

Удаленное управление системами
Mobile Admin
rovemobile.com/products/ma/features
Поскольку быть сразу в нескольких местах невозможно при всем желании, средство мобильного удаленного администрирования сервера является хорошим помощником для перегруженного специалиста по ИТ. Тем, кому оно нужно, стоит познакомиться с Mobile Admin («Мобильным администратором») от компании Rove Mobile (ранее Idokorro Mobile).
Mobile Admin – это клиент-серверная установка, где один сервер связи (имеющий доступ к серверам, которыми необходимо управлять) взаимодействует с набором переносных карманных устройств. У серверной части приложения нет агента, а это значит, что на серверах, которыми необходимо управлять, не нужно ничего устанавливать. Однако при этом нужно дать этому компьютеру и контексту приложения соответствующие права удаленного администрирования, чтобы иметь возможность администрировать компьютеры в своей инфраструктуре.
Доступ к серверу возможен с помощью большинства основных мобильных платформ, включая наладонники на основе Windows Mobile® и смартфоны, а также смартфоны BlackBerry. Вдобавок, любой компьютер, подключенный к Интернету и имеющий совместимый обозреватель, может подключиться к Mobile Admin (если политика безопасности это позволяет).
Одной из основных задач в области мобильного администрирования для любого специалиста по системам или сети является обеспечение безопасности. Те, у кого развернут BlackBerry Enterprise Server, могут выбрать шифрование всей связи по тройному стандарту шифрования данных (TDES) или улучшенному стандарту шифрования (AES) – оба они совместимы с федеральными стандартами обработки информации (FIPS) правительства США.
Кроме того, Mobile Admin расширяет функцию «уничтожения» потерянного устройства BlackBerry, удаленно устраняя ПО и данные с телефона. Для других карманных устройств можно реализовать VPN, чтобы обезопасить свои сообщения, и/или настроить Mobile Admin на использование входа Windows, LDAP, RSA SecurID, проверки подлинности RADIUS или специального входа Mobile Admin.
После подключения можно приступать к выполнению задач администрирования Windows, таких как просмотр и очистка журнала событий, перезагрузка компьютеров, управление файлами и каталогами, а также просмотру и правке назначенных задач.
В терминах интеграции с Active Directory® пользователь может просматривать, создавать, изменять, отключать или удалять пользователей, группы и компьютеры. В то же время, при администрировании Exchange он может изменять параметры почтового ящика, замораживать и размораживать очереди сообщений и выполнять иные задачи.
В IIS возможен перезапуск пулов приложений и веб-узлов, а также изменение параметров виртуального каталога. Для серверов SQL можно проделывать такие вещи, как запуск запросов T-SQL, изменение имен входа, а также запуск и остановку заданий агентов SQL. А в случае использования служб кластеров можно перемещать группы, отключать ресурсы от сети и производить переход на резервный ресурс, помимо прочих обычных административных задач.
Наконец, Mobile Admin также поддерживает управление аспектами Oracle, Novell LDAP, Lotus Domino, Citrix, HP iLO, Backup Exec и других программ.

Цена: начиная от 245 долларов США за сервер.

Рецензия на книгу
Managing Windows Network Forensics and Investigation
sybex.com
Возможно, у наших читателей имеется необходимое оборудование и процедуры для обнаружения и подавления угроз их сетям. Но известны ли им процедуры и есть ли у них протоколы для выслеживания и, возможно, судебного преследования виновников проходящего по части безопасности события?
Здесь-то и может прийти на помощь книга Mastering Windows Network Forensics and Investigation («Освоение искусства расследования в сети Windows») (изд-во Sybex, 2007 г.). Она разработана, чтобы дать читателю умения, необходимые для полного расследования вторжений в сети Windows, начиная от мелких инцидентов, затрагивающих один компьютер (таких как недопустимое использование услуг компании) до более широких атак против важных систем.
Эта книга проводит читателя через процесс сбора доказательств, охватывая все – от проведения допроса до трассировки подвергшихся аудиту событий и журналов. В ней рассказывается, где и как собирать доказательства на компьютерах и в сетях Windows при помощи средств вроде WireShark, LogParser, EnCase и набора SysInternals.
Кроме того, в книге рассматривается информация, которую можно получить из реестра, структуры и содержимого файловой системы, текстовых журналов, журналов событий и процессов на затронутых компьютерах. Из нее также можно узнать, как создать компакт-диск Live-Analysis (анализ в реальном времени), содержащий все необходимое для отслеживания всех необходимых доказательств. Наконец, в книге рассказывается о том, как представлять результаты своего расследования, подробно останавливаясь на рекомендациях и процедурах, касающихся дачи показаний в суде.

Цена: 59,99 долларов США.

Сбор данных о системе
MetaLAN
hammer-software.com/metalan.shtml
Централизованное администрирование является одним из ключевых компонентов успешного системного администрирования. Оно устраняет массу беготни и высвобождает некоторое количество ценного времени администратора, уменьшая нагрузку на него на работе.
MetaLAN от компании Hammer Software – это средство, помогающее поддерживать пользователей и серверы и управлять ими в сети Windows. Это не имеющее агента приложение позволяет быстро собирать информацию о компьютерах Windows, вносить изменения в их настройку и, в общем, управлять ими. Конечно, это требует наличия необходимого пользовательского контекста и прав.
MetaLAN имеет два режима работы. Его можно запустить напрямую в режиме администратора (который достигает машин, о параметрах которых необходимо произвести запрос или свойства которых необходимо изменить) или через бесплатное дополнение агента/службы, именуемое ProbeServer, на удаленной машине, в тандеме с MetaLAN работающем в режиме сервера для постоянного наблюдения за рабочими станциями.
Запуск приложения переносит пользователя в рабочий интерфейс контрольной панели MetaLAN, который, в свою очередь, дает возможность проверить текущую сеть на предмет доменов для управления. Отсюда также можно запустить компоненты различных средств, таких как средства службы поддержки, отчетов, программного обеспечения и RegCast.
Средство службы поддержки дает представление поиска и обзора для машин в домене, управление которым производится. При выборе компьютера выводится масса полезной информации о нем, в том числе производитель, IP-адрес, процессор, диски, MAC-адреса и роли сервера. Отсюда можно выполнять запросы инструментария управления Windows (WMI), подключаться к работающим в реальном времени мониторам производительности, просматривать установленное ПО и выполнять прочие полезные административные задачи.
Средство отчетов дает быстрые, экспортируемые и графические представления управляемых узлов. Например, здесь можно создать круговую диаграмму скоростей ЦП всех компьютеров в сети или проверить, на каких компьютерах установлена Windows XP с пакетом обновления 2.
Средство программного обеспечения позволяет быстро просматривать и экспортировать списки программ, установленных на группах от одной до N в сети – это прекрасное средство для аудитов.
А средство RegCast позволяет просматривать (а администратору домена или предприятия – изменять) данные реестра на удаленных компьютерах в выбранной группе компьютеров.
В состав MetaLAN также входят средство удаленного развертывания и установки пакетов установщика Microsoft Installer (MSI) (если они поддерживают незаметную установку); обзор накопителей, показывающих каждый диск на управляемых машинах и наличие свободного пространства; а также средство администратора служб, позволяющее запускать, останавливать и даже удалять службы. Как если бы этого было недостаточно, в нем имеется еще и замечательное средство удаленного управления VNC, загружающее на управляемую машину маленький исполняемый файл VNC, который при запуске обеспечивает удаленный контроль над компьютером (во многом подобно удаленному помощнику).

Цена: Начиная от 75 долларов США за пакет лицензий на 20 узлов.
Средство службы поддержки дает представление поиска и обзора
Средство службы поддержки дает представление поиска и обзора

Автоматизация задач
AutoHotkey
autohotkey.com
Автоматизация может быть лучшим другом специалиста по ИТ, помогая ему избежать длительных, механически повторяющихся задач. Среди многих средств, предназначенных для помощи в этой области, имеется служебная программа AutoHotkey. Это бесплатное средство с открытым исходным кодом позволяет упростить и ускорить рутинные дела на рабочем столе, автоматизируя почти любую задачу, требующую ввода с клавиатуры, мыши или даже джойстика. Это основанное на сценариях суперсредство для «горячих клавиш» и макросов.
AutoHotkey работает на панели задач и выполняет созданное пользователем определение сценария при запуске системы. Программа выполняет отдельные команды сценария в порядке их расположения в файле сценария. Это очень полезно, например, для запуска любимого набора приложений при запуске системы. Но это еще не все: пользователь может определить любое число горячих клавиш и «горячих строк».
Горячие клавиши или клавиши быстрого доступа – это любые комбинации клавиш, которые пользователь определил как вызывающие действия, такие как запуск приложения, вынос окон на передний план и даже имитацию прокрутки колесика мыши.
А «горячие строки», со своей стороны – это текстовые сокращения для часто вводимых команд или фраз. Вдобавок, горячие строки можно использовать для запуска сценария действия подобно горячим клавишам. Например, можно создать горячую строку из простой последовательности букв "сч", которая будет открывать Microsoft Word и записывать сегодняшнее число в желаемом формате. Или, при наличии определенного параграфа ответа, который постоянно рассылается адресатам, можно создать простую горячую строку для автоматической записи этого параграфа в сообщение Outlook.
Сам язык сценариев поддерживает переменные, выражения для математических и строковых операций, встроенные глобальные переменные, функции, циклы и условные операторы, делая возможным конструирование сценариев, отвечающих административным нуждам конкретных систем. В целом, пользователю там помогают свыше 100 команд и языковых конструкций. Например, имеются возможности имитировать перетаскивание с помощью мыши, показывать окна сообщений, выполнять асинхронные операции, отправлять сообщения электронной почты, изменять реестр, устанавливать таймеры внутри циклов для обеспечения регулярных проверок, открывать приложения, закрывать окна и прерывать процедуры, и это лишь несколько примеров.
Другая отличная возможность AutoHotkey – это возможность компиляции сценариев для повторного использования и распространения после подгонки их под свои нужды. Это позволяет и пользователям, у которых не установлен AutoHotkey, пользоваться созданными в нем сценариями и ярлыками. Поскольку же код проекта открыт, их можно распространять без ограничений.
Например, можно легко распространить по конечным пользователям внутри организации исполняемый сценарий, выполняющий некоторый набор настроек, который иначе пришлось бы выполнять вручную прямо на их рабочем столе. Более того, на случай, если эти сценарии необходимо подгонять под каждого пользователя, AutoHotkey также принимает параметры командной строки, позволяя создать нечто как полезное, так и пригодное для использования во всем домене.
В отличие от многих проектов с открытым кодом, документации которых часто недостает подробности, документация AutoHotkey является исчерпывающей и хорошо изложенной, демонстрируя читателю создание сценариев задач автоматизации с помощью множества наглядных и полезных примеров. Помимо веб-узла проекта, в Интернете можно найти активный форум пользователей, где могут ответить на любые вопросы, и вики-страницу, содержащую сценарии, учебные материалы и справочник по командам. Имеется также страница демонстрации сценариев, предлагающая хороший набор работающих примеров, предоставленных пользователями.

Цена: бесплатно.
AutoHotKey может компилировать сценарии для повторного использования и распространения
AutoHotKey может компилировать сценарии для повторного использования и распространения

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


 Обзор служебных программ: Сертификация торгового знака Windows Server
Обзор служебных программ
Сертификация торгового знака Windows Server
Венкат Кришнамачари (Venkat Krishnamachari)
Загрузить исходный код для этой статьи: Работает с Windows Server 2008 (KB)

Посредством Windows Server® 2008 Software Certification корпорация Майкрософт пытается помочь разработчикам обеспечить соответствие рекомендациям и позволить специалистам по ИТ оценивать приложения перед покупкой, экономя время и нервы. Чтобы помочь клиентам оценить степень совместимости приложений, Майкрософт создала программу «Работает с Windows Server 2008», в состав которой входят бесплатные поддерживающие тестовые средства, помогающие обеспечить предсказуемую работу приложения.
Средство «Работает с...» собирает данные о воздействии приложения на ОС в ходе его жизненного цикла через наблюдение за состоянием файловой системы, реестра, служб и драйверов. Затем средство анализирует данные и сообщает об успехах и сбоях для конкретного контрольного примера. Документ среды тестирования «Работает с...» и дополнительные средства, доступные на windowsservercatalog.com/ready, предоставляют дополнительные подробности. Эти средства должны помогать независимым поставщикам программного обеспечения в работе над совместимостью приложений, в то же время позволяя специалистам по ИТ оценивать готовность приложения к развертыванию на Windows Server 2008.
Для использования этих средств сперва установите последнюю версию Windows Server 2008 на тестовом компьютере, загрузите средство «Работает с...» на windowsservercatalog.com/ready и не забудьте средство Application Verifier. Графический интерфейс пользователя средства имеет четыре простых функции: создание тестового прохода, возобновление существующего тестового прохода, просмотр результатов теста и создание пакета запроса (для независимых поставщиков ПО, которым нужна проверка «Работает с...» от уполномоченного поставщика тестов).
Текстовый отчет с результатами
Текстовый отчет с результатами
Тестовый проход создается путем перебора этапов жизненного цикла приложения: установки, настройки, выполнения и удаления. Средство «Работает с...», как правило работает в фоновом режиме, проверяя стабильность ОС и совместимость установщика, а также то, правильно ли выполняются компоненты, с учетом новых требований к безопасности платформы и прочих настраиваемых компонентов. Как правило, стоит завершить тестовый проход и создать полный отчет, что обычно занимает от двух до четырех часов. Однако можно также остановить тестовый проход, создать быстрый отчет и возобновить тест позже.
По завершении работы, пользователь получает ясные «красные» или «зеленые» отчеты о состоянии для каждого контрольного случая с подробными результатами, как показано на снимке экрана. Тесты с зелеными результатами означают совместимость. Для красных результатов можно просмотреть файл журнала, чтобы узнать условие ошибки. Не забудьте сохранить локально созданные журналы на другую машину, чтобы на них можно было сослаться после очистки диска на тестовом компьютере. Средство «Работает с...» запускается на любом серверном приложении, а также может оценивать клиентские компоненты и средства управления, разработанные для Windows Vista®.
Тем, кто использует коммерческое ПО, средство «Работает с...» может помочь запланировать перенос известных совместимых приложений. Результаты теста можно использовать, чтобы запрашивать поставщиков о планах поддержки, в то же время сохраняя время разработчиков, уходящее на обнаружение проблем совместимости и приоритизацию исправлений. В случае нестандартных приложений можно будет предоставить максимально конкретные отзывы своей группе разработчиков. Также можно будет подтверждать сохранение совместимости по мере выпуска новых исправлений и документировать данные настройки приложений для своего отдела ИТ. Некоторые из клиентов использовали средства для документации файлов, которых касаются системные приложения.
Нас интересуют ваши отзывы о том, как мы можем улучшить средства или контрольные примеры для повышения удобства их использования в вашей среде. Пишите нам об этом wslogofb@microsoft.com.

Венкат Кришнамачари (Venkat Krishnamachari) работает ведущим техническим специалистом в центре сертификации программного обеспечения Windows Server Software Certification с 2005 г., а перед этим работал в группе, занимавшейся поставками SQL Server 2005.


 Кабельщик: Перенос интрасети на IPv6 с помощью ISATAP
Кабельщик
Перенос интрасети на IPv6 с помощью ISATAP
Джозеф Дэвис (Joseph Davies)
Данная статья основана на предварительной версии Windows Server 2008. Любые приведенные в ней сведения могут быть изменены.

Одно из распространенных заблуждений относительно протокола Интернета 6-й версии (IPv6) заключается в том, что для IPv6 необходимо развертывать его встроенную адресацию и маршрутизацию, что требует детального анализа схем адресации IPv6, обновлений маршрутизатора и конфигурации, а также графика развертывания. Хотя это рано или поздно необходимо будет проделать для собственного подключения
IPv6, ничто не мешает развернуть туннелированное подключение IPv6, используя протокол ISATAP. При туннелировании подключения IPv6, узлы, поддерживающие ISATAP могут сообщаться, используя трафик IPv6, инкапсулированный с заголовком IPv4 (поле протокола IPv4 установлено на 41). Трафик ISATAP может пересекать интрасети, поддерживающие только IPv4, позволяя немедленно начать тестирование приложений, поддерживающих IPv6, не дожидаясь собственной инфраструктуры IPv6.
ISATAP – это технология назначения адресов автоматического туннелирования, определенная в RFC 4214 и предоставляющая одноадресное подключение IPv6 между узлами IPv6/IPv4, через поддерживающую только IPv4 интрасеть. Узлы ISATAP используют интерфейс логического туннелирования, которому назначаются адреса ISATAP, имеющие форму UnicastPrefix:0:5EFE:w.x.y.z (где w.x.y.z – это частный адрес IPv4, назначенный узлу ISATAP) или UnicastPrefix:200:5EFE:w.x.y.z (где w.x. y.z – публичный адрес IPv4, назначенный узлу ISATAP). UnicastPrefix – это любой 64-битный префикс адреса для одноадресного подключения, включающая уникальные локальные префиксы, глобальные префиксы и префиксы локальной связи. Примеры адресов ISATAP: 2001:DB8::98CA:200:131.107.28.9 и 2001:DB8::98CA:0:10.91.211.17.

Перенос интрасети на IPv6 с помощью ISATAP
Развертывание ISATAP состоит из одной или нескольких логических подсетей ISATAP, являющихся поддерживающими только IPv4 подсетями, которым назначен 64-битный префикс подсети IPv6. В логической подсети ISATAP имеются узлы ISATAP и маршрутизаторы ISATAP. Узел ISATAP использует интерфейс маршрутизирования ISATAP для инкапсуляции трафика IPv6. Этот трафик может быть направлен напрямую на другие узлы ISATAP в той же логической подсети ISATAP. Для достижения точек назначения в других подсетях ISATAP или собственных подсетях IPv6, трафик отсылается маршрутизатору ISATAP. Марштрутизатор ISATAP – это маршрутизатор IPv6, объявляющий префиксы подсети узлам ISATAP и пересылающий трафик IPv6 между узлами ISATAP и узлами на других подсетях IPv6. Рис. 1 показывает компоненты ISATAP на упрощенной интрасети.
Рис. 1 Части интрасети только с IPv4 и поддерживающие IPv6
Рис. 1 Части интрасети только с IPv4 и поддерживающие IPv6
ISATAP позволяет развертывать собственные возможности адресации и маршрутизации IPv6 на интрасети в три фазы.
Фаза 1. Интрасеть только с IPv4 В этой фазе вся интрасеть может быть единой, логической подсетью ISATAP. Рис. 2 показывает пример интрасети только с IPv4 и с маршрутизатором ISATAP, объявляющим глобальный или уникальный локальный префикс адреса только узлам ISATAP.
Рис. 2 Интрасеть только с IPv4
Рис. 2 Интрасеть только с IPv4
Фаза 2. Части интрасети только с IPv4 и поддерживающие IPv6 В этой фазе интрасеть имеет часть только с IPv4 (логическая подсеть ISATAP) и часть, поддерживающую IPv6. Часть интрасети, поддерживающая IPv6, поддерживает IPv4 и была обновлена для поддержки собственной адресации и маршрутизации IPv6. Эту конфигурацию можно было увидеть на рис. 1.
Фаза 3. Интрасеть, поддерживающая IPv6 В этой финальной фазе, вся интрасеть поддерживает как IPv4, так и собственную адресацию и маршрутизацию IPv6. Отметьте, что ISATAP больше не требуется. Рис. 3 показывает пример.
Рис. 3 Интрасеть, поддерживающая IPv6
Рис. 3 Интрасеть, поддерживающая IPv6
С помощью ISATAP, подключение по IPv6 между узлами и приложениями возможно в ходе первых двух фаз перехода с интрасети только с IPv4 на поддержку IPv6.

Windows Server 2008 и Windows Vista
Протокол IPv6 для Windows Server® 2008 и Windows Vista® поддерживает ISATAP, как в виде узла ISATAP, так и маршрутизатора ISATAP. Для каждого интерфейса LAN, установленного на компьютере, имеющем особый суффикс DNS, имеется отдельный интерфейс туннелирования ISATAP. Например, если на компьютере работает Windows Vista с двумя интерфейсами LAN, причем оба они присоединены к одной интрасети и имеют тот же суффикс DNS, то для них существует только один интерфейс туннелирования ISATAP. Если эти два интерфейса LAN присоединены к двум различным сетям с различными суффиксами DNS, интерфейсов ISATAP тоже будет два. Для компьютеров, использующих Windows Server 2008 или Windows Vista с пакетом обновления 1 (SP1), интерфейсы туннелирования ISATAP помещаются в отключенное от носителя состояние, если имя "ISATAP" не может быть разрешено.
По умолчанию протокол IPv6 для Windows Vista без установленных пакетов обновления автоматически настраивает локальные адреса связи ISATAP (FE80::5EFE: w.x.y.z или FE80::200:5EFE:w.x.y.z) на интерфейсах туннелирования ISATAP для адресов IPv4, назначенных соответствующим интерфейсам LAN.
Протокол IPv6 для Windows Vista SP1 и Windows Server 2008 настраивает локальные адреса связи ISATAP на интерфейсах туннелирования ISATAP, только если имя "ISATAP" может быть разрешено.
Для получения сообщения объявления маршрутизатора от маршрутизатора ISATAP, узел ISATAP должен отослать маршрутизатору ISATAP сообщение запроса маршрутизатора. На подсети Ethernet собственный узел IPv6 отсылает многоадресное сообщение запроса маршрутизатора, а машрутизаторы в подсети отвечают сообщением объявления маршрутизатора. Поскольку ISATAP не использует многоадресный трафик IPv4 и не требует поддерживающей многоадресность инфраструктуры IPv4, узел ISATAP должен одноадресно отправить сообщение запроса маршрутизатора маршрутизатору ISATAP.
Для одноадресной отправки сообщения запроса маршрутизатора маршрутизатору ISATAP, узел ISATAP должен сперва определить этот адрес IPv4 интерфейса маршрутизатора ISATAP в логической подсети ISATAP. Для протокола IPv6 для Windows Server 2008 и Windows Vista, узел ISATAP получает единый адрес IPv4 маршрутизатора ISATAP, посредством успешного разрешения имени узла "ISATAP" в адрес IPv4, или с помощью команды установки маршрутизатора isatap интерфейса netsh.

Перенос интрасети. Фаза 1.
Чтобы развернуть ISATAP в интрасети для фазы один перехода на IPv6, необходимо выполнить следующие действия.
Определить префикс подсети ISATAP Необходимо определить 64-битный префикс подсети, который будет назначен логической подсети ISATAP, соответствующей интрасети. 48-битный префикс можно получить от поставщика услуг Интернета или реестра Интернета, также можно вывести собственный 48-битный уникальный локальный префикс (см. RFC 4193 в сети на tools.ietf.org/html/rfc4193).
Из 48-битного префикса, выберите 16-битный идентификатор подсети для логической подсети ISATAP. Комбинация 48-битного префикса и 16-битного идентификатора подсети и является 64-битным префиксом подсети ISATAP. Например, 48-битный уникальный локальный префиус FD8A:219C:052A::/48 и идентификатор подсети 1 образуют 64-битный префикс подсети FD8A:219C:052A:1::/64.
Обозначить компьютер маршрутизатора ISATAP Определите, какой компьютер будет маршрутизатором ISATAP. Хотя многие коммерческие машрутизаторы поддерживают функции маршрутизатора ISATAP, предоставленная здесь информация относится только к компьютерам, использующим Windows Server 2008.
Компьютеру маршрутизатора ISATAP не нужно несколько интерфейсов LAN, как не нужно и подключение к поддерживающей IPv6 части сети для фазы 1; однако компьютер должен быть выбран таким образом, чтобы позднее его можно было дополнить интерфейсом LAN, подключенным к поддерживающей IPv6 части интрасети.
Настроить компьютер маршрутизатора ISATAP На компьютере маршрутизатора ISATAP, отдание следующей команды помещает интерфейс туннелирования ISATAP на компьютере маршрутизатора ISATAP в состояние подключения к носителю:
netsh interface isatap set router IPv4Address
IPv4Address – это адрес IPv4, назначенный интерфейсу LAN компьютеру маршрутизатора ISATAP, который присоединен к логической подсети ISATAP.
Далее, определите имя индекса интерфейса туннелирования ISATAP, соответствующее имени интерфейса LAN компьютера маршрутизатора ISATAP, присоединенного к логической подсети ISATAP, из выходных данных следующей команды:
netsh interface ipv6 show interfaces
Далее используйте эту команду, чтобы разрешить объявления на интерфейсе ISATAP:
netsh interface ipv6 set interface ISATAPInterfaceNameOrIndex advertise=enabled
ISATAPInterfaceNameOrIndex – имя индекса интерфейса туннелирования ISATAP.
Далее используйте следующую команду для настройки компьютера маршрутизатора ISATAP на объявление префикса подсети ISATAP узлам ISATAP:
netsh interface ipv6 add route ISATAPSubnetPrefix ISATAPInterfaceNameOrIndex publish=yes
ISATAPSubnetPrefix – установленный префикс подсети ISATAP
Настроить DNS В DNS, добавьте запись адреса (A) для имени ISATAP в соответствующие домены, чтобы узлы ISATAP на интрасети могли полностью разрешать имя "ISATAP". Например, если узлы инрасети используют суффикс DNS contoso.com, то необходимо добавить запись A к домену contoso.com для имени isatap.contoso.com с адресом IPv4, который назначается интерфейсу LAN маршрутизатора ISATAP на сети только с IPv4.
Если сервер DNS работает только на Windows Server 2008, используйте редактор реестра (regedit.exe) на сервере DNS, чтобы удалить запись ISATAP из значения реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters\GlobalQueryBlockList.
Протестировать узлы ISATAP С узла ISATAP в интрасети, используйте средство Ipconfig, чтобы просмотреть назначенные адреса. Узлы ISATAP должны иметь адрес в форме ISATAPSubnetPrefix:: 5EFE:w.x.y.z или ISATAPSubnetPrefix:: 200:5EFE:w.x.y.z. Для примера, если префикс подсети ISATAP – это FD8A:219C: 052A:1::/64 и узел ISATAP имеет адрес IPv4 10.1.31.97, то интерфейсу туннелирования узла ISATAR будет назначен адрес FD8A: 219C:052A:1::5FE:10.1.31.97.
Если у узла ISATAP нет адреса ISATAP на основе префикса подсети ISATAP, проверьте, может ли узел разрешить имя "ISATAP". Если нет, проверьте, созданы ли записи A в соответствующих доменах и для серверов DNS, использующих Windows Server 2008, проверьте, изменено ли значение реестра GlobalQueryBlockList и удалена ли из него запись ISATAP. Если имя может быть разрешено, проверьте, верно ли настроен компьютер маршрутизатора ISATAP. Если это так, убедитесь, что маршрутизаторы в интрасети допускают пересылку трафика 41 протокола IPv4.
Когда узлы ISATAP могут успешно настраивать себя с помощью адресов, основанных на префиксе подсети ISATAP, они регистрируют эти адреса ISATAP как записи AAAA в DNS и начинают использовать их для подключений на основе IPv6.

Перенос интрасети. Фаза 2.
В фазе 2 перехода на IPv6 необходимо изменить конфигурацию маршрутизатора ISATAP, чтобы он выполнял перенаправление между частями интрасети только с IPv4 и частями, поддерживающими IPv6.
На компьютере маршрутизатора ISATAP используйте следующую команду:
netsh interface ipv6 show interfaces
Из ее выходных данных, определите имя индекса интерфейса LAN, присоединенного к поддерживающей IPv6 части интрасети и интерфейса туннелирования ISATAP.
Используйте эту команду, чтобы позволить перенаправление на интерфейсе ISATAP:
netsh interface ipv6 set interface ISATAPInterfaceNameOrIndex forwarding=enabled
Используйте эту команду, чтобы разрешить перенаправление на интерфейсе LAN:
netsh interface ipv6 set interface LANInterfaceNameOrIndex forwarding=enabled
LANInterfaceNameOrIndex - имя индекса интерфейса туннелирования LAN.
Используйте следующую команду, чтобы добавить маршрут по умолчанию к маршрутизатору ISATAP:
netsh interface ipv6 add route ::/0 LANInterfaceNameOrIndex NextHopAddress publish=yes
NextHopAddress – адрес IPv6 соседнего собственного маршрутизатора IPv6 на поддерживающей IPv6 части интрасети.
Чтобы сделать логическую подсеть ISATAP доступной для поддерживающей IPv6 части интрасети, важно настроить собственные маршрутизаторы IPv6 на маршрут для префикса подсети ISATAP, указывающего на компьютер маршрутизатора ISATAP.
Чтобы выборочно отключить ISATAP для компьютеров на поддерживающей IPv6 части интрасети, измените записи A для имени ISATAP в DNS так, чтобы компьютеры на поддерживающей IPv6 части интрасети не могли разрешить имя ISATAP.
Другим вариантом является создание и установка значения реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters\DisabledComponents на 0x4 (тип DWORD).

Перенос интрасети. Фаза 3.
Для фазы 3, когда вся интрасеть поддерживает IPv6, необходимо удалить развертывание ISATAP через DNS и перенастроить компьютер маршрутизатора ISATAP. Для DNS, удалите все записи A из имени ISATAP. Это не даст узлам определять адрес IPv4 маршрутизатора ISATAP.
Для компьютера маршрутизатора ISATAP выполните следующую команду:
netsh interface isatap set router default
Эта команда возвращает компонент ISATAP к его состоянию по умолчанию.
Определите имя или индекс интерфейса туннелирования ISATAP из выходных данных этой команды:
netsh interface ipv6 show interfaces
Используйте эту команду, чтобы запретить перенаправление и объявление на интерфейсе ISATAP:
netsh interface ipv6 set interface ISATAPInterfaceNameOrIndex forwarding=disabled advertise=disabled
Используйте эту команду, чтобы удалить маршрут префикса подсети ISATAP с компьютера маршрутизатора ISATAP:
netsh interface ipv6 delete route ISATAPSubnetPrefix ISATAPInterfaceNameOrIndex
ISATAPSubnetPrefix – установленный префикс подсети ISATAP.
Дополнительную информацию о развертывании ISATAP, включая сведения об избыточных маршрутизаторах ISATAP и вопросах брандмауэра, можно найти в статье "Intra-Site Automatic Tunnel Addressing Protocol Deployment Guide" («Руководство по развертыванию протокола ISATAP») на go.microsoft.com/fwlink/?LinkId=106926.

Джозеф Дэвис (Joseph Davies) работает разработчиком технической документации в корпорации Майкрософт. С 1992 года занимается преподаванием и пишет о сетях Windows. Он автор восьми книг, опубликованных издательством Microsoft Press, и ведет ежемесячную рубрику «Кабельщик» в журнале TechNet. Более подробно о «Кабельшике» рассказывается на microsoft.com/technet/community/columns/cableguy/about.mspx.


 Windows PowerShell: Отчет о ходе выполнения
Windows PowerShell
Отчет о ходе выполнения
Дон Джонс (Don Jones)

Недавно мне пришлось писать довольно длинный и замысловатый сценарий Windows PowerShell, который в ходе работы начал довольно плохо отвечать на запросы. Я написал его для выполнения в качестве назначенного задания, так что видимого вывода он выдавал не то чтобы много. Тем не менее, выполнив его в рамках первого большого теста, я начал опасаться,
что случайно вписал в него бесконечный цикл или какой-либо еще проблематичный элемент сценария.
Оболочка оставалась безмолвной, жалобно мигая своим маленьким курсором, и я спросил себя: "Жива ли она?" Как видно, у меня нет уверенности в себе, поскольку я поспешно нажал Ctrl+C, чтобы прервать сценарий. Пора добавить какую-никакую функцию сообщений о ходе работы.

Болтовня, болтовня, болтовня
Командлет месяца: Tee-Object
В этом месяце я хочу рассмотреть один из моих любимых командлетов для устранения неполадок. Рассмотрим, например, следующий случай:
Get-WMIObject Win32_Service | Where { $_.State -ne "Running"
-and $_.StartMode -eq "Automatic" } | ForEach-Object { $_.Start() }
На первый взгляд, кажется, что эта команда запускает все службы, установленные на автоматический запуск, но еще не запустившиеся по какой-либо причине. Однако на практике это не работает, и обнаружить причину может быть непросто, поскольку заглянуть в середину конвейера нельзя. Ну, нельзя, если не использовать Tee-Object.
Tee-Object перенаправляет объекты к файлу (либо внутрь переменной) и передает их по конвейеру. Например:
Get-WMIObject Win32_Service | Tee-Object AllServices.csv | Where
{ $_.State -ne "Running" -and $_.StartMode -eq "Automatic" } |
Tee-Object FilteredServices.csv | ForEach-Object { $_.Start() }
Это изменение позволяет мне увидеть, что происходит после каждой команды конвейера, и я могу быстро обнаружить, что мой файл FilteredServices.csv ничего не содержит! Ничего удивительного, что сценарий не работал! Немного дополнительной работы, и источник проблемы раскрыт – StartMode указан как "Auto", а не "Automatic", – а Tee-Object позволяет мне точно указать, где именно имела место проблема.

В первую очередь мне хотелось добавить пачку сообщений о состоянии, точно дающих мне знать, чем именно занят сценарий. Оболочка позволяет легко выполнить такую задачу с помощью командлета Write-Verbose. Попробуйте это сами:
Write-Verbose "Test Message"
Те, кто попробовал, должны были заметить, что ничего не произошло. Это объясняется тем, что Write-Verbose отсылает объекты специальному конвейеру Verbose, который по умолчанию не отображает свои выходные данные. Этот конвейер контролируется встроенной переменной оболочки, $VerbosePreference. Значение этой переменной по умолчанию – SilentlyContinue, при котором подробный вывод не допускается. Однако после замены его на Continue конвейер открывается:
$VerbosePreference = "Continue"
Теперь я могу добавить пачку операторов Write-Verbose к моему сценарию и получить подробное представление того, что происходит в ходе его выполнения. Прелесть этого приема заключается в том, что по завершении тестирования и устранения неполадок я могу отключить всю эту дополнительную болтовню, установив $VerbosePreference обратно на SilentlyContinue в начале сценария.
В поиске и удалении всех операторов Write-Verbose нет нужды. Более того, поскольку они остаются в сценарии, каждый раз, когда мне требуется запустить сценарий вручную, я могу легко включить конвейер Verbose вновь, если это необходимо.

Но мне нужен настоящий индикатор выполнения
После того, как стало ясно, что сценарий не попал в бесконечный цикл и, на самом деле, работал идеально, я отключил конвейер Verbose и запустил его снова – на всякий случай.
Теперь возникла новая проблема – даже зная, что сценарий функционирует без проблем, я просто не мог вынести созерцания мигающего курсора. (У меня есть проблемы с длительным сосредоточением внимания. В отчаянии я начал искать свежую краску – уж лучше было бы сидеть и смотреть, как она сохнет.)
Что мне было нужно – это общее указание о проценте выполненной работы и оценка времени, необходимого на ее завершение. По сути, что-нибудь вроде индикатора выполнения.
К счастью, Windows PowerShellTM включает командлет Write-Progress. Этот командлет не предоставляет графического индикатора выполнения, подобного имеющемуся в Windows®, но неплохой индикатор выполнения он все же предоставляет, как показано на рис. 1. Он довольно похож на индикатор выполнения копирования файлов, используемый основанной на тексте частью программы установки в Windows Server® 2003 или даже Windows XP.
Рис. 1 Насколько выполнен сценарий?
Рис. 1 Насколько выполнен сценарий?
Использование Write-Progress требует некоторых объяснений. На самом деле, думаю лучше будет привести пример. Рассмотрим следующий сценарий:
for ($a=1; $a -lt 100; $a++) {
  Write-Progress -Activity "Working..." `
   -PercentComplete $a -CurrentOperation
   "$a% complete" `
   -Status "Please wait."
  Start-Sleep 1
}
Он использует Write-Progress для отображения индикатора выполнения. Я использовал Start-Sleep, чтобы заставить сценарий делать паузу на одну секунду при каждом проходе через цикл, чтобы его выполнение было достаточно медленным и мы могли увидеть процесс выполнения – без паузы цикл дошел был от 0 до 100 с такой скоростью, что индикатор выполнения лишь мелькнул бы ненадолго на экране.
Как можно увидеть, Activity («Действие»), которое я установил на Working («Работающее»), отображается на верху индикатора выполнения. Status («Состояние») показано прямо под ним, а CurrentOperation – внизу. Оболочка поддерживает только один индикатор выполнения за раз. При использовании Write-Progress либо будет создан новый индикатор выполнения, если текущий не отображается в настоящий момент, либо обновлен отображаемый.
Здесь я пока не сделал одной вещи – не указал индикатору исчезнуть по завершении. Для этого достаточно добавить к концу сценария следующее:
Write-Progress -Activity "Working..." `
 -Completed -Status "All done."
Как правило, индикатор выполнения исчезнет сам по себе после завершения сценария, но если сценарию надо сделать что-то еще, то лучше скрыть его, после того, как он стал не нужен, – параметр -Completed просто удалит индикатор с экрана.

Тик, тик, тик
Другое распространенное использование Write-Progress – создание счетчика "осталось секунд" вместо собственно индикатора выполнения. Приведу пример:
for ($a=100; $a -gt 1; $a--) {
  Write-Progress -Activity "Working..." `
   -SecondsRemaining $a -CurrentOperation
   "$a% complete" `
   -Status "Please wait."
  Start-Sleep 1
}
Все, что я здесь сделал, – это изменил цикл на отсчет со 100 до 1 и использовал параметр SecondsRemaining во Write-Progress, вместо PercentComplete. Результат показан на рис. 2. Как можно заметить, индикатор выполнения заменен на счетчик обратного отсчета. Оболочка автоматически преобразует общее число оставшихся секунд в часы, минуты и секунды, предлагая более удобную для пользователя информацию. Показанный здесь процент выполнения отсчитывается вниз от 100, просто потому, что это предоставленный мной параметр CurrentOperation. Реально процент выполнения не вычисляется, Windows PowerShell просто предоставляет текущее значение процента и строку «% выполнено».
Рис. 2 Сколько осталось до завершения выполнения сценария?
Рис. 2 Сколько осталось до завершения выполнения сценария?

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

Дон Джонс (Don Jones) — пишущий редактор журнала TechNet Magazine и соавтор книги Windows PowerShell: TFM (изд-во SAPIEN Press, 2007г.). Он преподает работу с Windows PowerShell (см. www.ScriptingTraining.com), и с ним можно связаться через веб-узел ScriptingAnswers.com


 Эй, сценарист!: Игры в наперстки с помощью оболочки
Эй, сценарист!
Игры в наперстки с помощью оболочки
Программисты корпорации Майкрософт
Загрузить исходный код для этой статьи: HeyScriptingGuy2008_03.exe (150KB)

Согласно древней поговорке, даже самый крохотный воробей не может упасть на землю так, чтобы это не заметили на небесах. Нет, Scripting Guys конечно не предлагают читателям заняться сшибанием воробьев с небес. (Хотя, если кто-нибудь желает позаботиться о идиотских воронах, орущих на крыше в семь утра по субботам, то это совсем другое дело. [Нашему редактору сценариев нравятся вороны, так что мы уверены в том, что под «позаботиться» сценарист из Scripting Guys, пишущий эту статью имеет в виду «обеспечить их благополучие». – Эд.]) В любом случае, приятно знать, что кого-то волнует твое падение и что, каким бы мелким и незначительным ты не казался, все равно кто-то где-то присматривает за тобой. [Даже если это просто редактор. – Эд.]
То, что верно для воробьев, похоже, верно и для написания сценариев системного администрирования. Можно спокойно сказать, что в мире сценариев основная часть внимания прикована к большим шишкам: Windows PowerShellTM, VBScript, WMI, ADSI и даже FileSystemObject. То, что эти технологии притягивают наибольшее внимание, вполне понятно, в конце концов, они позволяют делать много всего интересного и полезного. Но это не значит, что они являются единственными технологиями, доступными авторам сценариев. Отнюдь нет.
Возьмем, к примеру, объект оболочки. Хотя объект оболочки может и не быть настолько же известен или разрекламирован, как Windows PowerShell, он, тем не менее, важен – и полезен.
Существует значительная вероятность того, что рано или поздно возникнет необходимость написать сценарий системного администрирования, использующий объект оболочки. Это ведет к очевидному вопросу: что именно можно сделать с помощью объекта оболочки? Оказывается, много всего интересного и часть этих вещей (таких как управление дисковыми квотами и отображение индикатора выполнения) уже освещена в руководстве по написанию сценариев для Microsoft® Windows® 2000 (microsoft.com/technet/scriptcenter/guide). В данном выпуске нашей рубрики мы собираемся показать вам еще несколько милых маленьких фокусов, которые можно проделать с объектом оболочки и о возможности проделать которые вообще, а тем более используя объект оболочки, читатели, вероятно, не знают.

Изменение даты последнего изменения файла
Многие из читателей, вероятно, смотрят на предшествующий заголовок и думают: «Постойте. Ведь менять дату последнего изменения с помощью сценария нельзя, по крайней мере, не с помощью VBScript». На что мы можем сказать только одно: откуда вообще взялась такая мысль?
Ох, верно; мы, Scripting Guys, вероятно сказали это в прошлом, не так ли? Что ж, как оказалось, мы ошибались. Возмутительно! Менять дату последнего изменения с помощью VBScript можно. Все, что для этого нужно – использовать объект оболочки.
Примечание. Не трудитесь спрашивать, как Scripting Guys могли тут ошибиться, после стольких лет это должно быть довольно очевидно. Вот куда более интересный вопрос: как нам вообще удается хоть когда-либо быть правыми?
Итак, необходимо поменять дату последнего изменения файла, да? Просто используйте этот сценарий:
Set objShell = _
  CreateObject("Shell.Application")

Set objFolder = _
  objShell.NameSpace("C:\Scripts")
Set objFolderItem = _
  objFolder.ParseName("Dr_Scripto.jpg")

objFolderItem.ModifyDate = _
  "01/01/2008 8:00:00 AM"
Как можно заметить, в этом нет ничего сложного. Сначала создается экземпляр объекта Shell.Application. (Кстати, не спутайте Shell.Application с Wscript.Shell, объектом оболочки сервера сценариев Windows. Объект оболочки с котором мы работаем сегодня – это объект оболочки Windows.) После того как наш экземпляр объекта оболочки заработал, мы используем метод пространства имен для привязки к папке C:\Scripts, а затем своеобразно названный метод ParseName для привязки к конкретному файлу внутри этой папки. В данном случае мы привязываем к изображению JPEG с именем файла Dr_Scripto.jpg:
Set objFolderItem = _
  objFolder.ParseName("Dr_Scripto.jpg")
И что мы делаем после привязки к самому файлу? Мы просто назначаем новую дату и время свойству ModifyDate:
objFolderItem.ModifyDate = _
  "01/01/2008 8:00:00 AM"
Вот и все, что нужно сделать.
Знаете, вы правы. Это довольно круто, не так ли? После запуска сценария дата последнего изменения файла будет установлена на 1 января 2008 года, 8:00. (Если пожелаете, можно открыть папку C:\Scripts в Windows Explorer, чтобы убедиться в этом самому.)
Само собой, кое кто из читателей может думать: «Круто. Я могу поменять дату последнего изменения файла. Но зачем мне вообще может понадобиться менять дату последнего изменения файла?». Ну, достаточно часто пользователи используют эту дату как своего рода систему контроля версий; если, скажем, в системе болтается несколько копий сценария, один из способов найти официальную версию – проверить дату последнего изменения. Проверив дату последнего изменения, можно сказать, является ли определенная копия сценария его неизмененной изначальной версией.
Примечание. Да, конечно, кто-нибудь может запустить только что продемонстрированный сценарий и изменить эту дату. Но, помимо подписывания кода после каждой операции, нет такого подхода, который кто-нибудь не сумел бы обойти. Если предположить, что коллеги – честные люди, с которыми можно делиться сценариями, этот подход разумен.
В какой-то момент может возникнуть потребность в обновлении – и стандартизации – даты последнего изменения для всех сценариев. Как проделать это? Предполагая, что все сценарии находятся в папке C:\Scripts, достаточно выполнить следующий сегмент кода:
Set objShell = _
  CreateObject("Shell.Application")

Set objFolder = _
  objShell.NameSpace("C:\Scripts")
Set colItems = objFolder.Items

For Each objItem In colItems
    objItem.ModifyDate  = _
      "01/01/2008 8:00:00 AM"
Next
Как можно заметить, этот сценарий начинается очень похоже на первый показанный нами сценарий. Но в данном случае, после привязки к папке C:\Scripts, мы не используем ParseName для привязки к отдельному файлу в этой папке. Вместо этого мы используем следующую строку кода, чтобы возвратить собрание всех файлов, найденных в этой папке:
Set colItems = objFolder.Items
После получения собрания мы устанавливаем цикл For Each для перебора всех элементов в нем. Внутри цикла For Each, мы используем следующую удобную строку кода, чтобы изменить значение свойства ModifyDate первого файла в собрании на 1 января 2008 года, 8:00:
objItem.ModifyDate  = _
  "01/01/2008 8:00:00 AM"
А затем мы просто продолжаем выполнение цикла и повторяем процесс на следующем файле в собрании. После того как все сказано и сделано, все файлы в папке C:\Scripts (ну, за исключением скрытых файлов) будут иметь идентичную дату последнего изменения. Видите, как просто? Ну и кто там сказал, что менять дату последнего изменения с помощью VBScript нельзя?
Ох, да.

К слову об заблуждении...
В доисторическую эпоху, когда Scripting Guys впервые начали работать со сценариями системного администрирования, не было никакой возможности получить доступ к расширенной информации о файле, присоединяемой к файлу в файловой системе NTFS. Например, если щелкнуть правой кнопкой мыши на файл .wav, а затем щелкнуть свойства, можно увидеть информацию, подобную указанной на рис. 1.
Рис. 1 Сводка свойств файла
Рис. 1 Сводка свойств файла
Как извлечь значения, вроде скорости потока или размера аудио образца, используя сценарий? Никак. Ну, если не использовать для этого объект оболочки. (Или Windows Desktop Search 3.0, если эта программа загружена и установлена.) Где-то в процессе к объекту оболочки была добавлена способность извлекать всю расширенную информацию о свойствах файла, но Scripting Guys каким-то образом просмотрели данный факт. Как следствие, мы говорили читателям: «Использовать сценария для определения скорости потока файла .wav невозможно», хотя, как показывает код на рис. 2, на деле это возможно.
Figure 2 Используйте сценарий, чтобы найти скорость потока файла .wav (Close Figure 2)
Set objShell = CreateObject("Shell.Application")

Set objFolder = objShell.NameSpace("C:\Scripts")
Set objFolderItem = objFolder.ParseName("J0388563.wav")

For i = 0 to 33
    strHeader = objFolder.GetDetailsOf(objFolder.Items, i)
    strValue = objFolder.GetDetailsOf(objFolderItem, i)
    If strValue <> "" Then
        Wscript.Echo strHeader & vbTab & strValue
    End If
Next
Как работает этот сценарий? Ну, начинается и он точно так же, как первый, показанный нами: мы создаем экземпляр объекта Shell.Application и привязываем его к папке C:\Scripts, затем используем метод ParseName для привязки к рассматриваемому файлу (в данном случае, J0388563.wav).
С этого момента все становится несколько хитрее. Для начала мы устанавливаем цикл For Next, выполняющийся с 0 до 33, поскольку файлы поддерживают до 31 расширенного свойства, которым даны номера в индексе с 0 до 33. (Отметьте, что есть несколько номеров, таких как 27 и 28, которые входят в индекс, но не содержат значений свойств.) В действительности файлы поддерживают свойства, показанные на рис. 3.
Figure 3 Свойства файла (Close Figure 3)

Индекс | Свойство
0 | Имя
1 | Размер
2 | Тип
3 | Дата изменения
4 | Дата создания
5 | Дата доступа
6 | Атрибуты
7 | Состояние
8 | Владелец
9 | Автор
10 | Заголовок
11 | Тема
12 | Категория
13 | Страниц
14 | Комментарии
15 | Авторские права
16 | Артист
17 | Название альбома
18 | Год
19 | Номер дорожки
20 | Жанр
21 | Протяженность
22 | Скорость потока
23 | Защищен
24 | Модель камеры
25 | Дата снимка
26 | Размеры
29 | Название серии
30 | Описание программы
32 | Размер аудио образца
33 | Частота дискретизации
Так что у нас есть внутри цикла For Next? В первую очередь мы исполняем следующую строку кода:
strHeader = _
  objFolder.GetDetailsOf(objFolder.Items, i)
Здесь мы используем метод GetDetailsOf для извлечения имени свойства 0 (помним, что наш цикл работает с 0 до 33). Затем мы сохраняем это имя в переменной, именуемой strHeader, а также используем данную строку кода для извлечения значения свойства элемента 0, сохраняя возвращенную информацию в переменной, именуемой strValue:
strValue = _
  objFolder.GetDetailsOf(objFolderItem, i)
Поняли, в чем смысл? Элемент 0 – это свойство имени. Так что при первом проходе через цикл strHeader будет равен имени. В то же время реальное имя (то есть значение свойства имени) для первого файла – J0388563.wav. Следовательно, при первом проходе через цикл strHeader будет равен J0388563.wav. В таком изложении это не кажется таким уж сложным, верно?
Как читатели, вероятно, знают, не все типы файлов поддерживают все расширенные свойства. (Например, файл .jpg не будет иметь свойств, вроде названия альбома или частоты дискретизации.) Следовательно, в следующей строке кода мы проверяем, не является ли возвращенное значение пустой строкой:
If strValue <> "" Then
Если оно является таковой, мы просто переходим к началу цикла и повторяем процесс со следующим расширенным свойством. Если значение – не пустая строка, мы выводим имя и значение свойства, вот так:
Wscript.Echo strHeader & vbTab & strValue
Что мы имеем в итоге? Нечто подобное следующему:
Имя    j0388563.wav
Размер    169 KB
Тип    Wave Sound
Дата изменения   1/19/2004 8:56 AM
Дата создания    3/6/2006 2:02 PM
Дата доступа   12/3/2007 10:41 AM
Атрибуты      A
Состояние  Online
Владелец   FABRIKAM\kenmyer
Скорость потока        90kbps
Размер аудио образца       4 bit
Частота дискретизации       11 kHz
Здорово.
У нас уже заканчивается время (и объем в журнале), но для тех, кто ищет еще более простой способ возвращения наиболее актуальных значений свойств, мы рекомендуем сценарий на рис. 4 вместо предыдущего.
Figure 4 Простой способ возвращения значений свойств (Close Figure 4)
Const colInfoTip = -1

Set objShell = CreateObject("Shell.Application")

Set objFolder = objShell.NameSpace("C:\Scripts")
Set objFolderItem = _
  objFolder.ParseName("01. Out On The Weekend (Album Version).wma)")

Wscript.Echo objFolder.GetDetailsOf(objFolderItem, colInfoTip)
Что делает этот сценарий? Ну, если в проводнике Windows задержать курсор мыши над файлом, то всплывет подсказка с некоторой полезной информацией о файле, подобной показанной на рис. 5. Как можно получить эту подсказку, используя сценарий? Совершенно верно. Применив сценарий, который мы только что показали:
Рис. 5 Свойства, показанные в подсказке
Рис. 5 Свойства, показанные в подсказке
Артист: Neil Young
Название альбома: Harvest
Год: 1972
Номер дорожки: 1
Протяженность: 0:04:35
Тип: Windows Media Audio file
Скорость потока: 256kbps
Защищен: Yes
Размер: 5.31 MB
Вот наше время на этот месяц и подошло к концу. Да, одно последнее замечание о воробьях. Одна из причин, по которой стоит следить за крохотными воробьями, такова: в некоторых странах мира воробей, влетевший в дом, считается приносящим несчастье. Почему? Потому что это значит, что кто-то из живущих в доме умрет. (В некоторых случаях это верно, только если воробей сядет на пианино. Но это не суеверие, это просто странно.) А вот теперь кое-что интересное: в других странах мира воробей, влетевший в дом, предвещает скорое вступление в брак одного из обитателей. Вот что называется оказаться меж двух огней, ага?

Головоломка-сценарий доктора Скрипто.
Задача на этот месяц потребует не только умения решать головоломки, но и навыков создания сценариев.

Март 2008: Загадочный сценарий
В этом месяце головоломка является шифрограммой – каждая буква в ней заменена другой буквой. (Мы оставили все цифры и символы как есть.) Каждая замененная буква представлена одной определенной буквой. Например, все буквы a могут быть заменены на b, все b на z и так далее. Вот простой пример:
tdsjqu dfoufs
расшифровывается так:
script center
Расшифровка в данном случае была выполнена путем замены каждой буквы на букву, предшествующую ей в алфавите: t на s, d на c, и т.д.
Сама головоломка несколько посложнее. Расшифруйте этот сценарий и получите сценарий, который открывает экземпляр Microsoft Excel®, добавляет новую таблицу, назначает четыре значения первому столбцу в таблице и сортирует содержание этот столбца в восходящем порядке.
Желаю удачи!

Головоломка
kqyjs edfjkzyrlyg = 1
kqyjs edyq = 2
kqyjs edjqtstqmj = 2

jzs quwzekzd = ktzfszquwzks("zekzd.faadlkfslqy")
quwzekzd.iljludz = stcz

jzs quwmqtxuqqx = quwzekzd.mqtxuqqxj.frr
jzs quwmqtxjozzs = quwmqtxuqqx.mqtxjozzsj(1)

quwmqtxjozzs.kzddj(1, 1) = "kfs"
quwmqtxjozzs.kzddj(1, 2) = "rqg"
quwmqtxjozzs.kzddj(1, 3) = "ufs"
quwmqtxjozzs.kzddj(1, 4) = "faz"

jzs quwtfygz = quwzekzd.fkslizkzdd.zysltztqm
quwtfygz.jqts quwtfygz, edfjkzyrlyg, , , , , , edyq, , , edjqtstqmj

Головоломка-сценарий доктора Скрипто.
Ответ. Загадочный сценарий, март 2008 года
Вот ключ для расшифровки сценария:
Actual Letter	a	b	c	d	e	f	g	h	i	j	k
Coded Letter	f	u	k	r	z	b	g	o	l	w	x

Actual Letter	l	m	n	o	p	q	r	s	t	u	v	w	x	y	z
Coded Letter	d	n	y	q	a	h	t	j	s	c	i	m	e	v	p
А вот собственно расшифрованный сценарий:
Const xlAscending = 1
Const xlNo = 2
Const xlSortRows = 2

Set objExcel = CreateObject("Excel.Application")
objExcel.Visible = True

Set objWorkbook = objExcel.Workbooks.Add
Set objWorksheet = objWorkbook.Worksheets(1)

objWorksheet.Cells(1, 1) = "Cat"
objWorksheet.Cells(1, 2) = "Dog"
objWorksheet.Cells(1, 3) = "Bat"
objWorksheet.Cells(1, 4) = "Ape"

Set objRange = objExcel.ActiveCell.EntireRow
objRange.Sort objRange, xlAscending, , , , , , xlNo, , , xlSortRows

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


 На страже безопасности: Использование SCW в Windows Server 2008
На страже безопасности
Использование SCW в Windows Server 2008
Йеспер М. Йоханссон (Jesper M. Johansson)
Данная статья основана на предварительной версии Windows Server 2008. Любые приведенные в ней сведения могут быть изменены.

В 2005 году корпорация Майкрософт выпустила Windows Server 2003 с пакетом обновления 1 (SP1). В состав этого пакета обновления входило первое средство управления безопасностью на основе ролей для Windows: мастер настройки безопасности (SCW). SCW был разработан, в первую и главную очередь, для уменьшения области, доступной для атак. Его цель заключалась в анализе того,
что пользователь реально делал со своим компьютером, и автоматической его настойки для поддержки необходимых ролей с одновременным отключением неиспользуемых ролей и служб.
В Windows Server® 2008 остался мастер SCW, обновленный посредством добавления новых ролей и интеграции с новым брандмауэром Windows®. Он остается таким же современным средством администрирования, каким он был ранее.
В состав Windows Server 2008 также входит новое средство диспетчера серверов на основе ролей и родственные ему мастера добавления ролей и компонентов. В Windows Server 2008 для настройки сервера вместо добавления отдельных компонентов через старомодную панель управления установкой и удалением компонентов Windows теперь можно использовать средства управления ролями. Байрон Хайнз рассматривает эти средства в своей статье «Настройка ролей с помощью диспетчера серверов», выходящей в данном номере журнала TechNet Magazine.
Мастера добавления ролей и компонентов разработаны для создания настройки сервера с верными компонентами для поддержки выбранных ролей. Они также настраивают встроенный брандмауэр для обеспечения верного функционирования этих ролей. Учитывая это, можно задать вопрос – а нужен ли теперь SCW? Конечно, у многих администраторов теперь отпала потребность в SCW. Однако для двух групп пользователей SCW все еще может быть бесценным средством. Первая – это страдающие паранойей специалисты по безопасности. Они не могут не оценить способность SCW вывести безопасность на новый уровень.
Мастера добавления ролей и компонентов можно представить себе как средства, берущие сервер по умолчанию и создающие настройку для безопасной поддержки выбранных ролей и компонентов. SCW, с другой стороны, это средство, создающее настройку сервера, поддерживающую только выбранные поли и компоненты. SCW также имеет определенный воспитательный эффект, помогая лучше ознакомиться с настройкой сервера. Поэтому я настоятельно рекомендую запускать SCW после того, как на сервере создана настройка из нужного комплекта ролей и компонентов.
Вторая группа состоит из пользователей, желающих разобраться в отношениях между различными компонентами. SCW поставляется с набором файлов XML, которые документируют отношения между ролями и компонентами, службами, а также сетевыми портами. Для тех, кто хочет разобраться, что нужно различным компонентам, SCW является очень ценным средством.
В этой статье я опишу, как работает SCW и как использовать его для защиты сервера. Также я предоставлю сравнение SCW со средствами диспетчера серверов. Обратите внимание, что материал для данной статьи позаимствован из моей книги Windows Server 2008 Security Resource Kit («Комплект ресурсов безопасности Windows Server 2008») (изд-во Microsoft Press®, 2008 г.).

Обзор мастера настройки безопасности
Чтобы подготовить сцену, я хочу представить некоторую статистику, касающуюся области, доступной для атак в Windows Server 2008. Перед настройкой сервера путем добавления выбранных пользователем ролей и компонентов он уже имеет относительно внушительную область служб. По умолчанию, в Windows Server 2008 имеется 105 служб – 42 установленных на автоматический запуск, 55 на ручной и 8 отключенных. Сравните это с чистой установкой Windows Server 2003 R2 с пакетом обновления 2 (SP2), в которой по умолчанию устанавливается 86 служб – 34 установленных на автоматический запуск, 32 на запуск по запросу и 20 отключенных.
Даже с учетом метафоры ролей и уменьшения числа поддерживаемых по умолчанию ролей, Windows Server 2008 все равно имеет большую область, доступную для атак, и требует дополнительного внимания при укреплении безопасности серверов. SCW проводит пользователей через создание индивидуализированной настройки безопасности для конкретных серверов.
SCW использует совершенно отличный от существующих средств подход к укреплению безопасности серверов Он работает с метафорой ролей, чтобы создать настройку, не поддерживающую ничего или почти ничего, кроме этих ролей. Хотя SCW помогает настроить брандмауэр подобно мастерам добавления ролей и компонентов, он также отключает ненужные службы и настраивает некоторые дополнительные параметры безопасности. Наконец, если мастера добавления ролей и компонентов могут устанавливать и настраивать только роли, встроенные в Windows, то SCW расширяем. Разработчик или администратор может написать нестандартную роль или файл настройки компонента и использовать SCW для настройки любого продукта.
SCW разработан для использования после установки всех ролей и компонентов, которые должны иметься на сервере. Если на сервере предполагается иметь приложения сторонних производителей, их также следует установить до запуска SCW.
Чтобы продемонстрировать, как это работает, я создал настройку сервера с тремя ролями (сервер приложений, сервер DNS и веб-сервер) и двумя компонентами (возможности Microsoft® .NET Framework 3.0 и служба активации процессов Windows). Это не слишком логичный набор ролей и компонентов, но он служит хорошим примером для этого рассказа.
Запустите SCW из меню «Администрирование». Возникнет диалог, показанный на рис. 1.
Рис. 1 SCW начинает с того, что спрашивает, что пользователь хочет сделать
Рис. 1 SCW начинает с того, что спрашивает, что пользователь хочет сделать
Первый этап – это выбор того, хотите ли вы создать новую политику безопасности, изменить или применить существующую политику или выполнить откат политики, возвращая систему к изначальным параметрам. Суть вариантов относительно ясна из их перечисления.
При выборе создания новой политики безопасности SCW создает новую политику, используя какой-либо компьютер как шаблон для того, что политика должна поддерживать. Он анализирует компьютер, определяет какие компоненты и роли тот поддерживает, гарантируя как то, что они будут работать, так и то, что многие ненужные компоненты не будут включены.
SCW работает по модели прототипа. Он использует файлы XML для указания, на что должны быть похожи роли и компоненты – какие файлы следует установить, какие службы настроить и т.д. Именно по этой причине на компьютер, где разрабатывается политика, следует установить всё заранее. Программы от сторонних производителей, устанавливающие определения SCW при собственной установке, интегрируются без проблем. Но если программы от сторонних производителей не устанавливают определения SCW, их понадобится настроить вручную.
Как несложно заметить, политику можно создать на одной системе и применить ее к многим. При создании сети со многими системами сначала следует определить главные классы, которые настраиваются отдельно. Затем следует создать политику, используя один из них как прототип, и просто применить политику ко всем остальным с минимальными изменениями или вовсе без изменений.
При нажатии кнопки «Далее» (в диалоге, показанном на рис. 1) мастер запрашивает, какой компьютер следует использовать как базовый вариант, или прототип, для этой новой политики. Обычно стоит выбирать локальный компьютер, но можно использовать в качестве прототипа и удаленный компьютер.
После указания, какую систему использовать, начинается фаза анализа. В ней SCW формирует список установленных ролей и компонентов и сопоставляет его с базой данных ролей и компонентов. База данных содержит информацию, касающуюся того, какие службы используются каждой ролью и компонентом, какие сетевые порты им нужны и прочую важную информацию о настройке. После завершения анализа можно нажать кнопку просмотра базы данных настроек, чтобы увидеть, что нашел SCW. Отметьте, что эти сведения отображаются в представлении только для чтения, предоставляющем исчерпывающую информацию о настройке компьютера. Те, кому действительно интересно, что находится на их компьютере, могут провести немало времени, изучая эту информацию.

Настройка сервера с помощью SCW
При нажатии кнопки «Далее» пользователь входит в первый из четырех разделов SCW: настройку служб на основе ролей. Можно заметить, что имеющиеся в SCW роли, показанные на рис. 2, не идентичны ролям в мастере добавления ролей. Большинство ролей, доступных в мастере добавления ролей, присутствуют и здесь, а также SCW предлагает некоторые роли, не включенные в мастер добавления ролей. Например, выбранная мною роль сервера приложений отсутствует. Это вызвано тем, что SCW несколько иную метафору для ролей. Я подробнее рассмотрю этот вопрос чуть ниже.
Рис. 2 Использование SCW для выбора ролей, которые должен поддерживать сервер
Рис. 2 Использование SCW для выбора ролей, которые должен поддерживать сервер
В диалоге зачастую будет присутствовать уже выбранный правильный набор ролей. Так что просто проверьте, нашел ли анализ то, что, по идее, должен был найти. Если что-то не так, проверьте, установлена ли роль, и установите ее в случае отсутствия перед перезапуском SCW. Если и допущена ошибка, это еще не конец света. Функция отката в SCW вернет все к начальной точке, отменяя все изменения, внесенные политикой.
Ответы, которые пользователь дает в этом разделе, крайне важны, поскольку они определяют, что он увидит позже, в разделе сети. К счастью, логика обнаружения достаточно хороша, и обычно выбирается верный набор ролей.
Обратите внимание, что по умолчанию показываются установленные роли, то есть роли, которые сервер способен поддерживать при помощи того, что выложено на диск. Выбранные роли – это роли, которые он поддерживает в настоящий момент. Также можно выбрать показ всех ролей в базе данных. Для этого просто укажите «Все роли» в раскрывающемся списке. Это полезно, в первую очередь, при необходимости создать политику, используя прототип сервера, на котором еще не установлены все необходимые роли.
После настройки ролей выберите клиентские компоненты, которые следует поддерживать. Набор компонентов похож на присутствующий в мастере добавления компонентов, но не идентичен ему и содержит меньше компонентов. Опять-таки, метафоры не вполне совпадают, и SCW может быть расширен, так что список отличается от показываемого в мастере добавления компонентов.
При нажатии кнопки «Далее» на странице клиентских компонентов в SCW пользователь переходит к диалогу выбора управления и других параметров, как показано на рис. 3. Параметром в SCW считается то, что не вполне подпадает под определение роли или компонента. Он может предоставлять поддержку в администрировании или просто быть единственной службой, такой как обнаружение интерактивных служб. Опять же, большинство необходимых компонентов следует выбрать здесь. Также стоит указать на раскрывающееся меню. Оно заполнено вариантами, относящимися к ранее выбранным ролям и компонентам, и будет различным на различных компьютерах.
Рис. 3 Выбор прочих служб и компонентов в SCW
Рис. 3 Выбор прочих служб и компонентов в SCW
Далее следует диалог выбора дополнительных служб. Хотя в комплекте SCW поставляется очень большая база данных служб, в ней описано не все. Службы, найденные SCW на компьютере и отсутствующие в базе данных, показываются на странице дополнительных служб. Все встроенные службы должны быть описаны, и этот диалог не должен возникать, если не установлены какие-либо службы от сторонних производителей.
Затем мастер позволяет выбрать, что делать со службами, которые пользователь не настраивает. Этот вариант предназначен для случаев, когда предполагается взять создаваемую политику и применить ее к другому компьютеру. Если на этом компьютере присутствует иной набор служб, чем на компьютере, где создается политика, мастеру SCW нужно знать, что с ними делать. Один из вариантов, применяемый по умолчанию, – оставить их в покое. Второй вариант – отключить их, это более безопасно, но может вызвать сбои. Но если следовать совету применения политик только к серверам, идентичным тем, на которых они были созданы, то выбор, сделанный на этой странице, не имеет значения.
Теперь работа с разделом настройки ролей SCW завершена, и мастер резюмирует сделанное. Как можно увидеть на рис. 4, даже если пробежать через него не задумываясь, это сильно повлияет на область, доступную для атак. Например, поскольку компьютер не является сервером печати, и на нем не установлено принтеров, то нет и причины запускать службу диспетчера очереди печати. SCW отключает все ненужные службы. На нашем тестовом сервере SCW отключил 17 служб, установленных на автоматический запуск, и 42 службы, запускавшиеся вручную. Ваши результаты, конечно, могут отличаться в зависимости от настройки сервера, но, как можно убедиться, SCW позволяет легко подогнать политику под любой уникальный сервер, тем самым радикально уменьшая область, доступную для атак.
Рис. 4 SCW резюмирует сделанные изменения
Рис. 4 SCW резюмирует сделанные изменения
Далее пользователь переходит к, возможно, самому важному разделу SCW: работе с сетью. После первоначальной страницы приветствия появляется диалог правил сетевой безопасности, показанный на рис. 5. Он содержит список всех правил брандмауэра, предлагаемых SCW и основанных на поддержке ролей, выбранных в предыдущих разделах.
Рис. 5 SCW перечисляет все правила, необходимость в которых определена
Рис. 5 SCW перечисляет все правила, необходимость в которых определена
Если не производить дальнейших настроек в разделе работы с сетью, то SCW создаст правила брандмауэра, блокирующие сетевые интерфейсы таким образом, что будут доступны только эти роли и компоненты, но все клиенты смогут иметь к ним доступ. Но чтобы действительно довести до совершенства безопасность серверов, следует использовать SCW как неотъемлемый элемент создания стратегии изоляции серверов. Для получения дополнительных сведений об изоляции серверов (и ее «сестре», изоляции доменов), загляните на technet.microsoft.com/network/bb545651.
В моей книге Windows Server 2008 Security Resource Kit имеется глава о обеспечении безопасности сети с помощью изоляции серверов и доменов. Она также рассказывает, как использовать моделирование сетевых угроз для анализа сети и упрощения развертывания изоляции серверов. SCW – ценное средство в этом процессе.
Ограничения на предложенных правилах можно настраивать, выбирая правило и нажимая кнопку «Изменить». При этом возникает диалог, показанный на рис. 6. Это одна из четырех страниц, позволяющих устанавливать дальнейшие ограничения на правила работы с сетью. Например, можно затребовать проверки подлинности IPsec. Выбрав ее, можно также привязать порт к строго определенным конечным точкам. Например, можно настроить его так, чтобы удаленное администрирование было возможно лишь с конкретных узлов. Как можно увидеть, это ключевое преимущество по сравнению с мастерами добавления ролей и компонентов.
Рис. 6 SCW позволяет создавать правила брандмауэра и IPsec
Рис. 6 SCW позволяет создавать правила брандмауэра и IPsec
Возможность создавать правила безопасности подключений на основе выбранных ролей служит двум важным целям. Во-первых, она предоставляет отличную возможность изучить, что именно делают серверы. Для этого даже не потребуется расширять сервер. Достаточно просто запустить мастер, выбрать иные варианты и посмотреть, как это повлияет на последующие страницы. Во-вторых, это позволяет привязать весьма абстрактную концепцию порта к намного более логичной концепции службы и настраивать сетевые ограничения именно на основе того, чем реально занята система.
Если выполнить это правильно, то становится возможной очень тщательно подогнанная под задачи настройка серверов. Раздел работы с сетью в SCW, без сомнения, является местом, где стоит проводить большую часть времени в ходе создания политики безопасности для своих серверов.
Оставшаяся часть SCW позволяет настроить аудит и еще несколько параметров реестра. Значения по умолчанию для этих параметров адекватны для большинства организаций, и, за исключением случаев наличия особых требований, здесь не нужно прилагать особых усилий.
После создания политики ее можно сохранить и применить к компьютеру, над которым идет работа. Или к другим компьютерам. Также ее можно преобразовать в объект групповой политики (GPO), используя команду scwcmd.exe /transform.
Однако при наличии в политике параметров, относящихся к конкретному компьютеру, это может закончиться неудачей или дать весьма странные результаты. Например, в случае создания в разделе работы с сетью ограничений конечных точек, включающих локальные адаптеры, политика будет сочтена относящейся к конкретному компьютеру и не будет успешно преобразована. Это может быть вызвано тем фактом, что данные адаптеры необходимо указывать, используя идентификаторы GUID. Идентификатор GUID для адаптера на одном компьютере не имеет смысла на другом компьютере.
Следовательно, SCW часто лучше использовать для индивидуальной настройки отдельных серверов и как средство обучения. На крупных фермах серверов SCW можно использовать как средство получения сведений о компьютерах и разработки базовой политики. Затем эту политику можно взять и воссоздать для развертывания с помощью того средства, которое используется для настройки серверов в данном случае, скажем групповой политики или системы управления предприятием (такой как Microsoft Systems Center).

SCW по сравнению с диспетчером серверов
Читатели уже могли увидеть, что метафоры, используемые для ролей и компонентов, различаются. «Компонент» в SCW – это что-либо, проделываемое компьютером для работы в качестве клиента. Соответственно, «роль» - это нечто, проделываемое для работы в качестве сервера.
Это отличается от метафоры, используемой в диспетчере серверов, где роль – это собрание служб и компонентов, которое можно представить себе как единое целое, а компонент – это нечто, поддерживающее роль. По сути, для диспетчера серверов роль – это та функция, для выполнения которой пользователь купил сервер. Компоненты важны, но не принадлежат к числу функций, ради которых сервер был куплен. Две метафоры и два различных использования идентичных терминов неизбежно ведут к путанице. Меняя средство, необходимо остановиться и хорошенько обдумать это.
Вдобавок, средства диспетчера серверов не расширяемы. Они разработаны для управления только компонентами, поставляемыми в комплекте с Windows. В ярком контрасте с этим, устанавливаемые программы от сторонних производителей могут добавлять роли и компоненты к SCW. Он позволяет даже писать собственные роли и компоненты. В техническом документе "Extending the Security Configuration Wizard" («Расширение мастера настройки безопасности») (доступный на go.microsoft.com/fwlink/?LinkId=107397) объясняется, как это делать.
SCW также отключает ненужные компоненты. Средства диспетчера серверов, с другой стороны, просто разворачивают запрашиваемые компоненты и не делают с компьютером ничего другого. Для тех, кому нужна помощь в определении компонентов, которые могут понадобиться, SCW является верным выбором.
Вдобавок, хотя как средства диспетчера серверов, так и SCW настраивают работу с сетью, возможности SCW в этом плане гораздо шире. В случае построения стратегии изоляции серверов SCW может быть золотым дном информации и незаменимым средством развертывания. Само собой, это уже относится к области администрирования повышенной безопасности, но SCW и является средством безопасности с повышенными и расширенными возможностями.
Наконец, SCW также настраивает некоторые дополнительные параметры безопасности, которые не настраиваются средствами диспетчера серверов. Однако в Windows Server 2008 они и так уже в основном замещены более эффективными элементами управления или установлены по умолчанию.

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


 Документы о рабочей среде: Нельзя быть слишком толстым или слишком тонким
Документы о рабочей среде
Нельзя быть слишком толстым или слишком тонким
Уэс Миллер (Wes Miller)

Те, кто хоть раз бывал на кампусе Майкрософт, скорее всего видели системы интерактивных терминалов в приемных помещениях большинства строений. Эти системы были созданы при помощи сетевой системы предварительной обработки информации, подключенной к службам терминалов Windows, так, чтобы сотрудники, перемещающиеся с места на место, могли бы получать электронную почту и вообще
подключаться к сети. Первоначально они были созданы на основе старых ПК, списанных с прежних рабочих мест и переработанных под новую задачу. Оборудование, которое иначе недоставало бы скорости, памяти или объема жесткого диска, оказалось идеальным для приложений тонких клиентов. Те, у кого по какой-либо причине имеется старое оборудование, могут успешно использовать его для создания рабочих станций в конференц-залах, обучающих машин и так далее. Вместо того, чтобы наполнять свалки, можно разом позаботиться об окружающей среде и сэкономить деньги.
Если организация обдумывает переход на Windows Vista®, может оказаться, что часть имеющегося оборудования старше, чем казалось. Это может означать отсутствие поддержки доверенного платформенного модуля (Trusted Platform Module – TPM) или Aero®, но если системам недостает лишь объема жесткого диска или ОЗУ, то оборудование можно обновить. Однако некоторые системы просто не будут в состоянии запустить Windows Vista из-за слишком маломощного, или лишенного ключевых функций оборудования. Но такое оборудование идеально для использования тонкого клиента Windows®. Рис. 1 иллюстрирует требования Windows Vista, позволяя пользователям оборудования узнать, подпадает ли оно под них.
Figure 1 Требования к оборудованию для Windows Vista (Close Figure 1)

Оборудование | Требования
ЦП | Рекомендованное значение – 1 ГГц и более. Скорость ЦП может определять полезность Windows Vista. Медленный одноядерный ЦП не подойдет для нее, но может прекрасно послужить тонкому клиенту. В случае наличия каких-либо планов относительно x64 отметьте, что обновление оборудования для перехода на Windows Vista является идеальным моментом для их реализации и перехода на x64 в процессе общего обновления.
Память | Рекомендованное значение – 1 ГБ и более. Память часто можно добавить к системе, но подумайте, будет ли рентабельно устанавливать память на десятках, сотнях и тысячах систем.
Графический процессор | 128МБ+ и более, DirectX® 9.0 с драйвером WDDM и поддержкой Pixel Shader 2.0. Несоответствие здесь может и не стать препятствием, поскольку оно в основном ограничивает поддержку Aero.
HDD | 40 ГБ и более. Чаще бывает проблемой на мобильных системах, чем на настольных.
Проблемы с драйверами | Доступны ли драйверы Windows Vista для всех устройств в компьютере?
TPM | Если необходима поддержка BitLocker, не требующая флэш-накопителя USB, компьютер должен иметь оборудование TPM 1.2.

Итак, для чего годится тонкий клиент?
Используя старое оборудование и сравнительно маленькие операционные системы можно создавать интерактивные терминалы для общих помещений и приемных, позволяя пользователям перехватывать последнюю электронную почту точно так же , как в офисах Майкрософт. Можно устанавливать системы, использующие клиент удаленного рабочего стола или аккуратно управляемый экземпляр Internet Explorer®. Microsoft PowerPoint® и клиент удаленного рабочего стола почти что сами по себе достаточны для установки систем проигрывания презентаций в конференц-залах. Сочетания старого оборудования с тонкими клиентами можно также использовать для торговых терминалов или интерактивных терминалов поиска работы. Так какой же тонкий клиент стоит использовать?

Windows XP Embedded
Я уже упоминал в предыдущем выпуске этой рубрики, что Windows XP Embedded была разработана как пластичная, разбитая на компоненты версия Windows XP. Как рассказывалось в статье Дона Джонса (Don Jones) за апрель 2007 (см. technetmagazine.com/issues/2007/04/XPe), существует несколько средств для создания образов Windows XP Embedded и основным из них является Target Designer (см. рис. 2). Target Designer позволяет создать собственный, индивидуализированный образ Windows XP Embedded.
Рис. 2 Образ Windows XP Embedded, созданный Target Designer
Рис. 2 Образ Windows XP Embedded, созданный Target Designer
Отметьте, что Target Designer поставляется с несколькими шаблонами форм, помогающими приступить к работе. Само собой, это можно сделать и самому, но использование шаблона существенно упрощает вещи. На рис. 2 можно увидеть консоль для игр/интерактивного терминала и шаблоны терминалов на основе Windows, которые являются хорошей стартовой точкой. Windows XP Embedded также дает полную поддержку устройств и встроенное управление питанием, подобно полному образу операционной системы (нужно просто встроить их в свой образ). Само собой, чем больше компонентов добавляется, тем больше оборудования требуется, так что выбор стоит делать обдуманно. Значительный объем информации о Windows XP Embedded доступен на веб-узле Майкрософт: microsoft.com/windows/embedded/eval/xpe/default.mspx.

Windows Embedded для пунктов обслуживания
Windows Embedded для пунктов обслуживания предоставляет полностью стандартизированный шаблон для систем пунктов обслуживания (POS), созданных на основе Windows XP Embedded. WEPOS предоставляет встроенную поддержку различной периферии, связанной с POS, и предназначается в первую очередь для использования в розничной торговле и гостиничном бизнесе. В отличие от Windows XP Embedded, она предоставляет жестко фиксированный набор функций, предназначенных именно для этой роли и ее нельзя настраивать так же гибко, как Windows XP Embedded.
Платфоома WEPOS разработана систем с минимальнейшими конфигурациями, требуя всего лишь процессор Pentium II 233 МГц (или более быстрый), 64 МБ ОЗУ и только 280 МБ на основу образа операционной системы. Подробная информация о WEPOS и ссылки, по которым можно заказать пробную версию, доступны на microsoft.com/windows/embedded/wepos.

Windows Fundamentals для устаревших ПК
В отличие от Windows XP Embedded и WEPOS, в первую очередь предназначенных для поставки прямо на устройствах, Windows Fundamentals для устаревших ПК (FLP) лицензирована как компонент Software Assurance и разработана для использования в этом конкретном сценарии . Рис. 3 показывает экран установки Windows FLP, предлагающий выбор из четырех вариантов конфигурации: минимальной, типичной, полной и подбираемой пользователем.
Рис. 3 Установка Windows FLP
Рис. 3 Установка Windows FLP
Windows FLP требует 64 MБ ОЗУ, 500МБ или более дискового пространства и разрешение экрана 800x600, либо лучшее. Действительные требования к дисковому пространству могут варьироваться, в зависимости от выбранных для установки компонентов ОС.
Для тех, кто ищет относительно гибкую, минимизированную операционную систему для использования на устаревшем оборудовании и уже имеет Software Assurance, Windows FLP является хорошим вариантом. См. microsoft.com/licensing/sa/benefits/fundamentals.mspx, чтобы получить дополнительные сведения о том, как Windows FLP предоставляет гладкий переход на новейшее оборудование и операционные системы.

Рационально скомпонованная Windows XP
В дополнение к этим уменьшенным версиям, Windows XP, как она есть, может быть идеальным вариантом. В случае недостатка ОЗУ, отключение таких служб, как темы Windows и прочие, может сэкономить достаточно системных ресурсов для обеспечения адекватной работы. Следует, однако, следить за тем, что отключается, и за тем, не нарушается ли при этом безопасность (например, путем отключения брандмауэра Windows).

Что не будет работать
Увы, пользователи часто пытаются найти другие варианты использования Windows для облегченных систем. Ниже приведены наиболее очевидные из них и причины, по которым они не будут работать, как можно ожидать.
Windows XP Starter Edition приспособлена для использования на системах с ограниченными ресурсами, но предназначена в первую очередь для использования в области разработки технологий и доступна только как лицензионная копия Windows с OEM, включаемого на новые ПК, предназначенные для этой цели. Следовательно, обычно это не вариант. Те, кому он любопытен, могут заглянуть сюда: microsoft.com/presspass/newsroom/winxp/WinXPStarterFS.mspx.
Точно так же Windows PE не является подходящим вариантом. Что любопытно, в ходе разработки Windows PE первоначально обдумывалось ее использование как облегченной ОС. Однако в итоге она была разработана для использования вовсе не в качестве облегченной ОС, а в качестве минимизированной, сфокусированной на развертывании, среды предустановки. В частности, Windows PE не имеет оболочки, кроме командной строки (и добавить работоспособную оболочку непросто), а также определенного набора API-интерфейсов, управления питанием и поддержки звука.
Урезанная версия Windows XP также не является хорошим решениям. Мне приходилось слышать, что один из возможных вариантов – урезание Windows. Я имею в виду не просто отключение служб, а удаление приложений, для создания облегченной установки Windows. Я решительно не рекомендую этот вариант. Урезание Windows путем удаления двоичных файлов грозит сделать ее нестабильной или небезопасной. Если необходима уменьшенная версия Windows, используйте Windows XP Embedded. Она требует дополнительного изучения и подбор идеального образа занимает некоторое время, но в целом она предлагает очень широкие возможности и, что еще лучше, поддерживается Майкрософт.
Подобно минимизированной версии Windows XP, использование более старой версии Windows может выглядеть заманчиво, но отсутствия поддержки, обновлений и безопасности должно быть достаточно, чтобы передумать. Придерживайтесь решений, которые Майкрософт уже предлагает для удовлетворения потребностей в облегченных вычислительных ресурсах и извлекайте максимальную выгоду из старого оборудования, не жертвуя возможностями или безопасностью.

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


 Полевые заметки: Подготовка к &#171;ИТ 2.0&#187;
Полевые заметки
Подготовка к «ИТ 2.0»
Роми Махаян (Romi Mahajan)

В своей книге Жизнь разума выдающийся философ и эссеист Джордж Сантаяна написал: «Те, кто не помнит своей истории, обречены повторять её», указывая на величайшее значение обучения на былых ошибках для активного построения лучшего будущего. Практическая применимость этой мысли в мирах политики, культуры, истории и даже науки очевидна. Идея «учебы на ошибках» так распространена, что является клише. Но сколько из нас, работников сферы информационных технологий, действительно помнят историю и учатся на ошибках? А если таких нет, готовы ли мы хоть насколько-то к миру информационных технологий будущего? И, в самом деле, как обещает выглядеть этот будущий мир?
Что ж, давайте воспользуемся собственной памятью, чтобы предположить. Изменения за последние 30 лет были глубочайшими. ИТ эволюционировали с больших мэйнфреймов до работы компьютеров на основе обозревателей; с концентрации устройств до быстрого распространения устройств; с незрелости и редкости до сверхспециализации и распространенности; с относительной простоты до крайней сложности. Проецируя эти тенденции в будущее, мы можем ожидать, что ИТ станут более сложными, более специализированными и более демократичными. От ИТ также потребуется поддерживать всевозрастающее число и все более разнообразные типы устройств и платформ. Все это будет требовать более детального планирования, чем когда-либо ранее.
Усвоены ли эти идеи широко? Совсем нет.
Возьмем, к примеру, беседы в группе экспертов, проводивших публичное обсуждение вопроса «Потребительское перерождении ИТ», которую мне недавно пришлось возглавить на конференции по технологиям в ноябре 2007 года. Идея, породившая это обсуждение, была проста: границы между потребительскими технологиями и бизнес-технологиями расплылись, потребительнские приложения и устройства теперь направляют развитие ИТ и, следовательно, ИТ-отделам необходимо встретить во всеоружии семейство явлений, представителями которого являются Facebook, iTune, BlackBerry и их подобия. Простая идея? Очевидная? С бородой?
Судя по реакции присутствовавших в зале, никак нет. Из примерно 100 человек только четверо упомянули, что бывают на Facebook. «Это для молодежи,» заметил один участник. «Но не являются ли сотрудники, которых поддерживает ваш ИТ-отдел молодежью, использующей Facebook?» спросил один из ведущих обсуждение. Последовало замешательство и отрицание. По пальцам можно было пересчитать число ИТ-управленцев в зале, чувствовавших необходимость расширения своей организации путем найма людей, понимающих, как создавать и поддерживать приложения и устройства на новых платформах, на которых приходится основная часть времени реального взаимодействия обычных пользователей с технологией.
Когда был задан вопрос, как создавать эффективные ИТ-политики, управляющие использованием и безопасностью пересекающихся технологий, таких как мобильные телефоны и переносные компьютеры, используемые как на работе, так и дома, публика была многогласна, но предлагала мало основательных мнений. Общие чувства были просуммированы одним из участников, сказавшим в драконовской манере, типичной для ИТ 1.0: «Если бы кто-нибудь из моих сотрудников подключил проигрыватель MP3 к рабочему компьютеру, или случайно оставил выданный на работе мобильный телефон в баре, я бы его уволил».
Угу. Флаг в руки.
Другая область, в которой обнаруживается эта бедность мысли, – это сухость конференций, предназначенных для ИТ-руководителей. Если я увижу еще одну программу конференции, посвященную неопределенным вещам, вроде «ориентации ИТ-бизнеса» или «распространенного представления результатов», то, думаю, перестану ездить на них. Почему так мало людей спрашивает, на что будут похожи ИТ 2.0 и что нужно сделать, чтобы опередить время? Почему нам не интересно, какие умения и отношение к делу будут нужны новому поколению ИТ-специалистов для создания динамичного будущего? Почему мы не жалуемся на то, что ни одна компания не рассматривает свой ИТ-отдел в том же ключе, в котором компании, двигающие прогресс, думают о своих исследовательских отделах? Вместо дебатов о сравнительных преимуществах централизации и децентрализации, почему бы не взяться за реальную проблему сравнения ИТ-тоталитаризма с ИТ-демократией?
Нам стоит любить себя немного больше путем заботы о собственном будущем. Все мы слышали о «Сети 2.0». Пора начинать думать об ИТ 2.0, если собираемся воплотить в жизнь что-нибудь хотя бы отдаленно соответствующее возможностям технологии.

Роми Махаян (Romi Mahajan) является директором группы технического аудита и платформенного маркетинга в корпорации Майкрософт. Роми принадлежит множество публикаций в различных сферах, в том числе о политике, защите окружающей среды, технологиях и по социологии.


 О Windows из первых рук: Как бета-версии становятся версиями-кандидатами
О Windows из первых рук
Как бета-версии становятся версиями-кандидатами
Рэймонд Чен (Raymond Chen)

В былые времена Windows® предварительные версии продукта следовали довольно стандартной схеме. Первыми были альфа-версии, использовавшиеся внутренне и порой предоставляемые партнерам по разработке программного обеспечения за пределами группы разработчиков Windows.
После альфа-версий, естественно, следовали бета-версии, рассылавшиеся несколько более широкой аудитории. Крупным различием между пользователями альфа- и бета-версий было то, что выпуск бета-версии затрагивал людей, не являющихся разработчиками ПО, таких как конечные пользователи, которые хотели протестировать предварительную версию программы, и корпорации, которым нужна была фора в оценке новой ОС для определения совместимости нового продукта не только с их важнейшими собственными приложениями, но и с их корпоративной сетью, стандартными конфигурациями оборудования и средствами управления системой.
Наконец, имелись версии-кандидаты. Они, как следует из имени, были версиями кода, являвшимися кандидатами на выпуск в виде окончательной версии. Другими словами: «Если все пойдет хорошо, мы отправляем эту малышку в продажу». В случае обнаружения какой-либо ужасной ошибки, ставившей крест на этих ожиданиях, сразу после исправления данной ошибки собиралась новая версия-кандидат, и цикл тестирования начинался снова. В случае Windows 95 в продажу была направлена шестая версия-кандидат.
Мне рассказали, что разработчики Windows NT® следовали тому же шаблону именования версий, но столкнулись с проблемой: корпорации не утруждали себя тестированием своих ключевых приложений на бета-версиях Windows NT. Логика обычно была примерно следующей: «Чего ради стараться? Это только бета. Беты – для фанатов. В окончательном выпуске все в любом случае будет другим. А тестирование сейчас будет просто потерей времени».
Аналогично, производители программного обеспечения не обращали внимание на проблемы, найденные в ходе бета-тестирования Windows NT. «Мы не поддерживаем бета-версии операционных систем», – отвечали они.
Эти компании брались за тестирование всерьез только после выхода версий-кандидатов и неизменно находили кучу проблем. Некоторые из этих проблем компании могли разрешить своими силами, тогда как другие были более сложными и касались «недостаточной совместимости» Windows NT с предыдущими версиями операционной системы. Возникали мелкие загвоздки в том, как работали те или иные компоненты проектов, и некоторые из них порой могли быть быстро исправлены. Но некоторые проблемы были настолько серьезны, что выпуск продукта откладывался, чтобы разработчики могли разрешить их.
Версии-кандидаты также создавали массу предложений. Мы получали отзывы вроде: «Мы думаем, что интерфейс пользователя будет выглядеть лучше, если переставить кнопки вот так», или: «Перефразировав это сообщение, можно сделать его менее сбивающим с толку для наших сотрудников». Эти предложения были бы отличными, будь они получены в процессе бета-тестирования, но к моменту выпуска первой версии-кандидата вносить изменения в интерфейс давно уже поздно. Файлы документации и справки уже написаны, продукт переведен на десятки языков, а снимки экрана для руководства и коробки продукта уже сверстаны, настроены, прошли цветоделение и отпечатаны. Всю эту работу нельзя начинать с начала только ради перемещения кнопки.
Я припоминаю встречу в эпоху Windows XP, на которой обсуждалось одно из этих изменений в последний момент. Предлагаемое изменение потребовало бы изменения 20-килобайтного файла справки для приведения указаний в соответствии с новым интерфейсом пользователя. Представитель отдела локализации и перевода сообщил нам, что повторный перевод измененного файла справки в крайне ограниченный срок будет стоить сотни тысяч долларов.
Чтобы как-то побороть отношение «бета-версии не считаются», группа разработчиков Windows NT прибегла к словесным играм с раздутием рангов. Бета-версии по-прежнему существуют, но поздние бета-версии, когда еще есть время (хоть и немного) для выполнения каких-то отладок, теперь известны как версии-кандидаты, а то, что раньше называлось версиями-кандидатами, теперь именуются «условно завершенными сборками». Слова «условно завершенная» хорошо передают реальное состояние сборки: «Она закончена, и мы не собираемся касаться ее, если не возникнет действительно экстренной ситуации».

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