 TechNet Magazine September 2007

TechNet Magazine September 2007

Windows Vista: Развертывание Windows Vista при помощи BDD 2007

Ваша организация готова перейти с Windows 2000 или Windows XP на Windows Vista, и вы отвечаете за этот проект. Не волнуйтесь. Перед вами пошаговое руководство по использованию Business Desktop Deployment 2007 Solution Accelerator для упрощения развертывания Windows Vista.

Michael Niehaus Windows Vista: Руководство по технологиям резервного копирования Windows Vista.

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

Christine Fok Windows Server: 11 незаменимых средств управления Active Directory

В больших организациях даже самые заурядные задачи Active Directory, такие как добавление и изменение объектов, могут стать долгими и утомительными. Эти 11 средств могут существенно упростить управление Active Directory.

Laura E. Hunter Windows Server: Восстановление объектов-захоронений Active Directory

Каждый план аварийного восстановления Active Directory должен включать основные приемы и методы. Восстановление объектов-захоронений — один из таких приемов, предлагающий единственный способ восстановления удаленных объектов без выведения контроллера домена в автономный режим. Перед вам руководство по поиску и восстановлению объектов-захоронений в Active Directory.

Gil Kirkpatrick Связь: Объединяя пользователей с помощью Office Communications Server 2007

Эра единого общения наступила. Взгляните на Microsoft Office Communications Server 2007 и почувствуйте, как объединенные обмен сообщениями, голосом, видео и конференции могут повысить производительность и улучшить сотрудничество на расстоянии в вашей организации.

Alan Maddison От редактора: Пути к знаниям

Joshua Trupin Письма: Ответы на ваши вопросы

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

Greg Steen Вопросы и ответы по SQL: «Узкие места», связанные с процессором, восстановление и перемещение баз данных и прочее

Edited by Nancy Michell Обзор служебных программ: PageDefrag

Типовая программа дефрагментации Windows может оптимизировать основную часть файлов, хранящихся на жестком диске, но некоторые элементы, такие как файл подкачки Windows и ветви реестра, находятся вне власти программ дефрагментации. Служебная программа, созданная Марком Русиновичем (Mark Russinovich) для компании Sysinternals, позволяет сэкономить целый день, дефрагментируя файлы, которые другие программы не трогают.

Lance Whitney Кабельщик: Модели сильного и слабого узлов

Многосетевой узел обеспечивает дополнительные возможности подключения благодаря одновременному подключению к нескольким сетям. Однако выполняемые на многосетевых узлах службы более уязвимы для атак. Чтобы помочь предотвратить атаки, в данной статье рассматриваются различные модели размещения многосетевых узлов и их поддержка в Windows.

Joseph Davies Windows PowerShell: Обеспечение безопасности Shell

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

Don Jones Эй, автор сценариев!: Можно ли сохранить такие отношения?

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

The Microsoft Scripting Guys Вопросы и ответы по Exchange: Установка, журнал сообщений, возможности хранения и другое

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

KC Lemson and Nino Billic На страже безопасности: Долговременное воздействие управления учетными записями пользователей

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

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

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

Wes Miller Заметки разъездного инженера: Бесплатное угощение и полезные советы

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

Michael Dragone Конфиденциальные сведения о Windows: Балансировка известных библиотек DLL

Функция «известные библиотеки DLL» включена в состав Windows как способ увеличения производительности. Рассмотрим, как это работает, и изучим, как эта функция изменялась во времени.

Raymond Chen


 Windows Vista: Развертывание Windows Vista при помощи BDD 2007
Windows Vista Майкл Нихаус (Michael Niehaus)

Развертывание Windows Vista при помощи BDD 2007
Краткий обзор:
  • BDD 2007 Solution Accelerator
  • Подготовка образа
  • Драйверы и пакеты приложений

Вы постоянно откладывали это, но наконец настало время сделать решительный шаг. В вашей организации сотни, возможно, даже тысячи компьютеров, для которых необходимо выполнить переход с Windows 2000 или Windows XP на Windows Vista. И этим должна заниматься ваша команда.
С чего же начать?
Если вы занимались установкой операционной системы Windows® в течение многих лет, вы, вероятно, заметили, что за время от Windows NT® 3.5 до Windows XP произошло относительно мало изменений. Процесс установки и настройки довольно последователен, используются одинаковые средства, и общий процесс не был изменен. Но в Windows Vista® переработан весь процесс, и появилось много новых средств. Прекрасный обзор этих изменений и их влияния на работу приведен в статье «10 вещей, которые надо знать о развертывании Windows Vista» в выпуске журнала TechNet Magazine за ноябрь 2006 г., которая также находится на веб-узле technetmagazine.com/issues/2006/11/Deployment.

Как получить сведения о новом процессе и средствах?
Существует две возможности.
  1. Изучить каждое новое средство. Изучить всю доступную документацию. Определить, как можно использовать эти средства в существующих процессах. Внести необходимые изменения. Подтвердить результаты.
  2. Воспользоваться неким средством, которое все это уже проделало за вас.
Конечно, вы можете выбрать первую возможность, но в этом случае это была бы книга, а не журнальная статья. Я советую выбрать второй путь: использовать «некое средство» под названием Business Desktop Deployment (BDD) 2007 Solution Accelerator, которое можно загрузить в центре развертывания рабочей среды Microsoft® по адресу microsoft.com/desktopdeployment.
BDD 2007 Solution Accelerator — это набор средств, руководств и пошаговых процедур для упрощения процесса развертывания операционной системы Windows, объединяющий все новые процессы и средства развертывания, представленные в Windows Vista.
Для начала работы с BDD 2007 определите компьютер Windows XP или Windows Server® 2003 для установки BDD 2007. Перед установкой необходимо установить Microsoft .NET Framework 2.0 и консоль управления (MMC) 3.0. Затем можно установить сам BDD 2007. После установки просмотрите заметки о выпуске, которые доступны в папке BDD 2007 в меню «Пуск». Затем запустите оснастку MMC с помощью ярлыка Deployment Workbench (см. рис. 1).
Рис. 1 Запуск BDD 2007 Deployment Workbench
Рис. 1 Запуск BDD 2007 Deployment Workbench
В данный момент следует просмотреть информацию, доступную в информационном центре, в особенности документацию и контрольный список «Начало работы». Необходимо загрузить последние новости и список компонентов, щелкнув правой кнопкой мыши узел «Components» (Компоненты) и выбрав «Check for updates» (Проверка обновлений).
Существует еще одно необходимое условие — наличие пакета автоматической установки Windows (AIK). Для множества выполняемых BDD 2007 функций необходимы средства пакета автоматической установки Windows. Пакет автоматической установки Windows можно получить различными способами: загрузить из центра загрузки Microsoft (go.microsoft.com/fwlink/?LinkId=85377) или использовать узел «Components» (Компоненты) средства Deployment Workbench. В любом случае размер загружаемых файлов довольно большой, и загрузка может длиться долго.
После установки пакета автоматической установки Windows можно перейти к следующему этапу — сбору всех файлов, необходимых для развертывания Windows Vista.

Какие файлы необходимы?
В данный момент необходимо собрать файлы установки Windows Vista, приложения, которые следует установить, драйверы для оборудования и все необходимые обновления и языковые пакеты Windows Vista. Все файлы будут скопированы в структуру общих папок распространения, созданную при установке BDD 2007.
Создание собственного пользовательского образа
Рассматриваемые в данной статье действия описывают развертывание стандартного образа Windows Vista непосредственно с диска DVD продукта Майкрософт. Но может быть необходимо развертывание настроенного образа с дополнительными приложениями (например с выпуском 2007 системы Microsoft Office) на всех компьютерах. Это классический спор: следует ли оставить минимальный «тонкий» образ и установите все компоненты во время развертывания или следует создать «толстый» образ большего размера с предварительно установленными всеми компонентами? Часто ответ зависит от таких факторов, как доступное для развертывания время, объем работы администратора по созданию и поддержке образа, производительность сети и т.д. В большинстве случаев образ меньшего размера предпочтительнее, но это ваш выбор.
Независимо от того, что будет включено в образ, необходимо обеспечить полную автоматизацию процесса создания пользовательского образа. Благодаря автоматизации обновление образа осуществляется простым добавлением к процессу другого этапа, последующим повторным выполнением всего процесса и копированием образа.
Как это выполняется при использовании BDD 2007? Это довольно просто:
  1. Создайте сборку для создания пользовательского образа.
  2. Измените последовательность задач для этой сборки так, чтобы в нее вошли все дополнительные этапы.
  3. Выполните «голое» развертывание из лабораторной точки развертывания (с помощью загрузки с образа ISO Windows PE), выбрав эту сборку.
  4. Укажите необходимость присоединения к рабочей группе.
При выполнении этих действий в мастере развертывания отобразится другая панель.
При выборе записи образа эталонного компьютера BDD 2007 автоматически запустит программу Sysprep для подготовки операционной системы к записи, затем выполнит перезагрузку в Windows PE и запустит программу ImageX.exe для записи нового образа WIM. Затем этот образ можно импортировать в Deployment Workbench и использовать его для следующего развертывания.
Запись эталонного образа с помощью BDD 2007
Запись эталонного образа с помощью BDD 2007

Сначала необходимо скопировать файлы установки операционной системы. Установите диск DVD Windows Vista (предпочтительно носитель с корпоративной лицензией, поскольку в этом случае не требуется отдельный ключ продукта для каждой установки), затем запустите New OS Wizard (мастер добавления новой операционной системы), щелкнув правой кнопкой мыши узел «Operating Systems» (Операционные системы) в Deployment Workbench и выбрав команду «New» (Создать). Выберите «Full Set of Source Files» (Полный набор исходных файлов) и укажите путь к устройству чтения дисков DVD (или соответствующий путь, если эти файлы уже были скопированы в другое место). Завершите работу мастера, приняв оставшиеся параметры по умолчанию. Теперь в списке, отображаемом при щелчке узла «Operating Systems» (Операционные системы), должен находиться один или несколько образов операционной системы (в зависимости от использованного носителя).
Следующим этапом являются приложения. В данный момент добавление приложений не требуется, но если они все-таки были добавлены, их можно выбрать из списка при развертывании Windows Vista. В идеальном случае было бы желательно указать командную строку для установки приложения без взаимодействия с пользователем, чтобы никому не приходилось ждать начала установки приложения. Чтобы посмотреть работу этого средства, попробуйте добавить одно приложение сейчас, выбрав команду «New» (Создать) в узле «Applications» (Приложения) Deployment Workbench, а затем выполнив мастер добавления приложений (см. рис. 2).
Рис. 2 Добавление приложения в рабочую среду
Рис. 2 Добавление приложения в рабочую среду
Следующим этапом являются пакеты операционной системы. Существует три типа пакетов, которые, вероятно, вас заинтересуют: языковые пакеты, обновления безопасности и компоненты Windows Vista.
Языковые пакеты обеспечивают работу Windows Vista на различных языках. Сведения о поддерживаемых языках приведены на веб-узле microsoft.com/globaldev/vista/Vista_Language_Support.mspx. Языковые пакеты, упакованные в виде файлов CAB, доступны для загрузки пользователям, имеющим гарантию на программное обеспечение, на веб-узле licensing.microsoft.com и в центре обновления Windows, если используется Windows Vista Ultimate. (Обратите внимание, что только Windows Vista Enterprise и Windows Vista Ultimate поддерживают установку на компьютере нескольких языковых пакетов.)
Обновления безопасности Windows Vista, как правило, выпускаются ежемесячно и доступны для загрузки на веб-узле microsoft.com/technet/security/bulletinsandadvisories как отдельные файлы MSU.
Кроме того, можно включить новые компоненты Windows Vista, например, Windows PowerShell™. Эти компоненты доступны для загрузки в центре загрузки Microsoft (microsoft.com/downloads) и также упакованы как файлы MSU.
На самом деле все это фактические компоненты, также называемые пакетами, с узла пакетов операционной системы. Эти компоненты могут быть введены в Windows Vista в оперативном (при работе операционной системы) или автономном режиме (когда операционная система не запущена). При использовании BDD 2007 компоненты всегда устанавливаются в автономном режиме после разворачивания и размещения на диске образа Windows Vista, но до первой загрузки.
Но существует одна дополнительная сложность: файлы MSU предназначены для установки в оперативном режим при работе операционной системы Windows Vista с помощью программы установки обновлений WUSA.EXE. Однако в этом примере эти обновления будут устанавливаться в автономном режиме. Для этого необходимы файлы CAB с фактическими компонентами. Фактически, эти файлы MSU являются файлами CAB и на самом деле содержат файлы CAB действительных компонентов. Эти файлы CAB можно извлечь из файлов MSU самостоятельно с помощью следующей команды:
EXTRACT.EXE file.msu -F:*.CAB C:\
В результате будет получен файл CAB для импорта. Следует заметить, что корпорация Майкрософт выпустила исправление для BDD 2007, автоматически выполняющее извлечение файлов. После установки исправления выполнять эти действия вручную более не потребуется, можно указать BDD 2007 файлы MSU, остальное будет выполнено автоматически. Дополнительные сведения об этом исправлении приведены на веб-узле support.microsoft.com/kb/937191.
Для добавления этих компонентов в средство Deployment Workbench щелкните узел «OS Packages» (Пакеты операционной системы) правой кнопкой мыши и выберите «New» (Создать) для запуска мастера добавления пакетов. Укажите путь к папке с пакетами для добавления.
Наконец, могут быть необходимы драйверы оборудования компьютера, на котором будет установлена операционная система Windows Vista. Найдите необходимые драйверы на веб-узлах поставщиков или в центре обновления Майкрософт, загрузите их, затем извлеките файлы пакетных форматов. Последний этап может быть немного сложным, но конечным результатом должны быть исходные файлы драйверов: файлы INF, SYS, DLL и связанные файлы, необходимые для самого драйвера.
После извлечения файлов драйверов запустите мастер добавления драйверов, щелкнув правой кнопкой мыши узел «Drivers» (Драйверы) и выбрав «New Deployment» (Новое развертывание). Средство Workbench выполнит поиск всех файлов INF в структуре каталогов, поэтому не нужно беспокоиться об очистке извлеченных структур каталогов.
После импорта драйверов средство Deployment Workbench создает каталог со всеми сведениями о драйверах, включая поддерживаемые платформы, производителя, версию, а также список поддерживаемых драйвером идентификаторов Plug and Play (PnP ID).

Что необходимо сделать с этими драйверами? Следует ли добавить их в импортированный ранее образ операционной системы?
BDD 2007 не изменяет импортированный образ операционной системы. Вместо этого драйверы добавляются во время процесса развертывания. Основной процесс выглядит следующим образом.
  1. Служебная программа (Microsoft.BDD.PnpEnum.exe) запускается на компьютере, на котором выполняется развертывание, определяя присутствующие на компьютере идентификаторы PnP.
  2. Выполняется поиск идентификаторов PnP в каталоге драйверов. Для каждого найденного совпадения копируются необходимые для компьютера файлы драйверов.
  3. Программе установки Windows Vista указывается на необходимость добавления драйверов к операционной системе после копирования образа на диск, но до первого запуска Windows Vista. Этот порядок используется потому, что некоторые драйверы, например драйверы накопителей, могут быть необходимы для запуска операционной системы.

Могу ли я начинать развертывание?
До начала развертывания осталось еще несколько этапов. Во-первых, необходимо определить сборку, в которой операционная система в дистрибутивном общем ресурсе сопоставляется параметрам, которые должны использоваться, и последовательности задач, которые должны быть выполнены для установки и настройки операционной системы.
Для создания этой сборки щелкните узел «Builds» (Сборки) правой кнопкой мыши и выберите «New» для запуска мастера создания сборок. Укажите идентификатор сборки (выбранную простую строку без пробелов и специальных символов), а также имя и описание сборки, которые будут отображаться при развертывании операционной системы (см. рис.3). Затем выберите операционную систему для установки и укажите основные параметры для использования.
Рис. 3 Указание основных сведений о сборке
Рис. 3 Указание основных сведений о сборке

Ладно, теперь мы готовы к развертыванию?
Необходимо еще одно: точка развертывания. Проще говоря, это общий сетевой ресурс, содержащий все собранные файлы, сведения о сборке и образы Windows PE, используемые в процессе развертывания. Создание точки развертывания осуществляется точно так же, как описывалось несколько раз ранее в этой статье: щелкните узел «Deployment Points» (Точки развертывания) правой кнопкой мыши и выберите «New» (Создать). Выберите «Lab or single-server deployment» (Развертывание в лабораторной среде или с помощью одиночного сервера) (см. рис. 4) и примите оставшиеся параметры по умолчанию.
Рис. 4 Выбор типа точки развертывания
Рис. 4 Выбор типа точки развертывания
По завершении работы мастера щелкните новую точку развертывания на панели списка правой кнопкой мыши и выберите «Update» (Обновить) для создания общего ресурса и образов Windows PE.
Помните добавленные ранее драйверы? Эти же драйверы, по крайней мере сетевые драйверы и драйверы накопителей, также необходимы Windows PE, поэтому во время процесса обновления они будут автоматически добавлены в образ Windows PE.

Мы наконец готовы к развертыванию?
Да! Прежде всего, попробуем выполнить развертывание на новом компьютере. Запишите файл LiteTouchPE_x86.iso, находящийся в папке \distribution\boot, на диск CD-R с помощью любимого программного обеспечения для записи компакт-дисков или средства cdburn.exe, которое можно загрузить с веб-узла Майкрософт (go.microsoft.com/fwlink/?LinkID=77796). Загрузите компьютер с компакт-диска; будет запущена Windows PE, и появится начальный экран приветствия, показанный на рис. 5.
Рис. 5 Можно начинать развертывание
Рис. 5 Можно начинать развертывание
Выберите «Run the Deployment Wizard» (Запустить мастер развертывания) и нажмите кнопку «Next» (Далее) для его запуска. В мастере можно выбрать определенную сборку, добавленные приложения и импортированные пакеты языковой поддержки. Также можно выбрать присоединение к домену, указать имя компьютера и настроить различные другие параметры. Можно даже указать автоматическую запись нового пользовательского образа (используя Sysprep, Windows PE и ImageX для создания нового файла образа).
Развертывание может занять длительное время (в зависимости от скорости и типа компьютера), но вмешательство пользователя не требуется. По завершении работы мастера развертывания отобразится экран сводки с предупреждениями и ошибками, зарегистрированными во время процесса. Это позволяет быстро проверить успешность развертывания — желтый или красный экран сводки означает, что необходимы дополнительные действия, тогда как белый экран означает успешное развертывание.
Теперь попробуем выполнить развертывание на компьютере с установленной Windows XP. В командной строке подключите общий ресурс Distribution$, созданный на сервере BDD 2007, затем запустите LiteTouch.vbs для начала развертывания:
NET USE M: \\MyServer\Distribution$
cscript.exe M:\Scripts\LiteTouch.vbs
Запустится показанный ранее мастер развертывания, только теперь станут возможными несколько новых вариантов (см. рис. 6).
Рис. 6 Варианты для компьютера под управлением Windows XP
Рис. 6 Варианты для компьютера под управлением Windows XP
При выборе «Refresh this computer» (Переустановить систему на этом компьютере) существующая операционная система будет удалена (после дополнительной записи данных и параметров пользователя с помощью программы переноса, которую необходимо загрузить с помощью узла «Components» (Компоненты), как выполнялось ранее с пакетом автоматической установки Windows), далее будет выполнена новая установка Windows Vista. Также можно выбрать «Upgrade this computer» (Обновить этот компьютер), что позволяет программе установки Windows Vista выполнить обновление существующей операционной системы, сохраняя существующие приложения, данные и параметры на компьютере. Выбор варианта зависит от различных факторов, хотя в большинстве случаев будет выбрана переустановка для начала работы с чистого и известного состояния.

Что же еще необходимо знать?
Как насчет Windows XP?
Что делать, если развертывается Windows XP? Не беспокойтесь, BDD 2007 можно использовать для выполнения этого процесса. Выполняйте те же самые действия: используйте файлы установки Windows XP для создания первоначальной сборки, запишите новый образ Windows Imaging (WIM) Windows XP — развертывание образа Windows XP выполняется гораздо быстрее, чем автоматическая установка — затем используйте этот файл WIM для последующих развертываний.
Помните, что по сравнению с развертыванием Windows Vista при развертывании Windows XP существует несколько дополнительных сложностей.
Для драйверов запоминающих устройств Windows XP необходима дополнительная настройка, такая как папки TEXTMODE, параметры unattend.txt и параметры sysprep.inf. Конечно, поскольку драйверы запоминающих устройств не могут быть добавлены к существующим образам Windows XP, при каждом добавлении дополнительного драйвера запоминающего устройства необходимо записывать новый образ. Кроме того, образы Windows XP не являются независимыми от HAL, поэтому требуется два или три отдельных образа. Наконец, языковые пакеты и обновления безопасности не могут быть добавлены в Windows XP в автономном режиме, поэтому они должны быть установлены после того, как Windows XP будет запущена и работоспособна.
При использовании BDD 2007 для развертывания Windows XP вы будете полностью подготовлены к развертыванию Windows Vista, когда решите, что уже пора это сделать.

Это всего лишь основы. Но ознакомление с полным циклом работы процесса позволяет узнать о совместной работе всех новых средств без необходимости изучения каждого из них по отдельности. Теперь вы можете перейти к изучению сценариев и журналов BDD 2007 для получения сведений о выполненных действиях. Можно создать собственные настраиваемые образы и добавить их в BDD 2007 для развертывания вместо использования стандартного образа Windows Vista. Можно создать диск DVD или флэш-накопитель USB с загруженным образом. Можно включить в процесс сервер SMS 2003 и его пакет возможностей OS Deployment Feature Pack.

Где можно найти дополнительные сведения?
Просмотрите все указанные ранее документы — доступно более тысячи страниц, разделенных между различными командами, обычно участвующими в проекте развертывания. Также посетите упоминавшийся ранее веб-узел microsoft.com/desktopdeployment. Используйте группу новостей microsoft.public.deployment.desktop, в которой специалисты по ИТ, такие же, как вы, задают всевозможные вопросы о развертывании Windows. Посетите веб-узлы сторонних компаний, например, deployvista.com и myitforum.com, на которых представлены обширные сведения о развертывании BDD 2007 и Windows Vista. Ознакомьтесь с новой книгой Windows Vista Resource Kit (microsoft.com/mspress/books/9536.aspx) издательства Microsoft Press. Обсуждения различных частей BDD 2007 доступны на моем блоге по адресу blogs.technet.com/mniehaus. Обратитесь к местным представителям корпорации Майкрософт за получением информации о доступных в вашем регионе учебных семинарах по BDD 2007 и Windows Vista. Наконец, дополнительные сведения приведены на врезке «Материалы по развертыванию».
При наличии гарантии на программное обеспечение на Microsoft Office System воспользуйтесь преимуществами служб Desktop Deployment Planning Services (microsoft.com/licensing/sa/benefits/deployment.mspx), чтобы Майкрософт или ее партнеры в течение нескольких дней разработали совместно с вами план, или даже поработали над проверкой концепции тестовой лаборатории на вашем рабочем месте.
Материалы по развертыванию
  • Центр развертывания рабочей среды Microsoft microsoft.com/desktopdeployment
  • 10 вещей, которые надо знать о развертывании Windows Vista technetmagazine.com/issues/2006/11/Deployment
  • Microsoft .NET Framework 2.0 go.microsoft.com/fwlink/?LinkId=94601
  • Консоль управления (MMC) 3.0 для Windows Server 2003 x86 go.microsoft.com/fwlink/?LinkId=94602
  • Бюллетени по безопасности и рекомендации microsoft.com/technet/security/bulletinsandadvisories

Майкл Нихаус (Michael Niehaus) — инженер по проектированию систем в группе Solution Accelerators корпорации Майкрософт. Он отвечает за разработку рекомендаций по использованию, средств и сценариев для Business Desktop Deployment. С ним можно связаться по адресу michael.niehaus@microsoft.com.
© 2007 Корпорация Майкрософт и компания CMP Media, LLC. Все права защищены; полное или частичное воспроизведение без разрешения запрещено.


 Windows Vista: Руководство по технологиям резервного копирования Windows Vista.
Windows Vista Кристина Фок (Christine Fok)

Руководство по технологиям резервного копирования Windows Vista.
Краткий обзор:
  • Резервное копирование и восстановление файлов
  • Средство резервного копирования и восстановления всего компьютера Windows
  • Восстановление системы
  • Теневое копирование

Слишком многие пользователи не думают про резервное копирование своих данных, пока не лишатся их. Это не должно происходить, но, увы, это происходит. Windows Vista нацелена на упрощение резервного копирования при помощи полного набора функций для беспроблемной защиты данных.
Знакомое средство восстановления системы переделано для повышения надежности и поддержки большего числа вариантов восстановления системы. Средство резервного копирования файлов улучшено, а чтобы сделать защиту данных более простой и тщательной, были добавлены два новых средства: средство резервного копирования и восстановления всего компьютера Windows® и средство теневого копирования.
Все эти функции так или иначе полагаются на службу теневого копирования томов (VSS). Данная служба создает копии тома на определенный момент времени (так называемые «теневые копии») и отслеживает изменения, произведенные в периоды между снятием теневых копий.
Каждая из этих четырех функций, доступных через новый центр резервного копирования и восстановления (см. Рис. 1), позволяет создавать резервные копии и использовать их для восстановления данных, но все они сильно отличаются друг от друга. Вместе же они предоставляют широкую защиту от различных форм потери данных на протяжении рабочего цикла компьютера.
Рис. 1 Центр резервного копирования и восстановления в Windows Vista
Рис. 1 Центр резервного копирования и восстановления в Windows Vista

Резервное копирование файлов
Создание расписания работы резервного копирования компьютера
Наличие расписания регулярного резервного копирования для средства резервного копирования всего компьютера является одной из возможных гарантий постоянного наличия свежих образов всей системы. Расписание резервного копирования всего компьютера нельзя составить через панель управления, но можно воспользоваться другим способом — создать новую задачу в планировщике задач. В случае использования такого расписания я рекомендую периодически проверять, выполнено ли резервное копирование. Почему это важно? Потому что данный метод не уведомляет пользователя посредством всплывающего окна, если резервное копирование заканчивается сбоем из-за нехватки места на диске или других временных проблем. Его не следует считать заменой регулярному использованию функции резервного копирования файлов. Так или иначе, расписание работы средства резервного копирования компьютера создается в планировщике задач следующим образом:
  1. Откройте планировщик задач (его можно найти в папке «Стандартные» > «Служебные» раздела «Все программы» меню «Пуск»).
  2. Нажмите кнопку «Создать задачу».
  3. Перейдите на вкладку «Общие».
  4. Введите описательное имя, скажем «Запланированное полное резервное копирование компьютера».
  5. Если нужно, чтобы задача запускалась вне зависимости от того, вошел ли пользователь в систему, щелкните «Выполнять вне зависимости от регистрации пользователя».
  6. Нажмите кнопку «Выполнить с наивысшими правами».
  7. Перейдите на страницу «Триггеры».
  8. Нажмите кнопку «Создать» и выберите, когда и как часто должно производиться запланированное резервное копирование.
  9. Перейдите на страницу «Действия».
  10. Нажмите кнопку «Создать».
  11. В поле «Программа или сценарий» введите wbadmin.
  12. В поле «Добавить аргументы (необязательно)» введите следующую команду, изменяя букву целевого диска по мере надобности:
    Start backup –allcritical –backupTarget:D: -quiet
    Если необходимо включить дополнительные тома, не являющиеся системными, загрузочными или принадлежащими среде восстановления Windows, вместо вышеприведенной используйте следующую строку, заменяя буквы дисков E и F на буквы, соответствующие ситуации (разделенные запятыми):
    Start backup –allcritical –backupTarget:D: -include:E:,F: -quiet
    Отметьте, что команда всегда должна включать флаг allcritical. Отсутствие флага приводит к риску исключения важных системных томов из резервного копирования, что приведет к неудаче восстановления.
  13. Настройте все прочие параметры, относящиеся к задачам.
  14. Нажмите кнопку «OK».

Предположим, я покупаю новый портативный компьютер. После копирования различных файлов — фотографий, документов Microsoft® Word и т.п. — в новую систему, установки приложений и загрузки последних обновлений Windows я решаю провести резервное копирование файлов. Для этого я подключаю внешний жесткий диск к портативному компьютеру и открываю центр резервного копирования и восстановления. При нажатии кнопки «Архивация файлов» открывается мастер, проводящий через этот процесс. Он запрашивает у меня место назначения резервного копирования (в данном случае внешний жесткий диск), категории файлов для резервного копирования (такие как «Изображения») и время проведения резервного копирования.
Для выбора файлов, подлежащих архивации, используется подход, основанный на категориях. Источник должен быть отформатирован под NTFS, но диск назначения может быть отформатирован как под NTFS, так и под FAT. Принадлежность файла к определенной категории определяется по трем факторам: типу MIME, сопоставлении приложений и расширении имени файла.
При необходимости скопировать файлы, не подходящие ни под одну из категорий, выберите категорию «Дополнительные файлы». Она включает файлы с расширениями, не опознаваемыми Windows, но не поддерживает исполнимые и системные файлы. Такие файлы не копируются данной функцией, поскольку они редко представляют собой данные пользователя. Если действительно необходимо провести резервное копирование системных и исполнимых файлов при помощи этого механизма, можно поместить их в файл ZIP и выбрать категорию «Сжатые файлы» в мастере.
Поскольку я использую функции резервного копирования на моем портативном компьютере в первый раз, немедленно выполняется полное резервное копирование — то есть резервное копирование всех файлов из выбранных категорий. Затем будет выполняться лишь разностное резервное копирование. Термин «разностное» в контексте резервного копирования файлов означает отслеживание лишь новых или измененных файлов. Например, если имеется старый документ Word, в который вносятся некоторые изменения, средство резервного копирования файлов сохранит точные копии как старого, так и обновленного документа. (Совокупность одной полной резервной копии и последовательности разностных резервных копий я буду в дальнейшем называть резервным набором данных.)
Вместо постоянного выполнения разностных копирований следует время от времени выполнять полное резервное копирование. Необходимость этого зависит от таких факторов, как время, прошедшее с последнего полного резервного копирования, число копируемых файлов, количество компакт-дисков или дисков DVD, на которое они копируются, и так далее. Это необходимо для постоянного наличия полной копии основных компонентов.
Сохраняемые данные хранятся в виде файлов ZIP (максимальный размер 200 МБ). Это упрощает доступ к данным. Например, позволяет восстановить данные на компьютер, не использующий Windows Vista, путем прямого обзора резервных носителей. Резервные данные сохраняются в отдельных файлах и могут находиться на нескольких дисках. В случае выхода из строя одного диска резервные данные на других носителях останутся доступными.
Резервное копирование файлов использует службу теневого копирования томов для создания согласованных копий файлов, открываемых или используемых приложениями. В течение процесса резервного копирования приложение, проводящее резервное копирование, считывает информацию с этих согласованных копий. Это удобно, скажем, при резервном копировании файла PST, постоянно открываемого Microsoft Outlook®. Служба теневого копирования томов гарантирует, что сохраненный файл PST находится в согласованном состоянии и к нему будет возможен доступ после восстановления.
Резервные копии файлов не удаляются автоматически, однако при нехватке места на диске их можно удалить вручную. Небольшой совет: вместо удаления отдельных разностных копий всегда стоит удалять резервные наборы данных целиком,.
Отдельно следует указать, что стоит избегать копирования резервной копии файлов в новое местоположение. В случае же такой необходимости помните, что это будет работать лишь при перемещении данных с единственного исходного резервного носителя на другой единственный носитель. Например, можно скопировать резервные данные с одного компакт-диска на один диск DVD, но нельзя скопировать резервные данные с нескольких компакт-дисков на один диск DVD. При перемещении резервных данных необходимо скопировать папку резервной копии с именем компьютера и файлом mediaid.bin, которые расположены в корневой папке резервного носителя. Обратите внимание, что при восстановлении файла, который был перемещен, следует выбрать «Специальное восстановление» | «Восстановление файлов из резервной копии, сделанной на другом компьютере» на панели управления резервного копирования, чтобы добраться до этих файлов, поскольку каталогу резервных копий компьютера не будет известно о новом местоположении архивов.

Полное резервное копирование компьютера
Теперь, когда все, что нужно моему портативному компьютеру, установлено и настроено, я хочу провести полное резервное копирование, защищая все, включая операционную систему, установленные мною приложения, параметры настройки и обновления. Я использую функцию полного резервного копирования компьютера, которая затем может быть использована для восстановления моего компьютера после поломки жесткого диска или иного несчастья. В таком случае мне не надо будет заново устанавливать все приложения и проводить настройку. При первом выполнении эта функция выполняет полное резервное копирование всех блоков в выбранных томах, за исключением блоков, которые не хранят информации. Последующие резервные копирования являются разностными на уровне блоков (подробности ниже).
После выполнения резервных копирований панель управления центра резервного копирования и восстановления обновляется (см. Рис. 2). Теперь она предоставляет информацию о времени создания и месте хранения резервной копии.
Рис. 2 Центр резервного копирования и восстановления предоставляет сведения о предыдущих копированиях
Рис. 2 Центр резервного копирования и восстановления предоставляет сведения о предыдущих копированиях
Хотя оба средства выполняют резервное копирование, средство полного резервного копирования компьютера работает совсем не так, как средство резервного копирования файлов. Средство полного резервного копирования компьютера создает резервную копию всего компьютера в виде образа на уровне блоков в формате виртуального жесткого диска (VHD). В течение первого полного резервного копирования механизм просматривает исходный диск и копирует блоки, содержащие информацию, в файл VHD, сохраняемый на диске назначения. Хотя зарезервированные данные и не сжаты, много места они не занимают.
При следующем выполнении полного резервного копирования компьютера в файл VHD записываются только новые и измененные данные, а старые данные в тех же блоках перемещаются в область хранения теневых копий. Служба теневого копирования томов используется для вычисления различий между сделанными моментальными снимками, а также осуществления процесса перемещения старых данных в область теневой копии на диске назначения (см. Рис. 3). Такой подход делает резервное копирование быстрым (поскольку копируются только измененные блоки) и эффективным (поскольку данные сохраняются компактно). Заметьте, что приложение резервного копирования определяет максимальный объем дискового пространства, отводимого под хранение теневых копий на диске назначения. Пошаговая процедура регулярного или автоматического использования системы полного резервного копирования компьютера приведена на боковой панели «Создание расписания полного резервного копирования компьютера».
Рис. 3 Как перемещаются данные в средстве полного резервного копирования и восстановления компьютера
Рис. 3 Как перемещаются данные в средстве полного резервного копирования и восстановления компьютера
При восстановлении данных блоки восстанавливаются на их изначальные местоположения. Если необходимо провести восстановление с более старой резервной копии, механизм считывает соответствующие блоки из области теневой копии и восстанавливает их.
Отметьте, что для полного резервного копирования компьютера доступны лишь диски формата NTFS. Если резервная копия помещается на жесткий диск, этот диск тоже должен иметь формат NTFS.

Восстановление системы
Восстановление системы включено по умолчанию. Я открываю мастер восстановления системы, выбрав «Устранение неполадок Windows с помощью восстановления системы», в левой верхней части центра резервного копирования и восстановления (или в папке «Стандартные» > «Служебные» раздела «Все программы» меню «Пуск»). Если я выберу «Выбрать другую точку восстановления» и нажму кнопку «Далее», я увижу, что точки восстановления уже были созданы в разных точках по ходу настройки моего портативного компьютера, установки приложений и выполнения резервных копирований.
Точки восстановления включены по умолчанию только на загрузочном томе, даже если жесткий диск разделен на несколько томов. Точки восстановления создаются автоматически в ходе установки приложений и драйверов, а также ежедневно в выбранных томах (если точка восстановления уже не была взята в этот день). Точки восстановления также можно создавать вручную через функцию защиты системы в апплете панели управления «Система». Теневые копии, созданные в ходе резервного копирования файлов и полного резервного копирования компьютера, также можно использовать как точки восстановления.
В Windows XP средство восстановления системы использует фильтр файловой системы для отслеживания изменений в файловой системе. В Windows Vista восстановление системы использует службу теневого копирования томов для отслеживания изменений на уровне блоков в выбранных томах. Это делает средство восстановления системы более надежным и позволяет поддерживать больший набор вариантов восстановления.
Кроме того, новое средство восстановления системы может работать, даже если установленная копия Windows нефункциональна. Это делается с помощью среды восстановления Windows, позволяющей восстановить систему, даже если Windows не загружается.

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

Управление пространством для теневого копирования
Пространство для хранения теневых копий выделяется отдельно на рабочих томах и на резервном диске для полного копирования системы. Используемое, выделенное и максимальное пространство для теневых копий можно проверить путем запуска следующей команды из командной строки с повышенными привилегиями:
VSSAdmin list ShadowStorage
Используемое пространство — пространство, занятое теневыми копиями в настоящий момент; выделенное — пространство, зарезервированное для теневых копий (и не используемое для других задач); максимальное — верхний порог, дальше которого объем теневых копий не может расти.
Выделение пространства для теневых копий происходит автоматически, а значит, оно не может быть установлено пользователем. Новое пространство выделяется фиксированными кусками по мере занятия ранее выделенного пространства. По этой причине значение, указываемое для используемого пространства, всегда ниже, чем для выделенного.
Для рабочих томов максимальное допустимое пространство для хранения теневых копий определяется при создании первой теневой копии — обычно при первом включении средства восстановления системы и создания точки восстановления во время установки. Значение устанавливается на 30% свободного пространства или 15% от общего размера тома — что меньше. Этот максимальный размер статичен. Он не меняется ни при увеличении, ни при уменьшении свободного пространства, ни при изменении размера тома.
Однако размер можно подправить вручную путем использования средства VSSAdmin из командной строки с повышенными привилегиями. Например, чтобы увеличить максимальный размер пространства хранения на диске C:\ до 15 ГБ, нужно выполнить следующую команду:
VSSAdmin Resize ShadowStorage /For=C: /On=C: /MaxSize=15GB
Это средство впервые появилось на Windows Server®, где теневые копии определенного тома можно было держать на другом томе. В Windows Vista теневые копии тома хранятся на том же томе. Следовательно, копируемый том и том, на котором копии находятся, должны совпадать.
С другой стороны, объем пространства для хранения теневых копий на диске назначения полного резервного копирования компьютера зафиксирован на 30% от полного объема диска. Это значение контролируется программой резервного копирования компьютера и не может быть изменено вручную. Данное пространство хранения теневых копий используется для хранения добавочных копий, создаваемых средством полного резервного копирования компьютера.
До 64 теневых копий могут находиться на томе в один момент времени, если им хватит места в области хранения теневых копий. После того как максимальное ограничение по объему достигнуто, более старые теневые копии удаляются, чтобы освободить место для более новых. Следовательно, старые точки восстановления для средства восстановления системы удаляются при достижении предела хранимого в рабочем томе объема, а старые резервные копии, созданные CompletePC Backups удаляются при достижении этого предела на резервном диске. Вдобавок, хранение и правка иных данных на резервном диске могут вмешаться в нормальный процесс «старения» резервных копий, приводя к их ускоренному удалению.

Восстановление файлов с помощью теневых копий
Теперь представим, что мой портативный компьютер работал в течение некоторого времени и использовался для создания нескольких презентаций. Законченные презентации были переданы моим клиентам. Прошел месяц, у меня новые проекты, и эти файлы уже удалены. И тут мой менеджер просит у меня копию старых презентаций. Тут-то теневое копирование и может действительно пригодиться.
Искать копии удаленных файлов можно двумя путями. Во-первых, если я знаю, где хранился файл, я могу просто щелкнуть папку правой кнопкой мыши и выбрать «Восстановление предыдущих версий». Затем я выберу дату, содержащую желаемую версию удаленного файла (см. Рис. 4), нажму кнопку «Открыть» и скопирую нужный файл в другую область рабочего тома. Эта операция копирования столь же быстра, как и простое копирование файлов.
Рис. 4 Восстановление удаленного файла
Рис. 4 Восстановление удаленного файла
Забыв, где хранился файл, я могу открыть предыдущую версию ближайшей родительской папки в дереве каталогов и повести поиск оттуда. Например, если я не помню конкретную папку, но помню, что она находилась внутри папки «Документы», я могу выполнить поиск в предыдущей версии папки «Документы», введя имя файла (полное или частичное) в окне поиска, расположенном в верхнем правом углу окна проводника Windows, как показано на Рис. 5. Заметьте, что функция поиска теневых копий не работает в корневой папке, а поскольку теневые копии не индексируются, время поиска может быть большим, чем на рабочем томе.
Рис. 5 Поиск предыдущей версии документа путем ввода части имени файла
Рис. 5 Поиск предыдущей версии документа путем ввода части имени файла

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

Восстановление файла из полной резервной копии компьютера
Для полноты следует упомянуть, что копии, создаваемые средством полного резервного копирования компьютера, можно использовать для восстановления отдельных файлов. Хотя полная резервная копия компьютера и предназначена для восстановления на уровне томов, она сохраняет данные в формате VHD, а это значит, что можно использовать автономное средство работы с файлами VHD для открытия и восстановления отдельных файлов. (На момент написания этой статьи средство работы с файлами VHD доступно лишь как часть Microsoft Virtual Server 2005 R2 с пакетом обновления 1 (SP1), который можно загрузить с microsoft.com/technet/prodtechnol/eval/virtualserver.) Чтобы установить резервную копию, откройте командную строку с повышенными правами и перейдите к Microsoft Virtual Server\Vhdmount. Команда выглядит так:
vhdmount /m [path of the .vhd file] [drive letter to assign to the virtual hard drive]
Когда это делается в первый раз, система может не подобрать нужного драйвера, поскольку он не подписан. Это вызовет сообщение об ошибке, говорящее, что не удалось загрузить драйвер устройства. Для решения этой проблемы после подключения файла VHD при помощи вышеописанной команды перейдите к диспетчеру устройств, щелкните правой кнопкой мыши обнаруженное новое устройство и выберите «Свойства». Оттуда перейдите на вкладку «Драйверы», выберите «Обновить драйвер», щелкните «Выполнить поиск драйверов на этом компьютере» и затем выберите «Выбрать драйвер из списка уже установленных драйверов». Правильный файл драйвера будет находиться в Microsoft Virtual Server\Vhdmount\vhdstor.inf. После установки появится новый диск, а с ним возможность просмотреть последнюю полную резервную копию компьютера и скопировать нужные файлы в другое место.

Полное восстановление компьютера
Вообразите, что в один прекрасный день мне вздумалось использовать мой портативный компьютер, сидя у бассейна. Поскользнувшись на сколькой плитке, я утопила его в бассейне. Ремонту он не подлежит, остается лишь купить новый. Поскольку я использовала средство полного резервного копирования компьютера, я могу восстановить мою систему на новом портативном компьютере, не тратя уйму времени на ручную переустановку каждого приложения и личную настройку параметров каждого. Выполнение полного восстановления компьютера прямолинейно. При запуске я использую установочный диск Windows Vista для загрузки среды восстановления Windows. Там мне предлагается подключить устройство, содержащее образ системы. Я выбираю нужный образ, и начинается процесс восстановления.
После того как восстановление завершено, я выполняю восстановление файлов из моей последней резервной копии. Это делается потому, что я выполняю резервное копирование файлов более часто, и данные в резервных копиях файлов более свежие. Поскольку компьютер возвращен к моменту до резервного копирования избранных файлов, он не содержит записей об этом резервном копировании в каталоге. Поэтому я выбираю «Дополнительные параметры» | «Файлы из архива, созданного на другом компьютере» | «Восстановить все содержимое этого архива». Я также начинаю новое полное резервное копирование, чтобы защитить мои свежевосстановленные данные.
Среда восстановления Windows часто устанавливается изготовителем на жесткий диск как скрытый раздел. Это можно использовать для восстановления образа полной резервной копии компьютера на то же оборудование, но если необходимо восстановить на компьютере образ, созданный на другом компьютере, необходимо запускать среду восстановления Windows с внешнего носителя, такого как диск установки Windows.
Стоит запомнить несколько предостережений. Полное восстановление компьютера работает без сложностей при восстановлении на то же оборудование, с которого была взята резервная копия. (Если, конечно, поломка оборудования не была частью проблемы.)
Поскольку полная резервная копия компьютера включает образ всего компьютера, восстановление на иное оборудование связано с некоторыми ограничениями. Во-первых, образ резервной копии содержит драйверы, используемые для загрузки компьютера после завершения восстановления. Драйверов, необходимых для загрузки на новом оборудовании, среди них может не оказаться. Это может произойти при восстановлении резервной копии образа, снятой на одном типе контроллера диска (IDE, SATA или SCSI), на другой тип контроллера диска. Даже в этом случае есть достаточно большая вероятность успешного завершения восстановления, поскольку стандартные драйверы Windows, входящие в резервную копию образа, скорее всего будут совместимы.
Во-вторых, восстановление может быть выполнено, только если новый компьютер имеет как минимум столько же жестких дисков, как и старый, и каждый жесткий диск не меньше оригинала. Следует иметь эти ограничения в виду при намерении использовать полную резервную копию компьютера для перехода на новое оборудование.
Поскольку резервное копирование и восстановление выполняются на уровне блоков для целых томов, полное восстановление компьютера требует полного восстановления тома или его пропуска. Следовательно, может быть разумным создание нескольких томов для резервной копии (например, отделение системных файлов от файлов данных). Тогда при восстановлении можно будет выбрать, восстанавливать ли только системный том (помеченный как необходимый) или все тома.

Практическое использование этих функций
Windows Vista представила значительные улучшения по сравнению с Windows XP в области защиты данных и системы в виде новых технологий резервного копирования и улучшения существующих функций. Четыре основных функции резервного копирования — резервное копирование и восстановление файлов, средство полного резервного копирования и восстановления компьютера Windows, восстановление системы и теневое копирование — предоставляют разные, но взаимоподдерживающие возможности, всемерно расширяя охват защиты данных. Знакомство с совместной работой этих функций важно для точной настройки системы на эффективное использование всех четырех методов и применение адекватной защиты и восстановления.
Опыт показывает, что в ситуации потери данных всегда следует начинать с попытки восстановления из теневой копии, поскольку этот метод, вероятно, предоставит наиболее новую из всех существующих копий данных. В случае нестабильности системы используйте восстановление системы. Полное восстановление компьютера желательно приберегать как последнее средство для полного восстановления системы и использовать с осторожностью. Тем не менее, полное восстановление компьютера может стать настоящим спасителем. Самое главное, действуйте, пока еще не поздно: создайте резервную копию немедленно!
Я хотела бы поблагодарить Эдуардо Лауреано (Eduardo Laureano), Ивана Пашова (Ivan Pashov), Джил Золлер (Jill Zoeller) и всех работников группы продуктов резервного копирования и восстановления за их помощь в написании этой статьи.

Кристина Фок (Christine Fok) работает руководителем программы в подразделении решений для хранения данных корпорации Майкрософт. Она специализируется на резервном копировании и восстановлении в клиентской платформе Windows.


 Windows Server: 11 незаменимых средств управления Active Directory
Windows Server Лора Хантер (Laura E. Hunter)

11 незаменимых средств управления Active Directory
Краткий обзор:
  • Создание объектов в командной строке
  • Выполнение пакетных операций в Active Directory
  • Обновления и обслуживание Active Directory

Те, кому приходилось иметь дело с такими вещами, как таблица Excel, перечисляющая 200 новых сотрудников, начинающих работать со следующей недели, или учетные записи пользователей, настроенные неверно, потому что кто-то в службе поддержки щелкнул то,
чего щелкать не следовало, а также те, кому интересен более простой способ управления Active Directory®, помимо открытия папок «Пользователи» и «Компьютеры» каждый раз, могут воспользоваться одним из бесплатных средств администрирования. Некоторые из них встроены прямо в операционную систему Windows®, некоторые поставляются в пакете Resource Kit или в наборе средств поддержки Windows, а некоторые являются бесплатной продукцией сторонних производителей. Что это за удобные средства и где их можно достать? Давайте выясним.
Начнем со встроенных средств командной строки в Windows Server® 2003, позволяющих создавать, удалять, модифицировать и искать объекты в Active Directory.

CSVDE
Средство CSVDE позволяет импортировать новые объекты в Active Directory, используя исходный CSV-файл; оно также дает возможность экспортировать существующие объекты в файл CSV. CSVDE нельзя использовать для изменения существующих объектов; при использовании этого средства в режиме импорта можно лишь создавать новые объекты.
Экспорт списка существующих объектов с помощью CSVDE довольно прост. Ниже показано, как экспортировать объекты Active Directory в файл под названием ad.csv:
csvde –f ad.csv
Параметр –f указывает, что за ним следует имя выходного файла. Но следует понимать, что, в зависимости от среды, этот базовый синтаксис может привести к выводу огромного и неудобного файла. Чтобы ограничить средство экспортом лишь объектов внутри определенного структурного подразделения (OU), команду можно изменить следующим образом:
csvde –f UsersOU.csv –d ou=Users,dc=contoso,dc=com
Предположим далее, что мне необходимо экспортировать лишь объекты пользователя в мой файл CSV. В таком случае можно добавить параметр –r, позволяющий указать фильтр протокола LDAP для данного поиска, который ограничит число экспортируемых атрибутов (заметьте, что все нижеследующее является одной строкой):
csvde –f UsersOnly.csv –d ou=Users,dc=contoso,dc=com –r
    "(&(objectcategory=person)(objectclass=user))" –l
    DN,objectClass,description
Параметр –i позволяет импортировать объекты в Active Directory из исходного файла CSV. Однако создание объектов пользователя с помощью CSVDE имеет один важный недостаток: с помощью этого средства нельзя устанавливать пароли пользователей, поэтому я бы не стала использовать CSVDE для создания объектов пользователей.

LDIFDE
Active Directory предоставляет второе встроенное средство для пакетных операций пользователей, именуемое LDIFDE и обладающее более широкими и гибкими возможностями, чем CSVDE. Помимо создания новых объектов, LDIFDE позволяет модифицировать и удалять существующие объекты и даже расширять схему Active Directory. Платой за гибкость LDIFDE является то, что необходимый входной файл (файл LDIF) с расширением .ldf использует более сложный формат, чем простой файл CSV. (Немного поработав, можно также настраивать пароли пользователей, но об этом чуть позже.)
Начнем с простого примера — экспорта пользователей в структурном подразделении в файл LDF (отметьте, что все нижеследующее является одной строкой ):
ldifde -f users.ldf -s DC1.contoso.com -d "ou=UsersOU,dc=contoso,dc=com"
       –r "(&(objectcategory=person)(objectclass=user))"
Как и в случае большинства средств командной строки, полное описание параметров LDIFDE можно получить, запустив команду LDIFDE /? . На Рис. 1 показаны те, что я использовала здесь. (Заметьте, что параметры для команд CSVDE и LDIFDE одинаковы.)
Figure 1 Параметры LDIFDE (Close Figure 1)

Параметр | Описание
-d | Указывает путь LDAP, к которому LDIFDE следует подключиться для выполнения операции.
-f | Указывает имя файла, который следует использовать, в данном случае, для вывода результатов экспорта.
-r | Указывает фильтр LDAP для использования при экспорте.
-s | Указывает контроллер домена (DC) к которому следует подключиться для выполнения операции; если не вводить этот параметр, LDIFDE подключится к локальному DC (или DC, проверившему подлинность, если средство используется с рабочей станции).
По-настоящему возможности LDIFDE раскрываются при создании объектов и управлении ими. Однако перед этим необходимо создать входной файл. Нижеследующий код создает две новых учетных записи пользователя — afuller и rking; для создания входного файла введите текст в блокноте (или другом редакторе открытого текста) и сохраните его как NewUsers.ldf:
dn: CN=afuller, OU=UsersOU, DC=contoso, DC=com
changetype: add
cn: afuller
objectClass: user
samAccountName: afuller

dn: CN=rking, OU=UsersOU, DC=contoso, DC=com
changetype: add
cn: rking
objectClass: user
samAccountName: rking
После того как создание файла завершено, запустите следующую команду:
ldifde –i –f NewUsers.ldf –s DC1.contoso.com
Единственный новый параметр здесь — это -i, который, как несложно догадаться, указывает, что выполняется операция импорта, а не экспорта.
При модификации или удалении существующих объектов синтаксис команды LDIFDE не меняется; вместо этого изменяется содержимое файла LDF. Для изменения поля описания учетных записей пользователей создайте текстовый файл, именуемый ModifyUsers.ldf, такой как показано на Рис. 2.
Рис. 2 Файл LDF ModifyUsers
Рис. 2 Файл LDF ModifyUsers
Изменения импортируются путем запуска того же синтаксиса команды LDIFDE, что и раньше, с указанием нового файла LDF после параметры -f. Формат LDF для удаления объектов еще проще; для удаления пользователей, с которыми вы работали, создайте файл, именуемый DeleteUsers.ldf, и введите следующее:
dn: CN=afuller OU=UsersOU, DC=contoso, DC=com
changetype: delete

dn: CN=rking, OU=UsersOU, DC=contoso, DC=com
changetype: delete
Отметьте, что, в отличие от CSVDE, LDIFDE может настраивать пароли пользователей. Однако перед настройкой атрибута unicodePWD для учетной записи пользователя необходимо настроить шифрование SSL/TLS на контроллерах домена.
Вдобавок, LDIFDE может создавать и модифицировать любые объекты Active Directory, а не только учетные записи пользователей. Например, нижеследующий файл LDF создаст новое расширение схемы, именеуемое EmployeeID-example, в схеме леса contoso.com:
dn: cn=EmployeeID-example,cn=Schema,
cn=Configuration,dc=contoso,dc=com
changetype: add
adminDisplayName: EmployeeID-Example
attributeID: 1.2.3.4.5.6.6.6.7
attributeSyntax: 2.5.5.6
cn: Employee-ID
instanceType: 4
isSingleValued: True
lDAPDisplayName: employeeID-example
Поскольку в файлах LDIFDE используется стандартный отраслевой формат файла LDAP, приложения от сторонних производителей, которым необходимо модифицировать схему Active Directory, часто поставляют файлы LDF, с помощью которых можно изучить и одобрить изменения, прежде чем применять их к производственной среде.
Помимо средств для операций пакетного импорта и экспорта, в состав Windows Server 2003 входит встроенный набор средств, позволяющий создавать, удалять и изменять различные объекты Active Directory, а также выполнять запросы к объектам, отвечающим определенным критериям. (Следует отметить, что данные средства, dsadd, dsrm, dsget, and dsquery, не поддерживаются Active Directory в Windows 2000.)

Dsadd
Dsadd используется для создания экземпляра класса объектов Active Directory в определенном разделе каталога. В число данных классов входят «пользователи», «компьютеры», «контакты», «группы», «структурные подразделения» и «квоты». У dsadd имеется общий синтаксис следующего вида:
dsadd <ObjectType> <ObjectDistinguishedName> attributes
Замечу, что каждый создаваемый тип объектов требует особого набора параметров, соотносящихся с атрибутами, доступными для этого типа. Эта команда создает один объект пользователя с различными заполненными атрибутами (отметьте, что все нижеследующее является одной строкой):
dsadd user cn=afuller,ou=IT,dc=contoso,dc=com
–samID afuller –fn Andrew –ln Fuller –pwd *
-memberOf cn=IT,ou=Groups,dc=contoso,dc=com "cn=Help Desk,ou=Groups,
dc=contoso,dc=com"
–desc "Marketing Director"
Параметр -memberOf требует полного различающегося имени (DN) каждой группы, к которой следует добавить пользователя, если его нужно добавить в несколько групп, можно добавить несколько DN, разделенных пробелами.
Если элемент, скажем DN группы «Служба поддержки», содержит пробел, этот элемент надо поместить в двойные кавычки. Если элемент, скажем структурное подразделение IT\EMEA, содержит обратную косую черту, эту черту нужно ввести дважды: IT\\EMEA. (Эти требования относятся ко всем средствам ds*.)
При использовании параметра -pwd * последует запрос на ввод пароля для пользователя в командной строке. Пароль можно указать внутри самой команды (-pwd P@ssword1), но тогда он будет отображен открытым текстом на экране или в любом текстовом файле либо файле сценария, в который вставлена команда.
Аналогично, можно создать объект группы и структурное подразделение при помощи следующих двух команд:
dsadd computer cn=WKS1,ou=Workstations,dc=contoso,dc=com
dsadd ou "ou=Training OU,dc=contoso,dc=com"

Dsmod
Dsmod используется для изменения существующих объектов, а работают с ним почти так же, как с dsadd, используя различные подменю и синтаксис, зависящие от типа изменяемого объекта. Нижеследующая команда dsmod изменяет пароль пользователя и модифицирует его учетную запись так, чтобы при следующем входе в систему ему был выдан запрос на смену пароля:
dsmod user "cn=afuller,ou=IT,dc=contoso,dc=com" –pwd P@ssw0rd1
    –mustchpwd yes
Чтобы увидеть, насколько похожи эти параметры, взгляните на синтаксис dsadd, используемый для создания пользователя с теми же настроенными атрибутами:
dsadd user "cn=afuller,ou=IT,dc=contoso,dc=com" –pwd P@ssw0rd1
    –mustchpwd yes
Очевидно, что, зная параметры для создания объектов при помощи dsadd, можно использовать их же для изменения пользователей при помощи dsmod.

Dsrm
Противоположностью dsadd является dsrm; как несложно вообразить, это средство используется для удаления объектов из командной строки. Базовый синтаксис dsrm достаточно прямолинеен: просто введите dsrm, а за ним — различающееся имя объекта, который следует удалить, примерно так:
dsrm cn=WKS1,ou=Workstations,dc=contoso,dc=com
По умолчанию dsrm выдаст запрос «Вы действительно хотите удалить этот объект?». Введите Y и нажмите кнопку Enter. Этот запрос можно отключить с помощью параметра –noprompt, но, очевидно, что в таком случае исчезнет шанс подтвердить перед удалением, что объект выбран верно,. Два дополнительных параметра могут быть полезны при удалении объекта-контейнера, то есть структурного подразделения, которое потенциально может содержать другие объекты. Следующая команда удаляет структурное подразделение TrainingOU и все содержащиеся в нем объекты:
dsrm ou=TrainingOU,dc=contoso,dc=com –subtree
А эта удаляет все дочерние объекты в TrainingOU, но не трогает само структурное подразделение:
dsrm ou=TrainingOU,dc=contoso,dc=com –subtree
    –exclude

Dsmove
Для перемещения или переименования объекта в Active Directory используется средство dsmove, но следует отметить, что его можно использовать лишь для перемещения объектов внутри домена. Для переноса объектов между доменами или лесами используйте средство переноса Active Directory Migration Tool (ADMT), бесплатно загружаемое с веб-узла Майкрософт. Dsmove полагается на два параметра, которые можно использовать отдельно или вместе. Даная команда изменяет фамилию в учетной записи пользователя Steve Conn:
dsmove "cn=Conn, Steve,ou=IT,dc=contoso,dc=com"
    –newname "Steve Conn"
Данная команда перемещает учетную запись Steve из структурного подразделения IT в подразделение Training:
dsmove "cn=Conn, Steve,ou=IT,dc=contoso,dc=com" –newparent
    ou=Training,dc=contoso,dc=com
Переименование и перенос можно произвести в рамках одной операции, указав оба параметра разом:
dsmove "cn=Conn, Steve,ou=IT,dc=contoso,dc=com" –newname
    "Steve Conn" –newparent ou=Training,dc=contoso,dc=com

Dsget и Dsquery
В состав набора средств командной строки ds* также входят два средства, используемые для запросов информации Active Directory, а не для создания или изменения объектов.
Dsget получает на входе различающееся имя (DN) объекта и выдает значение указанного атрибута или атрибутов. Dsget использует те же подменю, что dsadd и dsmod — «пользователь», «компьютер», «контакт», «группа», «структурное подразделение» и «квота».
Чтобы получить имя учетной записи SAM и код безопасности (SID) учетной записи пользователя, введите следующую команду (отметьте, что все нижеследующее является одной строкой):
dsget user cn=afuller,ou=IT,dc=contoso,dc=com
    –samAccountName –sid
Результаты будут подобны показанным на Рис. 3.
Рис. 3 Работа dsget
Рис. 3 Работа dsget
Dsquery возвращает список объектов Active Directory, отвечающих указанным критериям. Следующие параметры можно указать вне зависимости от используемого подменю:
dsquery <ObjectType> <StartNode> -s <Search Scope> -o <OutputFormat>
Dsquery может использовать следующие подменю, каждое со своим синтаксисом, для ObjectType: «компьютер», «контакт», «подсеть», «группа», «структурное подразделение», «веб-узел», «сервер» (следует отметить, что подменю сервера извлекает данные о контроллерах домена, а не о серверах в вашей среде), «пользователь», «квота» и «раздел». А если один из данных типов запросов не является тем, чем нужно, можно использовать подменю *, позволяющее ввести запрос LDAP свободной формы.
StartNode указывает местонахождение дерева Active Directory, в котором начнется поиск. Можно использовать конкретное DN, такое как ou=IT,dc=contoso,dc=com, или один из следующих описателей краткого пути: domainroot, начинающийся с корня определенного домена, или forestroot, начинающийся с корня корневого домена леса, используя сервер глобального каталога для выполнения поиска.
Наконец, параметр области поиска указывает, как средство dsquery должно производить поиск в дереве Active Directory. Опросы поддерева (вариант по умолчанию) обращаются к указанному StartNode и всем его дочерним объектам, одноуровневые опросы обращаются только к непосредственным дочерним объектам StartNode, и базовые опросы обращаются только к объекту StartNode.
Для лучшего понимания областей поиска представьте структурное подразделение (OU), содержащее как объекты пользователя, так и дочернее OU, которое также содержит дополнительные объекты. При использовании поддерева в качестве ообласти будет запрошено OU, все пользовательские объекты внутри него, дочернее OU и его содержимое. При одноуровневой области будет запрошены только пользователи, содержащие в OU, но не дочернее OU и его содержимое. При базовом запросе будет запрошено только само OU без запроса содержащихся в ней объектов.
Наконец, можно использовать выходной формат, чтобы контролировать форматирование результатов dsquery. По умолчанию dsquery возвращает различающиеся имена всех объектов, совпадающих с запросом, примерно так:
"cn=afuller,ou=Training,dc=contoso,dc=com"
"cn=rking,ou=ITTraining,ou=Training,dc=contoso,dc=com"
Чтобы запросить все объекты пользователей, содержащиеся в структурном подразделении IT и его дочерних OU, используйте следующее:
dsquery user ou=IT,dc=contoso,dc=com
Запрос можно сделать еще более точным, добавляя дополнительные параметры, такие как -disabled, возвращающий только отключенные учетные записи пользователей; -inactive x, возвращающий только пользователей, не подключавшихся в течении x или более недель; или -stalepwd x, возвращающий только пользователей, которые не меняли свои пароли в течении x или более дней.
В зависимости от числа объектов в каталоге может возникнуть необходимость указать параметр -limit x при запуске запроса. По умолчанию dsquery возвращает до 100 объектов, совпадающих с параметрами запроса; но можно указать и большее число, такое как -limit 500, или использовать -limit 0, чтобы dsquery возвратило все совпадающие объекты.
Можно также использовать другие подменю для выполнения полезных запросов других типов объектов. Рассмотрим следующий запрос, возвращающий каждую подсеть, определенную в «Active Directory — узлы и службы», и входящую в пространство адресов 10.1.x.x:
dsquery subnet –name 10.1.*
А следующую команду можно использовать для возвращения каждой подсети, находящейся на веб-узле Corp:
dsquery subnet –site Corp
С помощью очередного подменю можно быстро определить, сколько контроллеров домена в лесу настроено для работы серверами глобального каталога:
dsquery server –forest –isgc
Можно также использовать данный синтаксис, чтобы упростить определение контроллера домена в определенном домене, содержащего роль FSMO эмулятора основного контроллера домена (PDC):
dsquery server –hasfsmo pdc
Как и в случае с другими командами ds*, включающими подменю, все параметры, доступные в конкретном подменю dsquery, можно просмотреть, войдя в командную строку и введя dsquery user /?, dsquery computer /?, dsquery subnet /?, и так далее.
Дополнительным хитрым приемом является передача исходящих данных dsquery по конвейеру в другое средство, такое как dsmod, при помощи знака | (SHIFT+обратная косая черта при английской раскладке клавиатуры). К примеру, компания переименовала отдел из «Подготовка» во «Внутреннее развитие», и теперь нужно обновить поле описания каждого относящегося к этому отделу пользователя. Одной командной строкой можно запросить все объекты пользователей, имеющие поле описания «Подготовка», и затем заменить это поле описания для всего пакета следующим образом:
dsquery user –description "Training" | dsmod
    -description "Internal Development"

Некоторые находки от сторонних производителей
Поскольку Active Directory основана на стандартах LDAP, в ней можно создавать запросы и вносить изменения при помощи любого инструмента, понимающего LDAP. Многие сторонние поставщики выпустили платные средства для помощи в администрировании Active Directory, но порой можно найти и настоящие сокровища, которые распространяются бесплатно. Это, в частности, можно сказать про коллекцию, созданную обладателем звания MVP по службам каталогов Джо Ричардсом (Joe Richards) и доступной для загрузки на joeware.net/freetools. В ней можно найти многочисленные средства, служащие для решения различных задач. К трем из них я возвращаюсь постоянно — это adfind, admod и oldcmp.

Adfind и Admod
Adfind и admod подобны dsquery и dsmod; adfind является средством запроса с помощью командной строки для Active Directory, а admod может создавать, удалять или изменять объекты Active Directory.
В отличие от средств ds*, имеющих несколько подменю и различные параметры в зависимости от типа объекта, adfind и admod пользуются единым синтаксисом вне зависимости от типа выполняемого запроса или изменения. Базовый синтаксис для adfind:
adfind –b <Search Base> -s <Search Scope> -f <Search Filter>
    attributesDesired
Запрос различающегося имени и описания всех объектов компьютеров в домене будет выглядеть как:
adfind –b dc=contoso,dc=com –s subtree –f (objectclass=computer) dn
    description
Запрос всех объектов пользователей будет выглядеть как:
adfind –b dc=contoso,dc=com –s subtree –f "(&(objectcategory=person)
    (objectclass=user))" dn description
Отметьте, что за исключением запроса содержимого LDAP, синтаксис не менялся.
Работая с adfind, можно найти несколько сокращенных вариантов записи параметров, которые избавляют от лишней работы по вводу. Например, параметр -default может заменить -b dc=contoso,dc=com в предыдущем примере и провести поиск по всему домену; -gc ищет, основываясь на сборке мусора (GC), и возвращает всех пользователей в вашем лесу Active Directory. Параметр -rb также можно использовать для установки относительной базы для поиска; если, скажем, необходимо найти структурное подразделение «Подготовка» в домене phl.east.us.contoso.com, то можно заметно сэкономить время, просто указав –default –rb ou=Training, вместо –b ou=Training, dc=phl,dc=east,dc=us,dc=contoso,dc=com.
Adfind также может выполнять ряд функций расширенного поиска, которыми сложно управлять из командной строки без него, включая показанные на Рис. 4.
Figure 4 Параметры Adfind (Close Figure 4)

Параметр | Описание
-showdel | Запрашивает контейнер удаленных объектов на предмет объектов-захоронений.
-bit | Запрашивает по знакам операции над битами, такие как атрибут userAccountControl.
-asq | Выполняет запрос по атрибутам. Эта функция (которую нельзя воспроизвести в dsquery) может взять атрибут определенного объекта и провести запрос по нему.
-dsq | Передает результаты запроса adfind по конвейеру в dsmod или одно из прочих средств ds*.
Пример, использующий параметр -asq, будет запрашивать «Покажи мне членство в группах членов HelpDesk» следующим образом:
adfind –default –rb cn=HelpDesk,ou=IT –asq member memberOf
Admod, как следует из названия программы, используется для изменения объектов в Active Directory. Как и в случае adfind, в нем нет специализированных подменю со своими синтаксисами, которые надо запоминать; admod использует один и тот же синтаксис вне зависимости от типа обрабатываемого объекта. Admod также можно использовать для добавления, перемещения, переименования удаления и даже восстановления объектов путем простого добавления соответствующего параметра, скажем -add, -rm, -move, -undel. И точно так же, как в dsquery и dsmod, знак | можно использовать для передачи данных запроса adfind по конвейеру в admod.
Обратите внимание, что выполнение восстановления с помощью admod заключается в простой операции восстановления объекта-захоронения, в котором большинство атрибутов объекта уже удалено. Для полного восстановления объекта со всеми атрибутами потребуется провести принудительное восстановление объекта.

Oldcmp
Есть еще одно средство из коллекции программ Джо, которое я считаю незаменимой частью своего набора средств автоматизации: oldcmp, ищущее в базе данных Active Directory учетные данные компьютеров, которые не использовались в течение указанного числа недель, и способное проводить следующие действия:
  • создавать отчеты об учетных записях без каких-либо действий в их отношении;
  • отключать неиспользуемые учетные записи компьютеров;
  • перемещать учетные записи компьютеров в иное, заранее указанное, структурное подразделение;
  • полностью удалять учетные записи компьютеров.
Отмечу, что поскольку oldcmp может устроить серьезный разгром в каталоге, он снабжен несколькими встроенными функциями безопасности. Он не удаляет учетные записи, которые не были отключены ранее (если в командной строке вы не сказали: «Нет, я действительно хочу это сделать!»). Он не изменяет более 10 объектов за раз (если, опять же, обратное не указано особо), и он никогда не будет ничего делать с учетной записью компьютера контроллера домена.
К настоящему моменту Джо обновил oldcmp, так что он может выполнять подобные функции также и на учетных записях пользователей, которые не использовались в течение указанного отрезка времени.
Для небольшой среды Active Directory или среды, где работа идет лишь с одним-двумя дополнениями или изменениями за раз, средств с графическим интерфейсом, таких как «Active Directory — пользователи и компьютеры», может быть достаточно для повседневного администрирования, но при необходимости каждодневно добавлять или изменять большое количество объектов или простом желании найти более рациональное решение для задач администрирования переход на командную строку может намного ускорить процесс создания, изменения и удаления объектов в Active Directory. Как было показано выше, существует набор гибких и мощных бесплатных средств — как встроенных в Windows, так и распространяемых членами сообщества Active Directory. Любое из них способно намного повысить производительность работы администратора Active Directory, вместе же они становятся еще более важными для его повседневной работы.

Лора Хантер (Laura E. Hunter) является четырехкратным лауреатом премии Microsoft MVP в области средств для работы с сетью Windows Server. Она автор второго издания «Справочного руководства по Active Directory» (изд-во O'Reilly, 2006). Имея десять лет стажа в отрасли ИТ, Лора работает сейчас проектировщиком Active Directory в инженерно-технической фирме мирового уровня. Она также является обладательницей нескольких отраслевых сертификатов, а также часто выступает на встречах групп пользователей и отраслевых конференциях.


 Windows Server: Восстановление объектов-захоронений Active Directory
Windows Server Джил Киркпатрик (Gil Kirkpatrick)

Восстановление объектов-захоронений Active Directory
Краткий обзор:
  • Как удаленные объекты хранятся в Active Directory
  • Использование LDP и ADRESTORE для нахождения и восстановления объектов-захоронений
  • Атрибуты объектов и systemFlags

Вероятно, вы не любите об этом думать, но возможность случайной потери данных — это факт, и как специалист по ИТ вы должны быть готовы к любого рода сценариям восстановления. В номере за апрель 2007 журнала TechNet Magazine я рассказывал, как важно иметь план
для восстановления пользователей и групп Active Directory® . В этой статье, которую можно найти на веб-узле technetmagazine.com/issues/2007/04/ADRecovery, я рассмотрел механизмы связи объектов, репликации, удаления и принудительного восстановления. К сожалению, функция полномочного восстановления требует запуска контроллера домена (DC) в режиме восстановления службы каталогов (DSRM). Эта операция выводит контроллер домена из работы на весь период восстановления.
Вы должны знать о существовании другого подхода. Восстановление объектов-захоронений (не имеющее ничего общего с оживлением зомби) предоставляет единственно возможный способ восстановить удаленные объекты без вывода контроллера домена в автономный режим; кроме того, это единственный способ восстановить идентификационные данные удаленного объекта, такие как атрибуты objectGUID и objectSid. Этот подход прекрасно справляется с задачей повторного создания удаленного пользователя или группы и восстановления прежнего списка управления доступом (ACL), содержащим objectSid удаленного объекта. Имейте в виду, что восстановление объектов-захоронений имеет собственные определенные ограничения, о которых я расскажу позже, поэтому принудительное восстановление должно входить в число ваших приемов.
Восстановление объектов-захоронений впервые появилось в Active Directory в Windows Server® 2003 для упрощения восстановления определенных данных. Это свойство основано на том факте, что Active Directory хранит удаленные объекты в базе данных в течение определенного периода времени, перед тем как физически удалить их. В этой статье я подробно расскажу вам, как Active Directory удаляет и восстанавливает объекты, а также покажу, как можно восстановить удаленные объекты, используя стандартный набор инструментов Майкрософт.

Что такое объект-захоронение?
Когда Active Directory удаляет объект из каталога, он не удаляет его из базы данных физически. Вместо этого Active Directory помечает объект как удаленный, устанавливая для атрибута isDeleted объекта значение «истина», удаляя большинство атрибутов из объекта, переименовывая объект, а затем перемещая объект в специальный контейнер в контексте именования (NC) объекта под названием CN=Deleted Objects. Объект, который теперь зовется объектом-захоронением, невидим для обычных операций в каталогах. Он невидим в любых оснастках консоли управления Microsoft® (MMC), а большинство служебных программ протокола LDAP даже не знают о существовании этого объекта-захоронения. Объект-захоронение по существу может называться исчезнувшим. Однако данные все еще здесь — просто они невидимы. Зачем Active Directory хранит объекты-захоронения, или иными словами удаленные объекты, в базе данных?
Будучи невидимым для других процессов, объект-захоронение все еще видим для процесса репликации Active Directory. Для того чтобы убедиться в том, что удаление выполнено на всех контроллерах домена, содержащих удаленный объект, Active Directory реплицирует объект-захоронение на другие контроллеры домена. Таким образом, объект-захоронение используется для репликации удаления по всей среде Active Directory.

Время жизни объекта-захоронения
Active Directory обычно удаляет объект из каталога в ответ на операцию по удалению протокола LDAP или операцию по удалению диспетчера учетных записей безопасности (SAM). Эта операция называется исходным удалением и отличается от операции удаления, которая выполняется в процессе репликации Active Directory. В этой статье не рассматриваются динамические объекты, которые удаляются совершенно другим способом, а именно удаляются самой средой Active Directory, когда истекает срок их жизни (TTL).
Когда Active Directory получает задание на удаление, среда сначала делает проверку, чтобы убедиться, что объект можно удалить. Этот процесс совершенно необходим, поскольку он проверяет верность следующих критериев:
  • Для атрибута isDeleted объекта еще не установлено значение «истина». (Вы не можете удалить уже удаленный объект!)
  • Контрольный флаг «частный объект» дескриптора безопасности, зависящего от ресурса, не установлен в дескрипторе безопасности объекта. (Это недокументированное «свойство». Флаг частного объекта — это бит 1 байта Sbz1 структуры дескриптора безопасности.)
  • Бит «запретить удаление» (0x80000000) не установлен в атрибуте systemFlags объекта.
  • Для атрибута isCriticalSystemObject объекта не установлено значение «истина».
  • Дескриптор безопасности объекта дает соответствующие права доступа пользователю для удаления объекта. (Конкретнее, пользователю позволяют удалить сам объект и удалить дочерний объект из родительского объекта.)
  • Объект не является объектом перекрестных ссылок (objectClass = crossRef) для существующего контекста именования.
  • У объекта нет никаких подчиненных объектов. (Если операция удаления по протоколу LDAP включает идентификатор объекта управления «удалить дерево» по протоколу LDAP, Active Directory автоматически удалит подчиненные объекты, если их атрибут isCriticalSystemObject не установлен в значение «истина». Это защищает критические системные объекты от непреднамеренного удаления в ходе операции удаления объектов дерева. Разумеется, вы можете удалить эти объекты индивидуально.)
  • Объект не является критическим внутренним объектом (например, это не объект nTDSDSA для контроллера домена или не объекты заполнения для предшествующих объектов головных объектов NC).
Помимо того что все упомянутые критерии должны выполняться, Active Directory также должна находиться в соответствующем состоянии для выполнения удаления. Например, если Active Directory находится в процессе переименования домена, она не будет удалять доверительную учетную запись домена или объект перекрестных ссылок.
Если определено, что объект действительно может быть удален, Active Directory начинает переводить объект в состояние объекта-захоронения. Сначала Active Directory удаляет ненужные атрибуты объекта, оставляя лишь обозначенные на Рис. 1 и те, которые по схеме должны сохраняться у объекта-захоронения. (Дополнительные сведения об этом можно найти в разделе «Восстановление атрибутов объекта».) Затем она изменяет относительное различающееся имя (RDN) объекта на CN=<old RDN>\0ADEL:<objectGUID>, где \0A означает символ ASCII перевода строки, а <objectGUID> – это objectGUID, выраженный строкой. Атрибут lastKnownParent затем устанавливается на различающееся имя (DN) родительского контейнера объекта, а атрибут isDeleted устанавливается в значение «истина». Active Directory затем удаляет из объекта все атрибуты ссылок на предыдущий и следующий элемент. Наконец, если в атрибуте systemFlag объекта не установлен бит «не разрешать перемещение после удаления», Active Directory перемещает объект в контейнер CN=Deleted Objects для NC. (Дополнительные сведения приведены на врезке «Атрибут systemFlags и поведение объекта».)
Figure 1 Атрибуты, сохраненные в объекте-захоронении (Close Figure 1)

Жестко заданные для сохранения
attributeID
attributeSyntax
dnReferenceUpdate
dNSHostName
flatName
governsID
groupType
instanceType
lDAPDisplayName
legacyExchangeDN
mS-DS-CreatorSID
mSMQOwnerID
nCName
objectClass
objectGUID
objectSid
oMSyntax
proxiedObejctName
replPropertyMetaData
sAMAccountName
securityIdentifier
sIDHistory
subClassOf
systemFlags
trustPartner
trustDirection
trustType
trustAttributes
userAccountControl
uSNChanged
uSNCreated
whenCreated
Сохраняемые благодаря установке searchFlags
msDS-AdditionalSamAccountName
msDS-Auxiliary-Classes
msDS-Entry-Time-To-Die
msDS-IntId
msSFU30NisDomain
nTSecurityDescriptor
uid
Необходимо учитывать, что папка CN=Deleted Objects — плоская и не имеет иерархии объектов. Можно предположить, что при удалении двух разных объектов с одним CN могут возникнуть конфликты с именем. Этого не произойдет. Поскольку objectGUID включен в RDN каждого объекта-захоронения, RDN каждого объекта-захоронения является уникальным в рамках контейнера CN=Deleted Objects.
Очевидно, объекты не остаются в контейнере CN=Deleted Objects навсегда. По умолчанию срок жизни объекта-захоронения составляет 60 дней для лесов, построенных при помощи Windows® 2000 и Windows Server 2003, и 180 дней для лесов, построенных при помощи Windows Server 2003 SP1. Срок жизни объекта-захоронения можно изменить, установив атрибут tombstoneLifetime в объекте CN=Directory Service,CN=Windows NT, CN=Services, CN=Configuration, DC=<корневой домен>.
Каждые 12 часов контроллер домена начинает процесс сборки мусора. (Это можно изменить, установив новое значение для атрибута garbageCollPeriod объекта CN=Directory Service,CN=Windows NT, CN=Services, CN=Configuration, DC=<корневой домен>.) Сборщик мусора проверяет все объекты-захоронения на контроллере домена и физически удаляет те, чей срок жизни больше, чем срок жизни объектов-захоронений.

Использование LDP для поиска объектов-захоронений
LDP — это служебная программа, схожая с проводником Windows, для работы с Active Directory. LDP была изначально создана группой разработчиков Active Directory для тестирования кода протокола LDAP, когда Active Directory находилась в разработке. Теперь, будучи частью средств поддержки Windows Server 2003, LDP развилась в надежное средство для работы с Active Directory.
Хотя объекты-захоронения невидимы для обычных операций с каталогами, можно обнаружить объекты-захоронения в Active Directory, используя поисковые операции LDAP и специальные расширения протокола LDAP, называемые элементами управления. Элементы управления — это механизм, определяемый в стандарте LDAP и используемый для расширения протокола LDAP с целью обеспечения дополнительной функциональности помимо той, что определена в стандарте LDAP, сохраняя при этом совместимость с другими программами, поддерживающими LDAP. Active Directory поддерживает 22 элемента управления, включая элемент управления «Возврат удаленных объектов». Если этот элемент управления используется для расширения операции поиска LDAP, он выявляет удаленные объекты, которые в другом случае оставались бы невидимыми.
Чтобы продемонстрировать, как это работает, я войду в домен foo.local, используя учетные данные администратора предприятия, а затем воспользуюсь оснасткой ММС «Active Directory — Пользователи и компьютеры» (ADUC) для создания объекта пользователя (CN=John Smith,CN=Users,DC=foo, DC=local), как показано на Рис. 2. Затем, используя ADUC, я удаляю объект пользователя.
Рис. 2 Использование ADUC для создания пользователя
Рис. 2 Использование ADUC для создания пользователя
Теперь я могу запустить программу LDP и использовать ее для показа объекта-захоронения для удаленного пользователя. Первый этап — подключить LDP к определенному контроллеру домена и пройти проверку подлинности, используя соответствующие учетные данные. Для соединения с DC я использую пункт Connect (Подключить) из меню Connection (Подключение). Поскольку я запускаю LDP на контроллере домена, я просто нажимаю кнопку OK, чтобы подключиться к локальному контроллеру домена. Если вы запускаете LDP удаленно, вы должны указать имя контроллера домена, к которому нужно подключиться. После успешного подключения LDP показывает атрибуты rootDSE — сюда входят атрибуты, описывающие состояние и настройку самого контроллера домена (см. Рис. 3).
Рис. 3 LDP подключен к контроллеру домена
Рис. 3 LDP подключен к контроллеру домена
Теперь, чтобы пройти проверку подлинности на контроллеру, используя учетные данные администратора домена или предприятия, я выбираю Bind (Привязать) из меню подключения. Поскольку я уже вошел в сеть как администратор предприятия для леса (администраторы домена и администраторы предприятия по умолчанию имеют право выводить список и восстанавливать объекты в контейнере CN=Deleted Objects), я просто оставляю поля имени пользователя и пароля пустыми в диалоге привязки и нажимаю OK. В другой ситуации я могу ввести соответствующие учетные данные в диалогом окне привязки.
Далее я хочу вывести содержание контейнера CN=Deleted Objects,DC=foo=DC=local. Обычно увидеть контейнер CN=Deleted Objects нельзя, поскольку сам контейнер отмечен как удаленный. Единственный способ произвести поиск в контейнере CN=Deleted Objects — это использовать элемент управления протокола LDAP «Вернуть удаленные объекты».
Для использования этого элемента управления при помощи LDP перейдите в меню Browse (Обзор) и выберите Search (Поиск). Появится диалоговое окно поиска, показанное на Рис. 4. Поле Base Dn позволяет вам указать место в дереве каталогов, с которого следует начать поиск. Я ввожу DN контейнера Deleted Objects для домена – в данном примере DN – это CN=Deleted Objects,DC=foo,DC=local.
Рис. 4 Диалог поиска в LDP
Рис. 4 Диалог поиска в LDP
В поле фильтра я указываю критерий поиска для LDP. Класс по умолчанию — (objectClass=*), который дает поиску указание возвращать все объекты, у которых есть значение атрибута objectClass. Поскольку даже удаленные объекты в Active Directory имеют значение для objectClass, фильтр по умолчанию вернет каждый объект в области поиска. В этом примере я изменяю фильтр на (objectClass=user), ограничивая поиск только объектами-пользователями. Таким образом мне будет легче найти удаленного пользователя Джона Смита среди тысяч объектов-захоронений в контейнере CN=Deleted Objects.
Можно обнаружить, что в контейнере CN=Deleted Objects гораздо больше объектов, чем Active Directory может вернуть в результате одного поиска. Чтобы решить эту проблемы, можно использовать постраничный поиск LDAP, возвращающий результаты по группам. Тем не менее, LDP не позволяет указать одновременно постраничный и расширенный поиск. Поэтому придется поработать с фильтром LDAP, чтобы обнаружить нужный объект.
Переключатели Scope позволяют указать долю дерева каталогов для поиска. Начальный поиск вернет только объект, указанный при помощи поля Base Dn. Одноуровневый поиск вернет объекты, находящиеся в непосредственном подчинении объекту Base Dn. Поиск в поддереве вернет все объекты в подчинении объекту Base Dn. Поскольку папка CN=Deleted Objects плоская, я использую одноуровневый поиск для выявления всех объектов-захоронений.
Я сделал набросок обычного поиска LDAP. Если бы мне пришлось запускать его сейчас, программа LDP выдала бы ошибку, которая бы сообщала, что CN=Deleted Objects,DC=foo,DC=com не существует, поскольку он отмечен как удаленный. В поиск мне нужно включить элемент управления LDAP «Возврат удаленных объектов». Для этого я нажимаю кнопку Options (Параметры) в диалоговом окне поиска и выбираю Extended (Расширенный) для типа поиска, как показано на Рис. 5. Этот режим позволяет указать элементы управления для поиска. Кроме того, я изменяю список атрибутов на *. В результате LDP покажет все обычные атрибуты для каждого выявленного объекта вместо набора атрибутов, используемых в LDP по умолчанию.
Рис. 5 Поиск LDP Диалог Options (Параметры)
Рис. 5 Поиск LDP Диалог Options (Параметры)
Теперь я нажимаю кнопку Controls (Элементы управления), чтобы вывести диалог элементов управления. Диалоговое окно элементов управления LDP не очень удобное, поэтому внимательно выполняйте указания для добавления элемента управления «Вернуть удаленные объекты».
Откройте раскрывающийся список Load Predefined (Загрузить назначенное), выберите Return Deleted Objects (Вернуть удаленные объекты) и нажмите кнопку Check in (Вернуть с изменениями). Это добавит идентификатор объекта (OID) для элементу управления «Вернуть удаленные объекты» (1.2.840.113556.1.4.417) в списке активных элементов управления, как показано на Рис. 6. LDP затем добавляет элемент управления ко всем последующим операциям расширенного поиска. Нажмите кнопку OK, чтобы сохранить настройки элемента управления, и нажмите ОК еще раз, чтобы закрыть диалоговое окно параметров поиска.
Рис. 6 Добавление элемента управления «Вернуть удаленные объекты»
Рис. 6 Добавление элемента управления «Вернуть удаленные объекты»
Диалоговое окно элементов управления ведет себя весьма оригинальным способом. Например, даже если в списке активных элементов управления появляется OID, это не обязательно означает, что элемент управления активирован. Иногда необходимо взять элемент управления для изменения, а затем вернуть его после изменения снова, чтобы убедиться, что он будет использоваться в следующей операции протокола LDAP.
Теперь я готов к поиску. Я нажимаю кнопку OK в диалоговом окне поиска LDP, и LDP выводит все объекты пользователя из контейнера CN=Deleted Objects для этого домена. Результаты показаны на Рис. 7.
Рис. 7 Результаты из контейнера CN=Deleted Objects
Рис. 7 Результаты из контейнера CN=Deleted Objects

Анализ результатов LDP
Мой поиск выявил два объекта-захоронения. Во-первых, можно видеть DN первого объекта-захоронения: CN=John Smith\0ADEL:41800281-6bc4-42c3-a99b-b283022b3af8,CN=Deleted Objects,DC=foo,DC=local. objectGUID удаленного объекта представлен в виде строки (41800281-6bc4-42c3-a99b-b283022b3af8). Под DN расположен список атрибутов, показывающих значения для objectClass, cn, distinguishedName, и т.д. Видно, что значение атрибута isDeleted есть «истина», что означает, что объект на самом деле удален. Кроме того, видно, что в объекте-захоронении сохранен objectSid — это важно для восстановления объекта-захоронения пользователя и группы, о чем я расскажу дальше. Атрибут lastKnownParent, представляющий DN объекта, который содержал удаленный объект до того, как он стал объектом-захоронением, также очень важен для восстановления объектов-захоронений.
В моем примере LDP вывел два объекта-захоронения, оба из которых были объектами-пользователями, под названием CN=John Smith, изначально содержащимися в контейнере CN=Users,dc=foo,dc=local. Как могли два разных объекта с одним и тем же RDN появиться из одного и того же контейнера? Этому есть очень простое объяснение. Перед тем как запустить LDP на поиск объектов-захоронений, я создал объект пользователя CN=John Smith в контейнере CN=Users,DC=foo,DC=local и удалил его. Затем я создал еще один объект пользователя с такими же атрибутами и также удалил его. Поскольку я уже удалил первый объект пользователя CN=John Smith, было вполне разумным создать второй, несмотря на то, что у него было точно такое же имя. Однако это два отдельных, уникальных объекта, отличающиеся своими идентификаторами objectGUID. Поскольку Active Directory включает objectGUID в DN объекта-захоронения, они появляются как отдельные объекты в контейнере CN=Deleted Objects.

Как восстанавливается объект-захоронение
Active Directory предлагает механизм для восстановления объекта-захоронения до состояния нормального объекта. Это, по существу, функция восстановления для удаленных объектов. Функция представляет собой специально созданную операцию протокола LDAP по изменению, которая должна включать две конкретные модификации атрибута: она должна удалять атрибут isDeleted (а не просто устанавливать для него значение «ложь»), а также перемещать объект в другой контейнер, изменяя различающееся имя объекта. Новое различающееся имя обычно (но не обязательно) использует атрибут lastKnownParent в качестве контейнера и сохраняет то же RDN минус компонент \0ADEL:<objectGUID>, который был добавлен Active Directory при создании объекта-захоронения.
Перед восстановлением объекта-захоронения Active Directory производит проверку того, чтобы определенные необходимые условия являлись верными. Расширенное право доступа пользователя к восстановленному объекту-захоронению должно быть определено в дескрипторе NC контейнера NC, содержащего объект-захоронение. Пользователь не может восстанавливать свой собственный объект. Атрибут isDeleted объекта-захоронения должен быть установлен в значение «истина». Идентификатор безопасности (SID) владельца объекта, как определено в дескрипторе безопасности, должен иметь SID из одного из доменов леса или доверенного домена.
Если рассматриваемый объект находится в контексте именования конфигурации или схемы, в атрибуте systemFlags объекта-захоронения должны быть установлены биты FLAG_CONFIG_ALLOW_RENAME и FLAG_ CONFIG_ALLOW_MOVE. Если объект находится в контексте именования конфигурации или схемы с установленным флагом FLAG_CONFIG_ALLOW_LIMITED_MOVE, объект может быть перемещен только в контейнер с тем же прародителем — другими словами, объект должен сохранить своего прапрародителя после перемещения, а если объект находится в контексте именования домена или раздела приложения, то биты FLAG_DOMAIN_DISALLOW_RENAME и FLAG_DOMAIN_DISALLOW_MOVE не должны устанавливаться в атрибуте systemFlags объекта-захоронения.
Пользователь должен иметь право, как определено в дескрипторе безопасности, изменять RDN (обычно CN, но не всегда) и добавлять объект в новый родительский контейнер. Новый родительский контейнер должен иметь возможность быть старшим для objectClass объекта-захоронения, как определено в схеме. Хотя перемещения внутрь и за пределы системного контейнера обычно не разрешены (если только параметр реестра Unlock system поддерева не равен нулю), восстановление объекта-захоронения в системный контейнер допускается.
Восстановление объекта схемы не допускается ни при каких обстоятельствах. Это, тем не менее, не является большой проблемой, поскольку вы не можете законным образом удалить объект из контекста именования схемы.
Если все проверки прошли успешно и необходимые требования соблюдаются, Active Directory произведет следующие действия по восстановлению объекта-захоронения:
  • Атрибут isDeleted удаляется.
  • Если операция изменения не предписывает иного, objectCategory настраивается на наиболее конкретный objectClass, указанный в объекте-захоронении.
  • RDN изменяется, и объект записывается в новый родительский контейнер.
После восстановления у объекта будут те же атрибуты objectGUID и objectSid, которые были у него изначально. Это означает, что внешние ссылки на объект, например в ACL, не нужно перенастраивать, как в случае повторного создания удаленного объекта. Восстановленный объект выглядит и ведет себя точно так же, как до того, как он был удален. Существует, тем не менее, одно важное различие: в восстановленном объекте не будет атрибутов, которые не были сохранены в объекте-захоронении.

Использование LDP для восстановления объектов-захоронений
Атрибут systemFlags и поведение объекта
Атрибут systemFlags — это дополнительный атрибут, определенный для вершины класса, что делает systemFlags дополнительным атрибутом для каждого класса Active Directory. Это 32-разрядное целочисленная маска, контролирующая перемещение и удаление объекта. Вот краткое описание важных флагов.

FLAG_DISALLOW_DELETE (0x80000000)

Если этот флаг установлен, система не допустит удаления или перемещения объекта в другой домен.

FLAG_CONFIG_ALLOW_RENAME (0x40000000)

Объекты в контекстах именований конфигурации и схемы не могут быть переименованы, пока этот флаг не будет установлен в атрибуте systemFlags.

FLAG_CONFIG_ALLOW_MOVE (0x20000000)

Объекты в контекстах именований конфигурации и схемы не могут быть перемещены, пока этот флаг не будет установлен в атрибуте systemFlags.

FLAG_CONFIG_ALLOW_MOVE (0x20000000)

Объекты в контекстах именований конфигурации и схемы не могут быть перемещены, пока этот флаг не будет установлен в атрибуте systemFlags. Этот флаг налагает дальнейшие ограничения на целевой контейнер операции перемещения — целевой контейнер должен иметь того же прародителя, что и текущий контейнер.

FLAG_DOMAIN_DISALLOW_RENAME (0x08000000)

По умолчанию объекты в контексте именования домена или приложения могут быть переименованы. Однако если этот флаг установлен в атрибуте объекта systemFlags, система не позволит переименовать объект.

FLAG_DOMAIN_DISALLOW_RENAME (0x08000000)

По умолчанию объекты в контексте именования домена или приложения могут быть перемещены в другой контейнер. Однако если этот флаг установлен в атрибуте объекта systemFlags, система не позволит переместить объект.

FLAG_DISALLOW_MOVE_ON_DELETE (0x02000000)

Если этот флаг установлен, система не будет перемещать объект в контейнер CN=Deleted Objects его контекста именования. Он просто установит атрибут isDeleted, переименует объект и удалит атрибуты, не предназначенные схемой для сохранения. Это означает, что не все удаленные объекты появляются в контейнере CN=Deleted Objects для контекста именования; некоторые остаются в исходном родительском контейнере.

Теперь, когда я рассказал, как работают процессы восстановления, я хочу показать, как я использую LDP для восстановления пользователя CN=John Smith, которого я удалил. Сначала я подключусь к DC и пройду проверку подлинности. Теперь я могу выполнить операцию по изменению, используя LDP. В параметрах операции по изменению я могу удалить атрибут isDeleted и в то же время указать новое различающееся имя.
Поскольку я провожу операцию на объекте-захоронении, я должен указать элемент управления протокола LDAP «Вернуть удаленные объекты». Чтобы установить этот элемент управления для операции по изменению в LDP, в меню параметров выберите Controls (Элементы управления), затем выберите Return deleted objects (Вернуть удаленные объекты) в раскрывающемся списке Load Predefined (Загрузить назначенное), нажмите кнопку Check In (Вернуть после изменения) и нажмите кнопку ОК, чтобы сохранить параметры элемента управления.
Теперь я выбираю Modify (Изменить) в меню Browse (Oбзoр), чтобы открыть диалоговое окно изменения, и ввожу различающееся имя объекта-захоронения, который нужно восстановить. Самый простой способ сделать это — это скопировать и вставить различающееся имя из результатов поиска, который я проводил до этого.
Далее мне нужно ввести список операций с атрибутами для выполнения. Для восстановления объекта-захоронения необходимо выполнить две операции с атрибутами: удалить атрибут isDeleted и заменить атрибут distinguishedName желаемым различающимся именем восстановленного объекта-захоронения, поэтому я ввожу isDeleted в поле атрибута и выбираю кнопку-переключатель Delete (Удалить). Когда я нажимаю клавишу ВВОД, операция атрибута добавляется в лист ввода, как показано на Рис. 8.
Рис. 8 Указание операций с атрибутами
Рис. 8 Указание операций с атрибутами
Затем я ввожу различающееся имя в поле атрибута, выбираю кнопку-переключатель Replace (Заменить) и ввожу новое различающееся имя объекта в поле значений. В этом случае я использую оригинальное различающееся имя пользователя: CN=John Smith,CN=Users,DC=foo,DC=local. Когда я нажимаю клавишу ВВОД, операция изменения добавляется в список ввода.
Поскольку мне нужно включить элемент управления LDAP «Вернуть удаленные объекты» в операцию по изменению, я должен использовать расширенное изменение LDAP. Для этого я установлю флажок на расширение. После того как настройка произведена, как показано на Рисунке 9, я нажимаю кнопку Run, чтобы произвести изменения. LDP покажет результаты в большом текстовом окне.
Рис. 9 Изменить distinguishedName
Рис. 9 Изменить distinguishedName
Когда я возвращаюсь к оснастке ММС «Active Directory — пользователи и компьютеры» и заглядываю в контейнер CN=Users, я обнаруживаю, что однажды удаленный объект пользователя находится там, где и был. Однако у этого объекта будет несколько важных отличий от оригинального объекта, о которых я вскоре расскажу.

Использование ADRESTORE для восстановления объектов-захоронений
Как только вы поймете, как использовать LDP, восстановление объекта-захоронения станет делом очень несложным. Однако эта процедура не очень удобная. К счастью, умельцы из Sysinternals (компания, которая теперь входит в Майкрософт) разработали средство командной строки для упрощения процесса восстановления. Это средство под названием ADRESTORE можно загрузить с веб-узла Майкрософт по адресу microsoft.com/technet/ sysinternals/utilities/AdRestore.mspx. Его очень просто установить. Просто скопируйте исполняемый файл в соответствующий каталог на вашем компьютере, например C:\WINDOWS\SYSTEM32.
Программа ADRESTORE работает в двух режимах. При запуске без параметров она выведет список всех объектов-захоронений в контейнере CN=Deleted Objects домена по умолчанию. Можно добавить строку для поиска в командной строке, чтобы выбрать объекты для показа, например:
C:\> adrestore John
Результатом будут все объекты-захоронения в контейнере CN=Deleted Objects, которые содержат строку «John» в атрибуте CN или OU — программа использует поисковый фильтр LDAP cn=*John* и ou=*John*. Это не самый гибкий способ поиска объектов-захоронений, но во многих ситуациях он работает очень хорошо. На Рис. 10 показаны результаты поиска, возвращенного программой ADRESTORE.
Рис. 10 Атрибуты, сохраненные в объекте-захоронении
Рис. 10 Атрибуты, сохраненные в объекте-захоронении
Если нужно восстановить объект-захоронение, а не только найти его, необходимо указать параметр –r вместе с дополнительной строкой, например, вот так:
C:\> adrestore –r John
Эта команда предложит восстановить каждый подходящий объект-захоронение. ADRESTORE всегда восстанавливает объект в контейнер, указанный атрибутом lastKnownParent объекта-захоронения, нет никакого способа указать другой контейнер.
ADRESTORE предлагает удобный интерфейс командной строки для использования функции восстановления Active Directory. Хотя он не очень гибкий, его легче использовать, чем LDP. Тем не менее, ADRESTORE не решает двух основных проблем, связанных с восстановлением объектов-захоронений: восстановление атрибутов, удаленных из объекта во время удаления самого объекта, и восстановление объектов, удаленных из контекста именования конфигурации.

Восстановление атрибутов объекта
В плане восстановления данных восстановление объекта-захоронения имеет больше преимуществ, чем принудительное восстановление: восстановление объекта-захоронения не требует выведения контроллера домена в автономный режим, а восстановление объектов-захоронений гораздо лучше, чем простое воссоздание новой версии удаленного объекта. Если вы вновь создаете объект, он всегда будет иметь новые атрибуты objectGUID и objectSid (если это участник политики безопасности, такой как пользователь). В результате любые внешние ссылки на объект, такие как ACL, необходимо будет обновлять для отражения нового идентификатора объекта. Это может стать очень большой проблемой.
Некоторые атрибуты удаляются вместе с удалением объекта, и эти атрибуты не восстанавливаются вместе с восстановлением объекта-захоронения. Но Active Directory сохраняет основные атрибуты в объекте-захоронении, самые важные из которых — атрибуты, относящиеся к идентификации, такие как objectGUID и objectSid. Также по умолчанию сохраняются многие другие атрибуты (см. Рис. 1). Большинство жестко установленных для сохранения атрибутов не очень интересны, особенно при обсуждении восстановления удаленных объектов пользователя, однако можно указать дополнительные атрибуты для сохранения в объекте-захоронении, установив бит 3 (0x00000008) атрибута searchFlags соответствующего объекта attributeSchema object в схеме Active Directory. В некоторых атрибутах этот бит уже может быть установлен в схеме Windows Server 2003 R2 (они также показаны на Рис. 1).
Установка некоторых приложений может изменить бит 3 в searchFlags существующих атрибутов или даже добавить новые атрибуты, у которых установлен бит 3. Exchange Server, например, настраивает некоторые дополнительные атрибуты для сохранения в объекте-захоронении.
Active Directory не будет сохранять атрибуты ссылок вперед и назад в объекте-захоронении, даже если указать на необходимость этого в атрибуте searchFlags объекта схемы. В частности, Active Directory не сохраняет такие вещи, как атрибут членства в группе или атрибут пользователя memberOf attribute. Таким образом, восстановление объекта-захоронения не предоставляет возможности восстановления членства в группе в Active Directory, см. мою статью «Аварийное восстановление: Active Directory — пользователи и группы» на веб-узле technetmagazine.com/issues/2007/04/ADRecovery. Вам все равно придется найти альтернативный механизм для восстановления этой информации при восстановлении объектов-захоронений.
Если нужно использовать восстановление объектов-захоронений в качестве части стратегии восстановления данных, нужно либо убедиться в том, что основные атрибуты сохранены в объекте-захоронении, либо найти другой способ сохранить и восстановить важные атрибуты, например, использовать LDIFDE или другую схему резервного копирования или восстановления. Другие варианты включают продукты по восстановлению данных Active Directory от сторонних производителей, предлагающие автоматический механизм по копированию и восстановлению атрибутов, которые не сохраняются и не восстанавливаются из объекта-захоронения.

Восстановление объектов из контекста именования конфигурации
Еще одним существенным ограничением при восстановлении объектов-захоронений является то, что нельзя восстанавливать объекты, удаленные из контекста именования конфигурации. Эти объекты подчиняются особенным правилам в отношении перемещения и переименования, как определено в атрибуте объекта systemFlags. Если иное не указано в атрибуте systemFlags, объекты в контексте именования конфигурации не могут перемещаться или переименовываться, что означает, что их объекты-захоронения не могут быть восстановлены. Active Directory обеспечивает определенные значения для атрибута systemFlags, когда создает объекты конкретных классов, как показано на Рис. 11. Обратите внимание на то, что Active Directory применяет побитовую логическую операцию ИЛИ к этим значениям в сочетании с любым значением systemFlags, указанным в операции добавления. Таким образом, даже если в приложении указано другое значение для атрибута systemFlags, необходимые биты будут установлены правильно.
Figure 11 Параметры systemFlags по умолчанию (Close Figure 11)

Класс | Параметр по умолчанию
server | FLAG_DISALLOW_MOVE_ON_DELETE FLAG_CONFIG_ALLOW_RENAME FLAG_CONFIG_ALLOW_LIMITED_MOVE
site | FLAG_DISALLOW_MOVE_ON_DELETE
serversContainer | FLAG_DISALLOW_MOVE_ON_DELETE
nTDSDSA | FLAG_DISALLOW_MOVE_ON_DELETE
siteLink | FLAG_CONFIG_ALLOW_RENAME
siteLinkBridge | FLAG_CONFIG_ALLOW_RENAME
nTDSConnection | FLAG_CONFIG_ALLOW_RENAME
Единственными объектами в контексте именования конфигурации, которые можно восстанавливать при нормальных обстоятельствах, являются серверные объекты. Интересно, что когда Active Directory удаляет серверный объект, объект-захоронение не перемещается в контейнер CN=Deleted Objects для контекста именования конфигурации; объект-захоронение просто остается там, где находится объект. Это позволяет средству проверки согласованности знаний (KCC), являющемуся процессом, ответственным за расчет топологии репликации Active Directory, автоматическое восстановление в определенных ситуациях, где удаленные серверные объекты могли препятствовать правильной репликации, поэтому, если вы пытаетесь восстановить серверный объект, помните, что вы не найдете его в контейнере CN=Deleted Objects.

Восстановление объектов-захоронений в плане восстановления
Восстановление объектов-захоронений должно быть основной частью вашего набора средств по восстановлению данных. Этот механизм — единственный способ восстановить удаленные объекты без вывода контроллера домена в автономный режим и, что не менее важно, это единственный способ восстановить идентификационную информацию удаленного объекта. Это очень хорошо решает проблему восстановления удаленного пользователя или группы и последующего постановлениях старых ссылок ACL.
Однако восстановление объекта-захоронения — это лишь часть решения. Вам необходимо обеспечить собственный механизм для восстановления атрибутов, которые Active Directory не сохраняет в объектах-захоронениях, при этом ваша способность восстанавливать удаленные объекты из контекста именования конфигурации остается ограниченной. Помните, что, если вы решили восстановить удаленного пользователя или группу, вам все равно придется восстанавливать членство в группе и любые другие связанные атрибуты, которые могут вам понадобиться.

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


 Связь: Объединяя пользователей с помощью Office Communications Server 2007
Связь Алан Мэддисон (Alan Maddison)

Объединяя пользователей с помощью Office Communications Server 2007
Краткий обзор:
  • Архитектура Office Communications Server
  • Возможности проведения конференций
  • Enterprise Voice
  • Расширенное присутствие

Эра единого общения наступила. Грядущий выпуск Office Communications Server 2007 полностью изменит ваше представление об общении, которое было доступно через Live Communications Server 2005. Дополнительно к улучшениям архитектуры и администрирования в составе Office
Communications Server 2007 имеется новый клиент — Office Communicator. Также добавлены новые функции: Enterprise Voice, веб-конференции, расширенное присутствие (enhanced presence), обмен мгновенными сообщениями и федерация (federation). Все эти функции вместе создают платформу для стратегии Microsoft® Unified Communication (Единое общение) и обещают повысить производительность и улучшить совместную работу на расстоянии в вашей организации.
Данное обновление также включает модернизированный интерфейс консоли управления (Microsoft Management Console, MMC). На рис. 1 показано одно из усовершенствований счетчиков производительности.
Рис. 1 В новую оснастку консоли управления (MMC) включены счетчики производительности
Рис. 1 В новую оснастку консоли управления (MMC) включены счетчики производительности
Новый Office Communications Server 2007 доступен в 2 выпусках: Standard и Enterprise. Office Communications Server 2007 Standard идеален для развертываний, в которых участвуют менее 10 000 пользователей. В выпуске Standard развертыванием является единственный сервер клиентского доступа, на котором будут размещены все службы.
Для более крупных развертываний доступен выпуск Enterprise, он может быть развернут в консолидированной или расширенной конфигурации. При консолидированной топологии все оборудование организовано в виде единого пула серверов клиентского доступа. Чтобы достичь максимальной масштабируемости, можно использовать расширенную конфигурацию. Она позволяет использовать выделенные веб-серверы с Internet Information Services (IIS), веб-конференции и серверы для аудиовизуальных (A/V) конференций вне пула серверов клиентского доступа. На рис.2 показана топология расширенной конфигурации.
Рис. 2 Топология расширенной конфигурации
Рис. 2 Топология расширенной конфигурации

Архитектура
Архитектура Office Communications Server 2007 построена на основе следующих серверов: серверов клиентского доступа, пограничных серверов и серверов приложений. Серверы клиентского доступа обеспечивают проверку подлинности пользователей, поддержку адресных книг, управление присутствием, конференциями и размещением приложений, а также обработку сигналов между клиентами и серверами, управление информацией (включая общие файлы) и маршрутизацию мгновенных сообщений и трафика конференций.
Основная функциональность Office Communications Server 2007 обеспечивается серией объединенных серверов, известных под названием «блоки многоточечного управления» (multipoint control units, MCUs). На рис. 3 дано описание этих серверов и показана их роль.
Figure 3 Серверы конференций и их функции (Close Figure 3)

Серверы конференций (блоки многоточечного управления) | Поддерживаемая функциональность
Мгновенные сообщения | Позволяет обмениваться мгновенными сообщениями в группе, распределяя трафик мгновенных сообщений между участниками. Встроены в сервер клиентского доступа и не могут быть установлены на отдельном сервере.
Телефония | Поддерживает входящие и исходящие звонки. Встроена в сервер клиентского доступа и не может быть установлена на отдельном сервере.
Веб | Отвечает за функциональность совместной работы, такую как рисование на доске, совместное использование приложений и сеансы ответов на вопросы. Этот сервер также поддерживает совместное использование документов Office и презентаций PowerPoint. Может быть установлен на сервере клиентского доступа или в конфигурации расширенного пула на отдельном сервере.
Аудио/видео | Используется для смешивания аудио/видео и ретрансляции. Может быть установлено на сервере клиентского доступа или в конфигурации расширенного пула на отдельном сервере.
Еще одной важной функцией серверов клиентского доступа является размещение сервера адресной книги. Те из вас, кому знаком Live Communications Server 2005 с пакетом обновления 1 (SP1), узнают данную службу. В Office Communications Server 2007 она играет центральную роль и теперь уже не является дополнительным компонентом. Сервер адресной книги состоит из двух частей: службы адресной книги и хранилища файлов адресной книги. Этот сервер отвечает за получение контактной информации из внутренних и внешних источников. Глобальный список адресов, списки рассылки из Active Directory® и Exchange Server являются типичными примерами внутренних источников. В число внешних источников входят пользователи федеративных партнеров или общие контакты обмена мгновенными сообщениями.
Office Communications Server 2007 расширяет возможности по подключению внешних пользователей, представленные в Live Communications Server 2005, и дает возможность внешним пользователям участвовать в локальных конференциях. Данная дополнительная функциональность требует наличия двух новых пограничных серверов: пограничного сервера для веб-конференций и пограничного сервера для аудиовизуальной информации. Другое изменение: то, что раньше было прокси-сервером доступа, теперь называется пограничным сервером доступа. Пограничные серверы Office Communications Server разработаны для размещения в периметре вашей сети (промежуточной подсети) и обеспечения подключения внешних пользователей. На рис. 4 дано описание ролей пограничных серверов и показано, для чего они используются.
Figure 4 Роли пограничных серверов (Close Figure 4)

Сервер | Поддерживаемая функциональность
Пограничный сервер доступа | Федерация, связь с удаленными пользователями, Public IM Connectivity (PIC).
Пограничный сервер веб-конференций | Внешние веб-конференции.
Аудиовизуальный пограничный сервер | Аудиовизуальные конференции и двухточечные аудиовизуальные звонки между удаленными пользователями.
Обратный прокси-сервер | Расширение групп, загрузка файла адресной книги, доступ веб-конференции к содержимому встречи. Не совсем роль Office Communications Server, но предоставляет критическую функциональность. ISA Server 2006 также может предоставить функциональность обратного прокси-сервера.
В дополнение к объединенным серверам, описанным выше, Office Communications Server использует различные серверы приложений, которые позволяют выполнять такие необходимые функции, как проверка подлинности, хранение метаданных конференций, предоставление функциональности списков рассылки. В число приложений, которые обычно работают совместно с Office Communications Server, включают IIS, серверы сертификатов, серверы глобального каталога из вашей среды Active Directory, SQL Server® 2005, Exchange Server 2007 и файловые серверы.
IIS используется для доступа к информации о встречах, обновлениям адресной книги, расширениям групп рассылки Active Directory для мгновенных сообщений, расширениям списков рассылки для внешних пользователей Outlook® и для обеспечения лежащей в основе связи между компонентами Office Communications Server.
Серверы сертификатов играют важную роль в Office Communications Server , обеспечивают безопасность взаимоотношений клиент-сервер и сервер-сервер. Если вы пользуетесь внутренним сервером сертификатов предприятия, все внешние клиенты и серверы должны доверять выпускающему центру сертификации. Таким образом, каждый сертификат центра сертификации должен быть установлен в доверенное корневое хранилище на каждом компьютере. Если вы пользуетесь службами федерации Office Communications Server, то ваши организации-партнеры должны поступать также.
Проверка подлинности участников конференции поддерживается сервером глобального каталога в вашей среде Active Directory. Для внешних и федеративных пользователей ваши серверы глобального каталога будут использовать Kerberos для проверки подлинности. Удаленные пользователи, которые работают на вашу компанию, будут использовать свои учетные записи Active Directory через NTLM, а анонимные пользователи будет аутентифицированы с помощью дайджест-проверки подлинности.
SQL Server 2005 используется для поддержки данных состояния о конференциях, регистрации пользователей и информации о присутствии. В случае сбоя вы имеете возможность восстановить встречу с помощью данных, сохраненных в базе данных SQL Server, таким образом обеспечив быстрый и надежный способ восстановления без потери содержимого.
Exchange Server 2007 и возможности единого обмена сообщениями являются важным дополнением к Office Communication Server 2007, добавлены возможности голосовых сообщений и секретарь.
Файловые серверы используются для хранения данных, доступ к которым необходим клиентам. Например, физические файлы, необходимые клиентам при загрузке адресной книги, хранятся на файловом сервере. Аналогично, дополнительная информация о встрече хранится на файловом сервере.
Архитектура протоколов Office Communications Server 2007 основана на сочетании стандартных протоколов Интернета и протоколов Майкрософт. Например, Session Initiation Protocol (SIP) применяется для такой функциональности, как мгновенные сообщения, конференции и подписки присутствия. Протоколы, используемые различными компонентами Office Communications Server, обеспечивают максимум производительности и гибкости. На рис. 5 дано описания этих базовых протоколов и их использования.
Figure 5 Протоколы и их использование (Close Figure 5)

Протокол | Поддерживаемая функциональность
HTTP | Клиентский доступ, загрузка содержания встречи, данные адресной книги. Также используется для связи между серверами конференций и Focus, компонентом Office Communications Server.
SIP | Создание сеансов и управление ими при помощи различных компонентов Office Communications Server, включая Enterprise Voice, IM, серверы конференций и расширенное присутствие.
CCCP | Протокол используется для установления конференций и управления конференциями и клиентами.
PSOM | Протокол используется для передачи содержания веб-конференций, включая ключи безопасности, роли и пользователей.
RTP | Передача данных в реальном времени. В Office Communications Server 2007 предоставляет транспортный механизм для Enterprise Voice и аудиовизуальных конференций.
SRTP | Службы безопасности: шифрование, проверка подлинности сообщений и интеграция с данными RTP. В Office Communications Server 2007 он используется для защищенной передачи на мультимедийные устройства (микрофоны и колонки).
RTCP | Используется вместе с SRTP для передачи информации о качестве сигнала аудиовизуальных конференции между мультимедийными устройствами.

Enterprise Voice
Enterprise Voice — реализация корпорацией Майкрософт телефонии VoIP (Voice over Internet Protocol ). Enterprise Voice является самым значительным дополнением в продукте. Решение Enterprise Voice, основанное на реализации, использующей протокол Real Time Protocol (RTP) для голосового трафика и протокол Session Initiation Protocol (SIP) для передачи сигналов, позволяет совершать звонки как между компьютерами, так и на стационарные телефоны. Кроме того, Enterprise Voice предоставляет возможности управления вызовом, маршрутизации вызова и нормализации номера. Поддерживается коммутируемая телефонная сеть общего пользования (КТСОП), совместная работа с УАТС, которые поддерживают либо SIP, либо Computer-Supported Telecommunications Applications (CSTA), или обращаются напрямую к интерфейсу API Office Communications Server.
Office Communications Server 2007 может быть развернут без существенных изменений в имеющейся голосовой инфраструктуре, в то же время предоставляя огромные преимущества. Enterprise Voice поддерживает 3 настройки развертывания: SIP–УАТП, SIP–IP–УАТП и IP-КТСОП.
При настройке SIP–УАТС все удаленные звонки управляются УАТС, вы сохраняете ваши существующие телефоны. Такая интеграция возможна благодаря использованию шлюза удаленного управления звонками (Remote Call Control, RCC) и CSTA.
Настройка SIP–IP–УАТП включает в себя преимущества шлюза IP-КТСОП, который устраняет необходимость в CSTA и позволяет клиенту Office Communicator набирать номера и управлять телефоном IP-УАТП. Если у вас нет телефонных трубок, вы можете настроить Office Communicator как «программный телефон».
Если вы развернете Office Communications Server 2007 с компонентой IP-КТСОП, вы получите возможность направить управление звонками на серверы клиентского доступа. Office Communicator может взаимодействовать с конечными точками VoIP или конечными точками SIP сторонних производителей, сертифицированными Майкрософт (в большинстве организаций такими конечными точками являются телефоны), это позволяет делать и принимать звонки через Интернет.
Медиашлюзы являются шлюзами сторонних производителей, которые осуществляют передачу сигналов и преобразование между VoIP и КТСОП. Office Communications Server 2007 поддерживает три вида медиашлюзов: основной, усовершенствованный и основной гибридный. Чтобы поддержать шлюзы, отличные от усовершенствованного, Office Communications Server 2007 предлагает роль сервера-посредника (Mediation Server), обеспечивающего работу критических протоколов и преобразование информации. Интеграция с удаленным офисом также возможна с использованием компонентов в составе Office Communications Server.
Что касается других компонентов Office Communications Server 2007, здесь Enterprise Voice использует пограничные серверы, что обеспечивает связь со внешними пользователями. В частности, требуется пограничный сервер доступа (его роль в передаче сигналов SIP) для пользователей вне корпоративной сети, а аудиовизуальный пограничный сервер дает возможность внешним пользователям подключаться через службы периметра сети, такие как брандмауэр и реализации NAT (Network Address Translation).
Несмотря на то, что Enterprise Voice будет поддерживаться множеством клиентов, в данный момент мы рекомендуем использовать последний выпуск Office Communicator. Кроме того, корпорация Майкрософт и ее партнеры объявили о планах по созданию нового оборудования для VoIP, которое будет интегрировано с Office Communications Server.
Вдобавок Enterprise Voice объединен с единой системой обмена сообщениями Exchange Server 2007, предлагая единый интерфейс для голосовой почты, электронной почты, календарей, контактов и получения факсов, которые доступны либо по телефону при помощи Outlook Voice Access, либо через компьютер. Дополнительно единая система обмена сообщениями предоставляет услуги электронного диспетчера, который позволяет внедрить автоматическую систему голосового меню.

Расширенное присутствие
Концепция присутствия, с которой вы можете быть знакомы из Live Communications Server 2005, дополнена и расширена в Office Communications Server 2007. В общем, присутствие ассоциируется с состоянием и доступностью пользователей. В Office Communications Server поддерживающая инфраструктура создала богатую гамму событий с улучшенными деталями, позволяющими настраивать информацию, связанную с присутствием.
У пользователей появилась возможность выбрать из шести разных состояний: в сети, занят, не беспокоить, отошел, недоступен, отключен. У пользователей также есть возможность добавлять в состояние дополнительные сведения. Например, если у пользователя установлено состояние «не беспокоить», он может указать причину, почему его нельзя беспокоить.
Расширенное присутствие также позволяет пользователям фильтровать информацию, которая отображается другим пользователям. Это можно сделать, используя пять дополнительных уровней присутствия: личное, участники групп, рабочее место, общедоступное и блокировать. Эти уровни открывают иерархический подход к управлению присутствием. Например, уровень присутствия «Личное» предоставляет контактам наибольшую гибкость, разрешая такие действия, как общение через обмен мгновенными сообщениями, когда состояние пользователя «занят». Уровень присутствия также управляет тем, какое количество информации отображается контактам.
Более того, при использовании Office Communicator пользователь может указать свое местоположение, которое может быть или произвольным, или из определенного набора адресов. Информация о местонахождении доступна контактам из групп «личные» или «команда».
Усовершенствования в присутствии, несомненно, приветствуются, и они покажут свою состоятельность в сфере оптимизации коммуникаций, однако наибольшее влияние на организации окажет инфраструктура Office Communications Server и механизм присутствия. Например, Office Communications Server 2007 поставляется в комплекте с членской веб-частью и веб-частью Office SharePoint Server 2007, которые позволяют пользователям просматривать присутствие других пользователей, связанных с веб-узлом или порталом SharePoint. Эта веб-часть может быть легко добавлена к вашим веб-узлам SharePoint, чтобы облегчить размещение сведений о присутствии в важнейшей инфраструктуре совместной работы.
Информация о присутствии встроена в весь пакет Microsoft® Office 2007 через использование рабочих областей документов и кнопок действий смарт-тегов. Например, кнопки смарт-тегов могут отображать состояние, сведения о контакте и календаре пользователей. Пользователи могут применять смарт-теги для того, чтобы совместно выполнять работу, назначать встречи или начинать общение с помощью мгновенных сообщений.

Локальные конференции
Еще одно существенное улучшение в Office Communications Server 2007 — это наличие локальных конференций. Возможность проводить конференции в реальном времени со внутренними или внешними пользователями (анонимными или федеративными) — необходимая вещь во многих организациях. Эти конференции могут быть запланированы или происходить спонтанно, могут включать в себя конференции с использованием мгновенных сообщений, аудио/видеоконференций и веб-конференций, а также другие средства совместной работы: совместное использование файлов, доску для рисования, аннотации к слайдам, опросы участников и сеансов ответов на вопросы. Office Communications Server также поддерживает переходы от одного типа конференции к другому. К примеру, пользователь имеет возможность добавить совместную работу к существующему сеансу общения с помощью мгновенных сообщений и тем самым создать спонтанную конференцию.
Office Communicator является рекомендованным клиентом для конференций, Office Communications Server 2007 также поддерживает Office Live Meeting 2007 и надстройку Office Live Meeting для Outlook 2007. Office Communicator 2007 поддерживает мгновенные сообщения, участие в аудиовизуальных сеансах, совместное использование приложений, доску для рисования и передачу файлов. Office Live Meeting 2007 включает поддержку конференций, а также запланированных сеансов, записываемых сеансов, опросов участников и сеансов ответов на вопросы.
Надстройка Office Live Meeting 2007 для Outlook 2007 включает поддержку конференций с помощью Outlook 2007, а также возможность назначать индивидуальных пользователей участниками или докладчиками и позволяет отправлять различные приглашения в соответствии с ролью. В дополнение к пользователям с ролями организатора, докладчика или участника, их можно разбить на категории по принадлежности к внешним или внутренним группам пользователей по их местоположению или учетным записям. У внешних пользователей есть имя для входа Active Directory, и они находятся в корпоративной сети. Внешние пользователи подразделяются на три категории: удаленные, федеративные и анонимные.
Удаленный пользователь — это пользователь с учетной записью Active Directory внутри организации. Это может быть удаленный работник или подрядчик. Все удаленные пользователи могут проводить, подключаться и презентовать конференции.
У федеративных пользователей имеются учетные записи, определенные создателями федерации внутри Office Communications Server. Федеративные пользователи могут посещать встречи, выступать в роли докладчиков, но они не могут организовывать встречи.
Анонимные пользователи являются самой ограниченной в правах группой, они могут только посещать встречи, на которые пригласили.
Чтобы обеспечить дополнительный уровень безопасности для каждой встречи, есть возможность указать различные типы параметров управления входом. Office Communications Server 2007 предоставляет следующие типы собраний: открытые с проверкой подлинности, закрытые с проверкой подлинности и анонимные.
Открытое собрание с проверкой подлинности позволяет подключиться всем удаленным или внутренним пользователям с учетной записью Active Directory. Любой федеративный пользователь может также присоединиться к собранию. В закрытом собрании с проверкой подлинности могут участвовать только пользователи, приглашенные организатором встречи. Федеративные пользователи не могут участвовать в собрании такого типа.
Анонимное собрание открыто для всех, кто получил приглашение. Для того чтобы подключиться, пользователь должен предоставить ключ конференции и пройти дайджест-проверку подлинности. Анонимный пользователь может быть только участником, если не запросил у организатора другую роль после подключения. Некоторые доступные параметры показаны на рис. 6.
Рис. 6 Параметры собраний
Рис. 6 Параметры собраний

Набор номера
Оптимизируя общение, объединяя различные среды передачи данных, предоставляя управление пользователю, Office Communications Server 2007 может революционизировать метод работы компании. Основой революции будет концепция контекстуальной связи, где и сведения о присутствии, и средства для общения встроены в одно приложение. Если Office Communications Server 2007 еще нет в вашем отделе, ему следует там быть.
Дополнительные сведения об Office Communications Server 2007 и его бета-выпуск доступны на TechNet Office System TechCenter по адресу technet.microsoft.com/en-us/office/bb267356.aspx. Также не забудьте посетить блог группы единого общения по адресу blogs.technet.com/uc.

Алан Мэддисон (Alan Maddison) является старшим консультантом в MTI Technology Corporation. Его основной специализацией являются Active Directory, Exchange Server и виртуализация.


 От редактора: Пути к знаниям
От редактора
Пути к знаниям
Джошуа Трупин (Joshua Trupin)

В течение всей нашей издательской истории мотивом сентябрьских выпусков было своего рода «начало учебного года». Мы, конечно, сознаем, что временное совпадение не всегда идеально. Например, в значительной части Соединенных Штатов учебный год начинается в конце августа. А некоторые люди, похоже, никогда не перестают учиться.
Но у большинства из нас сентябрь вызывает нужные ассоциации. А TechNet Magazine – высшая школа, присваивающая степень специалиста по ИТ. Ладно, это мы просто выдумали. Но знания, даваемые нашим журналом, – это совсем не выдумки. В этом месяце мы представляем настоящую учебную программу.
Как и все приличные высшие образовательные заведения, мы предлагаем разнообразный набор учебных программ от вводных курсов SQL для любителей сценариев (в разделе «Эй, сценарист!») до обзора средств управления Active Directory.
Наши занятия промежуточного уровня включают дипломный учебный курс по Windows Vista. Сперва рассказывается, как развертывать Windows, используя пакет Business Desktop Deployment (BDD 2007). Затем, когда Windows Vista развернута на предприятии, можно воспользоваться инструкциями по применению регулярного резервного копирования на охваченных системах с обзором ряда ключевых технологий, доступных в настоящее время.
Затем, по мере приближение к диплому специалиста по ИТ, читатель сможет воспользоваться нашей высокоуровневой курсовой работой по Active Directory. Те, кто задумывался о восстановлении объектов-захоронений, но не хочет ждать нашего специального выпуска на Хеллоуин, могут начинать раскапывать могилы уже в этом месяце.
TechNet Magazine, само собой, – лишь один путь к знаниям. Веб-узел Microsoft TechNet предлагает дополнительные курсы заочного обучения. TechNet может похвастаться сотнями веб-трансляций на тему технологий, ключевых для специалистов по ИТ, включая показ того, как отдел ИТ Майкрософт использует их у себя. Предлагаемые веб-трансляции разбиты по типу аудитории (специалисты по ИТ, руководители, и т.д.) и технологиям, а также по уровню сложности, как в каталоге настоящего колледжа.
В качестве одного лишь примера скажу, что TechNet Magazine предлагает в этом месяце несколько отрывков с углубленным описанием Active Directory. А что если вам чуть недостает умения использовать их самым лучшим образом? Просто перейдите на веб-трансляции TechNet и поглядите презентацию уровня 200, именуемую «Основы Active Directory» (msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032295120).
Современные образовательные возможности очень разнообразны. От журнала до Интернета, мы работаем, что предоставить читателям нужную информацию. Прочитав наши статьи, отчего бы не посетить блог журналаTechNet Magazine (blogs.technet.com/tnmag) для беседы за чашечкой кофе по окончании лекций?
— Джошуа Трупин

Мы хотели бы поблагодарить следующих технических специалистов корпорации Майкрософт: Пола Баудена (Paul Bowden), Джастина Холла (Justin Hall), Ананда Лакшминараянана (Anand Lakshminarayanan), Эдуардо Лореано (Eduardo Laureano), Майка Льюиса (Mike Lewis), Тима Минтнера (Tim Mintner), Майкла Мерголо (Michael Murgolo), Марка Руссиновича (Mark Russinovich), и Джима Трухера (Jim Truher).


 Письма: Ответы на ваши вопросы
Письма
Ответы на ваши вопросы

Комплект программ PsTools
В колонке «Материалы о рабочей среде» (март 2007) Вес Миллер (Wes Miller) рассказывает о комплекте программ PsTools («Премьера комплекта программ PsTools», technetmagazine.com/issues/2007/03/DesktopFiles). У меня возникли небольшие проблемы при попытке запустить эти потрясающие программы. Особенно меня интересует PsLoggedOn. Не могли бы вы объяснить, как разместить эти программы в папке по моему пути? Приведенный вами пример действительно помог бы мне разобраться.
— Тим

Для начала лучше всего загрузить полный пакет PsTools (download.sysinternals.com/Files/PsTools.zip) в рабочий каталог (например, c:\toolbox). Сразу после того, как вы распакуете файл ZIP в данную папку, комплектом программ можно пользоваться. Если вы хотели бы добавить использованную директорию к вашей переменной PATH, чтобы запускать комплект программ откуда угодно, просто наберите следующую команду в командной строке, заменяя тем самым ваш рабочий каталог на c:\toolbox:
SET PATH=%PATH%;c:\toolbox

Хвала Robocopy
До момента, как я прочитал вашу статью (ноябрь 2006) о графическом интерфейсе для Robocopy (technetmagazine.com/issues/2006/11/UtilitySpotlight), у нашей службы поддержки были постоянные трудности, и мы никак не могли найти способ, как сохранить метки времени для файлов, переносимых из сетевых папок в хранилища SharePoint®. Robocopy — отличная программа!
— Кристино

Проверка подразделов реестра
Пару недель я размышлял на тем, как узнать, что значение подраздела реестра EnableLUA равняется 1 или 0. Когда значение равно 0, Управление учетными записями пользователей также выключено. Это как раз то, что нам нужно, когда мы устанавливаем программы автоматически в нашей тестовой лаборатории, и нам не требуется входить в систему под учетной записью администратора для подтверждения. Мы бы хотели поставить этот тест в начало всех наших установочных сценариев и затем запускать сценарий, который бы изменял значение EnableLUA с 1 (включено) на 0 (выключено) перед тем, как сценарий будет запущен. Однако я так и не понял, как заставить этот тест работать. Я был бы очень признателен, если бы вы могли мне помочь.
— Дерек

Ниже приведен простейший пример сценария, позволяющего прочитать параметр реестра, проверить его значение и изменить его при необходимости. В данном примере читается параметр HKLM\Software\Microsoft\Test\TestKey, происходит проверка, равно ли значение 1, если да, то значение изменяется на 0, если значение не 1, то сценарий заканчивает работу:
On Error Resume Next
Set WSHShell =  Wscript.CreateObject _
    ("Wscript.Shell")
RegLoc = _
    "HKLM\Software\Microsoft\Test\TestKey"
KeyValue = WSHShell.RegRead(RegLoc)
If (KeyValue = "1") then
  WSHShell.RegWrite RegLoc,"0"
end If
Wscript.Quit
Как обычно, используйте сценарии, изменяющие реестр, с большой осторожностью, особенно в данном случае.

Функция ReadyBoost
Не могли бы вы рассказать о функции ReadyBoost более подробно? Насколько я понимаю, ReadyBoost выступает в роли буфера между ОЗУ компьютера и жестким диском, но информация будет записываться одновременно. Не означает ли это, что производительность снизится из-за того, что система дважды копирует данные? Как мне протестировать производительности системы с ReadyBoost и без нее?
— Алекс

Основная идея ReadyBoost — сделать так, чтобы флэш-память (флэш-накопители для USB и т.п.) была своеобразным временным кэшем, который пополнит традиционную оперативную память (часто весьма дорогую). ReadyBoost не обязательно записывает одни и те же данные во флэш-память и на жесткий диск одновременно. Скорее эта функция выступает в роли промежуточного кэширующего слоя между ОЗУ и диском. Марк Руссинович (Mark Russinovich) более детально описывает данный вопрос в своей статье «Внутри ядра Windows Vista. Часть 2» (март 2007):
«После инициализации кэширования службой ReadyBoost драйвер устройства Ecache.sys перехватывает все обращения чтения и записи к локальным жестким дискам (например, диску C:\) и копирует записываемые данные в созданный службой файл кэширования...
...Если служба ReadyBoost определяет, что осуществляется произвольное чтение данных, и эти данные есть в кэше, данные извлекаются из кэша. Но ввиду того, что у жестких дисков скорость последовательного чтения выше, чем у флэш-памяти, операции последовательного чтения осуществляются непосредственно с диска, даже если эти данные есть в кэше».
Вы можете прочитать всю статью Марка в Интернете по адресу technetmagazine.com/issues/2007/03/VistaKernel.

Загрузка Windows PE
Как мне кажется, в вашей рубрике «Письма» в майском номере 2007 имеется некоторое противоречие. В первом вопросе («Создание образа») говорится: «Вы можете построить и настроить образы Windows® PE 2.0 с помощью средств, которые можно найти в WAIK...» Здесь подразумевается, что среда Windows PE входит в число средств и ее можно загрузить.
Однако в последнем вопросе («Как получить Windows PE») , «Windows PE доступен только в качестве преимущества гарантии на программное обеспечение...». Мне кажется, первый ответ правильный, а второй несколько устарел.
— Сихуа

Среда Windows PE 2.0 доступна для загрузки в составе комплекта Windows Automated Installation Kit (WAIK). У нее отличные от Windows PE 1.6 правила лицензирования (предшествующей версии, которая обсуждалась в прошлом году в статье «Знакомство с Windows PE». Вы можете ознакомиться с данной статьей по адресу technetmagazine.com/issues/2006/09/WindowsPE). Windows PE 1.6 была доступна только в качестве преимущества гарантии на программное обеспечение.

Безопасность в среде Windows PowerShell
Было много разговоров о Windows PowerShell™. Я видел множество статей, которые нахваливают синтаксис наподобие UNIX, простоту форматирования выходных данных команды и т.д., но я ничего не слышал о вопросах безопасности при развертыванииWindows PowerShell в центральный узел.
Какие проблемы с безопасностью могут появится при развертывании или использовании такой мощной оболочки, как Windows PowerShell, на рабочих серверах?
— Карлос

Мы полностью согласны с вами в том, что вопросы безопасности Windows PowerShell — важная тема. Собственно говоря, наш ведущий рубрики Windows PowerShell, Дон Джонс (Don Jones), детально рассматривает данный вопрос в этом номере журнала TechNet. Дополнительно к этому обратите внимание на две недавно изданные книги: «Windows PowerShell в действии» Брюса Паета (Bruce Payette, Manning Publications, 2007) и «Windows PowerShell: TFM» Дона Джонса и Джеффри Хикса (Don Jones and Jeffrey Hicks, SAPIEN Press, 2007). Обе эти книги рассказывают о Windows PowerShell достаточно подробно, и обе они содержат главы, посвященные безопасности.

Практические рекомендации по использованию SQL
Я категорически не согласен с рекомендациями, изложенными в вашем ответе по вопросу использования анализатора соответствия рекомендациям (Best Practices Analyzer – BPA) и объектов, квалифицирующих схемы (см. technetmagazine.com/issues/2007/05/SQLQA). SQL Server™ 2005 должен все еще разрешать схемы (в противовес только владельцам в SQL Server 2000, которых автор неверно называет «схемами»). Порядок разрешения для SQL Server 2005 хорошо документирован в интерактивной документации Books Online (BOL).
Таким образом, квалифицировать объекты — это лучший способ избежать ошибок неоднозначности и сохранить оптимизирующие циклы процессора, разрешающие имена объектов. Рекомендации в рубрике, похоже, противоречат техническому документу Майкрософт «Пакетная компиляция, перекомпиляция и проблемы с кэшированием планов в SQL Server 2005».
— Майк

За ответом мы обратились прямо к источнику, Дэвиду Брауну (David Browne), автору нашей рубрики «SQL, вопросы и ответы» и архитектору технологий в Центре технологий корпорации Майкрософт (Даллас, Техас). Он ответил следующее:
Рекомендации — это то, с чем люди могут и будут не соглашаться, особенно в вопросах производительности: у людей разные ощущения того, что создает значительную разницу в производительности и что может быть оптимизацией, которая дает результат.
Например, писать запросы таким образом, чтобы сохранять оптимизирующие циклы процессора во время компиляции — это то, чего бы я не стал делать, и я сомневаюсь, что это принесет измеримое различие в реальной нагрузке.
С другой стороны, уменьшение частоты компиляций путем разработки повторного использования планов запросов — это общепринятая оптимизация.

WinPE
Мы используем Systems Management Server (SMS) Operating System Deployment Feature Pack (OSDFP) для установки операционных систем. Теперь, после того как была выпущена Windows Vista®, мы бы хотели устанавливать ее с помощью OSDFP, и мы обновились до последней версии. Какая версия Windows PE поставляется в комплекте с последней версией пакета OSDFP?
Мы создавали образ установки, файл ISO, и копировали его в службу удаленной установки (Remote Installation Services, RIS). Затем мы использовали возможность сетевой загрузки, чтобы загрузиться на новом компьютере. Но мы обновили RIS до службы развертывания Windows (Windows Deployment Services, WDS), которая поддерживает только файлыWindows Imaging (WIM) в качестве загрузочного образа. Как нам теперь создать образ WIM с помощью пункта меню установки из OSD?
— Васишта

Версия Windows PE не была обновлена в последнем выпуске OSDFP, этот пакет все еще содержит версию 1.5 (известную также как Windows PE 2004). Несмотря на то, что версия Windows PE не была обновлена, установка Windows Vista полностью поддерживается в последнем выпуске OSDFP.
Процесс, который лучше всего использовать для создания образа, описан в BDD (Business Desktop Deployment) Solution Accelerator. Вы можете найти все необходимые компоненты и документацию в Интернете по адресу microsoft.com/technet/desktopdeployment/bdd/2007. Также обратите внимание на статью Майкла Нихауса (Michael Niehaus) «Развертывание Windows Vista с помощью BDD 2007» в этом номере журнала TechNet.

Постеры Windows Server 2003
Я только что получил июльский номер журнала TechNet, и меня очень порадовали два постера Windows Server® 2008! Мой коллега получил постер Windows 2003 Server в предыдущем номере. Вы не подскажите, где я могу достать версии этих постеров для Windows 2003 Server, либо уже напечатанные, либо в виде файлов PDF?
— Джейсон

Мы рады, что вам понравились постеры Windows Server 2008! Версия постера Windows Server 2003 в виде файла PDF доступна по адресуgo.microsoft.com/fwlink/?LinkID=80428. Мы создали только один вариант постера Windows Server 2003.


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

Перемещение баз данных SQL Server
Пакет xSQL Bundle Professional Edition
www.xsqlsoftware.com
Не имеет значения, занимаетесь ли вы эксплуатационной поддержкой, разработкой приложений, тестированием с целью контроля качества или управлением настройкой. Если вы специалист по ИТ (а кто еще будет читать TechNet Magazine), перемещение баз данных SQL Server™, вероятно, является частью вашей жизни. А вместе с ним и необходимость быть осторожным во избежание несоответствий при перемещении данных и схем данных. Чтобы уменьшить вероятность несоответствий, нужен хороший набор средств для сравнения и синхронизации схем и данных.
Одно из средств, которые я использовал в последнее время, — пакет xSQL Bundle от компании xSQL Software. Пакет состоит из четырех различных приложений: xSQL Object, xSQL Data Compare и связанных с ними программ командной строки.
xSQL Object позволяет сравнивать и синхронизировать схемы баз данных. Он предоставляет несколько вариантов сравнения для типов и экземпляров объектов, существующих в разных базах данных. Приложение также позволяет создавать снимки схем, полезные при ведении журнала версий. Эта функция также предоставляет простой способ отката к предыдущему состоянию схемы. С помощью xSQL Object можно даже создавать сценарии схем, что позво-
ляет пользователю передавать или пакетировать схему своей базы данных.
xSQL Data Compare может синхронизировать и устанавливать равенство между данными, содержащимися в двух базах SQL Server. При этом можно сравнить все содержимое баз данных или выбрать набор таблиц для сравнения. В случае если таблицы не вполне совпадают, можно определить приспособленное к случаю сопоставление таблиц, чтобы убедиться в совпадении информации в них. При синхронизации больших объемов данных приложение переходит в режим вставки больших массивов данных, экономя время процесса синхронизации.
Как xSQL Data Compare, так и xSQL Object позволяет сохранять рабочее пространство, избавляя от необходимости постоянно воссоздавать среду для сравнения. Синхронизация транзакционна для обоих приложений, так что следует удостовериться, что либо все операции проведены успешно, либо проведен общий откат. Все приложения в пакете поддерживают базы данных как SQL Server 2000, так и SQL Server 2005, что позволяет сравнивать и синхронизировать данные и объекты между разными версиями.
Вероятно, одной из самых полезных функций xSQL Bundle являются две программы командной строки, которые фактически позволяют запускать задачи сравнения и синхронизации через любую имеющуюся сборку, процесс, наблюдение или планировщик автоматизированных задач. (По мне, автоматизация дублирующихся задач всегда делает работу легче и производительнее.) Программы командной строки заглатывают файл настройки формата XML, создаваемый с помощью мастера настройки из пользовательского интерфейса основного приложения, причем каждая программа располагает набором параметров ведения журнала через текстовые файлы, что дает возможность проследить происходящее в ходе автоматического исполнения.

Цена: xSQL Bundle Professional Edition стоит от 499 долларов США за лицензию для одного пользователя.
xSQL Data Compare может синхронизировать данные в двух базах SQL Server
xSQL Data Compare может синхронизировать данные в двух базах SQL Server

Предоставление более безопасного подключения
WinSSHD
www.bitvise.com
Если необходимо улучшить безопасность в вашей организации, то стоит обратить внимание на Secure Shell Handling 2 (SSH2) и Secure FTP (SFTP). Попросту говоря, туннелирование SSH2 позволяет безопасно подключаться к службам на удаленных машинах. Оно также помогает ограничить открытость потенциальным хакерам, уменьшая число доступных прослушивающих и прямо связанных с приложениями портов, открытых на брандмауэре. SFTP является альтернативой стандартному серверу FTP и использует SSH2 для обеспечения безопасности данных и команд.
Тем, кого заинтересовали эти протоколы, определенно следует взглянуть на WinSSHD от Bitvise. WinSSHD — сервер SSH2, разработанный специально для Windows.
Установка прямолинейна. Приложение предоставляет интуитивно понятную панель управления для распоряжения службами WinSSHD. На панели управления можно найти все, от базовых функций «начать/остановить» до специальных представлений журнала событий Windows® (через который можно отфильтровать события WinSSHD). Отсюда же запускается панель параметров, позволяющая работать с мелкими деталями настройки. В ней можно установить привязки интерфейса и портов, точно настроить параметры ведения журнала, указать методы шифрования, которые следует включать во время сеанса SSH, настроить тайм-ауты сеанса, выбрать методы проверки подлинности, указать настройки прокси и элементы управления, имеющие доступ к экземпляру. Кроме того, можно импортировать и экспортировать настройки.
Параметры управления доступом дают возможность ограничить доступ через правила доступа по IP (с поддержкой маскировки для управления подсетями) и правила имен для DNS (которые обрабатываются после правил доступа по IP).
WinSSHD поддерживает виртуализацию, что просто великолепно для реализаций SFTP. Это означает возможность привязать тысячи виртуальных пользователей к одной учетной записи Windows, уменьшая проблемы с учетными записями и безопасностью. Это приложение также поддерживает группы проверки подлинности и контроля доступа Windows, так что политику не придется определять для каждого пользователя отдельно.
Благодаря поддержке Kerberos 5 и проверки подлинности NTLM WinSSHD можно встроить в среду с единым входом. Выполнение этой задачи требует клиента SSHA с поддержкой GSSAPI, такого как Tunnelier — этот приятный продукт-спутник также имеется у компании Bitvise. Как и следует ожидать, Tunnelier полностью совместим с сервером WinSSHD. Его также можно использовать для удаленной настройки сервера WinSSHD.
Если среда сервера SFTP или SSH2 критически важна, WinSSHD можно кластеризовать для повышения доступности. Это довольно прямолинейная задача, но те, кому потребуется помощь, могут найти ее на веб-узле компании, предоставляющем информацию и руководства по настройке для установки кластеризации, переадресации портов, туннелирования удаленного рабочего стола и так далее.

Цена: 99,95 долларов США.
WinSSHD позволяет указать методы шифрования для сеанса SSH
WinSSHD позволяет указать методы шифрования для сеанса SSH

Отслеживание активности USB
USB Monitor Professional
www.hhdsoftware.com
Этот продукт предназначен всем типам пользователей. Возможно, вы человек, который без ума от самодельного программного обеспечения, которому нравится создавать и модифицировать драйверы для своих устройств USB. Или проектировщик оборудования, который эти устройства USB создает. Или просто пользователь, который, глядя на светодиодный индикатор активности устройства USB, задумался, что именно вызывает такую большую активность. Вам может помочь USB Monitor Professional от компании HHD Software. Эта служебная программа позволяет записывать, отображать и анализировать данные, перемещающиеся между устройством USB и работающей под Windows системой через управляющий контроллер USB.
Пользовательский интерфейс несколько запутан, но, привыкнув к нему, можно собирать огромные объемы информации о данных, передаваемых с отслеживаемого устройства USB и на него. По умолчанию приложение записывает большинство команд и наборов команд, передаваемых на устройство USB. Для некоторых устройств, особенно для запоминающих устройств, запись может получиться довольно многословной. К счастью, пользователь может указать, какие данные он желает записать для запоминающего устройства.
После записи сеанса данные можно проанализировать несколькими способами. Для запоминающих устройств имеется представление Mass Storage View. Существуют также варианты с линейной диаграммой статистики и пропускной способности устройства, просмотром необработанных пакетов и запросов управления, просмотром дешифратора пакетов данных, просмотром на основе HID, а также представлением Still Image View (в котором декодируется протокол USB Still Image для соответствующих устройств).
Из-за объема данных, записываемых приложением, сеанс записи USB не стоит затягивать. Однако можно также ограничивать максимальное место на диске, отводимое активным сеансам записи, и сжимать записанные данные для уменьшения необходимого пространства.

Цена: от 175,99 долларов США за обычную лицензию.
USB Monitor Professional записывает команды, передаваемые на устройство USB
USB Monitor Professional записывает команды, передаваемые на устройство USB

Управление виртуальными носителями
Virtual CloneDrive
www.elby.ch/fun/software
Работа с физическими носителями бывает настоящей тягомотиной. Перейдя на Windows Vista и лишившись прямой совместимости с панелью управления Microsoft Virtual CD-ROM, я начал искать заменитель для установки образов компакт-дисков и дисков DVD. (Кстати, те, кому это интересно, могут найти панель управления Microsoft®Virtual CD-ROM для Windows XP на go.microsoft.com/fwlink/?LinkId=94801.)
Конечно, запуск панели управления Virtual CD-ROM возможен и на Windows Vista. Но проблема в том, что запуск возможен только для администратора, и установленное устройство чтения будет видно лишь администратору, то есть через командную строку в режиме «Выполнить от имени администратора», но не через проводник Windows в контексте пользователя. В результате средство не только не работает как мне нужно, но и требует от меня запускать приложение в менее безопасной среде.
Одно найденное мною средство, которое работает в контексте пользователя Windows Vista —
Virtual CloneDrive от компании Elaborate
Bytes. Это приложение устанавливает себя как приложение управления с графическим интерфейсом и контроллер внешней памяти, отображающийся в
диспетчере устройств. После установки приложение имеет три основных параметра. Во-первых,
можно определить желаемое число виртуальных приводов — максимум 8 параллельных. Во-вторых — это, пожалуй, мой любимый параметр — можно установить параметр Virtual Sheep, который заменяет стандартный значок устройства чтения компакт-дисков/дисков DVD изображением разозленной овцы, позволяя легко отличать образы ISO от настоящих, физических приводов в вашей системе. Наконец, для каждого виртуального привода можно выбрать автоматическую установку последнего назначенного ему образа при запуске системы.
Помимо файлов ISO, Virtual CloneDrive может устанавливать и читать файлы CCD, DVD, IMG, UDF и BIN. Кроме того, он встраивается в проводник Windows, давая тем самым быстрый доступ к установке и отмене установки образов. Среди прочих достоинств Virtual CloneDrive следует упомянуть его бесплатность. Пользователю, перешедшему на Windows Vista® и ищущему новое решение для управления файлами ISO, определенно стоит попробовать это средство.

Цена: бесплатно.
Разозленная овца Virtual CloneDrive
Разозленная овца Virtual CloneDrive

Обзор книги
Карманный консультант администратора по программным продуктам и технологиям SharePoint
microsoft.com/MSPress/books/10623.aspx
Современный офис, может, и не избавлен от бумаг, но число электронных документов, с которыми надо работать, явно растет. Оборот этих документов и их коллективное использование является растущей проблемой, для решения которой многие компании полагаются на Microsoft SharePoint®Services и SharePoint Server. «Карманный консультант администратора по программным продуктам и технологиям SharePoint», написанный Беном Карри (Ben Curry), может помочь в этом. Он является отличным справочником по административным функциям и повседневным задачам как для тех, кто только рассматривает установку SharePoint, так и для тех, кто уже завяз в вопросах ее планирования, и для тех, кто успел установить инфраструктуру SharePoint.
А для тех, кто уже знаком с серией «Карманный консультант администратора», это руководство покажется привычным. Оно не уступает остальным по части материала и его подачи. Данная конкретная книга охватывает Windows SharePoint Services 3.0, SharePoint Server 2007 Standard, и SharePoint Server 2007 Enterprise Edition. Она разбита на четыре раздела.
Первый раздел, «Основные сведения о программных продуктах и технологиях SharePoint» предоставляет обзор компонентов, версий, требований и хода установки продуктов SharePoint Server. Следующий раздел объясняет различия между Windows SharePoint Services 3.0 и версиями Standard и Enterprise продукта SharePoint Server. Затем раздел проводит читателя через установку каждого из трех продуктов. Он также подробно рассказывает, какие базы данных SQL Server и веб-узлы IIS создаются в ходе процесса установки.
Следующий раздел, «Основы администрирования SharePoint», охватывает пользовательский интерфейс центра администрирования и предлагает справки по созданию новых веб-узлов и коллекций веб-узлов, импорту, использованию и правке веб-частей, а также настройке параметров групп и электронной почты для установки. Здесь же можно узнать, как управлять различными возможностями задания бизнес-правил и как эти самые бизнес-правила отслеживать.
Третий раздел книги, «Работа с SharePoint Server 2007», углубляется в функции и возможности, характерные для версий SharePoint Server (Standard и Enterprise). Он охватывает такие темы, как настройка управления корпоративным информационным содержимым, создание и настройка порталов SharePoint, установка поиска и индексирования и настройка службы вычислений Excel®. Раздел о службах вычислений Excel также предоставляет инструкции по настройке служб в среде из нескольких серверов, позволяющей улучшить производительность и доступность.
Четвертый раздел разворачивает тему функциональных аспектов применения SharePoint Server, показывая, как расширить SharePoint Server 2007 до фермы серверов и различные возможные конфигурации для такой реализации. Наконец, книга позывает основы операций Backup and Restore, способы анализа производительности и использования средств ведения журнала SharePoint Server для обслуживания и улучшения веб-узлов.
Хотя книга и подает себя как настольный справочник для администраторов, я думаю, что те, кто только планирует использовать SharePoint или просто испытывает любопытство, найдут ее полезной для быстрого знакомства со SharePoint. Структура книги — начинающейся с предельно простого рассказа о технологиях SharePoint и их возможностях, затем продвигающейся через все более сложные темы, такие как настройка службы вычислений Excel и расширения до фермы серверов, — гарантирует, что она будет полезным справочником для тех, кто только начал знакомиться с технологиями SharePoint и останется таковым по мере роста знаний читателя.

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

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


 Вопросы и ответы по SQL: &#171;Узкие места&#187;, связанные с процессором, восстановление и перемещение баз данных и прочее
Вопросы и ответы по SQL
«Узкие места», связанные с процессором, восстановление и перемещение баз данных и прочее
Под редакцией Нэнси Мичелл (Nancy Michell)

Вопрос. Использование ресурсов процессора моим SQL Server™ начало неожиданно подскакивать за пределы обычного, хотя вроде бы ничего не произошло. Не добавлялись новые пользователи, не ломалось оборудование, не создавались новые таблицы. Так в чем причина?

Совет: доступ в ходе создания индексов
Рано или поздно перед каждым может встать необходимость создания индексов для больших таблиц (что может отнять очень много времени), но при этом сохранять доступ к данным в процессе. Как это можно совместить?
При каждом создании, удалении или переделке кластеризованного индекса SQL Server устанавливает блокировку изменения схем (SCH-M) на таблицу, исключая пользовательский доступ к данным в течение операции. Но это в случае создания кластеризованного индекса для таблицы. Для сравнения, при создании кластеризованного индекса для столбца SQL Server помещает совместную (S) блокировку на таблицу, что, хотя также исключает обновление данных в соответствующей таблице, по крайней мере позволяет выполнять команды SELECT, просматривая таким образом данные.
Если доступность таблицы для чтения в ходе создания кластеризованного индекса важна, можно создать индекс для таблицы и сделать эту операцию оперативной. Вот как это делается:
CREATE UNIQUE CLUSTERED INDEX CLUST_IDX_SQLTIPS
ON SQLTips (tip) with (ONLINE=ON) Go;
При проведении оперативных операций с индексом для таблицах SQL Server по-прежнему помещает блокировку SCH-M для кластеризованного индекса или совместную (S) блокировку для некластеризованного индекса на обрабатываемую таблицу, но лишь на очень короткие промежутки времени — в начальной и конечной фазах операции над индексом. Следовательно, этот вариант открывает больше возможностей для запросов и обновлений соответствующей таблицы в ходе процесса создания индекса. Отметьте, что оперативное создание индексов и работа над ними доступны лишь в SQL Server 2005 Enterprise Edition.

Ответ. «Узкие места», связанные с процессором и возникающие внезапно и неожиданно, без каких-либо изменений или дополнительной нагрузки на сервер, могут быть вызваны целым рядом причин, наиболее распространенные из которых включают неоптимальный план запросов, неудачную настройку сервера SQL, неверное проектное решение приложения или базы данных, и наконец, недостаточные ресурсы оборудования.
При возникновении подобной ситуации в первую очередь следует определить, ограничен ли сервер ресурсами процессора, и если это так, определить команды, являющиеся основными потребителями ресурсов процессора локальной системы SQL Server. Узнать, ограничен ли сервер ресурсами процессора, можно через системный монитор, посмотрев показания счетчика «Процессор: \% загруженности процессора». Если значение времени, используемого процессором, равно или выше 75 процентов, наличествует узкое место, связанное с процессором.
Также следует наблюдать за планировщиком заданий SQL Server, запрашивая динамическое административное представление (DMV) системы, именуемое SYS.DM_OS_SCHEDULERS, чтобы видеть значение пригодных к выполнению заданий. Ненулевое значение показывает, что задачам придется ждать своего временного интервала для выполнения, высокие значения этого счетчика также являются симптомом узкого места, связанного с процессором.
Для перечисления всех планировщиков заданий и просмотра количества пригодных к выполнению заданий можно использовать следующий запрос:
SELECT
 Scheduler_ID,
 Current_Tasks_Count,
 Runnable_Tasks_Count
FROM
 SYS.DM_OS_SCHEDULERS
WHERE
 Scheduler_ID < 255
Для получения списка 50 наиболее требовательных к ресурсам процессора команд SQL используйте запрос на Рис. 1.
Figure 1 50 основных пожирателей ресурсов процессора (Close Figure 1)
SELECT TOP 50 (a.total_worker_time/a.execution_count) AS [Avg_CPU_Time],
 Convert(Varchar,Last_Execution_Time) AS 'Last_execution_Time',
 Total_Physical_Reads,
 SUBSTRING(b.text,a.statement_start_offset/2,
 (case when a.statement_end_offset = -1 then len(convert(nvarchar(max), b.text)) * 2
 else
 a.statement_end_offset end - a.statement_start_offset)/2) AS Query_Text,
 dbname=Upper(db_name(b.dbid)),
 b.objectid AS 'Object_ID'
 FROM sys.dm_exec_query_stats a
 CROSS APPLY
 sys.dm_exec_sql_text(a.sql_handle) AS b
 ORDER BY
 [Avg_CPU_Time] DESC

Вопрос. Мне пришлось восстановить базу данных SQL Server 2005 с ленты. После восстановления большинство разрешений пользователям на доступ к этой базе данных оказались утеряны. Что я сделал неверно при восстановлении? Данные оказались в порядке, но разрешения превратились в кашу.

Ответ. Скорее всего, главная база данных не была восстановлена на тот же момент во времени, и учетные данные пользователей в их базе данных не совпадают с текущей главной базой данных. Необходимо синхронизировать их. На врезке «Где получить справку при перемещении базы данных» перечислены матералы, наиболее полезные для выяснения корней проблем, возникающих при восстановлении или перемещении баз данных.

Вопрос. Я разработал приложение, использующее хранимую процедуру для нарезки данных XML в реляционные таблицы при помощи OpenXML в SQL Server 2005 с пакетом обновления 1 (SP1). Документы XML не превышают 5 кБ (2,5 кБ в среднем). Хранимая процедура вызывается много раз параллельно (до 50 раз).
Конфликты при блокировках вызывают серьезные проблемы, и мне кажется, что причиной этого является OpenXML. Как вы считаете?

Ответ. Хотя OpenXML может работать быстрее при нарезке или преобразовании данных в одном потоке, чем узловой метод, последний лучше приспосабливается к увеличению числа потоков, особенно при параллельном использовании. А если уж используется OpenXML, то улучшить общую производительность помогут нижеследующие советы.
Вместо пятикратного вызова OpenXML с одинаковым шаблоном строки (о чем, можно заметить, говорилось в вопросе) следует извлечь все данные с одинаковым шаблоном строки во временную таблицу и затем выполнять выборку из нее. Попробуйте освободить память с помощью sp_xml_removedocument как можно раньше. Кроме того, неплохо бы избегать использования подстановочных знаков, таких как * и //, когда только возможно; предоставление явного пути улучшает работу запроса.

Вопрос. DBCC SHRINKFILE работает на моем сервере очень медленно. Поможет ли многопроцессорный компьютер улучшить производительность? Что можно сделать для улучшения ситуации?

Ответ. DBCC SHRINKFILE является однопоточной операцией и, следовательно, не использует преимуществ нескольких процессоров. Она перемещает страницы из конца в начало файла, по одной за раз. И сжатие, как часто называется эта операция, не сопровождается дефрагментацией, более того, увеличивает логическую фрагментацию во многих ситуациях.
Способы улучшения производительности при сжатии включают перемещение страниц в кластеризованных индексах. При наличии куч, включающих много некластеризованных индексов, скорость будет явно низкой (по сравнению с обработкой кластеризованных индексов).
Отметьте, что перемещение страниц для данных больших двоичных объектов (LOB) будет медленным, поскольку придется читать внутристрочные данные, чтобы найти корни данных LOB.
Если большая часть содержимого индекса или таблицы пребывает в конце файла, то можно перестроить индексы для перемещения их в начало файла. Перестройка индексов использует преимущества нескольких процессоров и может занять меньше пространства под журнал в режиме bulk_logged. При последующем запуске сжатия оно будет происходить быстрее.
Дополнительные сведения по операциям сжатия можно найти в блогах blogs.msdn.com/sqlserverstorageengine/archive/2007/03/29/how-does-your-schema-affect-your-shrink-run-time.aspx и blogs.msdn.com/sql-serverstorageengine/archive/2007/04/15/how-to-avoid-using-shrink-in-sql-server-2005.aspx.
Где получить справку при перемещении базы данных
  • Как перемещать базы данных между компьютерами, использующими SQL Server.
  • Как перемещать базы данных SQL Server на новые местоположения, используя функции отсоединения и присоединения в SQL Server.
  • INF: Использование параметра WITH MOVE в команде RESTORE.
  • Как справляться с проблемами разрешений при перемещении базы данных между серверами, использующими SQL Server.
  • INF: Как передавать имена входа и пароли между экземплярами SQL Server.
  • INF: Знакомство с мастером копирования баз данных SQL Server 2000 и устранение ошибок.
  • Входные данные пользователей и разрешения на базе данных могут оказаться неверными после ее восстановления.
  • Невозможно восстановить резервные копии системных баз данных на несовпадающую сборку SQL Server.
  • Как извлечь определенную таблицу или строки из резервной копии базы данных или резервной копии журнала транзакций в SQL Server.

Совет: изменение портов
Каждый, кто знаком с SQL Server, знает, что по умолчанию SQL Server прослушивает порт 1433. Хотя именованные экземпляры SQL Server настроены на использование динамических портов (а значит, могут выбрать любой доступный порт при запуске SQL Server), экземпляр SQL Server по умолчанию всегда ведет прослушивание на порту 1433. Очевидно, что если сервер ведет прослушивание на порту по умолчанию, и егонастройка безопасности не максимально строга, он подвергается риску. Но изменение порта по умолчанию может сорвать атаки. Делается это следующим образом.
Откройте диспетчер настройки SQL Server и разверните конфигурацию сети SQL Server 2005, затем Протоколы. Далее дважды щелкните TCP/IP. Список свойств TCP/IP и их функций показан в диаграмме ниже, так что расставляйте в соответствии с ней.
Отметьте, что ядро СУБД SQL Server может прослушивать несколько портов на одном IP-адресе, так что перечислите порты, которые хотите использовать, разделяя их запятой, в формате: 1433,1500,1501. Если необходимо настроить один IP-адрес на прослушивание нескольких портов, необходимо также указанть значение «нет» для параметра «Слушать все» во вкладке «Протоколы» диалогового окна «Свойства TCP/IP».
Теперь щелкните каждый адрес правой кнопкой мыши и выберите «Свойства» для определения IP-адреса, который желаете настроить. Если диалоговое окно «Динамические порты TCP» содержит 0, указывая, что ядро СУБД ведет прослушивание на динамических портах, удалите 0. В поле «Свойства IP» диалогового окна порта TCP введите номер порта, прослушивать который следует данному IP-адресу, и нажмите кнопку OK. На панели консоли щелкните «Службы SQL Server 2005», а на панели свойств щелкните правой кнопкой мыши SQL Server (<имя экземпляра>) а затем выберите перезапуск для остановки и перезапуска SQL Server.
После настройки SQL Server на прослушивание определенного порта клиент может подключиться к порту одним из трех способов. Можно запустить службу обозревателя SQL Server для подключения к экземпляру механизма СУБД по имени; можно создать псевдоним на клиенте, указывающий номер порта; или можно запрограммировать клиента на подключение при помощи индивидуальной строки подключения.

Свойство | Описание
Активно | Обозначает, что SQL Server прослушивает указанный порт. Не доступно для IPAll.
Включено | Включает или отключает данное подключение. Не доступно для IPAll.
IP-адрес | Позволяет просмотреть или изменить IP-адрес, используемый подключением. Указывает IP-адрес, используемый компъютером и IP-адрес заглушки, 127.0.0.1. Не доступно для IPAll.
Динамические порты TCP | Пусто, если динамические порты не включены. Для использования динамических портов установите на 0.
Порт TCP | Позволяет просмотреть или изменить порт, прослушиваемый SQL Server. Экземпляр по умолчанию прослушивает порт 1433. Данное поле ограничено 2047 знаками.

Благодарим за ответы на вопросы этого месяца следующих специалистов по информационным технологиям корпорации Майкрософт: Чэда Бойда (Chad Boyd), Синди Гросс (Cindy Gross), Джона Хаддена (John Hadden), Салима Хакани (Saleem Hakani), Стивена Джианга (Stephen Jiang), Махеша Наяка (Mahesh Nayak), Пола Рэндэла (Paul Randal), и Уэйна Ю (Wayne Yu).


 Обзор служебных программ: PageDefrag
Обзор служебных программ
PageDefrag
Лэнс Уитни (Lance Whitney)
Загрузить исходный код для этой статьи: PageDefrag (70KB)

Обычная программа дефрагментации Windows® позволяет оптимизировать основную часть файлов, находящихся на жестком диске, но некоторые из них не обрабатываются большинством программ дефрагментации. Файлы, открытые и заблокированные для монопольного доступа, такие как файл подкачки Windows и ветви реестра, обычно не обрабатываются программой-дефрагментатором, входящим в состав ОС Windows, а также программами сторонних поставщиков. Стандартные интерфейсы API Windows не поддерживают дефрагментацию тех файлов, которые находятся в использовании. К счастью, служебная программа PageDefrag, созданная Марком Русиновичем для компании Sysinternals, позволяет сэкономить много времени, дефрагментируя те файлы, которые остаются нетронутыми другими программами.
Программа PageDefrag позволяет дефрагментировать файл подкачки Windows, ветви реестра, журналы событий и файл спящего режима (область диска, в которой сохраняется содержимое памяти при переходе ноутбука в спящий режим). Программа оптимизирует эти файлы в ходе загрузки компьютера, перед началом их использования.
Чтобы запустить программу PageDefrag, достаточно дважды щелкнуть файл pagedfrg.exe. Программа отображает имена всех файлов, которые он может обработать при дефрагментации (см. рис. 1). Имя файла подкачки — pagefile.sys. Ветви реестра представлены в виде отдельных файлов на каждую ветвь — DEFAULT, SAM, SECURITY, SOFTWARE и SYSTEM. Журналы событий также отображаются в виде отдельных файлов: например, AppEvent.evt является журналом приложений, SecEvent.evt — журналом безопасности, журнал SysEvent.evt — системным журналом. И, наконец, файл спящего режима —Hiberfil.sys.
Рис. 1 Программа PageDefrag отображает имена всех файлов, которые она может обработать
Рис. 1 Программа PageDefrag отображает имена всех файлов, которые она может обработать
Рядом с именем каждого файла расположен столбец кластеров (Clusters), который показывает, сколько кластеров диска отведено для данного файла, и столбец фрагментов, который показывает, сколько фрагментированных или непоследовательных частей файлов разбросаны по диску. Основываясь на этих данных, можно определить, нуждаются ли файлы в дефрагментации.
Имеется две возможности: можно дефрагментировать файлы при последующей перезагрузке или при каждой перезагрузке. Если только файлы не находятся в постоянном использовании и ваш компьютер не является сервером или другим устройством, которое редко перезагружается, вы достигнете превосходных результатов в дефрагментации при последующей перезагрузке. Кроме того, существует задержка в виде обратного отсчета времени, так что у вас всегда есть возможность прервать процесс дефрагментации при запуске компьютера.
При последующей перезагрузке компьютера обычно будет запущена программа chkdsk, после чего стартует программа PageDefrag. Файлы, размещенные в виде последовательных кластеров, не обрабатываются. Файлы, разбитые на фрагменты, оптимизируются последовательно, один за другим. Программа показывает имя дефрагментируемого элемента, сообщает о том, успешно ли выполнена дефрагментация, и перечисляет количество кластеров, занятых файлом до и после дефрагментации.
Программа PageDefrag может оказаться неспособной оптимизировать файлы, если компьютер имеет недостаточно свободного пространства на диске или это свободное пространство само сильно фрагментировано. В этих случаях вам нужно будет освободить дополнительное пространство и вначале запустить программу дефрагментации Windows, чтобы оптимизировать свободное пространство, а затем повторно запустить программу PageDefrag.
Программа PageDefrag обычно работает быстро, поскольку она обрабатывает лишь малое количество файлов, однако если файлы сильно фрагментированы, для дефрагментации потребуется значительное время, особенно в первый раз. После того как программа PageDefrag завершит свою работу, Windows запускается обычным образом. Теперь можно запустить программу еще раз, чтобы убедиться, что каждый файл теперь представляет собой единый фрагмент.
Программу PageDefrag можно запустить неинтерактивно, с помощью командной строки или сценария, использовав ключи -e для дефрагментации по загрузке (Defrag boot), -o для однократной дефрагментации (Defrag once), -n для отказа от дефрагментации (Never Defrag) и -t для указания времени задержки в секундах (Set countdown) перед запуском программы pagedfrg.exe.
Для получения дополнительных сведений и загрузки копии программы посетите веб-страницу microsoft.com/technet/sysinternals/FileAndDisk/PageDefrag.mspx.

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


 Кабельщик: Модели сильного и слабого узлов
Кабельщик
Модели сильного и слабого узлов
Джозеф Дэвис (Joseph Davies)

Все большее распространение получают многосетевые узлы с несколькими сетевыми интерфейсами. Многосетевой узел обеспечивает дополнительные возможности подключения благодаря возможности одновременного подключения к нескольким сетям, таким как интрасеть или Интернет. Однако из-за возможности одновременного подключения к интрасети и
Интернету службы, выполняемые на многосетевых узлах, могут быть подвержены атакам. Чтобы помочь предотвратить атаки и получить представление о том, как обрабатывается трафик IP на многосетевом узле, я собираюсь рассмотреть модели слабого и сильного многосетевого узла, а также их поддержку в Windows®.
RFC 1122 — это спецификация, описывающая две модели многосетевых узлов, выступающих не в качестве маршрутизаторов, а только в качестве узлов, отправляющих и получающих одноадресный трафик IP. Эти модели, известные как сильный и слабый узлы, устанавливают, должен ли отправленный или полученный одноадресный трафик быть связан с сетевым интерфейсом, по которому он проходит. Эти модели определяют отправку и получение узлом пакетов, а также влияние на уязвимость выполняемых на узле служб.
Хотя спецификация RFC 1122 определяет эти модели для IPv4, они также применяются к IPv6. Примером многосетевого узла для IPv6 является компьютер, использующий протоколы IPv4 и IPv6, с сетевым адаптером, подключенным к интрасети и интерфейсу туннелирования IPv6.

Модель слабого узла
В модели слабого узла узел IP (IPv4 или IPv6) может отправлять пакеты через интерфейс, для которого не назначен IP-адрес отправителя отправляемого пакета. Это называется поведением отправки слабого узла. Узел IP также может получать пакеты на интерфейсе, для которого не назначен конечный IP-адрес получаемого пакета. Это называется поведением получения слабого узла.
При наличии многосетевого узла IP с несколькими интерфейсами разрешение поведения получения слабого узла на интерфейсах иногда может привести к тому, что узел станет уязвимым для многосетевых атак. Например, на рис. 1 показан узел A, подключенный к Интернету и интрасети. Узел A имеет общий IPv4-адрес 131.107.89.211, назначенный интерфейсу Интернета, и частный IPv4-адрес 192.168.17.48, назначенный интерфейсу интрасети.
Рис. 1 Пример многосетевого компьютера
Рис. 1 Пример многосетевого компьютера
При включенном поведении отправки слабого узла на интерфейсах Интернета и интрасети узел A может отправлять пакеты с адреса 131.107.89.211 с интерфейса Интернета, пакеты с адреса 192.168.17.48 с интерфейса Интернета, пакеты с адреса 131.107.89.211 с интерфейса интрасети и пакеты с адреса 192.168.17.48 с интерфейса интрасети.
При включенном поведении получения слабого узла узел A может получать следующие типы пакетов (предполагается, что правила брандмауэра узла разрешают входящий трафик): пакеты на адрес 131.107.89.211 на интерфейс Интернета, пакеты на адрес 192.168.17.48 на интерфейс Интернета, пакеты на адрес 131.107.89.211 на интерфейс интрасети, пакеты на адрес 192.168.17.48 на интерфейс интрасети.
При включенном поведении получения слабого узла злоумышленник в Интернете может отправлять пакеты интерфейсу Интернета узла A для атаки служб, выполняемых на узле A и доступных только узлам в интрасети. Это тип атаки становится доступным, если инфраструктура Интернета поддерживает пересылку пакетов, предназначенных для 192.168.17.48, интерфейсу Интернета узла A. Этот тип атаки можно предотвратить, настроив соответствующие правила брандмауэра на интерфейсе Интернета узла A. Однако даже в этом случае службы, выполняемые на узле A, доступном для клиентов интрасети, могут находиться в опасности.

Модель сильного узла
В модели сильного узла поведения отправки и получения отличаются. При отправках сильного узла узел может отправлять пакеты через интерфейс, только если для него назначен IP-адрес отправителя отправляемого пакета. При получениях сильного узла узел также может получать пакеты на интерфейсе, только если для него назначен IP-адрес назначения получаемого пакета.
При включенном на интерфейсах Интернета и интрасети поведением отправки сильного узла узел A, показанный на рис. 1, может отправлять пакеты только с адреса 131.107.89.211 через интерфейс Интернета, а также пакеты с адреса 192.168.17.48 через интерфейс интрасети.
При включенном поведении получения сильного узла узел A может получать только пакеты на адрес 131.107.89.211 интерфейса Интернета и пакеты на адрес 192.168.17.48 интерфейса интрасети.
Показанная на рис. 1 модель сильного узла для узла A отбрасывает все входящие пакеты на интерфейсе Интернета, адресованные 192.168.17.48, эффективно изолируя интерфейс интрасети узла A от Интернета — брандмауэр при этом настраивать не приходится.
При выборе модели сильного узла необходимо помнить, что она может влиять на некоторые типы связи, предназначенные для поведения слабого узла. Например, некоторые реализации балансировки нагрузки могут использовать поведение получения слабого узла для защиты пакетов на том или ином интерфейсе и последующей отправки их на соответствующий интерфейс внутренним способом. Это также может повлиять на узел, использующий отправленные слабым узлом данные для отправки трафика с какого-либо адреса отправителя на интерфейсе, соответствующем быстрому подключению.

Получение и отправка сильного узла
Теперь давайте рассмотрим процесс получения и отправки на общем узле для IPv4 или IPv6 при включении или отключении отправки и получения сильного узла для отдельных интерфейсов.
Для отправляемых пакетов протокол IP сначала проверяет указание адреса отправителя. Если адрес отправителя не указан, протокол IP выполняет неограниченный поиск адреса назначения пакета в таблице маршрутизации. При неограниченном поиске выполняется поиск по всем маршрутам таблицы маршрутизации. На основе выбранного для назначения маршрута протокол IP определяет интерфейс следующего прыжка (интерфейс для размещения пакета на канальном уровне) и адрес следующего прыжка. На основе интерфейса следующего прыжка протокол IP использует процесс выбора адреса, определенный в спецификации RFC 3484, что необходимо для определения наилучшего адреса отправителя. В этот момент у протокола IP есть все необходимое для отправки пакета: адрес отправителя и адрес назначения, интерфейс и адрес следующего прыжка.
Если указан адрес отправителя, известен интерфейс отправителя. Интерфейсу отправителя присваивается адрес отправителя. Затем протокол IP определяет, разрешены ли отправки сильного узла на интерфейсе отправителя.
Если отправки отключены, протокол IP выполняет неограниченный поиск адреса назначения пакета в таблице маршрутизации. На основе наилучшего подходящего маршрута для назначения протокол IP определяет интерфейс и адрес следующего прыжка. Протокол IP имеет адрес отправителя и адрес назначения, интерфейс и адрес следующего прыжка. Обратите внимание, что если на интерфейсе отправителя отключено поведение отправки сильного узла, интерфейс следующего прыжка может не совпадать с интерфейсом отправителя.
Если на интерфейсе отправителя разрешены отправки сильного узла, протокол IP выполняет неограниченный поиск адреса назначения пакета в таблице маршрутизации. При неограниченном поиске выполняется поиск только в маршрутах с интерфейсом следующего прыжка интерфейса отправителя. На основе выбранного для назначения маршрута протокол IP определяет адрес следующего прыжка. Протокол IP имеет адрес отправителя и адрес назначения, интерфейс и адрес следующего прыжка. Обратите внимание, что если на интерфейсе отправителя разрешено поведение отправки сильного узла, интерфейс следующего прыжка всегда совпадает с интерфейсом отправителя. На рис. 2 показан общий процесс на узле отправки IP.
Рис. 2 Общий процесс на узле отправки IP
Рис. 2 Общий процесс на узле отправки IP
Если указан адрес отправителя, неограниченный поиск маршрута может выбрать в таблице маршрутизации среди маршрутов с ближайшим соответствием назначению маршрут с более высокой метрикой. Например, узел A, показанный на рис. 1, имеет два маршрута по умолчанию; маршрут с метрикой 10 указывает на Интернет, а маршрут с метрикой 20 указывает на интрасеть.
Если отправляющее приложение на узле A не указывает адрес отправителя, результатом поиска маршрута будет являться маршрут по умолчанию с наименьшей метрикой; узел A всегда отправляет трафик с интерфейса Интернета с адресом отправителя 131.107.89.211. Однако если отправляющее приложение на узле A указывает адрес отправителя 131.107.89.211, результатом поиска будет являться маршрут по умолчанию для интерфейса Интернета; узел A отправляет трафик с интерфейса Интернета. Если отправляющее приложение на узле A указывает адрес отправителя 192.168.17.48, при поиске будет выбран маршрут по умолчанию для интерфейса Интернета; узел A отправляет трафик с интерфейса Интернета. После выполнения неограниченного поиска маршрута протокол IP отправляет трафик с адресом отправителя 192.168.17.48, используя маршрут по умолчанию с наибольшей метрикой.
Для принятого трафика протокол IP сначала определяет, предназначен ли трафик для узла. Если трафик не предназначен для узла, протокол IP сбрасывает пакет без уведомления, поскольку узел не выступает в качестве маршрутизатора. Затем протокол IP определяет разрешение служб сильного узла на входящем интерфейсе (интерфейс получения пакета). Если службы отключены, протокол IP обрабатывает пакет. Если службы включены, протокол IP определяет, назначен ли адрес назначения в пакете входящему интерфейсу. Если адрес назначен входящему интерфейсу, протокол IP обрабатывает пакет. В противном случае протокол IP сбрасывает пакет без уведомления. На рис. 3 показан общий процесс на узле получения.
Рис. 3 Процесс на узле получения
Рис. 3 Процесс на узле получения

Поведение слабого и сильного узлов в Windows
Windows XP и Windows Server® 2003 используют модель слабого узла для отправки и получения для всех интерфейсов IPv4 и модель сильного узла для отправки и получения для всех интерфейсов IPv6. Это поведение нельзя настроить. Набор протоколов TCP/IP нового поколения в Windows Vista и Windows Server 2008 поддерживает отправку и получение сильного узла для IPv4 и IPv6 по умолчанию для всех интерфейсов, кроме интерфейса туннелирования Teredo для связанной с узлом передачи Teredo. На рис. 4 перечислены команды, которые можно использовать для настройки поведения получения и отправки для IPv4 и IPv6 для отдельных интерфейсов. Обратите внимание, что InterfaceNameOrIndex является или именем интерфейса в папке «Сетевые подключения», или индексом интерфейса. Индекс интерфейса можно получить с помощью команды:
Figure 4 Команды для настройки поведения получения и отправки сильного и слабого узлов (Close Figure 4)

• netsh interface ipv4 set interface [InterfaceNameOrIndex] weakhostsend=enabled|disabled
• netsh interface ipv4 set interface [InterfaceNameOrIndex] weakhostreceive=enabled|disabled
• netsh interface ipv6 set interface [InterfaceNameOrIndex] weakhostsend=enabled|disabled
• netsh interface ipv6 set interface [InterfaceNameOrIndex] weakhostreceive=enabled|disabled
netsh interface ipv6 show interface
Поведение слабого и сильного узлов и спецификация RFC 3484
Для предоставления стандартизированного способа выбора адресов отправителя и адресов назначения IPv6 и IPv4 для выполнения подключений спецификация RFC 3484 определяет два алгоритма. Первым является алгоритм выбора адреса отправителя, позволяющий выбрать наилучший адрес отправителя для использования с адресом назначения. Вторым является алгоритм выбора адреса назначения для упорядочения списка возможных адресов назначения в предпочитаемом порядке.
Поведение сильного и слабого узлов активируется после определения списка потенциальных адресов отправителя для определенного адреса назначения; это также влияет на окончательный упорядоченный список адресов назначения. Для поведения отправки сильного узла список потенциальных адресов отправителя состоит из адресов одноадресной рассылки, назначенных отправляющему интерфейсу для назначения. Для поведения отправки слабого узла список кандидатов может включать адреса, назначенные любому интерфейсу со включенной отправкой слабого узла. Дополнительные сведения о выборе адреса отправителя и адреса назначения приведены в статье на веб-узле microsoft.com/technet/community/columns/cableguy/cg0206.mspx.

По умолчанию отправка и получение слабого узла отключены для IPv4 и IPv6 для всех интерфейсов, кроме интерфейса туннелирования Teredo для связанной с узлом передачи Teredo.
Дополнительные сведения о спецификации RFC 3484 приведены на врезке «Поведение слабого и сильного узлов и спецификация RFC 3484».

Отключение ролей по умолчанию для подключений VPN удаленного доступа
Клиент виртуальной частной сети (VPN) удаленного доступа является другим примером многосетевого узла. Даже если узел имеет один интерфейс локальной сети, подключенный к Интернету, когда клиент VPN удаленного доступа выполняет подключение к VPN, он является многосетевым. Он имеет два интерфейса: интерфейс локальной сети и интерфейс на основе протокола PPP для подключения VPN. Он также имеет два IPv4-адреса: назначенный поставщиком услуг Интернета IPv4-адрес для интерфейса локальной сети и назначенный сервером VPN IPv4-адрес для интерфейса на основе протокола PPP.
Для обеспечения отправки VPN-клиентом трафика маршрута по умолчанию интрасети через VPN-подключение Windows XP и Windows Server 2003 изменяют таблицу маршрутизации IPv4, повышая метрику существующего маршрута по умолчанию и добавляя новый маршрут по умолчанию с более низкой метрикой, использующий интерфейс PPP. Это поведение по умолчанию на время подключения к VPN делает расположения в интрасети доступными и почти все расположения в Интернете недоступными. Можно настроить VPN-клиент для разделения туннелирования, чтобы можно было одновременно иметь доступ к расположениям интрасети и Интернета, не добавляя маршрут по умолчанию для подключения VPN и добавляя определенные маршруты для назначений интрасети. Однако существует опасность маршрутизации VPN-клиентами с разделенным туннелированием пакетов между Интернетом и интрасетью. Дополнительные сведения приведены на веб-узле microsoft.com/technet/community/columns/cableguy/cg1003.mspx.
Поведение клиента VPN по умолчанию в Windows XP и Windows Server 2003 было разработано для поведения отправки слабого клиента. При поиске маршрута всегда используется маршрут по умолчанию для подключения VPN, поскольку он имеет наименьшую метрику. Однако при использовании поведения отправки сильного узла маршрут по умолчанию для отправки трафика зависит от IP-адреса отправителя, указанного в пакете. При поиске маршрута для трафика с IPv4-адреса, назначенного поставщиком услуг Интернета, будет использоваться маршрут по умолчанию, использующий интерфейс локальной сети, делающий все расположения Интернета доступными. При поиске маршрута для трафика с IPv4-адреса, назначенного сервером VPN, будет использоваться маршрут по умолчанию, использующий интерфейс протокола PPP, делающий все расположения интрасети доступными, поэтому при использовании поведения отправки сильного узла клиент VPN имеет настройку разделенного туннелирования и одновременный доступ к Интернету и интрасети, даже для приложений без прав администратора на непосредственное изменение таблицы маршрутизации IPv4.
Для предотвращения создания поведением отправки сильного узла настройки разделенного туннелирования по умолчанию клиент VPN в Windows Vista® и Windows Server 2008 автоматически отключает маршруты по умолчанию интерфейсов локальной сети после завершения подключения VPN. Это поведение обеспечивает наличие только одного активного маршрута по умолчанию в таблице маршрутизации, использующей интерфейс протокола PPP. Это поведение также предотвращает выполнение разделенного туннелирования приложениями без прав администратора.
Поскольку источником трафика от компьютера VPN-клиента должен являться IPv4-адрес, назначенный сервером VPN, такое поведение обеспечивает лучшую изоляцию интрасети от Интернета. После завершения подключения VPN происходит включение отключенных маршрутов по умолчанию.
Этим поведением можно управлять с помощью параметра:
netsh interface ipv4 set interface [InterfaceNameOrIndex]
ignoredefaultroutes=enabled|disabled

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


 Windows PowerShell: Обеспечение безопасности Shell
Windows PowerShell
Обеспечение безопасности Shell
Дон Джонс (Don Jones)

Когда команда, работавшая над созданием Windows PowerShell, засела за создание новой оболочки и за столом прозвучало слово «сценарии», скорбные стоны были, вероятно, слышны на весь Редмонд. В конце концов, предыдущие опыты Майкрософт в области сценариев администрирования — здесь я имею в виду VBScript — нельзя назвать лишенными недостатков. Излишне
либеральная модель выполнения в сочетании с привычкой большинства пользователей входить в систему с полными правами администратора проложила дорогу для несчастья.
«Только бы, — должно быть, молились собравшиеся на первом рабочем совещании по Windows PowerShell™, — не пришлось нам испытать все это снова». Не пришлось. Корпорация Майкрософт значительно улучшила свою репутацию по части безопасности, во многом потому, что начала обращать на нее внимание в первую очередь, а не на поздних этапах разработки программного обеспечения. Такой подход весьма заметен в Windows PowerShell.

Почему не запускаются мои сценарии?
Установите Windows PowerShell на свежем компьютере и дважды щелкните файл PS1: появится Notepad, а не Windows PowerShell. Это произойдет потому, что расширение имени файла PS1 — расширение, используемое для сценариев Windows PowerShell, — не сопоставляется с самой оболочкой. Другими словами, сценарии не запускаются простым двойным щелчком. Единственный способ запустить сценарий — открыть Windows PowerShell, ввести имя сценария и нажать клавишу ВВОД.
На самом деле, простого ввода имени сценария тоже недостаточно. Как можно увидеть на Рис. 1, файл Demo1.ps1 находится в текущей папке, однако ввод demo1 и нажатие клавиши ВВОД заканчивается ошибкой: «Терм 'demo1' не опознан как командлет, функция, выполнимая программа или файл сценария». Почему это происходит? Ведь файл находится там, где надо.
Рис. 1 Windows PowerShell требует путь к сценарию в целях предотвращения подмены команд
Рис. 1 Windows PowerShell требует путь к сценарию в целях предотвращения подмены команд
Это еще один аспект модели безопасности Windows PowerShell. Один из приемов, часто используемых злоумышленниками в других оболочках, заключается в создании сценария с тем же именем, что и встроенная команда. Для примера, если злоумышленник хочет, чтобы пользователь запустил его сценарий, он может назвать его Dir.ps1 и забросить в какую-нибудь папку. Если пользователь имел несчастье ввести Dir и нажать клавишу ВВОД, запустится не команда Dir, которую он ожидал, а сценарий злоумышленника. Этот прием называется подменой команд. В Windows PowerShell пользователь всегда должен указать путь к такому сценарию, что делает оболочку Windows PowerShell весьма хорошо защищенной от подмены команд.
Запустить demo1 не получается из-за отсутствия пути, но запуск ./demo1 работает. Происходит это потому, что теперь я указал путь — текущую папку. Такую командную строку сложнее спутать со встроенной командой, поскольку при обращении к встроенной команде не указывается путь. Таким образом, требование пути помогает Windows PowerShell избежать подмены команд и неуверенности относительно последствий нажатия клавиши ВВОД.

Политика выполнения сценариев
Допустим, у пользователя есть свежеустановленная копия Windows PowerShell, он использует правильный синтаксис и пытается запустить сценарий. К его удивлению, он сталкивается с очередным сообщением об ошибке, информирующим его, что Windows PowerShell не позволено запускать сценарии. Что такое??? Позвольте представить. Политика выполнения оболочки.
Текущую политику выполнения можно увидеть, запустив Get-ExecutionPolicy в оболочке. По умолчанию она установлена на Restricted, что попросту означает запрет на запуск сценариев. Полный запрет. Для всех. По умолчанию оболочку Windows PowerShell можно использовать только интерактивно, но не для запуска сценариев. Командлет Set-ExecutionPolicy можно использовать для выбора одного из четырех режимов политики выполнения:
  • Restricted, настройка по умолчанию, не допускает запуска сценариев.
  • AllSigned допускает запуск лишь доверенных сценариев (подробнее об этом рассказано чуть ниже).
  • RemoteSigned допускает запуск локальных сценариев, даже если они не являются доверенными, однако сценарии, загруженные из Интернета, должны быть доверенными для возможности их запуска.
  • Unrestricted допускает запуск всех сценариев, даже не являющихся доверенными.
Откровенно говоря, AllSigned — минимальный режим для рабочего компьютера. RemoteSigned я нахожу полезным для разработки и тестирования, но вряд ли он необходим среднему пользователю. Unrestricted же мне кажется ненужным, и я не стал бы возражать, если бы в одной из будущих версий Windows PowerShell этот чрезмерно либеральный режим был полностью исключен.

Это вопрос доверия
Компьютер любого пользователя заранее настроен на то, чтобы считать доверенными определенные корневые центры сертификации — то есть серверы, выпускающие цифровые сертификаты. На Рис. 2 показано приложение панели управления «Свойства обозревателя», перечисляющее доверенные корневые CA. В Windows Vista®, этот список весьма короток, включая лишь несколько крупных коммерческих центров сертификации. В Windows® XP, напротив, список по умолчанию настолько велик, что о многих корневых центрах сертификации из него я никогда не слышал ранее. Помещая центр сертификации в этот список, пользователь, по сути, говорит, что он доверяет компании, управляющей корневым центром сертификации, и ее дотошности при проверке тех, кому она поставляет цифровые сертификаты.
При получении цифрового сертификата класса III — часто именуемого сертификатом подписывания кода — центр сертификации (который может быть коммерческим центром сертификации или частным центром сертификации, существующим в рамках организации пользователя) должен удостовериться в личности пользователя. Цифровой сертификат подобен электронному паспорту или идентификационной карте. Скажем, перед выдачей мне идентификатора, говорящего, что я Дон Джонс, центру сертификации нужно предпринять определенные шаги, чтобы удостовериться, действительно ли я Дон Джонс. При использовании своего сертификата для установки цифровой подписи на сценарий Windows PowerShell, что делается с помощью командлета Set-AuthenticodeSignature, пользователь ставит на него подпись со своим именем. Само собой, если ему удалось добыть фальшивый сертификат с чужим именем, он может использовать его для подписывания сценария, почему и важно, чтобы список на Рис 2 содержал только достойные доверия центры сертификации.
Рис. 2 Доверенные корневые центры сертификации по умолчанию в Windows Vista
Рис. 2 Доверенные корневые центры сертификации по умолчанию в Windows Vista
Когда Windows PowerShell проверяет, является ли сценарий доверенным — что она делает при режимах политики выполнения AllSigned и RemoteSigned — она ставит три вопроса:
  • Подписан ли сценарий? Если нет, он не является доверенным.
  • Цела ли подпись? Другими словами, не изменялся ли сценарий после подписывания? Если подпись не цела, сценарий не является доверенным.
  • Была ли подпись создана при помощи цифрового сертификата, выпущенного доверенным корневым центром сертификации? Если нет, он не является доверенным.
Командлет месяца: Set-AuthenticodeSignature
Set-AuthenticodeSignature — ключевой элемент цифрового подписывания сценариев Windows PowerShell, позволяющий пользователю применять наиболее безопасную политику выполнения, AllSigned. Для использования этого командлета, нужно начать с другого — Get-ChildItem — который получает установленный сертификат подписывания кода:
$cert = Get-ChildItem –Path cert:\CurrentUser\my –codeSigningCert
Здесь необходимо заменить путь к файлу на другой, указывающий на установленный сертификат — любой установленный сертификат будет доступен через cert: drive. После загрузки сертификата запустите следующий файл для подписывания сценария:
Set-AuthenticodeSignature MyScript.ps1
–cert $cert
Само собой, нужно предоставить полный путь к файлу сценария PS1. Оболочка добавит блок подписи к сценарию.

Как система доверия улучшает безопасность? Конечно, хакер, в принципе, может написать вредоносный сценарий, подписать его и убедить кого-нибудь в среде пользователя исполнить его. Поскольку сценарий был подписан, он запустится. Но подпись можно использовать для обнаружения личности автора и принятия соответствующих мер (таких, как обращение в правоохранительные органы). Впрочем, только законченный дурак может подписать вредоносный сценарий своим собственным именем!
Само собой, если пользователь-злоумышленник сумел добыть сертификат под чужим именем — скажем, от центра сертификации, не располагающего надежной процедурой проверки личности — подпись не удастся использовать для обнаружения настоящего виновника. Именно поэтому от корневых центров сертификации требуется наличие удовлетворительной для пользователя процедуры проверки личности.
При использовании режима политики выполнения AllSigned пользователю даже необходимо ставить цифровые подписи на все сценарии, созданные им самим, прежде чем запускать их. Использовать командлет Set-AuthenticodeSignature довольно легко, но все же это может стать изрядным препятствием. Тут-то и может пригодиться программное обеспечение от сторонних производителей. Я рекомендую выбрать редактор сценариев или среду визуальной разработки, автоматически подписывающую сценарии, используя указанный ей сертификат. Это делает использование подписей прозрачным и не требующим дополнительных усилий. Чтобы получить совет насчет редакторов и сред разработки, поддерживающих данную функцию, можно пройтись по сетевым форумам создателей сценариев (таким, как мой веб-узел ScriptingAnswers.com) и создать сообщение, спрашивающее у любителей Windows PowerShell, что они используют.
По получении сертификата можно также запустить следующую команду, чтобы подписать все сценарии, находящиеся в определенном месте:
Get-Childitem *.ps1 | %{Set-AuthenticodeSignature $_.fullname $cert}

Централизованная безопасность
Политику выполнения Windows PowerShell, можно, само собой, устанавливать отдельно на каждом компьютере. Но это решение не является удовлетворительным для корпоративных сред. Вместо него можно использовать групповую политику. (Административные шаблоны Windows PowerShell можно загрузить с go.microsoft.com/fwlink/?LinkId=93675.) Просто перетащите файл в объект групповой политики (GPO), действующий на домен в целом, и установите для него режим Restricted. Таким образом, можно быть уверенным, что где бы ни была установлена оболочка Windows PowerShell, сценарии не станут запускаться. Затем можно применить более либеральный режим (скажем, AllSigned) для тех компьютеров, где предполагается запускать сценарии (таких, как собственная рабочая станция).

Альтернативные учетные данных
В отличие от всех предыдущих административных языков сценариев для Windows, Windows PowerShell даже готова к безопасной работе с альтернативными учетными данными. Например, командлет Get-WMIObject имеет параметр –credential, который позволяет указать альтернативные учетные данные для удаленных подключений WMI. Данный параметр может принять имя пользователя, но не пароль, не позволяя жестко программировать конфиденциальные пароли в сценарий в формате открытого текста. Вместо этого, после предоставления имени пользователя, Windows PowerShell запрашивает пароль, используя диалоговое окно. Если планируется использовать альтернативные учетные данные снова, сведения, относящиеся к проверке подлинности, можно сохранить при помощи командлета Get-Credential:
$cred = Get-Credential DOMAIN\USER
Последует немедленный запрос пароля, и итоговые учетные данные будут сохранены в переменной $cred. Переменная $cred может затем передаваться параметру –credential настолько часто, насколько нужно. Можно даже использовать командлеты ConvertTo-SecureString и ConvertFrom-SecureString для преобразования учетных данных в зашифрованную строку, или ранее зашифрованной строки обратно в учетные данные.
Однако при этом ключ шифрования оказывается хранимым в обычном текстовом сценарии, что начисто разрушает безопасность. Так что вместо этого можно добавить вызов Get-Credential в профиль Windows PowerShell. Впоследствии при запусках Windows PowerShell будет немедленно следовать запрос имени пользователя и пароля, сохраняемых затем в переменной $cred. Таким образом, переменная $cred всегда остается доступной в оболочке, представляя учетную запись администратора домена. Волноваться о хранении этих учетных данных больше не придется — поскольку они воссоздаются при каждом запуске оболочки, их не нужно хранить.

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

Дон Джонс (Don Jones) — ведущий программист компании SAPIEN Technologies и преподаватель на ScriptingTraining.com. Связаться с ним можно через его веб-узел ScriptingAnswers.com.


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

Отношения очень важны. Но откуда сценаристам знать, что отношения важны? Ну, для начала мы часто смотрим телевизор, а по телевизору нам рассказывают о важности отношений.
И об этом говорят не только в сериалах или художественных фильмах. Например, одна кредитная компания выпустила рекламу, которая привлекает к ним людей. Это происходит потому, что они хотят одолжить деньги тем людям, которые не могут получить кредит? Нет. Может быть, потому, что они дают кредит под 900 процентов годовых? Конечно, нет. Люди приходят к ним, потому что эта компания устанавливает с клиентами персональные отношения. В их рекламе так и говорится: «Отношения очень важны».
Примечание: конечно, мы плачем, и не стыдимся этого. Надо быть очень толстокожим, чтобы не расплакаться от одной мысли о глубоких и неразрывных связях, которые устанавливаются между человеком и его кредитной компанией.
Разумеется, мы знаем, о чем вы думаете: «Бог мой, если отношения важны для кредитных компаний, то они должны быть исключительно важны для людей, которые пишут сценарии, взаимодействующие с базами данных». Дело в том, что отношения действительно должны быть важны для людей, которые пишут сценарии, взаимодействующие с базами данных. К сожалению, тем не менее, эти авторы сценариев не всегда понимают, что отношения важны. Но это не страшно. В статье этого месяца мы все расставим по местам.
Мы знаем, что множество системных администраторов использует базы данных, зачастую в качестве средства для инвентаризации оборудования. Проблема в том, что многие из этих баз данных настроены не самым лучшим образом. Предположим, что вам нужна база данных, которая отслеживает диски на всех ваших компьютерах. Если у вас нет опыта в проектировании баз данных, то вы, скорее всего, захотите создать базу данных в виде таблицы, как показано на Рис. 1.
Рис. 1 Однотабличная база данных
Рис. 1 Однотабличная база данных
Как видите, ее очень просто создать: здесь присутствует только поле для названия компьютера и пара полей «Да/Нет» для обозначения того, если ли у компьютера диск C: и диск D:. И это все. Четко, понятно и по существу.
Так что плохого в такой базе данных? Если честно — то все. Если вы уверены, что ни у одного из ваших компьютеров не будет более двух дисков, эта схема будет более или менее рабочей. Однако что произойдет, если появится компьютер, у которого три диска? В этом случае вам придется добавлять еще одно поле, которое будет отслеживать диск E. Ладно, а что делать, если у компьютера будет одиннадцать дисков? А если вам еще нужно будет отслеживать параметры каждого из этих дисков? Например, вам потребуется отслеживать общий размер каждого диска. В этом случае вам понадобится поле Drive_C_Size. И поле Drive_D_Size. И поле Drive_E_Size, и... ну, в общем, вы поняли идею. (И упаси вас бог отслеживать свободное пространство на диске, тип интерфейса диска, включены ли для этого диска дисковые квоты и так далее.)
Необходимо запомнить одно основное правило: каждый раз, когда у предмета есть что-либо в количестве более одного (например, у компьютера может быть больше одного диска), такой «двухмерный» (однотабличный) подход лучше не использовать. Разумеется, в случае с количеством дисков вы можете подумать, что с этой проблемой легко справиться; в конце концов, к компьютеру может быть подключено ограниченное количество дисков. Но предположим, вам понадобится список всех дисков размером 100 гигабайт или больше, и вы решите составить запрос к базе данных. Как вы это сделаете? Сначала вам придется найти 100-гигабайтные диски в поле Drive_C_Size field, потом то же самое в поле Drive_D_Size, потом поле Drive_E_Size, потом... В общем, не очень эффективный и оправдывающий себя подход. А какова альтернатива? Если нельзя использовать «двухмерную» базу данных, что можно использовать?
Это просто: реляционную базу. Реляционные базы спроектированы, помимо прочего, чтобы заниматься отношениями «один ко многим» (например, в случае компьютера, у которого много дисков). И перед тем, как вы спросите — нет, вам не нужно никуда идти и покупать что-то новое для использования реляционной базы; если у вас есть любая база данных (Microsoft® Access™, SQL Server™, Oracle, что угодно другое), существует большая вероятность, что у вас уже есть реляционная база. Не нужно ничего покупать; вам нужно только знать две вещи: 1) как установить отношения между двумя таблицами в этой базе данных; и 2) как написать сценарий, который использует это отношение в своих интересах.
Примечание: как нас учат по телевизору, никогда не нужно использовать отношения в своих интересах. Но это не та ситуация.
Так как эта рубрика называется не «Привет, проектировщик баз данных!», мы не будем обсуждать тут, как работать с базами данных. Вместо этого мы покажем вам простую реляционную базу данных, которая позволит нам поговорить о том, как писать реляционные запросы. В этой базе данных у нас есть две таблицы. Первая называется Computers и состоит из пары полей: ComputerName и SerialNumber. В поле ComputerName мы будем хранить название компьютера, а в поле SerialNumber будет храниться — ну, вы уже сами догадались. Точно, серийный номер.
Тогда где мы собираемся размещать информацию о наших дисках? Она пойдет в нашу вторую таблицу, которая называется DiskDrives. В этой таблице три поля, назначение которых ясно из названия: SerialNumber, DriveLetter и DriveSize.
Основное поле этой таблицы — SerialNumber. Если это название кажется знакомым, то так и должно быть: точно такое же поле есть в нашей таблице Computers. И это не случайность и не совпадение; мы сделали это специально. Для того чтобы установить отношения между этими двумя таблицами, нам нужно одно общее для обеих таблиц поле; так мы сможем определить, какой диск какому компьютеру принадлежит.
Почему мы решили объединить две таблицы при помощи серийного номера, а не названия компьютера, например? Этому есть хорошее объяснение: названия компьютеров могут изменяться (и это происходит довольно часто). Серийные номера обычно остаются неизменными.
Но хватит разговоров. Давайте посмотрим на Рис. 2, где мы увидим сценарий, который может производить поиск в этих двух таблицах и выводить список дисков, принадлежащих каждому компьютеру. Рисунок 3 показывает, какие данные возвращает этот сценарий.
Figure 3 Результаты поиска (Close Figure 3)
atl-ws-01
C:

atl-ws-01
D:

atl-ws-01
E:

atl-ws-02
C:

atl-ws-02
D:
Figure 2 Поиск в таблицах (Close Figure 2)
Const adOpenStatic = 3
Const adLockOptimistic = 3

Set objConnection = CreateObject("ADODB.Connection")
Set objRecordSet = CreateObject("ADODB.Recordset")

objConnection.Open _
 "Provider = Microsoft.Jet.OLEDB.4.0; " & _
 "Data Source = c:\scripts\test.mdb"

objRecordSet.Open "SELECT Computers.*, DiskDrives.* FROM Computers " & _
 "INNER JOIN DiskDrives ON Computers.SerialNumber = DiskDrives.SerialNumber " & _
 "ORDER BY Computers.ComputerName, DiskDrives.Drive", objConnection, adOpenStatic, _
  adLockOptimistic

objRecordSet.MoveFirst

Do Until objRecordset.EOF
 Wscript.Echo objRecordset.Fields.Item("ComputerName")
 Wscript.Echo objRecordset.Fields.Item("Drive")
 Wscript.Echo
 objRecordset.MoveNext
Loop

objRecordSet.Close
objConnection.Close
Мы не будем обсуждать в этой статье основы соединения и работы с базами данных: если вы новичок в написании сценариев для баз данных, вам, возможно, следует воспользоваться веб-трансляцией группы Scripting Guys «Написание сценариев для баз данных для системных администраторов» (go.microsoft.com/fwlink/?LinkId=22089). Могу лишь сказать, что мы подключаемся к базе данных Access (C:\Scripts\Test.mdb) и работаем с реляционными таблицами, которые называются Computers и DiskDrives. Но это должно быть и так понятно из сценария.
Ну хорошо, скажем еще, что вам необходимо произвести одно небольшое изменение, чтобы система заработала с Access 2007: нужно изменить поставщика с Microsoft.Jet.OLEDB.4.0 на Microsoft.ACE.OLEDB.12.0 примерно таким образом:
objConnection.Open _
 "Provider = Microsoft.ACE.OLEDB.12.0; " & _
 "Data Source = c:\scripts\test.accdb"
И все. Мы же собираемся сосредоточиться на запросе SQL, который извлекает данные из наших двух таблиц:
objRecordSet.Open "SELECT Computers.*, " & _
 "DiskDrives.* FROM Computers " & _
 "INNER JOIN DiskDrives ON " & _
 "Computers.SerialNumber = " & _
 "DiskDrives.SerialNumber " & _
 "ORDER BY ComputerName, Drive", _
 objConnection, adOpenStatic, adLockOptimistic
Сложно? Ну, может быть, немного. Поэтому попробуем разбить это на части — возможно, тогда все это усвоится легче.
Первая часть нашего запроса очень простая. Мы хотим выбрать все поля в обеих таблицах: Computers и DiskDrives. Эта часть SQL принимает следующий вид:
SELECT Computers.*, DiskDrives.*
Не так и плохо; нет нужды говорить, что «звездочка» — это просто подстановочный символ, означающий «все».
Если вы раньше писали запросы SQL (или вы писали запросы инструментария управления Windows®, или WMI, использующего подмножества языка запросов SQL), то вам знакома процедура: после указания элементов для выбора вы указываете, откуда эти элементы должны выбираться Так создается следующая часть нашего запроса-головоломки:
FROM Computers INNER JOIN DiskDrives ON Computers.SerialNumber = DiskDrives.SerialNumber
Это не должно вас отпугивать. Это действительно сложнее, чем обычная инструкция FROM, но на то есть причины. В конце концов, в обычном запросе SQL мы только выбираем данные из одной таблицы; в данном же случае мы выбираем данные из двух таблиц одновременно.
Давайте обратим внимание на синтаксис и на то, как он работает. Как видите, мы просим сценарий выбрать данные из таблицы Computers и из таблицы DiskDrives. Обратите внимание, что мы не используем союз «и»; вместо этого мы используем термин INNER JOIN. Этот термин определяет тип отношений и, в свою очередь, описывает то, как мы можем объединить информацию из двух отдельных таблиц в одно подмножество записей. (Да, существуют и другие типы объединений — о них мы расскажем ниже.)
Как мы и говорили, нам самим необходимо указывать тип отношений, существующих между нашими таблицами; точно также именно мы должны указать, как эти таблицы будут относиться друг к другу. Эту функцию за нас выполняет следующая часть кода:
ON Computers.SerialNumber = DiskDrives.SerialNumber
Здесь мы определяем, каким образом мы будем объединять наши таблицы. Записи будут группироваться всякий раз, когда поле SerialNumber в таблице Computers будет совпадать с полем SerialNumber в таблице DiskDrives. А если бы мы использовали другое поле (например, ComputerName) в качестве объединяющего поля? В этом случае наш код выглядел бы следующим образом:
ON Computers.ComputerName = DiskDrives.ComputerName
Если вы еще не поняли, то у обоих полей не обязательно должны быть одинаковые названия; они просто должны содержать одни и те же данные. Использование одинакового названия просто облегчает идентификацию реляционного поля. Есть только одна особенность, о которой нужно знать: поскольку у нас два поля с одинаковым названием, нам нужно всегда использовать синтаксис TableName.Field.Name при ссылках на какое-либо из этих полей. Это означает использование кода следующим образом: Wscript.Echo obj- Recordset.Fields.Item("Computers.SerialNumber").
Это все, что нам нужно; остальная часть запроса всего лишь упорядочивает данные сначала по названию компьютера, а затем по диску:
ORDER BY ComputerName, Drive
Видите, это совсем не сложно, правда? Теперь сделаем небольшую паузу и поговорим об объединениях. Зачем мы использовали внутреннее объединение для нашего запроса? Это просто. Внутреннее объединение возвращает только записи с совпадающими значениями по каждой из таблиц. Другими словами, предположим, что у нас есть серийный номер 121989. Если этот серийный номер появляется в обеих таблицах Computers и DiskDrives, то будут возвращены соответствующие записи. (Разумеется, серийный номер где угодно не валяется — он должен быть в поле SerialNumber.) Пока понятно? Хорошо.
Теперь предположим, что у нас есть компьютер с серийным номером 121989; однако у нас нет дисков с таким же серийным номером. В этом случае нам не будет возвращено никаких данных с серийным номером 121989. Это происходит потому, что внутреннее объединение возвращает информацию только в том случае, если у записи есть совпадающие значение в обеих объединенных таблицах.
Другими словами, запрос внутреннего объединения возвращает информацию обо всех компьютерах, у которых есть жесткие диски. Он не возвращает информацию ни о компьютерах, у которых нет жестких дисков, ни о жестких дисках, не установленных на компьютерах. Это хорошо. В большинстве случаев это именно то, что нам нужно. Но если нам понадобится список компьютеров без жестких дисков или список жестких дисков без компьютеров? Что тогда делать?
Для этого существует внешнее объединение. (А, так вот для чего нужно внешнее объединение!) Пока что скажем лишь, что существует два различных вида внешних объединений: правое и левое. В нашей базе данных у нас есть две таблицы: Computers (считающаяся «левой» таблицей, поскольку это основная таблица) и DiskDrives (считающаяся «правой» таблицей, поскольку... в общем потому, что она не основная). Предположим, что нам нужно, чтобы наше возвращенное подмножество записей включало все компьютеры, даже те, на которых не установлены диски. В этом случае мы используем синтаксис LEFT OUTER JOIN, и запрос будет выглядеть следующим образом:
objRecordSet.Open "SELECT Computers.*, " & _
 "DiskDrives.* FROM Computers " & _
 "LEFT OUTER JOIN DiskDrives ON " & _
 "Computers.SerialNumber = " & _
 "DiskDrives.SerialNumber " & _
 "ORDER BY ComputerName, Drive", _
 objConnection, adOpenStatic, adLockOptimistic
Как вы, вероятно, поняли, левое внешнее объединение возвращает все записи из левой таблицы, даже если в правой таблице не нашлось соответствий. Таким образом, мы получаем информацию обо всех компьютерах, а из правой таблицы (диски) — только записи, связанные с компьютером.
Точно таким же образом мы можем получить список всех дисков, включая те, что не установлены на компьютере. Поскольку таблица DiskDrives является правой таблицей в отношении, мы используем синтаксис RIGHT OUTER JOIN следующим образом:
objRecordSet.Open "SELECT Computers.*, " & _
 "DiskDrives.* FROM Computers " & _
 "RIGHT OUTER JOIN DiskDrives ON " & _
 "Computers.SerialNumber = " & _
 "DiskDrives.SerialNumber " & _
 "ORDER BY ComputerName, Drive", _
 objConnection, adOpenStatic, adLockOptimistic
Если подумать, то, поскольку DiskDrives является правой таблицей в отношении, таблица Computers по полному праву может считаться таблицей мужа, а не левой таблицей. На своем горьком опыте некоторые из сценаристов знают, что муж никогда не является правым элементом отношений.
Используя правое внешнее объединение, мы получаем обратно все записи из правой таблицы (все диски) и только те компьютеры (записи из левой таблицы), которые связаны с диском.
Возможно, пока вы не видите в этом большого смысла, но если немного поэкспериментируете с этим, то узнаете принципы работы. Если вам нужна база данных для экспериментов, можете воспользоваться образцом, который мы разместили на узле microsoft.com/technet/scriptcenter/resources/tnmag/archive.mspx.
Необходимо упомянуть, что всякий раз, когда вы используете внешнее объединение, вы также должны, по крайней мере, сделать On Error Resume Next первой строчкой вашего сценария. Зачем? Предположим, что мы произвели левое внешнее объединение. В этом случае мы, возможно, получим компьютеры, на которых не установлено никаких жестких дисков. Это нормально (в конце концов, это именно то, что мы хотим получить). По крайней мере, до тех пор, пока мы не встретим вот такую строку кода, которая выводит букву диска:
Wscript.Echo objRecordset.Fields.Item("Drive")
Поскольку для этого конкретного компьютера не существует поля дисков, сценарий будет прерван по сбою:
C:\Scripts\database.vbs(22, 9) Microsoft VBScript runtime error: Type mismatch
Однако, если мы будем применять On Error Resume Next, сценарий сможет проигнорировать тот факт, что у компьютера нет дисков, и спокойно продолжить свою работу. Точно также вы можете использовать следующий код для проверки значения поля дисков и принятия соответствующих мер:
If IsNull(objRecordset.Fields.Item("Drive")) _Then
    Wscript.Echo "No disk drives installed."
Else
    Wscript.Echo _
      objRecordset.Fields.Item("Drive")
End If
При помощи этого кода мы проверяем, получим ли мы нулевое значение вместо фактической буквы диска. В этом случае мы получим сообщение «нет установленных дисков». Если мы не получаем нулевого значения, то мы получаем значение поля диска. Получаемый результат показан на Рис. 4.
Figure 4 Показать соответствующие результаты (Close Figure 4)
atl-ws-01
C:

atl-ws-01
D:

atl-ws-02
C:

atl-ws-02
D:

alt-ws-03
No disk drives installed.
Не вдаваясь в долгие объяснения, приведем еще несколько примеров запросов. Например, здесь перед нами запрос внутреннего объединения, возвращающий список компьютеров и установленных на них дисках с учетом того, что размер каждого из этих дисков больше 50 гигабайт (по умолчанию считается, что размер дисков считается в гигабайтах):
objRecordSet.Open "SELECT Computers.*, " & _
 "DiskDrives.* FROM Computers " & _
 "INNER JOIN DiskDrives ON " & _
 "Computers.SerialNumber = " & _
 "DiskDrives.SerialNumber " & _
 "WHERE DriveSize > 50 " & _
 "ORDER BY Computers.ComputerName, " & _
 "DiskDrives.Drive", objConnection, _
 adOpenStatic, adLockOptimistic
Как можно видеть, мы всего лишь добавили стандартное предложение WHERE к исходному запросу:
WHERE DriveSize > 50
А что если нам была нужна информация только о диске E на компьютерах? Никаких проблем — просто добавьте соответствующее предложение Where:
WHERE Drive = 'E:'
А вот чуть более сложный запрос, возвращающий коллекцию компьютеров, на которых нет установленных дисков:
objRecordSet.Open _
 "SELECT Computers.ComputerName, " & _
 "DiskDrives.Drive " & _
 "FROM Computers LEFT JOIN DiskDrives " & _
 "ON Computers.SerialNumber = " & _
 "DiskDrives.SerialNumber " & _
 "GROUP BY Computers.ComputerName, " & _
 "DiskDrives.Drive " & _
 "HAVING (DiskDrives.Drive) Is Null " & _
 "ORDER BY Computers.ComputerName", _
 objConnection, adOpenStatic, adLockOptimistic
Как мы сказали, этот запрос чуть более сложный, и поскольку мы уже исчерпали место для статьи, мы не будем объяснять, как он работает. Но он работает, и это самое главное.
Ну, может быть, не самое главное, поскольку, как мы уже упоминали несколько раз, самое главное — это отношения. Что не означает, что отношения не могут пойти вкривь и вкось. Как сказал Вуди Аллен в конце своего фильма «Энни Холл»: «Отношения... как акула; они должны постоянно двигаться вперед, иначе они умрут. И мне кажется, что в данный момент перед нами именно мертвая акула». Ах, если бы только Вуди знал о существовании внешних и внутренних объединений. С этими методиками запроса ваши отношения всегда будут живы и успешны!

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


 Вопросы и ответы по Exchange: Установка, журнал сообщений, возможности хранения и другое
Вопросы и ответы по Exchange
Установка, журнал сообщений, возможности хранения и другое
Кей Си Лемсон (KC Lemson) and Нино Биллич (Nino Bilic)

Вопрос. Я запускаю установку Exchange Server 2007, меня интересует, могу ли я пропустить проверку предварительных условий. Я не хочу разбираться с теми техническими проблемами, на которые мне указала проверка предварительных условий, я бы хотел просто запустить установку и закончить на этом!

Ответ. Если ответить на ваш вопрос кратко, то нет, пропустить проверку предварительных условий нельзя. Вам действительно необходимо разобраться с теми проблемами, на которые указала проверка предварительных условий, если эти проблемы блокируют продолжение установки, иначе вы не сможете нормально работать с Exchange в дальнейшем.
Некоторые администраторы пытались изменить файл ExBPA.PreReqs.xml (в нем содержится список предварительных требований программы установки Exchange 2007), убирали проверки, которые блокируют установку. Но это не сработает, так как файл XML защищен цифровой подписью, и любые изменения его содержания сделают подпись недействительной.
Так сделано для того, чтобы вы не установили программу, которая не будет работать, как полагается. Мы протестировали работу Exchange 2007 в различных средах и убедились, что одни настройки и параметры работают лучше, нежели другие, а некоторые могут создать серьезные проблемы. Предварительные требования были введены для того, чтобы установка прошла максимально успешно, основываясь на нашем опыте и тестах.
Если вы столкнулись с настоящей проблемой в работе проверки готовности Exchange 2007 и она блокирует дальнейшую установку, свяжитесь со службой технической поддержки Exchange.

Вопрос. Где мне найти файл журнала установки? Не могу найти его в корневой папке диска C:\ .

Ответ. Все файлы журналов установки находятся в папке %SYSTEMDRIVE%\ExchangeSetupLogs, в большинстве случаев в c:\ExchangeSetupLogs. В папке лежит множество файлов, вам необходимы два из них:
ExchangeSetup.log В этом журнале содержится информация о задачах и параметрах, которые использовались при установке. Когда настраиваются роли сервера, информация о задачах, которые были запущены для настройки сервера, также записывается в этот журнал. Есть еще один файл, в котором присутствует информация, связанная с установкой вашего сервера. При установке пакета обновления информация будет дописана в конец этого же файла.
ExchangeSetup.msilog Этот файл содержит информацию о стадии распаковки процесса установки. Когда установщик Microsoft® копирует файлы в их место назначения из временной папки, он записывает журнал процесса в названный файл. Если у вас проблема, связанная со способностью скопировать файлы или с доступом к файлам во время установки, вам может помочь этот файл.

Вопрос. Как мне известно, проверка предварительных требований выполняется с помощью анализатора соответствия рекомендациям для Exchange Server (Exchange Server Best Practices Analyzer, BPA), где мне найти отчет о предварительных требованиях?
Ответ. Если вам требуется отчет, созданный BPA во время проверки предварительных требований, загляните в следующую папку:
%SYSTEMDRIVE%\Exchangesetuplogs\PreReqs
У имен файлов стандартный формат:
ExBPA.<dateandtime>.data.xml
Если вы хотели бы узнать, на что именно была нацелена проверка предварительных требований, найдите файл XML, в котором содержится представленное вам сообщение об ошибке. Чуть выше этого сообщения вы увидите определение проверяемого правила.
Вопрос. Как лучше читать файлы журналов установки? Какие существуют варианты?
Ответ. В целом есть два основных способа прочитать файлы журналов. Можно использовать командлет Get-SetupLog из командной консоли Exchange или просто открыть файлы журналов установки с помощью «Блокнота» или вашего любимого текстового редактора.
Ниже приведен пример, как можно найти любые предупреждение и ошибки при использовании Get-SetupLog:
Get-SetupLog c:\exchangesetuplogs\exchangesetup.log –error
Чтобы просматривать файлы стало еще приятней, можно использовать сценарии Out-HTML.ps1 и Out-IE.ps1 из демонстрационного пакета Exchange 2007 PowerShell Scriptacular. (Дополнительные сведения имеются на нашем блоге по адресу msexchangeteam.com/archive/2006/12/27/431998.aspx.)
Загрузив эти сценарии, поместите их в папку сценариев Exchange (по умолчанию c:\program files\microsoft\exchange server\scripts) и выполните следующую команду:
Get-SetupLog –tree:$false –error:$false | Where { $_.status –eq "Error" } | select datetime, depth, description, status | Out-HTML | Out-IE
В результате откроется окно простого в использовании обозревателя с представлением ошибок, которые могли произойти во время установки, в формате HTML (см рис. 1).
Рис. 1 Out-HTML и Out-IE делают представление файлов журналов установки более читаемым
Рис. 1 Out-HTML и Out-IE делают представление файлов журналов установки более читаемым
С другой стороны, если вы предпочитаете просматривать файл exchangesetup.log в «Блокноте», ниже приведено несколько советов:
  • Чтобы найти начало установки, осуществите поиск строки [0] Starting Microsoft Exchange 2007 Setup.
  • Чтобы найти конец установки, осуществите поиск строки [0] End of Setup.
  • Основные участки установки разделяются с помощью строки [0] **************.
  • Чтобы найти учетную запись, под которой производилась установка, осуществите поиск строки [0] Logged on user.
  • Чтобы узнать, какой контроллер домена использовался во время установки, осуществите поиск строки [0] Setup will use the domain controller.
При просмотре журналов установки через «Блокнот» следует начинать с конца файла и возвращаться обратно во времени, чтобы узнать, в чем заключалась проблема. Ошибки — обычно самая последняя информация, которая записывается в файл журнала.

Вопрос. Могу ли я использовать единую систему обмена сообщениями Exchange 2007 с моей УАТС?

Ответ. Скорее всего, можете. По адресу microsoft.com/technet/prodtechnol/exchange/telephony-advisor.mspx находится список поддерживаемых шлюзов VoIP и УАТС. Любые изменения списка поддерживаемых продуктов будут отражены на этой странице.
Вопрос. Я пользуюсь клиентом под управлением Small Business Server 2003 с Exchange. Политика компании требует, чтобы производилось наблюдение за всей почтой. Чтобы вести наблюдение, я бы хотел отправлять копию всей входящей и исходящей почты на учетную запись администратора. Как мне это осуществить?
Ответ. Журналирование сообщений — вот то, что вам необходимо. Оно позволит вам хранить копию всех сообщений, отправленных или полученных из определенной базы данных почты, в отдельном почтовом ящике-журнале. Есть множество параметров, которые позволяют определить, насколько подробными должны быть копии в журнале (например, следует ли показывать получателей скрытой копии BCC), кроме того, можно загрузить дополнительное средство, которое содержит некоторые усовершенствованные функции, по адресу go.microsoft.com/fwlink/?LinkId=93725. Журналирование в Exchange 2003 включено на уровне базы данных, таким образом, каждый пользователь базы попадает в журнал. Создав почтовый ящик для хранения сообщений, регистрируемых в журнале, откройте свойства хранилища почты в Диспетчере Exchange и установите флажок архивации сообщений, отправляемых или получаемых почтовым ящиками в том хранилище. В зависимости от ваших корпоративных политик, ваш Диспетчер почтовых ящиков может быть настроен так, чтобы старые копии удалялись автоматически из почтового ящика журнала.
В Exchange 2003 есть другая похожая на журнал функция — приемник архива (archive sink). В отличие от журнала, который сохраняет копии писем в другой почтовый ящик в Exchange, приемник архива сохраняет сообщения в указанную папку на жестком диске сервера. Какой метод выбрать? Журналирование предназначено для ситуаций контроля выполнения нормативных требований. Приемник архива может быть полезен, если вы хотели бы сохранить все сообщения, приходящие или уходящие в Интернет.
Exchange 2007 существенно упрощает эти ситуации, и вы можете легко вести журнал по одному пользователю или списку рассылки. Если не нужно, чтобы пользователи знали, что их почта регистрируется в журнале, можно скрыть список рассылки от глобального списка адресов (обратите внимание, что это не то же самое, что скрытое членство списка рассылки) или настроить особый атрибут для пользователей. Затем создайте группу рассылки на основе запроса (Query-Based Distribution Group, также называемую динамическим списком рассылки или DDL), чтобы выключить всех пользователей с этим атрибутом. Если нужно журналировать почту всей организации в одном и том же месте, оставьте поле получателя пустым, когда будете создавать правило журналирования. Кроме того, обратите внимание, что если нужно вести журнал не на основе баз данных в Exchange 2007, вам потребуется корпоративная клиентская лицензия (Client Access Licenses, CAL) для этих пользователей. Дополнительные сведения имеются на странице microsoft.com/exchange/howtobuy/licensingFAQ.mspx. Если использование CAL или какой-либо из этих функций нежелательно, можно и дальше использовать журнал на основе баз данных в Exchange 2003. Наконец, рекомендуем статью Дэвида Строма (David Strome) из декабрьского номера журнала TechNet за 2006 год под названием «Еще более производительное ведение журнала в Exchange 2007», она доступна по адресу technetmagazine.com/issues/2006/12/journaling.

Вопрос. Все мои пользователи работают в Microsoft Office 2003, и у нас пока нет планов переходить на Office 2007 до замены оборудования в 2008 году. Мне кажется, что они из-за этого упустят некоторые новые функции. Смогут ли они использовать единую систему обмена сообщениями?

Да, смогут. В Office 2003 единая система обмена сообщениями позволяет пользователям получать голосовую почту и факсы в их почтовые ящики. Кроме того, пользователи имеют доступ к своим почтовым ящикам по телефону. Если вы не обновитесь до Outlook 2007, вы не сможете настроить голосовую почту через вкладку «Параметры» в Outlook, также вы не сможете пользоваться специальной формой, которая появляется, когда вы получаете голосовую почту в Outlook, и благодаря которой не требуется дополнительный проигрыватель мультимедиа для прослушивания сообщений. Кроме того, возможность записывать звуковые заметки и сохранять их вместе с сообщением голосовой почты не будет доступна. Но даже без Outlook 2007 ваши пользователи единой системы обмена сообщениями могут работать с OWA 2007 для доступа к параметрам единой системы (на странице параметров OWA), а также к особой форме для голосовой почты в OWA.

Вопрос. В моей компании уже есть сеть хранения данных (Storage Area Network, SAN), и я бы хотел подключить Exchange 2007 к ней. Но я много всего слышал о системах хранения с прямым подключением (direct attached storage, DAS), и теперь я думаю, может, стоит выбрать тот вариант. Как вы считаете?

Ответ. На данный вопрос нет правильного или неправильного ответов, все зависит от политики вашей компании и ситуации (особенно если у вас уже есть SAN). Если вы размышляете над приобретением новой SAN, добавлением другой, или так или иначе думаете об обновлении, мы настоятельно рекомендуем вам DAS. Ниже приведена некоторая информация к сведению. По состоянию на июнь 2007, отдел ИТ корпорации Майкрософт установил 17 почтовых серверов Exchange 2007 на 40 000 ящиков (с квотами от 500 МБ до 10 ГБ), все с использованием кластерной непрерывной репликации (CCR) и DAS. К сентябрю мы планируем поставить 35 почтовых серверов Exchange 2007 на 152 500 ящиков, и все на DAS. Так что, если вы не можете решить, подходит ли DAS для корпоративного уровня, мы можем вас заверить, что подходит. DAS является вариантом, позволяющим отделу ИТ корпорации Майкрософт увеличивать квоты пользователей, при этом уменьшая общую стоимость хранения. Дополнительные сведения по данной топологии, развертыванию, экономии средств имеются по адресу microsoft.com/technet/itshowcase/content/64bitexchange2007.mspx.
Хотя может показаться, что можно много сэкономить при подключении всех ваших серверов к одной и той же SAN, существуют определенные риски. Например, проблемой, с которой мы сталкиваемся, является различные ситуации использования программного обеспечения, подключенного к SAN. Пусть у вас имеется приложение отдела кадров на SAN, которое, например, запускает пакетный процесс каждый вечер в 17:00, такие затраты на ввод-вывод могут серьезно повлиять на ваших пользователей Exchange. Отсутствие детерминированного ввода-вывода — часто встречающаяся проблема с совместно используемыми решениями SAN.
Преимуществом DAS, по нашему мнению, является простота управления, поскольку в этом случае не требуется отдельных администраторов по хранению или специального оборудования. Такое решение можно легко купить и расширить в дальнейшем. И оно в целом не так дорого, так что если возникнет необходимость создать запас по емкости, это не будет разорительным.

Вопрос. Я установил свой первый сервер Exchange 2007. Теперь при попытке подключится к нему с помощью Outlook 2003 появляется сообщение об ошибке, в нем говорится, что администратор заблокировал мою версию Outlook (Your Exchange Server administrator has blocked the version of Outlook that you are using. Contact your administrator for assistance.) Но я сам администратор и ничего не блокировал. В чем причина?

Ответ. Такое поведение не совсем неожиданно. Когда устанавливается Exchange 2007, программа установки спрашивает у вас, используете ли вы Outlook 2003 или предыдущие версии или клиенты Entourage в вашей организации (см. рис. 2). Если вы ответили «нет» на этот вопрос, у вас могут появиться проблемы.
Рис. 2 Вопрос о стандартном клиенте при установке Exchange 2007
Рис. 2 Вопрос о стандартном клиенте при установке Exchange 2007
Чтобы решить эту проблему уже после установки, вам необходимо создать хранилище общих папок с помощью консоли управления Exchange или командной консоли Exchange и перезапустить службу банка сообщений. В этом случае необходимо обязательно перезапустить службу банка сообщений, стандартные клиенты (Outlook 2003 и предыдущие версии) не смогут подключиться к серверу до того, как служба будет перезапущена.
Кроме того, если вы запустили автоматическую установку Exchange 2007, можно воспользоваться ключом /EnableLegacyOutlook, чтобы указать, как вы хотели бы отвечать на вопросы по устаревшим клиентам.

Вопрос. Почему для Exchange 2007 имеет значение, подключаюсь ли я к серверу с использованием старых версий Outlook? Почему создание хранилища общих папок и перезапуск службы банка сообщений решают эту проблему?

Ответ. Ответы на эти вопросы связаны с наличием хранилища общих папок. Хранилище общих папок в предыдущих версиях Exchange, кроме всего прочего, используется для хранения данных о том, свободны пользователи или заняты. Когда пользователь устаревшей версии Outlook подключен к своему серверу Exchange с помощью MAPI или RPC через HTTP и публикует что-либо в свой календарь, информация о его состоянии «Свободен/Занят» также публикуется на сервере в специальной общей папке, называемой Schedule+. Только таким образом клиенты устаревшей версии Outlook узнают о том, что были опубликованы данные «Свободен/Занят» на сервере, и только таким образом устаревшая версия Outlook узнает, как прочитать эту информацию о пользователях.
А Exchange 2007 знает об этом, поэтому он блокирует старые версии клиентов, если хранилища общих папок нет. В случае, если для Exchange 2007 разрешено подключение устаревших версий клиентов, то у них появятся частые ошибки, так как Outlook не сможет подключиться к хранилищу общих папок для публикации данных «Свободен/Занят». Функциональность клиента будет ограничена, так как поиск по состоянию «Свободен/Занят», который пользователю нужно выполнить (например, при попытке назначить встречу с кем-нибудь), просто не сработает. Создание хранилища общих папок решает проблему, так как сервер Exchange 2007 тогда знает, что стандартные клиенты могут использовать функциональность публикации состояния «Свободен/Занят», и, таким образом, разрешается подключение к почтовому ящику.
В итоге, можно отметить еще одну вещь: клиентам Outlook 2007 не требуется хранилище общих папок для публикации их информации «Свободен/Занят». Это верно, но существует небольшая уловка.
Не будем углубляться в подробности, но, если хранилище общих папок присутствует на сервере Exchange 2007, даже клиенты Outlook 2007 будут публиковать туда данные «Свободен/Занят». Так сделано, чтобы другие клиенты (некоторые из которых предположительно являются клиентами Outlook) могли осуществлять поиск информации «Свободен/Занят» для пользователя Outlook 2007. Если в хранилище общих папок нет информации, стандартные клиенты не найдут ее для пользователя Outlook 2007, так как до этого никто не поместил эту информацию в хранилище. Если нет хранилища общих папок, клиент Outlook 2007 будет пытаться публиковать данные «Свободен/Занят». Когда нет хранилищ общих папок и все клиенты являются клиентами Outlook 2007 или более поздних версий, используется другой механизм поиска информации «Свободен/Занят». При этом данные календаря читаются прямо из почтовых ящиков пользователей без создания копии этой информации где-либо. Дополнительные сведения по данному вопросу есть в разделе о службе доступности в вашем файле справки по серверу или в документации Exchange по адресу go.microsoft.com/fwlink/?LinkId=69434.

Вопрос. Я только что прочел статью базы знаний 288894, в которой рассказывается про блокировку клиентов MAPI с помощью раздела реестра (см. support.microsoft.com/kb/288894). Я проверил реестр моего сервера, но такой раздел не установлен. Как же все-таки происходит блокирование этого устаревшего клиента?

Ответ. Очень хороший вопрос! Действительно, банк сообщений Exchange 2007 не использует параметр реестра «Disable MAPI Clients», который упоминается в той статье базы знаний. Причина заключается в том, что существует вероятность, что нет хранилища общих папок, и, таким образом, никакие изменения раздела реестра не могут разблокировать те клиенты, если нет хранилища общих папок.
Поведение, при котором блокируются клиенты старше, чем Outlook 2007, жестко установлено в банке сообщений Exchange 2007. Во время запуска службы хранилище проверяет, присутствует ли хранилище общих папок, затем принимает решение, должен ли только Outlook 2007 иметь возможность подключения, или старые версии тоже. Такая проверка проводится только при запуске службы. Поэтому вам необходимо перезапустить службу банка сообщений для того, чтобы изменения вступили в силу после создания хранилища общих папок.

Кей Си Лемсон (KC Lemson) — менеджер по пользовательской среде для Exchange Server. В данный момент она работает над докторской диссертацией в престижном неаккредитованном университете.
Нино Биллич (Nino Bilic) — руководитель программы поддержки Exchange Server. Он подумывает над тем, чтобы стать профессиональным автогонщиком в Forza Motorsports 2.


 На страже безопасности: Долговременное воздействие управления учетными записями пользователей
На страже безопасности
Долговременное воздействие управления учетными записями пользователей
Йеспер Йохансон (Jesper M. Johansson)

Администраторы сталкиваются с совершенно очевидной проблемой: любые вредоносные программы, атакующие пользователей или приложения, с которыми они работают, подчиняют себе 90 процентов компьютера, который они заражают. Управление учетными записями пользователей (UAC) в Windows Vista –– это попытка корпорации Майкрософт решить одну из основных проблем безопасности, а именно то, что более
90 процентов пользователей, работающих с Windows, обладают правами администратора. Хотя, возможно, работа с Windows® XP в качестве обычного пользователя — а я так и делаю –– может оказаться довольно непростым делом. Например, если вы часто путешествуете и возите с собой компьютер, на котором установлена среда Windows XP, вы заметите, что обычный пользователь не может, например, изменять часовые зоны системы.
UAC – возможность изменить все это. Вот первое заблуждение. UAC – это не просто возможность, это коллекция возможностей, большинство из которых не особенно очевидны. Я не буду предлагать вам глубокий анализ всех деталей работы UAC. Для этого я рекомендую вам прочитать статью Марка Руссиновича в июньском номере TechNet Magazineза 2007 год, которую можно найти на веб-узле technetmagazine.com/issues/2007/06/UAC.
В своей статье я собираюсь беспристрастно объяснить вам, что такое UAC, чем оно не является и как оно влияет на ваши возможности управления системами в операционной среде Windows Vista®.

Что такое UAC
Самой заметной функцией UAC является диалоговое окно повышения прав, показанное на рис. 1. На самом деле, если бы вы спросили у типичных пользователей Windows Vista о том, что такое UAC, большинство, вероятнее всего, ответило бы что-нибудь о раздражающем диалоговом окне повышения прав.
Рис. 1 Диалоговое окно одобрения UAC для администратора в режиме одобрения администратором
Рис. 1 Диалоговое окно одобрения UAC для администратора в режиме одобрения администратором
Несмотря на видимость и все мнения о UAC, я не верю, что в большинстве обсуждений UAC содержится много сведений о том, чем на самом деле является UAC. В действительности похоже, что здесь присутствует определенная путаница. Эксперты пишут статьи, сообщения в блогах и группах новостей с такими названиями, как «Самая раздражающая функция Vista», и разглагольствуют о том, как много пользователей выключит эту функцию и почему она настолько всех раздражает.
Учитывая то, что совсем немного лиц потрудилось ознакомиться с разумным обоснованием UAC, почему бы мне не начать эту статью с рассмотрения того, что такое UAC?

Что такое UAC
UAC – это попытка увеличить количество пользователей, работающих в качестве обычных. В известном смысле это версия 2.0 такой попытки. Версия 1.0 впервые появилась в Windows NT® 3.1 и позволила пользователю работать как «не администратору». Это был коренной уход от 16-разрядной операционной системы Windows 3.1 и ее преемников, Windows 3.11, Windows 95, Windows 98 и Windows Me, ни одна из которых не имела концепции пользователей с низким уровнем привилегий. Возможность выполнения не администратором что-либо полезного зависела от множества факторов, но до XP и Windows Server® 2003 минимальные привилегии пользователей считались тягостными или даже бесполезными. Windows Vista предлагает первый набор технологий для упрощения работы с привилегиями интерактивных пользователей.
Хотя утверждение, что целью UAC является предоставление приложениям, работающим как администраторы, некоторого уровня защиты от приложений, не являющихся администраторами, верно, это нисколько не было основной целью UAC. Основная цель заключалась в том, чтобы навести нас на путь увеличения количества пользователей, работающих в качестве обычных, что в свою очередь вызвало бы написание разработчиками большего количества программ, работающих в качестве обычных пользователей, и сократило количество ситуаций, в которых необходимо повышение привилегий пользователей. С написанием разработчиками большего числа совместимых с UAC приложений снижается количество запросов пользователя, тем самым улучшая его работу. В идеале этот процесс приведет к тому, что большинство пользователей не будут работать как администраторы, и, надеюсь, начнут с сомнением относиться к получаемым запросам на повышение прав. Чем меньше число запросов, тем более вероятно, что пользователи будут тщательно рассматривать их перед одобрением.
Теория выглядит приблизительно так. Соответственно может уменьшиться количество вредоносных программ, но это будет зависеть от включения пользователями функции UAC, что зависит от написания разработчиками программ для этой функции и от того, перестанут ли пользователи рассматривать запросы в качестве упражнений на быстроту щелчка и будут ли на самом деле выяснять законность запросов на повышение прав.
Для достижения главной цели – увеличения количества пользователей, которые большую часть времени могут работать не как администраторы, – функция UAC разработана так, чтобы достичь ряд отдельных целей.
  1. Уменьшение количества ситуаций, требующих повышения прав до учетной записи администратора.
  2. Значительное упрощение повышения прав — по возможности автоматическое — по сравнению с предыдущими небрежностями, такими как использование runas.exe или переключение между учетными записями. Другими словами, ликвидация разрыва до исправления независимыми поставщиками программного обеспечения своих программ.
  3. Предоставление определенной изоляции для приложений, работающих с правами администратора, чтобы защитить их от приложений, не работающих с правами администратора.
  4. Обеспечение возможности выполнения некоторых уязвимых приложений с наименьшими возможными привилегиями.
Две из этих целей предназначены для того, чтобы сделать работу пользователя, не являющегося администратором, максимально удобной. Другие две цели преследуют защиту особенно уязвимых приложений.
Что интересно, так это то, что всего две цели относятся к функции, обычно рассматриваемой как UAC, и только одна цель относится к фактическому повышению прав. Пока повышение прав при запросе приложением дополнительных привилегий – это то, на что жалуются пользователи, поскольку это единственное видимое проявление набора технологий, составляющих UAC. Первая всеобъемлющая цель не имеет совсем никакого отношения к повышению прав. Идея просто состояла в обеспечении работы пользователей без прав администратора большую часть времени. По сути, вы можете возразить, что намерением является уменьшение количества событий повышения прав.
К самой задаче повышения прав относятся цели 2 и 3. Цель номер 2 состоит в упрощении повышения прав во сравнению с Windows XP, а цель номер 3 заключается в предоставлении некоторого уровня защиты приложениям, работающим с повышенными правами. Оставшиеся цели предназначены для решения совсем других проблем. Однако для достижения всех этих целей необходимо изменение операционной системы. Те, кого это интересует, могут ознакомиться с упомянутой выше статьей Марка Руссиновича, в которой рассмотрены эти изменения.
Как было сказано выше, высказывается множество рекомендаций отключить функцию UAC. Весьма вероятно, что ряд пользователей поступит именно так, даже не испытав работу UAC, а множество других получит свои компьютеры из крупных магазинов с установленной сборкой Windows Vista и уже отключенной функцией UAC. Я думаю, то, что розничные продавцы в своих стандартных образах развертывания отключают важные функции безопасности операционной системы, является постыдным.
К несчастью, множество советов отключить функцию UAC основаны на первоначальном опыте. При установке программного обеспечения и внесения необходимых изменений, выполняемых при настройке компьютера, появится довольно много запросов. Следует ожидать, что ваша работа по администрированию компьютера при настройке будет совсем не такой, как работа на компьютере в установившемся состоянии. Первые несколько недель будут значительно отличаться от последующих нескольких недель. Если вы попробуете поработать с функцией UAC на компьютере с относительно установившемся состоянием, я думаю, вы обнаружите, что эта функция совсем не является навязчивой.

Чем не является UAC
UAC не создавалось намеренно как самая раздражающая функция в истории Windows. Скорее, этот набор технологий был предназначен для того, что направить нас на путь, на котором пользователям не требуется подвергать свои системы воздействию потенциально вредоносного кода так часто, как это происходило последние несколько лет.
В своей текущей форме функция UAC не остановит по-настоящему опытных злоумышленников или пользователей, которым они помогают. Если злоумышленники не знают другого способа победить UAC, они почти наверняка будут просить пользователей сделать это за них. При выборе между танцующими свинками и безопасностью мы по опыту знаем, что всегда будут выбираться свинки. Пользователи научились закрывать диалоговое окна, и они будут поступать именно так, пока нам не удастся их переучить. Это обусловлено множеством способствующих факторов, включая факт наличия множества диалоговых окон с предупреждениями, бесполезность этих сообщений, а также то, что во множестве руководств к различным приобретаемым пользователями устройствам содержится указание «нажать на кнопку Да в диалоговом окне с предупреждением безопасности, чтобы закрыть его».
UAC не обеспечивает безопасность путем защиты от неумелого обращения. По существу, она снова делает интересными добрые старые локальные атаки повышения привилегий. Опасность этого класса атак в значительной степени умалялась, поскольку почти все пользователи Windows и так являлись администраторами, поэтому повышение прав до какого-либо иного администратора было довольно бессмысленным. Так или иначе, UAC явно изменяет природу таких атак и изменяет правила игры в сторону ситуации с операционной системой UNIX, существующей уже более 20 лет.
UAC не предотвратит похищение ваших личных данных злоумышленниками. Личные данные доступны пользователю независимо от его привилегий. По существу, приложение, включая вредоносное, имеет доступ к данным. UAC не изменяет и не может изменить это. Оно не устраняет необходимость быть бдительным, недоверчивым и параноиком — качества, которые все мы должны при каждой возможности прививать конечным пользователям.
Функция UAC не предназначалась для защиты приложения, работающего с повышенными правами, от всех атак со стороны приложения, работающего с обычными правами в том же сеансе. Хотя UAC обеспечивает определенную слабую изоляцию процесса, целью проектирования UAC не являлась изоляция приложений друг от друга.

Слухи
Корпорация Майкрософт сама причастна к распространению слухов о UAC и непониманию работы этой функции. Например, в главе «Защита от вредоносных программ» руководства по безопасности Windows Vista функция UAC представлена как основная технология по этому вопросу (microsoft.com/technet/windowsvista/security/guide.mspx). В главе рекомендуется большую часть времени работать с включенной функцией UAC, а также перечисляется ряд моментов, на которые следует обратить внимание при использовании UAC для борьбы с вредоносными программами. Однако один момент грубо пропущен: функция UAC не препятствует работе вредоносных программ и не предназначалась для этого.
Некоторые наиболее светлые умы мира, в настоящее время занимающиеся безопасностью Windows, например, Джоанна Рутковска, понимают цель UAC. 4 февраля 2007 г. в своем блоге она написала, что UAC – «это новый механизм безопасности, представленный в Vista, целью которого является принуждение пользователей работать с ограниченными правами, а не в качестве администраторов» (theinvisiblethings.blogspot.com/2007/02/running-vista-every-day.html). Она выразилась почти правильно, за исключением того, что вместо термина «принуждение» я бы использовал термин «разрешение».
Это, однако, означает существенное изменение природы обычно используемых атак против Windows. Как упоминалось ранее в этой статье, уязвимости повышения локальных привилегий, в которых пользователь может подняться от обычного локального пользователя к локальному администратору, никогда не представляли особенного интереса в платформе Windows.
В операционной системе Windows Vista появилось представление о работе пользователей в качестве обычных, что неожиданно привело к появлению интереса к проблемах повышения локальных привилегий. К несчастью, здесь мы также сталкиваемся с определенными ограничениями UAC. Напомним, что отсутствует эффективная изоляция, отсутствует рубеж безопасности, изолирующий процессы одного компьютера. Операционная система включает некоторые меры защиты для поддержания блокировки очевидных и ненужных каналов связи, но блокировка всех каналов является невозможным и нежелательным. Поэтому корпорация Майкрософт не рассматривает нарушения этого несуществующего рубежа безопасности в качестве нарушений безопасности. Марк Руссинович в реплике в блоге по адресу blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspx указал именно на это.
Марк абсолютно прав. Корпорация Майкрософт прекрасно осведомлена об отсутствии рубежа безопасности между процессом с низкими правами и процессом с повышенными правами на одном компьютере. Поскольку какая-либо изоляция между процессами на одном компьютере никогда не предусматривалась, обнаружение отсутствия изоляции между процессами на одном компьютере на самом деле не может быть названо уязвимостью безопасности. Очевидно, это снижает ценность UAC как первоочередного механизма борьбы с вредоносными программами, но функция UAC все равно не предназначалась для этого, несмотря на то, что можно прочитать в различных источниках, включая некоторые публикации Microsoft.
Снижает ли этот факт ценность UAC относительно основной цели этой функции — разрешение большему числу пользователей работать в качестве обычных пользователей большее количество времени? Нет. Существование или отсутствие непроницаемого рубежа безопасности между вредоносным приложением с низкими привилегиями и приложением с повышенными правами не устраняет факт того, что большее количество пользователей могут эффективно использовать UAC и работать на компьютерах под управлением Windows Vista в качестве обычных пользователей. В действительности, вопреки тому, во что заставили вас поверить некоторые представители отрасли, я написал эту статью (и если уж на то пошло, всю мою книгу о безопасности Windows Vista), работая в качестве обычного пользователя Windows Vista, и ни разу не получал запрос UAC на одобрение чего-либо, чего я не писал!
Тот факт, что UAC не предотвращает всех проблем безопасности, или что функция не обладает свойством, которые бы хотели иметь многие из вас, включая меня — первоочередная защита от вредоносных программ — не означает, что UAC не является технологией безопасности. Возможность определения пользователей через отдельные учетные записи сама по себе не предотвращает заражение вашей системы вредоносными программами, но из этого нельзя сделать вывод, что учетные записи пользователей не являются технологией безопасности. То, что функция UAC не разрешает всех проблем, которые мы бы хотели, чтобы она решала, не означает, что разрешаемые проблемы являются несерьезными.
UAC оставляет решение остальных проблем другим технологиям, таким как значительно улучшенный брандмауэр Windows, защитник Windows и другие программы защиты от вредоносного ПО, для предотвращения проникновения вредоносного кода и от его выполнения, если он все-таки попал в систему (из-за хитрого программирования или летающих свинок). Хотя ни одна из этих технологий безопасности не обеспечивает стопроцентное выполнение своих задач, все они являются достаточно ценными и занимают свои места в общей системе обеспечения безопасности. Но как я уже много раз говорил, даже если закрыть всех пути атаки, это приведет к невозможности работы пользователя. Если сидящий за клавиатурой пользователь разрешает выполнение вредоносного кода, не поможет никакая техническая защита во всем мире.

Практические рекомендации
Как использовать UAC? Следует ли работать в качестве администратора в режиме одобрения администратором? Как уже несколько раз упоминалось, UAC не предотвращает введение кода из приложения с низкими привилегиями в приложение с более высокими привилегиями на одном компьютере. Это означает, что ни работа в режиме одобрения администратором, ни работа в качестве обычного пользователя с повышением прав в течение сеанса (повышение с помощью запроса на повышение прав) не обеспечивают эффективной изоляции. Однако любое из двух решений гораздо лучше работы в качестве администратора в Windows XP или в Windows Vista с выключенной функцией UAC. Однако в конечном счете, вредоносная программа скорей всего будет написана для использования преимуществ приложений с повышенными правами на интерактивном рабочем столе.
Выбор варианта работы зависит от вашей философии управления рисками. При работе в качестве обычного пользователя и использовании запросов на повышение прав среда пользователя приложения с повышенными правами отличается от среды обычного приложения. Это уменьшает опасность атак путем подделки записей кэша, при которых вредоносное приложение без повышенных права заражает среду пользователя приложения с повышенными правами, но не обязательно приводит к потере возможности приложения без повышенных прав управлять приложением с повышенными правами. Хотя вредоносному приложению, запущенному несколько недель назад, непросто заразить запущенное сегодня приложение с повышенными правами, выполняемое в данный момент вредоносное приложение может управлять приложением с повышенными правами. Необходимо оценить опасность использования режима одобрения администратором или запроса на повышение прав с точки зрения предоставляемой простоты использования.
Это приводит к созданию набора практических рекомендаций для UAC, которые подытожены на рис. 2. На мой взгляд, наилучший вариант является и самым сложным. Однако для настоящих параноиков и беззащитных пользователей лучшим вариантом является работа в качестве обычного пользователя и постоянный отказ от повышения прав. До некоторой степени работа в качестве администратора в Windows XP после выполнения вредоносного кода вела к неизбежному краху. Запуск вредоносного кода в Windows Vista и последующее повышение прав в этом же сеансе могут привести к краху. Вы свободны в выборе подхода, который наиболее вам подходит и предоставляет нужный уровень защиты.
Figure 2 Практические рекомендации по повышению прав учетной записи (Close Figure 2)

Уровень защиты | Метод повышения прав
Худший | Отключение UAC.
Плохой | Автоматические повышение прав администраторов.
Хороший | Работа в режиме одобрения администратором.
Улучшенный | Работа в качестве обычного пользователя и повышение прав до отдельной учетной записи администратора.
Наилучший | Работа в качестве обычного пользователя и переключение на отдельную учетную запись администратора вместо использования UAC для повышения прав.
Добавлю, настоящий параноик не доверяет поставщику, когда он говорит, что приложение должно работать с правами администратора! Одним из самых ярких примеров такого утверждения, не соответствующего истине, является Visual Studio® 2005 с пакетом обновления 1 (SP1). При запуске Visual Studio появляется сообщение о необходимости запуска в качестве администратора. Однако это является верным только разработчиков, выполняющих определенные задачи. Дополнительные сведения представлены на веб-узле msdn2.microsoft.com/en-us/vstudio/aa972193.aspx.

Предоставление пользователям прав
Пользователям должна быть предоставлена возможность принятия решений. Существуют специалисты в области безопасности, считающие, что решения относительно безопасности должны быть скрыты от пользователя. Их невысказанное объяснение заключается в том, что пользователям не только не интересна безопасность, но они недостаточно сообразительны, чтобы изучить ее. Они могут быть надежно защищены только с помощью ВставьтеСюдаВашуЛюбимуюАнти-технологию.
Я не видел случаев, чтобы технология могла полностью защитить людей от атак, направленных именно на них. Большинство современных атак, включая практически все атаки с помощью фишинга, направлены в первую очередь на людей и их работу с компьютерами, а не на технологии компьютеров. Наиболее эффективные из этих атак могут сочетать атаки на людей с атаками на технологии, но для них все равно часто необходимо взаимодействие с пользователем. Технология просто не может защитить от атак, направленных не на технологию. Недавно я подробно описал это: technetmagazine.com/issues/2006/07/SecurityWatch.
UAC уже принуждает пользователей к принятию решений относительно безопасности, и поставщики технологий уже обещали выпустить решения, не позволяющие пользователям принимать такие решения. Верно, что пользователи предпочитают не утруждать себя безопасностью. Однако также верно, что ни одного программное обеспечение не может понять намерения другого программного обеспечения. Никакие системы предотвращения вторжения не могут сказать, запрашивает ли веб-узел номер вашей кредитной карточки для того, чтобы отправить вам экземпляр книги «Windows Vista Security» (Безопасность в Windows Vista), или же чтобы отправить этот номер тайной преступной организации. Это может сделать только конечный пользователь, и только если ему предоставлена необходимая информация. Как специалистам по программному обеспечению, нам необходимо убедить пользователей в том, что они должны принимать разумные решения относительно безопасности, обучить их и предоставить всю необходимую информацию.
Если мы будем продолжать использовать текущий подход — препятствование пользователям принимать решения относительно безопасности — мы обнаружим только то, что не смогли их защитить. Со временем пользователи устанут от взломов, краж с банковских счетов, нарушения конфиденциальности и попрания их личности, достоинства и самоуважения. Когда это произойдет, пользователи перестанут использовать продукты, продажа которых поддерживает отрасль. Существуют представители сферы высоких технологий, которые верят, что если скрыть существование проблем безопасности компьютеров, и всего, что с ними связано, пользователи будут слепо использовать то, что мы им кинем. Нет ничего дальше от истины. Когда пользователи наконец-то узнают, что мы не были открыты и честны с ними, они полностью потеряют доверие и откажутся от наших продуктов, что приведет к краху отрасли, защитить которую мы пытаемся, скрывая факты.
UAC – это превосходный шаг к возложению на пользователей ответственности за безопасность своих систем. UAC никоим образом не является полным решением безопасности, но являясь первой попыткой помочь пользователям в работе с минимальными правами, эта функция определенно является значительным шагом в верном направлении.

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


 Материалы о рабочей среде: Восстановление компьютера при помощи Windows PE
Материалы о рабочей среде
Восстановление компьютера при помощи Windows PE
Уэс Миллер (Wes Miller)

В предыдущих статьях я упоминал, что нашей первоначальной концепцией Windows PE была среда развертывания. Как и все хорошие продукты, Windows PE далеко вышла за пределы этой концепции. Клиентам (для начала — сборщикам систем) было необходимо создание единого решения, которое бы могло использоваться как для самостоятельного восстановления на производстве, так и для пользовательского самовосстановления, и несколько компаний выпустили такие решения —
решения Windows® PE, работающие во всех случаях.
Большинство существующих сегодня средств восстановления основаны на идее возврата системы к известному рабочему состоянию с помощью зеркалирования процесса развертывания. Windows Vista® еще больше упрощает восстановление по сравлению с Windows XP и предоставляет встроенную поддержку работу с образами (см. статью по технологиям резервного копирования Windows Vista Кристины Фок в этом выпуске журнала TechNet Magazine).
В рубрике этого месяца я рассмотрю создание собственного решения восстановления на основе Windows PE. Windows PE 2.0 — это бесплатный компонент пакета автоматический установки Windows для всех лицензий Windows. Эта лицензия применяется не только для развертывания, но также для использования Windows PE для целей восстановления и устранения неисправностей.
Очевидно, необходимо учитывать собственные настройки и модификации, но в этой статье я рассмотрю общие моменты, которые необходимо знать при развертывании Windows XP или Windows Vista. Если вы знакомы с работой с образами, вы уже знаете многие эти моменты.
Вот ключевые компоненты любого решения для восстановления на основе Windows PE:
  • Windows PE;
  • программа для работы с образами;
  • привязывание с помощью сценариев (или формальное приложение) для объединения компонентов.
При необходимости можно включить поддержку SQL и интерфейсов Active Directory® (ADSI). Возможности подключения SQL позволяют косвенно создать решение, предоставляя системе обширную «ведомость материалов», которая определяет необходимые условия для установки. Аналогичным образом подключение к Active Directory удобно для обработки свойств объекта учетной записи для компьютера (per-machine account object – MAO).
Обратите внимание, что включение ADSI в Windows PE не поддерживается корпорацией Майкрософт, но в Интернете доступно довольно много статьей с объяснением того, как такое включение можно выполнить; если оно выполняется правильно, оно работает вполне успешно. Если вам не очень хочется разбираться с ADSI, можно добавить поддержку SQL и создать рабочий процесс для средства восстановления Windows PE. Если какие-либо свойства ADSI все же понадобятся, можно использовать серверную систему с назначенной задачей для обращения к этому же серверу SQL Server™ и последующего обращения к Active Directory через ADSI, фактически осуществляя ретрансляцию.
Решние это не идеально, необходимы определенные сценарии или другая автоматизация, но такая схема позволяет обращаться к Active Directory из Windows PE.
Имейте в виду, что также можно использовать программу LDIFDE для чтения данных Active Directory из Windows PE (дополнительные сведения об этом приведены в статье базы знаний по адресу support.microsoft.com/kb/237677). Например, можно использовать следующую команду:
ldifde -m -f x:\output.ldf -b <username> <domain netbiosname> <accountPassword> -s
<DC or domain name> -d "DC=contoso,DC=com" -r "(&(objectclass=<computerclassname>)
(netbuisname=<mycomputername>))" - l "<attributename>"
Эта команда используется для получения атрибута от определенного объекта-компьютера в файл x:\output.ldf, в котором затем данные могут быть проанализированы.

Продукты, разрядность и языки
Необходимо учитывать версии, архитектуры и языки операционных систем Windows, которые необходимо развернуть. В небольшой локальной организации, вероятно, будет развертываться только одна операционная система — либо Windows XP, либо Windows Vista — или же будут использоваться компоненты, уже установленные на новых компьютерах. Вам, вероятно, нечасто приходится развертывать 64-разрядные версии Windows — если вы вообще с ними сталкиваетесь. И скорей всего вам необходима поддержка только одного языка. Однако чем больше размер вашей организации и чем обширнее ее участие на международном рынке, тем больше вероятность работы с большим количеством архитектур, версий и настроек.
В одной из предыдущих статей я упоминал, что образы томов x64 и x86 можно сохранять в одном файле WIM (формат Windows Imaging), но это не приведет к экономии места. Если вы занимаетесь созданием решения для восстановления и вам необходимо учитывать обе архитектуры, каждая должна быть сохранена в отдельном файле WIM. Аналогично, при развертывании и поддержке Windows XP и Windows Vista сохранение обеих операционных систем в одном образе не приведет к уменьшению объема. Здесь экономия места достигается, только если многие приложения (например, выпуск 2007 системы Microsoft® Office) включены в оба развертывания. В этом случае файлы приложений не требуется сохранять несколько раз, но значительная экономия места все равно маловероятна.
Методы загрузки Windows PE
Windows PE 1.6
Загрузка с помощью протокола PXE из удаленной установки
Служба (RIS) (без RAMDisk)
Жесткий диск
Флэш-накопитель USB
RAMDisk с помощью протокола PXE
RAMDisk с помощью компакт-диска или диска DVD
RAMDisk с помощью флэш-накопителя USB
RAMDisk с помощью жесткого диска

Windows PE 2.0
RAMDisk с помощью протокола PXE
RAMDisk с помощью компакт-диска или диска DVD
RAMDisk с помощью флэш-накопителя USB
RAMDisk с помощью жесткого диска

Загрузка с помощью протокола PXE через RIS является оптимальным вариантом при необходимости протокола PXE, но стоит заметить, что при использовании этого метода загрузка длится дольше и потребляется больше сетевых ресурсов, чем при использовании RAMDisk с помощью протокола PXE.
Жесткий диск использует минимальный объем памяти, но блокирует привод. Этот метод является идеальным при использовании восстановления с одного раздела на другой.
Флэш-накопитель USB делает загрузку удобной, однако использование накопителя такого рода (для вариантов с RAMDisk и без RAMDisk) является лотереей, если загружаемые системы не проверены изготовителем как допустимые для загрузки с флэш-накопителя USB и для них отсутствует проверка логотипа Windows Vista Capable (обеспечивающая поддержку загрузки с флэш-накопителя USB как требования проверки логотипа). Для загрузки с флэш-накопителя USB необходим скоростной флэш-накопитель (с возможностью чтения и записи), а также контроллер USB и BIOS с поддержкой высокоскоростной шины USB.
Загрузка с использованием RAMDisk (во всех вариантах) требует большего количества памяти, но обеспечивает оптимальную производительность и устраняет необходимость записи Windows PE, помещая ее на RAMDisk в памяти. Загрузка Windows PE 1.6, как правило, должна использоваться в системах с ОЗУ не менее 256 МБ. Windows PE 2.0 (всегда загружающаяся с образа WIM на RAMDisk), как правило, должна использоваться на системах с ОЗУ не менее 384 МБ.

Стоит отметить, что при сохранении несколько продуктов определенной версии Windows в одном файле WIM достигается значительная экономия места. Например, предположим, что Windows XP Professional сочетается с Windows XP Tablet PC Edition или Windows Vista Business Edition сочетается с Windows Vista Ultimate Edition — эти сочетания эффективно используют пространство, поскольку два продукта одного выпуска и уровня пакета обновления используют большую часть общего кода и файлов.
Наконец, поговорим о языках. Чем больше организация, тем больше языков необходимо учитывать. В Windows XP можно выбрать использование локализованных сборок или пакета многоязыкового интерфейса пользователя (MUI). В полностью локализованных сборках Windows XP практически все, даже самые короткие строки, переведены на определенный язык. С другой стороны, в пакете многоязыкового интерфейса пользователя основным языком является английский, а различные пакеты (позднее — пакеты интерфейса пользователя) изменяют максимальное возможное количество строк. (Пакет многоязыкового интерфейса пользователя имел хорошие результаты в Windows 2000 и намного лучшие в Windows XP и Windows Server 2003.)
Если в вашей организации используется пакет многоязыкового интерфейса пользователя, довольно хорошие результаты достигаются при объединении различных языковых версий в одном файле WIM. Это происходит потому, что их основу составляют двоичные файлы на английском языке. Однако это не относится к локализованным версиям до Windows Vista. Поскольку локализованы сами двоичные файлы, они являются различными для разных языков, значит, для каждого языка необходимо сохранять почти всю операционную систему (и все локализованные приложения).
Локализованные версии Windows Vista (локализованные как часть одного двоичного файла с ресурсами) можно считать устаревшими. Windows Vista использует файлы ресурсов MUI для всех языков, включая английский. По существу, Windows Vista — это система, не относящаяся ни к какому конкретному языку. Почти все данные языков содержатся в файлах MUI. Таким образом, сохранение нескольких языковых версий Windows Vista в одном файле WIM приведет к значительной экономии пространства. Сохранение двух, четырех или большего числа языков в одном файле WIM означает, размер образа существенно не изменится, в последствие можно добавлять языки или переключаться между ними при возникновении такой необходимости.
В двух словах, при создании решения необходимо учитывать, какие версии Windows и других приложений используют общие двоичные файлы, что допускает один экземпляр хранилища файлов. Это поможет определить количество необходимых для организации файлов WIM.

Пользовательские варианты
Обычно чем больше становится организация, тем более она усложняется. Это происходит не только из-за размера, но также и из-за всех представленных переменных — большее количество пользователей и подразделений с отдельными потребностями.
Я знаю одну международную организацию, в которой были десятки тысяч пользователей, а процесс развертывания полностью управлялся из одного места как географически, так и организационно. Лицо, управлявшее этой организацией, всегда задавало очень трудные вопросы. Например, руководитель беспокоился о некоторых удаленных пользователях в определенных частях Африки, у которых часто отсутствовало надежное сетевое подключение — фактически, многие из них находились в тысячах миль от телефонной линии. Ему необходимо было знать, как эти пользователи могут восстановить свои системы без простоя в течение нескольких дней и поездок на большие расстояния.
При разработке продукта, а в этом смысле решение восстановления следует рассматривать в качестве продукта, необходимо подумать о пользователях. Необходимо думать не только об определенных потребностях бизнеса, но также и о сложностях, связанных с различными категориями пользователей. Следует включить примеры использования с короткими описаниями всех типов конечных пользователей, поддержка которых необходима. Это поможет выявить пользователей, случайно не включенных в решение восстановления, и обеспечить учет всех типов пользователей.

Верная версия Windows PE
Другим важным решением является определение подходящих для ваших требований версии Windows PE. Полезную информацию содержат предыдущие выпуски этой рубрики, но здесь я попытаюсь объяснить решение немного подробнее. Если верно хотя бы одно из перечисленных ниже утверждений, следует использовать Windows PE 1.6.
  • Выполняется восстановление только Windows XP (или Windows Server 2003).
  • Восстанавливаются системы, не являющиеся совместимыми со стандартом ACPI.
  • Восстанавливаются системы с объемом ОЗУ менее 512 МБ.
  • Восстанавливаются системы с необходимостью загрузки по протоколу PXE и с ОЗУ менее 256 МБ.
Если верно хотя бы одно из перечисленных ниже утверждений, следует использовать Windows PE 2.0.
  • Выполняется восстановление только Windows Vista (или Windows Server 2008).
  • Восстанавливается и Windows Vista, и Windows XP.
  • Используется BitLocker™.
Обратите внимание, что ImageX (см. раздел «Создание, обновление и сохранение») и большинство решений для работы с образами сторонних производителей хорошо работают с обеими версиями Windows PE.

Загрузка Windows PE
Следующее, что необходимо учитывать, это способ загрузки Windows PE. Здесь ключевую роль играют особенности условий работы пользователей. Могут ли пользователи перевозить компакт-диски или диски DVD для восстановления? Могут ли пользователи использовать диски с переносными компьютерами во время поездок? Как осуществляется регулярное обновление носителей? Образы восстановления на съемных носителях могут очень быстро устаревать.
Наиболее часто использующимся вариантом, который я встречал, являлся дополнительный раздел жесткого диска. Другой возможностью является загрузка по протоколу PXE. Или же можно использовать внешние накопители USB или даже флэш-накопители USB, но имейте ввиду, что рассматриваемое оборудование должно явным образом поддерживать загрузку с флэш-накопителя USB.
На врезке «Методы загрузки Windows PE» описаны поддерживаемые методы для загрузки каждой версии Windows PE и важные моменты, касающиеся каждого метода.
Целью загрузки Windows PE должен являться запуск процесса восстановления с соблюдением определенного критерия.
  • Минимальное взаимодействие с пользователем.
  • Минимальное количество перемещаемых компонентов (съемные носители или устройства).
  • Компьютеры могут быть не подключены к сети.
  • Компьютеры могут не загружаться локально (сбой загрузки Windows).
Администраторы часто считают размещение Windows PE (обычное или на RAMDisk) на жестком диске невозможным из-за возможности сбоя диска, но в действительности этот вариант можно использовать: во-первых, современные диски весьма надежны, а во вторых, при сбое физического диска пользователь все равно не сможет восстановить систему самостоятельно.
Я предпочитаю создать дополнительный раздел для хранения образа восстановления. Я не сторонник делать этот раздел скрытым — это может озадачить пользователей. Использование на нем списка управления доступом (ACL) является возможным только в том случае, если пользователи являются локальными администраторами.
Благодаря сжатию раздела для Windows (см. врезку «Создание раздела восстановления») можно освободить достаточное пространство для хранения Windows PE и образа восстановления. Для размещения Windows PE на дополнительном разделе необходимо просто создать соответствующий загрузочный сектор в разделе восстановления и разместить в этом разделе Windows PE (в документации Windows AIK и более ранних версий Windows PE объясняется этот процесс, поэтому я не буду здесь подробно рассматривать его). Следует помнить, что раздел для загрузки определяется тем, какой раздел отмечен активным. Программа Diskpart использует флаг активности и такой же важный флаг неактивности. Для загрузки раздела восстановления из Windows (или из копии Windows PE) используйте программу Diskpart для переключения между активными разделами (см. рис. 1). Ниже приведен пример сценария Diskpart (используйте diskpart /s nameofscript.txt), используемого для переключения одного диска системы с двумя разделами:
SEL DIS 0
SEL PAR 1
INACTIVE
SEL PAR 2
ACTIVE
EXIT
Рис. 1 Изменение активного раздела средством Diskpart
Рис. 1 Изменение активного раздела средством Diskpart
Этот процесс используется множеством пользовательских средств восстановления для перестановки разделов, что может быть выполнено только из Windows PE для определенных типов разделов, таких как скрытые разделы, созданные сборщиком системы. Иногда эти средства также раскрывают подобные скрытые разделы.

Создание, обновление и сохранение
Создание раздела восстановления
Процесс создания раздела восстановления, не затрагивающего целостность Windows, не является сложным, если вы знаете последовательности этого процесса. Ниже приведен краткий обзор необходимых действий. Обратите внимание, что для этого процесса необходима среда Windows PE 2.0. Хотя вы можете и не использовать Windows PE 2.0 для развертывания или восстановления, для выполнения этой задачи необходимо использовать версию 2.0. Этот процесс также может использовать при развертывании Windows Vista и для создания загрузочного раздела для использования с загрузочными файлами BitLocker, поскольку для BitLocker необходимо не менее двух разделов (один для загрузочных файлов, а второй для системы Windows).
  1. Выполните дефрагментацию диска (это может помочь ускорить процесс сжатия, который занимает достаточно длительное время)
  2. Загрузите Windows PE 2.0
  3. Запустите программу Diskpart (при необходимости можно создать сценарий для действий 4 – 9 и передать diskpart следующий аргумент: /s имя_сценария
  4. SEL VOL 1 (или том для сжатия).
  5. SHRINK DESIRED=N MIN=N (указанный в мегабайтах, DESIRED — это цель, а MIN — абсолютный необходимый минимум).
  6. После завершения сжатия запустите SEL DIS 0.
  7. CRE PAR PRI (при необходимости указания размера, отличного от размера оставшегося на диске места, можно указать SIZE=N).
  8. ASSIGN LETTER=N: (эта буква предназначена для использования только средой Windows PE).
  9. Выйдите из программы Diskpart.
  10. FORMAT N: /Q /Y /FS:NTFS (форматирование нового раздела под NTFS).
  11. Запустите bootsect N: /nt60 для 2.0, /nt52 для 1.x).
  12. Скопируйте необходимые файлы Windows PE в раздел восстановления.
  13. Завершите работу системы.

Хотя ImageX — это бесплатное решение, вы можете уже пользоваться другим средством работы с образами. Вы можете использовать любое удобное для вас средство. При использовании ImageX необходимо отметить несколько преимуществ (кроме отличной цены). В частности, ImageX является очень конкурентным средством. Что также приятно, дополнение и изменение образа осуществляются довольно просто.
Мне также нравится, что ImageX позволяет безболезненно создать образ одного или нескольких томов, сохраняя данные пользователя простым перемещением. Другими словами, при восстановлении Windows удаление всего тома не требуется.
Затем, разумеется, необходимо определить место сохранения образа. Если допустить, что решение использует раздел восстановления, в нем можно сохранить файл WIM и другие файлы для работы с образами. Можно даже использовать службы развертывания Windows (WDS), создавая стандартный образ операционной системы и сохраняя его в сети. Это позволяет создать общее решение для восстановления, доступное во всей инфраструктуре. Конечно, если пользователи работают в географически удаленных регионах (как в упомянутой выше организации), необходимо обеспечить наличие у них собственных решений, когда сеть для них недоступна.
Ранее я упоминал, что можно использовать носители, например диски DVD, но существует ряд причин, по которым мне не нравится использование этого способа в качестве обычного. Например, размер образа может быстро увеличиться и превысить размер диска DVD, а такие диски не могут быть быстро обновлены. Это не означает, что оптические носители не используются; необходимо просто определить наилучший вариант для каждого типа пользователей. Я предпочитаю сохранять образ в разделе восстановления, на жестком диске USB или флэш-накопителе USB, или, если возможно, в сети с помощью WDS.
Причина, делающая WDS привлекательным вариантом, заключается в том, что централизованный образ может быть просто обновлен. Вы все уже должны знать, что обновления Windows выпускаются каждый месяц и часто являются критическими. Необходимо так создавать решение, чтобы образ восстановления содержал самые свежие обновления. WDS позволяет полностью выполнять процесс обновления образа на каждом сервере.

Вопросы данных и параметров пользователя
При создании решения восстановления необходимо учитывать несколько моментов. Ключевым аспектом планирования любого решения восстановления является обеспечение безопасности данных пользователя. Вам же не нужно, чтобы пользователь на месте выполнял восстановление только для того, чтобы узнать, что в результате этого он потерял все важные данные. В идеальном случае данные пользователя должны быть сохранены не в разделе C:, если вас беспокоит выполнение восстановления системы.
Я уже упоминал, что ImageX позволяет выполнять неразрушительное восстановление диска. Например, это средство переместит существующее дерево каталогов Documents and Settings (или Users) в другой каталог, чтобы пользователь или сценарий могли восстановить файлы вручную после выполнения восстановления. Пользователи, сохраняющие все свои файлы в своем профиле или использующие перемещаемые профили, в большинстве случаев должны иметь возможность восстановить систему без потери своих данных, но важно помнить, что, чтобы избежать потери некоторых данных пользователя, необходимо очень аккуратно создавать решение для восстановления или иметь отличное решение для резервного копирования.
Помните, что вопреки вашим ожиданиям некоторые пользователи будут сохранять данные не в своих профилях. Необходимо обеспечить, чтобы решение учитывало, что оно может случайно удалить данные пользователей, и заблаговременно предупреждать пользователей об этом.
При использовании файловой системы EFS убедитесь, что выполнен план восстановления ключей — вы же не хотите потерять данные из-за невозможности восстановления зашифрованных данных. Аналогично, в случае BitLocker вы должны быть подготовлены к восстановлению зашифрованных томов. Это означает, что нужно использовать Windows PE 2.0 (1.x не может взаимодействовать с BitLocker). Дополнительные сведения о восстановлении BitLocker приведены на веб-узле blogs.msdn.com/si_team.
Наконец, будьте готовы к тому, что некоторых пользователей будет огорчать потеря своих настроек или приложений. Настройки (приложений и самой системы Windows) сохраняются в случайных местах, не обязательно в профиле пользователя. При восстановлении всего раздела операционной системы некоторые пользователи будут спрашивать «куда исчезло приложение X?» или «Почему пропала кнопка Y в приложение Word?» Объясните пользователям, что среда может быть не совсем такой, какой была днем раньше.
Создание собственного решения при помощи Windows PE занимает некоторое время, и при планировании и создании решения необходимо думать о пользователях. Решение для восстановления не должно быть слишком сложным — оно просто должно обеспечивать пользователям выполнение восстановления и возврат к работе за минимальное количество времени с ограниченным обращением в службу технической поддержки.

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


 Заметки разъездного инженера: Бесплатное угощение и полезные советы
Заметки разъездного инженера
Бесплатное угощение и полезные советы
Майкл Дрейгон (Michael Dragone)

Я работаю системным инженером в одной из ведущих страховых компаний, имеющей около 150 сотрудников. Наши потребности в вычислительных ресурсах в действительности очень непритязательны, поскольку основные наши бизнес-приложения основаны на веб-технологиях. В основном мы используем программу Internet Explorer® и, конечно же, пакет Microsoft® Office.
Раз приложения настолько просты, может показаться, что у пользователей не может быть много, а то и вообще может не быть повседневных проблем, с ними связанных. В основном это так. Обычно возникающие проблемы таковы, что средний читатель журнала TechNet Magazine сможет устранить их за считанные секунды.
Основываясь на своем опыте, я пришел к выводу, что квалификация пользователя является важным условием, определяющим число возникающих проблем. Я хотел бы поделиться парой своих приемов, которые использую при работе с нашими работниками, с тем чтобы вы могли пользоваться ими тоже.
Первый — это учебные занятия. Достаточно регулярно мы проводим занятия по изучению новых систем, которые установлены в нашем офисе, новых развертываемых приложений и новых политик, используемых в работе. Аналогично, если мы собираемся ознакомить с основными изменениями системы, мы проводим специальные занятия, которые посвящены этим изменениям, и отвечаем на все вопросы. Мы проводим занятия перед тем, как внести эти изменения, так что наши пользователи оказываются полностью готовыми к ним.
Например, мы намереваемся провести коренное обновление системы телефонии. Хотя наши пользователи по-прежнему будут получать доступ к своей голосовой почте через программу Outlook®, как они делают это сейчас, программное обеспечение, используемое для этого, будет другим. Мы планируем повести учебный курс, в ходе которого производитель телефонной системы ознакомит наших пользователей с новым интерфейсом и ответит на все возникшие у них вопросы еще до начала развертывания системы.
Мы также обсуждаем текущие моменты, по которым у наших пользователей возникают затруднения. Если вы хоть некоторое время работали с системой учетных листков, то вы имеете представление о таких вопросах. Например, одна из сотрудниц никак не могла понять, почему две разные системы должны использовать два разных пароля. Никакие устные объяснения не убедили ее до тех пор, пока она не увидела картинку презентации PowerPoint® и не воскликнула «Ага!»
Из моего опыта я вывел, что, вне зависимости от темы беседы, ключом к успеху совещания является бесплатное угощение и непринужденный тон. Позвольте пользователям задавать любые поросы, в том числе самые «тупые».
Вторым моим советом является совершать прогулки по офису. Ежедневно я трачу по 10-15 минут, чтобы пообщаться с сотрудниками. Если я вижу, что кто-то делает что-нибудь неправильно, я останавливаюсь, и в течение нескольких минут мы обсуждаем с сотрудником, как это делается. Обычно я показываю им другой, более простой способ. Например, один из наших сотрудников то и дело случайно менял местами панели инструментов Outlook и не имел ни малейшего представления, как это исправить. Он молчаливо страдал, пока я не заметил это однажды. Я показал ему, как настраивать панель инструментов таким образом, чтобы после того как он случайно изменит что-нибудь, он смог бы восстановить ее наиболее подходящий вид.
Другие сотрудники могут испытывать проблемы, с которыми они по ряду причин не хотели бы обращаться ни ко мне, ни в службу технической поддержки. Кто-то может испытывать чувство неловкости, считая, что его вопросы глупы и не достойны внимания специалистов по информационным технологиям. Кто-то будет работать на негодной клавиатуре или мыши, не подозревая, что в службе технической поддержки обычно имеется запас как раз на этот случай. Потратив несколько минут, чтобы повидаться с вашими пользователями, вы сможете устранить целый ряд подобных проблем и придумать темы для будущих тренировок. (И не забудьте об угощении!)
Важно помнить о том, что ваши пользователи являются предметом вашей заботы. Многие, если не все, изменения, производимые в системах, политиках и процедурах, хоть как-то, да затронут пользователей. Каждый пользователь будет реагировать на эти изменения по-своему.
Очень часто нам, людям, которые с техникой на «ты», трудно бывает обслужить наших пользователей, которые не столь технически продвинуты. Проявив немного терпения, проводя учебные занятия, вы сможете помочь им полюбить компьютеры так же, как любите их вы. Постепенно, конечно!

Майкл Дрейгон (Michael Dragone) — системный инженер, работающий в одной из ведущих страховых компаний Нью-Йорка. Он имеет сертификаты MCDST и MCSE: Messaging корпорации Майкрософт. В свободное время он любит совершать прогулки по берегу, играть со своей собакой и заниматься настройкой серверов.


 Конфиденциальные сведения о Windows: Балансировка известных библиотек DLL
Конфиденциальные сведения о Windows
Балансировка известных библиотек DLL
Рэймонд Чен (Raymond Chen)

Функция Windows, неофициально называемая «известные библиотеки DLL» (Known DLLs), является списком библиотек DLL (библиотек динамической компоновки), которые обрабатываются особым образом с помощью загрузчика модулей ядра. Если загрузчик в момент загрузки видит программу с динамической связью с известной библиотекой DLL, то эта копия известной библиотеки будет использована немедленно, исключая процедуру поиска, которая обычно выполняется при загрузке модулей. Можно подумать, что это является функцией безопасности (хотя, по общему признанию, очень слабой), но в действительности безопасность никогда не была назначением этой функции. Функция известных библиотек DLL относится только к производительности.
Механизм работы функции известных библиотек DLL менялся со временем. В некоторых версиях Windows® ядро использует список известных библиотек DLL в качестве отправной точки, после чего просматривает все библиотеки DLL, с которыми связаны известные библиотеки DLL, затем — библиотеки DLL, с которыми связаны эти библиотеки, и так далее. Этот процесс образует транзитивное замыкание всех зависимостей и обрабатывает их все как известные. В других версиях Windows такое транзитивное замыкание не строится, вместо этого только явно указанные библиотеки обрабатываются как известные библиотеки DLL. В некоторых версиях Windows известные библиотеки DLL загружаются ядром предварительно, в момент запуска системы; в других версиях такая предварительная загрузка не производится, и ядро просто использует данный список, чтобы оградить себя от трудностей при поиске путей к библиотекам DLL.
От версии к версии менялось не только представление списка известных библиотек DLL. Содержимое раздела реестра KnownDLLs также подвергалось изменению. Группа производительности Windows изменяет как список известных DLL, так и правила, по которым этот список преобразуется в набор библиотек DLL, исходя из понимания того, каким образом приложения используют систему Windows. Как это бывает обычно при проектировании, такие решения являются результатом компромисса. Предварительная загрузка известных библиотек DLL при запуске системы дает возможность приложениям, использующим эти библиотеки, запускаться быстрее, но за это приходится платить. Это требует большего времени запуска системы, возрастает потребление памяти, поскольку указанные библиотеки DLL остаются в памяти вне зависимости от того, используются они или нет. Производительности одних компонентов увеличивается за счет других. Как видно, точное достижение баланса является трудной задачей: этот процесс требует постоянной подстройки, поскольку картина использования постоянно изменяется.
Один из результатов использования известных библиотек DLL, который может показаться не столь очевидным, состоит в том, что известные библиотеки имеют приоритет перед локально переадресуемыми библиотеками DLL. (Мы рассматривали локально переадресуемые библиотеки DLL в январском выпуске этой рубрики за 2007 г.). Если поразмыслить об этом, то можно понять, что такое поведение является ожидаемым. В конце концов, цель указания списка известных библиотек DLL состоит в том, чтобы исключить процедуру поиска путей и тем самым ускорить загрузку библиотек. Если потребуется, чтобы ядро проверило локально зарегистрированные библиотеки DLL, это может привести лишь к замедлению. Можно было бы предположить, что добавление к пути поиска всего одного каталога не имеет большого значения, но если этот каталог оказывается сетевым сервером, расположенным на другой стороне земного шара, добавление всего одного каталога может вызвать огромные потери производительности.
Хотите верьте, хотите нет, но мы изучали программы, работа которых зависит от того, какие библиотеки DLL объявлялись известными. Одна программа содержала файл с именем Version.dll, расположенный в каталоге приложения. В обычных условиях эта закрытая копия файла Version.dll должна была замещать копию файла в системном каталоге, но в ОС Windows XP библиотека Version.dll была указана как известная. Это привело к тому, что копия библиотеки в каталоге приложения игнорировалась, а использовалась копия библиотеки, находившаяся в системном каталоге.
В системе Windows Vista® библиотека Version.dll не объявлена как известная библиотека DLL, возможно, потому что сотрудники группы производительности решили, что приложения не использовали ее настолько часто, чтобы оправдать затраты. В результате программа переставала работать в системе Windows Vista, поскольку приложение фактически надеялось, что ядро проигнорирует библиотеку DLL, которую программа установила в своем каталоге. Программа преднамеренно устанавливала библиотеку DLL в путь поиска, а затем переключалась на Windows, чтобы игнорировать ее! Конечно, если бы требовалось, чтобы система Windows игнорировала файл, то намного более эффективным решением было бы просто не устанавливать этот файл в первом месте. В итоге, компания, которая разрабатывала эту программу, сообщила об ошибке, утверждая, что нашла дыру в безопасности.

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