Обновление инфраструктуры до 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, но и среды службы каталогов Active Directory®. Возможно, пользователям будет приятно узнать, что Exchange 2007 уже не использует маршрутизацию с учетом состояния канала и топологию, основанную на группах маршрутизации и соединителях. Вместо этого, Exchange 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 в виде диаграмм. Учтите, что чем больше подробностей включено в предварительные планы, тем лучше будет весь проект.



Как приложение 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 отражается на топологии организации.



Пока все идет нормально. Заметьте, что стоимость по умолчанию соединителя группы маршрутизации, созданного в 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 соединители «Send» (отправить) и «Receive» (получить), чтобы заменить все соединители SMTP, которые были назначены на сервере Exchange 2003 для обработки маршрутов к внешним пространствам адресов SMTP.

На следующей диаграмме показано перемещение ресурсов из группы маршрутизации «Акапулько» на сервер Exchange 2007. Группу маршрутизации «Акапулько» теперь можно отключить, однако это означает необходимость назначить соединитель группы маршрутизации уже другой группе. На рис. 3 показан пример настройки соединителя группы маршрутизации к серверу-плацдарму группы маршрутизации «Майами север».



Рассмотрим перемещение группы маршрутизации «Лос-Анджелес восток» на Exchange 2007. Возникает ситуация, когда задача сохранения маршрутов намного усложняется. На рис. 4 показано, что сервер Exchange 2007 был установлен на узле «Лос-Анджелес», вторая группа маршрутизации была отключена, но создание дополнительных соединителей группы маршрутизации не было выполнено.



Теперь при отправке сообщения с сервера Exchange 2007 узла «Лос-Анджелес» на сервер Exchange 2003 группы маршрутизации «Лос-Анджелес запад», оно будет отправляться сначала к группе «Акапулько», далее к «Майами север», «Майями юг», и, наконец, к «Лос-Анджелес запад». Если сообщение отправляется с сервера Exchange 2003, расположенного в группе маршрутизации «Лос-Анджелес запад», на сервер Exchange 2007 узла «Лос-Анджелес», то оно будет отправляться начала к группе «Майями юг», далее к «Майами север», «Акапулько», и, наконец, обратно к узлу «Лос-Анджелес». Вот так-то.

Чтобы избежать подобной ситуации, необходимо добавить второй соединитель группы маршрутизации. На рис. 5 показано добавление соединителя группы маршрутизации от «Лос-Анджелес запад» к серверу Exchange 2007, расположенному на узле «Лос-Анджелес». Примечание: если необходимо избежать избыточности соединителей групп маршрутизации, следует убедиться, что первый соединитель группы маршрутизации настроен в концентраторе Active Directory, имеющем надежное соединение.



Это отражает проблему, которая может не быть очевидна на первый взгляд. Теперь существует несколько путей от группы маршрутизации Exchange 2007 и к ней. Поскольку группа маршрутизации Exchange 2007 не учитывает состояние канала, возникает возможность образования петли маршрутизации. Сервером Exchange 2003 может быть выбран альтернативный маршрут для обхода нефункционирующего соединителя, в то же время Exchange 2007 будет всегда выбирать маршрут с наиболее низкой стоимостью. Исключить возникновение данной проблемы можно путем ограничения количества несущественных извещений об обновлении состоянии канала, что предотвратит отправку извещений о неработающем соединителе, однако разрешит отправку извещений об изменении настроек. Это важно, поскольку серверы Exchange 2003 должны быть оповещены о новых соединителях групп маршрутизации, но они не должны выполнять расчет альтернативного маршрута. Конечный результат состоит в том, что серверы 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 Application Mode, режим приложения Active Directory).

После установки как минимум одного транспортного сервера-концентратора можно приступить к развертыванию пограничного транспортного сервера в периферийной сети и далее прописать пограничный транспортный сервер в узел Active Directory, где расположен транспортный сервер-концентратор. Служба EdgeSync на пограничном транспортном сервере-концентраторе скопирует в ADAM поднабор данных получателей, который содержится в Active Directory.

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

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

Дополнение:

Серверные роли Exchange Server 2007

Почтовый сервер (Mailbox Server) Роль «Почтовый сервер» обеспечивает хранение сообщений организации. В Exchange 2007 на каждом сервере может находиться до 50 хранилищ. Эти хранилища могут быть установлены как 50 отдельных групп хранилищ, а можно в одной группе хранилища создавать до 50 хранилищ. Роль «Почтовый сервер» является единственной ролью, которую можно устанавливать как кластер. Это означает, что при использовании кластеризации необходимо устанавливать почтовый сервер на отдельном компьютере.

Сервер клиентского доступа (Client Access) Роль «Сервер клиентского доступа» выполняет те же функции, что и внешний сервер. Она обеспечивает доступ к почтовым ящикам тем клиентам, которые обращаются к серверу Exchange, используя протоколы POP3, IMAP4, приложение Outlook® Web Access (OWA), технологию RPC по HTTPS (теперь известную под названием Outlook Anywhere), а также протокол Exchange ActiveSync®.

Транспортный сервер-концентратор (Hub Transport) Данная роль обеспечивает работу служб передачи сообщений SMTP и MAPI в организации, использующей Exchange. Все сообщения, получаемые или отправляемые пользователями организации, обрабатываются транспортным сервером-концентратором. Это хорошо тем, что все сообщения могут передаваться только в соответствии с правилами сервера или в соответствии со стратегиями регистрации, что обеспечивается работой агентов, размещенных в различных участках транспортной сети.

Сервер единой системы обмена сообщениями (Unified Messaging) Данная роль предоставляет речевой доступ к почтовому ящику. Она объединяется со шлюзом IP/VoIP и IP-АТС и обеспечивает доступ по телефонным линиям к сообщениям и элементам календаря, а также производит запись и преобразование голосовых ответов пользователя. Этой роли в Exchange раньше не было, поэтому ее взаимодействие с более ранними версиями Exchange невозможно.

Пограничный транспортный сервер (Edge Transport) Пограничный транспортный сервер обычно устанавливается в периферийной сети. Он обеспечивает передачу сообщений по протоколу SMTP между инфраструктурой Exchange и Интернетом, а также защиту от нежелательных сообщений и вирусов с помощью транспортных агентов. Теперь становится возможным использование единых правил на основе единой технологии как для сервера организации, так и пограничного сервера. Подобная модель беспрепятственного взаимодействия упрощает администрирование и обеспечивает легкость интегрирования пограничных серверов.

Автор: Кейт Фоллис (Kate Follis).

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