Начинаем готовиться к Exchange 2007

Итак, Exchange Server 2007 уже появился на горизонте. Пользователи вовсю тестируют демоверсию, а Microsoft обещает выпустить окончательный вариант в начале 2007 года. Необходимость в этом программном обеспечении давно назрела, в нем много нового, поэтому следует заранее подготовиться к его внедрению и определить последовательность выполнения миграции. Многие считают, что не стоит торопиться с переходом и лучше подождать, пока не будут выявлены ошибки в новом продукте Microsoft. Однако даже те, кто будет ждать выхода первого пакета обновлений для Exchange 2007, все равно, скорее всего, перейдут на новую версию в конце 2007-го или в начале 2008 года.

Возможно, кто-то полагает, что у нас еще очень много времени, но, учитывая некоторые фундаментальные изменения в Exchange 2007 (например, переход исключительно на 64-разрядную платформу, причем только x64, поскольку Exchange 2007 не поддерживает IA64), имеет смысл начать планировать процесс миграции как можно раньше. И для подготовки к планированию необходимо сконцентрироваться на некоторых ключевых моментах проекта, отличиях 64-разрядного Exchange, оптимизации маршрутной топологии и использовании Windows PowerShell.

В поисках совершенства

Если вы будете анализировать свою инфраструктуру, размышляя, на чем лучше устанавливать Exchange 2003 или Exchange 2000, то сразу увидите, что Windows Server 2003 как нельзя лучше подходит для внедрения. Трудно определить понятие совершенства в таком разрезе, поскольку лучшие решения меняются с развитием программного обеспечения, а различные компании предъявляют разные требования. Многие утверждают, что разработчики Microsoft видят лучшее решение внедрения Exchange 2003, базируясь на собственном опыте внедрения этого продукта в компании. Но мало кто будет устанавливать такие большие почтовые кластеры Exchange, как те, что работают в центре обработки данных Microsoft в Редмонде. Не так много существует компаний, имеющих объединенные команды внедрения Windows и Exchange, которые можно вызвать в случае проблем с кластером. Каждый по-своему понимает, что есть совершенство, да и не каждый к нему стремится. Вместо того чтобы искать совершенное решение, лучше как можно больше учиться у других компаний и создавать собственные решения, учитывающие особенности конкретной среды.

Следует иметь в виду, что Microsoft упростила процедуру анализа и корректировки внедрения с помощью такой утилиты, как Exchange Server Best Practices Analyzer (ExBPA). Эту программу можно использовать для сравнения информации от одного или нескольких серверов с тем, что рекомендует Microsoft. Запуск ExBPA будет удачным началом внедрения, поскольку ExBPA выявит очевидные недостатки имеющейся системы и их можно будет учитывать для улучшения инфраструктуры. Но важно помнить, что любой администратор знает о своих серверах Exchange гораздо больше, чем автоматизированный инструмент, поэтому результаты работы ExBPA следует воспринимать как рекомендации, а не руководство к действию.

Для того чтобы иметь под рукой актуальный набор используемых правил ExBPA, рекомендую следить за сайтом Microsoft Exchange Analyzers. Microsoft, выпуская новые версии этого инструмента, помогает пользователям наилучшим образом подготовиться к Exchange 2007. ExBPA всегда предлагает обновить набор правил, поскольку от этого зависит качество анализа системы. Следовательно, можно предположить, что обновленный ExBPA сможет определить новые проблемы, которые необходимо решить, прежде чем начать переход на Exchange 2007.

Размышления о миграции

Убедившись, что имеющаяся среда Exchange стабильна, можно начать думать о переходе на Exchange четыре этапа: исследование, анализ, принятие решения и выполнение.

Исследование. Как много серверов Exchange используется и поддерживается в существующей инфраструктуре (с учетом серверов антиспама, антивирусов, серверов резервного копирования, DHCP, Global Catalog — GC, WINS)? Где эти серверы расположены и как много почтовых ящиков поддерживают? Есть ли предпосылки (например, сетевая доступность) для размещения серверов в других местах? Используются ли продукты, которые не поддерживаются в Exchange 2007?

Анализ. Требуется рассмотреть изменения в архитектуре Exchange 2007 и 64-разрядной версии Windows, которые могут улучшить или упростить существующую инфраструктуру. Например, можно собрать воедино на одном сервере набор функций маломощных серверов. Также необходимо рассмотреть основные функциональные моменты, о которых сообщает Microsoft относительно Exchange 2007, и определить, важны ли они для вас. Например, Exchange 2007 может похвастать лучшей интеграцией с возможностями контроля почты на предмет спама и вирусов. Следует определить, как это повлияет на имеющуюся систему.

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

Выполнение. Важный совет: не стоит сосредоточиваться только на Exchange. Сфокусироваться следует на общей картине, включающей все объекты миграции, которые необходимо координировать для успешного завершения процесса. Это серверы и системы хранения данных, обучение, программное обеспечение независимых разработчиков, группа поддержки, эксплуатационные процедуры и клиенты (включая их мобильные устройства).

Разбить большую задачу на последовательные модули — удачный метод реализации сложного проекта. Но, чтобы решить проблему, надо изучить изменения, появившиеся в Exchange 2007. Поэтому рассмотрим самые важные изменения, которые специалисты Microsoft сделали в текущем выпуске продукта.

64-разрядное аппаратное обеспечение

Самым существенным изменением в Exchange 2007 является перенос программного обеспечения на 64-разрядную платформу. Microsoft полагает, что перенос Exchange на 64-разрядную платформу предоставит лучшую масштабируемость в плане количества поддерживаемых почтовых ящиков на сервере, более тщательную обработку больших почтовых ящиков и сообщений и уменьшение требований к дорогим системам вводавывода в связи с широким использованием в Exchange кэша в расширенном диапазоне адресуемого пространства памяти. Этот переход также решит проблему фрагментации виртуальной памяти, которая присутствовала в больших организациях Exchange 2003 (особенно на кластеризованных серверах).

Именно поэтому необходимо устанавливать Windows 2003 (предпочтительно Release 2 — R2) и Exchange 2007 на 64-разрядном аппаратном обеспечении. Обновить существующие серверы Windows 2003 и Exchange 2003 до новой платформы будет нельзя, даже если это программное обеспечение работает на оборудовании с 64-разрядным процессором (например, AMD Opteron или Intel EMD64T). Microsoft не поддерживает технологию «обновление на месте», поскольку это в данном случае очень сложная задача и сначала придется установить новые серверы, развернуть на них Exchange 2007 и воспользоваться режимом переноса почтовых ящиков для миграции пользователей. Недостаток такого решения состоит в том, что требуется новое аппаратное обеспечение, но миграцию на Exchange 2007 можно выполнять с постепенной заменой оборудования, чтобы минимизировать стоимость перехода. В то же время специалисты Microsoft значительно расширили возможности процедуры Exchange Move Mailbox в Exchange 2007 для облегчения переноса почтовых ящиков между серверами, включая возможность использования сценариев PowerShell для автоматизации переносов.

Поскольку Exchange работает в определенной «экосистеме», которая включает различное программное обеспечение независимых фирм (например, антивирусы и продукты антиспама, программное обеспечение для резервного копирования, продукты для анализа журналов, системы управления, такие как HP Open-View), переход на 64-разрядную платформу затрагивает не только Windows и Exchange. Потребуется проверить все перечисленное программное обеспечение для поддержки Exchange 2007, поэтому рекомендуется связаться со службами технической поддержки используемых продуктов, чтобы определить, будет ли готов к модернизации каждый из них.

Windows и маршрутизация

До сих пор на сайтах Windows было удобно собирать рабочие станции в одном месте. С точки зрения Exchange администраторы должны были позаботиться только о наличии серверов GC в сайтах для поддержки серверов Exchange. Транспортная подсистема Exchange 2007 лишилась маршрутных групп, присутствовавших в Exchange 2003 и Exchange 2000. Вместо этого используются сайты Windows для построения маршрутизации SMTP. Сайты Windows определяют одну или более подсетей IP, поэтому имеет смысл при маршрутизации сообщений SMTP через сеть IP задействовать сайты в качестве топологии маршрутизации.

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

При проектировании дизайна сайтов вашего домена Active Directory (AD) не принималось во внимание, что Microsoft может использовать сайты в качестве основы для почтовой маршрутизации. А, возможно, проект AD и вовсе не составлялся вплоть до начала внедрения первого Windows 2000, поэтому сейчас подходящий момент, чтобы поднять старые документы и посмотреть на них свежим взглядом. Также надо будет проанализировать развитие сетевой инфраструктуры компании с момента миграции на AD, так как могли появиться высокоскоростные каналы и топология могла измениться от звезды к полносвязной петле. Важно убедиться не только в том, что репликация AD продолжает работать надежно, но и в том, что соединенные сайты эффективно обмениваются почтовыми сообщениями. Только сайты, которые содержат шлюзовые серверы — плацдармы Exchange 2007, будут участвовать в почтовой маршрутизации. Эти сайты также должны содержать по крайней мере один сервер GC для помощи серверу Exchange при выполнении маршрутизации, проверке почтового адреса, разрешении построенных на запросе списках рассылки, раскрытии списка рассылки и т. п.

Exchange 2007, использующий сайты AD для построения топологии маршрутов, не накладывает карту сайтов на топологию сети «один в один». Только сайты AD, имеющие сервер-плацдарм, участвуют в маршрутной топологии, так что это правило является отправной точкой для рассмотрения текущей топологии маршрутов Exchange 2003. Следует рассмотреть расположение сайтов AD и сопоставить их со структурой маршрутных групп Exchange 2003, чтобы выяснить, совместимы они или нет. Это сравнение позволит определить, надо ли внести какие-нибудь изменения, например включить в сайт AD сервер-плацдарм, чтобы сообщения могли следовать через него. Кроме того, нужно убедиться, что все серверы почтовых ящиков Exchange имеют доступ к серверам-плацдармам для маршрутизации сообщений. Проводя исследование, желательно максимально упростить маршрутную топологию: возможно, топология развивалась неэффективно с той поры, как были разработаны планы внедрения Exchange 2003 или Exchange 2000.

Помимо коренных изменений в топологии маршрутизации и замены маршрутных групп сайтами Windows, разработчики Microsoft использовали .NET Framework для написания транспортного движка Exchange 2007, чтобы упростить его и обеспечить ускоренную обработку сообщений. Побочный эффект заключается в том, что все, что было разработано для обработки транспортных потоков в Exchange 2003 или Exchange 2000, теперь функционировать не будет. Например, для соответствия законодательству некоторые финансовые компании разрабатывали программы, предотвращающие возможность обмена почтовыми сообщениями между различными подразделениями компании. Поскольку программная обработка таких событий требует нетривиального кодирования, весьма вероятно, что развитие этого модуля потребует значительных усилий. Разработчики Microsoft обещают, что Exchange 2007 будет более доступен для программирования, так как этот продукт базируется на платформе .NET Framework. Так что будем готовиться к развитию программных модулей, поскольку их требуется переписать заново для работы с Exchange 2007.

Привыкаем к Shell

PowerShell, ранее известный как Monad, — это мощный инструмент командной строки и интерфейс сценариев, который обеспечивает единое средство для автоматизации управления на платформе Windows. Microsoft воспользовалась случаем, чтобы ликвидировать беспорядок во множестве приложений API (не все из которых документированы), использовавшихся в предыдущих версиях Exchange для выполнения административных задач. Например, для серверов Exchange 2003 и Exchange 2000 применялся набор приложений API, обеспечивавший автоматизацию административных действий. В среде Exchange 2007 вместо старых приложений API будут использоваться только наборы команд — PowerShell cmdlets (труднопроизносимое слово cmdlets, command-lets, означает пакеты команд, предназначенные для выполнения определенных функций, таких как создание нового почтового ящика). Фактически Microsoft построила систему управления Exchange 2007, включая новую версию консоли Exchange System Manager (называемую Exchange 2007 Management Console), на сценариях PowerShell.

Не нужно ждать Exchange 2007, чтобы изучить PowerShell: для Windows 2003 он доступен и сегодня. Вы не сможете управлять серверами Exchange, но можете изучить, как создавать сценарии для выполнения реальных задач. Во время развертывания Exchange 2007 на сервере процедура установки добавит новые операции Power-Shell для управления сервером Exchange, и после этого можно будет просто пополнить свои знания в части команд управления Exchange.

Подготовка на других фронтах

Помимо программных продуктов, необходимых для поддержки Exchange, таких как антивирусы, следует включить в бюджет новые версии другого программного обеспечения, которое потребуется для внедрения Exchange 2007. Например, Microsoft выпускает Office 2007, который содержит новую версию Outlook. Необходимо протестировать Outlook 2007, чтобы понять, как это отразится на стоимости внедрения. Интересная особенность Outlook 2007 — возможность для клиента использовать предоставляемую сервером Exchange службу Web под названием AutoDiscovery, которая опрашивает AD для поиска сервера с пользовательским почтовым ящиком, что уменьшает вероятность возможных ошибок пользователя при настройке Outlook.

Многие компании рассматривают Microsoft SharePoint Portal Server как естественную замену общим папкам сервера Exchange. Microsoft планирует реализовать общие папки в версии, которая последует за Exchange 2007, возможно, через три или четыре года. В частности, косвенно на это указывает на то, что в Exchange 2007 Management Console нет возможности управлять общими папками. Управление ими осуществляется через PowerShell или сервер Exchange 2003. Поэтому необходимо выработать стратегию замены общих папок. Новая версия SharePoint, которая скоро появится, работает совместно с SQL Server, поддерживающим базы для SharePoint, так что следует учесть данный продукт в общем плане миграции. Возможно, многим приходилось внедрять Live Communication Server — его тоже надо иметь в виду при разработке плана миграции.

«Экосистема» Exchange — это уже не только продукт, служащий для доставки почтовых сообщений. Чтобы гарантировать, что все необходимые компоненты будут перенесены вместе, нужно проявить целостный подход к проекту перехода на Exchange 2007.

Обучение

Даже те, кто имеет 10-летний опыт работы с Exchange, быстро убедятся, что Exchange 2007 требует серьезного изучения. Информацию о PowerShell и его мощных возможностях написания сценариев можно свести в несколько таблиц, но такие процессы, как настройка 64-разрядной платформы, обеспечение маршрутизации через сайты Windows, сосуществование серверов Exchange разных поколений и координация обновлений в больших организациях, требуют детального изучения. Неплохо было бы установить бета-версию Exchange 2007 на нескольких серверах для изучения некоторых возможностей. Например, помощник планирования; эта функция давно уже должна была присутствовать в серверах Exchange.

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

Начиная с 1996 года Microsoft каждые несколько лет выпускает новые версии Exchange, поэтому выпуск очередной версии не станет неожиданностью. Но каждое обновление имеет свои трудности. Основными изменениями в Exchange 2007 являются переход на 64-разрядную платформу, изменение подсистемы маршрутизации и новые возможности использования сценариев и администрирования системы. Новая возможность передачи сообщений Unified Messaging (UM) также может быть полезна, она рассматривается во врезке «Общение посредством Exchange UM». Поскольку подготовка к модернизации системы на Exchange 2007 будет длительной, сейчас самый подходящий момент, чтобы начать этим заниматься.

Общение посредством Exchange UM

Разработчики Microsoft особенно гордятся системой Unified Messaging (UM), которая встроена в Exchange 2007. Компания надеется успешно конкурировать на рынке UM благодаря интеграции этой службы универсальных сообщений с Exchange и Outlook, в результате чего стоимость внедрения UM может быть снижена до 20 долл. за лицензию, что сделает ее более доступной по сравнению с другими решениями.

Microsoft и раньше достигала успеха путем снижения цен при выпуске новых продуктов на рынок. Возможно, лучшим примером будет SharePoint Portal Server, который Microsoft представила в 2001 году, сокрушив цены на портальные решения. Что-то подобное может произойти и с предложением Microsoft Exchange 2007 UM. Exchange 2007 UM обладает следующими возможностями.

• Архитектура базируется на Session Initiation Protocol (SIP), который позволяет UM подключаться к АТС, поддерживающим SIP, или к шлюзам, конвертирующим передачу Time Division Multiplexing (TDM) в SIP. Intel и AudioCodes в числе первых одобрили идею поддержки таких шлюзов.
• Речевой доступ к голосовой почте, электронная почта, календарь и контакты. Обычно Microsoft демонстрирует это на примере вызова пользователем своего календаря Exchange с сотового телефона по дороге на работу. Это довольно удобно — отменить какие-то встречи, разобраться с календарем, позвонить с помощью почтовых сообщений своей группе и сообщить, что задерживаетесь. Но Exchange UM изначально не поддерживает все языки для речевого ввода, и это ограничение влияет на продажи данной услуги за пределами США. Еще ограничить применение UM может то, что пользователи говорят с разной скоростью, поэтому к данному сервису надо привыкать и тестировать его.
• Прием факсов таким образом, чтобы они поступали прямо в пользовательские почтовые ящики.
• Уведомления о пропущенных звонках работают так, что, если звонок переадресовывается на голосовую почту, а вызывающий не оставляет сообщения, Exchange отправляет почтовое сообщение получателю с указанием времени и идентификатора звонившего. Если Exchange разрешит идентификатор в контактах, то будет предоставлено имя звонившего.
• Политики управления UM. Администраторы могут настроить такие параметры, как максимальная длина приветствия, минимальная длина пароля PIN, срок действия PIN до требования изменения и запреты международных вызовов.

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