 TechNet Magazine December 2006
TechNet Magazine December 2006
DECEMBER 2006
Exchange Server 2007

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

Кроме того, вы познакомитесь с самыми последними усовершенствованиями как в сервере Exchange Server 2007, так и в почтовом клиенте Outlook 2007, научитесь более эффективным методам борьбы с нежелательной почтой с помощью средства Sender ID Framework (cистема кода отправителя), а также исследуете ведение журналов в Exchange 2007, которое позволяет добиться лучшего уровня управления и соответствия требованиям.
СТАТЬИ
Exchange Server 2007 Обновление инфраструктуры до Exchange 2007

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

Кейт Фоллис (Kate Follis) Управление с помощью среды управления Exchange

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

Дэвид Строум (David Strome) Exchange и Outlook: совместная работа

Совместное использование Exchange Server 2007 и Microsoft Office Outlook 2007 позволяет сделать качественный скачок в сфере обмена данными и совместной работы. Узнайте больше об упрощенных настройках, улучшенных функциях поиска, единой системе обмена сообщениями и многом другом.

Майкл Халили (Michael Khalili) Exchange 2007 £ и вы всегда на связи

Возможности обмена информацией стали еще разнообразнее. Рассмотрим, как единая система обмена сообщениями и веб-клиент Outlook, встроенные в Exchange Server 2007, позволяют получить доступ ко всем сообщениям из любой точки мира.

Джошуа Трупин (Joshua Trupin) Более мощные средства ведения журнала Exchange 2007

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

Дэвид Строум (David Strome) Защита против нежелательной почты и фишинга с помощью системы кода отправителя

Проверка подлинности электронных сообщений на основе Sender ID Framework (системы кода отправителя) получает все более широкое применение, обеспечивая значительный прогресс в защите от нежелательной почты и фишинг-сообщений. В действительности, более трети мирового объема электронных сообщений уже проходит проверку подлинности и согласовано с системой кода отправителя. Давайте посмотрим, как это работает на самом деле.

Крейг Спизл (Craig Spiezle) и Александр Николаев
РАЗДЕЛЫ
От редактора

Наши достижения

Джошуа Трупин (Joshua Trupin) Арсенал инструментов

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

Грег Стин (Greg Steen) Среда Wndows PowerShell

Простые команды. Мощные возможности администрирования

Дон Джонс (Don Jones) Анализ реализованных проектов

Переход с Exchange 5.5

Уитни Робертс (Whitney Roberts) 		SQL, вопросы и ответы

Предотвращение перезагрузок, установка нескольких обновлений и другое

Редактор – Нэнси Мичелл (Nancy Michell) Эй, программист!

Где подставки для стаканов?

Группа Microsoft Scripting Guys Обеспечение безопасности

Развертывание инфраструктуры открытых ключей (PKI) с глобальным доверием

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

Подробнее о формате Windows Imaging Format

Уэс Миллер (Wes Miller) Секреты Windows

В ожидании RunOnce

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


 Exchange Server 2007: Обновление инфраструктуры до Exchange 2007
Exchange Server 2007 Кейт Фоллис (Kate Follis)

Обновление инфраструктуры до Exchange 2007
Краткий обзор:
  • Новое в Exchange 2007.
  • Подготовка к обновлению.
  • Развертывание на основе ролей.
  • Топология маршрутизации сообщений.

Я вела курсы о переходе с версии Exchange Server 5.5 на версию Exchange 2000 Server. Занятия начинались в 8:30 утра и заканчивались около 6 часов вечера. После занятий у меня уже
ни на что не оставалось сил. Требовалась большая подготовительная работа, чтобы просто перенести ресурсы каталогов, а еще эта путаница с NTDSNoMatch и то, что временами сервер Windows NT® 4.0 никак не хотел устанавливать доверительные отношения. Из-за недостатка времени мы только слегка затрагивали тему администрирования Exchange 2000 Server, однако в классе всегда найдется парочка активных студентов, которые планируют начать переход в пятницу вечером после занятий и полностью выполнить ее за выходные. Я предупреждала, что так делать не следует, советовала выделить больше времени, однако сомневаюсь, что такие студенты прислушивались к моим советам.
О переходе с Exchange 2000 Server или Exchange Server 2003 на Exchange Server 2007 можно сказать то же самое £ следует выделить время на подготовку плана. Обычно процесс перехода зависит от конкретной организации и сложности текущего развертывания системы, однако в любом случае переход будет состоять из нескольких этапов. В небольшой организации все этапы такого перехода можно выполнить за один раз, в то время как крупная организация может принять решение о постепенном внедрении серверных ролей и в течение некоторого времени поддерживать работу обеих версий сервера Exchange в режиме сосуществования. Весь процесс перехода планируется таким образом, чтобы поддерживать функционирование службы сообщений и стабильность работы в течение всего переходного периода. В данной статье я хочу остановиться на основных действиях, необходимых для сохранения в организации нормального обмена сообщениями при обновлении до Exchange Server 2007.

Сложные вопросы перехода
В первую очередь необходимо отметить, что Exchange Server 2007 нужно устанавливать на 64-разрядный компьютер и переход к нему невозможно выполнить простым обновлением какой-либо из предыдущих версий сервера Exchange. Перенос существующих служб обмена сообщениями на сервер Exchange 2007 необходимо проводить постепенно. Чтобы обеспечить возможность включения в систему серверов Exchange 2007, вся инфраструктура Exchange должна работать в собственном режиме. Это значит, что если организация в данный момент использует версию Exchange 5.5, то прежде чем перейти на Exchange 2007, ей необходимо выполнить промежуточный переход на версию Exchange Server 2003.
При планировании перехода следует учесть важные изменения, внесенные в Exchange 2007. Например, развертывание Exchange 2007 выполняется на основе серверных ролей, что дает возможность развернуть сервер с такими ролями, которые необходимы для выбранных служб обмена сообщениями. Можно использовать для развертывания каждой серверной роли отдельное оборудование, а можно установить на одном физическом сервере несколько ролей, притом что администрирование каждой роли будет выполняться независимо. Для получения сведений о каждой из серверных ролей см. боковой заголовок «Серверные роли Exchange 2007».
Серверные роли Exchange Server 2007
Почтовый сервер (Mailbox Server) Роль «Почтовый сервер» обеспечивает хранение сообщений организации. В Exchange 2007 на каждом сервере может находиться до 50 хранилищ. Эти хранилища могут быть установлены как 50 отдельных групп хранилищ, а можно в одной группе хранилища создавать до 50 хранилищ. Роль «Почтовый сервер» является единственной ролью, которую можно устанавливать как кластер. Это означает, что при использовании кластеризации необходимо устанавливать почтовый сервер на отдельном компьютере.
Сервер клиентского доступа Роль «Сервер клиентского доступа» выполняет те же функции, что и внешний сервер. Она обеспечивает доступ к почтовым ящикам тем клиентам, которые обращаются к серверу Exchange, используя протоколы POP3, IMAP4, веб-клиент Outlook®, технологию RPC через HTTPS (новое название £ мобильный Outlook), а также протокол Exchange ActiveSync®.
Транспортный сервер-концентратор (Hub Transport) Данная роль обеспечивает работу служб передачи сообщений SMTP и MAPI в организации, использующей Exchange. Все сообщения, получаемые или отправляемые пользователями организации, обрабатываются транспортным сервером-концентратором. Это хорошо тем, что все сообщения могут передаваться только в соответствии с правилами сервера или политиками ведения журнала, которые предоставляются агентами, размещенными в различных участках транспортного конвейера.
Сервер единой системы обмена сообщениями (Unified Messaging) Данная роль предоставляет голосовой доступ к почтовому ящику. Она объединяется со шлюзом IP/VoIP и IP-АТС и обеспечивает доступ по телефонным линиям к сообщениям и элементам календаря, а также производит запись и преобразование голосовых ответов пользователя. Этой роли в Exchange раньше не было, поэтому ее взаимодействие с более ранними версиями Exchange невозможно.
Пограничный транспортный сервер (Edge Transport) Пограничный транспортный сервер обычно устанавливается в демилитаризованной зоне. Он обеспечивает передачу сообщений по протоколу SMTP между инфраструктурой Exchange и Интернетом, а также защиту от нежелательных сообщений и вирусов с помощью транспортных агентов. Теперь становится возможным использование единых правил на основе единой технологии как для сервера организации, так и пограничного сервера. Подобная модель беспрепятственного взаимодействия упрощает администрирование и обеспечивает легкость интегрирования пограничных серверов.

Исследуйте топологию своей сети
Итак, с чего начать? Чтобы понять, куда следует идти, надо сначала выяснить, где же вы находитесь. Уделите время для того, чтобы оценить состояние среды своей организации и создать описание топологии не только среды сервера Exchange, но и среды службы каталогов Active Directory®. Возможно, пользователям будет приятно узнать, что Exchange 2007 уже не использует маршрутизацию с учетом состояния канала и топологию, основанную на группах маршрутизации и соединителях. Вместо этого Exchange Server 2007 использует все преимущества уже существующей в организации топологии Active Directory. В результате данные всех получателей Exchange и все настройки хранятся в службе каталогов Active Directory, топология маршрутизации создается на основе настроек узла Active Directory, и все роли серверов используют информацию, накопленную на сайте, для получения сведений о службах, выполняющихся на серверах с другими ролями
Убедитесь в том, что существующая топология узла Active Directory полностью использует ресурсы базовой физической сети, а также, что все узлы Active Directory имеют связанные подсети, затем составьте описание существующих узлов Active Directory и соединений по протоколу IP. Также внесите в описание физическое расположение всех серверов Exchange 2003 и структуру групп маршрутизации и их соединителей.
Это наиболее сложный этап в процессе перехода к новой версии: переход с инфраструктуры маршрутизации Exchange на основе групп маршрутизации на инфраструктуру, основанную на использовании узлов Active Directory. Для небольшой организации этот процесс, как правило, достаточно прост. Однако в большой организации с множеством групп маршрутизации потребуется тщательное планирование переходного этапа, когда будут одновременно использоваться приложения Exchange 2003 и Exchange 2007. Самый нежелательный вариант событий – это когда сообщение, посланное сидящим напротив вас пользователем почтового ящика Exchange 2007 на почтовый ящик Exchange 2003, будет направлено через какую-нибудь удаленную группу маршрутизации с использованием низкоскоростного соединения.
Начнем с некоторых предположений относительно существующей топологии:
  • все структуры Exchange 2003 работают в собственном режиме;
  • существует несколько групп маршрутизации;
  • существует несколько узлов Active Directory.
На рис. 1 представлена топология Exchange и Active Directory. Учтите, что чем больше подробностей включено в предварительные планы, тем лучше будет весь проект.
Рис. 1 Топология Exchange и Active Directory
Рис. 1 Топология Exchange и Active Directory (Щелкните изображение, чтобы уменьшить его)
Рис. 1 Топология Exchange и Active Directory
Рис. 1 Топология Exchange и Active Directory (Щелкните изображение, чтобы увеличить его)

Как приложение Exchange 2007 использует Active Directory
При запуске сервера Exchange 2007 устанавливается атрибут узла, который позволяет другим серверам Exchange 2007 обнаружить службы, работающие на данном сервере. Внутри структуры только транспортный сервер-концентратор может использовать протокол SMTP для передачи сообщений внутри организации. Каждый сайт Active Directory, на котором есть почтовый сервер, должен также содержать транспортный сервер-концентратор, а если пользователи обращаются к своим почтовым ящикам с помощью методов, не являющихся методами MAPI, то на каждом сайте должен быть также сервер клиентского доступа. Всякий раз, когда понадобится выполнить обработку сообщения для доставки, оно будет направляться через транспортный сервер-концентратор, который будет принимать решение по поводу его маршрута. Если сообщение направлено на почтовый сервер, расположенный на одном сайте Active Directory с транспортным сервером-концентратором, то он доставит сообщение в почтовый ящик. Если сообщение направлено на почтовый сервер, расположенный на другом сайте, то транспортный сервер-концентратор отправит сообщение транспортному серверу-концентратору на удаленном сайте.
Транспортный сервер-концентратор использует сведения о стоимости IP-соединений узла Active Directory для расчета самого дешевого маршрута к узлу Active Directory, где расположен почтовый ящик получателя. Алгоритм выбора маршрута схож с алгоритмом, используемым в Exchange 2003, однако он основан на цене IP-соединений узла, а не на цене соединителя группы маршрутизации. Более того, сообщение не останавливается на каждом транспортном сервере-концентраторе до самого конца своего пути. Оно проходит напрямую от источника до места назначения. Почему необходимо рассчитывать маршрут с наименьшей ценой, если для передачи сообщения используется сеть IP? Есть несколько причин. Одна из них – это задержка момента ветвления сообщений. При отправке сообщения нескольким получателям может потребоваться доставка на почтовые серверы, расположенные на нескольких узлах Active Directory. Вместо того, чтобы выполнить ветвление сообщения на первом транспортном сервере-концентраторе, приложение Exchange 2007 не производит ветвление до того момента, пока сообщение не достигнет ветвления на маршруте. В результате сообщение будет доставлено непосредственно на сервер с ролью транспортного сервера-концентратора на сайте Active Directory, представляющем собой пункт ветвления. Данное поведение известно под названием «отложенное ветвление».
В случае недоступности места назначения сообщения для определения места помещения сообщения в очередь используется маршрут с наименьшей стоимостью. Если транспортный сервер-концентратор на сайте назначения Active Directory недоступен, отправляющий транспортный сервер-концентратор попытается доставить сообщение на транспортный сервер-концентратор на ближайшем сайте Active Directory в соответствии с маршрутом. Доставка сообщения по маршруту с наименьшей стоимостью будет продолжаться до тех пор, пока оно не достигнет узла Active Directory, где есть доступный транспортный сервер-концентратор. И, наконец, в том случае, если на всем маршруте до целевого узла Active Directory доступный транспортный сервер-концентратор обнаружен не будет, сообщение ставится в локальную очередь. Данный метод помещает сообщение в очередь, расположенную ближе всего к месту назначения, что облегчает и делает более точной диагностику неполадок в сети. Данное поведение известно под названием «постановка в очередь в точке неполадки».
Exchange 2003 работает иначе. Он производит расчет маршрута с наименьшей стоимостью от одной группы маршрутизации до другой в зависимости от цены, назначенной соединителям между группами маршрутизации. Сервер-плацдарм в каждой группе маршрутизации на маршруте получает и затем отправляет сообщение. Если следующий соединитель по маршруту недоступен, то производится расчет альтернативного маршрута. Для извещения других серверов Exchange о неработающем соединителе по организации Exchange проводится отправка извещений об обновлении состояния канала. Серверы-плацдармы производят попытки обойти неработающий соединитель до момента получения извещения о восстановлении работоспособности указанного соединителя.
Задача состоит в том, чтобы сохранить поток почтовых сообщений в крупной организации в период одновременной работы серверов разных версий. В целях сохранения стабильной работы при вводе в среду приложения Exchange 2007 все серверы Exchange 2007 включаются в одну группу маршрутизации. Это означает, что независимо от того, на каком сайте Active Directory расположен сервер Exchange 2007, Exchange 2003 будет считать его принадлежащим к указанной единой группе маршрутизации. Это позволяет установить соединитель группы маршрутизации между этой группой и группами Exchange 2003 таким образом, чтобы сервер Exchange 2003 имел возможность определять способ маршрутизации сообщений к Exchange 2007. Exchange 2007 будет также использовать соединитель группы маршрутизации для определения способа доставки сообщений к серверу Exchange 2003. Однако при определении маршрута Exchange 2007 будет всегда отдавать предпочтение другому серверу Exchange 2007 и никогда не станет использовать соединители группы маршрутизации Exchange 2003 для доставки сообщения на другой сервер Exchange 2007.

Ввод первого сервера Exchange 2007
При установке первого сервера Exchange 2007 в организации Exchange 2003 необходимо выбрать сервер-плацдарм Exchange 2003, с помощью которого будет устанавливаться первый соединитель группы маршрутизации.
На рис. 2 показано, как ввод первого сервера Exchange 2007 отражается на топологии организации.
Рис. 2 Установка первого сервера Exchange 2007
Рис. 2 Установка первого сервера Exchange 2007 (Щелкните изображение, чтобы уменьшить его)
Рис. 2 Установка первого сервера Exchange 2007
Рис. 2 Установка первого сервера Exchange 2007 (Щелкните изображение, чтобы увеличить его)
Пока все идет нормально. Заметьте, что стоимость по умолчанию соединителя группы маршрутизации, созданного в Exchange 2007, равна всего лишь 1. Сообщения электронной почты продолжают поступать как обычно через серверы Exchange 2003, а если сообщение отправлено пользователю сервера Exchange 2007 с любого сервера Exchange 2003, то оно будет доставлено через группу маршрутизации «Акапулько». При создании соединителя группы маршрутизации выбранный сервер-плацдарм Exchange 2003 автоматически становится членом универсальной группы безопасности «ExchangeLegacyInterop» и ему предоставляются действительные разрешения для отправки и получения сообщений электронной почты на адрес сервера Exchange 2007 и с него. При назначении сервера Exchange 2007 исходным или целевым сервером для соединителя следует всегда использовать командлет «New-RoutingGroupConnector» (создать соединитель группы маршрутизации) средства Exchange Management Shell. Для изменения настроек соединителя группы маршрутизации можно также использовать командлет «Set-RoutingGroupConnector» (установить соединитель группы маршрутизации). Например, для обеспечения избыточности можно добавить исходные и целевые серверы к начальному соединителю группы маршрутизации. (Для получения дополнительных сведений см. статью Дэвида Строума (David Strome) о средстве Exchange Management Shell в этом выпуске журнала TechNet.)

Подготовка к переносу нескольких почтовых ящиков
Следующим шагом является перенос нескольких почтовых ящиков с серверов Exchange 2003 на серверы Exchange 2007. Для выполнения данного действия воспользуйтесь командлетом Move-Mailbox (переместить почтовый ящик). Прежде чем отключить серверы Exchange 2003, необходимо создать на сервере Exchange 2007 соединители отправки и приема, чтобы заменить все соединители SMTP, которые были назначены на сервере Exchange 2003 для обработки маршрутов к внешним пространствам адресов SMTP.
На следующей диаграмме показано перемещение ресурсов из группы маршрутизации «Акапулько» на сервер Exchange 2007. Группу маршрутизации «Акапулько» теперь можно отключить, однако это означает необходимость назначить соединитель группы маршрутизации уже другой группе. На рис. 3 показан пример настройки соединителя группы маршрутизации к серверу-плацдарму группы маршрутизации «Майами север».
Рис. 3 Настройка соединителя группы маршрутизации
Рис. 3 Настройка соединителя группы маршрутизации (Щелкните изображение, чтобы уменьшить его)
Рис. 3 Настройка соединителя группы маршрутизации
Рис. 3 Настройка соединителя группы маршрутизации (Щелкните изображение, чтобы увеличить его)
Рассмотрим перемещение группы маршрутизации «Лос-Анджелес восток» на Exchange 2007. Возникает ситуация, когда обеспечение маршрутизации немного усложняется. На рис. 4 показано, что сервер Exchange 2007 был установлен на сайте «Лос-Анджелес», вторая группа маршрутизации была отключена, но создание дополнительных соединителей группы маршрутизации не было выполнено.
Рис. 4 Установка Exchange 2007 на сайте «Лос-Анджелес».
Рис. 4 Установка Exchange 2007 на сайте «Лос-Анджелес». (Щелкните изображение, чтобы уменьшить его)
Рис. 4 Установка Exchange 2007 на сайте «Лос-Анджелес».
Рис. 4 Установка Exchange 2007 на сайте «Лос-Анджелес». (Щелкните изображение, чтобы увеличить его)
Теперь при отправке сообщения с сервера Exchange 2007 сайта «Лос-Анджелес» на сервер Exchange 2003 группы маршрутизации «Лос-Анджелес запад» оно будет отправляться сначала к группе «Акапулько», далее к «Майами север», «Майями юг» и, наконец, к «Лос-Анджелес запад». Если сообщение отправляется с сервера Exchange 2003, расположенного в группе маршрутизации «Лос-Анджелес запад», на сервер Exchange 2007 узла «Лос-Анджелес», то оно будет отправляться начала к группе «Майями юг», далее к «Майами север», «Акапулько», и, наконец, обратно к узлу «Лос-Анджелес». Вот так-то.
Чтобы избежать подобной ситуации, необходимо добавить второй соединитель группы маршрутизации. На рис. 5 показано добавление соединителя группы маршрутизации от «Лос-Анджелес запад» к серверу Exchange 2007, расположенному на сайте «Лос-Анджелес». Примечание: если необходимо избежать избыточности соединителей групп маршрутизации, следует убедиться, что первый соединитель группы маршрутизации настроен в концентраторе Active Directory, имеющем надежное соединение.
Рис. 5 Более эффективная маршрутизация
Рис. 5 Более эффективная маршрутизация (Щелкните изображение, чтобы уменьшить его)
Рис. 5 Более эффективная маршрутизация
Рис. 5 Более эффективная маршрутизация (Щелкните изображение, чтобы увеличить его)
При этом возникает проблема, которая на первый взгляд может быть неочевидна. Теперь существует несколько путей от группы маршрутизации Exchange 2007 и к ней. Поскольку группа маршрутизации Exchange 2007 не учитывает состояние канала, возникает возможность образования петли маршрутизации. Сервером Exchange 2003 может быть выбран альтернативный маршрут для обхода нефункционирующего соединителя, в то же время Exchange 2007 будет всегда выбирать маршрут с наиболее низкой стоимостью. Исключить возникновение данной проблемы можно путем ограничения количества несущественных извещений об обновлении состояния канала, что предотвратит отправку извещений о неработающем соединителе, однако разрешит отправку извещений об изменении настроек. Это важно, поскольку серверы Exchange 2003 должны быть оповещены о новых соединителях групп маршрутизации, но они не должны выполнять расчет альтернативного маршрута. Конечный результат состоит в том, что серверы Exchange 2003 будут демонстрировать то же самое поведение «постановка в очередь в точке неполадки», что и серверы Exchange 2007.
На рис. 6 показано дальнейшее перемещение ресурсов Exchange 2003 на Exchange 2007. Извещения об обновлении состояния каналов ограничены, а соединители, поддерживающие логический путь маршрутизации, установлены.
Рис. 6 Дальнейшее перемещение ресурсов Exchange 2003 на сервер Exchange 2007
Рис. 6 Дальнейшее перемещение ресурсов Exchange 2003 на сервер Exchange 2007 (Щелкните изображение, чтобы уменьшить его)
Рис. 6 Дальнейшее перемещение ресурсов Exchange 2003 на сервер Exchange 2007
Рис. 6 Дальнейшее перемещение ресурсов Exchange 2003 на сервер Exchange 2007 (Щелкните изображение, чтобы увеличить его)
Тем не менее, существует еще одна проблема. Наличие островов состояний каналов на узлах «Редмонд» и «Ванкувер». Почтовые сообщения доставляются исправно, хотя и через «Майами», однако «Редмонд» и «Майами» не могут обмениваться извещениями об изменениях настроек состояния каналов. Для сохранения существующей таблицы маршрутизации необходимо настроить дополнительный соединитель группы маршрутизации между узлами «Редмонд» и «Ванкувер». Можно установить высокую цену этого соединителя группы маршрутизации, которая предотвратит его использование сервером Exchange 2003, однако этот соединитель будет позволять обмен сообщениями об изменениях настроек состояния канала.
Тщательное планирование позволяет избежать неполадок, которые могут быть вызваны эксплуатацией двух независимых топологий маршрутизации Exchange. Наиболее плавный переход осуществляется путем переноса отдельных групп маршрутизации с переходом к следующей группе до того момента, пока не останутся только серверы Exchange 2007.
До настоящего момента в статье основное внимание уделялось изменениям маршрутизации в Exchange 2007 и их влиянию на процесс перехода. Существуют также иные сложные моменты, которые необходимо учитывать при планировании перехода на Exchange 2007.
Внешние серверы Exchange 2003 не могут получать доступ к почтовым ящикам сервера Exchange 2007. Однако сервер клиентского доступа Exchange 2007 с легкостью подключается к почтовым ящикам Exchange 2003. При использовании сервера клиентского доступа Exchange 2007 необходимо просто использовать ту же версию OWA (веб-доступа Outlook), что и на сервере электронных сообщений, где хранится почтовый ящик. Если развертывание Exchange 2007 производится на отдельном компьютере, то роль сервера клиентского доступа должна быть первой ролью, которая вводится в сайт Active Directory. Перед перемещением почтовых ящиков на сервер Exchange 2007 необходимо заменить все внешние серверы Exchange 2003, обеспечивающие доступ из Интернета к почтовым ящикам, на серверы клиентского доступа Exchange 2007.
Как упоминалось ранее, на каждом сайте, содержащем роль почтового сервера, должна быть также роль клиентского доступа (при наличии клиентов MAPI £ а как в наши дни можно прожить без OWA?) и роль транспортного сервера-концентратора. Таким образом, если требуется расположить на одном компьютере несколько ролей, следует при выборе ролей обязательно включить сервер клиентского доступа. Обычная установка включает роли сервера-концентратора, клиентского доступа и почтового сервера £ это все, что необходимо для создания полнофункциональной среды Exchange.
Другой момент состоит в том, что при переходе на новую версию необходимо обновить приложение почтового клиента (Outlook). Использование всех возможностей Exchange 2007 без обновления почтовых клиентов до версии Outlook 2007 невозможно. Это обновление включает в себя расширенные параметры сообщений об отсутствии на работе и возможности управляемых папок почтовых ящиков.
Необходимо также решить, когда следует развертывать роль пограничного транспортного сервера. Технически можно заменить сервер ретрансляции SMTP в демилитаризованной зоне и промежуточные узлы сервером с ролью пограничного транспорта до или после создания всех остальных ролей сервера Exchange 2007. Если вначале развертывается пограничный транспортный сервер, то общее количество доступных функций будет ограничено, поскольку Exchange 2003 не может реплицировать необходимые пограничному транспортному серверу данные получателей и конфигурации из Active Directory в ADAM.
После установки как минимум одного транспортного сервера-концентратора можно приступить к развертыванию пограничного транспортного сервера в периферийной сети и далее подписать пограничный транспортный сервер на сайт Active Directory, где расположен транспортный сервер-концентратор. Служба EdgeSync на пограничном транспортном сервере-концентраторе скопирует в ADAM поднабор данных получателей, который содержится в Active Directory.
Эти данные позволяют пограничному транспортному серверу выполнять поиск получателей и компоновать списки безопасных отправителей, что дает возможность полностью использовать функции агентов по борьбе с нежелательными сообщениями, работающих на пограничном транспорте. В дополнение EdgeSync создает соединители Send (отправить), которые необходимы для обмена сквозным потоком электронных сообщений между организацией Exchange и Интернетом. Это может упростить процесс замены SMTP-соединителей Exchange 2003, обеспечивающих маршрутизацию к внешним пространствам адресов.
Уделив некоторое время планированию перехода на Exchange 2007, можно обеспечить четкость выполнения и отсутствие неполадок при выполнения данной задачи.

Кейт Фоллис (Kate Follis) в настоящее время работает старшим специалистом по публикациям в группе документации по Exchange 2007. Эта группа специализируется на серверных ролях «Пограничный транспортный сервер» и «Транспортный сервер-концентратор». До перехода на работу в корпорацию Майкрософт Кейт несколько лет вела курсы по программным продуктам Exchange и Active Directory в качестве сертифицированного преподавателя Майкрософт.
© 2007 Корпорация Майкрософт и компания CMP Media, LLC. Все права защищены; полное или частичное воспроизведение без разрешения запрещено.


 Exchange Server 2007: Управление с помощью среды управления Exchange
Exchange Server 2007 Дэвид Строум (David Strome)

Управление с помощью среды управления Exchange
Краткий обзор:
  • Как работает среда управления Exchange.
  • Как использовать командлеты.
  • Командлеты и команды.

Специалисты, ответственные за администрирование среды Exchange, вероятно, слышали о том, что выпускаемый вскоре сервер Exchange Server 2007 содержит новый интерфейс командной строки, называемый средой управления Exchange. Построенная на основе среды Microsoft Windows PowerShell,
среда управления Exchange является мощным средством управления всеми функциями сервера Exchange Server 2007 из командной строки. Пользуясь командной строкой, можно непосредственно работать со средой управления Exchange, писать сценарии автоматизации или интегрировать собственные приложения с основным ядром. Рисунок 1 показывает работу среды.
Рис. 1 Среда управления Exchange
Рис. 1 Среда управления Exchange (Щелкните изображение, чтобы уменьшить его)
Рис. 1 Среда управления Exchange
Рис. 1 Среда управления Exchange (Щелкните изображение, чтобы увеличить его)
Консоль управления Exchange не просто использует среду управления Exchange для выполнения операций, в ней имеются также мастера, показывающие выполняемые команды. Можно скопировать команды, создаваемые с помощью мастеров, и вставить их непосредственно в командную строку или сценарий. После внесения в параметры необходимых изменений рекомендуется проверить сценарии или команды с помощью параметра WhatIf (что если), который позволяет увидеть результаты до внесения изменений в среду.
Среда управления Exchange предоставляет надежную и гибкую платформу для создания сценариев, которую можно объединить с уже имеющимися средствами создания сценариев, и позволяет производить обмен данными с такими источниками данных, как COM и инструментарий управления Windows (WMI), на их собственном языке команд. Для принятия и возврата структурированных данных вместо обычного текста в среде управления Exchange, основанной на платформе .NET Framework, используются командлеты £ элементарные функциональные единицы среды управления Exchange. Более подробные сведения о командлетах будут приведены ниже.

Оснастка среды Windows PowerShell
Первым шагом в освоении среды управления Exchange является изучение того, как она связана со средой Windows PowerShell™, новым мощным и гибким интерфейсом командной строки на основе платформы .NET Framework. Эта среда объединяет лучшие качества нескольких других оболочек, а также содержит много новых возможностей. Среда Windows PowerShell предназначена для размещения других приложений, что во многом аналогично тому, как консоль управления (MMC) служит для размещения различных оснасток, поставляемых вместе с приложениями. Среда управления Exchange станет первой оснасткой, выпущенной для среды Windows PowerShell.
Оснастки £ это коллекции командлетов, используемые для управления приложением или крупным компонентом. Для использования их необходимо предварительно загрузить. К счастью, процедура запуска оснастки среды управления Exchange чрезвычайно проста. Однако прежде следует рассмотреть некоторые важные моменты, которые нужно понимать при чтении данной статьи и работе в среде управления Exchange.
Командлеты. Командлеты похожи на встроенные команды в других оболочках, например команду dir в оболочке cmd.exe. Как и эти знакомые команды, командлеты могут вызываться непосредственно из командной строки в среде управления Exchange и выполняться в контексте среды, а не в качестве отдельного процесса. Командлеты, в отличие от команд других оболочек, имеют описательные имена, состоящие из глагола и существительного. Глагол описывает действие, выполняемое командлетом, а существительное описывает компонент или свойство, над которым это действие производится.
Таким образом, пользователю не нужно пытаться угадать, что делает командлет. Название командлета Move-Mailbox (переместить почтовый ящик) точно говорит о его назначении.
Чтобы понять, чем командлеты отличаются от обычных команд, прочитайте статью в боковой панели «Cmdlets vs. Commands» (командлеты и команды) раздела .NET Framework 3.0 пакета SDK Windows® по адресу: windowssdk.msdn.microsoft.com/en-us/library/ms714395.aspx (на английском языке).
Параметр Identity and Positional Parameter (параметр идентификации и позиции). Параметр Identity может использоваться с большинством командлетов, относящихся к серверу Exchange. Данный параметр предоставляет доступ к уникальным идентификаторам, обозначающим определенные объекты сервера Exchange Server 2007, предоставляя возможность осуществления действий над отдельными объектами Exchange с помощью уникального значения по выбору пользователя.
Параметр Identity является коллекцией значений других параметров. Данные значения уникальны в пределах всего множества объектов. Можно задать значения указанных других параметров, например Name (имя) и DistinguishedName (различающееся имя), либо их значения могут назначаться системой, как в случае идентификатора GUID. Дополнительные параметры (в случае их использования), а также их значения зависят от объекта, параметры которого необходимо указать.
Параметр Identity считается позиционным параметром, поскольку его значение можно задать без указания имени. Параметр является позиционным, если его атрибут Parameter Position (позиция параметра) является целым числом. Это число указывает, на какой позиции в командной строке командлета находится значение данного параметра. В силу того что параметр Identity является позиционным и расположен в позиции 0, являющейся самой первой позицией, любое значение, введенное в эту позицию без имени параметра, считается значением параметра Identity. Это позволяет уменьшить количество нажатий клавиш, необходимых для ввода команд. Например,
Get-Mailbox –Identity "Kim Akers"
выполняет то же действие, что и
Get-Mailbox "Kim Akers"
Pipelining (конвейерная обработка). Конвейерная обработка в среде управления Exchange £ это такая организация работы, при которой один командлет использует при выполнении своей операции выходные данные другого командлета. Конвейерная обработка осуществляется путем использования символа «|». Все командлеты, в названия которых входят различные глаголы, но одно и то же существительное, могут использовать информацию, получаемую друг от друга по конвейеру. Некоторые наборы командлетов с определенным существительным в названии позволяют передавать данные через конвейер командлетам с другими существительными.
Использование конвейерной обработки для связывания действий двух или нескольких командлетов позволяет создавать мощные инструменты из простых компонентов. Например, можно использовать один командлет для сбора данных, передавать эти данные второму командлету для фильтрации, а затем передавать полученное подмножество данных третьему командлету для осуществления операций лишь над этим подмножеством.

Запуск среды управления Exchange
Самый простой способ загрузить эту среду £ нажать кнопку «Пуск», выбрать команду «Программы», затем выбрать команду Microsoft Exchange Server 2007, а затем щелкнуть пункт «Среда управления Exchange».
Второй способ загрузки оснастки среды управления Exchange состоит в ручном запуске из сеанса Windows PowerShell. Нажмите кнопку Start, выберите команду Programs и щелкните пункт Windows PowerShell. После того как среда Windows PowerShell запустится, для загрузки среды управления Exchange выполните следующую команду:
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin
Существуют некоторые различия между загрузкой оснастки среды управления Exchange с помощью меню "Программы" и запуском вручную с помощью командлета Add-PSSnapin. При использовании для запуска пункта меню «Программы» происходит не только загрузка оснастки среды управления Exchange, но также и запуск сценария среды Windows PowerShell для настройки пользовательской среды управления Exchange. Чтобы настроить аналогичную среду управления после загрузки среды управления Exchange, произведенной вручную, следует перейти в подкаталог bin каталога, где установлен Exchange, например, C:\Program Files\Microsoft\Exchange Server\Bin. Затем необходимо ввести следующую команду:
..\Exchange.ps1
Информацию о настройке среды Windows PowerShell под конкретные требования можно получить, изучив сценарий Exchange.ps1. При загрузке среды управления Exchange на экран выводится изображение, подобное приведенному на рис. 2..
Рис. 2 Приветствие среды управления Exchange
Рис. 2 Приветствие среды управления Exchange (Щелкните изображение, чтобы уменьшить его)
Рис. 2 Приветствие среды управления Exchange
Рис. 2 Приветствие среды управления Exchange (Щелкните изображение, чтобы увеличить его)

С чего начать
Поскольку среда имеет обширный состав командлетов, чрезвычайно полезными ресурсами являются командлет Get-Help (показать справку) и файл справки Exchange Server 2007. Раздел «Operations» (Операции) файла справки Exchange Server 2007 содержит десятки инструкций, охватывающих выполнение большинства административных задач.
При вводе командлета Get-Help без параметров на экран выводятся общие сведения об использовании функции справки. Для получения справки о конкретном командлете введите Get-Help, а затем название командлета, о котором необходимо получить сведения. Составом выводимых сведений можно управлять с помощью параметров Detailed (подробно), Full (полностью) и Example (пример). Данные параметры добавляются в конце команды. Например, команда Get-Help название командлета –Full выдает все имеющиеся разделы справки по данному командлету.
Использование командлета Get-Help с параметром Parameters (параметры) позволяет получить сведения о конкретном параметре или нескольких параметрах какого-либо командлета. Так, для просмотра тех параметров командлета Set-Mailbox, которые содержат слово "quota", и их описаний следует использовать следующую команду:
Get-Help Set-Mailbox –Parameter *quota*
Может потребоваться просмотреть список командлетов, управляющих какой-то ролью сервера или свойством компонента или влияющих на ряд объектов в рамках определенных функций. Командлет Get-Help позволяет сделать это с помощью трех параметров £ Role (роль), Component (компонент) и Functionality (функция). При использовании данного командлета с приведенными параметрами их значения необходимо заключить в подстановочные символы £ звездочки (*). Ниже приведены примеры вызова командлета Get-Help с каждым из этих параметров:
Get-Help -Role *Mailbox*
Get-Help -Component *Recipient*
Get-Help -Functionality *Server*
Дополнительные сведения приведены в разделе «Getting Help» файла справки Exchange Server 2007. Файл справки содержит полный список возможных значений параметров role, component и functionality.

Выходные данные команды Formatting (формат)
По умолчанию при выводе результатов на экран среда управления Exchange отображает только часть доступных свойств каждого объекта. Однако доступ ко всем свойствам нетрудно получить, передавая с помощью конвейерной обработки выходные данные команды следующим трем командлетам форматирования: Format-List (форматировать список), Format-Table (форматировать таблицу) и Format-Wide (форматировать во всю ширину). Можно предположить, что необходимость в использовании командлетов Format-List и Format-Table будет возникать регулярно, поэтому рассмотрим их подробнее.
Командлет Format-List получает входные данные с конвейера и выдает результат в виде списка с вертикальными столбцами, содержащими все указанные свойства каждого объекта. Выбрать свойства, подлежащие отображению, можно с помощью параметра Property (свойство). Следует отметить, что параметр Property является позиционным, то есть необходимо задавать лишь значения, а не само имя параметра. Если вызов командлета Format-List производится без задания каких-либо параметров, в результате его выполнения отображаются все свойства. Данный командлет вместо усечения строк производит их перенос. Одним из оптимальных вариантов использования Format-List является переопределение стандартного вида выходных данных командлета таким образом, чтобы получить дополнительные или более конкретные сведения. Например:
Get-DistributionGroup | Format-List Name, *OnlyFrom,
PrimarySmtpAddress, *Size*
На рис. 3 показан результат выполнения этой команды.
Рис. 3 Пример результата выполнения командлета Format-List
Рис. 3 Пример результата выполнения командлета Format-List (Щелкните изображение, чтобы уменьшить его)
Рис. 3 Пример результата выполнения командлета Format-List
Рис. 3 Пример результата выполнения командлета Format-List (Щелкните изображение, чтобы увеличить его)
Командлет Format-Table позволяет вывести элементы на экран в формате таблицы, снабженной заголовками, где данные о свойствах располагаются в столбцах. По умолчанию многие командлеты, такие как Get-Mailbox (получить почтовый ящик) и Get-JournalRule (получить правило журнала), выводят результаты в формате таблицы. Среди параметров командлета Format-Table содержатся параметры Properties (свойства) и GroupBy (группировать по). Использование данных параметров идентично их использованию с командлетом Format-List. Чтобы на экране окончания строк не отсекались, а отображались полностью, используйте параметр Wrap (перенести), как показано ниже:
Get-Mailbox –Database Research | Format-Table Name,
ProhibitSendQuota, Database –Wrap
Результат показан на рис. 4.
Рис. 4 Пример результата выполнения Format-Table»
Рис. 4 Пример результата выполнения Format-Table» (Щелкните изображение, чтобы уменьшить его)
Рис. 4 Пример результата выполнения Format-Table»
Рис. 4 Пример результата выполнения Format-Table» (Щелкните изображение, чтобы увеличить его)
Использование в параметре командлета подстановочного символа позволяет задать несколько свойств без необходимости ввода каждого свойства в отдельности. Например, приведенная ниже команда возвращает все свойства, начинающиеся с Email.
Get-Mailbox | Format-List Email*

Практические занятия
Теперь, рассмотрев несколько основных команд, разберем приведенные ниже примеры. Они иллюстрируют широкие возможности и гибкость среды управления Exchange и позволяют получить некоторые практические навыки.
Первая команда создает 10 пользователей с именами User1 £ User10:
1..10 | ForEach { Net User "User$_" MyPassword=01 /ADD
/Domain; Enable-Mailbox "User$_" -Database "Mailbox
Database" }
Разберем этот пример. Команда 1..10 выводит целые числа от 1 до 10 и передает их через конвейер командлету ForEach (для каждого). Командлет ForEach обрабатывает каждый объект при его получении, выполняя для каждого объекта набор команд, заключенных в фигурные скобки. Команда Net User (сетевой пользователь) создает нового пользователя домена, а командлет Enable-Mailbox (включить почтовый ящик) создает на локальном сервере новый почтовый ящик в базе данных Mailbox Database (база данных почтовых ящиков). Эти две команды разделены точкой с запятой, поэтому могут быть помещены в одну командную строку. Переменная $_ является специальной переменной, содержащей значение текущего объекта конвейера. В данном примере переменная $_ содержит целое число, которое в данный момент обрабатывается конвейером.
Следующий пример позволяет просмотреть содержимое почтовых ящиков, размещенных на сервере с именем MBX, и возвращает значения свойств Name (имя), Mailbox Database (база данных почтовых ящиков) и quota (квота) для каждого из почтовых ящиков.
Get-Mailbox –Server MBX | Format-Table
Name,Database,*quota*
Командлет Get-Mailbox возвращает все почтовые ящики, заданные с помощью параметра Server (сервер), и передает выходные данные для каждого из почтовых ящиков через конвейер командлету Format-Table. По умолчанию Format-Table отображает все свойства, возвращаемые командлетом, если только не заданы конкретные свойства, которые нужно отобразить. В данном случае запрашиваются только свойства Name и Database, а также все свойства, содержащие строку quota. На рис. 5 показано возможное представление результата.
Рис. 5 Результат выполнения команды Get-Mailbox
Рис. 5 Результат выполнения команды Get-Mailbox (Щелкните изображение, чтобы уменьшить его)
Рис. 5 Результат выполнения команды Get-Mailbox
Рис. 5 Результат выполнения команды Get-Mailbox (Щелкните изображение, чтобы увеличить его)
В следующем примере устанавливается квота на отправку в размере 600 МБ для всех пользователей организации, которые имеют электронную почту и в названии должности которых входит слово «Manager» (менеджер).
Get-User –Filter { Title –Like "*Manager*"}
–RecipientTypeDetails UserMailbox | Set-Mailbox
–ProhibitSendQuota 600MB
Выполняющийся без параметров командлет Get-User (получить пользователя) возвращает всех пользователей в службе каталогов Active Directory, включая пользователей, не имеющих почтовых ящиков. Для получения множества пользователей, которое может быть использовано командлетом Set-Mailbox, необходимо указать командлету Get-User, что нужно выдать лишь те объекты из службы каталогов Active Directory, которые соответствуют пользователям, имеющим электронную почту. Параметр RecipientTypeDetails (сведения о типе получателя) позволяет задать тип получателя, зарегистрированного в Active Directory, в данном случае это UserMailbox (почтовый ящик пользователя). Затем необходимо получить множество пользователей, являющихся менеджерами и имеющих почтовые ящики. В данном примере производится заполнение свойства Title (должность) всех объектов пользователей службы каталогов Active Directory. Для определения того, какие пользователи являются менеджерами, данное значение можно использовать с параметром Filter (фильтр), который дает серверу команду возвратить только те объекты службы каталогов Active Directory, которые соответствуют заданным критериям. Это называется фильтрацией на стороне сервера. Полученный набор объектов передается командлету Set-Mailbox, который устанавливает для каждого почтового ящика свойство ProhibitSendQuota (квота запрета отправки) равным 600 МБ.
Теперь произведем проверку результатов выполнения команды удаления всех почтовых ящиков, являющихся членами группы рассылки. Вот эта команда:
Get-DistributionGroupMember "Fourth Year Students" |
 Where { $_.RecipientType –Eq "UserMailbox" } | Remove-
 Mailbox -WhatIf
Первый командлет возвращает объекты получателей, являющихся членами группы рассылки «Fourth Year Students» (студенты четвертого курса). Затем командлету Remove-Mailbox (удалить почтовый ящик) передаются лишь те объекты получателей, которые соответствуют значению UserMailbox (почтовый ящик пользователя) параметра RecipientType (тип получателя). Вместо удаления почтовых ящиков командлет Remove-Mailbox выведет на экран предполагаемое действие, а также объекты, над которыми предполагалось его выполнение. Командлет Get-DistributionGroupMember (получить членов группы рассылки) возвращает список объектов получателей, являющихся членами группы рассылки «Fourth Year Students». Однако, поскольку командлет Remove-Mailbox работает только с пользователями, имеющими электронную почту, необходимо отфильтровать все типы получателей, за исключением UserMailbox. В отличие от некоторых других командлетов Get-DistributionGroupMember не имеет командлета Filter, что означает, что он не может выполнять фильтрацию на стороне сервера. Для командлетов, которые не могут выполнять фильтрацию на стороне сервера (в связи с отсутствием преимуществ в производительности), можно использовать командлет Where (где) для выполнения фильтрации на стороне клиента. Этот командлет извлекает все объекты и производит фильтрацию на локальном клиентском компьютере. Командлет Where пропускает только те объекты, которые соответствуют заданным критерям. Объекты, у которых тип пользователя RecipientType равен UserMailbox, передаются командлету Remove-Mailbox. Данный командлет удаляет объект пользователя службы каталогов Active Directory и помечает почтовый ящик для удаления. При использовании параметра WhatIf командлет Remove-Mailbox отображает подобный текст:
What if: Removing the Mailbox "contoso.com/Users
/user10" will remove the Windows user object and mark
the mailbox in the database for removal.
При получении удовлетворительных результатов предполагаемого выполнения команды можно выполнить ее вновь без параметра WhatIf. Для некоторых командлетов, таких как командлеты, содержащие в названии глагол «Remove» (удалить), перед выполнением каких-либо изменений среда автоматически запросит подтверждение. Пользователю предоставляется возможность пройти изменения по шагам, либо дать среде команду не запрашивать подтверждение, либо отменить дальнейшую обработку. При использовании командлетов, по умолчанию не выдающих запрос подтверждения, можно включить режим подтверждения с помощью параметра Confirm (подтвердить).

Заключение
Теперь, после демонстрации возможностей использования командлетов, можно приступить к самостоятельным экспериментам, чтобы убедиться в том, насколько средства среды управления Exchange и Microsoft Windows PowerShell могут быть полезны при решении задач управления системами. Дополнительные сведения по данному вопросу можно получить, обратившись к следующим источникам. Дополнительные сведения о среде управления Exchange см. в файле справки по Exchange Server 2007 по адресу go.microsoft.com/fwlink/?LinkId=69434 (на английском языке), в центре сценариев Windows Powershell по адресу go.microsoft.com/fwlink/?LinkId=71134 (на английском языке), а также в блоге группы разработчиков Exchange team blog по адресу msexchangeteam.com (на английском языке).

Дэвид Строум (David Strome) более года работает техническим писателем в группе обучения пользователей Exchange в корпорации Майкрософт. До того как поступить на работу в корпорацию Майкрософт (Редмонд, штат Вашингтон), Дэвид в течение 10 лет занимался разработкой, реализацией и администрированием серверов Exchange в различных компаниях провинции Британская Колумбия (Канада). Отправить сообщение автору можно по адресуdstrome@microsoft.com..


 Exchange Server 2007: Exchange и Outlook: вместе £ лучше
Exchange Server 2007 Майкл Халили (Michael Khalili)

Exchange и Outlook: вместе £ лучше
Краткий обзор:
  • Упрощенная установка.
  • Интегрирование факсимильной связи, голосовой и электронной почты.
  • Использование управляемых папок для обеспечения соблюдения установленных правил.

В течение нескольких лет сервер Microsoft Exchange Server и диспетчер электронной почты Outlook обеспечивали надежный обмен электронной почтой для миллионов людей, помогая им организовывать совместную работу, эффективно использовать свое время, а также без проблем упорядочивать список контактов. И может оказаться интересно, что эта парочка сможет сделать на бис. Ну что ж, выпуск и сервера Exchange Server 2007,
и диспетчера электронной почты Microsoft Office Outlook 2007 ожидается в ближайшее время, а их совместное использование позволит сделать огромный скачок в сфере обмена данными и совместной работы.
Усовершенствования, внесенные в Exchange Server 2007 и Office Outlook® 2007, становятся очевидны с момента запуска клиента Outlook. В предыдущих версиях диспетчера электронной почты Outlook требовалось, чтобы пользователь знал имя своего почтового сервера Exchange, что ставило многих пользователей в тупик. Это приводило к частым обращениям в службу поддержки или созданию сложных сценариев инициализации, что увеличивало стоимость и сложность эксплуатации эффективной среды обмена сообщениями. Теперь же с помощью веб-службы автообнаружения Exchange диспетчер электронной почты Outlook может автоматически настраивать учетную запись клиента, подключенного к домену. Если клиент не подключен к домену, то пользователю будет необходимо ввести лишь имя, адрес электронной почты и пароль. Все остальное диспетчер электронной почты Outlook и сервер Exchange сделают сами (см. рис. 1).
Рис. 1 Настройка учетной записи
Рис. 1 Настройка учетной записи (Щелкните изображение, чтобы уменьшить его)
Рис. 1 Настройка учетной записи
Рис. 1 Настройка учетной записи (Щелкните изображение, чтобы увеличить его)
Аналогично, в то уходящее в прошлое время пользователи не только производили настройку диспетчера электронной почты Outlook для первоначального использования, но и должны были производить повторную настройку Outlook при каждой смене почтового сервера. Даже если пользователям отправлялось электронное сообщение о предстоящей миграции почтовых ящиков, вечно занятые сотрудники не обращали особого внимания на информацию об этом, пока однажды утром не обнаруживали, что не могут воспользоваться Outlook. И в службу поддержки поступал очередной звонок. Веб-службы Autodiscover решат и эту проблему. При переносе пользователя с одного почтового сервера на другой диспетчер электронной почты Outlook обнаруживает, что старые настройки стали недействительными, снова запрашивает веб-службу Autodiscover и затем заново производит настройку почтового клиента для работы с новым почтовым ящиком. Для конечного пользователя весь этот процесс абсолютно незаметен.

Повторное изобретение календаря
Раньше большая часть логики календаря была размещена в диспетчере электронной почты Outlook. Каждое обновление собрания обрабатывалось как отдельное приглашение на собрание, что означало, что уведомления могли быть приняты не в нужном порядке. При отправке двух обновлений собрания непосредственно друг после друга получатель мог получить второе обновление раньше первого, а в его календарь могла попасть устаревшая информация. Более того, доступ к информации, хранящейся в Outlook, со смарт-телефонов или карманных компьютеров мог привести к отображению различных сведений о доступности в зависимости от используемого метода просмотра данных.
Решение состояло в переносе всей логики календаря из почтового клиента Outlook на сервер Exchange Server 2007. При получении сервером приглашения на собрание оно автоматически помещается в календарь с пометкой «под вопросом» до того момента, пока пользователь не отклонит или не примет его. При получении изменения данных о времени или месте собрания обновление собрания будет произведено автоматически и старое приглашение будет помечено как устаревшее, чтобы пользователи не могли принять его по ошибке. Эта логика поддерживается всеми почтовыми клиентами £ диспетчером электронной почты Office Outlook, веб-клиентом Outlook, клиентом Outlook Mobile, а также почтовыми клиентами сторонних разработчиков, чтобы у пользователя отображались только правильные, самые новые сведения о собраниях.
Наличие такого надежного календаря позволяет предложить новый набор инструментов, который поможет повысить продуктивность работы пользователей. Ранее организация собраний с несколькими занятыми работниками была непростой задачей. Пользователям приходилось искать свободное время для встречи вручную, просматривая расписания на будущее, чтобы найти время, подходящее для всех участников. Теперь помощник по планированию Outlook 2007, показанный на рис. 2, автоматически найдет время, наиболее удобное для всех. После ввода сведений о том, присутствие каких работников обязательно, а каких желательно, а также сведений о необходимых помещениях и ресурсах помощник по планированию выводит на экран представление, содержащее выделенные цветом дни, наиболее подходящие для организации собрания. После того как день выбран, аналогично выбирается время в течение этого дня.
Рис. 2 Помощник по планированию
Рис. 2 Помощник по планированию (Щелкните изображение, чтобы уменьшить его)
Рис. 2 Помощник по планированию
Рис. 2 Помощник по планированию (Щелкните изображение, чтобы увеличить его)
Для определения оптимального времени собрания помощник по планированию в первую очередь учитывает данные сотрудников, присутствие которых обязательно, далее £ сотрудников, присутствие которых желательно, и, наконец, данные о наличии помещений и ресурсов. Помощник по планированию облегчает также работу с такими сложными вопросами, как гибкий график работы и разница во времени между часовыми поясами. Пользователи могут устанавливать рабочее время сами, указывая время начала и окончания своего рабочего дня. Таким образом, люди, которые приезжают на работу не раньше 9 или 10 часов утра, могут установить начало своего рабочего дня на это время. При планировании встречи другими пользователями более раннее время, например 8 утра, предлагаться не будет. Если необходимо организовать встречу двух групп из различных часовых поясов £ одной из Лондона, другой из Лос-Анжелеса, £ то будет предложено время встречи, приходящееся на рабочее время обеих групп. Для лондонской стороны эта встреча состоится вечером, для жителей Лос-Анжелеса £ утром. Зато ни для одной из сторон это не будет два часа ночи.

Поиск иголки в стоге сена
В последние годы количество сообщений электронной почты, приходящих в папку «Входящие» среднего пользователя, увеличивается с пугающей скоростью. Когда-то обычный рабочий почтовый ящик мог содержать всего пару сотен сообщений, а сейчас некоторые сотрудники получают такое количество сообщений каждый день. В этой лавине сообщений похоронена масса информации, которая очень важна для успешной работы любой организации. Поиск информации в тот момент, когда она нужна, может представлять собой достаточно сложную задачу.
Возможности поиска в Office Outlook 2007 и Exchange Server 2007 значительно расширены по сравнению с предыдущими выпусками. Независимо от того, работает пользователь в режиме кэширования или в оперативном режиме, при поиске сообщения применяются одни и те же алгоритмы. В оперативном режиме запрос поиска отправляется на сервер Exchange, где и осуществляется поиск. Индексатор содержимого Exchange, быстродействие которого почти в 35 раз выше индексатора в Exchange Server 2003, обеспечивает быстрый поиск и извлечение сообщений. При работе в режиме кэширования диспетчер электронной почты Outlook использует мгновенный поиск на основе панели поиска Windows® 3.0, что объединяет подсистемы индексирования и снижает нагрузку на центральный процессор. Поиск текста может выполняться в теме сообщения, в теле сообщения, в полях адреса отправителя и получателя и даже во вложениях, как показано на рис. 3.
Рис. 3 Новые способы поиска необходимого сообщения электронной почты.
Рис. 3 Новые способы поиска необходимого сообщения электронной почты. (Щелкните изображение, чтобы уменьшить его)
Рис. 3 Новые способы поиска необходимого сообщения электронной почты.
Рис. 3 Новые способы поиска необходимого сообщения электронной почты. (Щелкните изображение, чтобы увеличить его)

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

Безопасность и защита
Сегодня организации сталкиваются с большим количеством угроз своей среде обмена сообщениями. Совместная работа Outlook и Exchange позволяет успешно противостоять этим угрозам. Нежелательная почта £ один из видов таких угроз, и в Office Outlook 2007 добавлена поддержка штемпелей электронной почты Outlook £ нового способа борьбы с нежелательными сообщениями. Outlook составляет вычислительную головоломку из исходящего сообщения и прикрепляет ответ на нее к сообщению. После этого Exchange проверяет результат. Если при решении единичных головоломок расчет занимает небольшое время ЦП, что типично для законной корреспонденции, то нагрузка на компьютер отправителя нежелательных сообщений при их массовой рассылке будет чрезвычайно высока. Поэтому вероятность того, что сообщение со штемпелем электронной почты Outlook является законным, намного выше, и диспетчер электронной почты Exchange учитывает это при проверке законности каждого сообщения электронной почты.
В дополнение к старым угрозам, таким как нежелательные сообщения, новые нормы в отношении режимов хранения информации меняют требования к системам пересылки сообщений. Такие законы, как Sarbanes-Oxley, HIPPA и Basel II, диктуют жесткие правила хранения и уничтожения записей. Для удовлетворения этих требований сервер Exchange и диспетчер электронной почты Outlook вводят управляемые папки. Настройка этих папок для сообщений определенного типа производится администратором. В диспетчере электронной почты Outlook конечный пользователь видит эти папки с описанием того, что должно в них храниться (см. рис. 6). Отправление сообщений в определенную папку может выполняться также автоматически, с помощью правил транспорта Exchange. После перемещения в управляемую папку сообщение использует политики данной папки в отношении архивирования, хранения и прекращения действия и автоматически будет обрабатываться способом, соответствующим политике организации.
Рис. 6 Управляемые папки обеспечивают выполнение установленных правил для электронных сообщений
Рис. 6 Управляемые папки обеспечивают выполнение установленных правил для электронных сообщений (Щелкните изображение, чтобы уменьшить его)
Рис. 6 Управляемые папки обеспечивают выполнение установленных правил для электронных сообщений
Рис. 6 Управляемые папки обеспечивают выполнение установленных правил для электронных сообщений (Щелкните изображение, чтобы увеличить его)
Несмотря на все усилия, иногда случаются нарушения установленных правил. В подобных случаях необходимо быстрое выявление нарушения и его устранение. Высокая скорость поиска сервера Exchange может стать для сотрудников, ответственных за соблюдение установленных правил, ключом к выявлению нарушений. В целях отслеживания и устранения подобных нарушений установленных правил операции поиска могут выполняться по всем почтовым ящикам.

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

Майкл Халили (Michael Khalili) в настоящее время работает менеджером по продукту Exchange Server, ответственным за сервер клиентского доступа и единую систему обмена сообщениями. Кроме прочего, он несет ответственность за интегрирование Outlook и Exchange.


 Exchange Server 2007: Exchange 2007 £ и вы всегда на связи
Exchange Server 2007 Джошуа Трупин (Joshua Trupin)

Exchange 2007 £ и вы всегда на связи
Краткий обзор:
  • Усовершенствования в веб-клиенте Outlook
  • Единая система обмена сообщениями в Exchange Server 2007
  • Обеспечение безопасности в ISA Server 2006

Раньше обмен информацией был прост. Сообщения посылались по электронной почте с помощью протоколов POP3 и SMTP. Довольно просто. Конечно, теперь требования изменились. Сегодня организациям нужно предоставить работникам
возможность работать когда и как им удобно, причем сделать это на должном уровне безопасности. Сервер Microsoft® Exchange Server 2007 обладает встроенными функциями, поддерживающими эти требования, такими как веб-клиент Microsoft Office Outlook® и единая система обмена сообщениями. Рассмотрим два этих ключевых компонента Exchange Server 2007 и то, в чем они превосходят предыдущие версии, позволяя создавать более мощные коммуникационные платформы для современного предприятия.
Веб-клиент Outlook входит в сервер Exchange, начиная с версии 5.5. Честно говоря, первые версии были несколько громоздкими. Веб-клиент Outlook являлся решением проблемы доступа к почтовому ящику Exchange посредством веб-обозревателя, но не обеспечивал всех функций Outlook.
Положение конечных пользователей начало улучшаться с усовершенствованием веб-клиента Outlook в версии сервера Exchange 2003. Работа с почтой через веб-обозреватель стала намного более естественной, почти такой, как при использовании обычного почтового клиента. Разработчики веб-клиента Outlook, применяющегося в Exchange Server 2007, пошли даже дальше и, полностью переписав код предыдущих версий, использовали последние технические новинки, такие как RPC через HTTP и ASP.NET 2.0.
Например, рассмотрим, как работает веб-клиент Outlook. Предыдущие версии веб-клиента Outlook работали на почтовом сервере параллельно с процессом хранения. Это создавало дополнительную нагрузку на сервер почтовых ящиков и могло приводить к снижению эффективности системы. А веб-клиент Outlook 2007 обрабатывает данные посредством ASP.NET на серверах клиентского доступа. Это позволяет убрать обработку страниц с почтового сервера и улучшить производительность.
Задачи, выполняемые сервером переднего плана, тоже изменились. В предыдущей версии Exchange HTTP-запросы веб-клиента Outlook перенаправлялись на соответствующий почтовый сервер. Exchange Server 2007 уменьшает поток данных веб-клиента Outlook, получая данные напрямую от соответствующего почтового сервера через RPC. Это примерно тот же способ, который позволяет использовать Outlook на клиентском компьютере, не подключенном через виртуальную частную сеть к сети предприятия. Затем информация из почтового ящика воспроизводится при помощи веб-клиента Outlook. Exchange Server 2007 также может переадресовывать запросы веб-клиента Outlook, но направляет их на серверы клиентского доступа, а не почтовые серверы.
На рис. 1 показана архитектура веб-клиента Outlook, применяемая в Exchange Server 2007.
Рис. 1 Доступ веб-клиента Outlook к ресурсам сервера Exchange
Рис. 1 Доступ веб-клиента Outlook к ресурсам сервера Exchange (Щелкните изображение, чтобы уменьшить его)
Рис. 1 Доступ веб-клиента Outlook к ресурсам сервера Exchange
Рис. 1 Доступ веб-клиента Outlook к ресурсам сервера Exchange (Щелкните изображение, чтобы увеличить его)

Администрирование
Обновленная архитектура сервера Exchange Server 2007 поддерживает расширенные возможности администрирования веб-клиента Outlook. Можно использовать как консоль управления Exchange, так и среду управления Exchange. Параметры конфигурации хранятся в нескольких местах.
Консоль управления Exchange предоставляет доступ к большинству параметров конфигурации, таких как включение и отключение функций, использующих сегментацию, блокировку вложений, проверку подлинности, а также доступ к календарю, списку задач и проверке орфографии. Все, что может быть сделано при помощи консоли управления Exchange, может также быть выполнено и с использованием среды управления Exchange.
В дополнение к этому, среда управления Exchange позволяет создавать и удалять новые виртуальные каталоги для веб-клиента Outlook. Помимо этого, можно получить улучшенный контроль над параметрами сегментации для отдельных пользователей и изменить язык, использующийся по умолчанию.
Интервалы проверки подлинности на основе форм хранятся по умолчанию в реестре Windows (эти параметры недоступны из консоли управления Exchange или среды управления Exchange). Такие параметры веб-клиента Outlook, как блокирование вложений и сегментация, доступны через службу каталогов Active Directory®. Параметры, влияющие на поведение сервера IIS (проверка подлинности, поддержка алгоритма GZIP), хранятся в метабазе IIS. Параметры ASP.NET, отвечающие за загрузку вложений для почтовых сообщений веб-клиента Outlook, такие как «maxuploadsize» (максимальный размер загрузки на сервер), хранятся в файле web.config.

Проверка подлинности
Веб-клиент Outlook предоставляет несколько способов проверки подлинности на сервере. После установки по умолчанию предлагается проверка подлинности на основе форм. При этом она может быть усилена несколькими способами в соответствии с требованиями предприятия. Чтобы убедиться в том, что подключающийся пользователь имеет соответствующие доменные права, IIS-сервер может производить проверку подлинности с помощью Active Directory. Также для доступа к сообщениям электронной почты можно использовать основную проверку подлинности, дайджест-проверку подлинности, технологию RSA SecurID или даже смарт-карты.
Наивысший уровень безопасности для веб-клиента Outlook – это встроенная проверка подлинности Windows, сочетающая протоколы Kerberos и NTLM. На самом деле встроенная проверка Windows требуется для доступа к веб-части веб-клиента Outlook 2007, а также для перенаправления запросов между серверами клиентского доступа в разных сайтах Active Directory. Она также дает дополнительное преимущество пользователям в интрасети, обращающимся к веб-клиенту Outlook, поддерживая единый вход при проверке подлинности клиента Windows, при этом доверенному пользователю входить в веб-клиент Outlook не нужно.
Если используется проверка подлинности на основе форм, то по умолчанию веб-клиент Outlook будет автоматически отключать пользователя после определенного периода бездействия. В зависимости от того, какой тип компьютера выбран пользователем при входе в систему (общедоступный или личный), период бездействия может быть от 15 минут (для общедоступного) до 8 часов (для личного). Выбор между общедоступным и личным компьютером важен для пользователя, поскольку в зависимости от этого и другие параметры безопасности также могут быть настроены по-разному. Можно, например, блокировать вложения для пользователей общедоступных компьютеров или изменить интервалы проверки подлинности. Проверка подлинности на основе форм обычно состоит из четырех этапов, как показано на рис. 2.
Рис. 2 Процесс проверки подлинности
  1. Клиент посылает незашифрованный запрос на сервер.
  2. Сервер посылает клиенту зашифрованный файл «cookie».
  3. Сервер продолжает отвергать и создавать новые ключи шифрования, сохраняя в памяти три последних ключа.
  4. Клиент, посылающий запрос с устаревшим ключом шифрования, еще находящимся в памяти, получает новый файл «cookie», зашифрованный новым ключом.
    £или£
    Клиент, посылающий запрос с устаревшим ключом шифрования, который был отклонен и время ожидания для которого истекло, должен войти в систему заново.

msExchQueryBaseDN – это механизм, используемый для ограничения прав определенных пользователей веб-клиента Outlook и позволяющий им видеть только часть записей адресной книги. Отметка msExchQueryBaseDN добавляется к объектам пользователей Active Directory и указывает на список адресов или подразделение. Этот список адресов будет использован в качестве глобального списка адресов пользователя, причем в этом глобальном списке адресов пользователю будут доступны только учетные записи пользователей данного подразделения. msExchQueryBaseDN может быть установлен посредством протокола LDAP.

Совместимость с предыдущими версиями
Ядром веб-клиента Outlook в сервере Exchange Server 2007 является сервер клиентского доступа, причем модель серверов клиентского доступа построена так, чтобы обеспечить наилучшую совместимость с серверами, использующими предыдущие версии Exchange. Для обеспечения такой работы необходимо всегда устанавливать или обновлять серверы клиентского доступа перед обновлением связанных с ними почтовых серверов.
Сервер Exchange 2007 с установленной ролью сервера клиентского доступа может использоваться для подключения к почтовым ящикам серверов Exchange 2000 и Exchange 2003. Службы по протоколам RPC через HTTP и Exchange ActiveSync® продолжат работу и при частичном обновлении серверов. Веб-клиент Outlook и протокол WebDAV также будут работать, если доступ к ним осуществляется посредством виртуальных каталогов /exchange, /public или /exchweb. При помощи Exchange Server 2007 можно также создавать пользовательские виртуальные каталоги веб-клиента Outlook для этих более ранних версий.

Преимущества ISA Server 2006
Веб-клиент Outlook в Exchange Server 2007 представляет собой значительный шаг вперед, но он может работать еще эффективнее, если будет использоваться совместно с сервером Internet Security and Acceleration (ISA) Server 2006.
Сервер ISA Server 2006 является интегрированным шлюзом обеспечения безопасности. Одновременно с защитой узла от угроз из Интернета он также обеспечивает безопасный удаленный доступ к приложениям и данным. Поскольку веб-клиент Outlook служит для той же цели, совмещение их возможностей дает наилучший результат. (Подробные сведения о сервере ISA Server см. на веб-странице microsoft.com/isaserver/2006 (на английском языке)).
Сервер ISA Server 2006 приносит существенную пользу занятому администратору сервера Exchange. Например, функция Web Publishing Load Balancing (WPLB, балансировка нагрузки для веб-публикаций) позволяет выравнивать нагрузку, используя файлы «cookie», применяемые для протокола HTTP. Она обеспечивает привязку клиента к серверу даже при смене клиентом IP-адреса. Также сервер ISA Server 2006 поддерживает сжатие и распаковку по алгоритму GZIP, что позволяет анализировать поток данных или снимать с веб-серверов нагрузку по сжатию. При использовании сервера ISA Server 2004 необходимо было делать выбор – использовать HTTP-сжатие в веб-клиенте Outlook или использовать проверку подлинности на основе форм на сервере ISA Server. Сервер ISA Server 2006 поддерживает данные функции одновременно.
Кроме того, сервер ISA Server может выполнять преобразование ссылок веб-клиента Outlook. Если кто-то в сообщениях электронной почты использует ссылки для интрасети, ISA-сервер может преобразовать их в точную веб-ссылку. Это может быть довольно полезным, однако нужно помнить, что в этом случае ссылки для интрасети должны публиковаться на том же массиве серверов ISA, который обеспечивает доступ через веб-клиент Outlook.
Пожалуй, даже более важно то, что сервер ISA Server 2006 производит предварительную проверку подлинности, помогая защитить периметр сети. Предварительная проверка подлинности предназначена для предотвращения попадания злонамеренного HTTP-трафика на серверы. Если трафик, направленный на сервер клиентского доступа, действительно допустим, сервер ISA пропустит его в домен с периметра сети. (Серверы на периметре сети расположены вне домена интрасети, блокируя трафик, который не должен попадать внутрь. Серверы клиентского доступа не должны быть установлены на периметре сети, они должны находиться в домене интрасети, чтобы иметь доступ к учетным записям службы каталогов Active Directory.)

Устранение неполадок веб-клиента Outlook
Новые средства веб-клиента Outlook 2007 позволяют улучшить наблюдение и устранение неполадок. Задача слежения запускается на сервере клиентского доступа автоматически. Она проверяет подключение к каждому почтовому серверу, а также вход пользователей в веб-клиент Outlook. Exchange Server 2007 также предоставляет намного более подробные записи журнала событий и показатели счетчиков производительности.
Усовершенствованный анализатор соответствия рекомендациям для Exchange Server (Exchange Server Best Practices Analyzer) (см. описание на веб-странице microsoft.com/technet/technetmag/issues/2006/01/TuneUpExchange, на английском языке) был усовершенствован таким образом, чтобы сообщать администраторам о соответствующих предупреждениях и ошибках в случае неправильной настройки веб-клиента Outlook. Можно также составлять отчеты по использованию веб-клиента Outlook на основе журналов сервера IIS при помощи инструмента LogParser (описан в октябрьском номере журнала, см. веб-страницу microsoft.com/technet/technetmag/issues/2006/10/LogParser (на английском языке)).

Единая система обмена сообщениями
Веб-клиент Outlook отвечает нуждам мобильного офиса, в то время как единая система обмена сообщениями предназначена для объединения сообщений различных форм в одном месте (отсюда и "умное" название). Сейчас сообщения электронной почты находятся на сервере Exchange. Голосовые сообщения (телефонные звонки и голосовая почта) доступны на сервере телефонии. Сообщения электронной почты приходят на компьютер, а голосовая почта – по телефону. А о факсах лучше вообще не говорить!
Единая система обмена сообщениями сервера Exchange Server 2007 позволяет свести сообщения электронной почты, голосовые сообщения и факсы в единую папку «Входящие», где все они будут доступны пользователям посредством почтовой службы Outlook и веб-клиента Outlook. Единая система обмена сообщениями идет также и в другом направлении – голосовая почта, сообщения электронной почты, контакты и календарь становятся доступными пользователям по телефону при помощи голосового доступа к Outlook.
Для системного администратора применение единой системы обмена сообщениями упрощает обмен сообщениями, позволяя совместить инфраструктуру сервера Exchange и телефонной сети, предоставляя единое решение для хранения данных, единый каталог и единый транспорт. Общий уровень сложности уменьшается, поскольку каждый человек обладает одним почтовым ящиком.
В чем же главное достоинство? Все это может быть сделано с использованием уже существующих серверов, и для тех, кто знаком с Exchange Server 2007 и телефонной связью, обучение будет весьма простым. Единая система обмена сообщениями интегрирована с сервером Exchange, то есть используется та же модель безопасности и те же папки «Входящие». Даже голосовая почта и факсы доступны через веб-клиент Outlook.
На рис. 3 показана архитектура единой системы обмена сообщениями сервера Exchange Server 2007, на котором установлена роль сервера единой системы обмена сообщениями. Внимательно посмотрите на рисунок (потом может быть экзамен), а затем рассмотрим архитектуру единой системы обмена сообщениями более подробно.
Рис. 3 Единая система обмена сообщениями объединяет голосовую почту, факсы и обмен сообщениями
Рис. 3 Единая система обмена сообщениями объединяет голосовую почту, факсы и обмен сообщениями (Щелкните изображение, чтобы уменьшить его)
Рис. 3 Единая система обмена сообщениями объединяет голосовую почту, факсы и обмен сообщениями
Рис. 3 Единая система обмена сообщениями объединяет голосовую почту, факсы и обмен сообщениями (Щелкните изображение, чтобы увеличить его)
При установке единой системы обмена сообщениями на предприятии необходимо обратить внимание на множество тонкостей. Сервер Exchange содержит объекты, соответствующие аппаратуре телефонии. Эти объекты могут иметь взаимные связи, заданные в среде сервера Exchange. Системные объекты единой системы обмена сообщениями сервера Exchange включают cервер единой системы обмена сообщениями, телефонную группу единой системы обмена сообщениями, шлюз IP единой системы обмена сообщениями и группу слежения единой системы обмена сообщениями, а также политику почтовых ящиков единой системы обмена сообщениями и автосекретарь единой системы обмена сообщениями. Взгляните, чем каждый объект оправдывает свое существование.
Объект UM Server создается в службе каталогов Active Directory, где установлена роль сервера единой системы обмена сообщениями. Он позволяет администратору управлять установкой и свойствами единой системы обмена сообщениями сервера Exchange Server 2007. Объект UM Dial Plan является основным модулем администрирования единой системы обмена сообщениями и отражает использование внутренних номеров. Все пользователи, внесенные в телефонную группу службы универсальной обработки сообщений, могут связаться с остальными, просто набрав их внутренний номер. При установлении связи между несколькими пунктами следует иметь в виду, что каждый из них обычно имеет собственную телефонную группу.
Объект «Шлюз IP единой системы обмена сообщениями» представляет собой физический шлюз, работающий по протоколу VoIP, или IP-PBX c поддержкой протокола SIP. Сервер единой системы обмена сообщениями может принимать вызовы со шлюзов IP/VoIP. Объект UM Hunt Group связывает объект IP Gateway с объектом UM Dial Plan. После того как на PBX настроена группа слежения, в службе каталогов Active Directory создается соответствующий ей объект "Группа слежения единой системы обмена сообщениями". Группу слежения можно настроить на обеспечение балансировки нагрузки между шлюзами IP. Данные шлюзы в свою очередь могут обеспечивать балансировку нагрузки путем сопоставления нескольких шлюзов c одним объектом "Группа слежения единой системы обмена сообщениями". Объекты UM Mailbox Policies аналогичны классам обслуживания Classes of Service голосовой почты. Они включают телефонную группу и свойства, устанавливающие действующие политики для пользователей и групп.
Объект UM Auto Attendant может быть сопоставлен одному объекту UM Dial Plan. Он может быть индивидуально настроен для выполнения нескольких задач, таких как запись пользовательского приветствия и назначение задач на конкретную дату и время. Область применения автосекретарей может устанавливаться с помощью списков адресов.
На рис. 4 показано, как взаимодействуют эти шесть объектов единой системы обмена сообщениями.
Рис. 4 Взаимодействие объектов телефонии единой системы обмена сообщениями
Рис. 4 Взаимодействие объектов телефонии единой системы обмена сообщениями (Щелкните изображение, чтобы уменьшить его)
Рис. 4 Взаимодействие объектов телефонии единой системы обмена сообщениями
Рис. 4 Взаимодействие объектов телефонии единой системы обмена сообщениями (Щелкните изображение, чтобы увеличить его)

Настройка
Имеющийся у пользователя почтовый ящик Exchange Server 2007 администратор должен подключить к единой системе обмена сообщениями. Чтобы это сделать, необходимо сопоставить почтовому ящику объект UM Mailbox Policy и внутренний номер в рамках телефонной группы. АТС также должна быть настроена на переадресацию вызова к единой системе обмена сообщениями в случае отсутствия ответа (состояние RNA – ring, no answer). Сначала телефонная станция направляет вызов на внутренний номер пользователя. При отсутствии ответа вызов перенаправляется на VoIP-шлюз, а оттуда £ на сервер единой системы обмена сообщениями.
Единая система обмена сообщениями поддерживает масштабирование. Для достижения требуемой емкости можно добавить любое количество коммутируемых телефонных линий и серверов единой системы обмена сообщениями. При использовании VoIP-шлюзов IP-вызовы будут направлены на серверы Exchange, поддерживающие единую систему обмена сообщениями. Поскольку такие функции для многих предприятий являются новыми, необходимо провести подробный анализ сети и убедиться, что она имеет пропускную способность, достаточную для данных и голоса.
Типовой сервер единой системы обмена сообщениями на основе сервера Exchange Server 2007 способен обслуживать от 50 до 200 одновременных IP-вызовов и до 200 входящих голосовых или факсимильных вызовов (по умолчанию это значение установлено равным 100). Если необходима емкость, превышающая данную, или нужно повысить отказоустойчивость, можно подключить дополнительные серверы единой системы обмена сообщениями.

Заключение
Подведем итоги. Сервер Exchange Server 2007 обеспечивает две возможности – веб-клиент Outlook и единую систему обмена сообщениями, которые при совместном использовании предоставляют организации огромные преимущества. Веб-клиент Outlook обеспечивает безопасный доступ к сообщениям электронной почты из любой точки, а единая система обмена сообщениями предоставляет пользователям доступ к электронной и голосовой почте, факсимильным сообщениям и прочим данным, которые могут поступать в один почтовый ящик на сервере Exchange 2007.

Джошуа Трупин (Joshua Trupin) – ответственный редактор журналов MSDN и TechNet. Он написал множество статей для журналов MSJ, MIND, MSDN и TechNet, а также книгу «Hoop Stats: The Basketball Abstract».


 Сервер Exchange Server 2007: Более мощные средства ведения журнала Exchange 2007
Сервер Exchange Server 2007 Дэвид Строум (David Strome)

Более мощные средства ведения журнала Exchange 2007
Краткий обзор:
  • Правила журналов сервера Exchange Server 2007.
  • Новый мастер журналов.
  • Зачем нужен отчет журнала?

Приходилось ли вам когда-нибудь вести журнал сообщений, отправленных одному конкретному пользователю и полученных от него, и в результате получать нужные сообщения вместе с сообщениями из остальных 300 почтовых ящиков,
расположенных в том же хранилище? Сервер Microsoft Exchange Server 2007 решает эту проблему, обеспечивая необходимую точность управления.
Возможность ведения журнала для каждого получателя, предоставляемая корпоративными клиентскими лицензиями (Client Access Licenses, CAL), позволяет указать пользователей, для которых ведется журнал. При помощи правил ведения журнала можно указать только тех получателей и отправителей, которых нужно регистрировать в журнале. Вы можете сосредоточить внимание на отдельном почтовом ящике или же расширить контролируемую область, например, включив всех сотрудников отдела продаж. При этом почтовые ящики сотрудников необязательно должны находиться на одном сервере, в пределах одного узла Active Directory® или даже в одной организации Exchange. При помощи репликации Active Directory изменения автоматически применяются на всех компьютерах, выполняющих роль транспортного сервера-концентратора в организации.

Как ведется журнал
В Exchange Server 2003 ведение журнала было реализовано для отдельных хранилищ почтовых ящиков на каждом физическом сервере. Если требовалось вести журнал для всех почтовых ящиков в организации, приходилось настраивать ведение журнала для каждого хранилища почтовых ящиков. А чтобы вести журнал сообщений для одного получателя, приходилось или вести журнал для всех сотрудников, использующих это хранилище почтовых ящиков, или создавать отдельное хранилище почтовых ящиков для этого пользователя.
При ведении журнала на сервере Exchange Server 2007 используется новая ролевая топология Exchange. Как показано на рис. 1, все сообщения обрабатываются транспортными серверами-концентраторами при передаче или приеме от серверов почтовых ящиков и серверов единой системы обмена сообщениями, других серверов Exchange, приложений сторонних разработчиков и из Интернета. На всех транспортных серверах-концентраторах имеется транспортный агент, называемый агентом ведения журнала, который применяет правила журнала к сообщениям. Поскольку агент ведения журнала работает на транспортных серверах-концентраторах, он получает и обрабатывает все сообщения до того, как они будут доставлены получателю. Агент ведения журнала обрабатывает сообщения после классификации, что обеспечивает доступ ко всем атрибутам получателя и отправителя сообщения и позволяет агенту определить, было ли сообщение отправлено непосредственно получателю или же оно было получено путем расширения группы рассылки. Агент также может определить, в какой из строк («Кому», «Копия» или «Скрытая копия») сообщения был указан адрес получателя сообщения, поступившего из организации сервера Exchange Server 2007.
Рис. 1 Передача почтовых сообщений транспортным сервером-концентратором
Рис. 1 Передача почтовых сообщений транспортным сервером-концентратором (Щелкните изображение, чтобы уменьшить его)
Рис. 1 Передача почтовых сообщений транспортным сервером-концентратором
Рис. 1 Передача почтовых сообщений транспортным сервером-концентратором (Щелкните изображение, чтобы увеличить его)
Агент ведения журнала применяет настроенные администратором правила журнала к сообщениям по мере прохождения сообщений через транспортный сервер-концентратор. Эти правила определяют, должен ли агент записывать сведения о сообщении и пересылать их вместе с исходным сообщением в почтовый ящик журнала. Эти данные отправляются в сообщении, называемом отчетом журнала.
В предыдущих версиях Exchange приходилось применять настройки на нескольких серверах. Теперь при создании правила журнала для сервера Exchange Server 2007 эти изменения применяются ко всем транспортным серверам-концентраторам в организации при помощи службы Active Directory. Все транспортные серверы-концентраторы, а значит, и все агенты ведения журнала, считывают одну и ту же конфигурацию из Active Directory. Следовательно, этот сплошной охват обеспечивает использование одинаковых настроек ведения журнала всеми агентами.
При создании или изменении правил журнала следует учитывать время репликации Active Directory, поскольку изменения конфигурации должны быть реплицированы во всей организации и прочитаны транспортными серверами-концентраторами. Это может занять несколько часов. Обнаружить обновление конфигурации ведения журнала помогает то, что сервер Exchange записывает событие в журнал событий безопасности на каждом сервере.
Сервер Exchange Server 2007 никогда не допускает потери отчета, если почтовый ящик журнала недоступен, заполнен, неправильно настроен или отключен. (Это в особенности полезно, если необходимо обеспечить соответствие различным законодательным и нормативным требованиям, так как потерянные сообщения могут привести к нарушению соответствия.) Если отчет журнала не может быть доставлен в почтовый ящик журнала, он остается в очереди транспортного сервера-концентратора, пока почтовый ящик журнала не станет доступен. Поскольку это может привести к быстрому росту очередей, для правильной работы журнала необходимо следить за доступностью почтового ящика журнала. Если почтовый ящик журнала будет недоступен в течение длительного времени, можно настроить дополнительный почтовый ящик для получения отчетов, находящихся в очереди.

Что включать в журнал
Перед тем как создавать правила журнала, необходимо четко представлять себе, каких пользователей следует включать в журнал и какие данные должны регистрироваться в журнале. Указывая пользователя в правиле журнала, можно вести журнал для определенных пользователей. Эти пользователи могут быть, например, объектом нормативных требований или они могут участвовать в процессуальной деятельности, ведение которой предусматривает сбор почтовых сообщений и другой корреспонденции в качестве доказательств.
Помимо указания пользователей для включения в журнал, можно также определить область охвата сообщений, регистрируемых в журнале, выбрав регистрацию внутренних, внешних или всех сообщений. Регистрация внутренних сообщений касается только сообщений, передаваемых внутри организации, при регистрации внешних сообщений обрабатываются сообщения, отправитель или получатель которых находятся вне организации, регистрация всех сообщений охватывает как внутренние, так и внешние сообщения. (Обратите внимание, что при общей регистрации в журнале фиксируются все сообщения, проходящие через транспортный сервер-концентратор, даже те, которые могли быть уже обработаны правилами для внутренних и внешних сообщений.)
Сервер Exchange Server 2007 поддерживает единую систему обмена сообщениями, поэтому можно настроить Exchange так, чтобы все почтовые сообщения, сообщения голосовой почты и факсимильные сообщения пользователя поступали в его папку «Входящие». Это также означает, что можно вести журнал для всех этих данных или же исключить определенные данные.
При использовании сервера Exchange Server 2007 со стандартными клиентскими лицензиями по-прежнему можно вести журналы отдельно для каждого хранилища почтовых ящиков. Для использования новых возможностей ведения журнала для отдельных пользователей необходимо выполнить обновление до корпоративных клиентских лицензий сервера Exchange Server 2007.

Где разместить почтовый ящик журнала
После определения того, что следует включить в журнал, необходимо выбрать место назначения для отправки отчетов журнала. При наличии нескольких узлов для принятия решения о месте размещения почтовых ящиков журналов следует учесть топологию существующей или планируемой сети. В зависимости от размеров организации и числа почтовых ящиков ведение журнала может привести к появлению большого количества повторных отчетов.
Впрочем, не обязательно ограничиваться почтовыми ящиками на сервере Exchange. Отчеты журналов могут быть отправлены по любому допустимому SMTP-адресу. Этот адрес может указывать на службы Exchange Hosted Services, средства архивации сторонних поставщиков или любое сочетание этих возможностей при использовании группы рассылки. Однако следует учитывать, что в отношении адреса получателя отчетов журнала действуют определенные условия, связанные с безопасностью.
Независимо от того, где будет размещен почтовый ящик журнала, необходимо создать для него объект получателя в Active Directory. Это может быть почтовый ящик сервера Exchange Server 2007, контакт, поддерживающий электронную почту и перенаправляющий почтовые сообщения службам Exchange Hosted Services или средству архивации стороннего поставщика, а также список рассылки, содержащий как почтовые ящики, так и контакты.

Зачем нужен отчет журнала?
Когда агент ведения журнала регистрирует сообщение в журнале, он пытается поместить в отчет максимально возможное количество сведений о сообщении. После этого отчет отправляется в почтовый ящик журнала. Эта информация очень важна для определения цели сообщения, его получателей и отправителей. Например, способ указания получателей (прямая адресация в поле «Кому», включение адреса в поле «Копия» или отправка сообщения по списку рассылки) может помочь определить степень участия получателя в обсуждении. Исходное сообщение добавляется в отчет как вложение. На снимках экрана на рис. 2 показан отчет журнала о сообщении, отправленном по адресу david@contoso.com и пересланном по адресу christine@contoso.com, и другой отчет журнала, указывающий, что для сообщения, отправленного по адресу Sales_Group@contoso.com, было выполнено расширение группы рассылки, и получатель lukas@contoso.com, входящий в группу рассылки отдела продаж, получил это сообщение. Оба отчета содержат исходное сообщение в виде вложения, а также сведения об исходном отправителе (brian@contoso.com) и теме сообщения («Прогноз продаж»).
Рис. 2 Отчеты журнала: переадресованное сообщение и расширенная группа рассылки
Рис. 2 Отчеты журнала: переадресованное сообщение и расширенная группа рассылки (Щелкните изображение, чтобы уменьшить его)
Рис. 2 Отчеты журнала: переадресованное сообщение и расширенная группа рассылки
Рис. 2 Отчеты журнала: переадресованное сообщение и расширенная группа рассылки (Щелкните изображение, чтобы увеличить его)
Сервер Exchange выполняет классификацию только той информации, достоверность которой известна. Сведения, которые не могут быть определены автоматически, помещаются в соответствующие поля отчета журнала. Рисунок 2 поясняет значения полей, включенных в тело отчета журнала.

Все о безопасности
По умолчанию весь обмен информацией между серверами Exchange Server 2007 в одной организации Exchange зашифрован. Отчеты журнала также шифруются. Сервер Exchange выполняет ряд операций для снижения опасности вскрытия отчетов журнала.
  • Между транспортными серверами-концентраторами и серверами почтовых ящиков в организации Exchange 2007 используются защищенные каналы связи.
  • Отчеты журнала отправляются в виде «Microsoft Exchange» от имени отправителя исходного сообщения.
  • В сеансах связи между транспортным сервером-концентратором и сервером почтовых ящиков используется проверка подлинности.
  • При отправке отчетов журнала от транспортного сервера-концентратора серверам почтовых ящиков в одной организации Exchange 2007 принимаются только подключения с проверкой подлинности.
При создании почтового ящика журналов необходимо защитить его, так как этот почтовый ящик содержит сообщения, отправленные сотрудниками организации и адресованные им. Некоторые сообщения могут быть частью процессуальной деятельности или на них может распространяться действие нормативных требований, а различные законодательные акты требуют сохранения сообщений без изменения до их передачи следственным органам. Для повышения безопасности почтового ящика журнала следует настроить для этого ящика прием только сообщений, отправителем которых является сервер Microsoft Exchange, также следует установить требование, чтобы в почтовый ящик журнала могли попасть только сообщения от отправителей, прошедших проверку подлинности. На рис. 3 показана настройка ограничений доставки сообщений для почтового ящика журнала. Для настройки этих ограничений доставки сообщений можно также использовать следующую команду среды управления Exchange:
Set-Mailbox <Journal Mailbox Name>
-AcceptMessagesOnlyFrom "Microsoft Exchange" -RequireSenderAuthenticationEnabled $True
Рис. 3 Ограничения доставки сообщений
Рис. 3 Ограничения доставки сообщений (Щелкните изображение, чтобы уменьшить его)
Рис. 3 Ограничения доставки сообщений
Рис. 3 Ограничения доставки сообщений (Щелкните изображение, чтобы увеличить его)
При отправке отчетов журнала в почтовый ящик журналов, расположенный за пределами организации Exchange Server 2007 необходимо вручную обеспечить шифрование и защиту подключения между серверами Exchange Server 2007 и сервером, принимающим сообщения. Это можно сделать, потребовав использования протокола TLS между двумя системами с обязательной проверкой подлинности принимающей стороной и разрешив прием только сообщений, отправленных с SMTP-адреса получателя Microsoft Exchange (этот SMTP-адрес будет примерно таким: Exchange_UMUnique GUID@contoso.com). Необходимо также настроить для контакта Active Directory, используемого для пересылки сообщений, прием сообщений только от получателя Microsoft Exchange.

Реализация правил журнала
Но хватит разговоров. Давайте создадим несколько правил. Правила журнала агента ведения журнала могут быть настроены либо в среде управления Exchange, либо в консоли управления Exchange. Оба эти средства могут быть использованы для настройки параметров получателя, области действия и почтового ящика журнала. По умолчанию правила журнала включаются при создании. Значение, указанное в качестве адреса электронной почты журнала, должно соответствовать существующему объекту получателя в организации Exchange Server 2007. Этот объект получателя может представлять собой почтовый ящик, группу рассылки, динамическую группу рассылки или контакт, отправляющий сообщение по SMTP-адресу.
При использовании консоли управления Exchange для создания новых правил журнала можно воспользоваться мастером создания правил журнала. В разделе «Конфигурация организации» выберите роль транспортного сервера-концентратора. Затем на панели действий выберите ссылку «Создать правило журнала». Здесь необходимо указать имя правила, адрес электронной почты журнала и область действия правила. Если правило журнала должно применяться для обработки сообщений для всех получателей организации, указывать получателя в поле «Получатель» не требуется. Также можно выбрать отключение правила журнала при создании. На рис. 4 показан пример конфигурации, при которой в журнале регистрируются все сообщения, отправленные по адресу brian@contoso.com. Сообщения, регистрируемые в журнале, отправляются в почтовый ящик журналов «Compliance mailbox».
Рис. 4 Мастер создания правил журнала
Рис. 4 Мастер создания правил журнала (Щелкните изображение, чтобы уменьшить его)
Рис. 4 Мастер создания правил журнала
Рис. 4 Мастер создания правил журнала (Щелкните изображение, чтобы увеличить его)
В среде управления Exchange для администрирования агента ведения журнала можно использовать шесть командлетов.
  • New-JournalRule
  • Set-JournalRule
  • Get-JournalRule
  • Remove-JournalRule
  • Enable-JournalRule
  • Disable-JournalRule
Командлет New-JournalRule позволяет создать правило журнала. Основные требования при создании правила журнала этим способом такие же, как и при использовании мастера. Необходимо указать параметры Name, Scope и JournalEmailAddress. Опять же, не нужно указывать значение параметра Recipient, если правило журнала должно использоваться для регистрации в журнале сообщений всем получателям организации. Если при создании правило должно быть отключено, необходимо указать значение $False для параметра Enabled. Для создания правила с той же конфигурацией, которая показана на рис. 4 используйте следующую команду.
New-JournalRule
-Name "Brian Smith Journal Rule"
-Recipient brian@contoso.com
-JournalEmailAddress "Compliance Mailbox"
-Scope Global
Командлет Get-JournalRule используется для просмотра списка всех созданных правил журнала. При запуске этого командлета без параметров отображается общий список всех правил журнала, настроенных в организации, и параметров их конфигурации. Для просмотра полной информации о правиле журнала можно передать вывод командлета Get-JournalRule командлету Format-List. При этом вывод одного командлета передается для дополнительной обработки следующему командлету. Например, командлет Format-List отображает все полученные данные. Для просмотра полной информации о ранее созданном правиле журнала можно воспользоваться следующей командой.
Get-JournalRule -Identity "Brian Smith Journal Rule" | Format-List
Чтобы включить или отключить правило журнала, следует использовать командлеты Enable-JournalRule и Disable-JournalRule. При использовании этих командлетов необходимо указывать имя правила журнала в параметре Identity. Например, для отключения только что созданного правила журнала можно использовать следующую команду.
Disable-JournalRule -Identity "Brian Smith Journal Rule"
Командлет Set-JournalRule позволяет изменить существующее правило журнала. Чтобы указать агенту ведения журнала правило, которое требуется изменить, используется параметр Identity с именем правила журнала. Затем необходимо задать в любой комбинации параметры Recipient, JournalEmailAddress и Scope и новые значения параметров. Например, чтобы изменить для созданного правила значение параметра JournalEmailAddress, используйте следующую команду.
Set-JournalRule -Identity "Brian Smith Journal Rule" -JournalEmailAddress "Seattle Users Compliance Mailbox"
И наконец, командлет Remove-JournalRule позволяет удалить существующее правило журнала. Для указания имени правила журнала используется параметр Identity. Чтобы удалить наше примерное правило журнала, выполните следующую команду.
Remove-JournalRule "Brian Smith Journal Rule"
При этом среда управления Exchange выдаст запрос подтверждения удаления правила журнала. И последний совет: почти во всех командлетах можно не использовать метку параметра Identity, а просто указать значение этого параметра.

Дэвид Строум (David Strome) более года работает техническим писателем в группе обучения пользователей Exchange в корпорации Майкрософт. Перед тем как перейти в корпорацию Майкрософт в Редмонде, штат Вашингтон, Дэвид примерно 10 лет разрабатывал, реализовывал и администрировал установки сервера Exchange в различных компаниях в Британской Колумбии (Канада). Связаться с Дэвидом можно по адресу dstrome@microsoft.com.


 Exchange Server 2007: Защита от нежелательной почты и фишинга с помощью кода отправителя
Exchange Server 2007 Крейг Шпицле (Craig Spiezle) and Александр Николаев (Alexander Nikolayev)

Защита от нежелательной почты и фишинга с помощью кода отправителя
Краткий обзор:
  • Код отправителя. Общие сведения.
  • Настройка кода отправителя в Exchange Server.
  • Преимущества проверки подлинности.

В ответ на растущую угрозу получения нежелательных сообщений производится разработка множества технологий идентификации и фильтрации. Для обеспечения эффективности своей работы они полагаются на процедуру получения ответа на такие вопросы о каждом сообщении электронной почты, как
вопрос о том, кто является его отправителем. Однако на подобный вопрос ответить непросто. Сообщения электронной почты обычно отправляются через Интернет без какой-либо проверки подлинности отправителя или компьютера, действующего от его лица. На самом деле отправить электронное сообщение под чужим именем довольно просто, а автоматического метода определения поддельных сообщений просто не существует.
Протокол SMTP, который используется для отправки и получения электронных сообщений, никогда не был предназначен для проверки подлинности отправителя сообщения. Подобная технологическая недоработка позволяет указать любое имя и адрес в качестве данных отправителя. В результате для обеспечения соответствия фактического отправителя заявленному меры фильтрации содержимого и защиты от нежелательных сообщений не могут полагаться только на сведения, содержащиеся в заголовке сообщения.
Компенсировать эту технологическую брешь призваны, в частности, меры проверки подлинности сообщений. При использовании проверки подлинности сообщений обе системы обмены сообщениями £ и отправляющая, и получающая £ проверяют соответствие домена, откуда они были фактически отправлены, заявленному в них домену отправки. Это облегчает эффективную фильтрацию отправляемых в адрес организации нежелательных сообщений, при этом обеспечивая доставку законных сообщений адресатам.
В настоящий момент существуют два общедоступных для использования подхода к проверке подлинности электронных сообщений: «Sender ID Framework, SIDF» (система кода отправителя) и «DomainKeys Identified Mail, DKIM» (идентификация почты ключом домена). SIDF является решением, построенным на основе протокола IP и получившимся в результате объединения «Sender Policy Framework, SPF» (система политик отправителя) и «Microsoft Caller ID for E-Mail» (идентификатор отправителя электронной почты, разработанный корпорацией Майкрософт). В апреле 2006 года IETF опубликовала спецификации кода отправителя £ RFC 4405-4408. Объединение промышленных и коммерческих организаций, включая и корпорацию Майкрософт, основываясь на факторах, включающих в себя коммерческую и производственную ценность, стабильность, степень разработки, легкость развертывания, минимальное влияние на производительность обработки входящего и исходящего потоков электронных сообщений, а также способность взаимодействия с экосистемой среды электронных сообщений организаций и поставщиков услуг Интернета, рекомендует развертывание системы SIDF.
Подход DKIM является объединением спецификаций «Yahoo! DomainKeys» (доменных ключей Yahoo!) и «Identified Internet Mail, IIM» (идентификация Интернет-почты) корпорации Cisco Systems Inc. В январе 2006 года IETF одобрила создание рабочей группы по DKIM, и в настоящий момент данная спецификация находится в процессе рассмотрения в IETF.
Несмотря на отсутствие идеального решения по борьбе с нежелательными сообщениями, SIDF представляет собой весомую инициативу отрасли в целом по борьбе с фальсифицированными доменами. В результате данная организация стала ключевым компонентом в снижении объема нежелательной почты и сетевых атак с целью перехвата учетных данных (фишинга), а также увеличения степени доверия работы в сети. Организации во всем мире присоединяются к инициативе SIDF быстрыми темпами. Сегодня уже более 5,5 миллионов различных компаний и владельцев доменов опубликовали записи SPF и более чем 600 миллионов пользователей защищены системой SIDF. В настоящий момент более трети мирового ежедневного объема электронных сообщений проходит проверку подлинности и соответствует требованиям SIDF.
Развитие и всемирное использование SIDF было бы невозможным без вклада и поддержки множества организаций и компаний, включая AOL, Authentication and Online Trust Alliance (AOTA), Bell Canada, E-Mail Senders Provider Coalition (ESPC), CipherTrust, Cisco Systems, IronPort Systems, MarkMonitor, Port25 Solutions Inc, Sendmail, Symantec, TRUSTe, VeriSign, а также многих других.

Код отправителя. Общие сведения
Некоторые из проведенных в индустрии исследований показывают, что более 95 процентов сообщений для перехвата учетных данных пользователя отправляются из фальсифицированных доменов и имеют фальсифицированного отправителя или адрес электронной почты. Это является именно той проблемой, где SIDF выделяется своим методом обработки сообщений для защиты от нежданной почты. Сама по себе система SIDF не решит проблему нежелательных сообщений, однако она вносит значительный вклад в минимизацию последствий таких сообщений и фишинг-атак. Система SIDF не предотвращает отправку нежелательных сообщений. Однако она облегчает их обнаружение. Система помогает отправителям электронных сообщений защитить свои доменные имена, репутацию и торговые марки. Она предоставляет обширную базу для принятия решений при использовании фильтров на основе репутации и образа действий отправителя при отправке электронных сообщений.
Код отправителя производит попытку удостовериться в том, каждое электронное сообщение в действительности пришло с того адреса, который заявлен в сообщении в качестве адреса отправки. Это производится с помощью проверки адреса сервера, отправляющего электронную почту, по зарегистрированному списку серверов, которым владелец домена разрешил отправлять электронную почту. Проверка производится автоматически поставщиком услуг Интернета или почтовым сервером получателя, до того как сообщение попадает в папку "Входящие" пользователя.
Обратите внимание, что ни одна из систем £ ни код отправителя, ни иные механизмы проверки подлинности £ не заменяют собой системы фильтрации содержимого. Механизмы SIDF и DKIM не производят сканирования действительного содержания сообщения. Вместо этого проверка извещает почтовую систему входящих сообщений о том, может ли сообщение считаться отправленным от того отправителя, который в нем заявлен. Поскольку большинство нежелательных сообщений и сообщений для перехвата учетных данных пользователя действительно отправляются не из тех доменов, которые указываются, данный подход может быть полезным для автоматического определения этих сообщений и их отделения в потоке входящей почты.
При использовании механизма SIDF запись SPF содержит простую текстовую запись всех серверов исходящей почты с указанием домена и соответствующих IP-адресов. Организация публикует запись SPF в свой файл зон DNS-сервера, который затем проверяется почтовым сервером получателя. Настроить запись SPF можно быстро, без особых усилий и бесплатно. Средство «Sender ID Framework SPF Record Wizard» (мастер записи SPF системы кода отправителя) содержит пошаговые инструкции по наблюдению за почтовыми серверами домена и созданию специальных записей, готовых к отправке. (Подробные сведения о публикации записи SPF доступны по адресу: microsoft.com/senderid (на английском языке). Программа находится по адресу microsoft.com/senderid/wizard.)
Сервер входящих сообщений SMTP запрашивает наличие записи SPF у файла зон в DNS, расположенного в домене. При наличии записи производится проверка IP-адреса отправляющего сервера по списку IP-адресов. В случае обнаружения сообщение считается прошедшим проверку подлинности. С другой стороны, в случае если сведения записи SPF о домене отправителя не совпадают с IP-адресом отправления, то сообщение считается не прошедшим проверку подлинности, что приводит к назначению ему отрицательной оценки и вероятности его перемещения в папку нежелательных сообщений. На рис. 1 показан пример данного процесса.
Рис. 1 Проверка записей SPF для входящих сообщений
Рис. 1 Проверка записей SPF для входящих сообщений (Щелкните изображение, чтобы уменьшить его)
Рис. 1 Проверка записей SPF для входящих сообщений
Рис. 1 Проверка записей SPF для входящих сообщений (Щелкните изображение, чтобы увеличить его)
После того, как сообщение помечено, механизм SIDF разрешает почтовому серверу получателя провести анализ сообщения на основе предыдущего поведения и репутации отправителя, содержимого сообщения и иных критериев, которые могут устанавливаться по мере необходимости. Подобная возможность предоставляет дополнительные меры защиты. Например, отправители нежелательных сообщений для того, чтобы обмануть пользователя и заставить сеть считать себя законным отправителем, могут зарегистрировать похожие домены и опубликовать записи SPF. Даже в том случае, если сообщение может пройти проверку подлинности, репутации отправителя как отправителя нежелательных сообщений достаточно для того, чтобы сообщение было блокировано, помещено в папку нежелательных сообщений или удалено.

Возможности развертывания кода отправителя
Проверка подлинности исходящих сообщений с помощью SIDF не требует каких-либо изменений инфраструктуры, обновлений программного обеспечения и не зависит от ПО клиента и сервера. Однако организациям, которым необходимо внедрить проверку подлинности входящих сообщений для защиты компании и сотрудников, потребуется обновить системы входящих сообщений и средства «Агент передачи сообщений» (MTA) и осуществить развертывание программного обеспечения или устройств, которые поддерживают механизм SIDF. Большинство ведущих поставщиков ПО для борьбы с нежелательной почтой, а также поставщиков коммерческих и бесплатных MTA, включая Microsoft® Exchange Server и Exchange Hosted Filtering, предлагают интегрированные решения.
Корпорация Майкрософт внедрила SIDF во все свои продукты для обмена сообщениями, включая Microsoft Exchange Server 2003 Service Pack 2 (SP2), Exchange Server 2007, Microsoft Exchange Hosted Filtering, Microsoft Windows Live™ Mail, MSN® Hotmail®, Outlook® Express, а также почтовый клиент с возможностью совместной работы Office Outlook.
Однако даже корпорация Майкрософт получает нежелательную почту и не является исключением среди остальных получателей нежелательных сообщений. Ежедневно корпорация Майкрософт получает примерно 15 миллионов сообщений, а в течение недавних спам-атак мы наблюдали объем сообщений от двух до четырех раз больше. В подобной среде путь к успешной защите от нежелательной почты заключается в постоянном применении и внедрении доступных технологий.
Корпорация Майкрософт использует внутреннее решение Exchange Server для защиты от нежелательной корреспонденции на основе фильтра кода получателя приложения Exchange Server 2003 и агент кода отправителя приложения Exchange Server 2007. В обеих версиях приложения Exchange Server состояние кода отправителя основано на оценке записи кода отправителя, расположенной на соответствующих серверах DNS. Действительный домен отправки определяется с помощью анализа заголовков сообщения RFC 2822 в следующей последовательности:
  1. Resent-Sender
  2. Resent-From
  3. Sender
  4. From
Домен отправителя (или наиболее поздний объект, произведший отправку сообщения в поток почты, поскольку почтовые системы могут законно пересылать сообщения от имени почтовых серверов) определяется путем поиска в указанной последовательности первого определения ранее упомянутых заголовков. Если ни один из этих заголовков не найден, то механизм SIDF использует значение SMTP RFC 2821 MAIL FROM.

Настройка кода отправителя
В Exchange Server 2007 включение агента кода отправителя возможно на тех серверах, где установлена роль «пограничный транспортный сервер». Если агент кода отправителя включен, то он будет фильтровать сообщения, поступающие через соединители приема и обрабатывать весь входящий (из внешних источников) поток сообщений, которые не прошли проверку подлинности. В Exchange Server 2003 состояние кода отправителя сохраняется в пути между серверами в метке EXCH50, в Exchange Server 2007 это состояние также добавлено к метаданным сообщения. В конечном назначении метаданные сообщения и метка преобразуются в свойство MAPI для будущего использования клиентом.
Настройки фильтрации кода отправителя в Exchange Server 2003 производится в меню "Message Delivery Properties" и состоит в назначении способа обработки приложением Exchange Server сообщений, не прошедших проверку подлинности.
Для того чтобы включить код отправителя в Exchange Server 2007 достаточно открыть панель Exchange Management Console (Панель управления Exchange) сервера, для которого установлена роль «пограничный транспортный сервер», перейти на вкладку «Anti-spam», далее перейти к пункту «Sender ID» (Код отправителя) и в панели «Actions» (Действия) нажать кнопку «Enable» (Включить) или «Disable» (Выключить) агента кода отправителя, как показано на рис. 2. Кроме того, для включения или отключения кода отправителя можно использовать среду управления Exchange, как показано на рис. 3.
Рис. 2 Exchange Management Console. Управление агентом кода отправителя в Exchange Server 2007
Рис. 2 Exchange Management Console. Управление агентом кода отправителя в Exchange Server 2007 (Щелкните изображение, чтобы уменьшить его)
Рис. 2 Exchange Management Console. Управление агентом кода отправителя в Exchange Server 2007
Рис. 2 Exchange Management Console. Управление агентом кода отправителя в Exchange Server 2007 (Щелкните изображение, чтобы увеличить его)
Рис. 3 Включение кода отправителя с помощью среды управления Exchange
Рис. 3 Включение кода отправителя с помощью среды управления Exchange (Щелкните изображение, чтобы уменьшить его)
Рис. 3 Включение кода отправителя с помощью среды управления Exchange
Рис. 3 Включение кода отправителя с помощью среды управления Exchange (Щелкните изображение, чтобы увеличить его)
Состояние агента (включен или выключен) указывается в диалоговом окне «Sender ID Properties» (Свойства кода отправителя). На вкладке "Действие" содержатся параметры, подобные тем, что имеются в Exchange Server 2003 (см.рис. 4).
Рис. 4 Свойства действий агента кода отправителя в Exhange Server 2007
Рис. 4 Свойства действий агента кода отправителя в Exhange Server 2007 (Щелкните изображение, чтобы уменьшить его)
Рис. 4 Свойства действий агента кода отправителя в Exhange Server 2007
Рис. 4 Свойства действий агента кода отправителя в Exhange Server 2007 (Щелкните изображение, чтобы увеличить его)
В отношении внедрения и функций кода отправителя между серверами Exchange Server 2003 и Exchange Server 2007 больших различий нет, фильтр кода отправителя (в Exchange Server 2003) и агент кода отправителя (в Exchange Server 2007) для извлечения и проверки используют одинаковый базовый алгоритм. Диапазон возможных действий также одинаков: «Удалить сообщение» (без извещения пользователя), «Отклонить сообщение» (ответ протокола SMTP уровня 500) и «Поставить метку с результатом проверки кода отправителя и продолжить обработку». Последнее действие является принятым по умолчанию в обеих версиях Exchange Server.
В Exchange Server 2007 оба кода состояния FAIL и TempError могут вызвать действие «Отклонить сообщение» (в Exchange Server 2003 это действие может быть вызвано только кодом состояния FAIL). Поскольку сообщения с кодом состояния TempError по умолчанию принимаются системой, отмечаются результатом проверки кода отправителя и обрабатываются, то для вызова действия «Отклонить сообщение» необходимо настроить агент кода сообщения явным образом.
Возможность такой настройки не предоставляется в графическом интерфейсе, поэтому для настройки действий для кода состояния TempError необходимо использовать среду управления Exchange. Например, для принудительной настройки агента кода сообщения на действие «Отклонить сообщение» для сообщений с кодом состояния TempError запустите следующий командлет агента кода отправителя:
Set-SenderIDConfig -TempErrorAction Reject
Диапазон результатов состояния кода отправителя и возможных действий в Exchange Server 2007 и фильтра кода отправителя в Exchange Server 2003 одинаков и показан на рис. 5.
Figure 5 Состояние и действия кода отправителя в Exchange Server 2007 (Close Figure 5)

Состояние кода отправителя | Описание | Действия
Нейтральное | Опубликованные данные кода отправителя явно недостаточны | StampStatus
Pass | IP-адрес входит в разрешенный набор | StampStatus
Fail | IP-адрес входит в неразрешенный набор | StampStatus, Delete или Reject
SoftFail | Возможно, IP-адрес входит в неразрешенный набор | StampStatus
None | Опубликованных данных нет | StampStatus
TempError | Временная ошибка, например отсутствующий сервер DNS | StampStatus или Reject
PermError | Неустранимая ошибка, например ошибка формата записи | StampStatus
Сервер Exchange (в случае соответствующей настройки) будет производить удаление только тех сообщений, которые не прошли проверку подлинности с помощью кода отправителя. Получение других результатов не будет приводить к удалению сообщений. Входящие сообщения, проверка которых привела к результатам Neutral, None, SoftFail, TempError или PermError, будут помечаться соответствующими метками и передаваться для дальнейшей проверки на законность. В некоторых случаях, когда сообщение безнадежно испорчено и в нем отсутствует адрес FROM IP, оно не может иметь отметку состояния кода отправителя. В подобной ситуации не производится его отклонение. Вместо этого оно передается для дальнейшей обработки без отметки состояния кода отправителя, однако для уведомления это событие заносится в журнал.
Exchange Server 2007 позволяет с легкостью определять домены отправителей и получателей Exchange Server, для которых не требуется проводить проверку кода отправителя. Данная возможность настройки также доступна только с помощью среды управления Exchange. Например, чтобы исключить домен contoso.com из списка фильтра кода получателя, следует выполнить следующую команду:
Set-SenderIDConfig -BypassedSenderDomains contoso.com
Таким же образом, чтобы отменить фильтрацию по коду отправителя для сообщений, отправленных указанным получателям Exchange Server, можно использовать следующую команду:
Set-SenderIDConfig -BypassedRecipients user@contoso.com
В Exchange Server 2007 значения настроек кода отправителя, заданные с помощью командлетов среды управления Exchange и недоступные в графическом интерфейсе, могут быть выведены на экран с помощью команды Get-SenderIDConfig, выполненной в среде управления Exchange, как показано на рис. 6.
Рис. 6 Командлеты настроек кода отправителя
Рис. 6 Командлеты настроек кода отправителя (Щелкните изображение, чтобы уменьшить его)
Рис. 6 Командлеты настроек кода отправителя
Рис. 6 Командлеты настроек кода отправителя (Щелкните изображение, чтобы увеличить его)
Среду управлениям Exchange можно использовать, чтобы выполнить быструю проверку IP-адреса и соответствующего имени домена вручную. Чтобы выполнить проверку состояния кода отправителя, введите следующую команду:
Test-SenderID -IPAddress <IPAddress>-PurportedResponsibleDomain <SMTPDomain>
Если домен не существует, то на экран выводится результат, как показано на рис. 7.
Рис. 7 Состояние проверки элемента "Адрес" кода отправителя
Рис. 7 Состояние проверки элемента "Адрес" кода отправителя (Щелкните изображение, чтобы уменьшить его)
Рис. 7 Состояние проверки элемента "Адрес" кода отправителя
Рис. 7 Состояние проверки элемента "Адрес" кода отправителя (Щелкните изображение, чтобы увеличить его)

Преимущества использования кода отправителя
Помимо очевидных преимуществ при проверке подлинности электронных сообщений и снижения количества получаемой пользователями нежелательной почты, SIDF как протокол предлагает иные преимущества. Во время его разработки корпорация Майкрософт ориентировалась на несколько ключевых моментов, включающих в себя производительность, цену, развертывание, масштабируемость и возможность взаимодействия.
Механизм SIDF производит проверку подлинности отправителя сообщения, после чего позволяет применить оценку репутации отправителя. В результате этого достигается возможность уменьшения объема нежелательных и фальсифицированных сообщений, а также улучшается пропускная способность для законных сообщений от известных и доверенных отправителей. Создание записи SPF производится бесплатно, поэтому это легко может сделать любая организация, которая пожелает соответствовать требованиям SIDF. Организации, которые хотят соответствовать требованиям нового стандарта, должны иметь для этого соответствующие возможности. Обеспечить соответствие требованиям SIDF так же легко, как произвести публикацию записи SPF.
При разработке стандарта SIDF учитывалось требование максимальной совместимости с существующим программным обеспечением. Он может использоваться с множеством архитектур обмена электронными сообщениями, а также широким спектром клиентского и серверного программного обеспечения. Для того чтобы обеспечить эффективную работу, любая служба проверки подлинности должна удовлетворять потребностям крупного поставщика услуг Интернета так же легко, как и потребностям малого домашнего почтового сервера. SIDF может поддерживать от одного до тысяч почтовых серверов; к этому следует добавить тех, кто предоставляют свои почтовые серверы для других организаций.
С 18 по 19 апреля 2007 года корпорация Майкрософт и отраслевой консорциум из 30 организаций и партнеров проводят встречу «Authentication & Online Identity Summit» в г. Бостон, штат Массачусетс. Двухдневная программа встречи предполагает обзор практических случаев применения и обсуждение технической стороны механизма кода отправителя с подробным описанием коммерческой ценности проверки подлинности сообщений. Для получения дополнительных сведений см. веб-узел aotalliance.org/summit2007. Кроме того, для получения дополнительных сведений, включая сведения о средствах и ресурсах, см. microsoft.com/senderid и microsoft.com/exchange (на английском языке).

Крейг Шпицле (Craig Spiezle) в настоящее время является директором отдела Technology Strategy and Planning for Windows Live Safety в корпорации Майкрософт. Работая в качестве менеджера по продуктам проверки подлинности электронных сообщений, Крейг активно способствовал внедрению кода отправителя в данной отрасли. Начав работу в корпорации Майкрософт в 1992 году, Крейг занимал несколько управленческих должностей, включая должности в отделе международного маркетинга, отделе стратегий поддержки продуктов, отделе работы с с изготовителями оборудования, а также в отделе освоения новых рынков.
Александр Николаев (Alexander Nikolayev) работает менеджером программ в корпорации Майкрософт и является ответственным за протоколы серверной стороны, компонент «Transport Core» (ядро транспортировки), а также компоненты серверов Exchange Server и Windows Server для борьбы с нежелательной почтой. Александр имеет диплом магистра бизнеса, выданный университетом Мэри (University of Mary). Прочесть сообщения Александра можно в блоге группы Exchange по адресу: blogs.technet.com/exchange.


 От редактора: Наши достижения
От редактора
Наши достижения

ЖУРНАЛ «TECHNET MAGAZINE » £ ЭТО НЕЧТО БОЛЬШЕЕ, чем то удивительное печатное издание, которое вы держите в руках сегодня. Наш коллектив проделал огромную работу, чтобы создать новый современный веб-узел, благодаря которому с журналом смогут познакомиться более миллиарда человек во всем мире. Начиная с ноябрьского выпуска, каждая статья будет появляться в Интернете на семи языках: английском, испанском, французском, немецком, русском, китайском (упрощенное письмо) и бразильском португальском. Введение шести дополнительных языков (как вы знаете, английская версия нашего журнала уже доступна в Интернете) позволит увеличить аудиторию журнала, которая сможет читать его на своем родном языке, более чем на 1,6 миллиарда человек. Это невероятно! (В данной статье имеются ссылки на страницы на английском языке.)
И, как будто этого было мало, мы добавили целый ряд возможностей, чтобы сделать узел журнала более удобным. Новые настраиваемые RSS-каналы позволяют выбрать содержимое по дате, колонке, автору или теме. Можно даже выбрать нужное сочетание. Посетите веб-узел technetmagazine.com/rss, чтобы приступить к созданию каналов по своим предпочтениям уже сегодня.
Кроме того, мы представляем новые тематические страницы. Чтобы прочитать о том, что необходимо предпринять профессионалам в области информационных технологий для подготовки к переходу на Windows Vista, достаточно открыть страницу technetmagazine.com/vista. Администраторы электронной почты, без сомнения, должны посетить узел technetmagazine.com/exchange. У нас уже есть 32 разные темы по адресу technetmagazine.com/topics, и их число растет. (Например, в ноябре число предлагаемых вниманию читателей статей по безопасности достигло 43.)
И это еще не все. Теперь вы можете внимательнее присмотреться к журналу и погрузиться в мир профессионалов в области информационных технологий. Джошуа Хоффман (Joshua Hoffman), технический редактор и рецензент журнала TechNet, ведет Интернет-дневник журнала по адресу blogs.technet.com/tnmag. Кроме того, каждый месяц я размещаю на узле журнала звукозапись, которую можно найти по адресу www.technetmagazine.com/podcasts. В каждом выпуске я буду беседовать с авторами статей, чтобы, читая между строк, понять, как и почему эти статьи были написаны. Вам будет интересно услышать, как наши лучшие авторы рассказывают о своих статьях и о своей работе.
Мы собираемся сделать все возможное для того, чтобы журнал TechNet Magazine стал самым полезным в мире ресурсом для профессионалов в области информационных технологий. Мы хорошо поработали в 2006 году, но все же нам хотелось бы знать, что еще мы можем сделать для своих читателей. Присылайте нам свои комментарии! Адрес нашей редакции: tnmag@microsoft.com. Мы всегда открыты для предложений.
£ДЖОШУА ТРУПИН (JOSHUA TRUPIN)

Мы хотели бы поблагодарить следующих технических специалистов корпорации Майкрософт: Кевин Эллисон (Kevin Allison), Джессика Арнолд (Jessica Arnold), Себастьян Бенгочеа (Sebastian Bengochea), Нэвин Чанд (Naveen Chand), Ли Чен (Li Chen), Алпа Дейв (Alpa Dave), Джил Фрэнк (Jill Frank), Михай Джалобеану (Mihai Jalobeanu), Дарси Джейн (Darcy Jayne), Хэрри Кац (Harry Katz), Керри Лэнден (Kerry Landen), Тодд Луттинен (Todd Luttinen), Бретт Муззи (Brett Muzzey), Брюс Пэйетт (Bruce Payette), Тони Смит (Tony Smith), Шон Томас (Shawn Thomas), Джим Труэр (Jim Truher) и Скот Видикен (Scot Vidican).


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

Тестирование с нагрузкой для веб-приложений
Инструмент тестирования с нагрузкой для веб-приложений WAPT
www.loadtestingtool.com (на английском языке)
Для выбора правильного масштаба инфраструктуры, а также во избежание ситуаций, когда начальство интересуется, почему при попытке открыть сайт появляется сообщение «Сервер перегружен», необходимо знать, как будет работать последнее издание веб-приложения. И если вы ищите относительно недорогой и простой в использовании инструмент тестирования с нагрузкой для веб-приложений, рекомендую попробовать средство WAPT 4.0, разработанное в компании SoftLogica LLC.
Приложение работает практически со всеми версиями Windows®, однако чтобы полностью раскрыть его потенциал, лучше воспользоваться версиями Windows 2000, Windows XP или Windows Server® 2003, поскольку в более ранних версиях имеется ограничение на число сокетов. Как и в большинстве приложений для тестирования производительности, в которых используются виртуальные «пользователи», чем больше объем памяти, чем быстрее процессор и чем выше скорость сетевого подключения, тем больше виртуальных пользователей можно сымитировать с помощью WAPT.
Для версии PIV 2.4 при объеме ОЗУ 512МБ и гигабитном Ethernet-интерфейсе в документации определено ограничение в 2000 пользователей, однако это зависит от типа тестируемого приложения и настройки тестовой учетной записи. Еще один параметр, влияющий на тестирование £ это задержка между запросами. Приложение WAPT позволяет устанавливать время реакции виртуального пользователя в его учетной записи.
Когда учетная запись виртуального пользователя будет настроена по одному из множества сценариев тестирования, можно приступить к созданию плана теста для этой учетной записи. Приложение WAPT разделяет проведение теста на три последовательных этапа: начальный, основной и завершающий. Этапы являются скорее логическими, чем функциональными, но они позволяют разделить функции, например, входа и регистрации на начальном этапе и выхода £ на завершающем. Приложение WAPT позволяет вводить запросы вручную либо использовать встроенное средство записи обозревателя, чтобы указать способ просмотра сайта пользователями этой учетной записи. Далее можно перейти к общим настройкам и указать нагрузку для теста, а также определить, будет ли нагрузка фиксированной на протяжении обозначенного периода времени или будет изменяться. Во время тестирования приложение WAPT отображает в реальном времени статистику производительности по выбранному сценарию. По окончании теста результаты можно сохранить в файле HTML или CSV для последующего просмотра.
Цена: 350 долларов США для одного компьютера.
Для выбора правильного масштаба инфраструктуры, а также во избежание ситуаций, когда начальство интересуется, почему при попытке открыть сайт появляется сообщение «Сервер перегружен», необходимо знать, как будет работать последнее издание веб-приложения. И если вы ищите относительно недорогой и простой в использовании инструмент тестирования с нагрузкой для веб-приложений, рекомендую попробовать средство WAPT 4.0, разработанное в компании SoftLogica LLC.
Приложение работает практически со всеми версиями Windows®, однако чтобы полностью раскрыть его потенциал, лучше воспользоваться версиями Windows 2000, Windows XP или Windows Server® 2003, поскольку в более раннихстарых версиях имеется ограничение на число сокетов. Как и в большинстве приложений для тестирования производительности, в которых используются виртуальные пользователи, чем больше объем памяти, чем быстрее процессор и чем выше скорость сетевого подключения, тем больше виртуальных пользователей можно сымитировать с помощью WAPT.
Инструмент тестирования с нагрузкой для веб-приложений WAPT
Инструмент тестирования с нагрузкой для веб-приложений WAPT (Щелкните изображение, чтобы уменьшить его)
Инструмент тестирования с нагрузкой для веб-приложений WAPT
Инструмент тестирования с нагрузкой для веб-приложений WAPT (Щелкните изображение, чтобы увеличить его)
Для версии PIV 2.4 при объеме ОЗУ 512МБ и гигабитном Ethernet-интерфейсе в документации определено ограничение в 2000 пользователей, однако это зависит от типа тестируемого приложения и настройки тестовой учетной записи. Еще один параметр, влияющий на тестирование £ это задержка между запросами. Приложение WAPT позволяет устанавливать время реакции виртуального пользователя в его учетной записи.
Когда учетная запись виртуального пользователя будет настроена по одному из множества сценариев тестирования, можно приступить к созданию плана теста для этой учетной записи. Приложение WAPT разделяет проведение теста на три последовательных этапа: начальный, основной и завершающий. Этапы являются скорее логическими, чем функциональными, но они позволяют разделить функции, например входа и регистрации на начальном этапе и выхода £ на завершающем. Приложение WAPT позволяет вводить запросы вручную либо использовать встроенное средство записи обозревателя, чтобы указать способ просмотра сайта пользователями этой учетной записи. Далее можно перейти к общим настройкам и указать нагрузку для теста, а также определить, будет ли она фиксированной на протяжении обозначенного периода времени или будет изменяться. Во время тестирования приложение WAPT отображает в реальном времени статистику производительности по выбранному сценарию. По окончании теста результаты можно сохранить в файле HTML или CSV для последующего просмотра.
Цена: 350 долларов США для одного компьютера.

Обзор книги
Content Networking Fundamentals
www.ciscopress.com (на английском языке)
В наше время информационное содержимое стоит во главе угла, и книга Content Networking Fundamentals («Основы распространения в сети», Cisco Press, 2006, на английском языке), написанная Сильвано да-Рос (Silvano Da Ros), поможет быстро освоить способы улучшения инфраструктуры предоставления содержимого. Автор книги преподносит ее как «всестороннее введение в теорию и практику распространения содержимого в сети» и она оправдывает такую характеристику. Несмотря на то, что книга нацелена на сектор сетей Cisco, в ней хорошо раскрыты различные компонентыя распространения содержимого в сети и даны практические советы по применению принципов, не зависящих от типов продуктов для распространения содержимого в сети, используемых в вашей инфраструктуре.
В начале книги можно найти подробный обзор различных элементов распространения содержимого в сети, что действительно позволяет улучшить производительность и связи на четвертом, пятом, шестом и седьмом уровнях модели OSI. Затем автор углубляется в специфику основных форматов предоставления информации £ XML, HTML, WAP £ и его преобразования с помощью XSLT на периферийных сетевых устройствах. В книге рассказывается также о предоставлении потоковой мультимедийной информации. В завершающей части книги речь идет о масштабируемости и доступности, а также обсуждаются вопросы балансирования нагрузки на серверы (как глобальные, так и локальные) и брандмауэры, использование устройств кэширования информации, например, коммутаторов информационных служб Cisco.
Пользователям, в инфраструктуре которых используются такие коммутаторы Cisco, будет интересно прочесть главу о коммутации защищенной информации. В ней представлены подробности настройки модулей информационных служб для уровня защищенных сокетов, а также настройки URL-адресов и перезапись заголовков. Специалистам по сетевым технологиям, независимо от систем, с которыми они работают, для понимания механизмов работы очередей и способов устранения перегрузки будет полезна информация о качестве предоставляемых услуг.
В заключение можно сказать, что, хотя книга и перегружена описанием применения аппаратных средств Cisco (в конце концов, она издана Cisco Press), она поможет превратить маловразумительные слова «распространение содержимого в сети» в практически применимые методы для вашей инфраструктуры доставки содержимого.
Цена: 55,00 долларов США.

Мониторинг служб
WebWatchBot
www.exclamationsoft.com/webwatchbot/default.asp (на английском языке)
Специалиста по информационным технологиям характеризует способность находить (и исправлять) неполадки раньше, чем с ними столкнется конечный пользователь. Поэтому одним из наиболее важных средств для такого специалиста является эффективная система мониторинга, которая может глубоко анализировать различные службы с целью проверки нормального их функционирования. Средство WebWatchBot, разработанное компанией ExclamationSoft, может помочь в решении этой проблемы.
Это приложение способно контролировать любую стандартную службу, которую вы только сможете себе представить. Приложение WebWatchBot не просто проверяет, работает ли служба, а контролирует правильность ее работы. Например, система проверки FTP может действительно отправлять и загружать файлы, служба мониторинга DNS может выполнять запросы 40 разных типов с поиском определенной строки в полученном ответе, а тесты протоколов POP3 и SMTP выполняют подключение и создают отчеты по работе электронной почты.
WebWatchBot
WebWatchBot (Щелкните изображение, чтобы уменьшить его)
WebWatchBot
WebWatchBot (Щелкните изображение, чтобы увеличить его)
Кроме того, приложение WebWatchBot позволяет выстроить последовательность действий в транзакции и создать отчет о любых ошибках или недопустимом времени ожидания (относительно установленного порогового значения) для транзакции в целом. Приложение будет также вести мониторинг переходов на URL-адреса по протоколам HTTP и HTTPS и может проверять наличие определенного содержимого. Пользователь даже сможет настраивать средства мониторинга баз данных, которые будут выполнять запросы и проверять данные по шаблону ответа.
Цена: 495,95 долларов США за одну лицензию.

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


 Оболочка Windows PowerShell: Простые команды. Мощные возможности администрирования
Оболочка Windows PowerShell
Простые команды. Мощные возможности администрирования
Дон Джонс (Don Jones)
Данная статья основывается на предварительной версии Windows PowerShell. Любая информация, содержащаяся в статье, может быть изменена.

Разработка заняла немало времени, но оболочка Windows PowerShell почти готова к выпуску. Это означает, что для администраторов Windows пришло время с ней познакомиться.. Оболочка Windows PowerShell предоставляет, вероятно, самый простой и наиболее гибкий способ автоматизации широкого спектра административных задач, делая работу более эффективной и результативной.
Кроме того, что еще более важно, корпорация Майкрософт встраивает в оболочку Windows PowerShell™ графические консоли администрирования таких продуктов, как Exchange Server 2007 и System Center 2007. Это означает, что с помощью Windows PowerShell можно будет выполнить почти любую административную задачу. Корпорация Майкрософт планирует со временем включить в состав оболочки возможности администрирования большего числа продуктов. Таким образом, в итоге оболочка Windows PowerShell может стать первым универсальным инструментом для администрирования почти любым серверным продуктом корпорации Майкрософт. Чтобы помочь вам ознакомиться с оболочкой Windows PowerShell, я буду регулярно обсуждать ее в этой новой колонке. Копию оболочки можно загрузить по следующему адресу (на английском языке).

Мощность и простота
Как можно понять из названия, Windows PowerShell £ это оболочка, похожая на существующую со времен Windows NT® 3.1 командную строку (Cmd.exe). Оболочка Cmd.exe не сходит со сцены, но с появлением Windows PowerShell останется все меньше причин продолжать ею пользоваться.
Работа с Windows PowerShell не особо отличается от работы с Cmd.exe £ если, конечно, не считать того, что у Windows PowerShell больше возможностей. Как и Cmd.exe, оболочка Windows PowerShell имеет встроенный язык сценариев. Правда, намного более гибкий, чем примитивный пакетный язык Cmd.exe. Насколько гибкий? Оболочка Windows PowerShell позволяет автоматизировать чрезвычайно сложные задачи с помощью языка, включающего в себя немногим более полдюжины встроенных ключевых слов.
Раз уж я упомянул сценарии, необходимо коснуться и вопросов безопасности. Оболочка Windows PowerShell впитала в себя все, что корпорация Майкрософт узнала о безопасности за последние десять лет. По умолчанию оболочка Windows PowerShell не позволяет запускать сценарии, ее можно использовать только интерактивно для выполнения отдельных команд. Если запуск сценариев все же разрешен, можно настроить Windows PowerShell на выполнение только подписанных сценариев. Все эти меры позволяют гарантировать, что Windows PowerShell не станет вторым VBScript (это замечательный язык, которым часто злоупотребляли для создания вредоносных сценариев). Язык VBScript тоже еще не уходит со сцены, но вы, вероятно, обнаружите, что для решения множества различных задач удобнее использовать Windows PowerShell.
С помощью Windows PowerShell можно делать практически все, что раньше делалось с помощью Cmd.exe. Например, можно выполнить команду ipconfig и получить тот же самый знакомый вывод. Но оболочка Windows PowerShell представляет целый новый набор команд, которые не являются внешними исполняемыми файлами. Эти командлеты («cmdlet» произносится как «команд-лет») встроены прямо в Windows PowerShell. (Несколько наиболее полезных командлетов, которые помогут начать работу с Windows PowerShell, можно найти на боковой панели «Десять самых важных командлетов, готовых к работе».)
Десять самых важных командлетов, готовых к работе
  • Get-Command возвращает список всех имеющихся командлетов.
  • Get-Help отображает справочную информацию о командлетах и общие сведения.
  • Get-WMIObject возвращает сведения об управлении с помощью WMI.
  • Get-EventLog возвращает журналы событий Windows.
  • Get-Process возвращает отдельный активный процесс или список активных процессов.
  • Get-Service возвращает одну из служб Windows.
  • Get-Content считывает содержимое текстового файла, обрабатывая каждую строку как дочерний объект.
  • Add-Content добавляет содержимое в конец текстового файла.
  • Copy-Item копирует файлы, папки и другие объекты.
  • Get-Acl возвращает списки управления доступом (ACL).
Полный список командлетов, входящих в состав Windows PowerShell, можно найти на веб-узле windowssdk.msdn.microsoft.com/en-us/library/ms714408.aspx (на английском языке).
Названия всех командлетов соответствуют стандартному формату «глагол-существительное», благодаря чему их легче понять и запомнить. Например, в результате запуска командлета Get-Command будет выведен список всех имеющихся командлетов. Вероятно, наиболее полезным для администратора является командлет Get-WMIObject. Предположим, требуется выяснить, какой пакет обновления установлен на компьютере Server2. Достаточно просто выполнить команду
Get-WMIObject Win32_OperatingSystem –Property ServicePackMajorVersion
 –Computer Server2
Чтобы получить те же сведения с помощью VBScript, необходимо написать несколько строк кода. Другие командлеты позволяют работать со службами (Start-Service, Stop-Service и т. д.), процессами (Stop-Process и другие), файлами (например Rename-Item, Copy-Item, Remove-Item, Move-Item) и так далее. У многих из этих командлетов есть сокращенные имена, также называемые псевдонимами. Например, вместо Get-WMIObject достаточно ввести просто gwmi. Получить список этих сокращенных имен можно с помощью команды Get-Alias.

Что дает ориентация на объекты
Поскольку оболочка Windows PowerShell встроена в Microsoft® .NET Framework, она является полностью объектно-ориентированной. Обычно это интересует только разработчиков программного обеспечения, но в данном случае ориентация на объекты приводит к значительному сокращению временных затрат для администраторов. Это происходит потому, что администраторы теперь могут напрямую работать с мощными объектами прямо из текстовой оболочки. Рассмотрим следующий пример.
Get-Process | Sort-Object pm –desc | Select-Object –first 10
Это всего лишь одна строка с тремя различными командлетами, разделенными знаками вертикальной черты (подробнее об этом будет рассказано в статье ниже). За счет выполнения первого командлета будут получены все запущенные процессы, которые затем передаются командлету Sort-Object. Этот второй командлет сортирует все процессы в порядке убывания по свойству pm (Physical Memory, физическая память) каждого объекта процесса. Затем отсортированный набор объектов процессов передается командлету Select-Object, который извлекает и отображает первые десять из них. Что мы получаем в результате? С помощью одной строки отображаются 10 процессов, занимающих больше всего физической памяти компьютера, как показано на рис. 1. Это чрезвычайно эффективный способ выполнить быструю проверку в ходе диагностики.
Рис. 1 Диагностика с помощью одного командлета
Рис. 1 Диагностика с помощью одного командлета (Щелкните изображение, чтобы уменьшить его)
Рис. 1 Диагностика с помощью одного командлета
Рис. 1 Диагностика с помощью одного командлета (Щелкните изображение, чтобы увеличить его)
Использование знака вертикальной черты (этот символ на клавиатуре США обычно расположен на клавише обратной косой черты) £ это важная часть того набора функций, который делает оболочку Windows PowerShell такой полезной. С помощью символа вертикальной черты можно передавать объекты от одного командлета к другому, что позволяет каждой следующей команде уточнять результаты, форматировать их для вывода и т. д. Этот механизм работает, поскольку каждый командлет возвращает не текст, а один или несколько объектов, с которыми могут работать следующие командлеты.
Использование объектов в Windows PowerShell полностью распространяется на переменные. Нет необходимости описывать переменные заранее. Чтобы начать использовать их, нужно просто добавить знак доллара ($) перед именем переменной. Хотя это и необязательно, можно также указать оболочке Windows PowerShell тип данных, которые будут храниться в переменной. Это позволит оболочке сопоставить переменную с одним из чрезвычайно мощных типов .NET Framework, предоставив администратору множество дополнительных встроенных возможностей. Предположим, вам требуется вывести запрос имени компьютера и получить версию пакета обновления, установленного на этом компьютере. Однако вы не знаете, укажет ли пользователь при вводе имени две обратные косые черты (например, \\Сервер2). Поскольку известно, что командлету Get-WMIObject обратные косые черты не требуются, можно сохранить имя компьютера в строковой переменной и воспользоваться методом Replace, чтобы заменить обратные косые черты на пустые строки, как показано ниже.
[string]$c = Read-Host "Enter computer name"
$c = $c.Replace("\","")
    Get-WMIObject Win32_OperatingSystem
    –Property  ServicePackMajorVersion
    –Computer $c
Значение параметра -Computer было передано с помощью переменной $c. Эта переменная была изначально создана как строковая и поэтому обладала всеми возможностями типа String платформы .NET Framework, включая метод Replace. Конечно, изучение всех этих особенностей займет некоторое время, но, возможно, будет проще познакомиться с ними на примерах. Сама оболочка Windows PowerShell помогает упростить обучение. Например, если ввести выражение $c = $c. (не забыв про точку) и нажать клавишу Tab, оболочка Windows PowerShell отобразит Clone(), первый метод типа String. Если продолжать нажимать клавишу Tab, будут последовательно отображаться все доступные методы. В сущности, при этом оболочка Windows PowerShell показывает, что именно ей известно о способах использования типа String!
Теперь более сложная задача: чтение списка имен компьютеров из файла, по одному имени в строке, и отображение номера версии пакета обновления для каждого компьютера. Для решения такой задачи с помощью VBScript потребовалось бы написать десяток или более строк кода. В cmd.exe пришлось бы воспользоваться сложным пакетным файлом. В Windows PowerShell эта задача решается с помощью всего одной строки.
Get-Content "c:\computers.txt" | foreach
{ $_; gwmi Win32_OperatingSystem -prop
ServicePackMajorVersion -comp $_ }
Командлет Get-Content считывает содержимое файла C:\Computers.txt. Каждая строка файла превращается в самостоятельный объект. Этот набор объектов £ то есть, имен компьютеров £ передается команде foreach, которая в действительности представляет собой псевдоним командлета ForEach-Object. Команды внутри фигурных скобок повторяются один раз для каждого полученного объекта (в нашем примере £ для каждого имени компьютера). Особая переменная $_ содержит текущий объект (а именно, текущее имя компьютера).
На самом деле внутри фигурных скобок находятся две команды. Первая из них просто отображает текущее имя компьютера, выводя содержимое переменной $_. Вторая £ уже знакомая нам команда gwmi. Результат представляет собой список номеров версий пакетов обновления для всех компьютеров, перечисленных в файле. И все это было выполнено с помощью одной относительно простой строки команд.
Обратите внимание, что для имен параметров -Property и -Computer использовались сокращения. Для Windows PowerShell достаточно, чтобы сокращения позволяли однозначно определить имена параметров.

Удобочитаемость и повторное использование
Размещение команд и параметров в одной строке не способствует повышению удобочитаемости. К счастью, Windows PowerShell позволяет использовать более удобный вариант, который можно вводить прямо в оболочке, не создавая сценария. Вот как это могло бы выглядеть:
PS C:\> $names = get-content "c:\computers.txt"
PS C:\> foreach ($name in $names) {
>> $name
>> gwmi Win32_OperatingSystem -prop ServicePackMajorVersion -comp $name
>> }
>>
На этот раз содержимое файла сохраняется в переменной $names. В этом примере все еще используется команда «foreach», но она не входит в состав конвейера, и поэтому ей нужно указать, какой набор объектов должен быть циклически обработан и в какой переменной следует хранить каждый объект. Это сделано с помощью фрагмента ($name in $names). Все остальное практически не изменилось, и нажатие клавиши ВВОД приведет к выполнению кода и отображению результатов.
Если тот же самый код необходимо использовать несколько раз, можно просто оформить его как функцию. В этот раз введите следующий фрагмент кода прямо в оболочке:
PS C:\> function Get-ServicePacks ($file) {
>> $names = get-content $file
>> foreach ($name in $names) {
>> $name
>> gwmi win32_operatingsystem -prop servicepackmajorversion -comp $name
>> }
>> }
>>
Как видите, на самом деле почти ничего не изменилось. Предыдущий пример просто был оформлен как функция с именем «Get-ServicePacks». (При этом сохраняется соглашение Windows PowerShell о формате имен «глагол-существительное».) 101% Technet_Review rusloc1 11/15/2006 10:35:35 AM The function now has an input parameter named $file, which has been substituted in the Get-Content cmdlet so that a different file can be specified when the function is run. Different match in memory: Эта функция имеет входной параметр с именем $file, который подставляется в cmdlet-команду Get-Content, что позволяет указать другой файл при запуске данной функции. The function now has an input parameter named $file, which has been substituted in the Get-Content cmdlet so that a different file can be specified when the function is run. Эта функция имеет входной параметр с именем $file, который подставляется в командлет Get-Content, что позволяет указать другой файл при запуске данной функции. Теперь, когда функция определена, для ее запуска достаточно указать ее имя, почти как для командлета, и передать ей входной параметр.
PS C:\> Get-ServicePacks c:\computers.txt
Результаты показаны на рис. 2.
Недостаток такого способа заключается в том, что функция будет существовать только до тех пор, пока запущен данный экземпляр Windows PowerShell. После закрытия оболочки функция исчезнет. Впрочем, функцию можно скопировать в свой профиль Windows PowerShell. Он представляет собой разновидность сценария автозапуска, который выполняется каждый раз при запуске Windows PowerShell. При этом функция будет доступна в каждом открытом вами окне Windows PowerShell. Кроме того, функцию можно оформить как отдельный сценарий. Тогда для ее запуска достаточно будет ввести путь и имя файла этого сценария.
Рис. 2 Результаты работы функции Get-ServicePacks
Рис. 2 Результаты работы функции Get-ServicePacks

Мир как файл (или папка)
Все же оболочка Windows PowerShell £ это нечто большее, чем просто функции и командлеты. Рассмотрим в качестве простого примера управление файлами. Вы, вероятно, хорошо знакомы с переходами по дискам и папкам в сmd.exe. Необходимо ввести C:, чтобы переключиться на диск C, и cd \test, чтобы перейти в папку C:\Test. Оболочка Windows PowerShell работает точно так же, хотя cd £ это на самом деле псевдоним для командлета Set-Location.
Попробуйте запустить командлет Get-PSDrive, который отображает список всех имеющихся дисков. Кроме обычных дисков C:, D: и, возможно, A:, в списке обнаружатся диски с именами Cert, Env, HKCU и HKLM. Оболочка Windows PowerShell действительно показывает много разных типов ресурсов хранения как «диски». Это позволяет получить доступ к локальному хранилищу сертификатов, переменным среды и реестру с помощью знакомого интерфейса переходов, такого же, как для файлов.
Чтобы перейти к кусту реестра HKEY_LOCAL_MACHINE, достаточно ввести Set-Location HKLM: (или cd hklm:, если вам больше нравятся сокращенные имена) и нажать клавишу ВВОД. Затем выполнить команду cd software\microsoft для перехода к разделу SOFTWARE\Microsoft. Можно воспользоваться командой dir (это псевдоним для командлета Get-ChildItem), чтобы получить список подразделов этого раздела реестра. Если требуется удалить раздел, воспользуйтесь командой del, как если бы этот раздел был файлом или папкой. (Впрочем, будьте осторожны. Удаление нужных разделов или некорректное изменение реестра может вызвать серьезные проблемы.)
Подобная гибкость становится возможной благодаря разработчикам продуктов, которые приводят ресурсы (такие как реестр и хранилище сертификатов) к формату, похожему на формат файловой системы. Корпорация Майкрософт планирует расширить оболочку Windows PowerShell для работы с дополнительными продуктами, обеспечивая возможность переходов, например, в хранилище сервера Exchange Server, как если бы это была файловая система. Описанная выше методика очень важна, поскольку она позволяет работать с огромным множеством хранилищ, используемых системой Windows, причем все они выглядят одинаково. Кроме того, всеми этими хранилищами можно управлять с помощью системы команд и методов, с которыми вы уже знакомы.

Безопасность прежде всего
Как уже упоминалось выше, оболочка Windows PowerShell была разработана с учетом безопасности и надежности. Основной компонент безопасности оболочки Windows PowerShell £ это ее политика выполнения. По умолчанию для этой политики задано значение Restricted. В этом можно убедиться с помощью командлета Get-ExecutionPolicy. В режиме Restricted сценарии не выполняются. Точка. Поскольку это режим по умолчанию, оболочку Windows PowerShell нельзя использовать для запуска готовых сценариев.
Задать другие режимы можно с помощью командлета Set-ExecutionPolicy. Мне, например, больше всего нравится режим RemoteSigned. В этом режиме допускается запуск локальных (но не удаленных) сценариев, не имеющих цифровой подписи, что обеспечивает самый простой способ разработки и тестирования сценариев. Режим AllSigned не разрешает запуск сценариев, если они не подписаны с помощью сертификата, выпущенного доверенным издателем. И, наконец, в режиме Unrestricted можно запускать все что угодно. Я рекомендую никогда не включать этот режим, поскольку он позволяет использовать Windows PowerShell для запуска вредоносных сценариев, которые могут каким-либо образом оказаться на компьютере. Обратите внимание, что политику выполнения можно также задать с помощью групповой политики, которая перекрывает локальные параметры. (Если параметр групповой политики перекрывает локальные параметры, команда «Set-ExecutionPolicy» выведет предупреждающее сообщение.)
Кроме того, в оболочке Windows PowerShell нельзя выполнить сценарии из текущего каталога. Необходимо указать путь. Это было сделано для того чтобы предотвратить подмену команд. Предположим, некто создает сценарий с именем IPConfig.ps1 (PS1£ это расширение имени файла для сценариев Windows PowerShell). Если бы файлы можно было запускать из текущей папки, то существовал бы риск, что ввод команды ipconfig приведет к запуску сценария, созданного этим «некто», хотя на самом деле вы хотели выполнить программу Windows Ipconfig.exe. Однако, поскольку оболочка Windows PowerShell не поддерживает запуск сценариев из текущей папки, такая ошибка исключается. Если действительно требуется запустить сценарий из текущей папки, нужно просто указать путь, например .\myscript. Явная ссылка на текущую папку позволяет подтвердить, что требуется запустить именно сценарий, а не команду оболочки.
Кроме того, оболочка Windows PowerShell обладает возможностями, которые позволяют сделать эксперименты более безопасными. Например, рассмотрим (только не надо пробовать) такое пугающее сочетание:
Get-Process | Stop-Process
Командлет Get-Process создает набор объектов процессов и передает их командлету Stop-Process, который действительно остановит их! В результате мы получим синий экран с ошибкой STOP примерно через пять секунд после остановки критических процессов Windows. Однако можно просто посмотреть, что должно произойти, не выполняя команд. Для этого достаточно добавить очень простой параметр -Whatif.
Get-process | Stop-Process -Whatif
Запуск такой команды в Windows PowerShell выдаст целый ряд отчетов о том, к чему бы привело исполнение командлетов без их фактического выполнения. Параметр – Whatif еще не описан во встроенной справочной системе Windows PowerShell (к которой можно получить доступ с помощью псевдонима help), но постарайтесь его не забывать. Это отличный инструмент для тестирования сценариев и командлетов. Он позволяет проверить результаты их выполнения и в то же время избежать риска сделать что-нибудь потенциально вредное или опасное.

Заключение
Среди возможностей, которые не вошли в данную версию Windows PowerShell, возможно самая важная £ это поддержка интерфейса служб каталогов Active Directory®Services Interface (ADSI). (ADSI). Хотя оболочка Windows PowerShell может использовать очень сложные классы .NET для работы со службой каталогов Active Directory и другими службами каталогов, простой командлет Get-ADSIObject пока отсутствует. В результате работа с объектами каталогов немного затруднена.
Кроме того, оболочка Windows PowerShell часто предоставляет несколько разных способов решения одной и той же задачи. В общем, это хорошо, но процесс изучения Windows PowerShell становится более запутанным, поскольку для любой данной задачи можно найти полдесятка разных примеров ее решения.
Все это со временем будет приведено в порядок, и группа разработчиков Windows PowerShell продолжит добавлять к этому продукту новые компоненты и возможности. Чтобы быть в курсе событий, посетите блог группы разработчиков (на английском языке).

Дон Джонс (Don Jones) £ основатель веб-узла ScriptingAnswers.com (на английском языке) и один из авторов книги «Оболочка Windows PowerShell: TFM» («Windows PowerShell: TFM», издательство «SAPIEN Press», 2006 г.). С Доном можно связаться по адресу: don@scriptinganswers.com.


 Анализ реализованных проектов: Миграция с Exchange 5.5
Анализ реализованных проектов
Миграция с Exchange 5.5
Уитни Робертс (Whitney Roberts)

ПРОЕКТ
Департаменту образования штата Кентукки необходимо было осуществить миграцию с работающего сервера Microsoft® Exchange Server 5.5 на Exchange Server 2003. Данная система в течение учебного года обслуживала примерно 600 000 человек – преподавателей, сотрудников и учащихся.
УЧАСТНИКИ ПРОЕКТА
Проект осуществлялся управлением технических средств обучения (УТСО) департамента образования штата Кентукки при содействии консультантов компании KiZAN Technologies. Персонал УТСО обеспечивал общий надзор над существующей системой на основе Exchange 5.5. Повседневная эксплуатация серверов Exchange входила в обязанности персонала школьных округов.
ЗАДАЧИ
Департамент образования осуществляет техническое руководство всеми 178 школьными округами штата Кентукки. Эти школьные округи соединены друг с другом посредством глобальной сети, но каждый округ имеет свой собственный самостоятельно управляемый сервер Exchange 5.5, который необходимо было обновить отдельно. Такое обновление обеспечило бы поддержку клиентов кэшированного режима электронной почты Outlook® 2003, дополнительные возможности использования веб-клиента Outlook, поддержку стандартизированной схемы адресов электронной почты и дало бы много других преимуществ.
В дополнение к развертыванию нового почтового сервера и клиентской инфраструктуры многие школьные округи предполагали предоставить учащимся возможность пользоваться электронной почтой. Как федеральные нормы, так и нормы штата требовали, чтобы информация об учащихся была защищена и недоступна для просмотра за пределами соответствующего округа.
ПЛАН
Поскольку соединитель Active Directory® нельзя было использовать, была создана новая организация Exchange, и осуществлен перенос данных в нее. Стандартизация адресов электронной почты означала создание как новых дочерних доменов для идентификации каждого школьного округа, так и более 400 новых политик получателя. Для защиты адресов учащихся необходимо было создать для каждого школьного округа систему, включающую глобальные списки адресов и пользовательские списки адресов.
Реальный перенос включал установку нового оборудования, создание и настройку почтовых ящиков на основе принадлежности к округу и типа пользователя, а также установку таких атрибутов расширения на основе принадлежности к округу и типа пользователя, чтобы пользователь отображался в соответствующих списках адресов.
Было создано новое приложение на языке Visual Basic® для обнаружения и исправления неправильно настроенных атрибутов учетных записей и неверных данных об их принадлежности к группам, а также для предоставления новых почтовых ящиков с учетом ограничений на возможность их просмотра. Это приложение было развернуто во всех 178 округах и запускается на серверах школьных округов в соответствии с графиком.

Общие сведения
На первый взгляд все это не кажется трудной или технически сложной задачей. Однако необходимо было руководствоваться требованиями заказчика, а требования заказчика этого проекта были весьма неожиданными.
За много лет из-за децентрализованного управления и запутанных стандартов поддержка каждой системы требовала индивидуального подхода, и управлять всем этим, как правило, приходилось УТСО. Вдобавок УТСО приходилось одновременно обеспечивать соответствие системы на базе сервера Exchange 5.5 как требованиям школьных округов, так и департамента образования. Это означало, что в тех округах, где существовала электронная почта для учащихся, информация о них была защищена и недоступна для просмотра за пределами соответствующего округа, как требовали нормативы штата и федеральные нормативы (см. ed.gov/policy/gen/guid/fpco/ferpa/index.html (на английском языке)).
Для сервера Exchange 5.5 эти нормативы означали, что информация об учащихся округа не могла передаваться в другие школьные округи или другие государственные органы, которые имели доступ к данным глобального списка адресов. В частности, это приводило к необходимости осуществлять вручную процедуру импорта или экспорта для каждого из 178 узлов Exchange 5.5, а именно: скрыть информацию об учащихся, реплицировать список, открыть информацию об учащихся и, наконец, импортировать список адресов обратно. Таким образом, другие округи могли видеть только информацию о сотрудниках, а округ-владелец данных мог видеть все собственные данные и при этом – только данные о сотрудниках из других школьных округов.
С учетом сильных и слабых сторон существовавшей системы обновление инфраструктуры обмена сообщениями должно было удовлетворять некоторым особым требованиям. Во-первых, департамент образования штата Кентукки хотел ввести стандартизацию имен на основе общей легко читаемой схемы имен SMTP для всей организации. Эта схема должна была предоставить раздельные области SMTP-адресов для преподавательского состава и для учащихся.
Эта новая система должна была также обеспечить возможность централизованного предоставления услуг, чтобы снять с округов обязанности по управлению службой сообщений и ответственность за ее работу. Это означало, что управление восстановлением в случае аварии, потоком почты и ответами на обращения пользователей в службу поддержки должно было быть централизовано. По существу, новая система должна была обеспечить централизованный метод стандартизации конфигураций пользователей во всех округах, независимо от географического положения или принадлежности конкретного пользователя к какому-то округу.
Кроме того, новая система должна была обеспечить безопасный доступ к электронной почте через Интернет и с мобильных устройств в едином пространстве адресов, общем для всех округов.
С учетом всех этих требований, многие из которых еще не были реализованы в существовавшей системе Exchange 5.5, миграция на Exchange 2003 казалась грандиозной задачей.

Составные части решения
Для выполнения требований заказчика были определены несколько особенностей развертывания Exchange.
Было решено не использовать соединитель Active Directory из-за недостаточной стандартизации и значительных масштабов системы Exchange 5.5. Вместо этого была создана новая организация Exchange, и выполнена миграция в нее.
Для приведения в порядок и стандартизации адресов электронной почты персонала и учащихся всех округов потребовалось создать более 400 новых политик получателя. Для каждого округа требовалось создать уникальный идентификационный дочерний домен, включающий обозначение округа для учащихся. Например, для округа Шелби первичный дочерний домен будет shelby.kyschools.us. Учащимся всех округов назначен дочерний домен stu., то есть учащиеся округа Шелби получают адреса stu.shelby.kyschools.us.
Другим ограничением было то, что адреса учащихся должны были быть видны только внутри их собственного школьного округа, а адреса персонала должны были быть видны изо всех округов. Это потребовало построения сложной системы глобальных списков адресов и пользовательских списков адресов, как показано на рис. 1 и рис. 2. Одним из преимуществ миграции на Exchange 2003 было то, что списки адресов можно было защитить с помощью разрешений и, доступ к каждому конкретному адресу можно было контролировать путем включения в группу. Эта возможность позволила создать две группы безопасности на уровне округа (одну – для персонала, другую – для учащихся), а затем защитить глобальные и пользовательские списки адресов персонала и учащихся соответствующих округов таким образом, что определенные списки адресов были доступны только для пользователей, имеющих учетные записи конкретного округа. Удалив использовавшиеся по умолчанию глобальные и пользовательские списки адресов и убедившись, что группы Everyone (Все) и Authenticated Users (Пользователи, прошедшие проверку) не значатся в списке управления доступом ни одного из списков адресов, можно было установить список адресов, которые смогут увидеть конкретные пользователи конкретного округа.
Рис. 1 Пользовательские списки адресов на основе ролей
Рис. 1 Пользовательские списки адресов на основе ролей (Щелкните изображение, чтобы уменьшить его)
Рис. 1 Пользовательские списки адресов на основе ролей
Рис. 1 Пользовательские списки адресов на основе ролей (Щелкните изображение, чтобы увеличить его)
Однако благодаря разрешениям удалось решить только часть проблем, связанных с ограничениями на просмотр. Нужно было найти способ управлять тем, кто и в каком списке адресов должен был быть виден. Был создан базовый запрос LDAP, позволявший запросить информацию об отображении в списках адресов учащихся и сотрудников. Затем этот запрос был немного изменен применительно к каждому списку адресов и глобальному списку адресов. Например, запрос LDAP к глобальному списку адресов для персонала округа Шелби должен был отображать только соответствующий персонал и учащихся округа Шелби и весь персонал (но не учащихся) всех остальных округов штата. Глобальный список адресов учащихся Шелби должен был отображать только персонал и учащихся из округа Шелби и не должен был отображать ни персонал, ни учащихся из других округов штата. Такие запросы были созданы для всех округов в организации. На рис. 3 приведены примеры некоторых запросов LDAP, использованных при этой сложной миграции на новую систему.
Figure 3 Запросы LDAP для получения списка адресов (Close Figure 3)

Запрос LDAP для получения глобального списка адресов персонала
(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))
Запрос LDAP для получения списка адресов округа
(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=15)))))
Запрос LDAP для получения списка адресов учащихся округа
(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=20)))))
Запрос LDAP для получения автономного списка адресов персонала округа
(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))
Рис. 2 Глобальные списки адресов с разделением на персонал и учащихся
Рис. 2 Глобальные списки адресов с разделением на персонал и учащихся (Щелкните изображение, чтобы уменьшить его)
Рис. 2 Глобальные списки адресов с разделением на персонал и учащихся
Рис. 2 Глобальные списки адресов с разделением на персонал и учащихся (Щелкните изображение, чтобы увеличить его)
Различающим механизмом, лежащим в основе запросов LDAP, являлись значения свойств пользователей Exchange – extensionAttribute14 (пользовательский атрибут 14) и extensionAttribute15 (пользовательский атрибут 15). Для всего персонала и учащихся штата использовалось особое значение атрибута extensionAttribute14, обозначающее тип пользователя, и уникальное значение атрибута extensionAttribute15, обозначающее принадлежность к определенному округу. Благодаря использованию уникальных значений для каждого округа и одинаковых значений для каждого типа пользователей, в списках адресов могла отображаться лишь та информация, которая требовалась для каждого типа пользователей в каждом округе.
Эти списки адресов оказались вполне приемлемыми для тех случаев, когда пользователи работали с электронной почтой, используя Outlook в режиме без кэширования или используя веб-клиент Outlook (каждый пользователь направлялся к нужному списку адресов в веб-клиенте Outlook с помощью атрибута msExchQueryBaseDN). Однако была еще одна проблема, связанная с пользователями, которые работали с Outlook в режиме кэширования. Поскольку Outlook не использует пользовательский глобальный список адресов в качестве автономной адресной книги, пришлось создать дополнительные списки адресов, представляющие собой копии глобальных списков. В каждом хранилище почтовых ящиков округа был настроен соответствующий список адресов автономной адресной книги для пользователей, работающих в режиме кэширования. Всего потребовалось создать более 1 500 списков адресов для предоставления полного набора услуг пользователям различных типов всех 178 округов.

Соблюдение установленных требований
Для обеспечения правильной работы этой структуры после ее внедрения самым важным было соблюдение вновь установленных стандартов. Для каждого пользователя организации, работающего в системе Exchange, необходимо было выполнить несколько приоритетных задач. Причина состояла в том, что необходимо было правильно задать местоположение каждого пользователя во всех округных серверах Exchange, и каждый пользователь должен был отображаться в соответствующих списках адресов.
Пользователь должен был быть членом соответствующей группы безопасности в домене округа, поскольку принадлежность к группе безопасности определяет права на открытие соответствующих списков адресов. Необходимо было правильно установить для пользователя значение атрибута msExchQuerybaseDN на основе принадлежности к округу и структурному подразделению. Тип пользователя определялся подразделением.
Следующим шагом было создание почтового ящика пользователя в соответствующем хранилище соответствующего сервера на основе принадлежности к округу и типа пользователя. Таким способом определялись уровни обслуживания, максимальные размеры почтовых ящиков и списки адресов автономной адресной книги, чтобы обеспечить правильное функционирование Outlook в режиме кэширования. Атрибуты расширения устанавливались на основе типа пользователя и его принадлежности к округу так, чтобы пользователь отображался только в нужных списках адресов и не был виден в других.
Наконец, необходимо было обеспечить средства автоматической корректировки атрибутов учетной записи или членства в группах в случае их неправильного задания или изменения. Перемещение пользователя из одного подразделения в другое в пределах домена округа означает изменение классификации пользователя и, соответственно, необходимость изменения местоположения почтового ящика, назначенного пользователю глобального списка адресов и условий отображения пользователя в списках адресов.
Необходима была система поддержки, которая выполняла бы все эти задачи и обеспечивала слаженную и точную работу службы каталогов Active Directory. Было создано консольное приложение на языке Visual Basic, запускаемое по графику на серверах Exchange 2003 в школьных округах. Это приложение, проверяющее соблюдение политики и стандартов, а также создающее и настраивающее новые объекты, было установлено во всех 178 округах.
Было ясно, что задачи, которые предстояло решить, слишком сложны, чтобы их можно было быстро и надежно выполнить с помощью набора сценариев. Приемлемым решением было признано создание приложения на языке Visual Basic. Данный вариант отличается эффективностью и наличием структурированной поддержки обработки ошибок и исключений, причем впоследствии программный код можно будет с минимальными доработками преобразовать в код расширения сервера Microsoft Identity Integration Server (MIIS-сервер).
Поскольку осуществлялся перенос данных в новую организацию, необходимо было найти некоторый способ сосуществования старой и новой версий. В новой среде необходимо было поддерживать более 178 устаревших доменов SMTP, так как в некоторых округах уже были домены электронной почты для учащихся, а в некоторых не было, однако была возможность проводить миграцию в округах по очереди и переключать их на новую систему сообщений и адресов, не затрагивая другие округи. Тем не менее, необходимо было исключить нарушения работы электронной почты при миграции округа с сервера Exchange 5.5 на Exchange 2003. Это означало необходимость реализации определенной синхронизации между Active Directory сервера Exchange 2003 и устаревшим каталогом сервера Exchange 5.5. На время миграции корпорация Майкрософт предоставила департаменту образования штата Кентукки право ограниченного использования сервера MIIS, поэтому был разработан код расширения, использовавшийся для синхронизации старой и новой организаций Exchange перед миграцией, а также во время и после нее.
Переход к новой организации Exchange, естественно, влияет на конфигурацию клиента MAPI. Департамент образования столкнулся с тем, что на уровне округов существовали буквально десятки тысяч профилей MAPI, которые необходимо было перенастроить в ходе миграции. К счастью, корпорация Майкрософт выпустила инструмент Exchange Profile Tool (ExProfRe.exe), который был использован для миграции профилей MAPI в округах. Была создана программа пакетной установки, которая запускала ExProfRe.exe с предустановленными параметрами для автоматического выполнения миграции профилей MAPI. Программа запускалась через групповую политику. Автоматическое преобразование профилей между организациями происходило с почти стопроцентным успехом.

Обновление оборудования
Поскольку новые серверы Exchange 2003 должны были занять место географически разбросанных серверов Exchange 5.5, применяемое оборудование должно было обеспечивать возможность работы такого же количества пользователей, что и система на основе Exchange 5.5, а также дополнительное количество учетных записей учащихся. Серверы должны были размещаться в округах, поскольку топология глобальной сети была разработана таким образом, что весь поток данных между округами (как внутренний, так и связанный с обращением к Интернету) проходил по частным каналам T1 (в некоторых округах по нескольким каналам T1).
Из-за ограничений, связанных с бюджетом, возможностями управления и размещением оборудования, невозможно было снабдить серверы Exchange устройствами хранения данных, подключаемыми к сети областей хранения (SAN), поэтому все эти устройства хранения данных должны были быть либо встроенными, либо непосредственно подключаемыми. Поскольку в большинстве округов не было центров обработки данных со специальными стойками и централизованной системой охлаждения, необходимо было, чтобы серверы были максимально автономными. К счастью, в большинстве округов было менее 5 000 пользователей, поэтому в них можно было ограничиться установкой одного сервера. В округах с большим количеством пользователей использовались более мощные серверы (или несколько серверов) и дополнительные устройства хранения данных, иногда вместе с серверами предварительной обработки данных для дальнейшего разделения потоков информации учащихся и персонала.
В большинстве округов удалось установить хорошо оснащенные двухпроцессорные серверы, оснащенные максимальным количеством жестких дисков Ultra320 SCSI со скоростью вращения 15 000 оборотов в минуту, несколькими контроллерами RAID и оперативной памятью 4 ГБ. В более крупных округах устанавливался один или несколько четырехпроцессорных серверов, а при необходимости £ еще и менее мощные серверы переднего плана. Измерение и тестирование производительности перед установкой не выявило никаких проблем в работе, в том числе и при повышенной нагрузке. Тем не менее, решающим фактором, определяющим общую производительность серверов, были различные условия их эксплуатации.

Проверка концепции
Хотя реальная среда включала лес из 178 доменов Active Directory, модель для проверки концепции в тестовой лаборатории была уменьшена до 13 доменов округов и пустого корневого домена. Во все тестовые домены были экспортированы данные из реальных доменов. Были созданы виртуальные серверы Exchange 5.5, на которых были настроены копии выбранных баз данных округов, так что можно было протестировать процессы миграции и добавления планируемой среды к существующей. Вся тестовая среда для проверки концепции состояла из виртуальных компьютеров, так что она могла быть скомпонована, заморожена и вновь развернута, когда понадобится.
Были разработаны, запрограммированы, протестированы и окончательно оформлены различные комбинации сценариев (использующих язык VBScript), пакеты установщика сервера Systems Management Server (SMS) и консольные приложения. Наконец, имелись сценарии для выполнения первоначальной установки и конфигурирования сервера Exchange 2003, включая настройку политик получателя, глобальных и пользовательских списков адресов и разрешений. Конфигурирование административных групп, доменов округов (создание групп безопасности и делегирование разрешений) и подготовка к миграции после завершения установки также проводились с помощью сценариев.
Установка серверов Exchange 2003 представляла собой значительную проблему. Необходимо было провести установку серверов Exchange во всех 178 доменах, притом сделать это таким образом, чтобы не подвергать риску дальнейший процесс миграции. Сервер Exchange 2003 отличается от Exchange 2000 тем, что группа «Серверы домена Exchange», настраиваемая отдельно для каждого домена, не добавляется в список управления доступом организации до тех пор, пока в домене не будет установлен первый сервер Exchange 2003. (В Exchange 2000 эта группа добавляется при запуске процесса DomainPrep (Подготовка домена)). Чтобы убедиться, что все необходимые группы безопасности внесены в объект организации в Active Directory, нужно было провести установку одного домена, вручную провести репликацию Active Directory с этого домена на центральный сервер репликации Active Directory, а затем перенести эту реплику в следующий устанавливаемый округ. Установка в следующем округе могла начаться только после подтверждения, что список управления доступом объекта организации содержит группу «Серверы домена Exchange» из предыдущего округа. Если бы этот процесс завершился неправильно хотя бы в одном домене, установку в данном округе пришлось бы проводить повторно (по меньшей мере), или другие округи не смогли бы связаться друг с другом из-за того, что объект списка управления доступом содержал бы неправильный список остальных округов.
Процесс развертывания, конфигурирования, установки серверов и миграции тестировался много раз до тех пор, пока он не начал нормально выполняться в тестовой среде.

Миграция и болезни роста
После одобрения проектной группой процедуры проверки концепции и ее результатов можно было начинать миграцию. Первым провести миграцию решило само Управление технических средств обучения, чтобы непосредственно проверить процесс и его последствия. К моменту миграции все серверы уже были размещены и начальное состояние среды проверено. Все серверы предварительной обработки данных и почтовые серверы были на месте и готовы к обслуживанию пользователей.
План миграции был выполнен успешно, и после долгих 21 часа переноса данных с одного сервера на другой УТСО перешло на сервер Exchange 2003. К счастью, не возникло никаких значительных проблем при переносе профилей Outlook с сервера Exchange 5.5 на Exchange 2003. Был создан пакетный файл, который на основе несложных правил вызывал программу ExProfRe.exe в различных конфигурациях. Затем пакетный файл и программа ExProfRe.exe были помещены в папку общего доступа Netlogon контроллера домена в каждом округе, и в конце миграции с помощью политики групп был включен запуск этого пакетного файла для всех клиентов. Этот подход оказался удачным в случае с УТСО, что придало нам уверенности в успешном продолжении проекта.
К этому моменту план миграции был пересмотрен и вновь одобрен с учетом опыта развертывания в УТСО. Для продолжения миграции в качестве первой рабочей площадки были выбраны шесть округов. Перед миграцией каждого округа сервер MIIS должен был прочитать в системе Exchange 5.5 самые свежие данные о почтовых ящиках округа и обновить соответствующих пользователей в домене. Для реального переноса почтовых ящиков из одной организации в другую использовался мастер миграции Exchange (Mailmig.exe). После переноса почтовых ящиков с помощью мастера миграции все адреса прокси-сервера были заменены и обновлены с помощью данных, ранее экспортированных в Active Directory с MIIS-сервера. Во время миграции вся почта должна была накапливаться в очередях на SMTP-серверах переднего плана, а после завершения миграции, настройки серверов и проверки пользователей направляться в округи. Округ был готов к проведению широкомасштабного переноса клиентов с использованием ExProfRe.exe.

Проблемы со службой обновления получателей
Для обеспечения правильной работы клиентов Outlook нужно было, чтобы установка значений атрибутов была произведена именно программой наполнения данными. Для завершения работы по настройке учетных записей необходима была также служба обновления получателей, но она должна была запускаться только тогда, когда закончится наполнение данными. Для выполнения этого условия в графиках запуска экземпляров службы обновления получателей во всех 178 округах было установлено значение Never (Никогда), а в программу наполнения данными был включен код, который запускал службу обновления получателей после завершения работы программы наполнения данными.
В большинстве округов было менее 5 000 пользователей и совсем немного ежедневных обновлений, так что работа службы обновления получателей завершалась быстро, поскольку система наполнения данными в конце ежедневного сеанса просто запускала обновление вместо перестройки. Однако в нескольких округах было более 10 000 пользователей. Обновление в них заняло больше времени, а если бы службе обновления получателей потребовалось провести полную перестройку в этих больших округах, это могло занять неделю или больше. Поскольку служба обновления получателей во время работы вычисляет все типы объектов, проведение перестройки в таких больших округах было изнурительной работой.
Хотя мы не смогли предложить стратегию преодоления этой проблемы (мы пытались найти решение вместе с членами группы разработчиков продукта Exchange), программа наполнения данными была доработана для выполнения большинства тех задач, которые обычно выполняет служба обновления получателей. При первоначальном наполнении данными атрибуты пользователей showInAddressBook (Показывать в адресной книге) и proxyAddresses (Адреса прокси-сервера) устанавливались так, чтобы пользователи могли подключаться к системе сразу, не ожидая завершения работы службы обновления получателей. Была также создана задача, запускавшаяся вручную на одном из серверов предварительной обработки информации Exchange 2003. Она по графику выполняет импорт с помощью инструмента LDIFDE и очищает адрес шлюза gatewayProxy службы обновления получателей, так что, если в среде будет случайно применена какая-либо политика получателя, она не попадет в список выполняемых задач всех служб обновления получателей организации.

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

Извлеченные уроки
Если я и извлекла какой-то урок, работая над этим проектом, то он состоит в том, что все, что мы делаем в качестве консультантов, определяется требованиями заказчика. Много раз нам приходилось сопоставлять возможность выполнения требований заказчика со сложностью решения. Решения, описанные в этой статье, казались нам самыми подходящими в нашей ситуации (включая те ее стороны, на обсуждение которых здесь не было времени) с учетом имевшихся ресурсов и требований заказчика. Возможно, ваши решения будут другими, но, надеюсь, эта статья дала вам материал для размышлений. К счастью для нас, Exchange 2003 и Active Directory обладают достаточной гибкостью для выполнения всех требований такой сложной миграции. Пройдя трудный путь развертывания системы в департаменте образования штата Кентукки, я могу сказать, что само решение довольно несложное и основывается, как мне кажется, на малоиспользуемых возможностях Active Directory и Exchange 2003.
Другой ценный урок – это необходимость уделять равное внимание устранению неисправностей и управлению рисками и проблемами. Иногда неполадки можно устранить на местном уровне, а иногда необходимо привлечь дополнительные ресурсы службы технической поддержки Майкрософт.

Взгляд в будущее
Конечно, условия департамента образования штата Кентукки уникальны. В процессе развертывания почти каждая функция Exchange была использована или настроена, чтобы соответствовать требованиям департамента. Теперь, когда вся среда успешно развернута и перенесена, все готово для использования дополнительных возможностей. По мнению департамента образования, школьные округи заинтересованы в использовании платформы Windows Mobile®, и ожидается развитие поддержки мобильных устройств.
Значительные преимущества можно получить от консолидации серверов. Сейчас департамент образования штата Кентукки рассматривает возможность виртуализации некоторых аспектов среды Active Directory. И поскольку приближается выпуск сервера Exchange 2007, департамент начал готовить требования к обновлению системы обмена сообщений.
Департамент образования штата Кентукки рассматривает также дополнительные предложения о сотрудничестве в области применения серверов Live Communication Server, Live Meeting Server и т. д. В настоящее время идет развертывание системы Microsoft Operations Manager 2005 для управления серверами Exchange и Active Directory и слежения за ними.

Итоги
Эта качественная всеобъемлющая система охватывает каждого ребенка в системе среднего школьного образования штата Кентукки, включая моих собственных детей и детей тех людей, с которыми я работала над этим проектом. Его реализация убедила департамент образования штата Кентукки в необходимости двигаться вперед быстрее, чем когда бы то ни было, с помощью новых технологий и на основе безопасных и стандартизированных методов. Я горжусь тем, что принимала участие в этом проекте.

Уитни Робертс (Whitney Roberts) – главный консультант компании KiZAN Technologies (www.kizan.com (на английском языке), работает с программным обеспечением Exchange, начиная с выпуска Exchange 4.0.


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

Предотвращение перезагрузок

Вопрос. Как ограничить число перезагрузок при установке исправлений и других дополнений к SQL Server и к серверной операционной системе в целом?

Ответ. Во-первых, нужно учесть, что перезагрузки, происходящие после установки, довольно редко обуславливаются кодом программы установки. Чаще всего они происходят из-за блокировки файлов. Иными словами, если программа установки безуспешно пытается обновить файлы, которые в этот момент используются (блокируются) другим приложением или операционной системой, то выполняется перезагрузка. Наиболее очевидный способ избавиться от необходимости перезагрузки £ сделать так, чтобы к обновляемым файлам не обращались сторонние процессы. Как этого достичь?
Во-первых, нужно узнать, какие именно файлы во время инсталляции были заняты и заблокированы. Для этого откройте раздел реестра HKLM\system\currentcontrolset\control\sessionmanager\pendingfilerenameoperations. С помощью этого раздела вы сможете решить сразу две задачи: убедиться в том, что запрос на перезагрузку действительно был подан вследствие блокировки, и узнать перечень заблокированных файлов. Анализ содержимого упомянутого раздела между установкой и перезагрузкой позволит вам разобраться в причинах перезагрузки и предпринять меры к исключению аналогичных ситуаций в ходе последующих сеансов установки.
В этом разделе вам могут встретиться записи двух типов. Если файл был заблокирован для чтения, ему соответствует однострочная запись; это значит, что обновленный файл уже записан на диск и теперь необходимо удалить его временную копию. Если файл был заблокирован для записи, соответствующая ему запись состоит из двух строк; следовательно, обновление еще не произошло, состояние приложения неизвестно и обращаться к нему не следует. Записи такого типа отражают заминку в ходе установки. В таком случае в одной строке указывается существующий файл, а во второй £ временный файл (после перезагрузки первый заменяется вторым).
Содержание следующего этапа зависит от многих факторов, но суть в том, чтобы определить, какое ПО обращается к заблокированным файлам. По возможности воспользуйтесь средствами контроля зависимостей или базой данных DLL HELP в системе MSDN® (см. support.microsoft.com/kb/815065 (на английском языке).
Если программному обеспечению, которое обращается к файлу, соответствует та или иная служба, остановите её вручную и повторите проверку. Если речь идет о приложении, закройте его и проведите повторную проверку. В некоторых случаях к одному файлу обращаются сразу несколько приложений; если это так, нужно закрыть их все.
Результатом таких проверок (которые следует проводить в тестовой среде) должен стать перечень приложений и служб, которые в рабочей среде необходимо останавливать перед установкой. Таким образом, необходимость перезагрузки в рабочей среде можно будет исключить, так как файлы, с которыми работает программа установки, не будут блокироваться сторонним ПО. По завершении установки все ранее остановленное ПО нужно запустить вновь.
К счастью, схемы блокировки обычно не подвержены серьезным изменениям. Стоит единожды проследить такую схему и, скорее всего, при работе с системой в долгосрочной перспективе вам удастся избежать множества перезагрузок.
Есть еще одно правило, о котором стоит упомянуть. Иногда в одной системе устанавливается сразу несколько версий SQL Server™ или других продуктов, при этом у них даже могут быть разные уровни версий. В подобных ситуациях обновление всегда следует начинать с самой свежей версии. Скорее всего, в таком случае все необходимые файлы будут заменены последними версиями, а остальные экземпляры продукта не станут блокировать их. К примеру, если в системе установлено три экземпляра SQL Server 2000 SP3, при обновлении первого из них до SP4 файл MSXML3.dll должен быть заменен, а значит, нужна перезагрузка. Предположим, что вы её выполнили. При обновлении двух оставшихся экземпляров до SP4 перезагрузка не потребуется – ведь новая версия MSXML3.dll уже установлена. Аналогичное правило действует и в других случаях: при обновлении экземпляров SQL Server 2005 перед SQL Server 2000, SQL Server 2000 перед SQL Server 7.0 и так далее. Это универсальная, фактически работающая методика минимизации перезагрузок.
Если рассуждать стратегически, группы разработчиков корпорации Майкрософт уже долгое время трудятся над тем, чтобы исключить или по меньшей мере ограничить число перезагрузок в различных ситуациях. Так как тема этой статьи £ «SQL, вопросы и ответы», рассмотрим в качестве примера SQL Server.
При подготовке версии SQL Server 2005 разработчики SQL Server разбили код компонентов MDAC (Microsoft® Data Access Components), необходимый для функционирования SQL Server, на SQLNCLI (новые файлы), отказавшись от обновления собственно MDAC, при этом компоненты MDAC были возвращены в распоряжение ОС. К чему это привело? Дело в том, что операционная система Windows® сама обращается к компонентам MDAC и блокирует их файлы. По этой причине установка пакетов обновления SQL Server и других пакетов традиционно сопровождалась перезагрузкой. Теперь SQL Server обновляет собственную версию MDAC, не обращаясь к файлам MDAC, применяемым операционной системой, следовательно, необходимость перезагрузки отпадает.
Более того – в программе установки SQL Server 2005 SP1 есть встроенное средство контроля зависимостей и предусмотрена возможность приостановки. Это средство показывает перечень заблокированных файлов и предполагаемые источники блокировки; вы можете сразу остановить ПО, блокирующее необходимые файлы, и продолжить установку без перезагрузки. Таким образом, у вас появляется возможность предпринять меры к предотвращению перезагрузки в реальном времени, не обращаясь к тестовой среде. Естественно, при необходимости, а также при работе в несопровождаемом режиме можно продолжить установку без закрытия блокирующего ПО и выполнить перезагрузку. Как видите, выявить источники блокировки файлов теперь очень просто!
Помимо прочего, технология Microsoft Installer сейчас значительно эффективнее работает с разделом реестра PendingFileRenameOperations (PFR). Если вы помните, при обнаружении в вышеупомянутом разделе реестра записей о любых файлах процесс установки SQL Server 2000 блокировался. Что же касается программы установки SQL Server 2005, то она блокируется только если файлы относятся к SQL Server (и продолжение установки может привести к конфликту), но даже в таких случаях ей зачастую удается обратиться к разделу PFR и обновить его содержимое напрямую, тем самым избежав перезагрузки. На том или ином уровне эта технология реализована как в MSI, так и в update.exe £ двух стандартных на сегодняшний день программах установки от Майкрософт, с помощью которых выполняются все обновления.
Каковы известные факторы, приводящие к перезагрузке? В первую очередь, это файл MSXML3.dll. Он постоянно заблокирован службой Windows SVCHost, и при любом обращении к этой службе перезагрузки не избежать. Аналогичная ситуация характерна для большинства стеков MDAC (mdac_typ.exe). К счастью, в Windows Server® 2003, Windows XP SP2 и последующих версиях ОС компоненты MDAC являются "разделенными". Разработчики SQL Server здорово потрудились, отделив msxmlsql.dll, в результате чего обновления SQL Server обычно не сопряжены с перезагрузкой, хотя иногда её все же не избежать. В таких ситуациях трудно предложить какое-то решение £ закрыть службу SVCHost и продолжить обновление невозможно.
Кроме того, стоит упомянуть об особенностях процесса деинсталляции в исполнении пакетов update.exe. При деинсталляции они блокируют (естественно, вне разделов PFR) наличные файлы программы установки. В результате исполнение других пакетов update.exe до перезагрузки, при которой такая блокировка снимается, становится невозможным. С этим вряд ли что-то можно поделать – разве что планировать перезагрузку после деинсталляции исправлений.
Другая проблема – периодичность. Не все программы обращаются к тому или иному файлу постоянно. На самом деле большинство общих библиотек DLL используются не постоянно, а в отдельные моменты времени; это значит, что другие программы могут обращаться к ним только по необходимости, в зависимости от своей рабочей нагрузки и путей, заданных в коде. В такой ситуации даже десятикратные испытания могут не выявить заблокированных файлов, но не исключено, что впоследствии они совершенно неожиданно обнаружатся в рабочей среде. Увы, с этим ничего нельзя поделать. Попробуйте максимально приблизить тестовую среду к рабочей, в том числе смоделировать рабочую нагрузку (впрочем, к этому нужно стремиться всегда) и провести столько испытаний, сколько необходимо для выявления подобных явлений.
Установка пакетов обновления и отдельных обновлений ОС всегда сопряжена с перезагрузкой. Следует иметь в виду, что в версиях ОС нижнего уровня (Windows 2000, Windows XP и во всех предшествующих версиях) установка считается незавершенной вплоть до завершения перезагрузки £ даже если раздел реестра pendingfilerenameoperations пуст. Существуют операции, направленные на регистрацию пакетов исключений (exception packages), которые могут исполняться во время перезагрузки для установки кода. Они не входят в состав пакетов обновления; это встроенные команды операционной системы, которые запускаются сценариями обновления для сохранения работоспособности отдельных блоков кода.
Наконец, раздел PFR не выполняет ни проверок версий файлов, ни упорядочивания путем сериализации. Иными словами, он запускает процесс замены файлов в том порядке, в котором они перечислены. С другой стороны, на жестком диске они сохраняются в порядке «от последнего завершенного» (в противоположность порядку «от первого запущенного»). Это вполне разумное решение, но оно также означает, что при наличии в рамках одного пути двух копий одного и того же файла, указывающих на разные его версии, перезагрузка приведет к произвольному результату. Столкнувшись с подобной ситуацией, обязательно исправьте ее. Если вы не уверены, что нужно сделать, запустите после перезагрузки обе программы установки. При правильном подборе файлов ни один из них не приведет к сбою. При неправильном подборе запуск пакета с нужным файлом поможет исправить ситуацию. Честно говоря, это и быстрее и безопаснее, чем попытки определить желаемый результат.

Установка нескольких пакетов обновления

Вопрос. В кластере из четырех узлов установлено восемь кластеризованных экземпляров SQL Server 2000. Как провести установку SP4 с минимальным числом перезагрузок? Можно ли последовательно установить SP4 на всех 8 экземплярах, а затем провести перезагрузку всех узлов?

Ответ. После завершения установки первого экземпляра SQL Server SP4 (в результате которой может потребоваться перезагрузка) на любом сервере Windows (вне зависимости от того, входит ли он в состав кластера или нет) инсталляция SQL Server SP4 для других экземпляров SQL Server в данной системе не приводит к перезагрузке. Дело в том, что все общие файлы £ инструментальные средства, MDAC, MSXML и т. д. £ к этому моменту обновлены до нужной версии, и поэтому независимо от того, заблокированы они или нет, не требуют дополнительного обновления. Все файлы, не являющиеся общими, используются только первым экземпляром, который будет остановлен программой установки. Следует отметить, что при наличии нескольких экземпляров нескольких версий хронологически последний экземпляр SQL следует обновлять в первую очередь.

Исполнение от имени сетевой службы

Вопрос. Что конкретно представляет собой учетная запись NT AUTHORITY\NETWORK SERVICE и в чем её основное назначение? Кроме того, какой уровень безопасности обеспечивает эта учетная запись, в особенности если ей присвоены полномочия системного администратора (SA)?

Ответ. Учетная запись Network Service совпадает по составу сетевого удостоверения (удостоверения машины) с учетной записью System, но уступает ей по набору полномочий в локальной среде. Таким образом, если службе требуется доступ к сетевым ресурсам (например, для разрешения имен учетных записей на контроллере домена), она исполняется с учетной записью домена, System или Network Service. Последний вариант, как правило, безопаснее других, поскольку по своему диапазону эта учетная запись ограничивается локальной средой, в которой ей предоставляется ограниченный набор полномочий.
Присвоение учетной записи Network Service полномочий системного администратора в SQL Server приведет к тому, что любая другая служба, исполняемая в локальной среде с учетной записью Network Service, сможет получить полный контроль над сервером. Это, в частности, происходит при настройке исполнения учетной записи службы SQL Server в качестве Network Service. В то же время, включение учетной записи службы SQL Server в группу SA требуется для обеспечения функциональности сервера (например, для того, чтобы сделать возможным установление соединений обратной связи). Присвоение Network Service административных полномочий в среде SQL Server – не самое удачное с точки зрения безопасности решение, но в определенных (не во всех) случаях оно предпочтительнее по сравнению с привлечением для таких целей учетной записи домена, и определенно безопаснее присвоения SQL Server полномочий учетной записи LocalSystem.
Если вы не хотите присваивать Network Service полномочия на уровне системного администратора, попробуйте создать учетную запись домена, специально предназначенную для управления SQL Server в одной или нескольких инсталляциях Windows NT®.
В этом вам помогут следующие статьи: msdn.microsoft.com/library/en-us/dnpag2/html/paght000009.asp (на английском языке) и microsoft.com/technet/security/topics/serversecurity/serviceaccount (на английском языке).

Создание нескольких баз данных

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

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

Благодарим за технические консультации следующих ИТ-специалистов корпорации Майкрософт: Рамон Арджона, Фрэнк де Велле, Роберт Джабаров, Арман Лермон-Крики, Максвелл Майрик, Руслан Овечкин, Уттам Паруи, Шаши Рамака, Гэри Роос, Гевин Шарп, Виджей Сирохи, Джимми Томпсон и Мадхусудханан Вадламаани (Ramon Arjona, Frank De Waelle, Robert Djabarov, Herman Learmond-Criqui, Maxwell Myrick, Ruslan Ovechkin, Uttam Parui, Shashi Ramaka, Gary Roos, Gavin Sharpe, Vijay Sirohi, Jimmie Thompson, Madhusudhanan Vadlamaani).

Редактор £ Нэнси Мичелл (Nancy Michell)


 Эй, программист!: Где подставки для стаканов?
Эй, программист!
Где подставки для стаканов?
Сотрудники группы Microsoft Scripting Guys
В этой статье приведены сведения на основе предварительной версии Windows PowerShell. Информация в этой статье подлежит уточнению.

Всякий раз, когда появляется новая технология, людям требуется некоторое время, чтобы разобраться, чем эта новая технология отличается от того, что было до нее. Возьмем, к примеру, первые автомобили. Понятно, почему эти хитроумные штуковины воспринимались исключительно как кареты без лошадей: они по сути ими и являлись. Если вдуматься, единственная разница между первыми автомобилями и конными экипажами состояла в отсутствии лошади. Никаких других различий между ними не было.
Сегодня, конечно, вряд ли кто-нибудь перепутает автомобиль и карету. Потому что со временем производители научились делать автомобили так, что они и вправду стали отличаться от карет. Например, современные машины прямо на заводе комплектуются проигрывателями компакт-дисков, кондиционерами и спутниковыми навигационными системами. Немногие конные экипажи могут похвастаться тем же. Или представьте себе такое: вы правите каретой в году этак 1880-м, и вам нужно на минутку отставить ваш стаканчик с фрапучино... Извините, конечно, но у вас ничего не выйдет. А вот некоторые модели внедорожников оснащены ни много ни мало 17-ю держателями стаканов, а в одной из моделей автомобиля только для одного водителя предусмотрено три таких держателя. В некоторых новых машинах держатели стаканов даже имеют функции подогрева и охлаждения.
Замечание Да, теперь сложно даже представить, что были когда-то такие времена, что людям приходилось буквально выживать в пути, не имея возможности пить три разных напитка. Как, спрашивается, можно вести машину, имея под рукой только один или два напитка?
Для того чтобы новая технология действительно имела успех, люди должны понять, почему именно они должны предпочесть новое и неизвестное старому и проверенному. Когда появились первые проигрыватели DVD, они позволяли смотреть фильмы дома точно так же, как и видеомагнитофоны. С другой стороны, DVD-диски были гораздо дороже, чем видеокассеты, а DVD-проигрыватели не могли записывать телевизионные передачи. Прямо скажем, что победа DVD не была молниеносной. На самом деле DVD начали теснить своих видеоконкурентов только тогда, когда их производители стали помещать на диски сцены, вырезанные из фильмов, комментарии актеров, о которых вы даже не знали, что они снимались в этой картине, и другой материал, которого не было на видеокассетах. Производители DVD должны были предложить намного больше того, что уже было у потребителя £ возможности просто посмотреть фильм дома.
Замечание Смотрит ли кто-то эти дополнительные материалы, помещенные на диск, или нет, уже не так важно: такова человеческая натура £ если что-то можно поиметь, то это просто надо иметь. Кстати, группа Scripting Guys планирует выпустить DVD, содержанием которого будут главным образом тексты, удаленные из статей в журнале TechNet Magazine и скрипты с измененными окончаниями для системного администрирования.

Работа в среде Windows PowerShell
Windows PowerShell™ представляет собой новую технологию написания сценариев и работы с командами, разработанную корпорацией Майкрософт и являющая собой хороший пример вышесказанного. Первое, что человек слышит о среде Windows PowerShell, это, как правило, одно из следующих заявлений:
  • "Windows PowerShell позволяет управлять процессами и службами."
  • "Windows PowerShell позволяет извлекать события из журналов событий."
  • "Windows PowerShell позволяет управлять компьютером посредством WMI (Windows Management Instrumentation) £ инструментов управления Windows."
Все это правильно. Это все полезные и важные задачи. Но есть одна проблема. Все это можно и раньше было делать средствами языка сценариев VBScript и сервера сценариев Windows Script Host. Поскольку обратная совместимость очень важна, то Windows PowerShell не могла бы считаться новой технологией, если бы не обладала также возможностями языка VBScript. (Представьте себе DVD-проигрыватель, который не может воспроизводить фильмы. Хотя что там представлять £ у одного из наших программистов как раз такой и стоит дома.)
С другой стороны, если среда Windows PowerShell может делать только то, что делает язык VBScript, тогда зачем вообще нужна эта новая технология? Известно, что в комплект поставки VBScript держатели стаканов не входят. Но нет их и в среде Windows PowerShell. Тогда какая разница, какую из технологий использовать для написания сценариев?
Если честно, никакой разницы может и не быть. С другой стороны, если забыть про держатели стаканов, среда Windows PowerShell предлагает некоторые возможности, которых нет в языке VBScript. Если все, что нужно, это управление процессами и службами, то нет никакой необходимости изучать Windows PowerShell. Как говорится, не нужно чинить то, что работает. (У нас эта поговорка звучит так: "Люди, не вздумайте это чинить, а то оно обязательно сломается.") Преимущество среды Windows PowerShell проявляется в ситуациях, когда вы можете с ее помощью делать то, что не позволяет сделать язык VBScript. Что-нибудь вроде изменения времени последнего сохранения файла.

Изменение времени последнего сохранения файла
Вы не ослышались: изменение времени последнего сохранения файла. По многим причинам (например, для облегчения контроля версий) программисты мечтали о том дне, когда они смогут изменять время сохранения (или время создания) файла или набора файлов. К сожалению, такой возможности нет ни в инструментах управления Windows (WMI), ни в объекте FileSystemObject. В обеих технологиях даты и время у файлов £ атрибуты только для чтения.
А в среде Windows PowerShell изменение времени последнего сохранения файла на текущие время и дату производится простой командой:
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = Date
Прежде чем объяснять как работает эта команда, ответим на вопрос, который скорее всего возник у большинства читателей: каким образом Windows PowerShell может изменять время последнего сохранения файла, а WMI нет? Наверное, на этот вопрос нужно было ответить прежде всего, так как он указывает на всеобщее заблуждение относительно Windows PowerShell. Многие считают, что Windows PowerShell это просто новый способ использования WMI. Разумеется, Windows PowerShell можно использовать для доступа к данным WMI. Также следует признать, что в ожидании дополнительных командлетов (команды, исполняемые в среде Windows PowerShell) для большинства сценариев системного администрирования будет использоваться WMI. Дело в том, что Windows PowerShell работает на платформе .NET Framework, и командлеты для Windows PowerShell как правило работают с .NET-объектами, а не с WMI-объектами. И это необходимо учитывать, поскольку свойства, доступные в .NET Framework, не обязательно совпадают со свойствами, доступными в WMI.
Например, при использовании командлета Get-Item для доступа к файлу, мы получаем не экземпляр класса WMI CIM_Datafile, а .NET-объект. Действительно ли это так важно? Конечно: .NET-объект предоставляет набор свойств и методов для управления файлом, которые слегка отличаются от свойств WMI-объекта. Но, как мы только что убедились, это маленькое отличие может сыграть большую роль, как в случае отличия свойства только для чтения от свойства для чтения и записи.
Вопрос из зала: как определить, что командлет Get-Item возвращает .NET-объект? В данном случае, как и в большинстве других, самый простой способ узнать с какого рода объектом мы имеем дело (как, впрочем, и определить доступные свойства и методы) £ это получить доступ к файлу и передать этот объект командлету Get-Member:
Get-Item c:\scripts\test.txt | Get-Member
Результат выполнения этой команды показан на рис. 1. Как видите, это действительно .NET-объект (как будто программисты из Scripting Guys хоть когда-нибудь ошибались в таких вещах).
Figure 1 Члены объекта, возвращаемого Get-Item (Close Figure 1)

TypeName: System.IO.FileInfo

Name                      MemberType     Definition
----                      ----------     ----------
AppendText                Method         System.IO.StreamWriter AppendText()
CopyTo                    Method         System.IO.FileInfo CopyTo(String destFileName),
                                         System.IO.FileInfo CopyTo(S...
Create                    Method         System.IO.FileStream Create()
CreateObjRef              Method         System.Runtime.Remoting.ObjRef CreateObjRef(
                                         Type requestedType)
CreateText                Method         System.IO.StreamWriter CreateText()
Кстати, эта простенькая команда иллюстрирует две еще более интересные возможности Windows PowerShell: конвейерную обработку данных и метаданные. Не вдаваясь в технические подробности, поясним основную идею конвейерной обработки. Она заключается в том, что вы можете использовать один командлет для получения объекта и передачи его другому командлету. В этой команде мы воспользовались сначала командлетом Get-Item для получения объекта, представляющего файл C:\Scripts\Test.txt, а затем передали его по конвейеру (как объект) командлету Get-Member. (Символ «|» в командах Windows PowerShell обозначает конвейерную обработку.)
Затем командлет Get-Member выполняет собственные действия, заключающиеся в получении свойств и методов полученного объекта. Еще одно из замечательных свойств Windows PowerShell £ легкость доступа к метаданным, данным о данных. Используя командлеты Get-Member и Get-Command, можно делать любые запросы в Windows PowerShell, точно так же как вы пишете WMI-сценарии для получения информации о доступных классах, свойствах и методах WMI.
Надо отметить, что командлет Get-Member предоставляет больше возможностей, чем WMI. Несмотря на то, что WMI позволяет получать информацию о WMI-объектах, информация о других COM-объектах (например FileSystemObject) для него недоступна. В Windows PowerShell дело обстоит иначе. Командлет Get-Member работает со всеми объектами, которые можно создать или к которым получить доступ. Не можете вспомнить, какие методы доступны при использовании FileSystemObject? Введите следующую команду:
New-Object -comobject "Scripting.     FileSystemObject" | Get-Member
Возможности этой невероятно полезной команды оценены далеко не в полной мере.
Здорово, правда? Если при работе с файлом C:\Scripts\Test.txt просмотреть список доступных свойств и методов, то мы увидим такую строку:
LastWriteTime             Property       System.DateTime LastWriteTime {get;set;}
Интересно следующее. Очевидно, что свойство LastWriteTime поддерживает оба метода £ как get (чтение), так и set (запись). Означает ли это, что с помощью Windows PowerShell можно изменять значение времени последнего сохранения файла? Хм...
Глоссарий Windows PowerShell
Псевдоним Назначаемое имя, представляющее существующий командлет. В Windows PowerShell имеется ряд стандартных псевдонимов, которые представляют распространенные команды командного процессора ОС командлетам с эквивалентной функцией.
Командлет Функциональная единица в среде Windows PowerShell, аналогичная встроенным командам других сред.
Команда Действие, выполняемое в среде Windows PowerShell. Команда может состоять из несколько операций, выполняемых по конвейеру, а также объединять несколько строк с помощью символа «;».
Фрапучино Кофейный коктейль, который подают в Starbucks.
Monad/MSH/Microsoft Command Shell Прежние кодовые наименования Windows PowerShell.
Объект Структурированные данные, полученные от системы или из команды. Windows PowerShell манипулирует данными как .NET-объектами, что позволяет обращаться к свойствам этих объектов по имени и не проводить синтаксический анализ результата выполнения команды в виде текста.
Параметр Варианты значений в командной строке командлета. Для назначения параметра в Windows PowerShell используется дефис (-) перед параметром.
Конвейерная обработка данных Дает возможность отправлять результат действия одной команды другой команде. Иногда называется конвейером. Обозначается символом «|».
Профиль Настройки, загружаемые при запуске Windows PowerShell и дающие возможность управлять работой среды.
Сценарий Одна или несколько команд, сохраненных в виде файла и исполняемых из файла. В Windows PowerShell файлы сценариев имеют расширение .ps1.
Оболочка Среда командной строки, в которой выполняются команды и командлеты.
Переменная Объект или параметр с устанавливаемым, изменяемым и получаемым во время исполнения команды значением.

Давайте вернемся и поговорим о команде, которая меняет время последнего сохранения файла Test.txt на текущие время и дату. Она выглядит так:
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = Date
Как видите, команда очень простая. Сначала мы объявляем переменную $a. Затем используем командлет Get-Item для подсоединения файла C:\Scripts\Test.txt. Затем сохраняем объект в переменной $a. После точки с запятой (которая дает возможность вводить несколько команд в одной строке), мы присваиваем свойству LastWriteTime текущее время и дату. Это, похоже, восполняет отсутствие держателей стаканов, правда?

Немного фантазии
Безусловно, мы можем изменить время последнего сохранения файла не только на текущие время и дату. Рассмотрим следующий пример:
$b = Get-Date "5/22/2006 8:15 PM";
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = $b
Здесь мы объединили три команды в одну строку. Сначала с помощью командлета Get-Date создается объект времени и даты со значением 22.5.2006, 8:15. Почему для создания объекта времени и даты мы не используем командлет Get-Date в сценарии, который присваивает времени последнего сохранения текущие время и дату? Это просто: команда Date автоматически возвращает объект времени и даты. (Чтобы убедиться в этом, в консоли Windows PowerShell введите следующую команду: Date | Get-Member.)
После создания объекта времени и даты с необходимыми значениями мы воспользуемся уже знакомой командой Get-Item для получения объекта, представленного файлом Test.txt (объект, который сохранен в переменной $a). И, наконец, мы присваиваем свойству LastWriteTime значение переменной $b:
$a.LastWriteTime = $b
Хотите верьте, хотите нет, но это еще далеко не все. Взгляните на эту безобидную команду:
$b = Get-Date "5/22/2006 8:15 PM";
Get-ChildItem c:\scripts | ForEach-Object {$_.LastWriteTime = $b}
Что в ней такого интересного? Давайте посмотрим, что она делает. В первой части все просто: опять создается объект времени и даты со значениями 22.5.2006, 8:15. Однако заметьте, что во второй части вместо командлета Get-Item используется команда:
Get-ChildItem c:\scripts
В чем же смысл? Если применить командлет Get-ChildItem к каталогу, то он вернет набор всех файлов в этом каталоге. Мы получаем этот набор, и передаем все элементы этого набора по конвейеру (вот опять этот символ «|») на обработку командлету ForEach-Object.
А что сделает c этими файлами ForEach-Object? Конечно, он изменит свойство LastWriteTime каждого файла:
ForEach-Object {$_.LastWriteTime = $b}
Примечание Хотя эта статья и не является руководством для начинающих по Windows PowerShell, поясним, что символ $_ это особая переменная, которая представляет текущий элемент цикла For Each. Она эквивалентна objItem в следующем цикле в языке VBScript:
For Each objItem in colItems
    Wscript.Echo objItem.Name
Next
Когда наша команда Windows PowerShell завершит работу, все файлы в каталоге C:\Scripts будут иметь одинаковое значение времени последнего сохранения файлов. Хотелось бы посмотреть, как эти новые хитроумные кареты без лошади делают это!
Вариаций на тему этой команды предостаточно. Например, что если вам необходимо изменить время последнего сохранения txt-файлов в каталоге C:\Scripts? Хорошо, пожалуйста:
$b = Get-Date "5/22/2006 8:15 PM"; Get-ChildItem c:\scripts\*.txt | ForEach-Object {$_.LastWriteTime = $b}

Разжигаем аппетит
Все это очень здорово. Однако нужно сказать, что эта статья не преследует цель "продать" вам Windows PowerShell. Также, мы не призываем избавляться от VBScript-сценариев и переписывать их в Windows PowerShell. Если эти сценарии делают то, что они должны делать, оставьте их в покое. То же касается пакетных файлов, средств командной строки, разных магических формул и всего того, посредством чего вы управляете компьютерами. Помните? Если работает...
Смысл не в том, что Windows PowerShell позволяет делать то, что вы уже можете. А в том, что эта среда позволяет делать то, чего раньше вы делать не могли, и происходит это отчасти потому, что Windows PowerShell обеспечивает доступ к платформе .NET Framework. Изменение времени последнего сохранения файла (или группы файлов) это только один пример вышесказанного. Есть ли еще подобные примеры, зависит о того, что вы хотите сделать. Это те возможности, ради которых стоит изучить Windows PowerShell.
Для многих из вас, вероятно, это знакомство с Windows PowerShell было необычным: вместо того, чтобы начать с чего-нибудь вроде "Всем привет", мы сразу приступили к разбору составной команды Windows PowerShell, бросаясь такими словами как «конвейер» и «командлет», как будто все знают, что они означают. Это было сделано специально. В конце концов, многим из вас еще предстоит попробовать Windows PowerShell. Мы боялись, что если бы мы показали, как получить список служб на вашем компьютере, то вы бы просто пожали плечами и вернулись к своим делам.
Примечание: надеемся, что вы были не за рулем. Многим из нас довольно трудно пить из трех разных стаканов, смотреть кино на DVD и говорить по мобильному телефону, ведя машину, и при этом удержаться от "чтения Журнала TechNet".
Да ладно, мы ведь сказали «многие из нас». А не «все».

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


 В поисках безопасности: Развертывание инфраструктуры открытого ключа с глобальным доверием
В поисках безопасности
Развертывание инфраструктуры открытого ключа с глобальным доверием
Джон Морелло (John Morello)
Эта статья содержит предварительную информацию, которая может быть изменена.

Инфраструктура открытого ключа (PKI) является фундаментальным элементом при построении доверия между различными приложениями, операционными системами и идентификационными областями. PKI строится на основе иерархической модели доверия, где конечные субъекты доверяют общему ключу на высшем корневом уровне и, следовательно, все остальные ключи, подписанные этим корнем, становятся доверенными.
Благодаря этой структуре, правильно разработанную PKI можно легко расширить с помощью дополнительных центров сертификации (ЦС), не изменяя конечные субъекты.
PKI реализуются одним из следующих способов: самый распространенный подход £ по мере необходимости приобретать сертификаты у одного из безоговорочно доверенных поставщиков, например Cybertrust или VeriSign. Такие сертификаты, как правило, используются для обеспечения безопасности потоков данных на веб-узлах. Тем не менее они также применяются для шифрования в виртуальных частных сетях, для подписи сообщений электронной почты и других подобных задач. Эта технология позволяет свободно вывести отношения доверия за пределы организации, поскольку такие глобальные корни встроены в каждый современный веб-обозреватель. Внедрение такого метода в большой организации, однако, может оказаться дорогостоящим, так как сертификаты приобретаются только по мере необходимости.
В последнее время большее распространение получает модель внутренней PKI. Как следует из названия, внутренняя PKI обеспечивает доверие только внутри корпоративной сети. Эта модель дает компании более экономичный способ поддержки работы каждого пользователя и вычислительного устройства в сети с помощью сертификатов. Такой метод зачастую применяется с целью упростить работу при использовании таких технологий, как вход со смарт-картой, шифрованная файловая система (EFS) и защищенная беспроводная сеть. Недостатком же этого метода является то, что такие сертификаты не самым лучшим образом подходят для приложений с доступом за пределы сети, поскольку не обладают глобальным доверием. Поэтому большинство организаций, внедривших внутреннюю PKI, применяют комбинированный подход, приобретая для открытых приложений сертификаты одного из корней с глобальным доверием.
Как воспользоваться преимуществами обоих методов? А если ваша организация будет использовать собственную PKI: экономить средства, раздавая внутренние сертификаты и обеспечивая сертификаты с общим доверием, £ и все это из своей локальной системы? Такое решение дает преимущества внутренней PKI (как, например, интеграция службы каталогов Active Directory®, автоматическая подача заявок и локализованная IT-поддержка) и главное преимущество корневого сертификата с глобальным доверием. В университете штата Луизиана внедрена именно такая система. В этом выпуске будет подробно описана эта система, ее техническое решение и приведены практические рекомендации по развертыванию системы такого типа. Необходимо отметить, что данное решение было разработано, исходя из конкретных условий, продиктованных средой, ресурсами и бизнес-требованиями. Перед тем как определить оптимальный тип решения, необходимо учесть приведенные выше условия применительно к конкретной организации.

Реализация PKI в университете штата Луизиана
Университет штата Луизиана £ ведущий научно-исследовательский центр, начитывающий более 40 тыс. студентов, преподавателей и обслуживающего персонала. Он поддерживает много открытых веб-узлов, многие из которых требуют обеспечения безопасности транспортного уровня, это самое подходящее место для применения SSL-сертификатов. Раньше университет ежегодно тратил тысячи долларов на приобретение корневых сертификатов с глобальным доверием.
Недавно перед университетом встали новые задачи по обеспечению ИТ-безопасности, которые прекрасно решаются благодаря правильно построенной внутренней PKI. Задачи и требования в данной ситуации обычно ведут к выбору комбинированной модели. Но вместо этого мы решили поступить более оригинально.
Мы договорились с поставщиком корневых сертификатов с глобальным доверием Cybertrust о развертывании на оборудовании университета центра сертификации, подчиненного корневому ЦС Cybertrust (см. рис. 1). Cybertrust предоставляет данную услугу в рамках программы OmniRoot. По этому сценарию университет создает и эксплуатирует ЦС на собственном оборудовании. Тем не менее, в отличие от внутренней модели, описанной выше, ЦС университета не создает собственной подписи, а его ключ (а также подписи) обладает безоговорочным доверием для практически всех современных операционных систем и обозревателей. Технически такое решение является логическим расширением открытости стандартов x.509. Поскольку PKI создана на основе этих стандартов, становится возможным подключение систем, созданных разными разработчиками, к общей иерархии. Что действительно интересно в решении OmniRoot, так это условия применения этой услуги.
Рис. 1 Глобальный корневой сертификат Cybertrust
Рис. 1 Глобальный корневой сертификат Cybertrust (Щелкните изображение, чтобы уменьшить его)
Рис. 1 Глобальный корневой сертификат Cybertrust
Рис. 1 Глобальный корневой сертификат Cybertrust (Щелкните изображение, чтобы увеличить его)
Служба OmniRoot разработана специально для внедрения PKI с конфигурацией, которая использовалась в университете. В рамках программы OmniRoot организация платит Cybertrust фиксированный годовой взнос за участие в программе и за каждый открытый сертификат. Иными словами, университет может приобрести любое число внутренних сертификатов, не заботясь об их оплате. В последнее время открытые сертификаты стали значительно дешевле по сравнению с периодом, когда университет приобретал их по мере необходимости.
Итак, с технической точки зрения внутренние и открытые сертификаты идентичны. Они выдаются одной цепочкой ЦС, имеют одну стойкость шифрования и проходят через одну систему центров регистрации. Единственное различие £ это условия лицензирования.
В результате нам удалось расширить и усовершенствовать платформу информационной безопасности при меньших затратах. Это достижение стало мощным аргументом в пользу решения с применением PKI такого типа в университете. Теперь рассмотрим более подробно техническую сторону решения.

Иерархия PKI
Данная иерархия PKI представляет собой двухуровневую схему, в которой корневой уровень обслуживается компанией Cybertrust, а ЦС реализован на оборудовании университета (см. рис. 2). На корневом уровне формируется якорь доверия иерархии. Другими словами, отношения доверия всех сертификатов, выданных любым ЦС в иерархии, применяются к корневому ЦС (см. рис. 3). Таким образом, корневой ЦС объединяет все ЦС, сертификаты и конечные объекты в иерархии. Поскольку глобальный корневой сертификат Cybertrust встроен в операционную систему Windows® и практически в любую современную компьютерную систему, эта общая структура распространяется за пределы сети университета.
Figure 2 Двухуровневая иерархия PKI (Close Figure 2)

Корневой уровень (Cybertrust) | Уровень выдачи (университет)
Управляется Cybertrust | Управляется университетом
Находится в защищенном центре Cybertrust | Находится на территории университета в Бэтон Руж
Имеется в стандартном корневом сертификате почти всех современных вычислительных систем | Выдает сертификаты конечным объектам организаций университета
 | Сертификаты, выданные университетом, находятся на корневом уровне Cybertrust и поэтому обладают глобальным доверием
Рис. 3 Сертификат, выданный центром сертификации университета
Рис. 3 Сертификат, выданный центром сертификации университета (Щелкните изображение, чтобы уменьшить его)
Рис. 3 Сертификат, выданный центром сертификации университета
Рис. 3 Сертификат, выданный центром сертификации университета (Щелкните изображение, чтобы увеличить его)
Работа с корневым центром сертификации происходит на одном из защищенных узлов Cybertrust. На данных объектах используются мощные средства физической безопасности, включая шлюзовые кабины, биометрические замки и хранилища с особой степенью защиты, закрытые медными кожухами. Cybertrust выдает сертификаты только ЦС тех организаций, политики безопасности и сертификатов которых соответствуют установленным требованиям.
ЦС университета £ это система, работающая с конечными объектами и выдающая сертификаты пользователям и компьютерам университета. Сертификат ЦС университета подписан ЦС Cybertrust на более высоком уровне иерархии; сертификаты, выданные ЦС университета, поступают по цепочке через сам центр в корневой ЦС Cybertrust (см. Рис. 3).

Оборудование и операционная система для сертификации
ЦС университета построен на основе Windows Server® 2003 Enterprise Edition с пакетом обновления 1 (SP1). ЦС Windows Server 2003 предоставляет массу возможностей, включая архивацию ключа, разностные списки отзыва сертификатов и шаблоны "версии 2". ЦС на основе Windows применяется в соответствии со стандартными требованиями политики использования сервера Windows в университете. В системе установлены все необходимые обновления безопасности. Система управляется с помощью стандартных методов управления изменениями, набора программного обеспечения и средств обновления. Одним словом, несмотря на то, что существуют особые аспекты работы с ЦС, основное серверное оборудование и операционная система легко интегрируются в привычную информационную среду организации.
Кроме стандартных методов установки сервера, применяемых в университете, мы воспользовались преимуществами мастера настройки безопасности, который входит в Windows Server 2003 с пакетом обновления 1 (SP1). Мастер использует базу данных, содержащую матрицы зависимостей задач при работе сервера Windows и настроек безопасности, необходимых для выполнения таких задач. В этой базе данных содержится информация по двум основным ролям ЦС: службы ЦС и службы IIS, обеспечивающей работу PKI веб-узла с самообслуживанием.
С помощью мастера настройки безопасности нам легко удалось создать шаблон безопасности, который отключил все службы кроме необходимых для данных заданий, а также усилил защиту сетевого стека сервера. Затем с помощью программы scwcmd.exe мы преобразовали этот шаблон в объект групповой политики, чтобы применить его к серверу на уровне подразделений. Такой подход упрощает расширение и восстановление после аварии, так как ролевые настройки безопасности ЦС университета теперь хранятся в службе каталогов Active Directory, а не на конкретных компьютерах.
Центр сертификации университета работает на сервере IBM xSeries 346 с двумя процессорами Intel Xeon с частотой 3,2 ГГц, 4 ГБ ОЗУ и пятью жесткими SCSI-дисками емкостью 146 ГБ. При данных требованиях к производительности ЦС и учитывая, что в университете используется модуль безопасности оборудования, такая платформа должна обеспечить значительную долговечность и запас для расширения.
Мы воспользовались стандартными методами размещения баз данных и файлов журнала на разных физических дисках, создав два массива RAID 1. Пятый жесткий диск используется для горячего резервирования и доступен каждому массиву. Первый массив является системным томом, на котором хранится база данных ЦС. Второй массив используется для хранения файлов журнала и других файлов данных, например списков отзыва сертификатов. База данных ЦС построена на технологии Microsoft Jet, применяемой и в других местах в Windows, например в Active Directory. Поэтому в данном случае используются методы обслуживания и конфигурации дисков, применяемые в других решениях для хранения данных на основе технологии Jet.
Аппаратный модуль безопасности (АМБ) £ это специальное устройство, независимо управляемое из операционной системы. АМБ £ это, как правило, PCI-адаптер, но существуют также и отдельные сетевые устройства. Такие модули являются безопасным хранилищем ключей ЦС, а также имеют специальный шифровальный процессор для ускорения формирования подписи и шифрования. Windows работает с АМБ посредством интерфейсов CryptoAPI. С точки зрения операционной системы АМБ представляет собой устройство поставщика шифрования. В соответствии с требованиями OmniRoot для создания и хранения ключей могут использоваться АМБ, сертифицированные на соответствие федеральному стандарту обработки данных FIPS 140-2, уровень 3 (устройства уровня 4 довольно редки). Как уникальные и высоко безопасные устройства, АМБ требуют значительных капиталовложений; розничные цены на АМБ на основе PCI-адаптеров составляют 10-15 тыс. долларов.
Мы используем модуль nCipher nShield 500 TPS (модель на 500 транзакций в секунду) как непосредственно подключаемый АМБ. ("Непосредственно подключаемый" означает, что он находится внутри сервера и используется только этим сервером в отличие от отдельных сетевых АМБ, доступных нескольким компьютерам.) Этот АМБ сертифицирован в соответствии с FIPS 140-2, уровень 3 и осуществляет защиту ключей методом разделения мастер-ключей (K of N). АМБ гарантирует мощную защиту от несанкционированного доступа к закрытым ключам: злоумышленнику придется пробраться в память АМБ и захватить определенное количество маркеров доступа и PIN-кодов к ним.
Важно отметить, что АМБ предназначены для предотвращения доступа злоумышленников к их содержимому. Таким образом, АМБ строго ограничивает максимальное количество неудачных попыток входа в систему. В нашей системе данные удаляются из хранилища без возможности восстановления после десяти последовательных неудачных попыток входа.
Поскольку в системе используется только один центр сертификации, дополнительные расходы на внешний сетевой АМБ не оправданы. Тем не менее, если планируется использование ЦС, приобретение внешнего АМБ, используемого разными центрами сертификации, существенно сократит расходы. Данный метод также упрощает управление маркерами, поскольку память ключей может защищаться одним и тем же набором маркеров.

Active Directory и регистрация
Одно из преимуществ решения PKI на основе Windows заключается в том, что процесс сертификации не требует установки дополнительного программного обеспечения на объекты, являющиеся частью PKI. Сочетание автоматической подачи заявок и групповой политики делает автономную, не видимую конечному пользователю сертификацию более предпочтительной. В университете эта технология используется для автоматической выдачи сертификатов компьютерам-членам данной службы Active Directory. Кроме того, для обеспечения возможностей самостоятельного запроса сертификатов для узлов, не использующих Windows, мы используем специально настроенный веб-узел.
Как упоминалось ранее, в программе OmniRoot различаются открытые и внутренние сертификаты. Сертификаты считаются открытыми, если они используются системами или пользователями, не относящимися к университету (например, абитуриент, подавший заявление через веб-узел, защищенный SSL-протоколом). Сертификаты, используемые внутри университета (например применяемые для шифрования данных на серверах университета), считаются внутренними.
Необходимо вести учет приобретаемых открытых сертификатов, поскольку от их количества зависит стоимость программы OmniRoot. Чтобы различать открытые и внутренние сертификаты, используется шаблон: имя каждого публичного сертификата начинается с "PublicCertificate", а отображаемое имя £ с "Public Certificate". Например, TLS-шаблон сертификата нашего университета создан на основе стандартного шаблона Windows Web Server и называется Public Certificate LSU Web Server (открытый сертификат веб-сервера университета штата Луизиана). Для внутренних серверов имеется второй шаблон, Internal Certificate LSU Web Server (внутренний сертификат веб-сервера университета штата Луизиана). С технической точки зрения эти шаблоны одинаковы, различие в именах лишь упрощает учет.
При масштабной регистрации, например, регистрации целых отделов, когда используются сертификаты по протоколу IPSec, применяется автоматическая подача заявок. Это простое и чрезвычайно эффективное средство, встроенное в Windows. Администратору PKI достаточно изменить список управления доступом в шаблоне, давая право на автоматическую подачу заявок какой-либо нуждающейся в сертификатах группе пользователей или компьютеров. Затем эти объекты автоматически проверяют Active Directory, определяют шаблоны, к которым имеется автоматический доступ, находят ЦС, содержащие эти шаблоны, и автоматически подают заявку на сертификаты. Кроме того, функция автоматической подачи заявок обеспечивает замену сертификата в случае замены и автоматического обновления до истечения срока действия шаблона.
Для индивидуальных запросов, например сертификации веб-серверов, имеется веб-узел с самообслуживанием, где пользователи могут запросить сертификат через веб-обозреватель. Этот узел создан на основе страниц регистрации через Интернет, имеющихся в Windows Server 2003 (виртуальный каталог /certsrv): был создан стандартный для веб-узлов университета дизайн, а на странице запросов пользователю предлагаются стандартные варианты ввода. Кроме того, используется стандартный модуль выхода службы сертификации Windows, который автоматически отправляет сообщение по электронной почте группе администраторов PKI, если запрос, отправленный с этого узла, требует одобрения.

Отзыв сертификатов
Каждый сертификат имеет срок действия. Иногда возникает необходимость аннулировать тот или иной сертификат до окончания срока действия (например, сотруднику выдан сертификат, действительный до мая 2007 г., а он увольняется в январе). Такая операция реализуется посредством списков отзыва сертификатов (СОС), которые представляют собой список серийных номеров сертификатов, подписанных ЦС. Серийные номера в списках отзыва сертификатов указывают на сертификаты, срок действия которых не истек, но в доверии к которым отказано. Клиенты могут загружать эти списки и проверять действительность сертификатов.
Каждый сертификат x.509 v3 (кроме сертификата корневого ЦС) должен иметь указатель на действительный список отзыва сертификатов. Этот указатель называется точкой распространения СОС или ТРС. ТРС содержится в самом сертификате (см. рис. 4) и после выдачи сертификата изменению не подлежит. СОС являются главным средством для удостоверения действительности сертификатов, выданных ЦС. Поэтому мы обеспечиваем физическое резервирование СОС, их высокую доступность и простой доступ извне.
Рис. 4 Точка распространения СОС
Рис. 4 Точка распространения СОС (Щелкните изображение, чтобы уменьшить его)
Рис. 4 Точка распространения СОС
Рис. 4 Точка распространения СОС (Щелкните изображение, чтобы увеличить его)
ЦС сервера Windows, интегрированный с Active Directory (как в нашем университете), автоматически публикует СОС в Active Directory, благодаря чему он становится доступен по протоколу LDAP. Стандартное место публикации £ это контейнер ТРС (см. рис. 5), находящийся в контейнере службы открытых ключей леса. Это место публикации очень удобно, поскольку оно обеспечивает автоматическую репликацию, отказоустойчивость и локальность для поиска ТРС.
Рис. 5 Контейнер ТРС
Рис. 5 Контейнер ТРС (Щелкните изображение, чтобы уменьшить его)
Рис. 5 Контейнер ТРС
Рис. 5 Контейнер ТРС (Щелкните изображение, чтобы увеличить его)
Однако в нашем университете много работающих с PKI компьютеров, на которых установлены программные продукты, отличные от Windows и Active Directory. Университет £ крупная организация, большинство пользователей которой работают в университетской сети производительностью 10 Гбит/с, что сводит преимущества использования публикаций ТРС средствами Active Directory к минимуму.
Поэтому СОС публикуется только в HTTP, что позволяет упростить построение резервной платформы размещения (основной веб-узел уже имеет зеркало). Это также исключает возможные сложности, связанные с клиентским поиском по протоколу LDAP. СОС публикуется ежедневно, а разностные СОС публикуются каждый час.
Перспективы
Несмотря на то что настоящая PKI является надежным решением, обеспечивая безопасность университетского сообщества, мы планируем и дальше ее совершенствовать. Windows Vista™ и новая версия сервера Windows (кодовое название "Longhorn") предоставляют множество новых возможностей управления ключами, которые мы намерены исследовать. Нас особенно заинтересовали возможности клиента и респондента интерактивного протокола состояния сертификата (OCSP), поддержка эллиптической криптографии и алгоритмов SHA-256, а также значительно улучшенный интерфейс автоматической подачи заявок. Кроме того, в пакете обновления 3 (SP3) для Windows XP заявлена функция роуминга учетных данных, которая обеспечит безопасное перемещение пар ключей без затрат ресурсов, связанных с перемещением профилей. Наконец, с целью улучшения управления и отчетности мы исследуем применение диспетчера жизненного цикла сертификатов (на данный момент доступна бета-версия).
Таким образом, университетская PKI является мощной службой безопасности, необходимой для осуществления множества важнейших информационных функций. Программа Cybertrust OmniRoot позволяет использовать инфраструктуру открытого ключа, которая хорошо интегрируется с другими информационными системами университета, расширяя их глобальное доверие. Реализация решения на основе службы ЦС Windows обеспечивает эффективную сертификацию, управление, отличную интеграцию с существующим каталогом и систему управления идентификаторами. Словом, в университете штата Луизиана мечта о мощной защите и полном доверии средствами PKI уже становится реальностью.

Джон Морелло (John Morello) с отличием окончил университет штата Луизиана и в течение шести лет работал в корпорации Майкрософт в должности старшего консультанта консалтинговой службы, где он разрабатывал архитектуры открытого ключа для таких крупных клиентов, как Deloitte, General Electric и различных государственных организаций. Сейчас он является заместителем начальника управления информационной безопасности в университете штата Луизиана.


 Файлы рабочего стола: Формат образов Windows: взгляд изнутри
Файлы рабочего стола
Формат образов Windows: взгляд изнутри
Уэс Миллер (Wes Miller)
Эта статья основана на предварительных версиях средств развертывания Windows. Любая информация, содержащаяся в статье, может быть изменена.

С выходом Windows Vista способ установки и развертывания Windows претерпел значительные изменения. Механизм установки, а также весь набор средств развертывания для Windows Vista (так же как и для версии Windows Server с кодовым названием «Longhorn», которая должна скоро выйти) были переписаны. Я рассказывал об этих изменениях и о работе, которую
команда развертывания Windows® проделала для внесения этих изменений, в статьях последних выпусков журнала TechNet. Но обсуждение этой темы еще не закончено. Я буду рассказывать о Windows PE, об установке и развертывании Windows, а также обсуждать другие вопросы, касающиеся управления и безопасности Windows, в этой новой постоянной колонке.
В этом первом выпуске мы обсудим новый формат образов Windows (WIM). Если вы еще не знакомы с процедурой создания и развертывания образов, то можете получить общее представление о ней с помощью врезки "Типичный процесс использования образов". В следующей статье я познакомлю вас с пакетом автоматической установки Windows. Это новый набор инструментов, в который входит ImageX (средство командной строки для создания WIM-образов и управления ими) и службы развертывания Windows (WDS), которые приходят на смену службам удаленной установки (RIS). Я покажу, каким образом эти средства позволяют упростить установку ОС.

Поворотный пункт
Год за годом команда развертывания Windows слышала от изготовителей оборудования и корпоративных клиентов одни и те же пожелания. Они хотели получить улучшенную поддержку образов. Они хотели, чтобы корпорация Майкрософт разработала единые средства для работы с образами. Эти пользователи не желали решать задачу выбора стороннего производителя и изучения запутанных возможностей его продукта. Более того, эти изготовители оборудования и корпоративные клиенты часто были недовольны тем, что им приходится платить за средства работы с образами, используемые для развертывания Windows. Вместо этого они хотели бы, чтобы корпорация Майкрософт предоставила им такие средства.
В самом начале разработки Windows Vista™ команда развертывания Windows решила рискнуть. Мы решили полностью отказаться от всего механизма установки, многие компоненты которого просуществовали почти десять лет. Установка всегда была слабым звеном и состояла из слишком большого числа этапов. Мы собирались ускорить этот процесс, удалить лишние этапы и повысить надежность установки Windows в целом. Для этого требовалось изменить весь процесс установки, перейдя от механизма, требующего участия пользователя, который применялся довольно долгое время, к процессу установки, целиком основанному на образах.

Разработка нового формата образов
В самом начале процесса разработки нового механизма установки нам требовалось выбрать тип образа, который будет использоваться. Классический выбор предстояло сделать между сектором и файлом. А именно, мы должны были решить, будем ли мы использовать формат образов, который сохраняет копию тома по секторам, или формат, позволяющий хранить отдельно каждый файл. Преимущества, которые ожидает получить большинство людей £ это скорость (при использовании посекторного подхода) или сжатие (при использовании подхода на основе файлов). В конце концов мы остановились на формате, который, как мне кажется, представляет собой замечательный компромисс между этими двумя подходами. Он демонстрирует очень хорошую производительность, в то же время обеспечивая высокую степень сжатия.
Для начала мы определили несколько ключевых задач, решение которых позволило бы создать формат образов, отвечающий нуждам изготовителей оборудования и корпоративных пользователей. Для достижения поставленной цели больше подходила архитектура на основе файлов. Я думаю, нам всем были очевидны преимущества этого подхода, поэтому мы начали двигаться в этом направлении. Вскоре на свет появились WIM-файлы. (Если вам интересно, буква "M" в сокращении WIM ничего не обозначает. Сокращение WIM было выбрано в соответствии с событиями команды Windows, которые повторялись, как вехи. Кроме того, *.WI £ это все же очень странное сокращение.) Какие же задачи нам предстояло решить с помощью нового формата образов?
Независимость от формата файловой системы Windows Формат образов должен был работать с обеими архитектурами файловой системы, которые поддерживает система Windows. Хотя почти на всех компьютерах в процессе работы используется файловая система NTFS, многие изготовители оборудования и предприятия используют в качестве временной файловую систему FAT, поскольку она позволяет применять MS-DOS® для развертывания Windows. Преобразование в NTFS выполняется позже. Необходимо было сохранить поддержку обеих систем и для Windows Vista.
Независимость от геометрии тома Требовалось решить историческую задачу копирования большого тома и развертывания этой копии на том меньшего размера. Даже если средство для работы с образами может преодолеть эту трудность путем сложных манипуляций с разделами, этот способ ненадежен. В архитектуре на основе файлов для развертывания образа требуется столько места, сколько занимают составляющие этот образ файлы. Поскольку файловая система восстанавливается независимо, она никак не опирается на размер тома.
Типичный процесс использования образов
Когда изготовитель оборудования делает копии большого числа систем или крупной организации необходимо развернуть Windows на большом числе компьютеров, они обычно используют технологию образов. Идея состоит в том, чтобы взять эталонную систему, настроить ее в соответствии со своими нуждами, а затем скопировать на все остальные компьютеры. Для тех, кто не знаком с процессом использования образов, ниже приводится его краткое описание.
  1. Администратор устанавливает систему Windows на компьютер и настраивает ее в соответствии с собственными требованиями. Он может добавить или удалить компоненты, установить нужные приложения, настроить пользовательский интерфейс и другие параметры. Будем называть такой компьютер эталонным.
  2. Затем администратор запускает команду Sysprep (она поставляется корпорацией Майкрософт в составе средств развертывания Windows). При этом выполняется удаление всех атрибутов, которые отличают одну установку Windows от другой (таких как имя компьютера, идентификатор безопасности Windows (SID), а также другие уникальные идентификаторы системы). Эти атрибуты получат новые значения при выполнении второй части программы Sysprep.
  3. Затем администратор выключает компьютер и выполняет перезагрузку в Windows PE, MS-DOS или другую операционную систему, которая позволяет запустить приложение создания образа.
  4. Далее администратор запускает указанное средство и создает образ эталонной системы. Такой образ представляет собой файл (или набор файлов), который содержит точную копию эталонного диска или раздела.
  5. Компьютер выключается, и администратор сохраняет образ, который можно обновлять по мере необходимости (добавлять приложения, обновления и пакеты обновлений).
  6. Образ копируется на один или несколько компьютеров, после чего программа Sysprep завершает свою работу. Она запускается в составе сокращенной версии установки (которая называется Mini-Setup или Windows Welcome, в зависимости от того, в какой версии Windows работает программа Sysprep и как эта программа настроена). Этот этап опирается на небольшой исполняемый файл основного режима с именем setupcl.exe.

Независимость от архитектуры системы Архитектура образа должна работать с любой архитектурой, которую поддерживает система Windows. На тот момент это означало поддержку очень разных архитектур x86 и IA64 (Intel Itanium). Сегодня к этому списку добавилась архитектура x64 (AMD64 и EM64T).
Быстрота создания и развертывания образа Процесс создания образа должен быть достаточно быстрым при данной степени сжатия образа. Однако еще важнее, чтобы очень быстрым было развертывание образа.
Поддержка неразрушающего развертывания образа Поскольку нам требовалось заменить возможность обновления (которая заменяет ОС Windows, не повреждая данных пользователя и приложений), а также разработать инструмент, позволяющий выполнить восстановление системы, мы хотели, чтобы наше средство позволяло развернуть образ системы, не уничтожая ничего из того, что уже находится на томе. Форматы на основе секторов без значительной доработки не предоставляют пользователю такой возможности. В общем случае, можно восстановить том целиком или ничего вообще.
Поддержка значительной степени сжатия Когда разработка Windows Vista только начиналась, эту систему предполагалось распространять на компакт-диске. Поскольку размер образа Windows XP составляет почти 1 ГБ, было решено, что важно сжать образ настолько, насколько это возможно. Существует несколько приемов, чтобы добиться этого для образа на основе секторов, но детали такой реализации были для нас не важны. Многие форматы на основе секторов пропускают свободное пространство на диске для экономии места. (Зачем записывать 0 в образ, если он всегда остается нулем?) Однако при использовании подхода на основе файлов это получается само собой, поскольку свободное пространство не обрабатывается.
Поддержка копирования файлов в единственном экземпляре Эта задача имеет непосредственное отношение к предыдущей. Хорошо известно, что в Windows несколько копий одного и того же файла хранятся в нескольких разных местах. С помощью подхода на основе файлов легко сохранять только один экземпляр каждого файла и использовать его по мере необходимости.
Поддержка записи образа на несколько дисков Даже в самом начале работы над WIM, когда образ можно было записать на один компакт-диск, было понятно, что потребуется поддержка нескольких дисков. Даже если бы система Windows распространялась на одном компакт-диске, после добавления пользователями приложений, пакетов обновления и т.д. размер образа мог превысить размер одного компакт- или DVD-диска. Поэтому необходимо было предусмотреть возможность записи образа на несколько дисков, чтобы пользователи могли создавать собственные решения установки и восстановления.
Поддержка образов нескольких томов в одном большом двоичном файле Один образ редко годится для всего. При разработке "хранения одного экземпляра" мы также включили возможность копирования нескольких томов. Одна и та же степень сжатия и хранение одного экземпляра работают для каждого из этих томов. Таким образом, если создать образ Windows XP Professional, а затем добавить новый образ Windows XP Tablet PC Edition (который является надмножеством Windows XP Professional), в образ будут добавлены только те файлы, которые явно различаются в обеих версиях.
В результате изготовитель оборудования или корпоративный пользователь может объединить много производных образов без экспоненциального роста объема файла. Такой возможности нелегко было бы добиться в случае форматов на основе секторов.

Как работает WIM
Формат WIM разрабатывался с тем, чтобы сделать его настолько простым, насколько это возможно, в то же время не отступая от основных принципов. Подход на основе файлов позволил нам решить эту задачу. Но как именно все работает?
Если объяснять в двух словах, WIM-файл можно рассматривать как CAB-файл (который, в свою очередь, похож на формат ZIP, но корпорация Майкрософт разработала формат CAB и является его владельцем). На самом деле, я однажды слышал, как WIM называли "потомком CAB". Основное различие между WIM-файлом и CAB-файлом состоит в том, что в WIM-образе содержатся не только сжатые копии самих файлов, но и метаданные, которые относятся к файлам и каталогам, составляющим том в данном образе тома. То есть, файл образа представляет собой разновидность файла архива со всеми метаданными, с помощью которых том можно восстановить к состоянию на момент создания образа. При этом будут восстановлены списки контроля доступа (ACL), короткие и длинные имена файлов, атрибуты и т.д.
Обратите внимание, что при создании образа сведения о разделе (его размер или тип) не записываются. При развертывании образа создание разделов также не выполняется. В отличие от большинства средств работы с образами, программе ImageX, которая не зависит от разделов, для развертывания образа требуется, чтобы раздел был предварительно создан и отформатирован. Чтобы автоматизировать процесс до развертывания образа, необходимо воспользоваться средствами командной строки diskpart и format.
На содержимое образа тома не накладывается никаких ограничений. В образе могут содержаться два тома; один и тот же том, скопированный во вторник и в четверг; один образ с пакетом обновления и один без такового или что-нибудь еще, что может потребоваться. Главное, что нужно понимать £ это то, что одинаковые файлы будут записаны только один раз. Чем меньше таких файлов имеется в образах этих двух томов, тем больше места займут эти образы.
Следует также отметить, что формат WIM разработан с тем, чтобы его можно было применять и для более ранних версий Windows. Он будет работать с Windows 2000 не хуже, чем с Windows Vista. Теперь давайте более подробно рассмотрим, что же в точности происходит при создании и развертывании образов.

Создание образа
Создание образа тома состоит из следующих этапов.
Сбор метаданных тома Программа ImageX собирает данные об именах файлов, списках контроля доступа NTFS, а также о других атрибутах системы для данного тома. (Можно исключить некоторые файлы с помощью файла сценария.)
Сбор данных файла Программа ImageX загружает файл. Каждый файл, имеющийся на томе, загружается и подготавливается к сбору некоторых данных о нем.
Создание хэша файла Создается криптографический хэш файла на основании самого файла. Этот хэш становится уникальным идентификатором файлов в образе.
Пометка и удаление идентичных файлов Если другой файл с таким же хэшем уже имеется в образе, считается, что файлы одинаковы. Новый файл заменяется ссылкой на уже имеющийся файл.
Сжатие данных уникальных файлов В отличие от CAB и многих других форматов архивации, каждый файл в WIM-файле сжимается отдельно. В других форматах набор файлов группируется вместе как один поток данных. Кроме того, от сжатия можно отказаться. В этом случае данный этап пропускается.
Сжатие и сохранение метаданных тома После окончания архивации всех файлов создается запись метаданных для тома. Она представляет собой список файлов, добавленных в образ тома.
Создание и сохранение XML-данных образа Это ссылка на каждый созданный образ тома. Например, эти XML-данные отображаются при запуске команды ImageX /info.
Запись индекса кэшированных данных WIM И, наконец, записывается главный индекс данных (вместе с кэшированными данными). Это главная таблица файла для всего WIM-файла целиком, которая содержит по одной записи для каждого хэша.
Как можно видеть, WIM-образ создается на пофайловой основе. Более того, создается только один WIM-файл, независимо от числа томов, добавляемых в образ.

Перегрузка образа
Когда мы начинали работу над WIM, несколько других команд также занимались разработкой похожего решения. Команда служб автоматического развертывания разрабатывала решение для работы с образами, предназначенное для другого потребительского сегмента. Их подход имел несколько очень интересных деталей низкоуровневой реализации, но их механизм работы с образами, как и большинство подобных механизмов на тот момент, основывался на секторах. Команда Windows XP Embedded также разрабатывала механизм работы с образами на основе секторов. Он должен был позволить независимым поставщикам оборудования развертывать собственные образы при изготовлении компьютеров. Наконец, когда корпорация Майкрософт приобрела команду Virtual PC в 2003 году, эта команда принесла с собой другой формат файлов для файлов виртуального жесткого диска (VHD-файлов).
Все эти форматы были, по сути, ориентированы на секторы. Они отвечали нуждам своих потребительских сегментов, но эти решения не соответствовали принципам, определенным для WIM. В результате мы продолжили работу над новым форматом WIM и средством командной строки ImageX для создания образов. В итоге некоторые другие команды использовали наш формат задолго до того, как он увидел свет в составе предварительной версии Windows Vista. Команда SMS, например, включила раннюю реализацию WIM в свой пакет компонентов развертывания операционной системы.

Развертывание образа
Теперь давайте рассмотрим обратный процесс: развертывание образа.
Загрузка индекса кэшированных данных WIM Этот этап соответствует последнему этапу предыдущей процедуры. Поскольку это главный индекс, он должен быть первым загружен из WIM после того, как было указано, какой образ тома требуется развернуть.
Извлечение и загрузка метаданных образа Программа ImageX загружает метаданные, характерные для каждого образа тома.
Создание структуры каталогов Чтобы убедиться, что для каждого файла имеется расположение, в которое его следует восстановить, создается все дерево каталогов тома.
Извлечение данных файлов Файлы извлекаются из WIM точно в том же порядке, в котором они архивировались.
Развертывание данных файлов На этом этапе файлы загружаются, распаковываются (в том случае, если в WIM-файле использовалось сжатие образа тома) и копируются в каждое указанное размещение. Наконец, применяются все метаданные для каждого файла.
Развертывание метаданных всех каталогов Важно, что этот этап выполняется в последнюю очередь, поскольку в противном случае список контроля доступа для каталога мог бы помешать правильному развертыванию образа.

Гибкое сжатие
Одна из ключевых задач, которую требовалось решить при разработке формата образов WIM, это обеспечение гибких параметров сжатия. Поэтому мы включили возможность создания образа тома со сжатием, если это необходимо, однако возможность отказаться от сжатия тоже существует. Последний вариант подходит для сценариев, в которых сильное сжатие образа не требуется, или когда наиболее важна высокая скорость создания образа.
Имеется несколько основных принципов, которые нужно учитывать при выборе степени сжатия. Сжатие всегда занимает больше времени, чем распаковка. Чем более мощным является алгоритм сжатия, тем больше времени потребуется для сжатия одного и того же набора данных. И чем больше данных обрабатывает алгоритм сжатия, тем лучше они будут сжаты.
WIM-образы можно сжать с помощью алгоритмов XPress или LZX. Конечно, можно и совсем отказаться от сжатия. XPress £ это хороший компромисс в том случае, если требуется некоторое сжатие, но на создание образа нежелательно тратить слишком много времени. Механизм LZX обеспечивает оптимальную степень сжатия, но, как можно догадаться, этот метод требует значительно больше времени.
Если сжатие не используется, скорость создания образа максимальна, но при этом образ занимает больше всего места. Тип сжатия £ это параметр, который задается для всего WIM-файла в целом. После того, как один образ тома добавлен в WIM, все будущие образы томов должны создаваться с тем же параметром сжатия.
Обратите внимание, что, поскольку WIM-образы создаются на пофайловой основе, сжатие не является настолько полным, насколько могло бы. Это было осознанное решение, принятое, чтобы упростить изменение образа. Возможность изменения образов после их создания очень важна. Для файла, который следует изменить после создания образа, данные файла и его метаданные должны быть заменены. Если бы весь WIM-образ сжимался как единое целое, было бы очень сложно (если вообще возможно) обеспечить поддержку изменения файлов, и замена файла в образе требовала бы значительного времени. Избранный нами компромисс позволил создать формат с возможностью как сжатия образа, так и его изменения с помощью наших средств.
Я надеюсь, вы получили хорошее представление об использовании образов в Windows Vista. В следующей статье я расскажу о некоторых средствах, которые можно использовать для управления WIM-образами и их развертывания, уделив особое внимание ImageX и службам развертывания Windows.

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


 Конфиденциальная информация Windows: В ожидании RunOnce
Конфиденциальная информация Windows
В ожидании RunOnce
Рэймонд Чен (Raymond Chen)

ПРЕДСТАВИМ СЕБЕ установку, требующую перезапуска компьютера в середине процесса. Например, программе может потребоваться обновить системную DLL-библиотеку, используемую в данный момент. Для установки нового DLL-файла понадобится инициировать промежуточный перезапуск компьютера, чтобы затем использовать обновленную DLL-библиотеку на следующей стадии установки.
Раздел реестра RunOnce предназначен именно для этой цели £ использование программами установки для завершения установки после промежуточной перезагрузки. (Это было в те времена, когда считалось, что программы не могут принести никакого вреда.)
Windows® Explorer ожидает завершения работы программы, указанной в разделе RunOnce, перед созданием рабочего стола и панели задач. Это сделано, исходя из предположения о том, что RunOnce используется программами установки. Программа, указанная в разделе RunOnce, может изменять данные конфигурации системы, а работа пользователя в системе в процессе изменения конфигурации нежелательна.
Пусть, например, программа из раздела RunOnce выполняет перемещение и компоновку только что установленных файлов, при этом некоторые из них являются частью расширения оболочки. Ясно, что попытки пользователя запустить программу или активировать расширение во время продолжающегося обновления исполняемого файла совершенно нежелательны.
Другой подводный камень подхода к использованию раздела RunOnce как раздела «для программ установки» заключается в том, что указанная в этом разделе программа будет запущена только при входе в систему пользователя с правами администратора. Таким образом, пользователи, не являющиеся администраторами, не смогут выполнить установку. Кроме того, если бы программы, указанные в разделе RunOnce, запускались для пользователей, не являющихся администраторами, это уже не было «один раз» и привело бы к серьезным затруднениям. Как можно уведомить систему о том, что данная программа уже была запущена и запускать ее снова не нужно? Для изменения этого глобального состояния системы необходимы административные привилегии. Очевидно, что пользователь, не являющийся администратором, не обладает такими привилегиями. Программа перестала бы быть «запускаемой один раз»; вместо этого она стала бы «запускаемой снова и снова до входа в систему администратора».

(Щелкните изображение, чтобы уменьшить его)

(Щелкните изображение, чтобы увеличить его)
Раздел RunOnce, предназначенный для завершения установки программ, доступен самой программе установки Windows. При попытке установить пакет обновления или обновить операционную систему до новой версии Windows мастер установки проверяет значение раздела RunOnce. Если это значение не пустое, выдается сообщение об ошибке: «Обнаружена незавершенная установка программного обеспечения. Завершите установку перед обновлением операционной системы». Это справедливо, поскольку вряд ли кто-то захочет сменить операционную систему посреди установки программы.
Весь принцип работы раздела RunOnce выдает его прошлое. Этот раздел появился в Windows 95, операционной системе, не видящей разницы между администраторами и прочими пользователями. Поскольку в Windows 95 каждый пользователь фактически был администратором, программа установки, использующая раздел RunOnce, могла быть уверена в том, что действия, указанные в этом разделе, будут выполнены при следующей перезагрузке.
В более современных операционных системах Windows (особенно это касается Windows Vista™) возможна ситуация, когда за несколько месяцев в систему не войдет ни один пользователь с административными привилегиями. В результате программе, требующей выполнения RunOnce, придется ждать очень и очень долго.
В порядке отступления от темы: мне приходилось видеть «вечный RunOnce». Эта программа добавляла себя в раздел RunOnce при каждом запуске. Это явным образом противоречит предназначению раздела RunOnce, поскольку такие действия уже не являются частью установки программы, а являются частью ее обычной работы. Более того, такое поведение приводит к тому, что программа установки Windows всегда сообщает о наличии незавершенной установки.
Таким образом, пользователь никогда не сможет обновить операционную систему из-за того, что какая-то надоедливая программа постоянно говорит: «Я только хочу выполнить еще несколько мелких операций, и уж после этого обещаю закончить». Программа не завершит установку сегодня, но «завтра £ обязательно». Это в чем-то напоминает ожидание Годо, впрочем, будем надеяться, все обойдется без экзистенциального кризиса.

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