 TechNet Magazine February 2007
TechNet Magazine February 2007
FEBRUARY 2007
Администрирование в операционной системе Windows

В этом месяце Марк Руссинович (Mark Russinovich) наведет лупу на ядро Windows Vista и объяснит суть новых алгоритмов измерения производительности процессов и потоков, которые дают нам более точное представление о том, на что тратится время процессора. Кроме того, будет рассмотрена служба планирования мультимедийных классов (Multimedia Class Scheduler Service), которая за счет улучшенного управления фоновыми задачами (например, работой антивируса и индексацией содержимого) обеспечивает более высокое качество воспроизведения звука и видео.

Еще в этом месяце мы познакомимся со средствами делегирования в службе каталогов Active Directory и шаблонами групповых политик в Windows Vista, которые расширяют возможности групповых политик по сравнению с предыдущей версией. Ну и, разумеется, наши обычные рубрики: «Кабельщик», «Эй, программист!» и «Конфиденциальная информация Windows».
СТАТЬИ
Администрирование в операционной системе Windows Внутреннее устройство ядра Windows Vista: Часть I

Изменения в ядре Windows Vista улучшили многие аспекты работы системы, начиная с управления памятью и заканчивая надежностью и безопасностью. Мы начнем эту серию статей с усовершенствований в управлении процессами, потоками и вводом-выводом.

Марк Руссинович Делегирование полномочий в службе каталогов Active Directory

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

Джоэл Йокер (Joel Yoker) и Роб Кэмпбелл (Rob Campbell) Подробно о новых шаблонах групповых политик в Windows Vista

В Windows Vista внесены существенные изменения в шаблоны групповых политик. Узнайте все о новом формате ADMX, а также об улучшениях в управлении конфигурацией системы в связи с этими изменениями.

Даррен Мар-Элиа (Darren Mar-Elia) Руководство по отладке групповых политик

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

Дерек Мелбер (Derek Melber) Наблюдение за службой каталогов Active Directory с помощью MOM

Пакеты управления для программ Microsoft Operations Manager 2005 позволяют более эффективно наблюдать за ИТ-инфраструктурой. Вы узнаете, как пять описанных в этой статье пакетов помогают следить за текущим состоянием, безопасностью и надежностью работы всей службы каталогов Active Directory.

Джон Ханн (John Hann) Как играть в безопасной среде

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

Мэтт Клэпэм (Matt Clapham)
РАЗДЕЛЫ
От редактора

Заглянем под капот

Джошуа Трупин (Joshua Trupin) Инструментарий

Новые продукты для ИТ-специалистов

Грэг Стин (Greg Steen) SQL: вопросы и ответы

Размер базы данных, зеркальное отображение, помеченные транзакции и прочее

Под редакцией Нэнси Мичел (Nancy Michell) Обзор служебных программ

Инвентаризация групповых политик

Грэг Стин (Greg Steen) Кабельщик

Поддержка службы QoS в Windows

Джозеф Дэвис (Joseph Davies) 		Windows PowerShell

Поэтапное создание сценариев

Дон Джонс (Don Jones) Эй, программист!

XML и охота на автомобиль

Программисты корпорации Майкрософт В поисках безопасности

Развертывание файловой системы EFS. Часть I

Джон Морелло (John Morello) Файлы рабочего стола

Расширение формата Windows PE

Вэс Миллер (Wes Miller) Заметки на полях

Ну не работает, и все тут

Рыкандар Коррати (R'ykandar Korra'ti) Конфиденциальная информация Windows

Смешанное содержимое: за и против

Рэймонд Чен (Raymond Chen)


 Администрирование в операционной системе (ОС) Windows: Внутреннее устройство ядра ОС Windows Vista: Часть 1
Администрирование в операционной системе (ОС) Windows Марк Руссинович

Внутреннее устройство ядра ОС Windows Vista: Часть 1
Краткий обзор:
  • Приоритет и планирование потоков
  • Файловые символические ссылки
  • Отмена операций ввода-вывода

Это £ первая статья серии, посвященной нововведениям в ядре ОС Windows Vista. В этой работебудут затронуты изменения в области процессов, потоков и ввода-вывода. Следующие статьи будут посвящены управлению памятью, запуску и завершению работы, надежности и восстановлению, а также безопасности.
Данная статья охватывает изменения только ядра ОС Windows Vista™, в особенности файла Ntoskrnl.exe и связанных с ним компонентов. Следует помнить, что многие существенные изменения в ОС Windows Vista не затрагивают собственно ядро системы, и следовательно, здесь рассмотрены не будут. Это касается усовершенствований оболочки (например интегрированный поиск на рабочем столе), работы в сети (например новый стек IPv6 и двусторонний брандмауэр) и графической модели нового поколения (Aero™ Glass, платформа Windows® Presentation Foundation, диспетчер окон рабочего стола и новая модель графических драйверов). Также не будет рассмотрена новая инфраструктура драйверов пользовательского режима (UMDF) и режима ядра (KMDF) ОС Windows, поскольку ее можно устанавливать и на более ранние версии этой операционной системы.

Счетчик циклов центрального процессора
ОС Windows Vista содержит множество усовершенствований в области процессов и потоков, включая использование счетчика циклов центрального процессора для более равномерного выделения ресурсов, а также новую службу Multimedia Class Scheduler Service (MMCSS), способствующую безошибочному воспроизведению содержимого мультимедийными приложениями.
Все версии ОС Windows NT® до Windows Vista включительно выполняют подпрограммы прерывания интервального таймера примерно каждые 10 или 15 мс, в зависимости от аппаратной платформы. Данная подпрограмма обновляет статистику загрузки центрального процессора (ЦП) потоком, который ею прерван, так как если бы этот поток выполнялся весь интервал, хотя в действительности выполнение потока могло начаться перед самым завершением данного интервала. Далее поток мог формально получить ресурсы ЦП, но не получить возможности выполняться, поскольку вместо этого могли быть выполнены подпрограммы аппаратного или программного прерывания .
Подсчет времени на основе интервалов может подходить средствам диагностики, сообщающим загрузку ЦП процессами и потоками, но использование этого способа планировщиком потоков может приводить к нерациональному распределению ресурсов ЦП. По умолчанию клиентские версии ОС Windows позволяют выполнение потоков длительностью до 2 тактов (до 6 тактов на переднем плане). Однако на самом деле поток может совсем не получить времени ЦП, или же получить до 6 циклов (до 18 циклов на переднем плане), в зависимости от его поведения и прочей активности в системе.
Рисунок 1 демонстрирует случай нерационального распределения ресурсов, которое может произойти, если два потока с одинаковым приоритетом готовы к выполнению одновременно. Поток A выполняется до завершения следующего временного интервала, когда планировщик предполагает, что он выполнялся в течение всего интервала, и поэтому решает, что очередь потока A закончилась. Более того, потоку A засчитывается еще и прерывание, произошедшее во время его выполнения. На следующий интервал планировщик отдает предпочтение потоку B, который выполняется в течение полного интервала.
Рисунок 1 Неравномерное выделение ресурсов потокам
Рисунок 1 Неравномерное выделение ресурсов потокам
В ОС Windows Vista планировщик отслеживает точное количество циклов ЦП, в течение которых выполняется поток, с помощью регистра счетчика циклов современных процессоров. Определив, сколько циклов может выполнить процессор на протяжении интервала времени, планировщик может точнее раздавать ресурсы ЦП. К тому же, планировщик ОС Windows Vista не засчитывает выполнение прерывания во время выполнения потока. Это означает, что поток в ОС Windows Vista всегда получит, по крайней мере, свою очередь выполнения, не превышающую один дополнительный временной интервал, что обеспечивает более справедливое выделение ресурсов и предсказуемое поведение приложений. На рис. 2 показана реакция ОС Windows Vista на ситуацию, изображенную на рис. 1, выделением обоим потокам, по меньшей мере, по одному временному интервалу выполнения.
Рисунок 2 Планирование распределения ресурсов на основе циклов в ОС Windows Vista
Рисунок 2 Планирование распределения ресурсов на основе циклов в ОС Windows Vista
Врезка «Наблюдение за загрузкой ЦП процессом» демонстрирует, как можно наблюдать за использование процессом циклов ЦП с помощью программы Process Explorer.

Служба Multimedia Class Scheduler Service
Пользователи ожидают от мультимедийных приложений, таких как проигрыватели аудио и видео, ровного и безошибочного воспроизведения. Однако из-за занятости ЦП другими параллельно выполняющимися приложениями, например антивирусными программами, индексированием содержимого или даже почтовым клиентом могут возникать неприятные задержки и прерывания. Для обеспечения более качественного воспроизведения в ОС Windows Vista вводится служба MMCSS, управляющая приоритетами мультимедийных потоков для выполнения процессором.
Мультимедийное приложение, например проигрыватель Windows Media®, регистрируется в службе MMCSS с помощью новых функций прикладного интерфейса, отображающих его мультимедийные характеристики, которые должны совпадать с характеристиками, перечисленными по именам в следующем разделе реестра:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\Tasks

Рисунок A Просмотр времени ЦП и разницы циклов в программе Process Explorer (Щелкните изображение, чтобы уменьшить его)
Рисунок A Просмотр времени ЦП и разницы циклов в программе Process Explorer
Рисунок A Просмотр времени ЦП и разницы циклов в программе Process Explorer (Щелкните изображение, чтобы увеличить его)

Рис. 3 Определение аудиозадачи в планировщике классов мультимедиа
Рис. 3 Определение аудиозадачи в планировщике классов мультимедиа (Щелкните изображение, чтобы уменьшить его)
Рис. 3 Определение аудиозадачи в планировщике классов мультимедиа
Рис. 3 Определение аудиозадачи в планировщике классов мультимедиа (Щелкните изображение, чтобы увеличить его)
Служба MMCSS, реализованная в файле %SystemRoot%\System32\Mmcss.dll и запускаемая в процессе работы узла службы (Svchost.exe), имеет поток управления приоритетами, который выполняется с приоритетом 27. (Приоритеты потоков в ОС Windows находятся в диапазоне от 0 до 31). Этот поток повышает приоритет зарегистрированных потоков мультимедиа до диапазона, связанного со значением Scheduling Category раздела реестра данной задачи, как показано на рисунке 4. В системе Windows приоритеты потоков от 16 и выше относятся к диапазону приоритетов реального времени, что выше приоритета любых потоков в системе (за исключением рабочих потоков диспетчера памяти, которые выполняются с приоритетом 28 или 29). Права на увеличение приоритета, необходимые для установки приоритетов потоков реального времени, есть только у учетных записей с правами администратора, например у локальной системной учетной записи, в которой выполняется служба MMCSS.
Figure 4 Приоритеты потоков службы MMCSS (Close Figure 4)

Категория планирования | Повышенный приоритет потока
Высокий | 23-26
Средний | 16-23
При проигрывании звукового файла проигрыватель Windows Media регистрирует потоки задачи аудио, а при проигрывании файла видео £ потоки задачи воспроизведения. Служба MMCSS повышает приоритет всех потоков, заявивших о доставке потоковых данных, одновременно, когда они выполняются в процессе, которому принадлежит окно переднего плана, и если в разделе определения их задачи значение BackgroundOnly установлено в True.
Но в то время, как служба MMCSS помогает потокам мультимедиа получить необходимое время ЦП, она также гарантирует получение, по крайней мере, части процессорного времени другими процессами для обеспечения реакции системы и других приложений. Следовательно, служба MMCSS резервирует для других действий определенную часть процессорного времени , заданную в следующем разделе реестра:
HKLM\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\SystemResponsiveness
По умолчанию это составляет 20 процентов, т.е. служба MMCSS отслеживает загрузку ЦП и не разрешает выполнение потоков с повышенным приоритетом в течение времени свыше 8 мс из 10, если ресурсы ЦП запрашиваются другими потоками. Чтобы потоки мультимедиа не мешали другим потокам в течение остальных 2 мс, планировщик понижает их приоритет до диапазона от 1 до 7.
Повышение приоритета потоков службой MMCSS можно увидеть на врезке «Наблюдение за повышением приоритета службой MMCSS».

Файловые символические ссылки
Изменения, относящиеся к операциям ввода-вывода в ОС Windows Vista, включают в себя файловые символические ссылки, более эффективную обработку завершения операций ввода-вывода, полную поддержку отмены операций ввода-вывода и поддержку приоритетов операций ввода-вывода.
Одной из функций файловой системы, которой по мнению многих недоставало в системе NTFS, является поддержка символических ссылок на файлы (или, как они называются в UNIX-системах, гибких ссылок), которая появилась в ОС Windows Vista. В версии NTFS для Windows 2000 были представлены символические ссылки на каталоги, которые назывались соединениями каталогов, что позволяло создавать каталоги, указывающие на другие каталоги, но до выхода ОС Windows Vista файловая система NTFS поддерживала только жесткие ссылки на файлы.
Основным отличием в том, как в ОС Windows разрешаются символические ссылки и соединения каталогов, является способ их обработки. ОС Windows обрабатывает символические ссылки в локальной системе даже если они ссылаются на место на удаленном файловом сервере. ОС Windows обрабатывает соединения каталогов, ссылающиеся на удаленный файловый сервер, на самом сервере. Символические ссылки на сервере могут, таким образом, ссылаться на местоположения, доступные только с клиентских компьютеров, например тома на других клиентских компьютерах, что невозможно для соединений каталогов. Для решения этой проблемы ОС Windows Vista поддерживает новый тип символических ссылок как для файлов, так и для каталогов.
Многие команды файловой системы обновлены для учета особенностей символических ссылок. Например, команда Delete (Удалить) не следует по ссылке, что приводило бы к удалению целевого объекта, а удаляет саму ссылку. Однако в связи с тем, что некоторые приложения могут неправильно обрабатывать символические ссылки, для создания таких ссылок необходимы права на создание символических ссылок, которые по умолчанию имеются только у администраторов.
Символическую ссылку можно создать из командной строки с помощью команды Mklink. Встроенная команда вывода содержимого каталога командной строки обозначает символические ссылки пометкой <SYMLINK> и показывает конечный объект в квадратных скобках, как показано на рисунке 5. Проводник Windows также понимает символические ссылки и отображает их со стрелкой как ярлыки. Конечный объект ссылки можно видеть в Проводнике, если добавить к окну обзора столбец Link Target (Цель ссылки).Просмотр повышения приоритетов службой MMCSS
Убедиться в повышении приоритета потоков проигрывателя Windows Media службой MMCSS можно включив воспроизведение видео или звукового клипа, запустив системный монитор, установив масштаб графика равным 31 (наивысший приоритет потока в ОС Windows) и добавив счетчик Priority Current (Текущий приоритет) для всех экземпляров объектов потоков проигрывателя Windows Media (Wmplayer.exe). Один или несколько потоков будут выполняться с приоритетом, равным 21.
Рисунок B Повышение приоритета потока проигрывателя Windows Media
Рисунок B Повышение приоритета потока проигрывателя Windows Media (Щелкните изображение, чтобы уменьшить его)
Рисунок B Повышение приоритета потока проигрывателя Windows Media
Рисунок B Повышение приоритета потока проигрывателя Windows Media (Щелкните изображение, чтобы увеличить его)

Рисунок 5 Создание символической ссылки с помощью команды Mklink
Рисунок 5 Создание символической ссылки с помощью команды Mklink (Щелкните изображение, чтобы уменьшить его)
Рисунок 5 Создание символической ссылки с помощью команды Mklink
Рисунок 5 Создание символической ссылки с помощью команды Mklink (Щелкните изображение, чтобы увеличить его)

Завершение и отмена операций ввода-вывода
В систему ввода-вывода введено множество внутренних изменений, которые могут улучшить производительность серверных приложений. Как правило, такие приложения используют объект синхронизации, называемый портом завершения, для ожидания завершения асинхронных запросов ввода-вывода. До выхода ОС Windows Vista при завершении операции ввода-вывода инициировавший данную операцию поток выполнял задачу завершения ввода-вывода, что приводило к переключению в процесс, к которому принадлежал данный поток, и прерыванию прочих действий. Затем система ввода-вывода обновляла состояние порта завершения, что приводило к возобновлению потока, ожидавшего изменения состояния порта.
В ОС Windows Vista обработка завершения ввода-вывода выполняется не потоком, инициировавшим операцию ввода-вывода, а потоком, ожидающим изменения состояния порта завершения. Это относительно небольшое изменение позволяет избежать ненужного планирования выполнения потоков и переключения контекста, что приводило к снижению общей производительности системы и приложений. Для еще большего повышения производительности сервер может получать результаты разных операций ввода-вывода от завершения одним запросом, избегая переходов в режим ядра.
Вероятно, одним из наиболее заметных нововведений в систему ввода-вывода с точки зрения конечного пользователя является поддержка в ОС Windows Vista отмены синхронных операций ввода-вывода. Всем, кто когда-либо выполнял команду net view или пытался обратиться к общему ресурсу на выключенном удаленном компьютере под управлением ОС Windows XP или Windows Server® 2003, знакомы проблемы с операциями ввода-вывода, которые невозможно отменить: команда или окно проводника не отвечали до истечения времени ожидания сети. Приложению не оставалось ничего иного, кроме как ожидать ошибки выполнения операции, поскольку не существовало способа оповестить драйвер устройства, выполняющий операцию ввода-вывода, о том, что данную операцию выполнять уже не нужно.
Большинство операций ввода-вывода в ОС Windows Vista можно отменить, включая операцию открытия файла, которую используют команда Net View и Проводник. Однако для того, чтобы приложения отвечали на запросы пользователя об отмене операции ввода-вывода, их необходимо обновить, и многие служебные программы ОС Windows Vista, взаимодействующих с устройствами, имеющими интервал ожидания, уже поддерживают данную возможность. Например, в диалоговых окнах открытия и сохранения файлов, применяющихся практически во всех приложениях ОС Windows, включая сторонние приложения, теперь во время отображения содержимого папки доступна кнопка Cancel (Отменить). Синхронные операции ввода-вывода команды Net также могут быть отменены нажатием комбинации клавиш Ctrl+C.
В преимуществах возможности отмены операций ввода-вывода легко убедиться, открыв окно командной строки в ОС Windows Vista и набрав команду:
net view (\\nonexistentmachine)
Команда не будет отвечать до тех пор, пока ОС Windows будет пытаться связаться с несуществующей системой, но ее можно будет прервать, воспользовавшись сочетанием клавиш Ctrl+C. В ОС Windows XP комбинация клавиш Ctrl+C не действовала и команда не отвечала до истечения срока ожидания сети.
Еще одной разновидностью проблем с вводом-выводом в предыдущих версиях ОС Windows было то, что драйверы устройств не могли быть отменены должным образом, поскольку не существовало простого способа известить их об этом. Если пользователю приходилось завершать процесс, а затем видеть, как он остается в списке процессов, было можно наблюдать, как драйвер устройства не может ответить на запрос завершения процесса и отмены операции ввода-вывода, инициированной незавершенным процессом. ОС Windows не может окончательно завершить процесс до того, как все операции ввода-вывода данного процесса не будут либо завершены, либо отменены. В ОС Windows Vista драйверы устройств без проблем регистрируют извещения о завершении процесса, так что большинство проблем, связанных с незавершаемыми процессами, остались в прошлом.

Приоритет операций ввода-вывода
Несмотря на то, что операционная система Windows всегда поддерживала приоритеты использования ЦП, в ней отсутствовало понятие приоритетов операций ввода-вывода. Без поддержки приоритетов ввода-вывода фоновые операции, например индексация поиска, поиск вирусов и дефрагментация диска могут существенно ухудшать скорость ответа операций переднего плана. Пользователь, запускающий приложение или открывающий документ в то время, как другой процесс выполняет, например, операцию дискового ввода-вывода, сталкивается с задержками, поскольку приложению переднего плана приходится дожидаться доступа к диску. С теми же препятствиями сталкивается воспроизведение с жесткого диска потокового мультимедийного содержимого, например песни.
ОС Windows Vista обеспечивает два новых способа распределения приоритетов для предоставления предпочтения операциям ввода-вывода переднего плана: приоритеты на отдельные операции ввода-вывода и резервирование полосы пропускания ввода-вывода. Система ввода-вывода в ОС Windows Vista обеспечивает внутреннюю поддержку приоритетов операций ввода-вывода, как показано на рисунке 6, но используются только четыре приоритета (возможно, следующие версии ОС Windows будут поддерживать приоритет High (Высокий)).
Figure 6 Приоритеты ввода-вывода в ОС Windows Vista (Close Figure 6)

Приоритет операций ввода-вывода | Применение
Критический | Диспетчер памяти
Высокий | Не используется
Нормальный | Приоритет по умолчанию
Низкий | Приоритет задачи по умолчанию
Очень низкий | Фоновые операции
Приоритетом по умолчанию для операций ввода-вывода является Medium (Средний), а диспетчер памяти использует приоритет High (Высокий) для записи на диск содержимого памяти в ситуациях нехватки памяти для освобождения ОЗУ для других данных и кода. Планировщик задач ОС Windows устанавливает приоритет по умолчанию для задач ввода-вывода Low (Низкий), а написанные для ОС Windows Vista приложения, осуществляющие фоновую обработку, указывают приоритет Very Low (Очень низкий). Все фоновые операции в ОС Windows Vista, включая сканирование Windows Defender (Защитник ОС Windows) и индексирование поиска на рабочем столе, используют приоритет ввода-вывода Very Low (Очень низкий).Просмотр операций ввода-вывода с приоритетом Very Low (Очень низкий)
Служебная программа реального времени Process Monitor от компании Sysinternals для наблюдения за файловой системой и реестром собирает подробную информацию об операциях чтения и записи файловой системы, включая приоритеты ввода-вывода в ОС Windows Vista. Выделенная строка демонстрирует пример запроса с очень низким приоритетом ввода-вывода, инициированного компонентом SuperFetch (который будет рассмотрен в следующей статье цикла).
Рисунок C Просмотр операций ввода-вывода с приоритетом Very Low (Очень низкий) при помощи программы Proces Monitor
Рисунок C Просмотр операций ввода-вывода с приоритетом Very Low (Очень низкий) при помощи программы Proces Monitor (Щелкните изображение, чтобы уменьшить его)
Рисунок C Просмотр операций ввода-вывода с приоритетом Very Low (Очень низкий) при помощи программы Proces Monitor
Рисунок C Просмотр операций ввода-вывода с приоритетом Very Low (Очень низкий) при помощи программы Proces Monitor (Щелкните изображение, чтобы увеличить его)

Драйвер устройства класса системного хранения (%SystemRoot%\System32\Classpnp.sys) обеспечивает приоритеты ввода-вывода, которые автоматически применяются к операциям ввода-вывода, ориентированных на большинство устройств хранения. Этот и другие драйверы хранения помещают в свои очереди операции ввода-вывода с приоритетом Medium (Средний) до операций с приоритетами Low (Низкий) и Very Low (Очень низкий), но при этом выполняют, как минимум, одну операцию с приоритетом Low (Низкий) или Very Low (Очень низкий) в секунду, чтобы не препятствовать выполнению фоновых процессов. Данные, прочитанные операциями с приоритетами Low (Низкий) и Very Low (Очень низкий), также приводят к тому, что диспетчер кэша производит запись изменений на диск незамедлительно, не откладывая, и обходит логику упреждающего чтения для операций чтения, что в противном случае приводило бы к упреждающему чтению из файлов, открытых для чтения. Пример операций с приоритетом Very Low (Очень низкий), выводимых программой Process Monitor, можно увидеть на боковой врезке «Просмотр операций ввода-вывода с приоритетом Very Low (Очень низкий)».
Поддержка резервирования полосы пропускания в ОС Windows Vista удобна для применения приложениями воспроизведения данных мультимедиа, и проигрыватель Windows Media пользуется ею наряду с повышением приоритетов службой MMCSS для почти безошибочного воспроизведения локального содержимого. Приложение проигрывателя мультимедиа запрашивает у системы ввода-вывода гарантии возможности чтения данных на указанной скорости и если устройство может предоставлять данные с указанной скоростью, а существующие ограничения резервирования это позволяют, оно предоставляет приложению данные о допустимой скорости и объеме операций ввода-вывода. Система ввода-вывода станет обслуживать другие операции только в том случае, если возможно удовлетворить требования приложений, зарезервировавших целевое устройство хранения.
В завершение следует упомянуть о еще одном изменении в системе ввода-вывода, относящемся к объему операций ввода-вывода. Со времен первой версии ОС Windows NT диспетчер памяти и система ввода-вывода ограничивали объем данных, обрабатываемых отдельным запросом ввода-вывода для устройства хранения, 64 КБ. Таким образом, даже если запрос ввода-вывода приложения был значительно больше, он разбивался на отдельные запросы, не превышающие 64 КБ. Каждая операция ввода-вывода подразумевала дополнительные затраты ресурсов на переключение в режим ядра и инициирование передачи ввода-вывода на устройство хранения, поэтому в ОС Windows Vista объем операций ввода-вывода больше не ограничивается. Некоторые компоненты пользовательского режима ОС Windows Vista подверглись модификациям для того, чтобы воспользоваться преимуществами большего объема операций ввода-вывода, включая функцию копирования в Проводнике и команду командной строки Copy (Копировать), которые теперь оперируют операциями ввода-вывода объемом 1 МБ.

Что дальше
Были рассмотрены две области, в которых ядро ОС Windows Vista подверглось улучшениям. Более подробное рассмотрение будет представлено в следующем издании книги Windows Internals (Внутренняя структура ОС Windows) (в соавторстве с Дэвидом Соломоном), которое должно выйти одновременно с ОС Windows Server под кодовым названием «Longhorn». В следующей статье данной серии будет продолжено знакомство с новым ядром и обсуждены вопросы управления памятью, а также запуска и завершения работы системы.

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


 Администрирование в операционной системе (ОС) Windows: Делегирование полномочий в службе каталогов Active Directory
Администрирование в операционной системе (ОС) Windows Джоэл Йокер (Joel Yoker) and Роб Кэмпбелл (Rob Campbell)

Делегирование полномочий в службе каталогов Active Directory
Краткий обзор:
  • Определение административных ролей
  • Формирование модели подразделений и групп безопасности
  • Применение вспомогательных учетных записей
  • Инструменты делегирования прав

Возможности делегирования, предусмотренные в службе каталогов Active Directory, весьма значительны; они решают ряд проблем защиты и упрощают задачи управления. Грамотное делегирование прав в службе Active
Directory® позволяет регламентировать применение в среде определенных ролей, уменьшить вероятность и нейтрализовать последствия административных ошибок, реализовать в существующей инфраструктуре принцип наименьших привилегий. В то же время, многие организации, опирающиеся в своей работе на службы Active Directory, до сих пор не воспользовались потенциалом функции делегирования. Отчасти это объясняется кажущейся сложностью разработки модели делегирования в корпоративной среде службы Active Directory. Действительно, сформировать модель делегирования, отвечающую индивидуальным потребностям предприятия, сложнее всего, но с другой стороны, существует множество простых моделей, которые можно реализовать в большинстве ИТ-сред лишь с незначительными изменениями.
Естественно, каждая среда имеет свои особенности, но все крупные предприятия во многих отношениях схожи и призваны решать одни и те же задачи в сфере ИТ. К примеру многие компании структурированы по региональному принципу, сформировались на основе отдельных инженерных или эксплуатационных рабочих групп, имеют в своем составе автономные подразделения. Кроме того, для большинства крупных организаций актуальны проблемы несанкционированного расширения полномочий, злонамеренного применения учетных записей служб и формирования «доверительных отношений».
Понятие «доверие» весьма интересно само по себе; именно им часто обосновывается необходимость создания нескольких лесов службы Active Directory. Доверительные отношения обычно формируются исходя из способности одного подразделения или региона воздействовать на доступность систем в другом подразделении или регионе. Нередко уровень компетенции специалистов в различных структурных единицах компаний бывает различным; не исключена нехватка знаний о конкретных системах, необходимых для обеспечения работы ИТ-инфраструктуры в том или ином регионе или подразделении. По этой причине подразделения не горят желанием передавать административные права «центру».
В то же время, при любой реализации службы Active Directory администраторам вменяется в обязанность установить правила обращения приложений к инфраструктуре этой службы. К сожалению, широкое распространение, в том числе среди составителей руководств по установке приложений, получил метод, согласно которому учетная запись службы вводится в состав группы «Администраторы домена». Дело в том, что учетные записи служб по существу являются универсальными. Предоставление таким учетным записям прав администратора домена создает существенную угрозу безопасности ИТ-среды. Учетные записи служб очень удобны для безответственных администраторов и злоумышленников, занимающих эту важную должность, равно как и для инициаторов атак, стремящихся воспользоваться слабыми местами системы безопасности того или иного приложения.
Эти препятствия, на первый взгляд непреодолимые, в реальности оказываются исходной предпосылкой реализации модели делегирования службы Active Directory. Разработка модели делегирования £ это итеративный процесс проектирования, в рамках которого рекомендуется выполнить следующие поэтапные действия.
  1. Регламентировать административные роли в ИТ-среде организации.
  2. Разработать модель подразделений и групп безопасности.
  3. Создать для ИТ-администраторов вспомогательные учетные записи.
  4. Делегировать права.
Рассмотрим эти этапы в деталях.

Определение ролей
Для определения ролей нужно четко представлять себе структуру администрирования служб и данных. Эти понятия лежат в основе любой модели делегирования полномочий в службе Active Directory.
По существу, администрирование служб £ это управление важнейшими компонентами инфраструктуры службы каталогов, такими как серверы Exchange и контроллеры домена. В свою очередь, администрирование данных £ это управление объектами, в том числе почтовыми ящиками и учетными записями пользователей, которые существуют в рамках служб. В рамках службы Active Directory администраторы служб отвечают за предоставление и доступность служб каталогов, а администраторы данных управляют учетными записями пользователей и служб, группами и другими ресурсами домена.
Служба каталогов Active Directory позволяет детализировать делегируемые полномочия при помощи понятия «Подразделения» (Organizational Units – OU). Подразделения во многих случаях можно настроить так, чтобы уровень предоставляемых ими полномочий соответствовал уровню, предусмотренному для администраторов в рамках существующих моделей службы каталогов или доменов. В то же время, важно понимать, что некоторые функции не подлежат делегированию и требуют управления одной единственной, исключительно надежной группой специалистов или объектом.
Не менее серьезную роль играет анализ задач. Необходимо знать, какие задачи службы Active Directory выполняются администраторами и как эти задачи можно привязать к ролям. К примеру, создание узла службы Active Directory как задача относится к администрированию служб, в то время как изменение настроек членства в группе безопасности обычно приписывается к администрированию данных. Каждую задачу требуется проанализировать на предмет регулярности, значимости и сложности. Это £ важнейшие аспекты определения задачи; исходя из них принимается решение о том, нужно ли делегировать то или иное право. Задачи, которые выполняются постоянно, создают незначительные риски и просты в осуществлении, лучше всего подходят для делегирования. Задачи, которые выполняются нерегулярно, оказывают значительное воздействие в масштабе всей организации и требуют высокого уровня компетенции, напротив, не стоит делегировать. Для выполнения таких задач лучше подходит методика «расширения» (escalation), предполагающая временное продвижение учетной записи до уровня необходимой роли или переназначение задачи.
Так как крупные организации имеют много общего, можно с уверенностью говорить о том, что реализация стандартной модели делегирования возможна. Исходя из задач этой статьи, на рассмотрение представляется набор ролей, который, с одной стороны, реализует управляющие функции, а с другой, учитывает организационную структуру и имеет своей целью частичное решение проблем, связанных с доверительными отношениями (в том числе с доступностью общекорпоративных ресурсов, каковыми являются, например, контроллеры доменов). Эта модель £ не просто пример. Она может послужить основой для формирования аналогичной модели в любой организации. С другой стороны, воспроизводить её без изменений не стоит.
Некоторые роли определяются службой Active Directory автоматически, но для формирования модели делегирования их недостаточно £ ряд ролей придется создать заново. Вот пример набора ролей, который можно успешно реализовать во многих крупных средах службы Active Directory: «Администраторы предприятия», «Администраторы домена», «Администраторы 4 класса» (для администрирования служб), «Администраторы 3 класса», «Региональные администраторы», «Администраторы 2 класса» и «Администраторы 1 класса» (для администрирования данных). Список ролей и соответствующих обязанностей приводится на рис. 1.
Figure 1 Определение ролей и обязанностей (Close Figure 1)

Администраторы служб | Описание
Администраторы предприятия | Отвечают за высокоуровневое администрирование служб в масштабе предприятия. Следует избегать членства на постоянной основе.
Администраторы домена | Отвечают за высокоуровневое администрирование служб в масштабе домена. Достаточно небольшого, поддающегося учету числа надежных администраторов.
Администраторы 4 класса | Отвечают за администрирование служб в масштабе домена. Членам этой группы должен быть предоставлен набор прав, минимально необходимый для управления вверенными им службами. Эта группа служит отправной точкой расширения полномочий администраторов данных.
Администраторы данных | Описание
Администраторы 1 класса | Отвечают за общее управление объектами каталога и выполнение таких задач, как сброс пароля, изменение свойств учетных записей пользователей и т.д.
Администраторы 2 класса | Отвечают за выборочное создание и/или удаление учетных записей пользователей и компьютеров в масштабе отдельного региона или организации в целом.
Региональные администраторы | Отвечают за управление региональной структурой подразделений. Предоставленные участникам этой группы разрешения должны быть достаточны для создания большинства объектов в рамках подразделения.
Администраторы 3 класса | Отвечают за координацию действий всех администраторов данных. Эта группа выступает в качестве службы поддержки верхнего уровня и отправной точкой расширения полномочий всех региональных администраторов.

Администраторы служб
Рассмотрим роли, относящиеся к администрированию служб, подробнее. Администраторы служб управляют важнейшими компонентами инфраструктуры; все администраторы, приписанные к этой категории, получают высокий уровень привилегий. В отношении этих ролей рекомендуется проводить стратегию наименьших привилегий, согласно которой каждому пользователю выделяется минимальный набор разрешений, необходимый для выполнения поставленных перед ним задач.
Администраторы предприятия и домена Служба Active Directory определяет две группы уполномоченных администраторов с контекстом безопасности, который позволяет выполнять в каталоге критические функции. Эти группы (администраторы предприятия и администраторы домена) осуществляют высокоуровневое администрирование служб. В целях снижения рисков, создаваемых группами со столь высоким уровнем привилегий, настоятельно рекомендуется ограничить членство в них. В группе администраторов предприятия вообще не должно быть постоянных членов; что же касается администраторов домена, то здесь достаточно небольшого, поддающегося учету числа надежных специалистов, работающих в штате организации.
Для выполнения административных задач корпоративного уровня, таких как авторизация DHCP-сервера или создание узла службы Active Directory, участники группы администраторов домена в корневом домене леса службы Active Directory могут расширить привилегии путем наполнения группы администраторов предприятия. Такие привилегии должны предоставляться только на короткое время. Цель подобной политики £ избежать постоянного членства в группе администраторов предприятия. Не стоит и говорить, что все члены группы администраторов домена в каждом конкретном лесу службы Active Directory должны быть в равной степени надежны.
При разработке модели делегирования большинство организаций совершает одну и ту же ошибку £ они отключают или сокращают функциональность встроенных ролей. Внесение изменений в стандартные роли может привести к самым неожиданным результатам; кроме того, нет никакой гарантии, что при установке пакета обновления или модернизации продукта такие настройки сохранятся. Наконец, подобного рода изменения приводят к утрате совместимости с внешней средой за пределами организации. Лучше всего оставить в силе набор встроенных групп и ролей, но ограничить членство в них. Для этого, возможно, придется создать новые роли для администраторов, которые ранее входили в группы наподобие администраторов домена.
Администраторы 4 класса В группу администраторов 4 класса должны быть включены администраторы, специализирующиеся на поддержке всех корпоративных служб. Так как это нестандартная роль, права доступа к службе каталогов и к системе можно настроить согласно конкретным требованиям организации. Несмотря на то, что члены этой группы являются администраторами служб, они могут время от времени выполнять задачи управления данными в масштабе леса. В силу неоднородности классов систем и сфер ответственности роли 4 класса в рамках каталога подразделяются на несколько подгрупп. К примеру, группы класса 4 следует создать для раздельного управления системами различных видов (в частности, серверами Exchange). Эта группа, кроме того, служит отправной точкой расширения полномочий администраторов данных.
Одна из причин, по которым пользователи часто стремятся попасть в состав участников группы администраторов домена, заключается в том, что она предоставляет административные полномочия доступа ко всем системам в данном домене. Чтобы организовать работу администраторов служб в режиме наименьших привилегий, нужно включить их в группу администраторов 4 класса и разрешить в её настройках доступ к серверам предприятия; в этом случае необходимость включения таких администраторов в группу администраторов домена отпадает. Во избежание расширения привилегий администраторам 4 класса не стоит предоставлять членство в группе BUILTIN\Administrators в контроллерах домена; дело в том, что она предусматривает ряд фундаментальных прав в отношении службы каталогов, которые нельзя разделить. К примеру, каждый член группы BUILTIN\Administrators в том или ином домене имеет право управления членством в группе администраторов домена; иными словами, у него есть возможность расширять привилегии безо всяких ограничений.
С учетом изложенного правила, запрещающего нарушение функциональности стандартных разрешений, такой риск можно сократить за счет включения администраторов 4 класса во встроенные группы домена «Операторы сервера» и «Администраторы DNS» в качестве вложенных групп. Такое решение, с одной стороны, создает механизм локального управления контроллерами домена, а с другой, ограничивает возможности администраторов 4 класса расширять привилегии. В большинстве систем (за исключением «Контроллеров домена», «Серверов сертификатов» и т.д.) группу администраторов 4 класса имеет смысл включать в состав локальной группы «Администраторы». Членство во вложенных локальных группах можно автоматизировать при помощи функций «Группы с ограниченным доступом» групповой политики.

Администраторы данных
Теперь рассмотрим роли, относящиеся к администрированию данных. В них должны предусматриваться совокупные права; иначе говоря, администратор 2 класса должен обладать всеми правами администратора 1 класса и определенным набором дополнительных прав, и так на каждом последующем уровне. По этой причине рассмотрим группы в порядке от наименьших к наибольшим привилегиям.
Администраторы 1 класса Участники группы администраторов 1 класса осуществляют общее управление ранее созданными объектами каталога. Эта группа предусмотрена для наименее компетентных администраторов, а также для лиц, выполняющих отдельные задачи (например сброс паролей). В рамках определенного подразделения этой группе нужно предоставить права изменения свойств учебных записей пользователей, сброса паролей таких учетных записей, разблокирования учетных записей, включения и отключения учетных записей пользователей, добавления и сброса учетных записей рабочих станций, а также изменения настроек членства в объектах неадминистративных групп.
Администраторы 2 класса Задача этой группы – выборочное управление и создание объектов с расчетом на то, чтобы ими смогли управлять администраторы 1 класса (к примеру, группы безопасности могут в данном случае создаваться только в подразделении «Группы»). Администраторы 2 класса вправе добавлять и изменять учетные записи администраторов 1 класса; добавлять, изменять и удалять учетные записи в рамках подразделения; удалять объекты рабочих станций; добавлять, изменять и удалять объекты «Сервер», «Контакт» и «Общая папка».
Региональные администраторы Участникам этой группы предоставляются исключительные права управления региональной структурой подразделений. В то же время, они не могут управлять другими региональными структурами подразделений, существующими в каталоге. Учетные записи, относящиеся к группе «Региональные администраторы», считаются особо привилегированными; по этой причине они хранятся в отдельной иерархии подразделений и управляют ся администраторами служб из группы администраторов 4 класса. Группа «Региональные администраторы» имеет неограниченные права на создание большинства объектов в рамках локальной структуры подразделений (исключение: право создания новых подразделений за этой группой не закреплено); в связи с этим возникает риск создания объектов, которыми администраторы более низких классов не могут управлять.
Администраторы 3 класса Во многих организациях есть централизованная или ведущая служба поддержки. Наличие этой роли увеличивает численность администраторов данных; по сути, создается отдельная, вышестоящая по отношению ко всем региональным администраторам группа администраторов данных. Эта группа не имеет прав, специально делегированных ей в рамках каталога; в данном случае права аккумулируются посредством вложенного членства в каждой из групп «Региональные администраторы». В результате на высшем уровне формируется точка расширения прав всех администраторов данных; кроме того, создается центр регистрации задач, предназначенных для передачи группам администрирования служб.

Формирование модели подразделений и групп безопасности
Справившись с определением ролей в рамках организации, переходите к формированию модели подразделений и групп безопасности. Подразделение в службе Active Directory имеет смысл создать по двум причинам. Во-первых, оно позволяет организовать делегирование прав, а во-вторых, служит точкой связывания с объектами групповой политики. Подразделения регламентируют область управления (scope-of-management – SOM) в рамках каталога; такие области, в свою очередь, помогают на разных уровнях сузить действие прав до отдельных объектов. В связи с этим определяющим фактором реализации структуры подразделений должна стать принятая схема делегирования полномочий.
Соответственно, подразделение верхнего уровня (или набор таких подразделений) нужно создать непосредственно в рамках домена; в таком случае к нему (к ним) будут отнесены все объекты. Такое подразделение служит конкретной цели £ оно определяет для администраторов 4 класса область управления наивысшего уровня. Благодаря подразделению верхнего уровня процесс явного распределения прав в отношении службы каталогов можно начать на уровне подразделений (в противном случае пришлось бы обращаться к уровню домена). Делегирование от подразделения верхнего уровня, минуя уровень домена, сокращает риск расширения привилегий пользователями путем операций со встроенными группами домена, о которых упоминалось ранее.
В составе подразделений верхнего уровня необходимо создать отдельные иерархии дочерних подразделений, представляющие все регионы или организационные единицы с обособленными группами управления данными. В целях управления объектами каталога в каждом региональном дочернем подразделении должна быть стандартная, не предусматривающая возможности расширения иерархия подразделений. Для текущего управления крайне важна согласованность, так как значительная часть процесса делегирования прав автоматизирована. Поскольку в каждом регионе может требоваться особая иерархия подразделений, согласовать их довольно трудно. В то же время, администраторы ИТ-отделов должны гнуть свою линию, и даже если в каком-то регионе приходится выполнить расширение структуры дочернего подразделения, оно должно быть воспроизведено во всех других регионах. Наверное, поначалу это будет казаться сложным, но суть в том, что если организации удастся сформировать универсальную схему систематизации объектов, со временем нештатные ситуации перестанут её беспокоить.
Наконец, создайте дочерние административные группы и учетные записи, благодаря которым администраторы не смогут расширять свои полномочия. В каждой иерархии дочернего подразделения нужно создать группы «Администраторы 1 класса», «Администраторы 2 класса» и «Региональные администраторы». Благодаря размещению таких учетных записей в отдельных подразделениях область управления ограничивается этими подразделениями или более низким уровнем. Так, если все учетные записи администраторов 1 класса и соответствующая группа безопасности размещены в подразделении, относительно которого у них нет прав, администраторы не смогут присваивать чужие административные учетные записи и расширять привилегии других администраторов до своего уровня. К примеру, каждый член группы «Администраторы домена» может присоединить к этой группе любую учетную запись пользователя, созданную в данном домене. Если же действует модель подразделений, о которой говорится, такой риск сводится к минимуму. Пример структуры подразделений с соответствующими группами безопасности представлен на рис. 2.
Рис. 2 Структура подразделений и соответствующие группы безопасности
Рис. 2 Структура подразделений и соответствующие группы безопасности

Создание вспомогательных учетных записей
Модель делегирования сможет стать успешной только при условии соблюдения принципа наименьших привилегий. На практике это означает, что каждый участник политики безопасности должен выполнять только те задачи, которые требуются для исполнения его роли, и ничего более. К сожалению, при администрировании каталога и выполнении повседневных задач, таких как просмотр веб-страниц и чтение электронной почты, многие специалисты обращаются к одному и тому же участнику политики безопасности. Наличие автономных учетных записей сокращает риск случайного повреждения администратором того или иного класса службы каталогов или проведения атаки, направленной на администратора каталога, через стандартные приложения.
Чтобы решить эту проблему, не принуждая администратора выходить и вновь входить в систему, имеет смысл обратиться к службе вторичного входа в систему (компонент Runas.exe). Она позволяет пользователям расширять полномочия, указывая при выполнении сценариев и исполняемых файлов на серверах и рабочих станциях дополнительный набор учетных данных.
Несмотря на то, что принцип настройки учетных записей с наименьшими привилегиями довольно прост, в некоторых организациях он приживается с трудом £ старые привычки ИТ-специалистов не так уж легко побороть. Чтобы предотвратить применение привилегированных учетных записей для решения повседневных задач, можно составить административную политику организационного уровня и с её помощью запретить почтовый доступ к таким учетным записям в приложении Exchange Server. Этот сравнительно простой метод серьезно уменьшает вероятность употребления подобных учетных записей в повседневной работе, не связанной с администрированием.

Делегирование прав
На последнем этапе осуществляется собственно делегирование прав в службе Active Directory. Эта задача сводится к операциям с записями управления доступом (access control entries – ACE) и списками управления доступом (access control lists – ACL) к данным, хранящимся в структуре каталога. Списки ACL, относящиеся к контейнерам службы Active Directory, определяют объекты, которые могут создаваться в службе каталогов, и регламентируют способ управления этими объектами. Делегирование прав связано с базовыми операциями с объектами, в том числе с возможностью просмотра объектов, создания дочерних объектов определенного класса, чтения атрибутов и параметров безопасности объектов определенного класса. Помимо основных операций, в службе Active Directory определяются расширенные права, благодаря которым становятся доступными такие операции, как «Отправить как» и «Управление топологией репликации».
Ранее было обсуждено создание групп безопасности, соответствующих предусмотренным в организации ролям. При этом с каждой ролью ассоциируется группа безопасности, созданная в структуре дочерних подразделений. Для реализации такой модели делегирования группам необходимо назначить разрешения применительно к объектам каталога. На этом этапе не имеет смысла изобретать колесо и создавать среду с высокой индивидуализацией. По возможности старайтесь обходиться встроенными группами и правами. Предположим, что той или иной роли требуется предоставить средства управления DNS-записями в масштабах отдельного леса. Не пытайтесь делегировать права в отношении контейнеров и контекстов именования, связанных с встроенной в службу Active Directory службой DNS; лучше обратитесь к существующей в домене группе BUILTIN\DNS Admins. Кроме того, права пользователя и другие разрешения можно расширить с помощью групповой политики; в таком случае формируются дополнительные права, необходимые для управления определенным классом систем посредством определенной роли.
При распределении полномочий путем делегирования нужно ограничить или полностью исключить применение в каталоге запрещающих элементов ACE. Дело в том, что они могут создать трудности при устранении неполадок. Предоставить права настраиваемым группам, представляющим роли, лучше при помощи явных разрешающих элементов ACE. Не забывайте о том, что любая роль, определенная пользователем (например администраторов 4 класса), не имеет никаких прав, кроме тех, что были заданы в ней явным образом.
Существенную роль в системе безопасности службы Active Directory играет наследование; механизм наследования регламентирует действие тех или иных списков ACL на дочерние объекты в данном контейнере (обычном или вложенном). Разграничивая сферу наследования, будьте предельно конкретны £ применяйте наследуемые элементы ACE как можно ближе к целевым объектам. Наследуемые запреты разрешений (deny permissions), установленные в отношении родительского объекта, имеют приоритет относительно аналогичных запретов, установленных на уровне прародительского объекта; это одна из тех причин, по которым запрещающие элементы ACE не рекомендуется применять в практике делегирования. Более того, наследуемое разрешение не может перекрыть явно заданный в отношении объекта элемент ACE. По этой причине рекомендуется ограничить или полностью исключить для администраторов, принадлежащих к различным классам, возможность изменения списка управления доступом на уровне пользователей (путем отзыва права записи в списке разграничительного контроля доступа £ DACL), действующего в отношении объектов каталога (следует учитывать, что создателю объекта это право присваивается неявно). Как правило, если администратор имеет возможность изменить действующий в отношении объекта список DACL, он это сделает. Так уберегите же модель делегирования, на формирование которой ушло столько сил, от необоснованного выбора и возможных административных ошибок.
Существует ряд инструментов, которые потребуются для надежной реализации модели делегирования в службе Active Directory. В большинстве крупных организаций делегирование полномочий в каталоге посредством встроенного Мастера делегирования сопряжено с риском административных ошибок. Делегирование должно быть автоматизированным; в связи с этим модель делегирования должна быть комплексно документирована, предусматривать возможность поддержки и способ восстановления на случай утраты или случайного изменения настроек.
Основной инструмент, необходимый для реализации делегирования £ программа DSACLS.EXE. Это утилита с интерфейсом командной строки, применяемая для управления списками ACL службы каталогов, действующими в отношении объектов. Кроме того, она позволяет указывать применительно к родительским объектам флаги наследования списка DACL. (Виды флагов наследования: «Данный объект и дочерние объекты», «Только дочерние объекты», «Распространить наследуемые разрешения на один уровень».) В случае неверной установки флага наследования команды DSACLS завершаются с ошибками, поэтому при работе с рассматриваемой утилитой очень важно не пренебрегать тестированием. Вот пример синтаксиса команды DSACLS, предназначенной для делегирования права создавать объекты компьютеров в целевом подразделении demo:
dsacls.exe ou=demo,dc=contoso,dc=com /I:T /G contoso\dataadmin:CC;computer
Типы объектов в утилите DSACLS нужно указывать с соблюдением регистра. Скажем, попытка делегирования разрешений относительно класса объектов "cn=Computer" с помощью параметра "cn=computer" не приведет к желаемому результату (см. рис. 3).
Рис. 3 Ошибка, вызванная чувствительностью к регистру
Рис. 3 Ошибка, вызванная чувствительностью к регистру (Щелкните изображение, чтобы уменьшить его)
Рис. 3 Ошибка, вызванная чувствительностью к регистру
Рис. 3 Ошибка, вызванная чувствительностью к регистру (Щелкните изображение, чтобы увеличить его)
Для создания некоторых объектов требуется определенный набор прав. Имеются в виду обязательные и необязательные атрибуты объектов. Лучше всего этот принцип объясняет сравнение с гамбургером. В каждом полноценном гамбургере должны быть кусок мяса и булка. Это £ обязательные атрибуты класса объектов типа «Гамбургер». Соленья, кетчуп, салат и прочие компоненты относятся к категории необязательных атрибутов. Чтобы создать на основе гамбургера класс объектов «Чизбургер», нужно добавить в список обязательных атрибутов сыр.
Аналогичным образом устроены объекты пользователей. Теперь предположим, что для создания на основе этой модели объектов пользователей применяется следующий синтаксис команды DSACLS:
dsacls ou=demo,dc=contoso,dc=com /I:T /G contoso\demodata:CC;user
В ходе создания объектов таким способом администратор столкнется с несколькими ошибками. Нужно предоставить привилегии, необходимые для установки обязательных атрибутов объекта пользователя, в том числе указать пароль. Это сделано в следующем примере добавочного синтаксиса команды DSACLS.
В первую очередь, предоставим право записи обязательных атрибутов; для этого нужно присвоить всем атрибутам класса пользователя разрешения Generic Read/Generic Write (базовая запись/чтение):
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:GRGW;;user
Далее предоставим расширенное право изменения пароля:
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:CA;"Reset Password";user
Наконец, присвоим атрибуту «Последний пароль задан» права «Чтение свойства» и «Запись свойства»:
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;pwdLastSet;user
После делегирования прав определенные роли смогут управлять только теми классами объектов, которые указаны в списке DACL контейнера. В контексте предыдущего примера объекта компьютера отметим, что контекстное меню в консоли «Active Directory – пользователи и компьютеры» ограничивает список новых объектов, которые может создать пользователь, получивший подобные права путем делегирования (см. сокращенный список на рис. 4).
Рис. 4 Сокращенный список новых объектов
Рис. 4 Сокращенный список новых объектов
Для комплексного развертывания прав команды DSACLS можно автоматизировать. Ниже приведены некоторые команды DSACLS, позволяющие делегировать права управления стандартными атрибутами адресов по отношению к объектам пользователей в отдельно взятом контейнере.
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;c;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;co;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;l;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postalCode;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postOfficeBox;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;st;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;streetAddress;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;telephoneNumber;user
Подобные примеры в большинстве моделей делегирования встречаются нередко; их можно реализовать в совокупности с ранее указанными ролями.
Еще один инструмент, применяемый для реализации делегирования, называется DSREVOKE.EXE. Он позволяет администраторам находить и удалять права, делегированные отдельным участникам политики безопасности в отношении объектов каталога. Не умаляя достоинств этой утилиты, следует подчеркнуть, что она работает с конкретными участниками политики безопасности и не оценивает вложенную структуру членства в группах безопасности.
Помимо упомянутых утилит с интерфейсом командной строки, настоятельно рекомендуется обращаться к разделам «Назначение прав пользователя» и «Группы с ограниченным доступом» групповой политики. Как уже говорилось, раздел «Назначение прав пользователя» позволяет ИТ-администраторам продлевать или отзывать низкоуровневые права (например право удаленного доступа и перезагрузки системы) у различных групп пользователей в конкретных системах. Раздел «Группы с ограниченным доступом» позволяет настраивать и вводить в действие членство в локальных группах и группах доменов в масштабах того или иного леса. Сочетание всех этих инструментов предоставляет неограниченные возможности автоматизации и реализации модели делегирования в службе Active Directory.

Заключение
Формирование модели делегирования в службе Active Directory может, на первый взгляд, показаться сложной задачей, но на самом деле существуют очень простые модели, применимые в большинстве ИТ-инфраструктур. Один из важнейших этапов развертывания эффективной модели делегирования полномочий сводится к четкому определению ролей. Набор ролей должен быть компактным и поддающимся учету. Здесь важно найти компромиссное решение: если ролей слишком много, некоторые из них останутся без употребления, а если их слишком мало, разделение ролей будет затруднено.
Не забывайте о том, что при определении задач их нужно систематизировать по признакам регулярности, значимости и сложности. Справившись с определением ролей, создайте в целях автоматизации процесса тестирования набор вариантов использования, регламентирующих возможности и ограничения каждой роли. Тщательно подготовленные варианты использования помогут объяснить распределение ролей заинтересованным лицам в организации и сократить риск неожиданных последствий из-за ошибок автоматизации.
Наконец, при разработке модели делегирования лучше всего исходить из практических соображений. Не забывайте: простота упрощает поддержку, а устойчивая модель делегирования исключает многие проблемы, связанные с контролем административных прав в среде службы Active Directory.
Дополнительные ресурсы
  • Design Considerations for Delegation of Administration in Active Directory (Вопросы проектного решения модели делегирования административных полномочий в службе каталогов Active Directory) (на английском языке).
  • Best Practices for Delegating Active Directory Administration (Рекомендуемые методы делегирования административных полномочий в службе каталогов Active Directory) (на английском языке).

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


 Администрирование Windows: Подробно о новых шаблонах групповых политик в Windows Vista
Администрирование Windows Даррен Мар-Елия (Darren Mar-Elia)

Подробно о новых шаблонах групповых политик в Windows Vista
Краткий обзор:
  • Внутреннее устройство файлов ADMX
  • Редактирование файлов ADMX
  • Различия между файлами ADM и ADMX
  • Создание центрального хранилища

До появления Windows Vista задаваемые групповыми политиками значения реестра устанавливались с помощью файлов ADM со сложным собственным синтаксисом. Чтобы управлять дополнительными значениями реестра, не входящими в комплект поставки стандартных файлов ADM от Microsoft, необходимо было изучать этот
синтаксис и создавать пользовательские файлы ADM. Кроме того, файлы ADM хранились вместе с каждым объектом групповой политики (GPO) в среде Active Directory® и каждый из этих объектов GPO вместе с сопутствующими файлами ADM реплицировались на все контроллеры домена в данном домене.
С выходом Windows Vista™ корпорация Майкрософт сделала значительный шаг вперед в области шаблонов реестра на основе групповых политик. В Windows Vista вводятся существенные изменения как формата файлов ADM, которые теперь называются файлами ADMX, так и способа их хранения. В данной статье я хотел бы рассмотреть внутреннее устройство файлов нового формата ADMX и обсудить их отличия от прежнего формата ADM. Я также остановлюсь на способах хранения таких файлов в среде Windows Vista.

Отличительные особенности формата ADMX
Наиболее значительным из отличий нового формата файлов ADMX от старого формата ADM, применявшегося со времен Windows NT® 4.0, является использование в файлах ADMX стандарта XML для описания параметров политик в реестре. Это удобно по ряду причин. Во-первых, для редактирования файлов XML существует гораздо больше средств, чем для файлов ADM. Во-вторых, благодаря схематизации XML со временем станет проще создавать средства, облегчающие использование тегов и помогающих создавать правильно оформленные файлы ADMX. Под схематизацией имеется в виду, что для каждого конкретного применения XML, например, для формата ADMX, существует документированная схема, описывающая возможные элементы и атрибуты и то, как они организованы. Далее в этой статье мы рассмотрим это на примере.
Другим важным отличием ADMX от ADM является вынесение строкового раздела главного файла ADMX в отдельный файл ADML для конкретного языка. Тем, кто знаком с файлами ADM, известно, что в конце каждого файла есть раздел, обозначенный тегом "[strings]", где можно присваивать значения строкам, которые должны появляться при использовании редактора групповых политик и административных шаблонов. В этом строковом разделе хранился, например, текст, отображавшийся при выборе вкладки «Объяснение» групповой политики. Проблема заключалась в том, что строки хранились в самом файле ADM и при необходимости использовать это файл в операционной системе Windows® на другом языке нужно было создавать новый файл ADM со строковым разделом на этом языке.
Ситуация тем более усложнялась, если, скажем, на французской версии Windows нужно было изменить существующий объект групповой политики, использовавший файлы ADM со строками на английском. Французский администратор в редакторе групповых политик столкнулся бы с английским языком. В Windows Vista эта проблема решена выделением раздела [strings] в языковой файл ADML на базе XML. Файл ADML может поставляться на любом поддерживаемом языке и может быть легко изменен для поддержки нового языка без необходимости модифицировать главный файл ADMX, в котором хранятся политики. И, что еще более важно, когда французский администратор станет редактировать объект GPO со своего компьютера под управлением Windows Vista, редактор групповых политик определит использование французской версии Windows и автоматически загрузит для этого объекта GPO французский файл ADML.
Все файлы ADMX и ADML, идущие в поставке Windows Vista, можно увидеть в папке c:\windows\policydefinitions (см. рис. 1).
Рис. 1. Файлы ADMX в Windows Vista
Рис. 1. Файлы ADMX в Windows Vista (Щелкните изображение, чтобы уменьшить его)
Рис. 1. Файлы ADMX в Windows Vista
Рис. 1. Файлы ADMX в Windows Vista (Щелкните изображение, чтобы увеличить его)
Обратите внимание на папку en-us вверху списка файлов на рис. 1. Это папка, содержащая файлы ADML конкретного языка для файлов ADMX из данной папки PolicyDefinitions£в данном случае, для языка Английский (США). Для каждого файла ADMX существует один файл ADML. На момент написания данной статьи Windows Vista по умолчанию содержит 132 файла ADMX/ADML. Есть еще одно существенное отличие Windows Vista от предыдущих версий: Объекты GPO, созданные в Windows XP, обычно имели пять файлов ADM, самым большим из которых был System.adm, содержащих элементы политики для большинства компонентов Windows, управляемых политиками. В Windows Vista в корпорации Майкрософт решили разбить файлы ADMX по функциям, что привело к значительному увеличению их количества. Каждый файл ADMX обычно относится к какому-то одному компоненту Windows (панели управления, DNS-клиенту, проводнику Windows и т.п.).

Внутреннее устройство файлов ADMX
Как было замечено ранее, существенным улучшением является то, что файлы ADMX создаются с помощью XML. Многие администраторы, однако, не умеют создавать файлы XML и тем более не понимают схему, используемую файлами ADMX для создания расширений политик. Написание учебника по созданию пользовательских файлов ADMX выходит за рамки данной статьи, и все же рассмотрим, как формируются файлы ADMX.
Любой файл ADMX или ADML можно открыть в любом текстовом редакторе, даже Блокноте, но вряд ли это будет иметь смысл, если редактор не понимает синтаксис XML. Я использую Visual Studio®, его функция IntelliSense® помогает завершать отдельные элементы. На рис. 2 можно увидеть первые несколько строк одного из файлов ADMX из поставки Windows Vista.
Figure 2 Пример XML в файле ADMX (Close Figure 2)
<?xml version="1.0" encoding="utf-8"?>
<policyDefinitions xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" revision="0.9" schemaVersion="0.9"
  xmlns="http://www.microsoft.com/GroupPolicy/PolicyDefinitions">
  <policyNamespaces>
    <target prefix="AxInstSv" namespace="Microsoft.Policies.ActiveXInstallService" />
    <using prefix="windows" namespace="Microsoft.Policies.Windows" />
  </policyNamespaces>
Если вы не знакомы с XML, они могут казаться странными, но многие из этих элементов XML встречаются во всех файлах ADMX. Например, элемент policyNamespaces однозначно идентифицирует данный файл ADMX среди других таких файлов.
Те, кому доводилось создавать пользовательские файлы ADM в предшествующих версиях Windows, знают, что там был набор тегов, таких как Category, Policy, ListBox и ActionList, применяемых для определения параметров политики и отображавшихся в редакторе групповых политик. Многие из этих тегов в формате ADMX не изменились или изменились незначительно, но выглядят они совершенно иначе, поскольку представлены в виде XML. Например, я когда-то написал пользовательский файл ADM, активирующий различные типы ведения журнала в Windows для устранения неполадок при обработке групповых политик. Раздел этого файла ADM показан на рис. 3. Я перенес этот файл в новый формат ADMX, как показано на рис. 4.
Figure 4 Файл ADMX, преобразованный из ADM (Close Figure 4)
<policy name="Folder Redirection Logging" class="Machine" displayName="$(string.FolderRedirLogging)" explainText="$(string.FolderRedirLogging_Help)" key="Software\Microsoft\Windows NT\CurrentVersion\Diagnostics" valueName="FDeployDebugLevel">
      <parentCategory ref="PolicyLogging" />
      <supportedOn ref="windows:SUPPORTED_Win2K"/>
      <enabledValue>
        <decimal value="15"/>
      </enabledValue>
      <disabledValue>
        <decimal value="0" />
      </disabledValue>
    </policy>
Figure 3 Пользовательский файл ADM (Close Figure 3)
CLASS MACHINE
  CATEGORY !!System
    CATEGORY !!GroupPolicy
    CATEGORY !!Logging
POLICY !!FolderRedir
EXPLAIN !!FolderRedir_HELP
KEYNAME "Software\Microsoft\Windows NT\CurrentVersion\Diagnostics"
VALUENAME "FDeployDebugLevel"
VALUEON NUMERIC 15
VALUEOFF NUMERIC 0
END POLICY ;FolderRedir
      END CATEGORY ;Logging
   END CATEGORY ;GroupPolicy
 END CATEGORY ;SYSTEM
Во многих отношениях этот фрагмент файла ADMX проще и понятнее своего родственника в формате ADM, он лаконичнее. Элемент политики определяет задачу данной политики (ведение журнала перенаправления папки). Атрибуты, начинающиеся с $(string., ссылаются на соответствующий строковый элемент ADML. Атрибуты key и valuename, как следует из их названий, указывают на ключ и значение реестра, изменяемые данной политикой. Элемент parentCategory определяет, отображается ли эта политика в иерархии административных шаблонов редактора групповых политик. Элемент supportedOn указывает, в какой версии операционной системы поддерживается данная политика, и, наконец, элементы enabledvalue и disabledvalue определяют значения, которые записываются в реестр при включении и отключении данной политики.
Это довольно простая политика типа «включить-выключить». Как и при использовании синтаксиса ADM, с помощью редактора групповых политик можно создавать более сложные элементы пользовательского интерфейса. В таких случаях синтаксис файлов ADMX несколько усложняется и включает атрибут представления, ссылающийся на часть файла ADML, в которой находятся текстовые подписи элементов пользовательского интерфейса. Однако во всем остальном синтаксис файлов ADMX не намного сложнее. Следует помнить, что названия некоторых тегов в ADMX изменились по сравнению с ADM. Например, в файлах ADM были теги "edittext" и "listbox". В файлах ADMX эти теги называются соответственно "text" и "list". В файле ADML им будут соответствовать записи, указывающие на текст, который будет отображаться с этими элементами.
Как вам, вероятно, уже известно, администратор может загружать старые пользовательские файлы ADM в редактор объектов групповых политик Windows Vista. Меня часто спрашивают, предоставит ли корпорация Майкрософт утилиту для преобразования пользовательских файлов ADM в синтаксис ADMX. На самом деле корпорация Майкрософт совместно с FullArmor Corp. выпустила бесплатное средство под названием ADMX Migrator. Эта программа выполняет две функции. Во-первых, она преобразовывает старые пользовательские файлы ADM в формат ADMX (см. пример использования данной программы для преобразования моего файла gpolog.adm на рис. 5).
Рис. 5 ADMX Migrator
Рис. 5 ADMX Migrator (Щелкните изображение, чтобы уменьшить его)
Рис. 5 ADMX Migrator
Рис. 5 ADMX Migrator (Щелкните изображение, чтобы увеличить его)
Во-вторых, она включает редактор ADMX Editor, с помощью которого можно создавать новые файлы ADMX. Эту программу можно загрузить по адресу go.microsoft.com/fwlink/?LinkID=77409.

Хранение файлов ADMX
Еще одним примечательным нововведением является способ хранения файлов ADMX и ADML. В версиях Windows, предшествующих Windows Vista, при редактировании объектов GPO файлы ADM автоматически копировались с локального компьютера, на котором производилось редактирование, в папку SYSVOL объекта GPO на котроллере домена в домене Active Directory. В последствии эти файлы ADM реплицировались на каждый контролер домена в домене для каждого создаваемого объекта GPO. Это приводило к нерациональному использованию полосы пропускания сети и дискового пространства, особенно в больших средах с десятками и сотнями объектов GPO. В Windows Vista в данной ситуации происходит противоположное. По умолчанию при создании объекта GPO на основе службы каталогов Active Directory на компьютере под управлением Windows Vista отображающиеся в редакторе групповых политик политики административных шаблонов загружаются из папки c:\windows\policydefinitions на том же компьютере.
Файлы ADMX и ADML не копируются в сетевую папку SYSVOL, а используются локально. Это позволяет избежать нагрузки на сеть и системы хранения среды групповых политик, неизбежной при использовании файлов ADM. И это не единственный положительный момент. Windows Vista также поддерживает центральное хранилище £ базу данных административных шаблонов. Таким образом обеспечивается эффективное управление файлами ADMX, используемыми для редактирования объектов GPO, независимо от того, откуда производится редактирование. Это достигается путем копирования всех файлов ADMX и ADML официальной поставки и созданных пользователем в единое место в сети и последующего обращения к ним вместо локальных файлов при редактировании групповых политик с рабочих станций под управлением Windows Vista. Настройка центрального хранилища £ несложная задача, которую достаточно выполнить один раз для данного домена. Пошаговые инструкции по созданию хранилища приведены в боковой врезке "Создание центрального хранилища".

Заключение
Новый формат файлов ADMX в Windows Vista является однозначным улучшением по сравнению с файлами ADM, применявшимися в предыдущих версиях Windows. Использование в этих файлах XML облегчает поддержку редактирования и поиска. Перемещение строк с текстом на конкретном языке в отдельные файлы обеспечивает бесшовное редактирование групповых политик, а применение центрального хранилища устраняет необходимость в хранении и обновлении всех объектов GPO с копиями файлов ADM. Принимая во внимание все сказанное, овладение приемами работы с файлами ADMX представляется разумным шагом.
Создание центрального хранилища
Создать центральное хранилище относительно несложно. Чтобы создать хранилище в домене службы каталогов Active Directory:
Шаг 1: Откройте Проводник и перейдите в общую папку SYSVOL контроллера домена – эмулятора PDC в вашем окружении (можно использовать любой контроллер домена, но обычно изменения групповых политик сосредоточены именно на владельце роли PDC).
Шаг 2: Войдите в папку Policies в папке SYSVOL и создайте новую папку PolicyDefinitions.
Шаг 3: Скопируйте содержимое папки C:\windows\policydefinitions на вашей рабочей станции под управлением Windows Vista в новую папку PolicyDefinitions, включая языковую папку ADML (например en-us на компьютере с региональными настройками США).
После того, как файлы ADMX и ADML будут скопированы в папку центрального хранилища, редактор объектов групповых политик в Windows Vista начнет обращаться к этим файлам и игнорировать локальные файлы.

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


 Администрирование Windows: Руководство по отладке групповых политик
Администрирование Windows Дерек Мелбер (Derek Melber)

Руководство по отладке групповых политик
Краткий обзор:
  • Типичные проблемы, связанные с объектами групповой политики (GPO)
  • Правила групповой политики
  • Решение проблем, связанных с объектами GPO
  • Средства для устранения неполадок

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

Проблемные параметры
Групповые политики представляют собой сложный механизм с множеством составляющих, особенно в том, что касается способа их взаимодействия с общей идеей и реализацией службы Active Directory®. При поиске решения различных проблем, связанных с сетями и доступом, необходимо всегда учитывать службу Active Directory и основы реализации групповой политики. Чтобы начать процесс поиска решения, рассмотрим параметры групповой политики, при настройке которых могут быть допущены ошибки, а затем перейдем к более сложным проблемам, которые могут возникать в работе групповой политики.
Параметры групповой политики просматриваются администраторами Active Directory с помощью файлов административных шаблонов (файлы ADM или ADMX) и редактора объектов групповой политики GPEdit (запускается файлом gpedit.msc). С помощью GPEdit администратор создает файлы объектов групповой политики, или GPO. Объекты GPO настраиваются таким образом, чтобы применяться (или не применяться) к компьютерам и пользователям в структуре Active Directory. Для правильной работы объекты GPO должны соответствовать многим правилам. Рассмотрим их подробнее.
Объекты GPO должны быть связаны Вновь созданный объект GPO может быть не связан ни с одним узлом Active Directory. Такой объект GPO можно редактировать и изменять, но пока он не связан с каким-либо узлом, он не сможет влиять ни на один объект. Чтобы убедиться, что объект GPO должным образом связан, следует просмотреть окно информации в консоли управления групповой политикой (GPMC), показанное на рис. 1.
Рис. 1 Явно отображены связи объекта GPO
Рис. 1 Явно отображены связи объекта GPO (Щелкните изображение, чтобы уменьшить его)
Рис. 1 Явно отображены связи объекта GPO
Рис. 1 Явно отображены связи объекта GPO (Щелкните изображение, чтобы увеличить его)
Объект GPO должен применяться к объекту надлежащего типа Как известно, групповая политика должна применяться к объектам правильного типа в Active Directory. Однако в ходе процесса отладки этим иногда пренебрегают. Внутри объекта GPO существуют две основные категории: компьютер и пользователь. При настройке GPO обязательно отметьте, к какому типу объектов он применяется £ к компьютеру или к пользователю. Таким образом можно будет проверить, правильного ли типа объекты помещены в подразделение, с которым связан объект GPO.
Объекты GPO неприменимы к группам Объект GPO не может применяться к объекту группы безопасности Active Directory. С помощью объекта GPO можно настраивать параметры только двух объектов £ компьютеров и пользователей. Объекты GPO не могут воздействовать на объекты через принадлежность к группам. Например, если объект GPO связан с подразделением Финансы, как показано на рис. 2, он будет применен только к объектам Дерек и Франк. Параметры объекта GPO не будут применены к участникам группы Маркетинг, кто бы в нее не входил.
Рис. 2 Подразделение Финансы и находящиеся в нем объекты
Рис. 2 Подразделение Финансы и находящиеся в нем объекты (Щелкните изображение, чтобы уменьшить его)
Рис. 2 Подразделение Финансы и находящиеся в нем объекты
Рис. 2 Подразделение Финансы и находящиеся в нем объекты (Щелкните изображение, чтобы увеличить его)
Объекты, к которым применяется GPO, должны находится в пределах области управления Если параметр объекта GPO не производит должного воздействия на объект, существует еще более важный параметр £ объект должен находиться в пределах области управления объекта GPO. Это означает, что данный объект должен находиться ниже узла, к которым связан объект GPO (достаточно дочернего узла). Например, объект GPO, связанный с подразделением Финансы, не будет применен ни к одному из объектов подразделения Маркетинг, как показано на рис. 2. Область управления объекта GPO простирается от узла, с которым он связан, далее вниз по структуре службы Active Directory.
Рис. 3 Для подразделений, расположенных на одном уровне, объект GPO применяется только к подразделению, с которым он связан.
Рис. 3 Для подразделений, расположенных на одном уровне, объект GPO применяется только к подразделению, с которым он связан. (Щелкните изображение, чтобы уменьшить его)
Рис. 3 Для подразделений, расположенных на одном уровне, объект GPO применяется только к подразделению, с которым он связан.
Рис. 3 Для подразделений, расположенных на одном уровне, объект GPO применяется только к подразделению, с которым он связан. (Щелкните изображение, чтобы увеличить его)
Объекты GPO должны быть включены При создании объекта GPO он не настроен на внесение каких-либо изменений в целевые объекты. Однако он включен как для компьютеров, так и для пользователей. Если одна из этих настроек отключена, это может быть очень сложно отследить. Поэтому при отладке ошибок применения объекта GPO неплохо проверить, не отключены ли некоторые или даже все объекты GPO. Это можно сделать в разделе Объекты групповой политики | Политика учетных записей в консоли GPMC, проверив состояние GPO.
Некоторые параметры требуют перезагрузки Если параметр GPO работает неправильно, причиной может быть механизм обработки GPO. При периодическом фоновом обновлении объектов GPO могут быть обработаны не все параметры GPO, а лишь некоторые из них. Поэтому уже созданный параметр может еще не действовать. Некоторые параметры относятся к категории политик переднего плана и применяются только при перезагрузке компьютера или выходе пользователя из системы и повторном входе. Примерами параметров, которым свойственно такое поведение, могут быть установка программного обеспечения, перенаправление папки и приложение сценария.

Синхронное и асинхронное применение параметров
В объекте GPO можно задать способ применения политики при загрузке и входе в систему. Внесенные изменения либо предоставят немедленный доступ к рабочему столу до полного применения всех политик, либо обеспечат применение всех политик до того, как пользователь получит доступ к рабочему столу. На рис. 4 показано поведение каждой операционной системы по умолчанию. Если нужно изменить данное поведение, можно модифицировать следующий параметр политики:
Computer Configuration | Administrative Templates |
System | Logon | Always wait for the network at computer startup and logon
Figure 4 Обработка по умолчанию на клиенте (Close Figure 4)

Операционная система | Загрузка | Вход в систему | Обновление политики
Windows 2000 | Синхронно | Синхронно | Асинхронно
Windows XP Professional | Асинхронно | Асинхронно | Асинхронно
Windows Server 2003 | Синхронно | Синхронно | Асинхронно
Большинство администраторов предпочитают синхронное изменение политики для обеспечения применения всех политик до того, как пользователь получит доступ к рабочему столу. Таким образом обеспечивается применение всех параметров безопасности и настройки до того, как пользователь сможет выполнить какие-либо действия. Обратите внимание, что такое поведение по умолчанию отключено в Windows® XP Professional в пользу оптимизации ускоренного входа в систему.

Изменение наследования по умолчанию
Существует четыре разных способа изменения наследования по умолчанию для обработки объектов GPO. Эти мощные возможности следует использовать с осторожностью, поскольку они могут существенно изменить поведение обработки групповых политик. Они также очень трудны в отладке. Возможности изменения наследования по умолчанию включают следующие четыре параметра и настройки:
  • Блокировать наследование политики
  • Принудительное выполнение объектов GPO
  • Фильтрация объектов GPO по списку управления доступом (ACL)
  • Фильтры инструментария управления Windows (WMI)
Поскольку эти параметры следует использовать с осторожностью, случаи их использования должно быть несложно записать. Выяснить, используются ли эти возможности, можно в консоли управления групповыми политиками GPMC. Блокирование наследования выполняется на уровне домена или подразделения в панели GPMC. Параметры принудительного выполнения объектов, фильтрации по спискам ACL, и фильтрация WMI задаются для каждого объекта GPO отдельно.
Еще один способ £ это запустить на конечном компьютере команду Gpresult, чтобы узнать, не препятствует ли какой-то из этих параметров применению политик. Для получения более подробной информации о применяемом наборе политик можно добавить к команде Gpresult параметр /v, включающий подробный вывод.

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

Полезные инструменты
Существует множество средств обнаружения проблем в области групповой политики. Некоторые из них встроены в операционную систему, другие можно загрузить и установить. Далее мы обсудим соответствующие средства, чтобы вы могли выбрать то, которое подходит для решения конкретной задачи.
Dcgpofix Иногда могут возникать проблемы с одним из двух стандартных объектов GPO: Используемый по умолчанию GPO домена и используемый по умолчанию GPO контроллеров домена . Если один или оба из них повреждены настолько серьезно, что их нельзя исправить, или же возникает другая неизвестная неполадка, с помощью средства dcgpofix их можно вернуть в состояние по умолчанию. Данное средство включено в Windows Server® 2003. Его не следует использовать на контроллере домена Windows 2000; вместо этого можно использовать инструмент Recreatedefpol. Необходимо помнить, что после использования этого средства будут потеряны все пользовательские настройки.
Recreatedefpol Данное средство работает аналогично Dcgpofix, но для серверов Windows 2000. С его помощью можно вернуть два упомянутых стандартных объекта GPO в их исходное состояние. Данный инструмент предназначен для восстановления после серьезного сбоя, его не следует использовать для текущего обслуживания объектов GPO. Эту программу можно загрузить с узла корпорации Майкрософт (на английском языке).
Просмотр событий Средство просмотра событий может предоставить обширную информации о групповых политиках. К сожалению, для поиска записей о групповых политиках потребуется просмотреть все из различных файлов журналов. Там можно найти записи о применении, репликации и обновлении политик, что может помочь в обнаружении возникшей проблемы. В журналах событий иногда недостаточно информации о конкретных ошибках групповых политик, но следует помнить, что не поддающиеся идентификации ошибки всегда можно поискать в TechNet.
Gpresult Данное средство можно запускать только на целевом компьютере, зато оно выдает информацию о результирующем наборе политик (RSoP), заблокированных объектах GPO, разрешениях на GPO и многом другом. С параметром /v данная команда выведет подробную информацию об объектах GPO, действующих для данного компьютера, и учетных записях пользователей, связанных с текущим сеансом работы.
Gpupdate Для реализации новых параметров GPO или проверки полноты обработки всех GPO можно использовать средство Gpupdate. Это утилита командной строки, поставляемая с операционной системой (Windows XP и последующие версии). Она вызывает фоновое обновление, которое применяет все параметры GPO, соответствующие данному типу обновления. С параметром /force она повторно применяет параметры GPO, даже если с момента последнего обновления не происходило никаких изменений объектов GPO. Выполнение данной команды перед выполнением команды Gpresult является очень мощным способом отслеживания неполадок объектов групповых политик.
Gpotool Поскольку все объекты GPO реплицируются с контроллера домена, на котором в них были внесены изменения, на все другие контроллеры, существует вероятность сбоя репликации или неполадок при согласовании изменений. В результате может возникнуть несогласованность или сбой при применении изменений к конечным компьютерам. Утилиты Gpresult и RSOP помогают определить, какие из объектов GPO были применены, но данное средство, Gpotool, помогает обнаружить несогласованность объектов GPO между контроллерами домена. Эта утилита входит в состав Windows Server 2003 Resource Kit по адресу go.microsoft.com/fwlink/?LinkId=77613 (на английском языке).
Replmon При отладке репликации объектов GPO с одного контроллера домена на другой важно знать, каким из инструментов можно воспользоваться для устранения неполадок. Поскольку репликации подлежат две части объекта GPO, следует рассмотреть репликацию каждой из них. Первая часть £ содержимое папки SYSVOL на каждом из контроллеров домена, управляется службой репликации файлов (FRS). Существует не так уж и много способов управления такой репликацией, кроме выключения и включения службы для срабатывания интервала репликации. Другая часть объекта GPO, которая хранится в службе каталогов Active Directory, управляется репликацией Active Directory. Данной репликацией можно управлять между контроллерами домена на том же узле Active Directory с помощью средства Active Directory £ сайты и службы. Однако в тех случаях, когда необходимо вызвать репликацию между контроллерами домена на разных узлаъ Active Directory, нужно использовать такую утилиту, как Replmon. Средство Replmon может запускать принудительную репликацию базы данных службы Active Directory за пределы границы сайта, что невозможно сделать при помощи средства Active Directory £ сайты и службы. Таким образом в случае несогласованности информации групповых политик, хранимой в Active Directory, можно с помощью Replmon запускать процесс репликации для согласования данной информации на каждом контроллере домена. Утилита Replmon входит в Resource Kit и средства поддержки Windows XP. Ее можно загрузить по адресу go.microsoft.com/fwlink/?LinkID=77614 (на английском языке).
RSOP Подобно утилите командной строки Gpresult, средство RSOP обеспечивает графический интерфейс просмотра параметров, примененных ко всем объектам GPO. Файл RSOP.MSC встроен в Windows XP Professional и Windows Server 2003. Данный инструмент представляет данные о всех примененных параметрах политик в формате, похожем на формат редактора объектов групповой политики, как показано на рис. 5.
Рис. 5 Средство просмотра результирующего набора политик
Рис. 5 Средство просмотра результирующего набора политик

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

Дерек Мелбер (Derek Melber) является директором по вопросам решений для образования, сертификации и совместимости компании DesktopStandard, дочернего подразделения Microsoft. Дерек £ соавтор руководства Microsoft Windows Group Policy Guide (Microsoft Press, 2005). Он также написал серию книг, посвященных аудиту безопасности Windows (www.theiia.org (на английском языке)). С ним можно связаться по адресу derekm@desktopstandard.com.


 Администрирование в операционной системе Windows: Наблюдение за службой каталогов Active Directory с помощью MOM
Администрирование в операционной системе Windows Джон Ханн (John Hann)

Наблюдение за службой каталогов Active Directory с помощью MOM
Краткий обзор:
  • Пакеты управления для службы Active Directory.
  • Советы по настройке MOM.
  • Настройка оповещения.

Пакеты управления являются источником силы Microsoft Operations Manager (MOM) 2005 и тем, что отличает этот набор программ от других продуктов для управления. В MOM пакеты управления используются для объединения правил, отчетов, заданий и представлений, а также для ограничения сферы их применения конкретным приложением
или службой, например службой Active Directory. Группы разработки продуктов корпорации Майкрософт создают для разрабатываемых ими приложений пакеты управления, благодаря чему MOM отражает глубокое знание своего продукта каждой из групп. Более того, пакеты управления можно настраивать, чтобы они соответствовали конкретной ИТ-среде. При этом пользователь получает правила, осуществляющие наблюдение за продуктом и управление продуктом, основанные на среде конкретных серверов и приложений.
Существует не только специальный пакет управления для службы Active Directory®, но также множество пакетов управления для оценки работоспособности других служб каталогов, начиная с пакета управления базовой операционной системой Windows Server® и заканчивая пакетами управления службами DHCP (Dynamic Host Configuration Protocol £ протокол динамической настройки узлов), DNS и FRS (File Replication Service £ служба репликации файлов). Давайте подробно рассмотрим эти пакеты управления для лучшего понимания сквозного управления службой Active Directory, ставшего возможным благодаря MOM.

Пакет управления службой DHCP
Пакет управления службой DHCP осуществляет наблюдение за этой службой, работающей на компьютере под управлением ОС Windows NT®, Windows® 2000 или Windows Server 2003. Такое наблюдение полезно для отслеживания случаев возникновения у клиентов проблем с подключением к сети. Указанный пакет также позволяет получать предупреждения о работе в среде мошеннических (несанкционированных) серверов DHCP. Загружаемый с сервера пакет, содержащий данный пакет управления, включает руководство, в котором изложено описание правил и отчетов, а также вариантов наблюдения и процедуры развертывания. Большое количество дополнительной документации и руководств можно найти на веб-узле TechNet, посвященном MOM 2005 (microsoft.com/technet/prodtechnol/mom/mom2005).
Чем новее система Windows, на которой работает служба DHCP, тем больше инструментов и функций предоставляет MOM 2005 для управления ею. Следовательно, о сервере DHCP системы Windows Server 2003 можно получить больше информации, чем о сервере DHCP системы Windows NT. Например, для сервера DHCP, работающего на компьютере под управлением системы Windows Server 2003, возможно наблюдение за его суперобластями, в то время как для сервера DHCP системы Windows 2000 пакет управления службой DHCP осуществляет наблюдение только за обычными областями. Существует возможность исключить часть областей из числа тех, за которыми ведется наблюдение, поместив подлежащие исключению области в качестве параметра в сценарий наблюдения.
Как отмечалось раньше, пакет управления службой DHCP поддерживает серверы DHCP, работающие на компьютерах под управлением систем Windows NT, Windows 2000 Server или Windows Server 2003. Группы компьютеров заполняются посредством формул, в которых используются версия операционной системы и информация о наличии на сервере службы DHCP.
Пакет управления службой DHCP не поддерживает конфигурации с малым объемом прав. Учетная запись действия агента должна входить в локальную группу «Администраторы». Наблюдение без использования агента также поддерживается, но задания в конфигурации без использования агента не поддерживаются. На рис. 1 перечислены отчеты, которые можно получить с помощью пакета управления службой DHCP.
Figure 1 Отчеты службы DHCP (Close Figure 1)

Все серверы службы DHCP
Все уполномоченные серверы службы DHCP
Журнал производительности £ длина активной очереди
Журнал производительности £ длина очереди проверки конфликтов
Журнал производительности £ отклонений в секунду
Журнал производительности £ обнаружений в секунду
Журнал производительности £ миллисекунд на пакет (средн.)
Журнал производительности £ отрицательных подтверждений в секунду
Журнал производительности £ свободные адреса области
Журнал производительности £ задействованные адреса области
Журнал производительности £ свободные адреса суперобласти
Журнал производительности £ задействованные адреса суперобласти
Пакет управления службой DHCP можно загрузить по адресу go.microsoft.com/fwlink/?LinkId=79527.

Пакет управления службой DNS
Пакет управления службой DNS осуществляет наблюдение за этой службой, работающей на компьютере под управлением ОС Windows 2000 Server или Windows Server 2003. Так как эта служба является неотъемлемой частью, обеспечивающей работоспособность существующей службы Active Directory в целом, наблюдение за службой DNS с помощью MOM 2005 является очень важной задачей. Пакет управления этой службой позволяет отслеживать проблемы с разрешением имен, проблемы, связанные с базой данных, проблемы с реестром, события и ошибки среды выполнения, а также вести наблюдение за счетчиками, связанными с производительностью.
Для системы Windows 2000 Server должен быть установлен поставщик DNS инструментария управления Windows (WMI). В частности, это позволяет пакету управления службой DNS запрашивать у пространства имен WMI DNS информацию и тестировать его.
Все группы компьютеров заполняются посредством формул, в которых для определения членства в группах используются версия операционной системы и информация о наличии на сервере службы DNS. Пакет управления службой DNS поддерживает работу с малым объемом прав только для ОС Windows Server 2003. В системе Windows 2000 учетная запись действия должна входить в локальную группу «Администраторы». В системе Windows Server 2003 учетная запись действия должна входить в локальные группы «Пользователи» и «Пользователи системного монитора». Кроме того, учетная запись действия должна иметь права: «Управлять аудитом и журналом безопасности» (SeSecurityPrivilege) и «Разрешить локальный вход в систему» (SeInteractiveLogonRight). На рис. 2 приведены отчеты, которые можно получить с помощью пакета управления службой DNS.
Figure 2 Отчеты службы DNS (Close Figure 2)

Все серверы службы DNS системы Windows
Все серверы службы DNS системы Windows, по зонам
Все зоны службы DNS системы Windows, по серверам
Маркус Ох (Marcus Oh) имеющий статус MVP по серверу Microsoft® Systems Management Server (SMS), разработал сценарий, тестирующий сервер DNS путем вызова программы nslookup для проверки способности сервера DNS разрешать имена. Уделите время просмотру публикаций его блога, размещенного по адресу marcusoh.blogspot.com/2006/05/mom-monitoring-dns-synthetically.html; у вас появится желание включить этот сценарий в свою службу управления службой DNS.
Пакет управления службой DNS можно загрузить по адресу go.microsoft.com/fwlink/?LinkId=79528.

Пакет управления службой FRS
Пакет управления службой репликации файлов корпорации Майкрософт осуществляет наблюдение за службой FRS, работающей на компьютере под управлением ОС Windows 2000 или Windows Server 2003. Эта служба используется контроллерами доменов для осуществления репликации сценариев входа и информации групповой политики. Пакет управления службой FRS подробно отслеживает работоспособность службы на каждом контроллере домена.
Пакет управления службой FRS использует средство Ultrasound, которое можно получить на веб-узле go.microsoft.com/fwlink/?LinkId=79529. Средство Ultrasound создает для службы FRS на каждом контроллере домена пространство имен WMI. Обратите внимание, что средство Ultrasound нуждается в базе данных и будет хранить информацию по каждому пространству имен WMI на каждом контроллере домена для наблюдения за работоспособностью. Используя информацию средства Ultrasound, пакет управления службой FRS обеспечивает наблюдение за наборами репликации, членами, соединениями, самой службой FRS и службой контроллера Ultrasound.
Фактически средство Ultrasound необходимо установить на отдельный сервер, а не на сервер управления. Правила средства Ultrasound генерируют события и предупреждения для других компьютеров. Чтобы эти правила корректно обрабатывали данные, необходимо включить использование агента-посредника на консоли администратора MOM каждого сервера, на котором запущено средство Ultrasound. На рис. 3 приведены четыре отчета службы, которые можно получить с помощью пакета управления службой FRS.
Figure 3 Отчеты службы FRS (Close Figure 3)

Средство Ultrasound £ часто обнаруживаемые проблемы £ наиболее проблематичные соединения
Средство Ultrasound £ часто обнаруживаемые проблемы £ наиболее проблематичные участники
Средство Ultrasound £ часто обнаруживаемые проблемы £ наиболее проблематичный набор репликации
Средство Ultrasound £ часто обнаруживаемые проблемы £ сводка
Группы компьютеров, связанные с этим пакетом управления, включают серверы Microsoft Ultrasound 1.0 и серверы FRS, работающие на компьютерах под управлением ОС Windows 2000 Server или Windows Server 2003. Все группы компьютеров заполняются посредством формул, в которых для определения членства в группах используются версия операционной системы и информация о наличии на сервере службы FRS. Группа Ultrasound Servers (серверы Ultrasound) заполняется при установке на сервере средства Ultrasound.
При настройке пакета управления службой FRS для малого объема прав, задания не работают, но остальные функции пакета управления поддерживаются. Учетная запись действия должна иметь право доступа к базе данных средства Ultrasound для чтения и право запуска выполнения хранимой процедуры GetControllerStatusForMOM001. Пакет управления службы FRS включает поддержку наблюдения за компьютерами без агентов, а также за компьютерами, управляемыми агентами.
Пакет управления службой FRS можно загрузить по адресу go.microsoft.com/fwlink/?LinkId=79530.

Пакет управления системой Windows Server
Пакет управления базовой операционной системой Windows осуществляет наблюдение за системами Windows NT 4.0 Server, Windows 2000 Server и Windows Server 2003. Пакет управления базовой системой предоставляет отчеты о работоспособности операционной системы контроллерам доменов, а также осуществляет наблюдение за корневыми службами системы. Он предоставляет информацию о состоянии основных служб системы Windows, показателях работы памяти и процессоров, а также о свободном дисковом пространстве и задержке ответа дисков. Существует некоторое наложение правил наблюдения этого пакета управления и других пакетов управления, рассматриваемых в этой статье, но данный пакет обеспечивает отличное восходящее представление работоспособности контроллера домена.
На рис. 4 показаны отчеты, которые можно получить с помощью пакета управления базовой системой. Как и в случае других пакетов управления, все группы компьютеров заполняются посредством формул, в которых используется версия операционной системы.
Figure 4 Отчеты базовой операционной системы (Close Figure 4)

Анализ показателей работы дисков
Конфигурация операционной системы
Производительность операционной системы
Выключение операционной системы, по событиям
Выключение операционной системы, по серверам
Конфигурация средств хранения операционной системы
Установка программного обеспечения и приложений, по приложениям
Установка программного обеспечения и приложений, по экземплярам
Установка программного обеспечения и приложений, по серверам
Надежность £ выход из строя приложений, по приложениям
Надежность £ выход из строя приложений, по компьютерам
Надежность £ выход из строя приложений, по событиям
Надежность £ сбои операционной системы, по компьютерам
Надежность £ сбои операционной системы, по событиям
Надежность £ сбои операционной системы, по коду останова
Журнал производительности £ журнал производительности
Журнал производительности £ дополнительные отчеты
При настройке пакета управления базовой системой для работы с малым объемом прав система Windows 2000 требует, чтобы учетная запись действия входила в локальную группу «Администраторы». Для системы Windows Server 2003 необходимо, чтобы учетная запись действия входила в локальную группу «Пользователи» и «Пользователи системного монитора», а также имела права: «Управлять аудитом и журналом безопасности» (SeSecurityPrivilege) и «Разрешить локальный вход в систему» (SeInteractiveLog-onRight). Большая часть функций пакета управления основной системой, кроме заданий, поддерживаются на компьютерах без агента, за которыми ведется наблюдение.
Пакет управления основной системой можно загрузить по адресу go.microsoft.com/fwlink/?LinkId=79531.

Пакет управления службой Active Directory
Пакет управления службой Active Directory является очень обширным, и его правила применимы как к системе Windows 2000 Server, так и системе Windows Server 2003. Пакет охватывает следующие пять областей правил: наблюдение со стороны клиентов, наблюдение за довериями, наблюдение за репликацией и обнаружение топологии, а также правила, применимые к операционным системам Windows 2000 Server и Windows Server 2003. Как отмечалось выше, более новые версии системы Windows позволяют использовать больше инструментов и, следовательно, позволяют осуществлять дополнительное наблюдение. Например, пакет управления поддерживает наблюдение за довериями для системы Windows Server 2003, а для системы Windows 2000 эта функция не действует.
Пакет управления службой Active Directory создает несколько групп, используемых им для применения правил к конкретным компьютерам. Для правил наблюдения со стороны клиентов используется группа, называемая Active Directory Client Side Monitoring (наблюдение за службой Active Directory со стороны клиентов). В эту группу следует включить компьютеры, на которых установлен агент MOM, чтобы осуществлять наблюдение и управлять этими правилами. Я поместил в эту группу несколько настольных компьютеров, на которых установлен лицензированный агент, а также несколько серверов Exchange. Сервер Exchange Server использует службу Active Directory очень активно и будет первым показателем развития проблемы. Входящие в эту группу настольные компьютеры помогают оценить ощущение конечного пользователя при пользовании службой. Правилами наблюдения со стороны клиентов используются сценарии, позволяющие испытывать возможность подключения к контроллерам доменов, обращаться к ним с запросами по протоколу LDAP и выдавать сообщения об ошибках. Важно отметить, что правила наблюдения со стороны клиентов могут применяться только к управляемым агентами компьютерам, на которых включено использование посредников, но которые не являются контроллерами доменов.
Правилами наблюдения за довериями используется группа, называемая Active Directory Trust Monitoring (наблюдение за довериями службы Active Directory). Для проверки доверий в эту группу будут помещены компьютеры под управлением системы Windows Servers 2003. Для наблюдения за довериями система Windows Server 2003 имеет пространство имен WMI. Для обращения с запросами к пространству имен WMI эти правила используют сценарий. Эти правила предупреждают об обнаружении ошибок в доверии с другими трастами.
Существует множество правил пакета управления службой Active Directory, которые применимы либо к системе Windows 2000 Server, либо к системе Windows Server 2003. Эти правила описывают различия в организации службы Active Directory в этих двух операционных системах. Однако большая часть пакета управления службой Active Directory состоит из комбинированных правил, предназначенных для обеих операционных систем. Некоторые из этих правил включают сценарии для тестирования связи между контроллерами доменов, проверки текущих владельцев ролей FSMO, размера базы данных дерева информации о каталогах, проверки правильности обработки групповой политики, контроля средства KCC (Knowledge Consistency Checker £ средство проверки согласованности знаний) и проверки службы обмена сообщениями между узлами (Intersite Messaging).
Наблюдение за репликацией является центральной частью пакета управления службой Active Directory. Две группы: Active Directory Replication Latency Data Collection £ Sources и Active Directory Replication Latency Data Collection £ Targets существуют для выполнения настройки контроллеров доменов, использующихся только для составления отчетов по наблюдению за репликацией. Задержка репликации вычисляется для каждого члена групп сбора данных. В счетчики производительности заносится время, которое уходит на репликацию обновлений на каждый из членов групп. Рассчитывается задержка репликации в рамках всего предприятия, и в случае если ее значение превышает установленные пороговые значения, об этом выдаются сообщения (генерируются предупреждения). Обратите внимание, что на сервер Windows 2000 Server для наблюдения за репликацией должно быть установлено пространство имен WMI.
Обнаружение топологии, включенное в пакет управления службой Active, используется для построения диаграмм реализации сети. Эти полезные схемы могут быть экспортированы в приложение Microsoft Office Visio®. Эти диаграммы строятся MOM в реальном времени, поэтому за несколько секунд можно создать соответствующую данному моменту версию.
В Diagram Views (представления диаграмм) консоли оператора MOM 2005 находятся три диаграммы пакета управления службой Active Directory. На диаграмме Broken Connection Objects (объекты нарушенных соединений) (см. рис. 5) показываются соединения, которые находятся в состоянии ошибки. Эта диаграмма может быть пустой, если ошибок соединений не существует.
Рис. 5. На представлении диаграммы нарушенные соединения выделены
Рис. 5. На представлении диаграммы нарушенные соединения выделены
На диаграмме Connection Objects (объекты соединений) выделяются соединения между контроллерами доменов. На диаграмме Site Links (каналы связи узлов) показан каждый узел службы Active Directory, включая соответствующие контроллеры доменов этого узла и соединяющие узлы каналы связи.
Так как созданные MOM для этих представлений диаграммы являются динамическими, их можно экспортировать в Visio, где их будет несложно отредактировать и настроить. Например, на рис. 6 показана диаграмма Site Links (каналы связи узлов), отредактированная в Visio.
Рис. 6. Редактирование диаграммы Site Links в Visio
Рис. 6. Редактирование диаграммы Site Links в Visio (Щелкните изображение, чтобы уменьшить его)
Рис. 6. Редактирование диаграммы Site Links в Visio
Рис. 6. Редактирование диаграммы Site Links в Visio (Щелкните изображение, чтобы увеличить его)
На рис. 7 приведены отчеты, которые можно получить с помощью пакета управления службой Active Directory. Связанные с этим пакетом управления группы компьютеров показаны на рис. 8. Как видите, группы компьютеров службы Active Directory заполняются путем явного включения в группы; группы компьютеров Windows заполняются в соответствии с версией операционной системы и в зависимости от того, является ли машина контроллером домена.
Figure 8 Группы компьютеров (Close Figure 8)

Наблюдение за службой Active Directory со стороны клиентов
Данные о задержках репликации службы Active Directory
Сбор £ источники
Данные о задержках репликации службы Active Directory
Сбор £ цели
Наблюдение за довериями службы Active Directory
Контроллеры доменов системы Windows 2000 Server
Контроллеры доменов системы Windows Server 2003
Figure 7 Отчеты службы каталогов Active Directory (Close Figure 7)

Контроллер домена службы AD
Владельцы ролей службы AD
Объекты соединений репликации службы AD
Каналы связи узлов репликации службы AD
Дисковое пространство контроллеров доменов службы AD
Изменения доменов службы AD
Ошибки при проверке подлинности учетной записи компьютера службы AD
Пропускная способность репликации службы AD
Задержка репликации службы AD
На контроллерах доменов под управлением ОС Windows Server 2003 пакет управления службой Active Directory может быть настроен для работы с малым объемом прав. Этот пакет управления не поддерживает осуществление наблюдения без наличия агентов. В системе Windows 2000 Server учетная запись действия агента должна входить в группу «Администраторы домена» или локальную группу «Администраторы». Для работы с малым объемом прав учетная запись действия агента на контроллерах доменов под управлением системы Windows Server 2003 должна иметь дополнительные разрешения, включая членство в группе «Пользователи» и «Пользователи системного монитора», доступ к журналам регистрации событий и наличие прав «Управлять аудитом и журналом безопасности» (SeSecurityPrivilege), «Создание журналов безопасности» (SeAuditPrivilege) и «Разрешить локальный вход в систему» (SeInteractiveLog-onRight). Кроме того, необходим следующий доступ: полный доступ к контейнеру CN=MomLatencyMonitors службы Active Directory для наблюдения за репликацией, доступ для чтения к каталогам, содержащим базу данных NTDS.dit, файлы журналов, и доступ для чтения к следующему разделу реестра:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Service\NTDS\Parameters
При осуществлении наблюдения за довериями в системе Windows Server 2003 необходимо обратить внимание на то, что для выполнения сценария AD Monitor Trusts требуется вхождение учетной записи действия агента в группу «Администраторы домена» или «Администраторы».
Пакет управления службой Active Directory можно загрузить по адресу go.microsoft.com/fwlink/?LinkId=79540.

Настройка MOM для службы Active Directory
Пакет управления службой Active Directory должен быть настроен, иначе предупреждения будут постоянно заполнять консоль. Самым неспокойным временем для пакета управления службой Active Directory является момент, когда происходит перезапуск контроллера домена £ кажется, что запускаются все возможные предупреждения. Плохое известие заключается в том, что это непросто остановить. Для управления предупреждениями во время запланированных периодов осуществления технического обслуживания лучше всего использовать режим обслуживания MOM. Задача режима обслуживания состоит в автоматическом разрешении предупреждений для контроллеров доменов, чтобы консоль не заполнялась.
Не забудьте настроить группу Active Directory Client Side Monitoring (наблюдение за службой Active Directory со стороны клиентов), включив в эту группу клиентские компьютеры и соответствующие серверы. Связанные с этой группой правила помогут определить работоспособность FSMO и возможность подключения к ним.
Существуют правила в отношении производительности, которые используют пороговые значения для привязки к FSMO с применением LDAP, PING и DNS для проверки возможности подключения. Эти правила располагаются в касающихся производительности правилах Active Directory Availability (доступность службы Active Directory). Используемые этими правилами пороговые значения можно настроить, определив серьезность предупреждений. Например, привязки FSMO используют значения атрибутов, которые выражены в секундах. Касающиеся производительности правила для каждой роли FSMO используют эту методику создания предупреждений.
Важно понимать, как работают настройки Alert Severity Calculation (вычисление серьезности предупреждения) для State Rule (правило, касающееся состояния). В этом диалоговом окне для значения атрибута используются условия конструкции If-Else и задается соответствующая серьезность тревоги (см. рис. 9). Когда роль собирает данные счетчика Last Bind, созданного сценарием AD Op Master Response, она проверяет их, сравнивая с условными пороговыми значениями, заданными этими правилами. Необходимо настроить для среды эти различные уровни предупреждений.
Рис. 9. Настройка правил серьезности предупреждений
Рис. 9. Настройка правил серьезности предупреждений (Щелкните изображение, чтобы уменьшить его)
Рис. 9. Настройка правил серьезности предупреждений
Рис. 9. Настройка правил серьезности предупреждений (Щелкните изображение, чтобы увеличить его)
Не забудьте о расписании выполнения репликации для каждого контроллера домена. Если какой-либо определенный контроллер домена имеет расписание, отличающееся от расписаний других контроллеров доменов, то это исказит результаты задержки репликации и приведет к установлению более высоких пороговых значений. Параметры сценариев репликации следует устанавливать в соответствии с потребностями каждой конкретной среды. Важно отметить, что при отключении контроллера домена или возникновении на нем проблем с репликацией каждый другой контроллер домена этих групп может сообщить о сбое репликации на этом контроллере домена, даже если он и не является его непосредственным партнером по репликации. Следовательно, даже при переводе являющегося причиной неполадок контроллера домена в режим обслуживания другие контроллеры доменов могут сообщать о сбоях репликации.
В случае наблюдения за репликацией на настройку пакета управления службой Active Directory необходимо потратить больше всего усилий. Необходимо запустить пакет управления в своей среде на пару недель, чтобы увидеть, как он выдает предупреждения. Если вы увидите, что некоторые тенденции развиваются, то с помощью отчетов определите граничные значения задержек и соответствующим образом настройте пороговые значения.
И наконец, следует воспользоваться указаниями, приведенными в статье Alert Tuning Solution Accelerator (на английском языке).

Взгляд в будущее
Программы MOM 2005 и пакет управления службой Active Directory позволяют эффективно и действенно наблюдать за реализацией службы Active Directory организации. С помощью пакетов управления службами Active Directory, DHCP, DNS, FRS и основной системой Windows Server можно лучше отслеживать большую часть аспектов инфраструктуры, защищая работоспособность и благополучие инфраструктуры службы Active Directory, а также пользователей. Используя большое количество данных, собранных в хранилище данных отчетов, можно выполнить анализ производительности и данных о событиях, чтобы помочь в планировании необходимых мощностей и отслеживании тенденций, касающихся производительности.
Чтобы найти описанные в этой статье пакеты управления, а также многие другие пакеты, см. каталог Management Pack Catalog (на английском языке).
В следующее обновление пакета управления службой Active Directory будет включен обычный набор исправлений и подстроек нескольких пороговых значений. Больший интерес представляют новые функции, которые планируется включить в следующий выпуск этого продукта, называемый System Center Operations Manager 2007, включая возможность осуществлять наблюдение за несколькими лесами из одной группы настройки, определять группы контроллеров доменов (каждая из которых будет иметь свою предполагаемую задержку репликации между другими группами) и вести наблюдение за контроллерами доменов, работающими на следующей версии системы Window Server. Подробности см. на веб-узле microsoft.com/mom, посвященном программам MOM.

Джон Ханн (John Hann) работает с MOM с момента выхода версии MOM 2000 и обладает статусом MVP по MOM с 2004 г. Джон сотрудничает с MyITForum.com, MOMCommunity.com и LearnMOM.com. С ним можно связаться через его блог.


 Администрирование в операционной системе (ОС) Windows: Как играть в безопасной среде
Администрирование в операционной системе (ОС) Windows Мэт Клефем (Matt Clapham)

Как играть в безопасной среде
Краткий обзор:
  • Запись в защищенные папки и разделы реестра.
  • Сбои, связанные с защитой от копирования.
  • Вопросы, связанные с брандмауэром.
  • Проблемы, касающиеся корпоративных клиентов.

Днем я работаю руководителем программы обеспечения безопасности в корпорации Майкрософт. Я также довольно часто пишу статьи по безопасности для журнала TechNet Magazine. Нет необходимости говорить о том, что я очень серьезно отношусь к безопасности. Но у меня также есть и другие интересы.
В свободное время я люблю поиграть в игры на основе ОС Windows®. Мне особенно нравятся «стрелялки» от первого лица, симуляторы, ролевые и стратегические игры, работающие в реальном масштабе времени. Тем не менее, существует одно «но». Как и мои друзья Джеспер Джоханссон (Jesper Johansson) и Арон Маргосис (Aaron Margosis), я отказываюсь от работы с правами администратора, если в этом нет крайней необходимости. Я делаю это частично из-за того, чтобы быть уверенным, что проиграю в сетевой игре только из-за недостатка навыков, а не в результате атаки с помощью скрывающей свое присутствие вредоносной программы, замедляющей прицеливание (см. статью Quake 3 Buffer Overflow Advisory £Советы в отношении переполнения буфера в игре Quake 3, приведенную на боковой панели «Ресурсы»).
Я настолько серьезно отношусь к этому, что часто не могу играть в самые новые игры (см. рис. 1). Если после выполнения установки и обновления игры с использованием учетной записи администратора я не могу запустить ее с использованием учетной записи пользователя с ограниченными правами (LUA) на клиентском компьютере, подключенном к домену сервера Small Business Server, то я сразу ее удаляю. Нет оправдания такой плохой разработке программ, а мне есть из чего выбрать себе игру. Я признаю, что это может показаться чрезмерно серьезным подходом, но в этом вопросе я непреклонен. Тем не менее, я не против того, чтобы обойти несколько незначительных недостатков ради приятной игры, и именно это обсуждается в данной статье. Так что позвольте мне поделиться некоторыми связанными с играми проблемами, с которыми я столкнулся, и найденными мною решениями этих проблем. Краткую сводку наиболее эффективных методов см. на боковой панели Tips for Gaming as a Limited User (Советы, как играть в качестве пользователя с ограниченными правами).
Рис. 1. Проблема доступа к файлам при выполнении обновления вручную
Рис. 1. Проблема доступа к файлам при выполнении обновления вручную (Щелкните изображение, чтобы уменьшить его)
Рис. 1. Проблема доступа к файлам при выполнении обновления вручную
Рис. 1. Проблема доступа к файлам при выполнении обновления вручную (Щелкните изображение, чтобы увеличить его)

Распространенные проблемы
Ничего нового в проблеме предоставления прав нет. Существует множество игр и иных видов программ, для надлежащей работы которых необходимы права администратора. Обратитесь к статье «Certain Programs Do Not Work Correctly if You Log On Using a Limited User Account»Некоторые программы работают неправильно при входе в систему с использованием учетной записи с ограниченными правами» в базе знаний (см. ссылку support.microsoft.com/kb/307091). В ней перечислены около 200 игр и приложений, при запуске которых пользователем с ограниченными правами возникают проблемы, в том числе несколько программ корпорации Майкрософт.
Хочу пояснить, что я не считаю проблемой необходимость в наличии прав администратора для установки или обновления (вручную) игры. Это будет обычным требованием до тех пор, пока мы не сможем в ОС Windows выполнять стандартную установку программ для отдельных пользователей. Этот день приближается, но еще не наступил. Однако после того как игра установлена и обновлена, она должна быть готова к тому, чтобы в нее мог играть любой пользователь системы, даже имеющий ограниченные права.
Попытки выполнения записи в защищенные папки и разделы реестра Одна из наиболее распространенных проблем, с которой я сталкивался, это сбой при запуске или во время игры в результате попытки записи в защищенные папки или разделы реестра (свойственно многим приложениям на основе ОС Windows). По умолчанию запись в определенные папки (например %PROGRAMFILES%) и кусты реестра (например HKEY_LOCAL_MACHINE) могут осуществлять только администраторы (и не рекомендуемые для выполнения таких действий опытные пользователи). Возникающие в результате этого ошибки достаточно очевидны: «Error 42: Can't write log files to C:\Program Files\CoolGamesInc\NewestFPS\Logs\» (Код ошибки 42: невозможно записать файлы журналов в папку C:\Program Files\CoolGamesInc\NewestFPS\Logs\) или «Game not installed properly, reinstall and restart» (Игра не установлена надлежащим образом, переустановите ее и перезапустите компьютер). Я также видел примеры возникновения ошибок во время игры, например сообщения об ошибках, возникающие при сохранении своих достижений. Иногда авторы игр хотя бы предупреждают пользователя о том, что в настоящее время для работы программы необходимы права администратора, что я наблюдал в игре Age of Mythology®. Многопользовательские интерактивные игры часто приводят к возникновению проблем с правами, так как они часто самостоятельно обновляются, а задачу самостоятельного обновления технологически решить несколько сложнее. Когда я попробовал поиграть в пробную версию игры EVE Online, я обратил внимание на то, что у этой программы проблема заключатся не только в сохранении файлов журналов регистрации в ненадлежащие места, но также и в попытках самообновления данных содержания игры с сохранением в установочную папку.
Сбои, связанные с защитой от копирования Второй из замеченных мною наиболее распространенных причин, по которым игры не запускаются, являются случаи, когда встроенная защита игры от копирования (или другая функция, препятствующая пиратскому копированию) не работает при запуске программы пользователем с ограниченными правами. Возможно, драйвер не запускался правильно или не запускалась какая-то работающая в фоновом режиме служба. Наиболее распространенное проявление этой проблемы, которое я видел, выражалось в том, что игра выдавала запрос пользователю вставить диск даже в том случае, когда требуемый носитель уже был вставлен в дисковод. Я также видел игры, которые сообщали о необходимости наличия прав администратора, исходя из неправомерного мнения о том, что только администраторы могут надлежащим образом запускать проверку защиты от копирования. В худших случаях выдавалось плохо сформулированное, бессмысленное сообщение об ошибке, которая не упоминается на узле поддержки игры.
Отсутствие запроса о добавлении исключения в настройки брандмауэра Многопользовательские игры, в которые можно играть по локальной сети или через Интернет, очень распространены, и в ОС Windows XP с пакетом обновления 2 (SP2) добавлено сообщение, уведомляющее пользователя о том, что приложения пытаются прослушивать сеть. Это приводит меня к следующей часто встречающейся проблеме: существуют игры, требующие наличия исключения в настройках брандмауэра, но не выдающие запрос о добавлении этого исключения во время установки. Так как пользователи с ограниченными правами не могут изменять настройки брандмауэра, то это предупреждение (см. рис. 2) не может быть устранено без выполнения определенных настроек администратором. Хуже того, иногда эта проблема не очевидна, так как предупреждение появляется в оболочке системы Windows, а не в интерфейсе игры. Фактически данное сообщение об ошибке обычно даже не видно до выхода из игры.
Рис. 2. Когда настройки брандмауэра прекращают развлечение
Рис. 2. Когда настройки брандмауэра прекращают развлечение (Щелкните изображение, чтобы уменьшить его)
Рис. 2. Когда настройки брандмауэра прекращают развлечение
Рис. 2. Когда настройки брандмауэра прекращают развлечение (Щелкните изображение, чтобы увеличить его)
Проблемы, касающиеся корпоративных клиентов Я обнаружил еще одну проблему, которая не связана непосредственно с запуском программы пользователем с ограниченными правами, но которую, тем не менее, стоит рассмотреть. Моя домашняя компьютерная среда настроена как среда небольшого предприятия (я не будут описывать ее здесь слишком подробно, так как прочитать об этом можно на веб-страницев статье «Master Your Domain: Build a Corporate Network at Home» («Модифицируйте свой домен: создайте корпоративную сеть дома») (на английском языке), которую мы с Jesper Johansson (Джеспером Джоханссоном) опубликовали в выпуске журнала TechNet Magazine за октябрь 2006 г.). Используя сервер SBS 2003 (R2), я настроил полный домен системы Windows с папкой «Мои документы», которая перенаправляется на общий ресурс сервера. Таким образом я обнаружил последнюю широко распространенную проблему, которую рассмотрю в этой статье: игры, которые не работают с корпоративными клиентами.
Я заметил двойную проблему, касающуюся игры Age of Empires® III (AoE3). К чести группы разработчиков нужно сказать, что игра запускается и работает в случае пользователя с ограниченными правами нормально. Однако я заметил, что сценарии загружаются медленно, и это связано с передачей большого количества регистрируемых данных, которые записываются по сети. Кроме того, каждый раз при выходе игра AoE3 теряет настройки, сохраненные игры и достижения. Видно, что файлы находятся в папке «Мои документы», но игра не может их загрузить. Это было большим разочарованием, учитывая то, насколько лучше игра AoE3 стала работать с учетными записями пользователей с ограниченными правами по сравнению с более ранними выпусками этой серии.
Я видел одну игру, которая хотя бы признает наличие подобных проблем с корпоративными клиентами. Когда я попробовал играть в игру Fable®: The Lost Chapters™, она была настолько деликатной, что я получил сообщение о том, что удаленные папки «Мои документы» не поддерживаются, после чего был произведен корректный выход из программы. Я одобряю то, что группа разработчиков признает отсутствие поддержки такого сценария и отказ от продолжения игры. Однако кажется немного странным, что игра прекращает работу, чтобы разочаровать пользователя, учитывая тот факт, что программе требуется записать всего несколько мегабайт данных в папку «Мои документы».

Простые решения
Я сталкивался с изложенными проблемами снова и снова в таком количестве игр, что даже не могу их все вспомнить. К счастью, в большинстве случаев существуют удобные обходные пути. Моим любым способом устранения этих проблем является отказ от такой игры и переход на игру того же жанра, но другого издателя, которая подготовлена к работе с учетными записями пользователей с ограниченными правами. Хотя это и может показаться слишком радикальным решением. И это не очень хорошее решение, когда на новую игру только что были потрачены 60 долларов и нет возможности вернуть ее, потому что коробка уже открыта. Так что давайте рассмотрим способы устранения проблем, возникших с играми, которые уже куплены.Советы о том, как играть, используя учетную запись пользователя с ограниченными правами
  • Обновите систему до ОС Windows Vista.
  • Испытайте демонстрационную версию, прежде чем покупать полную версию. При этом, скорее всего, проявятся все связанные с учетной записью пользователя с ограниченными правами проблемы, которые существуют в полной версии.
  • Просмотрите на веб-странице список программ, в отношении которых известно о существовании проблем, связанных с запуском под учетной записью пользователя с ограниченными правами.
  • Ищите игры, имеющие знак Designed for Windows (разработано для ОС Windows).
  • После установки игры прежде чем запускать ее в качестве пользователя с ограниченными правами, обновите ее.
  • Если Вы обнаружили, что какая-то игра не работает под учетной записью пользователя с ограниченными правами, выразите свою обеспокоенность ее издателю и службе технической поддержки этой компании.
  • При необходимости используйте локальную учетную запись опытного пользователя системы.

Устранение проблем, связанных с защитой от копирования Сначала давайте займемся проблемой с драйвером защиты от копирования. Системы защиты от копирования должны быть, но это не означает, что они должны мешать пользователям, не являющимся администраторами, играть в игры! В большинстве игр используется механизм защиты от копирования SafeDisc компании Macrovision, при использовании которого устанавливается драйвер, проверяющий наличие оригинального диска с игрой. По умолчанию этот драйвер настроен таким образом, что запускается по требованию (функция, которую пользователям с ограниченными правами запускать запрещено). Корпорация Майкрософт и компания Macrovision распространяют исправление этой проблемы, но я нашел другой обходной путь:
  1. Пользуясь административной учетной записью, откройте диспетчер устройств.
  2. Перейдите к меню «Вид» и выберите пункт «Показывать скрытые устройства».
  3. Разверните узел Non-Plug and Play Drivers (Драйверы устройств не Plug and Play).
  4. Откройте свойства драйвера Security или SecDrv (см.
    Рис. 3. Обеспечение правильной работы механизма защиты от копирования (Щелкните изображение, чтобы уменьшить его)
Рис. 3. Обеспечение правильной работы механизма защиты от копирования
Рис. 3. Обеспечение правильной работы механизма защиты от копирования (Щелкните изображение, чтобы увеличить его)
Так как теперь этот драйвер запускается при первоначальной загрузке компьютера, то в момент, когда пользователь вставляет диск для запуска игры, он готов.
Устранение проблем с доступом к файловой системе и реестру Предполагаемое наличие неограниченного доступа к любой части файловой системы или реестра является распространенной проблемой многих современных и старых программ, а не только игр. В статье Aaron Margosis (Арона Маргосиса) на веб-страницепод названием «Problems of Privilege: Find and Fix LUA Bugs» («Проблемы привилегий: найдите и устраните ошибки, связанные с ограниченными правами пользователя») (на английском языке) решение различных проблем, связанных с необходимостью в обладании правами администратора, рассматривается значительно подробнее.
Проблемы с доступом отслеживать, может быть, несколько сложнее, но если необходимый набор файлов, папок и разделов реестра определен, расширение прав доступа, указанных в списках управления доступом (ACL), чтобы позволить пользователям с ограниченными правами играть в определенную игру, является достаточно простой задачей. Наиболее успешным оказался следующий метод.
  1. Загрузите с веб-узла microsoft.com/technet/sysinternals последние версии служебных программ Filemon и Regmon.
  2. Запустите эти служебные программы как администратор, и пусть они начнут собирать данные в журналы регистрации.
  3. Несколько минут поиграйте в игру в качестве администратора, выполняя наиболее часто используемые задания (начните новую кампанию, сохраните игру, инициируйте сетевую игру и т.д.).
  4. Отфильтруйте результаты в программах Filemon и Regmon, сосредоточившись на случаях доступа, исходящих от тестируемой игры.
  5. Расширьте соответствующим образом права доступа, указанные в списках ACL для папок и разделов реестра, к которым обращается игра.
  6. Запустите игру без прав администратора, чтобы убедиться в том, что она работает.
Однако при расширении прав доступа, указанных в списках ACL, будьте осторожны, не расширяйте их слишком сильно (например Everyone£Full Control (Всем £ полный контроль)) или на слишком высоком уровне (например HKEY_CLASSES_ROOT). Также лучше избегать изменения прав в отношении системных папок, например %SYSTEMROOT% и %PROGRAMFILES%, чтобы не допустить полного выхода из строя системы Windows или оставления ее в незащищенном состоянии.
Еще одним возможным обходным путем является запуск игры в качестве локального опытного пользователя системы. Это, по-моему, не лучший выход, но при использовании учетной записи, являющейся локальной для данной системы, в случае происшествия масштабы ущерба будут хотя бы ограничены одной рабочей станцией. Я пришел к выводу, что это способ действует для большинства игр, которые предположительно работают правильно только при их запуске администратором.
В качестве отступления можно отметить, что удобным способом самообновления игры является кратковременный запуск ее в качестве администратора. Я обычно запускаю игру в качестве администратора, вызываю ее функцию обновления, затем выхожу из игры и возвращаюсь к своей учетной записи пользователя с ограниченными правами, чтобы поиграть по-настоящему. (Стоит отметить, что ОС Windows Vista™ позволяет пользователям с ограниченными правами обновлять приложения, если исправления подписаны исходным издателем.)
Система Windows Vista также способствует разрешению проблем, возникающих у игр и приложений с доступом к файлам и реестру. По умолчанию запускаемые пользователями с ограниченными правами программы имеют включенные оболочки виртуализации, которые в случае неправильного доступа к файлу или реестру выполняют переадресацию к кэшу конкретного пользователя. Я лично видел разработанные в эпоху ОС Windows 9x игры (например игру The Neverhood), которые не работали нормально в ОС Windows XP (из-за проблем с правами), но отлично работают в ОС Windows Vista с оболочками по умолчанию. Я с нетерпением жду возможности протестировать проблематичные игры в ОС Windows Vista, но чувствую, что мне будет сложно найти игру, для которой ОС Windows Vista не сможет настроить подходящую оболочку.
Устранение проблем с брандмауэром. Лучше всего проблемы с брандмауэром разрешаются при первоначальной установке игры. Однако, если программа настройки игры не настолько продумана, чтобы запросить и выполнить необходимые настройки брандмауэра, ниже приводится метод, который, по моему мнению, работает хорошо.
  1. Войдите в систему как администратор.
  2. Из панели управления откройте брандмауэр Windows.
  3. Выберите добавление программы в список исключений брандмауэра.
  4. Выберите в списке игру или найдите исполняемый файл игры с помощью окна обозревателя, когда это будет предложено.
Добавляя исполняемый файл игры в исключения брандмауэра, я обеспечиваю этой игре доступ к любым портам, которые ей нужны для правильной работы. Затем следует большая бойня!
Устранение проблем, касающихся корпоративных клиентов Проблемы, которые возникают при запуске игр на корпоративных клиентах, со временем исчезнут. Число семей, имеющих несколько компьютеров и широкополосную сеть, увеличивается, и сообщество пользователей, которые в домашних условиях применяют сервер SBS, растет. Но пока решение все еще необходимо.
В моем конкретном случае я обнаружил, что использование в системе локальной учетной записи пользователя с ограниченными правами позволяет обойти проблему, связанную с перенаправлением папки «Мои документы». Игры Age of Empires III и Fable: The Lost Chapters отлично работали при запуске пользователем с ограниченными правами, если папка «Мои документы» не переадресовывалась в сетевую папку.Ресурсы
  • Quake 3 Buffer Overflow Advisory (на английском языке)
  • Windows Vista Application Development Requirements for User Account Control Compatibility (на английском языке)
  • Applying the Principle of Least Privilege to User Accounts on Windows XP (на английском языке)
  • Aaron Margosis’ LUA Buglight tool (на английском языке)
  • Standard User Analyzer
  • Master Your Own Domain: Build a Corporate Network at Home (на английском языке)
  • Problems of Privilege: Find and Fix LUA Bugs (на английском языке)
  • Некоторые программы работают неправильно при входе в систему с использованием учетной записи с ограниченными правами

Заключение
Я настоятельно рекомендую запускать программы в качестве пользователя с ограниченными правами чтобы иметь возможность пользоваться преимуществами, связанными с работой не в качестве администратора. Не всегда просто играть в подключенном к корпоративной среде и предоставляющем меньше всего прав мире, но это далеко не невозможно. За много лет я нашел множество игр в каждом из жанров, которые правильно работают при использовании учетной записи пользователя с ограниченными правами. И я обнаружил несколько способов устранения проблем, позволяющих заставить работать множество других игр. Тем временем за счет введенной в системе Windows Vista виртуализации игры, в которые невозможно было играть в качестве пользователя с ограниченными правами в ОС Windows XP, снова начинают работать.

Мэт Клефем (Matt Clapham), руководитель программы обеспечения безопасности в корпорации Майкрософт, активный участник сообщества по обеспечению безопасности в сфере информационных технологий г. Сиэтла и член группы управления рисками, действующей в рамках проекта развития информационных технологий.


 От редактора: Заглянем под капот
От редактора
Заглянем под капот

Windows Vista находится в состоянии полной боевой готовности перед тем как оказать значительное влияние на ИТ-отделы многих компаний в 2007 году. InformationWeek опубликовала последний прогноз IDC, согласно которому прямым следствием выхода Windows Vista на рынок станет 100 000 новых рабочих мест в этом году. Около 90 миллионов новых компьютеров в этом же году будут проданы с установленной Windows Vista, а к следующему году доля компьютеров с предварительно установленной Windows Vista из числа продаваемых компаниям составит 80%. Сейчас же наша задача состоит в том, чтобы помочь вам решить, использовать ли новую систему в вашей компании.
В этом месяце журнал TechNet Magazine начинает публикацию серии статей, посвященных глубокому анализу той части Windows Vista, которая в первую очередь характеризует новую операционную систему и отличает ее от остальных, £ ее ядру.Конечно, Windows Vista обладает новыми возможностями, привлекательными для пользователей, но если бы они были главной причиной перехода, то мы бы еще подумали. Ядро £ это сердце операционной системы, и ядро новой ОС работает значительно лучше, чем предыдущих версий.
И кто может рассказать об этих изменениях лучше, чем Марк Русинович (Mark Russinovich), который знает о ядре Windows больше, чем кто бы то ни было на планете? Его книга Windows Internals, написанная в соавторстве с Дэвидом Соломоном (David Solomon), стала главным источником информации для тех, кто хотел бы «заглянуть под капот» новой системе.
В этом месяце Марк рассказывает об усовершенствованиях, внесенных в распределение ресурсов центрального процессора, а также об улучшениях на уровне ядра операционной системы, повышающих производительность подсистемы мультимедиа Windows Vista. В статье также рассматриваются важные изменения, которые были внесены в модель ввода-вывода Windows Vista, включая символьные ссылки на файлы, новую функцию отмены синхронных операций ввода-вывода (на мой взгляд, главное изменение), а также концепцию приоритета операций ввода-вывода. Если вы думаете, использовать ли Windows Vista в вашей организации, обязательно прочтите статью Марка с исчерпывающим анализом системы.
Конечно, мы также попытаемся помочь пользователям Windows решить задачи, с которыми они сталкиваются в работе каждый день. Этот выпуск журнала рассказывает о многих особенностях администрирования Windows и включает статьи о распределении полномочий в Active Directory, новыx настройках Group Policy в Windows Vista, выявлении и устранении неисправностей в Group Policy и наблюдении за Active Directory, осуществляемом при помощи MOM.
И в заключение, если вы любите компьютерные игры и цените компьютерную безопасность, мы рекомендуем вам ознакомиться с публикацией о новой безопасной среде для компьютерных игр. Все мы знаем, что делу время, а потехе час. £ ДЖОШУА ТРУПИН (JOSHUA TRUPIN)

Мы хотели бы поблагодарить следующих технических специалистов по продуктам корпорации Майкрософт: Мэта Айерса (Matt Ayers), Юджина Бэка (Eugene Bak), Виджея Бхарадвая (Vijay Bharadwaj), Майкла Фортина (Michael Fortin), Дэвида Хикса (David Hicks), Хушру Ирани (Khushru Irani), Мехмеда Айигана (Mehmet Iyigun), Аруна Кишана (Arun Kishan), Марка Лоуренса (Mark Lawrence), Павла Лебединского (Pavel Lebedynskiy), Бена Майкла (Ben Mickle), Майкла Мурголо (Michael Murgolo), Джона Орефиса (John Orefice), Райвишанкара Пудипедди (Ravisankar Pudipeddi), Джеффри Рихтера (Jeffrey Richter), Дэвида Соломона (David Solomon), Джима Трухера (Jim Truher), Лэнди Ванга (Landy Wang) и Энди Зайглера (Andy Zeigler).


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

Перемещайте данные
Пакет SQL Examiner Bundle
www.sqlaccessories.com
Какой бы ни была роль специалиста в организации £ будь то роль администратора БД, разработчика, специалиста по эксплуатации или мастера на все руки £ если он работает с СУБД SQL Server™, то, возможно, ему приходится перемещать данные из одной среды в другую и заботиться о том, чтобы при этом не пострадала целостность данных и структур данных. Разумеется, в СУБД SQL Server встроено множество средств для репликации (копирования) и синхронизации, но когда приходится проверять, в точности ли база данных, используемая для контроля качества, соответствует той, что используется для разработки, то такой экономящий время и усилия инструмент, как пакет SQL Examiner Bundle компании TulaSoft, может оказаться бесценным.
Всего несколько раз щелкнув мышью, можно заставить это приложение выявить несоответствия как в структуре данных, так и между данными в двух экземплярах базы данных. Для этого нужно просто задать программе те базы данных, которые нужно проверить, и запустить процесс. Как и можно предположить по его названию, пакет SQL Examiner Bundle объединяет два приложения: SQL Examiner и SQL Data Examiner. Программа SQL Examiner исследует структуру баз данных, а SQL Data Examiner изучает данные целиком и выделяет различия.
Программа SQL Examiner просмотрит и сравнит все то, что содержится в экземплярах баз, от таблиц и хранимых процедур до полнотекстовых каталогов и коллекций XML-схем. Те, кто использует СУБД SQL Server 2005, могут также сравнивать сборки среды CLR. Когда сравнение баз данных произведено, программа SQL Examiner позволяет выбрать, какие объекты базы следует синхронизировать, и направление синхронизации.
Пользуйтесь приложением SQL Examiner для изучения и сравнения БД
Пользуйтесь приложением SQL Examiner для изучения и сравнения БД (Щелкните изображение, чтобы уменьшить его)
Пользуйтесь приложением SQL Examiner для изучения и сравнения БД
Пользуйтесь приложением SQL Examiner для изучения и сравнения БД (Щелкните изображение, чтобы увеличить его)
Одна из серьезных особенностей данного приложения состоит в том, что оно формирует сценарий SQL, создающий объект, и выделяет различия в этом сценарии между проанализированными базами данных. Это £ прекрасный способ выделить ошибки после неудачной попытки сформировать структуру целевой базы данных с помощью сценария создания или миграции. («А, вот где я прозевал кластеризованный индекс!») Составленные сценарии можно выполнять по отдельности, сохранить для того, чтобы выполнить позже, или просто нажать кнопку Synchronize (Синхронизировать) и предоставить программе возможность делать всю работу за пользователя.
Другая приятная особенность £ возможность исключать те или иные элементы из сравнения, например игнорировать комментарии, триггеры, индексы или расширенные свойства объекта. После изучения результатов сравнения структуры, программа SQL Data Examiner позволяет исследовать данные для того, чтобы обнаружить любые несоответствия в них. Можно выбрать, какие таблицы нужно сравнивать, а также по каким столбцам указанных таблиц должно производиться сравнение. Когда сравнение таблиц данных произведено, можно видеть, какие столбцы совпадают, какие различаются, а какие находятся только в одной базе данных.
Как и в случае программы SQL Examiner, приложение SQL Data Examiner позволяет синхронизировать таблицы щелчком мыши и выбирать переносимые данные и направление их переноса. Оба приложения позволяют сохранить сделанные настройки в виде проекта, так что не придется каждый раз заново создавать уже созданные задания. Каждое из приложений можно приобрести по отдельности, но опыт автора подсказывает, что пользователь пожелает купить оба.
Цена: 299,95 долларов США за лицензию для одного пользователя.

Найдите дубликаты файлов
Программа zsDuplicateHunter (Профессиональный выпуск)
Компания Zizasoft
Если деятельность специалиста связана с управлением настольными компьютерами, ему, конечно, приходилось сталкиваться с пользователем, на машине которого «кончилось свободное место». Расследование показывает, что этот пользователь делал копии своих документов каждый раз, когда вносил в них какое-нибудь исправление, хотя для хранения файлов пользователей имеется хранилище с резервным копированием, подключаемое к сети (NAS). Или имеется сервер журналов с запущенными процессами пакетной обработки, которые обеспечили дублирование журналов большого объема, занявших в результате все отведенное на сервере место. Одним из возможных решений этих проблем является использование программы zsDuplicateHunter Professional Edition £ приложения для поиска дубликатов файлов нa базе языка Java, которое может работать под операционными системами (ОС) Windows®, Linux или Mac OS X.
Это приложение позволяет легко вести поиск на отдельных приводах, в каталогах и в общих сетевых ресурсах и выявлять возможные дубликаты. Программа не ограничивается сравнением названий файлов, но также позволяет группировать файлы по размеру, контрольной сумме или даже хэшу для выявления тонких различий подготовленных к удалению дубликатов файлов. Кроме того, не обязательно окончательно удалять обнаруженные дубликаты. В качестве меры предосторожности программа позволяет перемещать все отмеченные дубликаты в особую папку.
Другой приятной особенностью является возможность сохранить файлы, расположенные в особой папке, но удалить дубликаты в других местах, позволяющая выбрать чистый исходный каталог и очистить все другие, которые могут находиться на диске. В результатах поиска можно также двойным щелчком открыть любой файл в соответствующей программе просмотра таких файлов, сортировать файлы и выбирать их, чтобы получить точно те результаты, которые нужны. Приятная профессиональная возможность позволяет управлять тем, какое количество памяти разрешено занимать приложению при поиске дубликатов. В качестве дополнительной защиты можно также отключить поиск скрытых или системных файлов для гарантии сохранения того, что не должно быть удалено, а также тех файлов, за которые отвечает операционная система или другое приложение.
В профессиональном выпуске (Professional Edition) предусмотрен также детализированный фильтр для набора результатов поиска, позволяющий использовать для точного поиска файлов, которые нужно удалить, регулярные выражения.
Цена: 39,95 долларов США за лицензию для одного пользователя..

Возьмите приложения с собой
Программа MojoPac
www.mojopac.com
Если приходится постоянно менять операционные системы, в которых недостает привычных приложений и настроек компьютера, или просто не хочется оставлять на чужом компьютере свои следы, может быть интересным ознакомиться с приложением MojoPac компании RingCube Technologies.
Если оставить в стороне легкомысленные названия, можно сказать, что программа MojoPac позволяет с помощью жесткого диска, управляемого по шине USB, персонального мультимедиа-устройства, которое можно подключить к базовому компьютеру по шине USB 2.0 (например проигрывателя Zune или iPod), или даже сотового телефона, если у него достаточно памяти, перенести имеющиеся настройки и приложения в любую систему Windows XP (выпуски Home, Professional, Media Center или Tablet). Во время написания этого обзора поддержки базовых систем под управлением ОС Windows Vista™ и Windows 2000 не было, но в документации на веб-узле программы было сказано, что скоро будет доступно обновление, поддерживающее эти ОС.
Программа MojoPac позволяет переносить настройки
Программа MojoPac позволяет переносить настройки (Щелкните изображение, чтобы уменьшить его)
Программа MojoPac позволяет переносить настройки
Программа MojoPac позволяет переносить настройки (Щелкните изображение, чтобы увеличить его)
В настоящее время для работы программы MojoPac требуются права администратора в базовой системе, но разрабатываемая версия 2.0 будет поддерживать работу в режиме пользователя с ограниченными правами. Это программное средство по существу выступает как посредник между базовой ОС и устройствами хранения и при первом запуске после установки приложения на мобильное устройство вызывает запуск процедуры первоначальной настройки учетной записи ОС Windows, устанавливая персональные настройки для пользователя программы на устройство MojoPac.
Когда программа запущена и выполняется, переключение между базовой системой и системой Mojo осуществить несложно: нужно просто щелкнуть область панели инструментов (которую можно минимизировать) в верхней части экрана. Установка приложений на устройство Mojo производится обычным способом, но программа MojoPac при этом должна быть активна. И, пока вы не забыто важное предупреждение о необходимости производить установки в каталог по умолчанию, сделанное в файлах Readme, нужно действовать.
В итоге программа MojoPac обещает быть ценным приобретением для каждого IT-специалиста, который постоянно путешествует, но хочет пользоваться собственными настройками. Например, можно держать в системе MojoPac все служебные программы, анализаторы пакетов и мониторы трафика и заниматься устранением неполадок с любого компьютера организации, не оставляя за собой следов.
Цена: 49,99 долларов США за лицензию для одного пользователя.

Обзор книги
Administrator’s Guide to SQL Server 2005 (Руководство администратора по СУБД SQL Server 2005)
www.aw-bc.com
Все большее количество IT-групп осознает, насколько большие потенциальные возможности и широкую функциональность обеспечивает СУБД SQL Server 2005. В этом приложении появилась масса ценных улучшений, начиная с широкой поддержки XML-данных и кончая службами SQL Server Integration Services (SSIS) и компонентом SQL Server 2005 Service Broker. Бак Вуди (Buck Woody) написал превосходное справочное руководство, которое поможет приступить к осуществлению программы обновления или к администрированию недавно установленного экземпляра СУБД SQL Server 2005 £ Administrator’s Guide to SQL Server 2005 (Addison-Wesley Professional, 2006).
Книга позволяет глубже понять технологии практического администрирования применительно к новой серверной платформе и в отличие от многих других существующих справочников делает это в сжатой форме. Книга начинается с раздела об определении размеров инфраструктуры, соответствующих требованиям работающих приложений, а также с руководства по выбору версий СУБД SQL Server, подходящих для разных сценариев использования. Здесь же можно получить представление о том, как спроектировать инфраструктуру, чтобы она не привела к образованию лишних узких мест в системе.
Далее руководство переходит к описанию различных программных средств, входящих в комплект СУБД SQL Server, таких как усовершенствованный вариант приложения SQL Server Profiler и новая среда SQL Server Management Studio. Предоставлена возможность углубленного изучения задач обслуживания и автоматизации, планирования дальнейшего развития на базе профилирования сервера и выигрыша за счет подходящего для реализации СУБД плана обслуживания.
Кроме того, в главе, посвященной безопасности, можно узнать, как защитить систему, начиная с сетевого уровня и уровня оборудования, и кончая уровнем операционной системы и экземпляра СУБД SQL Server. Здесь же можно бегло ознакомиться с дополнительными службами шифрования, сертификации и управления ключами, которые предоставляет новая платформа.
Одна глава посвящена объяснению механизмов обеспечения высокого уровня доступности системы в соответствии с требованиями применяемой реализации. Можно изучить использование кластеров, зеркального отображения баз данных, репликации и доставки журналов как способов обеспечения предъявляемых требований. А что касается виртуализации, которая становится прекрасным новым способом добиться высокого уровня доступности, избежав накладных расходов, связанных с физически независимыми инфраструктурами, книга содержит пошаговое руководство по настройке двухузлового кластера на основе продукта Microsoft Virtual Server.
Глава, посвященная службам SSIS, показывает, как пользоваться этим новым программным средством (прощайте, службы DTS!) не только для разработки и развертывания функций извлечения, преобразования и загрузки (ETL), но и для создания задач наблюдения, отправки извещений по электронной почте и резервного копирования.
Наконец, последние несколько глав посвящены углубленному описанию входящих в новую платформу SQL Server служб Reporting Services и Analysis Services. Здесь будет затронуто проектирование и создание отчетов, управление системами подготовки отчетов и проблемы, связанные с обслуживанием развернутых служб Analysis Services.
В целом, Administrator’s Guide to SQL Server 2005 £ это прекрасный способ ускорить работу, связанную с администрированием СУБД SQL Server 2005, наблюдением за ней и обновлением до нее предыдущих версий.
Цена: 49,99 долларов США.


 SQL: вопросы и ответы: Размер базы данных, зеркальное отображение, помеченные транзакции и прочее
SQL: вопросы и ответы
Размер базы данных, зеркальное отображение, помеченные транзакции и прочее
Под редакцией Нэнси Митчелл (Nancy Michell)

Перенос кластера
В. Требуется перенести кластер SQL Server 2000 на новый IP-адрес (оба физических сервера, лежащих в основе), а также кластер Windows® и кластер SQL Server™. Придется ли полностью перестраивать решение?
О. Нет, нужно просто запустить программу установки SQL Server и изменить IP-адреса. В данной статье базы знаний рассказывается, как это сделать (статья на английском языке).

Размер базы данных
В. Имеется сервер SQL Server 2000 SP4 с критически важной базой данных, размер которой составляет почти 10 ГБ. Используется режим восстановления Simple Recovery Model, размер основного файла 9850 МБ, а размер файла журнала операций 88 МБ. Размер резервной копии базы данных также составляет почти 10 ГБ. Следует ли уменьшить размер базы данных для повышения производительности? Если да, то какой командой воспользоваться, DBCC SHRINKDATABASE или DBCC SHRINKFILE? (К сожалению, в данном случае нет возможности проводить обслуживание в часы минимальной загрузки.)
О. Команды DBCC SHRINKDATABASE и DBCC SHRINKFILE полезны только в том случае, если записи в базе данных часто удаляются и обновляются, что приводит к уменьшению объема данных. Тут важно, почему вообще возник такой вопрос. Сегодня 10 ГБ пространства на жестком диске обходятся примерно в 20 долларов США. Может быть, имеет смысл добавить примерно 100 ГБ и использовать эту базу данных дальше? Фрагментация данных на жестком диске будет сказываться на производительности, но если нет возможности производить обслуживание, то особого выбора нет. Иногда в подобных случаях используется еще одна копия базы данных. Резервная копия обновляется при репликации, выполняется обслуживание резервной копии, а затем приложения переключаются на нее. Разумеется, для применения такого метода потребуется внести определенные изменения в код и перейти с модели восстановления SIMPLE либо на FULL, либо на BULK_LOGGED, но подобный вариант обслуживания может оказаться неплохим долговременным решением.

Обновление и производительность
В. Требуется перенести два приложения с сервера SQL Server 2000 на SQL Server 2005. Как избежать перепадов производительности во время обновления?
О. Обычно спад производительности при обновлении бывает вызван следующими ошибками, которых следует избегать.
  1. После обновления до SQL Server 2005 не восстановлена статистика.
  2. В выражениях с операторами JOINS и WHERE сравниваются данные разных типов, что приводит к снижению производительности. Особенно это влияет на серверы под управлением SQL Server 2000 SP3 и более ранних версий (см. статью support.microsoft.com/kb/271566/ на английском языке).
  3. Неправильно настроен экземпляр сервера SQL Server 2005; неправильно настроена память, расширения AWE, драйверы или какой-то другой компонент. Работа машины, на которой установлен SQL Server 2000, была оптимизирована, но человек, выполнявший оптимизацию, не зафиксировал этот факт документально, и для экземпляра SQL Server 2005 оптимизация проведена не была.
  4. Сбои вызываются оборудованием. Часто оборудование покупается из-за того, что в его описании указаны нужные параметры, а на деле оно не выдерживает нагрузки.
Прежде чем переводить экземпляр SQL Server в производственный режим, следует определить базовую производительность, чтобы убедиться, что ожидаемая производительность будет обеспечиваться. Это в дальнейшем позволит избежать проблем, связанных с инфраструктурой. Необходимо снять показания счетчиков Perfmon (счетчиков, показывающих производительность жесткого диска, число операций ввода-вывода и использование памяти) и сравнить значения, полученные для разных экземпляров.

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

В. При попытке настроить асинхронное зеркальное отображение выдается ошибка 1418. Выполнение команды Netstat -ano показывает, что SQL Server на всех серверах прослушивает верные порты. Та же ошибка выдается при попытке запуска зеркального отображения. В чем причина?
О. Проверьте, не блокируется ли соединение брандмауэром. Чаще всего причина кроется именно в этом. Дополнительную справочную информацию можно найти в статье Troubleshooting Database Mirroring Setup и MSSQLSERVER_1418 (статьи на английском языке).
Нужно иметь в виду, что эта проблема не связана с асинхронным зеркальным отображением. При синхронном отображении она также может возникнуть.
Появляющееся сообщение об ошибке («Не удалось подключиться к сетевому адресу "%.*ls" сервера, или адрес не существует. Проверьте имя сетевого адреса и убедитесь, что порты для локальной и удаленной конечных точек в рабочем состоянии») соответствует истине. Чаще всего удаленный партнер на самом деле существует, но к нему не удается подключиться.
Это сообщение может появиться, если произошел сбой в работе сервера, если он не прослушивает порт, и даже если произошел сбой на конечной точке (он может быть вызван тем, что партнеры не могут использовать один и тот же механизм проверки подлинности, или прочими проблемами, связанными с проверкой подлинности). То же самое может происходить, если брандмауэр партнера, инициирующего команду, блокирует сервер, с которым устанавливается связь.
Другие проблемы, на которые стоит обратить внимание в данном случае, могут быть связаны с именем источника данных (DSN) и с разрешением имен. В общем случае рекомендуется использовать полные доменные имена. Короче говоря, подобная проблема чаще всего связана с брандмауэром, но надо иметь в виду, что могут быть и другие причины.

В. Мы собираемся использовать зеркальное отображение для сервера SQL Server 2005, но нам говорили, что отображение лучше не применять, если несколько приложений обращаются к нескольким базам данных, хранящихся на одном и том же экземпляре SQL Server. Так ли это?
О. На самом деле ответ зависит от того, обращается ли каждое приложение к своей отдельной базе данных, или приложения выполняют межбазовые транзакции или транзакции через координатор распределенных транзакций (DTC). Если выполняются межбазовые транзакции, использование зеркального отображения может привести к нарушению логической согласованности, и транзакции будут выполняться некорректно. Подробное объяснение того, что происходит при указанных условиях, приведено в данной статье (статья на английском языке).
Если несколько приложений обращаются к нескольким базам данных, но у каждого приложения отдельная база данных, таких проблем при зеркальном отображении не возникнет.

Помеченные транзакции
В. Что такое помеченные транзакции? Можно ли их использовать, если одна база данных имеет формат SQL Server, а вторая £ Oracle?
Пометка транзакции периодически выполняется DBA для того чтобы поставить метку во всех журналах в одном и том же месте. Вкупе с возможностью восстановить таблицу до метки транзакции это позволяет восстановить все базы данных в том состоянии, в котором они находились в один и тот же момент времени. Операция эта может быть весьма неприятной, поскольку восстанавливать придется все задействованные базы данных, и значит, данные будут утеряны в каждой из них. Избежать необходимости такого восстановления можно, обеспечив сохранность файлов журналов. Помеченные транзакции используются только в SQL Server; если в распределенных транзакциях участвуют базы данных другого типа, они участвовать в пометке транзакций не могут. Обычно пометки транзакций в системах с распределенными базами данных используются редко. В таких системах потеря одного из журналов операций оборачивается катастрофой, и чтобы восстановить систему после нее требуется проделать большой объем работы вручную.

Средство преобразования баз данных Access в формат T-SQL
В. Существует ли средство для автоматического преобразования хранимых процедур из формата Access™-SQL в формат T-SQL?
О. Попробуйте воспользоваться помощником по миграции на SQL Server (SQL Server Migration Assistant, SSMA) для Access, который можно загрузить здесь. На этом же веб-узле есть подобный помощник по миграции для Oracle и Sybase, а также ссылка на статью «Migrating Informix Databases to Microsoft® SQL Server 2000» (на английском языке).
Для преобразования базы данных Access в формат SQL Server можно использовать и мастер преобразования для Office, но в помощнике SSMA для Access (см. рис. 1) больше функций, в том числе возможность создания отчетов по результатам преобразования и возможность сканирования сетей. Помощник SSMA для Access также позволяет устранить большинство проблем, которые мастер преобразования в формат SQL Server решает некорректно.
Рис. 1. Помощник по миграции на SQL Server для Access
Рис. 1. Помощник по миграции на SQL Server для Access (Щелкните изображение, чтобы уменьшить его)
Рис. 1. Помощник по миграции на SQL Server для Access
Рис. 1. Помощник по миграции на SQL Server для Access (Щелкните изображение, чтобы увеличить его)

Некластеризованные индексы
В. Имеется таблица, в которой первичный ключ состоит из двух идентификаторов GUID (скажем, GUID1 и GUID2). На основании идентификаторов GUID1 и GUID2 уже создан уникальный кластеризованный индекс. Теперь в целях устранения проблем, связанных с производительностью, нужно создать второй, некластеризованный индекс для GUID2 и GUID1. Не снизится ли производительность, если объявить индекс уникальным?
О. Объявление некластеризованного индекса уникальным не снижает производительность. В действительности оно может привести к уменьшению числа уровней в дереве индекса.
Если некластеризованный индекс объявляется неуникальным, указатель строки добавляется на страницах, соответствующих корню и промежуточным узлам, в тот элемент индекса, в котором содержится ключ. Это делается для того чтобы упростить удаление и обновление элементов индекса: такое размещение указателей позволяет избежать сканирования синонимичных цепочек в случае наличия повторяющихся ключей, поскольку элемент, который нужно изменить, обнаруживается операцией поиска системы по паре значений (ключ плюс указатель). В результате элементы индекса увеличиваются в размере (а в случае выбора кластеризованного ключа £ значительно увеличиваются). Это приводит к тому, что страницы, соответствующие корню и промежуточным узлам, заполняются быстрее. Если индекс уникален, следует объявлять его уникальным.
Дело в том, что независимо от наличия кластеризованного индекса таблицы для каждого некластеризованного индекса, не объявленного уникальным, в элементы индекса на страницах, соответствующих корню и промежуточным узлам, будет добавлен указатель.
Кроме того, если использовать столбец с целочисленным идентификатором в качестве суррогатного ключа, а затем добавить два уникальных индекса (GUID1, GUID2) и (GUID2, GUID1), производительность, скорее всего, повысится, поскольку в индексах будет 4-битный, а не 32-битный кластеризованный ключ.

Блокировка обновления
В. Имеется хранимая процедура следующего вида.
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION

-- Get The lock if available
UPDATE    ProcessingInstances
SET       LockHolder = @MessageId
WHERE     ( InstanceId = @InstanceId )
AND       ( LockHolder IS NULL )

COMMIT TRANSACTION
При наличии такой процедуры доступ к данным может получить только одна вызывающая программа, а остальным приходится ждать. Можно ли добиться такого же поведения, снизив уровень изоляции?
Кажется, подходящим уровнем будет READ COMMITTED, поскольку в данной транзакции только один запрос, и если в данный момент выполняется другая транзакция, обновляющая запись, данная транзакция будет выполнена только после ее завершения. Верно?
О. В данном примере не параметр serializable вынуждает прочие вызывающие программы ждать, а собственно обновление. Да, можно установить уровень изоляции READ COMMITTED, и тогда, разумеется, при обновлении будет блокироваться любой используемый в нем индекс. Это вызовет сложности для других процессов, выполняющих ту же самую инструкцию: они будут блокироваться до момента окончания обновления. (Кроме того, тут не требуется использовать явную транзакцию, если обновление является единственной инструкцией; каждая инструкция так или иначе входит в отдельную транзакцию, если не включена в явную транзакцию.)
С другой стороны, если в таблице нет строк, отвечающих условию, указанному в части WHERE инструкции UPDATE, использование уровня изоляции serializable гарантирует, что такие строки не будут добавлены или изменены в ходе выполнения других транзакций. Если бы инструкция UPDATE выполнялась при уровне изоляции READ COMMITTED, другие транзакции могли бы добавить строки, удовлетворяющие условию выполнения обновления. Однако если код хранимой процедуры соответствует приведенному, наверное, ни одно из этих действий (использование уровня serializable или транзакции) не имеет смысла. Нужно просто выполнить обновление.

Благодарим за технические консультации следующих ИТ-специалистов корпорации Майкрософт: Горава Аггарваля (Gaurav Aggarwal), Энтони Блоша (Anthony Bloesch), Тодда Брайли (Todd Briley), Шона Кокса (Shaun Cox), Роберто Дипьетро (Roberto Di Pietro), Майкла Эппрехта (Michael Epprecht), Кевина Файли (Kevin Farlee), Умачандара Джаячандрана (Umachandar Jayachandran), Чака Лэдда (Chuck Ladd), Калояна Манассиева (Kaloian Manassiev), Лучано Морейра (Luciano Moreira), Варда Понда (Ward Pond), Марка Пражака (Mark Prazak), Аруначалама Тирупати (Arunachalam Thirupathi), Роджера Вольтера (Roger Wolter), Клемента Йипа (Clement Yip) и Франки Юэнь (Frankie Yuen).


 Обзор служебных программ: Инвентаризация групповых политик
Обзор служебных программ
Инвентаризация групповых политик
Грег Стин (Greg Steen)
Загрузить исходный код для этой статьи: GPInventory.exe (150KB)

НЕВОЗМОЖНО ориентироваться в информации, если не следить за ней. Имея под рукой данные о запасах, можно избежать головной боли на совещаниях по распределению бюджета и при ежегодном аудите. Ну и, разумеется, начальству всегда надо знать, у кого что есть и почему, и что нужно для вот такой большой модернизации.
Средство, которое может помочь в таких случаях, называется инвентаризация групповых политик (GPInventory.exe), входящая в состав Windows Server® 2003 Resource Kit. Эта программа позволяет создавать запросы и возвращает системную информацию с помощью запросов результирующего набора политик пользователя (RSOP) и инструментария управления Windows® (WMI) от различных удаленных узлов, как показано на рисунке. Нет ничего удивительного в том, что эта программа с легкостью производит выборку информации о групповых политиках, но она также эффективна в качестве средства сбора подробной информации о системе, например количество установленных приложений, название и скорость процессора или список установленных исправлений. Но и это еще не все! Поскольку она входит в состав Windows Server 2003 Resource Kit, она полностью бесплатна.
Рис. 1 Использования GPInventory для сбора информации
Рис. 1 Использования GPInventory для сбора информации (Щелкните изображение, чтобы уменьшить его)
Рис. 1 Использования GPInventory для сбора информации
Рис. 1 Использования GPInventory для сбора информации (Щелкните изображение, чтобы увеличить его)
Существует множество разных способов применения GPInventory.exe. Например, если необходимо проверить состояние гарантии, можно собрать серийные или служебные номера компьютеров в сети, не осматривая каждый системный блок. Или же, если нужно узнать, используется ли компьютер в среде лаборатории, можно запросить данные о пользователях, подключенных к данному компьютеру, не вставая со стула. Если на сервере регулярно архивируются и восстанавливаются образы (например для очистки и восстановления среды контроля качества), проверить дату применения последнего образа можно, запросив дату установки компьютера.
Средство GPInventory просто в использовании. Необходимо только указать файл со списком компьютеров, подлежащих инвентаризации, выбрать запросы, которые следует выполнить, и обработать список. Далее программа соединяется с каждым из компьютеров из списка и запрашивает у него данные. Для быстрого запроса можно также выбрать целевые компьютеры прямо в службе каталогов Active Directory®, а действия запроса в меню Запрос.
Чтобы запустить на компьютере запрос RSOP, необходимо иметь разрешение Генерировать RSoP (протоколирование), которое по умолчанию есть у администраторов домена администраторов с делегированными полномочиями. Запросы WMI требуют наличия прав администратора на удаленном компьютере, или же можно использовать оснастку консоли управления управляющим элементом WMI для предоставления прав Включение учетной записи и Включить удаленно в пространстве имен root\cimv2 другому пользователю.
После выполнения запроса его результаты можно сохранить в текстовый файл с разделителем табуляцией или файл XML. Оба типа файлов можно импортировать для анализа в Microsoft® Excel®. Для выяснения всех подробностей результаты можно отсортировать, а затем применить к ним автофильтр.
Средство GPInventory может также выполняться из командной строки, благодаря чему можно просто назначить задание запроса системной информации и сохранить результаты в файл XML непосредственно, без использования графического интерфейса. Это может оказаться очень полезно для запросов, требующих длительного выполнения, которые удобнее выполнять в нерабочее время.
Программа поставляется со стандартным набором запросов RSOP и WMI, но в случае необходимости в файл запроса можно добавлять пользовательский список. В прилагаемом файле справки разъясняется, как определить новый запрос в файле XML списка запроса.
Программа GPInventory.exe является удобным способом сбора информации в сети компьютеров под управлением Windows, будь то для целей инвентаризации, групповых политик или проверки состояния. Ссылка на средство инвентаризации групповых политик находится в разделе загрузки нашего веб-узла (на английском языке)шего загрузки о инвентаризации групповых политик лять пользовательсяжбе каталогов ечніские настрое_

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


 Кабельщик: Поддержка службы QoS в операционной системе (ОС) Windows
Кабельщик
Поддержка службы QoS в операционной системе (ОС) Windows
Джозеф Дэвис (Joseph Davies)
Эта статья частично основана на предварительной версии «Longhorn» ОС Windows Server. Любая содержащаяся в ней информация может быть изменена.

Служба QoS (Quality of Service, качество обслуживания) охватывает ряд экономически эффективных технологий управления сетевым трафиком для расширения возможностей пользователя в домашней и производственной среде. С помощью технологий QoS можно измерять пропускную способность сети, выявлять изменение условий эксплуатации сети (таких как перегрузка или доступность),
назначать приоритеты и регулировать трафик. Например служба QoS может применяться для назначения приоритета обмену данными, чувствительному к задержке (например в голосовых или видеоприложениях), и управления трафиком, менее чувствительным к задержкам, таким как передача больших объемов данных. Для приоритетного обмена данными по протоколу TCP/IP требуется поддержка со стороны узлов и устройств сетевой инфраструктуры. В этом разделе описываются методы использования службы QoS на узлах, работающих под управлением ОС Microsoft® Windows®.
Главная проблема определения службы QoS для сетей с протоколом TCP/IP заключается в том, как задать и обеспечить приоритетный обмен данными по протоколу IP. Хотя базовая спецификация RFC 791 для протокола IP определяла возможность указания в поле Type of Service (TOS) параметров старшинства, задержки, пропускной способности, надежности и стоимости, протокол IP по существу реализует технологию коммутации пакетов по принципу «наибольших усилий» на основе датаграмм, в которой каждый пакет обычно обрабатывается одинаково по принципу «первым прибыл £ первым обслужен».

Настройка приоритетного обмена данными
Для организации приоритетного обмена данными можно выполнить некоторые процедуры. Можно настроить сетевую инфраструктуру таким образом, чтобы обеспечить специальную обработку определенным образом помеченного трафика и затем задать маркирование исходящего трафика на отправляющих узлах. Альтернативный подход £ настроить на отправляющих узлах динамическое программирование сетевой инфраструктуры для обеспечения специальной обработки в соответствии с характеристиками их исходящего трафика (например адресов и номеров портов).
При обмене данными по протоколу TCP/IP можно использовать несколько методов обеспечения приоритетов обмена. Например на уровне сетевого интерфейса для сетей Ethernet по стандарту IEEE 802.1 для разметки кадров, отправляемых узлом с приоритетной доставкой, используется 3-битовое поле Priority в заголовке виртуальной локальной сети (VLAN) кадра протокола Ethernet. Заголовок VLAN помещается в заголовок кадра протокола Ethernet между полем Source Address (Адрес источника) и полем Length (Длина) для кадра IEEE 802.3 или EtherType (Тип сети) для кадра Ethernet II.
Для реализации разметки 802.1p на отправляющем узле требуется, чтобы сетевой адаптер и драйвер устройства поддерживали спецификацию 802.1p и чтобы в сетевом адаптере была включена поддержка этой разметки. Обычно поддержку разметки 802.1p можно включить на вкладке Advanced (Дополнительно) свойств драйвера сетевого адаптера. На маршрутизаторах сети Ethernet также должна быть включена поддержка разметки 802.1p.
На уровне сетевого интерфейса для беспроводных сетей стандарта IEEE 802.1 сертификация Wi-Fi Alliance для мультимедиа Wi-Fi (WMM) определяет четыре категории доступа при назначении приоритетов сетевого трафика. Этими категориями (в порядке убывания приоритета) являются голос, видео, «наибольшие усилия» и фоновый режим. Для поддержки приоритетов беспроводного мультимедиа (WMM) на узле требуется, чтобы WMM поддерживали адаптеры беспроводной сети и их драйверы. В точках беспроводного доступа также должен быть включен режим WMM.
На уровне Интернета можно использовать дифференцированные службы и задать значение поля дифференцирования трафика DSCP (Differentiated Services Code Point) в IP-заголовке. Спецификация RFC 2472 определяет значение поля DSCP как старшие 6 битов поля TOS протокола IP версии 4 (IPv4) и поле Traffic Class протокола IP версии 6 (IPv6).
Корпоративные маршрутизаторы последних моделей поддерживают дифференцирование трафика DSCP, которое, однако, по умолчанию обычно отключено. При пересылке маршрутизаторы, поддерживающие дифференцирование трафика, считывают значение поля DSCP и помещают пакет в соответствующую очередь. Например можно настроить маршрутизаторы таким образом, чтобы в соответствии с заданным значением поля DSCP отправляемые пакеты помещались в очередь высокого приоритета, «наибольшего усилия» или более низкого приоритета. При настроенных очередях и значениях поля DSCP трафик с разметкой приоритетности может различать уровни обслуживания. Например критичный к потере информации сетевой трафик получает приоритет при пересылке данных и не задерживается другим трафиком массовой передачи данных, имеющим более низкий приоритет. Спецификация WMM определяет порядок обращения беспроводного мультимедиа к схеме сопоставления категорий со значениями поля DSCP. Точка беспроводного доступа с поддержкой беспроводного мультимедиа считывает значение поля DSCP и обрабатывает трафик в соответствии с его категорией доступа.
На уровне Интернета можно также использовать протокол резервирования ресурсов (RSVP), сигнальный протокол, описанный в спецификации RFC 2205. С помощью этого протокола узлы могут пытаться зарезервировать пропускную способность на маршруте к конечной точке. Протокол RSVP, однако, пока широко не развернут в сетях и в настоящее время не поддерживается в ОС Windows XP, Windows Server® 2003, Windows Vista™ и в следующей версии ОС Windows Server с кодовым названием «Longhorn» (в данный момент доступна его бета-версия).
Для отправки пакетов, помеченных приоритетной доставкой, приложения или компоненты операционной системы должны быть в состоянии задать значение приоритета разметки 802.1p или поля DSCP. В следующих разделах показано, как компоненты ОС Windows или ее приложения могут задать приоритет разметки 802.1p для кадров протокола Ethernet или значение поля DSCP для обмена данными по протоколу TCP/IP.

Служба QoS в ОС Windows XP и Windows Server 2003
Операционные системы Windows XP и Windows Server 2003 предоставляют интерфейсы приложений для назначения трафику параметров службы QoS. Разработчики для применения параметров QoS на уровне приложения к отдельным сокетам могут использовать службы прикладных интерфейсов Windows Sockets (Winsock) и Generic QoS (GQoS). Администраторы сетей с помощью средств управления трафиком, предназначенных для вызова прикладного интерфейса управления трафиком (TC API), могут применять параметры службы QoS на уровне узла.
С помощью службы Winsock и параметра сокета IP_TOS можно задавать значения поля DSCP для исходящих пакетов канала. Однако по умолчанию стековая память протокола TCP/IP игнорирует параметр сокета IP_TOS. Чтобы использовать параметр сокета IP_TOS, необходимо сначала создать DWORD-значение реестра DisableUserTOSSetting=0 в следующем разделе реестра (см. рис. 1):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Рис. 1 Создание параметра реестра DisableUserTOSetting
Рис. 1 Создание параметра реестра DisableUserTOSetting
Чтобы этот параметр реестра вступил в силу, необходимо перезагрузить компьютер.
Чтобы задать значение поля DSCP для трафика, не прибегая к использованию параметра сокета IP_TOS, можно использовать прикладные интерфейсы службы GQoS. Служба GQoS входит в состав службы Windows Sockets 2.0 (Winsock2). Для реализации возможностей службы QoS в ОС Windows большинство приложений, поддерживающих службу QoS, использует прикладной интерфейс службы GQoS. Служба GQoS в ОС Windows XP с пакетом обновления 2 (SP2) позволяет приложению задавать значение поля DSCP и регулировать свой исходящий трафик. Для назначения приоритетов разметки 802.1p на компьютерах, работающих под управлением ОС Windows XP SP2, необходимо использовать интерфейс TC API.
Интерфейс TC API обеспечивает доступ к механизмам управления трафиком, которые регулируют сетевой трафик на локальном узле. Этот интерфейс позволяет осуществлять прямое управление значениями поля DSCP, разметкой 802.1p и ограничением скорости. Администраторы сети могут использовать программы управления трафиком для вызова интерфейса TC API непосредственно из приложений, не поддерживающих службу QoS. Поскольку TC API является интерфейсом более низкого уровня, чем прикладной интерфейс службы GQoS, то для работы с ним требуются привилегии администратора.
В отличие от прикладного интерфейса службы GQoS интерфейс TC API допускает на одном и том же отправляющем узле объединение трафика от нескольких приложений в один поток службы QoS. В этом объединенном потоке трафик может определяться комбинацией его исходного и конечного IP-адресов, исходного и конечного портов и протокола (TCP или UDP). Например на данном узле весь трафик к определенному конечному IP-адресу может быть включен в общий поток службы QoS для любого исходного и конечного портов независимо от отправляющего приложения. С другой стороны, прикладной интерфейс службы GQoS позволяет определить в приложении его собственную процедуру QoS-обработки данных, которые оно отправляет через сокет.
Для поддержки службы QoS на компьютерах, работающих под управлением ОС Windows XP и Windows Server 2003, должен быть установлен компонент QoS Packet Scheduler (Планировщик пакетов QoS) и включен в окне свойств сетевых подключений папки Network Connections (Сетевые подключения), см. рис. 2. На компьютерах с ОС Windows XP планировщик пакетов QoS (Psched.sys) установлен и включен по умолчанию. Планировщик пакетов можно установить и в ОС Windows Server 2003.
Рис. 2 Настройка планировщика пакетов QoS
Рис. 2 Настройка планировщика пакетов QoS

Служба QoS в ОС Windows Vista и Windows Server «Longhorn»
Поддержка службы QoS в ОС Windows Vista и Windows Server «Longhorn» расширена и упрощена. Для установки значения поля DSCP и управления скоростью отправки данных приложением ИТ-специалисты теперь могут использовать службу QoS на основе политик, не прибегая к использованию прикладных интерфейсов или изменению существующих приложений. Разработчики смогут воспользоваться поддержкой прикладных интерфейсов для службы GQoS и интерфейса TC API, хотя в будущих версиях ОС Windows поддержка этих интерфейсов не планируется. Кроме того, удален параметр Winsock IP_TOS. В качестве замены прикладных интерфейсов для службы GQoS и интерфейса TC API и для упрощения поддержки службы QoS в обновляемых и будущих приложениях ОС Windows Vista и Windows Server «Longhorn» поддерживают новый прикладной интерфейс для службы QoS2, также известный как интерфейс qWAVE (Quality Windows Audio-Video Experience).
Служба QoS на основе политик в ОС Windows Server «Longhorn» и Windows Vista повышает удобство работы конечного пользователя, улучшает управление стоимостью пропускной способности и создает предпосылки для получения более выгодных уровней обслуживания от поставщиков сетевых услуг или подразделений предприятия. Становится возможной централизованное управление пропускной способностью сети компьютеров, работающих под управлением ОС Windows Vista или Windows Server «Longhorn» независимо от приложения и в масштабах всей инфраструктуры службы Active Directory®. Поскольку управление трафиком происходит ниже уровня приложения, изменять существующие приложения для управления трафиком с помощью службы QoS на основе политик не требуется.
Параметры службы QoS на основе политик в ОС Windows Server «Longhorn» и Windows Vista позволяют задавать приоритеты и управлять скоростью отправки данных для исходящего трафика с учетом следующих условий:
  • отправляющее приложение (путь и имя исполняемого модуля);
  • исходные и конечные адреса или префиксы адресов IPv4 или IPv6;
  • протокол (TCP, UDP или оба);
  • исходные и конечные порты или диапазоны портов (TCP или UDP).
Политики службы QoS применяются к сеансу входа пользователя или компьютеру как часть объекта групповой политики, который связан с таким контейнером службы Active Directory, как домен, веб-узел или организационная единица, либо могут применяться к группе безопасности. Как часть групповой политики службы QoS базируются на существующей инфраструктуре управления службой Active Directory.
С помощью службы QoS на основе политик можно определить приоритет трафика. В политике службы QoS может быть настроена маркировка исходящего трафика адресов IPv4 или IPv6 определенным значением поля DSCP. Можно также управлять использованием пропускной способности сети для исходящего трафика. В политике службы QoS можно задать ограничение скорости для исходящего трафика. С помощью этой настройки компоненты службы QoS ограничивают скорость составного исходящего сетевого трафика заданным значением. На компьютерах можно управлять использованием пропускной способности для входящего трафика. Для этого имеются дополнительные параметры входящей пропускной способности для трафика по протоколу TCP, задающие максимальный размер окна приема.
На компьютерах с ОС Windows Vista and Windows Server «Longhorn» планировщик пакетов QoS по умолчанию установлен и включен. Компонент Pacer.sys £ это новый облегченный драйвер фильтров NDIS (Network Device Interface Specification) версии 6.0, который управляет планированием пакетов для службы QoS на основе политик и для трафика приложений, поддерживающих службу QoS. Компонент Pacer.sys заменяет планировщик пакетов Psched.sys, используемый в ОС Windows XP и Windows Server 2003.
Чтобы развернуть службу QoS на основе политик в интрасети, настройте политики службы QoS на основе пользователей или компьютеров и примените их к необходимому контейнеру службы Active Directory. Компьютеры, работающие под управлением ОС Windows Vista или Windows Server «Longhorn», загружают и применяют параметры службы QoS на основе политик при обновлении групповой политики конфигурации пользователя или конфигурации компьютера.
Поскольку сети становятся все более и более общедоступными для приложений, обрабатывающих данные и аудио/видео (AV) потоки, решение для службы QoS позволит сделать AV-трафик, для которого недопустимы задержки, приоритетным относительно трафика данных. Кроме того, сети становятся все более и более беспроводными, что вносит дополнительные осложнения для приложений, чувствительных к задержкам и загрузке сети.
Интерфейс qWAVE в ОС Windows Vista обеспечивает совокупность программных модулей службы QoS, которые решают сетевые проблемы, связанные с AV-приложениями и беспроводными сетями. Интерфейс qWAVE интегрирован в подсистему службы QoS и работает с несколькими технологиями задания приоритета пакетов на уровне Интернета и сетевого интерфейса. Интерфейс qWAVE поддерживает одновременно несколько AV-потоков (потоки реального времени, требующие использования службы QoS) и потоков данных (потоки «наибольшего усилия», такие как электронная почта и передача файлов).
Совокупность технологий qWAVE помогает выявлять и наблюдать за пропускной способностью локальной сети, определять наличие поддержки службы QoS сетью и управлять распределенным допуском для сбалансированного и согласованного использования пропускной способности сети. Эти технологии, в которых реализованы расширенные методики управления AV-потоками, позволяющие приложениям динамически адаптироваться к изменению сетевых условий, доступны только через прикладной интерфейс службы QoS2.
Прикладной интерфейс службы QoS2, который в ОС Windows Vista и Windows Server «Longhorn» введен вместо интерфейса GQoS и параметра Winsock IP_TOS, значительно проще в использовании, чем прикладной интерфейс службы GQoS.

Дополнительные сведения
На веб-странице TechNet есть множество превосходных материалов о службе QoS. Начните с веб-страницы веб-узла службы Microsoft Quality of Service. Просмотрите также раздел службы QoS блога Windows Core Networking (на английском языке).

Джозеф Дэвис (Joseph Davies) работает техническим писателем в корпорации Майкрософт. С 1992 года занимается преподаванием и пишет о сетях ОС Windows. Джозеф Дэвис написал пять книг, опубликованных издательством Microsoft Press®, и ведет ежемесячную рубрику TechNet Cable Guy (на английском языке).


 Windows PowerShell: Поэтапное создание сценариев
Windows PowerShell
Поэтапное создание сценариев
Дон Джонс (Don Jones)

В предыдущих статьях я особое внимание обращал на то, что Windows PowerShell £ это оболочка. Она создана для интерактивного использования, в отличие от оболочки cmd.exe (или командной строки), с которой вы, возможно, уже знакомы. Но тем не менее Windows PowerShell поддерживает язык сценариев £ более функциональный, чем пакетный язык cmd.exe. В то же время
он предоставляет такие же, если не большие, возможности, что и языки, сходные с VBScript. Благодаря тому что Windows PowerShell™ является оболочкой интерактивной, изучение языка сценариев значительно упрощается. Сценарии можно разрабатывать в интерактивном режиме внутри оболочки, что позволяет писать их поэтапно £ строку за строкой £ и сразу видеть результаты работы.
Подобная техника создания сценариев также упрощает отладку. Поскольку результаты работы сценария видны сразу, его можно быстро исправить, если что-то пошло не так.
В этой статье я приведу пример интерактивного создания сценария в Windows PowerShell. Мы напишем сценарий, считывающий имена служб из текстового файла и устанавливающий для каждой службы режим запуска «Отключено».
На этом примере мне хотелось бы показать, что сценарий в Windows PowerShell можно создавать небольшими частями вместо того чтобы пытаться сразу написать его целиком. Любую административную задачу можно разбить на несколько составляющих и найти отдельное, независимое решение для каждой составляющей. Вы увидите, что Windows PowerShell позволяет без труда объединить эти сценарии в один. Я также намерен показать вам, что таким способом £ создавая сценарий по частям £ удобнее разрабатывать конечный сценарий.

Считывание имен из файла
Понять, как считывать данные из текстового файла в Windows PowerShell, непросто. Если запустить команду Help *file*, мы получим только справку по командлету Out-File, а он записывает текст в файл, а не считывает его. В справке по этой теме вообще ничего нет. Однако имена командлетов в Windows PowerShell следуют определенным правилам, и это можно взять на вооружение. Если в Windows PowerShell какие-то данные откуда-то считываются, имя командлета обычно начинается с Get. Запустим команду Help Get*, чтобы просмотреть список всех подобных командлетов. В нем мы видим имя Get-Content. Кажется, это то, что нам надо. Теперь запустим команду Help Get-Content и узнаем, для чего предназначен этот командлет (см. рис. 1). Похоже, мы можем использовать его для выполнения поставленной задачи.
Рис. 1. Запуск команды Help Get-Content для получения дополнительной информации
Рис. 1. Запуск команды Help Get-Content для получения дополнительной информации (Щелкните изображение, чтобы уменьшить его)
Рис. 1. Запуск команды Help Get-Content для получения дополнительной информации
Рис. 1. Запуск команды Help Get-Content для получения дополнительной информации (Щелкните изображение, чтобы увеличить его)
Оболочка Windows PowerShell практически любой элемент обрабатывает как объект, и текстовые файлы не являются исключением. С технической точки зрения, текстовый файл £ это набор строк; каждая строка представляет собой что-то вроде независимого объекта. То есть, если создать текстовый файл C:\services.txt и записать в него имена служб (каждое имя располагается на отдельной строке), в Windows PowerShell можно будет считывать имена служб по одному при помощи командлета Get-Content. Поскольку цель данного примера £ показать, что сценарии можно писать интерактивно, начнем с того, что просто запустим командлет Get-Content, указав имя созданного текстового файла, и посмотрим, что получится в результате.
PS C:\> get-content c:\services.txt
messenger
alerter
PS C:\>
Как и ожидалось, оболочка Windows PowerShell считывает записанные в файле имена и выводит их на экран. Разумеется, просто вывести имена на экран для решения поставленной задачи недостаточно, но зато теперь мы уверены в том, что командлет Get-Content работает так, как мы предполагали.

Изменение службы
Теперь нужно изменить режим запуска службы. Опять же, начнем с того, что найдем нужный командлет. Запускаем команду Help *Service*. Получаем довольно небольшой список. Из всех содержащихся в нем командлетов только Set-Service, похоже, нам подходит. Протестируем его, чтобы понять, как этот командлет работает, прежде чем включать его в сценарий. Запустив команду Help Set-Service, узнаем, как должен работать командлет, и небольшой тест подтверждает полученную информацию.
PS C:\> set-service messenger -startuptype
    disabled
PS C:\>

Объединение частей
Теперь нужно свести воедино способность считывать имена служб из файла и работу командлета Set-Service £ тут в дело вступает конвейерная обработка, применяемая в Windows PowerShell. Она позволяет использовать данные, полученные в результате работы одного командлета, в качестве входных данных для другого. По конвейеру передаются объекты целиком. Если на конвейер поступает набор объектов, каждый из них проходит конвейерную обработку независимо от остальных объектов. Это означает, что данные, полученные в результате работы командлета Get-Content £ они, как мы помним, представляют собой набор объектов £ могут быть поданы на вход командлета Set-Service. Поскольку командлет Get-Content передает набор объектов, каждый объект £ строка текста £ поступает на вход командлета Set-Service независимо от остальных. В результате командлет Set-Service выполняется для каждой строки нашего текстового файла. Команда выглядит следующим образом.
PS C:\> get-content c:\services.txt |
 set-service -startuptype disabled
PS C:\>
При выполнении команды происходит следующее:
  1. Выполняется командлет Get-Content, считываются все данные из файла. Каждая строка файла воспринимается как отдельный объект, а все строки вместе представляют собой набор объектов.
  2. Этот набор объектов передается командлету Set-Service.
  3. Конвейер запускает командлет Set-Service для каждого объекта, поступившего на вход. При каждом запуске командлета Set-Service объект, поступивший на вход, используется в качестве первого параметра командлета, то есть имени службы.
  4. Выполняется командлет Set-Service. В качестве первого параметра в нем используется объект, поступивший на вход, а также учитываются все остальные указанные параметры £ в данном случае это параметр startuptype.
Надо отметить, что поставленная задача выполнена, хотя полноценный сценарий так и не написан. Сделать то же самое в оболочке Cmd.exe было бы непросто, а код на языке VBScript содержал бы десяток строк. В оболочке же Windows PowerShell для решения этой задачи требуется всего лишь одна строка. Работа, конечно, еще не закончена. Если вы обратили внимание, при выполнении созданной команды мы не получаем никакого отчета о состоянии выполнения задачи. Трудно понять, было ли вообще что-то сделано £ мы только видим, что ошибок не возникло. Но теперь, изучив необходимые функции, мы можем обратить внимание на внешнюю сторону процесса и перейти собственно к созданию сценария.
Windows PowerShell Prompt Here от Майкла Мерголо
Один из популярных инструментов Microsoft® PowerToys для Windows® (и один из моих любимых) £ средство Open Command Window Here. Оно входит в набор инструментов Microsoft PowerToys для Windows XP и в набор Windows Server® 2003 Resource Kit Tools. Если оно установлено, можно, щелкнув правой кнопкой мыши папку или диск в проводнике Windows, открыть окно команд, причем данная папка или диск оказываются текущими.
Пока я изучал Windows PowerShell, мне пришло в голову, что хорошо бы иметь подобную функцию и для этой оболочки. Я взял файл INF из программы установки Open Command Window Here (из набора Windows Server 2003 Resource Kit Tools) £ cmdhere.inf £ и изменил его. В результате получилось контекстное меню Windows PowerShell Prompt Here. Файл INF для него можно найти в соответствующей записи в блоге, на основании которой и был написан материал для этой врезки (ее адрес: leeholmes.com/blog/PowerShellPromptHerePowerToy.aspx). Чтобы установить средство, щелкните правой кнопкой мыши файл INF и выберите «Установить».
Когда я создавал версию этого средства для Windows PowerShell, я обнаружил, что в исходном файле есть ошибка: при удалении средства Open Command Window Here в контекстном меню остается неработающий пункт. Я исправил исходный файл cmdhere.inf, его обновленную версию можно найти в той же записи в блоге.
Преимуществом для обоих упомянутых средств PowerToys является то, что эти пункты меню настраиваются в разделах реестра, связанных с типами объектов Directory и Drive. Выполняется настройка так же, как и настройка пунктов контекстного меню для типов файлов. Например, если щелкнуть правой кнопкой мыши файл TXT в проводнике Windows, в контекстном меню, в самом верху, вы увидите несколько пунктов: «Открыть», «Печать», «Изменить». Чтобы понять, как настраиваются эти пункты меню, взглянем на куст реестра HKEY_CLASSES_ROOT.
Откройте редактор реестра и раскройте куст HKEY_CLASSES_ROOT. В нем содержатся разделы с именами, соответствующими типам файлов, например DOC, TXT и т. п. Щелкните раздел .txt. В нем в качестве значения по умолчанию указано txtfile (см. рис. A). Это тип объекта, связанный с файлом TXT. Прокрутите список разделов и раскройте раздел txtfile, в нем раскройте раздел shell £ имена разделов в нем частично совпадают с названиями пунктов контекстного меню для файлов TXT. (Некоторых пунктов меню в этом списке нет, поскольку существуют и другие способы создания контекстных меню.) В каждом из разделов есть раздел command. Указанное в нем значение по умолчанию £ это команда, которую Windows выполняет при выборе соответствующего пункта в контекстном меню.
Точно таким же образом в средствах вызова командной строки и Windows PowerShell настраиваются пункты контекстного меню Open Command Window Here и Windows PowerShell Prompt Here. С дисками и каталогами типы файлов не связаны, но для данных объектов в кусте реестра HKEY_CLASSES_ROOT есть соответствующие разделы Drive и Directory.
Рис. A. Пункты контекстного меню настраиваются в реестре
Рис. A. Пункты контекстного меню настраиваются в реестре (Щелкните изображение, чтобы уменьшить его)
Рис. A. Пункты контекстного меню настраиваются в реестре
Рис. A. Пункты контекстного меню настраиваются в реестре (Щелкните изображение, чтобы увеличить его)

Майкл Мерголо (Michael Murgolo) £ старший консультант по инфраструктуре в консалтинговой службе корпорации Майкрософт. Он специализируется на операционных системах, развертывании, сетевых службах, Active Directory, управлении системами, автоматизации и управлении обновлениями.

Интерактивное создание сценариев
Нам нужно, чтобы для каждой службы, указанной в файле C:\services.txt, выполнялось несколько командлетов. При этом будет выводиться имя службы и прочая информация, что позволит нам отслеживать ход выполнения сценария.
Прежде объекты передавались от одного командлета к другому при помощи конвейерной обработки. Но на этот раз будет использован способ, более напоминающий обычный сценарий £ конструкция Foreach (я рассказывал о ней в предыдущем выпуске журнала). Конструкция Foreach может применяться к набору объектов. Для каждого объекта в наборе выполняется несколько командлетов. В конструкции назначается переменная, которой присваивается значение текущего объекта при каждом повторении цикла. К примеру, конструкция может начинаться так.
foreach ($service in get-content c:\services.txt)
Для считывания данных из текстового файла мы используем все тот же командлет Get-Content. При помощи конструкции Foreach мы обходим весь набор объектов, полученный в результате работы командлета Get-Content. Цикл выполняется один раз для каждого объекта, причем текущий объект помещается в переменную $service. Осталось только указать код, который должен выполняться в цикле. Для начала попробуем просто продублировать составленную нами команду, состоящую из одной строки (так мы создадим самый простой сценарий и убедимся, что он действует точно так же как и предыдущая наша команда).
PS C:\> foreach ($service in get-content c:\services.txt) {
>> set-service $service -startuptype disabled
>> }
>>
PS C:\>
Здесь мы видим кое-что необычное. Обратите внимание: первая строка конструкции Foreach заканчивается открывающей фигурной скобкой. Все, что пишется в фигурных скобках, считается телом цикла и выполняется один раз для каждого объекта из набора на входе. После того как мы ввели открывающую скобку и нажали клавишу ВВОД, оболочка Windows PowerShell изменила строку приглашения на >> (см. рис. 2). Это означает, что мы начали вводить некую конструкцию и оболочка ожидает ее завершения. Затем мы ввели командлет Set-Service. Теперь в качестве первого параметра мы использовали переменную $service, поскольку ей присваивается текущее имя службы, считанное из текстового файла. В следующей строке мы ввели закрывающую фигурную скобку, завершив тем самым конструкцию. После того как мы нажали клавишу ВВОД дважды, оболочка Windows PowerShell выполнила код.
Рис. 2. Оболочка Windows PowerShell показывает, что начата конструкция
Рис. 2. Оболочка Windows PowerShell показывает, что начата конструкция (Щелкните изображение, чтобы уменьшить его)
Рис. 2. Оболочка Windows PowerShell показывает, что начата конструкция
Рис. 2. Оболочка Windows PowerShell показывает, что начата конструкция (Щелкните изображение, чтобы увеличить его)
Код на самом деле выполняется сразу же. Введенный код похож на сценарий, но в действительности Windows PowerShell работает с ним «вживую», ни в каком текстовом файле код не сохраняется. Теперь введем все то же самое еще раз, но добавим строку кода, выводящую имя текущей службы на экран.
PS C:\> foreach ($service in get-content c:\services.txt) {
>> set-service $service -startuptype disabled
>> "Disabling $service"
>> }
>>
Disabling messenger
Disabling alerter
PS C:\>
Обратите внимание: то, что нужно вывести на экран, заключено в двойные кавычки. Кавычки в Windows PowerShell указывают на то, что определенная часть кода является строкой текста, а не еще одной командой. Когда используются именно двойные, а не одинарные кавычки, Windows PowerShell проверяет заключенную в них строку текста на предмет наличия в ней переменных. Если переменная обнаруживается, вместо нее подставляется фактическое значение, поэтому при выполнении кода на экран выводится имя текущей службы.
Но и этот код еще не является сценарием.
До сих пор оболочка Windows PowerShell использовалась интерактивно £ это отличный способ проверить результаты нашей работы. Однако в определенный момент набирать все строки кода заново надоедает. Именно поэтому Windows PowerShell также может выполнять сценарии. В действительности, оболочка обращается со сценарием как с самым обыкновенным текстом: она, грубо говоря, просто считывает текст из файла сценария и построчно его «вводит» £ точно так же, как если бы мы вводили строки кода вручную. Из этого следует, что все, что мы уже написали, можно вставить в файл сценария. Создадим в «Блокноте» файл сценария disableservices.ps1 и вставим в него следующие строки.
foreach ($service in get-content c:\services.txt) {
 set-service $service -startuptype disabled
 "Disabling $service"
 }
Сохраним файл в папке C:\test. Теперь попробуем запустить его в Windows PowerShell.
PS C:\test> disableservices
'disableservices' is not recognized as a cmdlet, function, operable program, or
<script file.
At line:1 char:15
+ disableservices <<<<
PS C:\test>
Так. В чем ошибка? В оболочке Windows PowerShell мы находимся в папке C:\test, но сценарий в ней оболочка не обнаруживает. Почему? Из-за ограничений системы безопасности Windows PowerShell не выполняет сценарии непосредственно из текущей папки: это сделано для того, чтобы предотвратить возможность подмены команд операционной системы. Скажем, нельзя создать сценарий dir.ps1 и заставить оболочку выполнять его вместо стандартной команды dir. Чтобы запустить сценарий из текущей папки, нужно указать относительный путь.
PS C:\test> ./disableservices
The file C:\test\disableservices.ps1 cannot be loaded.
The execution of scripts is disabled on this system.
Please see "get-help about_signing" for more details.
At line:1 char:17
+ ./disableservices <<<<
PS C:\test>
Что дальше? Сценарий по-прежнему не запускается. Путь указан правильно, однако Windows PowerShell выдает сообщение о том, что сценарии в ней не могут выполняться. Дело в том, что по умолчанию выполнение сценариев в Windows PowerShell отключено. Это еще одна мера системы безопасности, предупреждающая возникновение проблем, с которыми многие из нас сталкивались при использовании VBScript. Вредоносные сценарии не могут запускаться в оболочке Windows PowerShell, потому что по умолчанию сценарии в ней вообще не могут запускаться. Чтобы запустить сценарий, нужно в явном виде изменить политику выполнения.
PS C:\test> set-executionpolicy remotesigned
Политика выполнения RemoteSigned позволяет запускать сценарии с локального компьютера без подписи £ для запуска загружаемых сценариев подпись требуется. Лучше использовать политику AllSigned, которая позволяет запускать только сценарии, подписанные с использованием сертификата, выданного доверенным издателем, но у нас под рукой нет сертификата, а без него невозможно подписать сценарий, поэтому в данной ситуации правильнее всего выбрать политику RemoteSigned. Теперь еще раз попробуем запустить сценарий.
PS C:\test> ./disableservices
Disabling messenger
Disabling alerter
PS C:\test>
Нужно отметить, что политика выполнения RemoteSigned £ хороший, но не превосходный выбор. Есть более удачное решение. С точки зрения безопасности было бы лучше получить сертификат для подписи сценариев, подписать созданный сценарий в оболочке Windows PowerShell при помощи командлета Set-AuthenticodeSignature и установить политику выполнения AllSigned, являющуюся гораздо более надежной.
Существует еще одна политика выполнения £ Unrestricted £ использования которой следует избегать. Эта политика позволяет беспрепятственно выполнять на компьютере любые сценарии, даже вредоносные сценарии, запускаемые удаленно, что подвергает большому риску безопасность вашей системы, поэтому я рекомендую не использовать политику Unrestricted ни при каких обстоятельствах.

Незамедлительная проверка результатов
Возможность интерактивного создания сценариев в Windows PowerShell позволяет быстро создавать прототипы сценариев и даже просто их небольшие составляющие. Результаты работы можно сразу же проверить, благодаря чему вы можете легко оптимизировать сценарий так, чтобы получить именно тот результат, который вам нужен. Завершив оптимизацию, вы можете перенести код в файл PS1 и сохранить его для удобства использования в будущем. И помните: лучше всего подписывать файлы PS1, чтобы можно было установить политику выполнения AllSigned в оболочке Windows PowerShell £ наиболее безопасную политику выполнения сценариев.

Дон Джонс (Don Jones) £ ведущий программист SAPIEN Technologies, соавтор книги Windows PowerShell: TFM (см. www.SAPIENPress.com). Ему можно написать по адресу don@sapien.com.


 Эй, программист!: XML и охота на автомобиль
Эй, программист!
XML и охота на автомобиль
Сотрудники группы Microsoft Scripting Guys
Загрузить исходный код для этой статьи: HeyScriptingGuy2007_02.exe (150KB)

«Я НЕ ЗНАЮ, зачем мой пес гоняется за автомобилями, £ говорится в старом анекдоте. £ Посудите сами, ну если он один из них поймает, что он делать-то с ним будет?»
Отличный вопрос. Ни один из Scripting Guys ответить на него не может. Ну разве что это про Люси, ту собаку в конце улицы... Мы совершенно уверены, что если Люси отловит автомобиль, она устроит ограбление в винном магазине, а потом на пойманной машине скроется с места преступления. И судя по тому, что она сотворила с газоном перед домом, мы готовы биться об заклад, она не скоро остановится передохнуть. Если вы, конечно, понимаете, о чем речь.
Попроси нас кто-нибудь адаптировать этот бородатый анекдотец к условиям современной эпохи высоких технологий, получилось бы что-то вроде этого: «Я понятия не имею, зачем мой сисадмин пытается выучить язык XML. Посудите сами, ну если даже она его выучит, что делать-то с ним будет?»
Заметим в свое оправдание: мы всего лишь пытались перекроить старую шутку на новый лад, мы не обещали сделать ее смешной.
Откровенно говоря, XML в каком-то смысле слишком уж превозносят, особенно если речь идет о системном администрировании. На самом-то деле многие администраторы жили долго и счастливо, хотя и не написали ни единого сценария, работающего с файлом XML. Не думаем, что в ближайшем будущем что-то изменится.
Но также верно и то, что в приложениях все чаще используется стандарт XML для хранения данных. Собственно, почему бы и нет? Ведь файлы данных XML £ это не что иное как разукрашенные текстовые файлы. Их легко создавать, их можно переносить с одной платформы на другую, и они не требуют сложных программ для работы с базами данных (не говоря уже о том, что никаких программ не надо покупать). Есть операционная система и текстовый редактор? Можете создавать базу данных XML.
Из этого следует, что есть по крайней мере одно дело, к которому системный администратор может приспособить XML: он может писать сценарии, в которых выполняется обращение к файлу XML так, как будто он является полноценной базой данных. И скажите, кто как не Scripting Guys сможет подсказать вам, как это сделать?
Вопрос, конечно, справедливый, но если бы нам и впрямь его задали, мы готовы были бы поспорить, что Люси слишком увлечена раскапыванием чьей-то клумбы, чтобы писать статьи про XML.
Для начала взглянем на простенький файл XML (см. рис. 1), файл базы данных с четырьмя сценариями, которые можно найти в ежедневно обновляемой колонке Hey, Scripting Guy! (на английском языке).
Figure 1 Эй, программист! Сценарии в файле XML (Close Figure 1)
<?xml version="1.0" encoding="ISO-8859-1"?>
<Repository>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Access</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Print a Microsoft Access Report?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1020.mspx</URL>
  </Script>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Access</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Compact a Microsoft Access Database?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1009.mspx</URL>
  </Script>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Word</Subcategory>
    <Keyword>hyperlinks</Keyword>
    <Title>How Can I Change an Existing Hyperlink in a Microsoft Word Document?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1016.mspx</URL>
  </Script>
  <Script>
    <Category>Enterprise Servers</Category>
    <Subcategory>Microsoft SQL Server</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Create a Table in a SQL Server Database?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1016.mspx</URL>
  </Script>
</Repository>
Смотрите, это совсем простой файл. Каждый сценарий в нем выделен тегом <Script>. Дальше в статье каждый из этих сценариев мы будем называть записью. Конечно, вы правы, ни один поклонник XML никогда бы так делать не стал. Но это не важно. Наша цель £ рассказать, как применить имеющиеся знания (навыки составления запросов для баз данных) к новому, качественно отличному источнику данных. Мы решили сначала остановиться на том, как сделать то, что нам нужно. Может, когда-нибудь мы вернемся к этой теме и расскажем о том, как все это правильно называется.
Ну ладно, вернемся к записям. В каждой записи есть следующие поля: <Category>, <Subcategory>, <Keyword>, <Title> и <URL>.
Странно, а мы думали, это произведет на вас большее впечатление. Тогда давайте приведем сценарий, который открывает наш файл XML и выводит его содержимое.
Set xmlDoc = CreateObject("Microsoft.XMLDOM")
xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Scripts.xml")

Set colNodes = xmlDoc.selectNodes _
("/Repository/Script/*")

For Each objNode in colNodes
   Wscript.Echo objNode.Text
Next
Обратите внимание, что имена тегов чувствительны к регистру. Нужно писать «/Repository/Script», а не «/repository/script» и не «/REPOSITORY/SCRIPT».
Разумеется, и сценарий не особо вас впечатлил. Но в том-то все и дело: выполнить поставленную задачу не так сложно, как может показаться вначале.
Как видно из кода, мы сначала создаем экземпляр объекта Microsoft.XMLDOM, COM-объект, используемый для работы с файлами XML. После этого мы устанавливаем для параметра Async значение False: тем самым мы гарантируем, что файл будет считан в память полностью, прежде чем выполнение сценария будет продолжено. Затем при помощи метода Load мы считываем файл C:\Scripts\Scripts.xml.
xmlDoc.Load("C:\Scripts\Scripts.xml")
После того как файл загружен в память, можно использовать метод selectNodes для выбора определенных записей в базе данных.
Set colNodes = xmlDoc.selectNodes _
("/Repository/Script/*")
Обратите внимание на параметр, который передается методу selectNodes. Он представляет собой путь в файле XML. Наш файл XML имеет следующую структуру.
<Repository>
    <Script>
        <Category></Category>
        <Subcategory></Subcategory>
        <Keyword></Keyword>
        <Title></Title>
        <URL></URL>
    </Script>
</Repository>
Нужно ли об этом помнить? Да, нужно. При работе с файлами XML структура очень важна. Скажем, как получить отдельные свойства записи? Это просто. Мы переходим к тегу <Repository>, за которым идет тег <Script>. А после него находим теги отдельных свойств. Заметили? Это как раз тот путь, который указан в параметре, который передается методу selectNodes. После пути стоят косая черта и звездочка (/*). Это означает, что нужно выбрать все свойства данной записи. Другими словами, возвращаются все свойства всех записей в базе данных £ подобным образом действует запрос «Select * From» в инструментарии управления Windows® (Windows® Management Instrumentation, WMI).
Примечание. Попробуйте запустить сценарий, приведенный в качестве образца, и сразу станет ясно, что именно мы имеем в виду.
Остальная часть сценария понятна. Создается цикл For Each, при выполнении которого обходятся все записи и выводятся значения свойства Text для каждой записи и для каждого свойства.
For Each objNode in colNodes
   Wscript.Echo objNode.Text
Next
Это проще, чем гоняться за машинами.
Конечно, если бы нам нужно было только лишь вывести все содержимое файла, мы могли бы обойтись без XML и использовать FileSystemObject. (Может, это было бы чуть сложнее, но ненамного.) А вот если мы собирались удивить вас и убедить в том, что XML £ штука и впрямь удобная, пожалуй, наша цель еще не достигнута.
Посмотрим, что еще можно сделать. В первом сценарии мы получали на выходе все значения свойств для всех записей. Замечательно. А если нам надо получить только заголовок сценария? Мы сможем это сделать? Ммм... секундочку...
Да, Люси говорит, что для этого нужно всего лишь изменить команду selectNodes £ добавить в конце пути интересующее нас свойство. Другими словами, нужно написать так.
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/Title")
Как выясняется, в первом случае мы получали все свойства только потому, что использовали подстановочный знак (*). А теперь мы получаем только значение свойства Title. Почему? Потому что мы сами указали, что выдавать нужно значения только этого свойства.
Примечание. Посмотрите-ка, XML дает нам в точности то, что мы просим. Люси, ты уж не обижайся, но кажется, лучший друг человека £ это XML!
Разумеется, можно получать и значения нескольких свойств. Например, если изменить команду следующим образом, она будет возвращать значения Title и URL.
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/(Title | URL)")
Синтаксис может показаться неуклюжим, но как только вы привыкните к нему, то согласитесь, что он не так уж плох. Сначала в команде указывается родительская часть пути £ точно так же, как мы делали до этого.
    /Repository/Script/
Затем добавляется пара скобок, в которых указываются свойства, значения которых должны возвращаться. (Обратите внимание, что между отдельными свойствами ставится вертикальная черта.) То есть, надо написать следующее.
    (Title | URL)
Как мы и предупреждали, это выглядит нелепо, но зато работает.
И кстати, число возвращаемых свойств двумя не ограничивается. Вы можете добавлять свойства, разделяя их вертикальной чертой, сколько вам заблагорассудится. Например, следующая команда возвращает три значения (Title, URL и Keyword).
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/(Title | URL |          Keyword)")
Здорово, правда?
Так мы заранее знали, что это здорово, но вы-то нам не верили. Да, вы снова правы. До сих пор мы извлекали информацию только обо всех записях в базе данных сразу. На самом-то деле ничего страшного в этом нет. Именно этим зачастую и приходится заниматься. Но с другой стороны, иногда (и даже часто) нужно извлечь информацию о подмножестве записей. Допустим, требуется получить информацию только о сценариях, в поле Keyword которых стоит databases. Выполняется такая задача при помощи следующего сценария.
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’]")
Синтаксис и здесь выглядит немного странным. Но если разобраться, он на самом деле прост и четок. После родительского пути в квадратных скобках указывается часть, задающая условие отбора (например «x равно y») £ она эквивалентна разделу Where.
/Repository/Script [Keyword = ‘databases’]
Как легко догадаться, указанное условие означает: «Возвращать только записи, в которых атрибут Keyword имеет значение databases». Обратите внимание, что слово databases заключено в одинарные кавычки. Они там не для красоты £ это требование синтаксиса. Если заключить слово, задающее условие отбора, в двойные кавычки, при попытке запустить сценарий появится сообщение о синтаксической ошибке.
Примечание. Почему? Помните, что вся строка запроса £ "/Repository/Script [Keyword = ‘databases’]" £ заключена в двойные кавычки?
При фильтрации данных можно использовать не только знак равенства (=). В условии отбора может стоять знак больше (>) или меньше (<), а также всеми любимые меньше или равно (<=) и больше или равно (>=). Также можно использовать отрицание £ поставить восклицательный знак перед любым из перечисленных знаков. Например, следующая команда запрашивает все сценарии, в которых значение элемента Keyword не равно databases (обратите внимание на знак !=).
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword != ‘databases’]")
Так, минуточку. Это кто там говорит, что нельзя одновременно устанавливать фильтр и выбирать свойства, которые должны возвращаться? Неправда, можно.
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’]/Title")
Если все сделано правильно, при помощи такой команды возвращается только свойство Title для всех записей, элемент Keyword которых имеет значение databases. Давайте проверим, работает ли наш сценарий.
    How Can I Print a Microsoft Access Report?
    How Can I Compact a Microsoft Access Database?
    How Can I Create a Table in a SQL Server     Database?
Теперь посмотрим, можно ли добавить еще одну команду £ и с чистым сердцем пойдем на перекур. Мы уже многому научились, и все же сценарий по-прежнему выдает больше записей, чем нужно. Предыдущая команда возвращает как сценарии Microsoft® Access®, так и сценарии Microsoft SQL Server™. (Почему? Потому что в каждом из них элемент Keyword имеет значение databases.) А если нужно получить только сценарии, в которых элемент Keyword имеет значение databases, а элемент Subcategory £ значение Microsoft SQL Server? Можно ли отбирать записи по нескольким критериям?
Например, так.
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’ and " & _
    "Subcategory = ‘Microsoft SQL Server’]")
Тут использован все тот же базовый синтаксис, только введено два отдельных критерия (а именно, Keyword = ‘databases’ и Subcategory = ‘Microsoft SQL Server’), связанные оператором AND.
Примечание. Да, верно. У нас файл XML совсем маленький, и можно было просто запросить все сценарии, в которых элемент Subcategory имеет значение Microsoft SQL Server. Но это не так интересно и совсем не так поучительно.
Также можно использовать оператор OR. Допустим, есть большой набор сценариев Microsoft Office, в которых элемент Subcategory имеет значение Microsoft Excel®, Microsoft PowerPoint®, Microsoft Outlook® и т. д. Можно ли получать на выходе только сценарии, относящиеся к подкатегориям Microsoft Word и Microsoft Access? Абсолютно точно можно.
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Subcategory = ‘Microsoft Word’ " & _
    "or Subcategory = ‘Microsoft Access’]")
Ну что, совсем другое дело? Вряд ли эта статья в корне изменила всю вашу жизнь, но есть шанс, что рано или поздно станет весьма удобно использовать подобные запросы к файлам XML. Решать вам. Можно изучить некоторые основные приемы работы с XML, а можно и дальше гоняться за автомобилями. Все зависит только от вас. (Если вы выберете второй вариант и встретите Люси, ту псину, живущую в конце улицы, передавайте ей привет от Scripting Guys. И попросите ее держаться подальше от нашего двора!)
Эй, программист! £ ежедневные выпуски
Вы только что изучили статью из раздела «Эй, программист!», вышедшую в этом месяце. Вы считаете ее лучшей технической статьей из всех, что вы когда-либо читали. А может быть, вы вообще считаете ее лучшим из того, что когда-либо было написано. Вы часами простаиваете у почтового ящика в ожидании следующего выпуска журнала TechNet, потому что вам не терпится прочесть еще одну такую же статью.
Так чего же вы ждете? Вы хотите узнать еще что-нибудь про соседскую собаку Люси? Почитать про новые подвиги Scripting Son? А вы знаете, как прошел Turducken Bowl в прошлом году? Все это вы найдете в ежедневных £ да, вы не ослышались, ежедневных £ выпусках статей «Эй, программист!». С понедельника по пятницу (за исключением государственных праздников и выходных у Scripting Guys) вы сможете получать самую подробную информацию о студенческих бейсбольных, футбольных и баскетбольных матчах. Вам может встретиться даже местный прогноз погоды. (Ну да, он будет местным только если вы живете в Редмонде, но покажите мне человека, которому неинтересно, что в Редмонде творится с погодой?)
А кроме того, каждый день вы будете узнавать что-то новое о программировании. В этих увлекательных текстах на самом деле есть информация о том, как писать сценарии. В каждой статье Scripting Guys отвечают на реальные вопросы, присланные им реальными, как они надеются, людьми. Ежедневные выпуски статей можно прочесть на веб-узле microsoft.com/technet/scriptcenter/resources/qanda. Scripting Guys уже ответили на сотни вопросов, и скопился довольно большой архив £ кладезь ценной информации по написанию сценариев (microsoft.com/technet/scriptcenter/resources/qanda/hsgarch.mspx).
У вас появился вопрос к Scripting Guys? Если вы отправите его по адресу scripter@microsoft.com, есть небольшой шанс получить ответ. (Если вопрос не отправить, шансов получить ответ нет вообще, так что вы ничем не рискуете. Здесь вероятность выигрыша побольше, чем в лотерее.)

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


 В поисках безопасности: Развертывание файловой системы EFS: Часть 1
В поисках безопасности
Развертывание файловой системы EFS: Часть 1
Джон Морелло (John Morello)

На сегодняшний день уже каждый слышал сообщения о том, как личные или конфиденциальные данные были утрачены из-за кражи или потери портативного компьютера. Портативные компьютеры пропадают постоянно. С ростом числа хищений личных данных и при более чем когда-либо высокой важности соблюдения нормативных требований тщательная защита данных на мобильных компьютерных системах крайне важна.
Одним из решений является использование файловой системы EFS (Encrypting File System £ шифрованная файловая система), включенной в систему Windows® начиная с версии Windows 2000 и обеспечивающей встроенное высокоэффективное шифрование диска. Система EFS тесно интегрирована с проводником Windows, так что конечные пользователи часто даже не знают, что используемый ими файл зашифрован. Кроме того, система EFS работает одинаково хорошо с собственными технологиями проверки подлинности и контроля доступа системы Windows, так что пользователям не нужно запоминать для доступа к своим данным отдельные пароли. И, наконец, система EFS обеспечивает удобные варианты восстановления данных в случае потери пользователем доступа к своим ключам шифрования (например в случае удаления или повреждения профиля пользователя либо в случае потери смарт-карты).
Для генерирования, хранения и развертывания ключей криптостойкого шифрования для защиты данных в системе EFS используется встроенная в систему Windows технология шифрования. В операционной системе Windows XP с пакетом обновления 1 (SP1) и в более поздних версиях операционной системы для шифрования данных на диске в файловой системе EFS используется алгоритм стандарта AES (Advanced Encryption Standard £ улучшенный стандарт шифрования) с 256-разрядным ключом. Эти симметричные ключи затем защищаются ассиметричной (RSA) парой ключей. В системе EFS каждый файл шифруется своим собственным ключом AES, затем этот ключ шифруется пользовательским ключом RSA и результат сохраняется в файл. Дополнительную информацию о шифровании файловой системы EFS см. в статьях, приведенных на боковой панели «EFS Resources» (Источники информации о файловой системе EFS). А пока уделим основное внимание не техническим основам системы EFS, а тому, как развернуть эту систему и сделать ее применимой в пользовательской среде. По этой причине отметим, что данная статьи предполагает наличие предварительных знаний концепций шифрования файловой системы EFS.

Примечание о безопасности системы EFS
Утверждается, что некоторые приложения способны взломать или раскрыть шифрование системы EFS. Ни одно из приложений фактически не может расшифровать зашифрованные с помощью алгоритма стандарта AES (или стандарта шифрования данных DES либо расширенного стандарта шифрования данных DESX) данные, а скорее может только получить доступ к закрытому ключу EFS пользователя путем грубого взлома пароля пользователя. В отношении шифрования системы EFS важно помнить, что используемые для генерирования и защиты зашифрованных данных закрытые ключи используют интерфейс DPAPI (Data Protection API £ прикладной программный интерфейс защиты данных). Интерфейс DPAPI использует для защиты данных производные от учетных данных пользователя, поэтому конечный результат защиты данных с помощью системы EFS будет настолько надежным, насколько надежен пароль пользователя. С появлением ОС Windows Vista™ стало возможным хранение сертификатов шифрования системы EFS на смарт-картах, что изменяет эту парадигму и значительно повышает относительную безопасность данных, защищенных файловой системой EFS.
Насколько длинным должен быть пароль, чтобы обладать устойчивостью к таким атакам? С учетом возможностей современных аппаратных средств и существующих сейчас алгоритмов атак на пароли рекомендуется использовать пароль (или точнее фразу-пароль), состоящий из 11 или более символов. Фраза-пароль из 11 или более символов является очень стойкой к самым передовым на сегодняшний день методам, включая атаки с использованием предварительно вычисленной хэш-функции (например атака Rainbow Table; дополнительную информацию см. в публикации «Why you shouldn't be using passwords of any kind on your Windows networks» (почему не нужно использовать пароли в некоторых сетях Windows) (на английском языке), ссылка на которую приведена на боковой панели «Resources» (Источники информации)).

Нужна или не нужна инфраструктура открытых ключей (PKI)?
Одним из наиболее распространенных неправильных представлений о системе EFS является мнение, что для ее работы требуется наличие инфраструктуры PKI (public key infrastructure £ инфраструктура открытых ключей). Хотя система EFS легко интегрируется с существующей в организации инфраструктурой PKI и использует ее преимущества, наличие инфраструктуры PKI отнюдь не является обязательным требованием. С другой стороны, решение о том, использовать инфраструктуру PKI в своем варианте развертывания системы EFS или нет, влияет на многие будущие решения, касающиеся развертывания, поэтому этот вопрос следует исследовать первым.
Главное преимущество использования с системой EFS инфраструктуры PKI заключается в возможности выполнять архивирование и восстановление ключей. Несмотря на то, что используемая отдельно система EFS позволяет администратору выполнять восстановление данных, автоматическое восстановление ключей возможно только при наличии инфраструктуры PKI, при этом в качестве центра сертификации (CA) должна использоваться операционная система Windows Server® 2003 Enterprise Edition. Восстановление данных £ это процесс, в ходе выполнения которого потерявший доступ к своему ключу шифрования пользователь может предоставить свои зашифрованные данные назначенному администратору, называемому агентом DRA (Data Recovery Agent £ агент восстановления данных), который может либо расшифровать эти данные и вернуть пользователю, либо повторно зашифровать их для использования с новым закрытым ключом. Агент DRA дублирует процесс шифрования пользователя, в результате чего все, что пользователь шифрует с использованием своего ключа, также шифруется с использованием копии ключа агента DRA. Таким образом, если ключ пользователя потерян, может вмешаться агент DRA, взять зашифрованные данные, применить к ним для расшифровки (или повторного шифрования) ключ агента DRA и затем вернуть данные пользователю. Подход с использованием агента DRA работает хорошо, но может быть сложен в управлении, если пользователь зашифровал большие объемы данных или если отсутствуют местные ИТ-специалисты, которые могут выступать в качестве агентов DRA.
Восстановление ключа, с другой стороны, требует создания центром сертификации копии шифровального ключа пользователя в процессе создания этого ключа, а затем безопасного хранения копии ключа в базе данных центра сертификации. Если пользователь вдруг потеряет доступ к зашифрованным файлам, администратору центра сертификации необходимо только войти в эту базу данных и извлечь ключ пользователя. В этот момент пользователь немедленно вновь получит доступ к своим данным, и необходимости в восстановлении данных агентом DRA не будет. При использовании такого способа восстановление ключа может быть более быстрым и эффективным. Однако обратите внимание на то, что в качестве резервного варианта на случай потери ключей всегда рекомендуется иметь агентов DRA, даже если используется восстановление ключей. Это также позволяет крупным организациям иметь распределенную систему восстановления, при которой ИТ-администраторы могут восстанавливать данные пользователей и при этом вообще не обращаться к группе администраторов инфраструктуры PKI.
Еще одним потенциальным преимуществом использования инфраструктуры PKI с системой EFS является упрощение совместного использования зашифрованных файлов. Вспомните, что использование системы EFS не ограничивается только портативными компьютерами; эта файловая система может быть столь же ценной в любой ситуации, когда физическая безопасность компьютера не может быть гарантирована. В таких ситуациях может возникнуть необходимость в доступе нескольких пользователей к одним и тем же зашифрованным данным. Хотя поддержка системой Windows совместного использования зашифрованных файлов несколько ограничена, потому что позволяет совместно использовать только отдельные файлы, а не каталоги, данная поддержка может быть полезным средством. Для облегчения совместного использования файлов системы EFS пользователь, который организует совместное использование файла, должен иметь доступ к открытым ключам других пользователей, получающих доступ к этому общему файлу (что проще всего реализовать, если эти пользователи имеют действительные сертификаты системы EFS, опубликованные в их учетных записях в службе каталогов Active Directory®). Хотя это опубликование и можно выполнять вручную, использование центра сертификации системы Windows, установленного в корпоративном режиме (интегрированного в службу Active Directory), делает данный процесс полностью автоматическим.

Управление ключами системы EFS
При наличии готовой к использованию инфраструктуры открытых ключей на основе ОС Windows Server 2003 процесс генерирования пользовательских сертификатов системы EFS является несложным. Центр сертификации системы Windows Server 2003 поставляется с предоставляемым по умолчанию набором шаблонов сертификатов, включая шаблон Basic EFSBasic EFS (Базовое шифрование EFS). Однако этот шаблон является шаблоном версии 1 и не поддерживает архивирование ключей. Поэтому прежде чем делать его доступным в своем центре сертификации, нужно создать копию этого шаблона для создания нового шаблона версии 2 (его, например, можно назвать EFS with Key ArchiveEFS with Key Archive (EFS с архивом ключей), как показано на рис. 1). В этом новом шаблоне перейдите на вкладку Request HandlingRequest Handling (Обработка запросов) и установите флажок архивирования ключей шифрования пользователей. Обратите внимание на то, что прежде чем включать этот параметр, необходимо правильно настроить архивирование ключей в центре сертификации. В раздел источников информации включено отличное подробное описание этого процесса. Вам также следует заместить этим шаблоном шаблонBasic EFS Basic EFS (Базовое шифрование EFS), чтобы гарантировать использование клиентами этой новой версии (см. рис. 2).
Рис. 1. Файловая система EFS с архивом ключей
Рис. 1. Файловая система EFS с архивом ключей (Щелкните изображение, чтобы уменьшить его)
Рис. 1. Файловая система EFS с архивом ключей
Рис. 1. Файловая система EFS с архивом ключей (Щелкните изображение, чтобы увеличить его)
Рис. 2. Замещение шаблона Basic EFS (Базовое шифрование EFS)
Рис. 2. Замещение шаблона Basic EFS (Базовое шифрование EFS) (Щелкните изображение, чтобы уменьшить его)
Рис. 2. Замещение шаблона Basic EFS (Базовое шифрование EFS)
Рис. 2. Замещение шаблона Basic EFS (Базовое шифрование EFS) (Щелкните изображение, чтобы увеличить его)
Затем необходимо установить для шаблона соответствующие права, чтобы предоставить доступ для подачи заявок нужной совокупности пользователей. Так как компонент EFS в системе Windows автоматически запрашивает сертификат при первом использовании системы EFS, обычно нет необходимости разрешать пользователям автоматическую подачу заявок для шаблона EFS. Фактически, я бы не рекомендовал включать автоматическую подачу этих заявок, если нет уверенности в том, что все автоматически подающие заявки пользователи будут использовать систему EFS. На рис. 3 показаны настройки подачи заявок на сертификаты EFS. Выдавая сертификаты пользователям, которые, возможно, никогда не будут пользоваться системой EFS, вы бесполезно увеличиваете размер базы данных центра сертификации. Хотя размер самой базы данных центра сертификации не ограничен, но по мере увеличения количества выдаваемых сертификатов управление этой базой данных может усложняться (в частности, через консоль управления MMC).
Рис. 3. Настройка прав пользователей системы EFS
Рис. 3. Настройка прав пользователей системы EFS (Щелкните изображение, чтобы уменьшить его)
Рис. 3. Настройка прав пользователей системы EFS
Рис. 3. Настройка прав пользователей системы EFS (Щелкните изображение, чтобы увеличить его)
И, наконец, если необходима поддержка совместного использования зашифрованных файлов, следует обеспечить автоматическую публикацию сертификатов пользователей в службу каталогов Active Directory центром сертификации.
При правильной настройке шаблона центра сертификации когда пользователь впервые попытается зашифровать файл с помощью системы EFS, ему центром сертификации будет выдан сертификат, а его закрытый ключ будет автоматически помещен в архив.

Управление ключами агентов DRA
Следующий вопрос, который необходимо продумать при наличии инфраструктуры PKI, заключается в том, использовать или нет генерируемые центром сертификации сертификаты агентов DRA. В каких случаях не стоит использовать сертификаты агентов DRA из инфраструктуры PKI? Представьте ситуацию, когда имеется центр сертификации с собственным краткосрочным сертификатом (на два года или меньше). Этот центр не сможет выдавать сертификаты со сроком действия, превышающим его собственный, а это значит, что сертификаты агентов DRA будут иметь срок действия два года (или меньше). Это может привести к значительно более сложной схеме восстановления данных. Этот гипотетический пример иллюстрируется следующей ситуацией.
  1. Пользователь шифрует файл в январе 2006 г. Сертификаты агентов DRA, опубликованные на машину пользователя через групповую политику, имеют срок действия два года (истекают в январе 2008 г.).
  2. Пользователь продолжает работать с системой EFS, шифруя новые файлы.
  3. В январе 2008 г. срок действия сертификатов агентов DRA истекает, и администратор через групповую политику публикует на машину пользователя новые сертификаты.
  4. При выполнении любых операций по шифрованию с этого момента будут использоваться новые сертификаты агентов DRA (включая любые файлы, открываемые пользователем, которые были зашифрованы с использованием старых сертификатов агентов DRA; при их сохранении используются новые сертификаты DRA), но все файлы, которые пользователь не трогает, будут оставаться защищенными старыми сертификатами DRA.
  5. Пользователь случайно повреждает свой профиль и нуждается в восстановлении данных.
  6. В этой ситуации ИТ-администратор должен иметь два комплекта сертификатов DRA: новые для файлов, с которыми пользователь работал после этапа 3, и старые для файлов, с которыми пользователь после этого не работал.
Хотя ИТ-администратор может запустить после этапа 3 сценарий, обновляющий все файлы новым агентом DRA (с помощью команды cipher.exe /u), этот процесс может потребовать много времени. Кроме того, для ясности, пара ключей агента DRA не становится бесполезной после истечения срока действия, хотя компонент EFS и не позволит выполнять новые операции по шифрованию, если в его политику восстановления включен сертификат агента DRA, срок действия которого истек. Старые файлы, зашифрованные с использованием пары ключей DRA, срок действия которых истек, конечно же, могут быть восстановлены с использованием этих ключей. Следовательно, пары ключей агентов DRA никогда нельзя удалять, даже если их срок действия истек. Невозможно предсказать, когда они понадобятся.
По этой причине я рекомендую задействовать в средах с центрами сертификации, имеющими короткий срок действия собственного сертификата, самозаверяющиеся сертификаты DRA с более длительным сроком действия. Служебная программа шифрования включает параметр (cipher.exe /r), который автоматически создает пары ключей агентов восстановления данных системы EFS, имеющие срок действия 100 лет (см. рис. 4). Сертификат из этой пары ключей может быть прикреплен к объектам GPO (Group Policy Object £ объект групповой политики) и использован в качестве агента DRA в рамках всей организации. Так как компонент EFS не проверяет цепочку доверия сертификатов DRA, эти самозаверяющиеся сертификаты будут работать без внесения каких-либо изменений в список доверенных корневых центров сертификации соответствующих систем. Независимо от срока действия центра сертификации организации, я всегда рекомендую создавать хотя бы один сертификат агента DRA длительного действия и присоединять его к объекту GPO, примененному ко всему домену. Это резервный вариант восстановления данных, которым можно будет воспользоваться, если все другие варианты не сработают. Это особенно актуально в случае использования генерируемых центром сертификации ключей агентов DRA при отсутствии архива ключей центра сертификации. Если сертификат DRA в какой-либо момент подвергнется риску, можно будет обновить GPO, присоединив новый сертификат, и воспользоваться для обновления файлов командой cipher.exe /u, как это обсуждалось выше.

Рис. 4. Выполнение команды Ciquer /R (Щелкните изображение, чтобы уменьшить его)

Рис. 4. Выполнение команды Ciquer /R (Щелкните изображение, чтобы увеличить его)
Источники информации о системе EFS
Большое количество дополнительной информации о системе EFS и практических рекомендаций можно найти на следующих веб-узлах:
  • Why you shouldn’t be using passwords of any kind on your Windows networks (на английском языке)
  • Implementing Key Archival Walkthrough (на английском языке)
  • Encrypting File System in Windows XP and Windows Server 2003 (на английском языке)

Развертывание агентов KRA и DRA
Архивирование ключей обеспечивает администраторам центров сертификации возможность восстанавливать депонированные ключи шифрования для пользователей. Конечно же, это очень мощная возможность, затрагивающая конфиденциальность, потому что она позволяет администратору центра сертификации расшифровывать любые данные организации, которая использует ключи, подписанные этим центром сертификации. Таким образом, с архивированием и восстановлением ключей следует обращаться очень осторожно, и только очень небольшому кругу заслуживающих доверия сотрудников службы безопасности должно предоставляться соответствующее право. Так как операция восстановления ключей затрагивает конфиденциальность, то при желании использовать этот метод в качестве основного механизма восстановления доступа к зашифрованным с помощью системы EFS данным важно направить группе администрирования центра сертификации четко определенный процесс передачи запросов о восстановлении по инстанциям. Процесс восстановления должен инициироваться только после тщательной проверки таких запросов. Затем после фактического восстановления ключа он должен предоставляться пользователю безопасным методом (не по электронной почте), так как восстановленный ключ обеспечивает доступ ко всем защищенным с помощью системы EFS данным пользователя.
Ключи агента KRA (Key Recovery Agent £ агент восстановления ключей) генерируются и хранятся администраторами центра сертификации, эти ключи не распространяются через групповую политику. Фактически, даже сама система EFS не может определить, был ли используемый ею ключ скопирован в архив, а просто выполняет операции шифрования, как и полагается этой системе. Кроме того, созданные в центре сертификации ключи KRA никоим образом не являются предназначенными специально для системы EFS. К центру сертификации, в котором используется архивирование ключей, будет присоединено на уровне центра сертификации n ключей KRA, которые будут использоваться для защиты любых архивируемых центром сертификации ключей. К числу таких ключей относятся ключи, используемые для системы EFS, защиты электронной почты или для любого другого сертификата, включающего шифрование. Ключи KRA должны храниться с соблюдением мер безопасности лицами, являющимися агентами восстановления ключей, а для обеспечения наличия резерва на случай утраты одного из ключей таких ключей должно быть не меньше двух.
При первом входе администратора в систему контроллера вновь созданного домена на уровне домена по умолчанию создается политика восстановления с использованием самозаверяющегося сертификата и пары ключей, хранящихся в профиле администратора на контроллере домена. Этот сертификат DRA будет иметь срок действия три года. Рекомендуется удалить этот сертификат по умолчанию и заменить его самозаверяющимся сертификатом с большим сроком действия или сертификатом, выданным инфраструктурой PKI. Если не удалить этот создаваемый по умолчанию самозаверяющийся сертификат, то через три года после его создания система EFS перестанет шифровать новые файлы по всему домену. Это связано с тем, что срок действия сертификата истечет, и система EFS будет препятствовать шифрованию данных, если в ее политику восстановления будет включен сертификат DRA с истекшим сроком действия. Хотя системой Windows XP и более поздними операционными системами можно пользоваться без политики агента восстановления, это настоятельно не рекомендуется. Такое пользование означает, что в случае утраты по какой-либо причине пользователем доступа к своему ключу шифрования и при отсутствии возможности восстановить этот ключ, все данные этого пользователя будут безвозвратно утрачены.
Как уже отмечалось, ключи DRA могут быть либо самозаверяющимися, либо выданными центром сертификации. В большинстве случаев лучше всего применять смешанный подход, когда в качестве запасного варианта в рамках всего предприятия используется не менее двух самозаверяющихся сертификатов DRA с длительным сроком действия. Так как сертификаты DRA разворачиваются через объекты групповой политики (GPO), они, как и другие объекты GPO, обладают возможностями наследования. Иными словами, стандартный алгоритм накопления и применения локальных объектов групповой политики, объектов групповой политики узлов, доменов и подразделений, управляющий применением других настроек объектов групповой политики, также применяется и к агентам DRA. Таким образом, организация может легко реализовать разделенный на уровни подход к агентам DRA, при котором центральная ИТ-группа имеет доступ к агентам DRA для всего предприятия, а локальные ИТ-группы обладают возможностями в отношении своих конкретных зон ответственности. Это особенно ценно для больших, территориально разбросанных организаций, так как снижает потребность в передаче больших объемов зашифрованных данных по каналам глобальной сети для облегчения восстановления данных. На рис. 5 показано типовое развертывание агентов DRA при наличии нескольких уровней.
Рис. 5. Многоуровневое развертывание агентов DRA
Рис. 5. Многоуровневое развертывание агентов DRA
В этом случае пользователь из подразделения Baton Rouge в итоге имеет для каждого зашифрованного файла шесть агентов DRA: два от своих локальных администраторов, два от североамериканской ИТ-группы и два от уровня домена. Следовательно, если пользователь потеряет доступ к своим зашифрованным данным, ему их может восстановить локальный агент DRA в Baton Rouge или член североамериканской ИТ-группы. В крайнем случае, если эти четыре агента DRA будут недоступны или утрачены, заняться этим вопросом и восстановить данные могут агенты DRA уровня домена. Независимо от того, какой агент DRA выполнит восстановление, этот процесс будет практически одинаковым. Пользователь сначала сделает данные доступными агенту DRA. Важным моментом является обеспечение агентом DRA необходимых мер, направленных на проверку законности данного запроса и того, что этот запрос поступил от истинного владельца данных. После этого агент DRA загружает сертификат DRA, расшифровывает (и, желательно, повторно зашифровывает) данные, а затем отправляет эти данные обратно конечному пользователю. Некоторые организации также предпочитают выполнять локальное восстановление, когда агент DRA физически посещает пользователя, у которого возникли проблемы, загружает свою пару ключей агента DRA в профиль и расшифровывает данные, после чего удаляет свою пару ключей. Пользователь получает доступ к незашифрованным данным и может повторно зашифровать свои данные с помощью нового ключа. Необходимо отметить, что этот подход является намного менее надежным, потому что пара ключей агента DRA копируется (хотя и временно) на локальную машину, но это может сэкономить некоторое количество времени, особенно в том случае, когда необходимо восстановить большой объем данных.
Обратите внимание на то, что если восстановление обеспечивается пользователю посредством архивирования и восстановления ключа, то запрос о восстановлении должен обрабатываться совершенно независимо от этого процесса. Вместо использования агента DRA запрос пользователя о восстановлении ключа должен поступать администраторам центра сертификации, которые должны выполнить по этому запросу проверку, затем обратиться к архиву и восстановить закрытый ключ пользователя. Затем они должны безопасным методом предоставить этот закрытый ключ пользователю, например поместив его на безопасный веб-узел для загрузки пользователем. (Если пользователь для хранения ключа системы EFS пользуется смарт-картой, что возможно в ОС Windows Vista, то этот ключ также должен быть выдан повторно.) Пользователь загрузит данный ключ в свой профиль и сразу получит доступ ко всем своим зашифрованным данным.
Так как пары ключей агентов DRA и KRA могут использоваться для расшифровки конфиденциальных данных, важно обеспечить их надлежащую защиту. Пары ключей агентов DRA и KRA не должны храниться в нормальных профилях администраторов на настольных системах (в профилях, которые они используют для выполнения своих повседневных задач). Напротив, эти пары ключей должны безопасно сохраняться на автономный накопитель, например на дискету, оптический или флэш носитель, и храниться в физически защищенном месте. Затем, если необходимо выполнить восстановление, агент восстановления может загрузить соответствующую пару ключей с этого накопителя на восстанавливающую данные рабочую станцию, выполнить операцию восстановления и удалить эту пару ключей. В некоторых наиболее чувствительных к обеспечению безопасности организациях для восстановления отведены специальные выделенные рабочие станции, что позволяет дополнительно повысить защищенность этих пар ключей, но это требование не является обязательным для всех организаций.

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

Джон Морелло (John Morello) с отличием окончил университет штата Луизиана и в течение шести лет работает на различных должностях в корпорации Майкрософт. Работая в должности старшего консультанта, он разрабатывал решения в сфере безопасности для предприятий, входящих в рейтинг Fortune 100, а также для клиентов из гражданских и оборонных федеральных ведомств. В настоящее время является руководителем программы в группе по разработке операционной системы (ОС) Windows Server, занимающейся вопросами обеспечения безопасности и технологиями удаленного доступа.


 Файлы рабочего стола: Расширение возможностей среды Windows PE
Файлы рабочего стола
Расширение возможностей среды Windows PE
Уэс Миллер (Wes Miller)

Еще до того, как более пяти лет назад была выпущена среда предустановки Windows PE, увлеченные пользователи обращались с просьбами внести в нее дополнительные возможности. К сожалению, при проектировании среды Windows PE возможность легко расширить ее, как это можно сделать, например, с системой Windows XP Embedded, добавляя дополнительные уровни операционной системы, не была предусмотрена. Конечно, среда Windows PE должна была обеспечивать работу на элементарном уровне
поддержки интерфейса Win32® (необходимой для того, чтобы работало большинство приложений системы Windows®), поддержки сетевой работы и работы запоминающих устройств большого объема (для обеспечения сетевого обмена данными и возможности установки системы Windows). Но уже с самого начала мы стремились ограничить функции оболочки ядра. Используя вместо традиционного Проводника Windows интерпретатор cmd.exe, мы ограничили возможности среды Windows PE и, что более важно, добились того, что используемая по умолчанию среда позволяла легко использовать сценарии для любых задач, связанных с автоматизацией.
Тем не менее, возможности среды Windows PE можно увеличить £ необходимо только помнить, что они ограничены. Можно ожидать, что приложение не будет работать или будет вести себя неправильно, если для него требуется хотя бы одна из технологий, перечисленных на рис. 1 (список не исчерпывающий).
Figure 1 Недостающие интерфейсы среды Windows (Close Figure 1)

.Платформа .NET Framework (любые версии)
Интерфейсы служб Active Directory® (ADSI)
DirectX®
Компоненты MDAC (Microsoft Data Access Components)
Ядро БД Jet (СУБД Access)
Среда Visual Basic® (включая версии, не поддерживающие платформу .NET)
Любые исполняемые файлы, для которых необходима платформа, не входящая в стандартную конфигурацию среды Windows.
Проводник Windows или обозреватель Internet Explorer
Проигрыватель Windows Media®
Интерфейсы SAPI, MAPI, TAPI (прикладные интерфейсы речи, электронной почты и телефонной связи системы Windows, соответственно)
Если неизвестно, от чего зависит работа приложения, необходимо это выяснить. Но как? С той же самой проблемой столкнулись и мы, когда до выпуска среды Windows PE пытались заставить работать в ней компоненты ADO (ActiveX Data Objects £ объектов данных системы управления каталогами), сценарии сервера Windows (WSH) и приложения HTML (HTA). Следует, однако, заметить, что, хотя в этой статье и будут описаны способы, позволяющие проследить такие зависимости, добавление к образу среды Windows PE любых двоичных данных, входящих в систему Windows, кроме тех, которые помещает в него команда MKIMG, не предусмотрено Лицензионным соглашением (EULA). Чтобы внести подобные изменения в среду предустановки, будет необходимо приобрести у корпорации Майкрософт дополнение к лицензионному соглашению.

Как разобраться в зависимостях
Можно много узнать, если открыть в Блокноте и тщательно изучить inf-файл приложения. Часто это £ простейший способ разобраться в приложении и увидеть, от каких компонентов оно зависит. Важно понимать, что среда Windows PE в большинстве отношений настолько урезана, что для надежной работы приложения придется отслеживать несколько уровней зависимостей £ как непосредственные зависимости для приложения, так и зависимости, обусловленные каждой из этих зависимостей. Если не проявить достаточной осторожности, такая последовательность зависимостей может изрядно разрастись. При случайном (или сознательном) добавлении несколько компонентов, размер и сложность образа могут значительно увеличиться.
Если есть описывающий приложение inf-файл, сведения о зависимостях можно получить, выяснив, какие ключи реестра и файлы этот inf-файл добавляет в систему. Ищите разделы CopyFiles и AddReg. Записи в этих разделах будут указывать на приложения, библиотеки DLL и другие файлы, от которых зависит приложение. Из трех надстроек для среды Windows PE (отвечающей за интерфейс ADO, за приложения HTA и сценарии WSH) проще всего было создать надстройку для сценариев WSH. Поскольку распространяемая версия сервера WSH для предыдущих версий операционной системы (ОС) Windows оставалась доступной, и поскольку сегодня в систему Windows встроен inf-файл (%windir%\inf\wsh.inf), обеспечивающий сопоставление серверу WSH соответствующих типов файлов, дополнение среды Windows PE этой надстройкой было относительно несложным.

Программа Orca и моментальные снимки
Если рассматриваемое приложение распространяется в виде файла Microsoft® Installer (MSI-файла), то для обнаружения зависимостей можно сделать две вещи. Если пользователь является специалистом по пакетам MSI, то для их просмотра может использовать программу Orca (средство для редактирования файлов Windows Installer, распространяемое, как составная часть пакета Windows Server® 2003 R2 Platform SDK: go.microsoft.com/fwlink/?LinkId=77941). Можно также установить пакеты MSI для нужных компонентов и выполнить сравнительный анализ файлов и ключей реестра до и после установки. Можно сохранить копию реестра, установить приложение, вновь экспортировать реестр, а затем проанализировать его с помощью программы WinDiff (см. врезку «Using WinDiff»(Использование программы WinDiff) в боковой панели). Результат можно использовать как образец изменений, которые должны быть сделаны в реестре. Проблема состоит в том, что число таких изменений может быть нескончаемым. Однако, если под рукой нет inf-файла (или автора приложения), это может быть лучшей из доступных возможностей.
Возможно, пользователь знает, как делать моментальные снимки приложений. В сущности, это тот же сравнительный анализ до и после установки, который выполняется для того, чтобы заставить приложение работать. Раньше (в составе ОС Windows 2000) корпорация Майкрософт распространяла программное средство, которое позволяло это делать, но оно не работает ни с одной из более новых версий системы Windows. Способны это делать многие коммерческие приложения (переупаковщики установочных файлов), но способны и некоторые бесплатные программы. Как одно из возможных решений можно предложить установку пакета Platform SDK (см. ссылку в предыдущем абзаце), включающего программу WinDiff. Обратите внимание на то, что для сравнения с помощью программы WinDiff идеально было бы устанавливать анализируемое приложение в системе под управлением ОС Windows Server 2003 с пакетом обновлений SP1, потому, что будет использоваться именно эта версия среды Windows PE £ Windows PE версии 1.6 на основе выпуска ОС Standard Edition или Enterprise Edition (с пакетом обновлений SP1). Выполняя эту операцию в ОС Windows Server 2003, пользователь будет иметь дело со средой, максимально приближенной к среде Windows PE (где очевидным образом невозможно запустить пакет MSI). Следуйте процедурам, описанным в боковой панели «Использование программы WinDiff».
В результате будет видно, что изменилось значительное количество данных. К сожалению, не существует простого способа преобразовать полученные данные об изменении реестра и файлов так, чтобы получить инструкцию для установки приложения. Изменения нужно вносить вручную. Здесь мы столкнулись с одной из наиболее сложных проблем, имеющихся в первой версии среды Windows PE. Добиться того, чтобы компоненты HTA вообще могли работать, было сложно, поскольку определения для них во всей системе Microsoft (за исключением тех, что были в обозревателе Internet Explorer®) вообще не существовало. С помощью анализа различий нам удалось соорудить такую поддержку HTA, что стало можно рассчитывать на ее функционирование. Хотя можно добавить соответствующие ключи в реестр среды Windows PE вручную, пользователь может предпочесть добавить их после того, как среда предустановки будет запущена. Можно обратить внимание на файлы OC.bat и OC2.bat, которые используются для того, чтобы с помощью входящего в средства для сборки среды Windows PE сценария buildoptionalcomponents.vbs, включить в нее поддержку компонентов HTA, WSH и/или ADO.

Полезные инструменты
Даже выявив прямые зависимости, часто не удается найти каждый двоичный файл, от которого зависит возможность выполнения приложения. Например, не будет известно, не потребуются ли приложению для выполнения какой-то задачи дополнительные библиотеки DLL или OCX-файлы. Как же это узнать? Марк Руссинович (Mark Russinovich), прославившийся в компании Sysinternals (теперь технический специалист корпорации Майкрософт), написал удобную программу, которая называется listdlls и выполняет именно эту задачу. Программу listdlls можно загрузить на веб-странице microsoft.com/technet/sysinternals/utilities/ListDlls.mspx (на английском языке). Чтобы воспользоваться этой программой, выполните команду listdlls.exe > dlls.txt, а затем изучите выданные ею результаты. На рис. 2 показаны результаты выполнения программы listdlls для самой этой программы. Можно сравнить данный список с DLL- и OCX-файлами, входящими в среду Windows PE, чтобы определить, присутствуют ли все компоненты, от которых зависит приложение (для программы listdlls нужные компоненты уже присутствуют). Программа listdlls сыграла решающую роль в определении некоторых зависимостей, которые было невозможно установить другим способом при реализации в среде Windows PE поддержки приложений HTA.
Рис. 2 Результаты выполнения программы listdlls для нее самой.
Рис. 2 Результаты выполнения программы listdlls для нее самой. (Щелкните изображение, чтобы уменьшить его)
Рис. 2 Результаты выполнения программы listdlls для нее самой.
Рис. 2 Результаты выполнения программы listdlls для нее самой. (Щелкните изображение, чтобы увеличить его)
Но лишь только то, что библиотека DLL входит в список, не обязательно означает, что она необходима для работы приложения. Например, если запустить Блокнот, можно увидеть, что он загружает библиотеку uxtheme.dll. В среде Windows PE эта библиотека недоступна и поскольку темы Windows не используются, реально никогда не будет загружена. Распознавание того, какие отображаемые программой listdlls библиотеки действительно необходимы, а какие загружаются системой Windows по запросу, к несчастью, представляет собой тайное искусство, требующее либо изрядного количества проб и ошибок, либо близкого знакомства с тем, как система Windows работает на низком уровне (для этого рекомендуется книга Марка Руссиновича и Дэвида Соломона: Mark Russinovich, David Solomon Microsoft Windows Internals, Fourth EditionMicrosoft Press®, 2004; имеется русский перевод: Внутреннее устройство Microsoft Windows: Windows Server 2003, Windows XP и Windows 2000, СПб, 2006).
Теми же возможностями Марк наделил и бесплатный диспетчер задач ОС Windows £ Process Explorer. Разница состоит в том, что программа listdlls выдает результаты, которые, легче включать в сценарии и использовать для поиска и сбора сведений о недостающих компонентах.
Обратите внимание на то, что даже когда библиотека к создаваемому образу добавлена, это не обязательно означает, что работа закончена. Дело в том, что существует два вида библиотек: библиотеки одного вида требуют регистрации, второго £ нет. К сожалению, не существует простого способа различить их, кроме попытки зарегистрировать каждую. Чтобы зарегистрировать библиотеку DLL (или элемент OCX), следует выполнить команду regsvr32 имябиблиотеки.dll. Если выполнение команды будет успешным, откроется диалоговое окно, подтверждающее, что библиотека была зарегистрирована. Если нет, сообщения может не быть или, что более вероятно, появится диалоговое окно, сообщающее либо о неудачной регистрации, либо о том, что библиотека не может быть зарегистрирована. При разработке дополнительных компонентов для поддержки компонентов HTA и ADO в среде Windows PE было обнаружено, что для регистрации, временного сохранения inf-файлов установки или записи каких-то других необходимых библиотекам компонентов (например определенных каталогов), им требуется перезаписываемая память. В среде Windows PE это обычно означало, что регистрация закончилась неудачей. К счастью, в случае среды Windows PE 2.0 подобные задачи перестали представлять проблему, поскольку наличие свободного рабочего пространства предусмотрено по умолчанию.
(на английском языке).

Удаление файлов среды Windows PE
Наряду с возможностью добавлять компоненты к среде Windows PE пользователи часто просят инструкций о том, как сделать образ Windows PE меньше. Существуют процедуры, позволяющие немного уменьшить размер образа Windows PE. Экземпляр среды Windows PE, на который имеется лицензия, должен включать набор средств для сборки образа и определенную документацию. Среди документов имеется файл справки winpe.chm. Если открыть этот файл и обратиться к разделу «Windows Preinstallation Environment User’s Guide» (Руководство пользователя по среде предустановки ОС Windows), можно найти тему «Reducing the Size of Windows PE» (Уменьшение размера образа Windows PE). В этой теме перечислены файлы, которые (если они не нужны) можно безопасно удалить. К файлам, которые можно удалить, относятся три группы.
  • Всегда можно безопасно удалять файлы шрифтов.
  • Можно удалять inf-файлы и служебные программы, связанные с работой в сети; однако делать это следует только в том случае, если вообще не планируется пользование созданной средой в сети.
  • Не следует удалять программы командной строки. Не рекомендуется удалять какую бы то ни было из них, если определенно не известно, каковы ее функции и что может произойти при ее удалении.
Когда определено, какие файлы удалять безопасно, можно просто написать пакетный файл или сценарий другого типа и удалить их из сборки Windows PE после завершения ее создания с помощью сценария mkimg.cmd.

Редактирование реестра среды Windows PE
Можно видеть, что было принято сознательное решение не устанавливать дополнительные компоненты во время сборки. Хотя это предполагает несколько большие затраты времени при запуске, это также означает, что не пришлось изобретать совершенно нового способа вернуть эти компоненты в среду Windows PE £ задача, на решение которой не было времени и постановка которой, скорее всего, привела бы к необходимости от них отказаться. Но что если нужно внести изменения в реестр, например, добавить изменения, которые вносит в реестр приложение, или просто нужно отредактировать ключ, который может обеспечить его работоспособность? Этого добиться не сложно, и используется для этого, как показано на рис. 3, программа regedit. Выполните следующие действия.
  1. Запустите программу regedit и выберите в реестре куст HKEY_LOCAL_MACHINE.
  2. В меню выберите пункты File | Load Hive (Файл | Загрузить куст), а затем перейдите в расположение сборки Windows PE. Выберите файл setupreg.hiv в папке I386\System32\ (или MiniNT\System32, если это образ, который размещается на жестком диске).
  3. Введите временное имя куста, например WinPE, и перейдите к этому узлу в ветви HKLM.
  4. Измените этот ключ нужным образом. Интересно отметить, что по существу это тот же самый узел, каким при обычной установке ОС Windows был бы узел HKLM\System.
  5. По окончании внесения изменений выберите ключ, который был создан в ветви HKLM, выполняя действие 3 (очень важно при этом не ошибиться £ иначе можно повредить ОС).
  6. Выберите в меню пункты File | Unload Hive... (Файл | Выгрузить куст...) и нажмите кнопку Yes (Да) в окне подтверждения. Каждый раз необходимо убеждаться в том, что реестр демонтирован, поскольку при запертом реестре успешная сборка Windows PE невозможна.
Рис. 3 Открытие реестра Windows PE
Рис. 3 Открытие реестра Windows PE (Щелкните изображение, чтобы уменьшить его)
Рис. 3 Открытие реестра Windows PE
Рис. 3 Открытие реестра Windows PE (Щелкните изображение, чтобы увеличить его)
Выполняя следующие шаги, можно изменить раздел реестра HKLM\System. В папке I386\System32 находятся также два других ключа, позволяющие редактировать другие области реестра. Файл DEFAULT представляет собой куст по умолчанию для пользователей (и даже для учетной записи SYSTEM, под которой осуществляется работа в среде Windows PE), а файл SOFTWARE соответствует разделу HKLM\Software. Как всегда, изменения в реестр нужно вносить осторожно и только те, которые необходимо.
Теперь имеется некоторое представление о механизмах, которые помогут перенести любимую программу для поиска неполадок или восстановления системы в среду Windows PE. В следующем месяце будет рассмотрен комплект программ PSTools £ собрание чрезвычайно полезных средств управления системой, также написанное Марком Руссиновичем.
Использование программы WinDiff
Программа WinDiff может помочь найти зависимости приложения. Для успешной установки и выполнения программы нужно выполнить следующие действия.
  1. Подготовьте систему к установке £ нужно уменьшить время, которое пройдет между первоначальным и заключительным снимками, и изменения, которые за это время будут внесены в файловую систему и реестр.
  2. Откройте командную строку и выполните команду reg export HKLM C:\HKLM1.reg, чтобы сохранить полную копию куста реестра HKEY_Local_Machine.
  3. Выполните команду dir C:\*.* /S > C:\C1.txt, чтобы сделать полный снимок всех файлов на диске C: (если имя системного диска C:).
  4. Установите приложения и сделайте все необходимые после установки настройки.
  5. Выполните команду reg export HKLM C:\HKLM2.reg.
  6. Выполните команду dir C:\*.* /S > C:\C2.txt.
  7. Откройте программу WinDiff и выберите в меню пункты File | Compare Files... (Файл | Сравнить файлы...), а затем £ файл HKLM1.reg в первом диалоговом окне открытия файла и HKLM2.reg £ во втором.
  8. Появится набранное красным шрифтом сообщение, указывающее на то, какой из этих файлов новее. Будьте терпеливы: процедура может занять некоторое время, поскольку копии раздела HKLM могут быть очень большими.
  9. Дважды щелкните мышью красный текст, чтобы показать различия полностью.
  10. Возможно, потребуется настроить отображение в окне сравнения, установив флажок Options | Show Right-Only Lines (Параметры | Показывать строки, встречающиеся только справа). Это приведет к тому, что будут отображаться только вновь добавленные строки второго из сравниваемых файлов (так что отобразятся только новые файлы и ключи реестра).
Обратите внимание на то, что для нахождения ключей, связанных с приложением, может понадобиться функция поиска. На рисунках A и B можно видеть изменения файловой системы и ключей реестра для созданного автором вымышленного приложения. К счастью, в программе WinDiff работают копирование и вставка. Чтобы воспользоваться этими функциями, просто щелкните строку «!»> и выберите необходимые строки.
Рис. A Записи программы WinDiff
Рис. A Записи программы WinDiff (Щелкните изображение, чтобы уменьшить его)
Рис. A Записи программы WinDiff
Рис. A Записи программы WinDiff (Щелкните изображение, чтобы увеличить его)
Рис. B Отдельные ключи в программе WinDiff
Рис. B Отдельные ключи в программе WinDiff (Щелкните изображение, чтобы уменьшить его)
Рис. B Отдельные ключи в программе WinDiff
Рис. B Отдельные ключи в программе WinDiff (Щелкните изображение, чтобы увеличить его)

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


 Заметки на полях: Связь просто перестает работать
Заметки на полях
Связь просто перестает работать
Рыкандар Коррати (R'ykandar Korra'ti)

«Я не знаю, у меня просто обрывается связь».
«В любое время суток? Это происходит при каких-то определенных действиях? Вы подключаетесь с какого-то определенного компьютера?».
«Нет. У меня есть связь, а потом ее нет. Раз! И пропала».
«Знаете ли, этого недостаточно для работы над решением вашей проблемы. Пожалуйста, сообщите мне что-нибудь полезное. Предположение, намек, хоть что-нибудь».
«Я рассказала вам все, что знаю. Иногда у меня просто пропадает связь. Вы можете это исправить?».
Я говорю, что займусь ее проблемой. Из журналов регистрации маршрутизаторов мало что можно почерпнуть, но время от времени трафик действительно прерывается, что указывает на существование какой-то неисправности, но длится эта проблема одну или две минуты, после чего все опять возвращается в нормальное состояние. Ошибки отсутствуют, системы не прослеживается, просто время от времени нет трафика. Это странно. Затем нам повезло.
Звонит телефон, подключенный к линии DSL.
Отключается IP-соединение.
«Что за шутки?», £ думаю я. И все же это повторяется: если кто-то звонит по номеру линии DSL (которым никто не пользуется и который никто не должен знать), то соединение отключается. В качестве главного довода при продаже услуг телефонная компания заявляла, что об этой наиболее серьезной проблеме нам никогда не придется думать, но она возникла явно и очевидно.
А ведь мы всего в 300 метрах от подстанции. Этого не должно происходить. Я проверяю кабели, все перезапускаю и даже зачищаю соединения, чтобы проверить, не поможет ли это. Но, конечно же, это не помогает. Так что я звоню в телефонную компанию. «Вы помните, как обещали, что наше соединение никогда не будет прерываться входящими звонками? Угадайте, что происходит? Нас могут отключать организации, предлагающие товары по телефону».
«Может, это кабель...».
«Может, это кабель...».
На следующий день приходит техник и неожиданно обнаруживает, что по результатам теста мы находимся более чем в 900 метрах от подстанции, т.е. настолько далеко, что даже случайно упавший рядом с линией небольшой магнит может нарушить связь. В итоге мы узнаем, что когда наш район телефонизировался, все телефонные линии были связаны в жгуты, и каждая линия была подведена к каждому зданию квартала. Это было сделано для того, чтобы в будущем не потребовалось прокладывать новый кабель. Это нормально, если линии используются только для аналоговой передачи голосового сигнала, но с точки зрения технологии DSL каждый сантиметр этих ответвлений учитывается как расстояние до подстанции и ослабляет сигнал.
К счастью, эта проблема была быстро и легко устранена. Были отключены все отводы линии и сделано предупреждение: «Не восстанавливать подключение. Часть линии используется в качестве линии DSL». Вот и все! Расстояние уменьшилось до 300 метров, сигнал стал значительно более сильным и, что наиболее важно, исчезло пропадание несущей во время вызова.
Смысл этой истории заключается в следующем: не считайте, что проблема с подключением является слишком сложной или даже связанной с программным обеспечением. Иногда все дело в кабеле. При установке всегда требуйте от телефонистов выполнения проверки фактического уровня сигнала, передаваемого по линии DSL, даже если они уверены, что в этом нет необходимости; никогда не знаешь, что еще там может быть подключено и создаст проблему в будущем. И не верьте заявлениям о том, что проблема заключается в большом расстоянии до подстанции. Вы, как и телефонисты, понятия не имеете, куда проложены провода. Выясните этот вопрос. У телефонистов есть инструменты, есть технологии, просто заставьте их использовать имеющиеся возможности. Вы будете довольным тем, что сделали это. Особенно, если ваш номер линии DSL станет известен организациям, предлагающим товары по телефону.

Рыкандар Коррати (R'ykandar Korra'ti) работает администратором службы электронной почты небольшого кооперативного поставщика услуг Интернета и живет недалеко от г. Сиэтла со своей подругой Анной. Прежде она занималась поставкой почтовых продуктов в корпорации Майкрософт, а теперь хочет поступить в аспирантуру по такой сложной специальности, что она даже не имеет названия. Те, кто захочет порекомендовать ей соответствующий факультет, могут связаться с ней по адресу darako@murkworks.net.


 Конфиденциальная информация Windows: Смешанное содержимое: за и против
Конфиденциальная информация Windows
Смешанное содержимое: за и против
Рэймонд Чен (Raymond Chen)

Когда вы вставляете компакт-диск или DVD-диск , оболочка проверяет его и определяет тип содержимого. В зависимости от того, какие данные записаны на диске, выбирается действие, выполняемое при автозапуске. Документации, содержащей сведения о том, как происходит эта проверка, нет, поскольку эти методы представляют собой эвристики, которые в будущем могут измениться, если будет найден более эффективный алгоритм.
Если алгоритм формально задокументировать, его использование станет обязательным, и оптимизировать алгоритм в последующих версиях будет невозможно. По этой причине официальное описание алгоритма отсутствует.
Если вам не доводилось писать документацию к SDK, вы, может быть, и не обращали внимания на то, что публикация описания приводит к появлению определенных обязательств. Если сказано, что та или иная задача выполняется тем или иным способом, изменить его вы уже не сможете. В противном случае те, кто рассчитывал, что выполняться она будет именно так, как описано в документации, возмутятся: «Слушайте, в описании же сказано по-другому. Что же вы меняете правила, когда игра уже началась?»
Дабы избежать подобных возражений, здесь приводится краткое, максимально упрощенное описание процесса классификации содержимого компакт-дисков и DVD-дисков с данными, используемого в Windows® XP SP2 в случае отсутствия файла autorun.inf на диске. (Возможно, в следующих пакетах обновлений и в следующих версиях Windows классификация будет выполняться по-другому.) Я называю это описание максимально упрощенным, поскольку на самом деле алгоритм проверки представляется решающей таблицей, содержащей 61 уровень, в нем учитываются самые разнообразные условия: ответило ли приложение переднего плана на уведомление о запросе отмены автозапуска, работает ли какая-либо программа в полноэкранном режиме, и даже запускается ли диск на портативном компьютере, который был недавно пристыкован или отстыкован. Я же коснусь только этапа проверки содержимого.

Сначала проверяется, не установил ли пользователь настройку «Не выполнять никаких действий» для всех типов содержимого. В этом случае проверять тип содержимого не имеет смысла. Решение однозначно: «Не выполнять никаких действий».
Если же такая настройка не установлена, оболочка должна какое-то действие выполнить. Файлы на диске просматриваются по очереди £ вплоть до четвертого уровня в дереве каталогов £ и помещаются в одну из следующих категорий в зависимости от выявленного типа файла: изображения, музыка, фильмы.
Файлы, не подпадающие ни под одну из этих категорий, игнорируются. Если все проверенные файлы относятся к одной категории (например, на диске есть только музыкальные файлы), для диска устанавливается соответствующий тип. Если файлы на диске относятся к разным категориям, содержимое диска определяется как смешанное.
Из сказанного выше следует, что если на компакт-диске с музыкальными файлами записана обложка альбома, Windows XP SP2 будет считать его диском со смешанным содержимым. Это один из тех моментов, которые, наверное, можно бы оптимизировать. Но вообразим следующую ситуацию. Алгоритм на самом деле был оптимизирован, и теперь компакт-диск, содержащий файлы MP3, не становится диском со смешанным содержимым только из-за того, чтосреди музыкальных файлов попалась пара рисунков. Некая компания выпускает компакт-диски, на которых содержится много звуковых файлов и несколько файлов изображений. Компания рассчитывает на то, что содержимое диска будет восприниматься как смешанное, но алгоритм поменялся, и ее продукт теперь причисляется к классу музыкальных дисков. Руководство компании разочаровано. А кто виноват в этом? Компания, опиравшаяся на информацию об алгоритме проверки, или Windows, в которой был изменен алгоритм?
Так вот в Windows Vista™ алгоритм поменялся, хотя и незначительно. В этой версии операционной системы выполняется несколько предварительных проверок, которые блокируют дальнейшее выполнение алгоритма, если диск имеет определенную часто встречаемую структуру. Например, если в корневом каталоге диска есть папка DCIM, считается, что диск содержит цифровые фотографии. Посмотрим, заметит ли кто эти изменения.

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