Миграция с Exchange 2003 на 2007: новая архитектура ролей и Outlook Anywhere наконец без боли

Exchange 2003 у клиента работал исправно. Четыре года без серьёзных аварий, почта ходит, Outlook подключается, резервная копия снимается каждую ночь. Казалось бы - зачем трогать. Но два обстоятельства сложились одновременно: заканчивается основной цикл поддержки Windows Server 2003, на котором стоит вся почтовая инфраструктура, и около тридцати человек работают удалённо через VPN, который в последние полгода превратился в постоянный источник жалоб. Соединение рвётся, Outlook зависает, народ вынужден перелогиниваться по три раза за утро.

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

Роли - это не просто маркетинг

В Exchange 2003 сервер - это монолит. Ставишь один экземпляр, он делает всё: принимает почту снаружи, маршрутизирует внутри, хранит ящики, отдаёт клиентам через MAPI. Можно было запустить несколько серверов и разнести нагрузку, но концептуально это всё равно были одинаковые узлы.

Exchange 2007 введёт четыре отдельные роли:

• Edge Transport - принимает почту из интернета, антиспам, антивирус на периметре. Работает вне домена Active Directory, в DMZ.
• Hub Transport - внутренняя маршрутизация и применение политик. Должен быть в каждом сайте AD с почтовыми ящиками.
• Client Access Server (CAS) - всё, что касается клиентских подключений: Outlook Anywhere, OWA, ActiveSync, POP3/IMAP.
• Mailbox - хранение ящиков и публичных папок.

На небольшой инфраструктуре это не значит, что нужно четыре физических сервера. Роли CAS, Hub Transport и Mailbox вполне живут на одной машине. Но понимать, что ты ставишь и зачем - надо. Потому что когда начинаешь разбираться с сертификатами, маршрутизацией или почему Outlook Anywhere не поднимается, именно эта граница между ролями объясняет происходящее.

Миграция без простоя - это реально, но с условиями

Клиент - около двухсот ящиков, один почтовый сервер, всё в одном офисе плюс удалёнщики. Exchange 2003 и 2007 умеют сосуществовать в одной организации - это основа для поэтапной миграции.

Поставили новый сервер Windows Server 2003 R2 x64 - Exchange 2007 требует 64-разрядную платформу, это первое, во что упираешься при планировании железа. На старом сервере 32-битная Windows - значит, новое железо обязательно.

Ввели новый сервер в организацию Exchange, поставили роли CAS+Hub Transport+Mailbox. Некоторое время оба сервера работали параллельно: старый 2003-й оставался как «мост» для клиентов, которые ещё не переехали. Перенос ящиков делали пачками по двадцать-тридцать штук через Move Mailbox, в нерабочее время. Пользователи замечали только то, что при следующем запуске Outlook профиль переспрашивал сервер.

Единственный некрасивый момент - публичные папки. Технология в Exchange 2007 формально присутствует, но ощущение, что её держат из обратной совместимости и особо не развивают. Клиент использовал публичные папки для общего календаря отдела. Оставили их на старом сервере до отдельного разговора о переносе на общие папки в почтовых ящиках или SharePoint.

Outlook Anywhere - вот ради чего стоило переходить

В Exchange 2003 удалённый доступ через RPC over HTTPS (то, что теперь называется Outlook Anywhere) работал технически, но настройка требовала аккуратности: сертификат, IIS, конкретные настройки RPC-прокси, клиентские профили. И всё равно часть Outlook-клиентов периодически отваливалась без очевидной причины.

В Exchange 2007 Outlook Anywhere - штатная функция CAS, включается одной командой в Exchange Management Shell, которая кстати теперь на PowerShell. SSL-сертификат от нормального удостоверяющего центра, правильное имя в Subject Alternative Names - и клиент подключается через HTTPS к CAS так же, как подключался бы в локальной сети через MAPI. Тридцать удалёнщиков подключили за один вечер, переписав профили Outlook. Утром жалоб не было. Ни одной.

Это было неожиданно приятно. Не потому что задача казалась невыполнимой - просто с Exchange 2003 каждый такой случай сопровождался как минимум одним нестандартным кейсом, который приходилось разбирать отдельно.

Что стоит учитывать при планировании

Несколько вещей, которые мы теперь прояснили для себя как обязательные пункты при следующих миграциях:

• 64-битное железо - не рекомендация, а требование. Если у клиента нет подходящего сервера, это отдельная статья бюджета.
• Сертификаты - Exchange 2007 завязан на них серьёзнее, чем предшественник. SAN-сертификат с нужными именами надо планировать заранее, а не разбираться с ним в процессе.
• PowerShell - Management Console есть, но значительная часть тонких настроек - только через Shell. Кто не дружит с командной строкой, почувствует разницу.
• Публичные папки - если клиент на них завязан, это отдельный разговор ещё до начала миграции.

Exchange 2007 сложнее в проектировании, чем 2003-й. Нужно понимать, какие роли куда ставить, как они взаимодействуют, какие сертификаты нужны на CAS. Зато то, что раньше требовало танцев с бубном - удалённый доступ, мобильный ActiveSync, веб-интерфейс - теперь настраивается предсказуемо и работает стабильно.

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