Я вела курсы о переходе с версии 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
Как приложение 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
Пока все идет нормально. Заметьте, что стоимость по умолчанию соединителя группы маршрутизации, созданного в 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 Настройка соединителя группы маршрутизации
Рассмотрим перемещение группы маршрутизации «Лос-Анджелес восток» на Exchange 2007. Возникает ситуация, когда обеспечение маршрутизации немного усложняется. На рис. 4 показано, что сервер Exchange 2007 был установлен на сайте «Лос-Анджелес», вторая группа маршрутизации была отключена, но создание дополнительных соединителей группы маршрутизации не было выполнено.
Рис. 4 Установка Exchange 2007 на сайте «Лос-Анджелес».
Теперь при отправке сообщения с сервера Exchange 2007 сайта «Лос-Анджелес» на сервер Exchange 2003 группы маршрутизации «Лос-Анджелес запад» оно будет отправляться сначала к группе «Акапулько», далее к «Майами север», «Майями юг» и, наконец, к «Лос-Анджелес запад». Если сообщение отправляется с сервера Exchange 2003, расположенного в группе маршрутизации «Лос-Анджелес запад», на сервер Exchange 2007 узла «Лос-Анджелес», то оно будет отправляться начала к группе «Майями юг», далее к «Майами север», «Акапулько», и, наконец, обратно к узлу «Лос-Анджелес». Вот так-то.
Чтобы избежать подобной ситуации, необходимо добавить второй соединитель группы маршрутизации. На рис. 5 показано добавление соединителя группы маршрутизации от «Лос-Анджелес запад» к серверу Exchange 2007, расположенному на сайте «Лос-Анджелес». Примечание: если необходимо избежать избыточности соединителей групп маршрутизации, следует убедиться, что первый соединитель группы маршрутизации настроен в концентраторе Active Directory, имеющем надежное соединение.
Рис. 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
Тем не менее, существует еще одна проблема. Наличие островов состояний каналов на узлах «Редмонд» и «Ванкувер». Почтовые сообщения доставляются исправно, хотя и через «Майами», однако «Редмонд» и «Майами» не могут обмениваться извещениями об изменениях настроек состояния каналов. Для сохранения существующей таблицы маршрутизации необходимо настроить дополнительный соединитель группы маршрутизации между узлами «Редмонд» и «Ванкувер». Можно установить высокую цену этого соединителя группы маршрутизации, которая предотвратит его использование сервером 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, можно обеспечить четкость выполнения и отсутствие неполадок при выполнения данной задачи.