Установка Exchange 2003/2007 в среде Exchange 2010

Вопрос: Можно ли установить Exchange 2003 или 2007 в чистой среде Exchange 2010?

Ответ: Если речь идет об изначальной (greenfield) среде Exchange 2010 (то есть организации Exchange, которая состоит исключительно из серверов Exchange 2010 и где никогда не устанавливались предыдущие версии Exchange), то ответ нет. Если был осуществлен переход от Exchange 2007 до Exchange 2010 и последний сервер Exchange 2007 уже выведен из работы, то ответ также отрицательный. В такой организации в дальнейшем не удастся установить Exchange 2007, так как она теперь считается чистой средой Exchange 2010.

В ситуации, когда планируется переход с Exchange 2003 на Exchange 2010 и лес Active Directory уже подготовлен средствами установщика Exchange 2010, вы также не сможете установить в организации сервер Exchange 2007. Впрочем, установщик предупредит вас об этом при установке первого сервера Exchange 2010 в чистой организации 2003 Exchange (см. рис. 1).

Увеличить

Рис. 1. Установщик предупреждает, что после подготовки организации для установки Exchange 2010 в ней нельзя будет установить Exchange 2007

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

Вопрос: В настоящее время мы используем Exchange 2007 в качестве системы обмена сообщениями в нашей корпоративной среде. Мы только что обновили ОС Windows XP на всех клиентских машинах до Windows 7 и столкнулись с проблемами при попытке установить средства управления (Management Tools) Exchange 2007 с пакетом обновления SP2 на обновленных клиентах под управлением Windows 7. Что мы упустили при установке средств управления Exchange 2007 на Windows 7?

Ответ: Поскольку Exchange Server 2007 разрабатывался, когда Windows 7 еще не было, работа средств управления Exchange 2007 в Windows 7 не поддерживается. Команда разработчиков Exchange сосредоточила свои усилия на сервере Exchange 2010, который, конечно же, поддерживает Windows 7.

К сожалению, разработка ПО всегда ограничена бюджетом и ресурсами, и разработчики Exchange были вынуждены принять такое решение о поддержке установки средств управления Exchange на Windows 7. Важным аргументом было то, что около 65% всех клиентов, использующих Exchange, все еще работают на Exchange 2003 и после официального выпуска Exchange, 2010 большинство клиентов не станет устанавливать Exchange 2007 и перейдет непосредственно к Exchange 2010.

Проблема решается установкой пакета обновления 3 (SP3) сервера Exchange 2007 на клиенты под управлением Windows 7. Вы все верно поняли. По многочисленным запросам клиентов разработчики Exchange решили во второй половине 2010 года выпустить Exchange 2007 SP3, где предусмотрена поддержка установки средства управления Exchange 2007 на компьютеры под управлением Windows 7 и Exchange 2007 — на серверы под управлением Windows Server 2008 R2. Подробнее о планах выпуска Exchange 2007 SP3 можно узнать здесь: http://msexchangeteam.com/archive/2009/11/30/453327.aspx.

Вопрос: В рамках подготовки к запланированной миграции с Exchange 2007 на Exchange 2010 я установил тестовую среду с двумя отдельными лесами Active Directory. В лесу-источнике размещена организация Exchange 2007, а в лесу-приемнике — организация Exchange 2010.

Помнится, что при перекрестной миграции из леса Exchange 2003 в лес Exchange 2007, целевая организация не требовала, чтобы учетные записи пользователей из Active Directory были предварительно перенесены в лес-приемник.

Попытка выполнить перенос почтовых ящиков из леса Exchange 2007 в организацию Exchange 2010 показала, что в Exchange 2010 перекрестный перенос выполняется как-то иначе, чем в Exchange 2007.

Не могли бы вы объяснить, как выполнять перенос почтовых ящиков между лесами, когда приемник — организация Exchange 2010?

Ответ: Вы верно предположили, что перенос почтовых ящиков в Exchange 2010 работает не так, как это было в Exchange 2007.

Командлет Move-Mailbox, служащий для миграции в Exchange 2007, не требовал в обязательном порядке, чтобы учетные записи переносились в лес-приемник до перемещения связанного почтового ящика. Move-Mailbox в Exchange 2007 проверяет наличие в лесу-приемнике учетных записей, у которых соответствуют адрес прокси (SMTP-адрес), параметр ObjectSID источника (masterAccountSID, objectSID и sidHistory) или legacyExchangeDN (адрес x500, заданный на объекте пользователя). Если соответствие обнаруживается, включается поддержка электронной почты у соответствующей учетной записи леса-приемника. В противном случае командлет создает отключенную учетную запись пользователя с почтовым ящиком.

В Exchange 2010 ситуация поменялась. Во-первых, командлет Move-Mailbox больше не применяется — он заменен совершенно новым командлетом New-Move Request , который, помимо прочего, обладает новыми приятными функциями. При переносе почтовых ящиков между лесами этот командлет ожидает найти корректного пользователя почты и пытается сопоставить учетные записи, используя атрибут msExchMailboxGUID. Он не пытается задействовать для этого перечисленные ранее атрибуты, как это делается в Exchange 2007. Это означает, что перед миграцией между лесами в Exchange 2010 нужно в лесу-приемнике создать пользователей почты.

Кстати, в отличие от с Exchange 2007, теперь можно выполнять перенос почтовых ящиков между лесами средствами Консоли управления Exchange 2010 (см. рис. 2). Надо только предварительно добавить организацию Exchange целевого леса в эту консоль.

Увеличить

Рис. 2. Новое окно переноса почтовых ящиков в Консоли управления Exchange 2010

Пользователей почты можно создать в организации-приемнике Exchange 2010 средствами сценария PrepareMoveRequest.ps1, описанного в Microsoft TechNet или используя Identity Lifecycle Management (ILM) 2007 FP1 (с последним пакетом исправления, который обеспечивает поддержку создания пользователей в Exchange 2010) или Forefront Identity Management (FIM 2010), который в настоящее время доступен как версия-кандидат, а полноценный выпуск планируется позже в первом квартале 2010 года.

Вопрос: В нашей организации недавно развернули Exchange 2007. У нас реализовано решение высокой доступности, состоящее из четырех серверов Exchange 2007 — на двух серверах установлены роли «транспортный сервер-концентратор» (Hub Transport) и «сервер клиентского доступа» (Client Access), а остальные используются как узлы серверов почтовых ящиков в CCR-кластере (continuous replication cluster — кластер непрерывной репликации). Первые два сервера Exchange 2007 объединены в NLB-кластер для обеспечения балансировки нагрузки и автоматического перехода при сбое входящих клиентских и SMTP-подключений. Решение работает отлично, но с выходом Exchange 2010 хотелось бы перейти на самую свежую версию Exchange-сервера. В нем есть не только несколько интересующих нас функций, но мы также слышали, что сможем сократить число Exchange-серверов до двух, нисколько не снизив уже имеющуюся высокую доступность.

Есть ли какие-то нюансы, о которых надо знать перед переходом к решению высокой доступности на основе двух серверов Exchange 2010?

Ответ: Все верно — для создания решения обмена сообщениями высокой доступности на основе Exchange 2007 с автоматическим переходом при сбое и без единственной точки отказа как на уровне оборудования, так и систем хранения, требуется четыре машины: два сервера с ролями «транспортный сервер-концентратор» и «сервер клиентского доступа» и два сервера, объединенных в CCR-кластер.

Транспортный сервер-концентратор обладает встроенной балансировкой нагрузки и переходом при сбое в рамках сайта, причем последнюю функцию можно продублировать, реализовав механизм циклического обслуживания DNS (DNS round-robin). В сервере клиентского доступа никаких механизмов балансировки нагрузки не предусмотрено, поэтому их обычно создают парой, объединенной в NLB-кластер, обеспечивающий балансировку нагрузки и автоматический переход при сбое входящих подключений клиентов и серверов в Интернете и других внешних сетях.

Эти две машины, действующие как узлы в CCR-кластере, могут выполнять роли активного и пассивного серверов почтовых ящиков, так что кластеризованный сервер почтовых ящиков (CMS) мог осуществлять переключение от узла к узлу. Наконец, можно выделить один из внешних серверов как сервер-свидетель файлового ресурса в CCR-кластере.

Как известно функциональность CCR (а также SCC, LCR и SCR) удалена из Exchange 2010. Вместо этого в Exchange 2010 появилась новая функциональность — группы доступности базы данных (Database Availability Groups, DAG). В ней применяется та же технология синхронизации, что и в CCR и SCR, но в DAG-группах много новых функций и их функциональность настолько расширена, что делает их значительно лучше, чем CCR и SCR. Интересная особенность Exchange 2010 заключается в том, что на сервере с ролью «сервер почтовых ящиков», присоединенной к DAG-группе, могут выполняться другие роли («транспортный сервер-концентратор», «сервер клиентского доступа» и «единая система обмена сообщениями»). Это означает, что больше не надо выделять две машины в качестве внешних серверов для ролей «транспортный сервер-концентратор» и «сервер клиентского доступа». Достаточно просто установить все необходимые роли Exchange 2010 на этих двух машинах и, вуаля, — у вас готово полностью дублированное решение обмена сообщениями на основе Exchange 2010. Хорошо, да не совсем. Звучит слишком хорошо, чтобы быть правдой, не так ли?

Видите ли, в DAG-группах задействуются некоторые функции компонента WFC ОС Windows (прежде всего пульс и база данных кластера), поэтому эти два сервера нельзя сконфигурировать как узлы NLB-кластера — нельзя на сервере одновременно задействовать WFC и NLB. Это не поддерживается, начиная с Windows NT 4.0, а причина — в возможности конфликта при совместном использовании оборудования между службой кластеризации и NLB (подробнее см. статью: http://support.microsoft.com/default.aspx?kbid=235305.

Это означает, что вам придется использовать внешнее устройство балансировки нагрузки и перехода при сбое, например аппаратное. Также не забудьте, что его нужно дублировать, то есть потребуется как минимум два таких устройства.

Хотя вы и используете WFC и DAG входит в выпуск Enterprise Edition, на самом деле вам не нужен выпуск Exchange 2010 Enterprise Edition, чтобы пользоваться DAG-группами. В отличие от CCR в Exchange 2007, DAG также включен в выпуск Standard Edition. Но имейте в виду, что в этом выпуске число баз данных не может превышать пяти (включая активные и пассивные копии базы данных).

Так как роли «транспортный сервер-концентратор» и «сервер клиентского доступа» устанавливаются на машине , являющейся также сервером почтовых ящиков и сервером-членом DAG, вы можете сэкономить на двух компьютерах и на стоимости двух лицензий для Windows 2008 и Exchange 2010 Standard Edition. Если в вашей среде нет внешнего устройства балансировки, можно воспользоваться виртуальным или приобрести аппаратное устройство балансировки нагрузки. Ясно, что также потребуется сервер, который будет выполнять роль свидетеля файлового ресурса. Это настоятельно рекомендуется, но нигде не сказано, что это обязательно должен быть Exchange-сервер — подойдет любой имеющийся в среде файловый сервер под управлением Windows 2003 или 2008.