Сказ о том, как мы Exchange мигрировали

Kate · 16 Дек 2021

Нет ничего сложного в администрировании Windows инфраструктуры говорили они. Все эти ваши окошки и далее-далее, проприетарщина…

Ничего не предвещало каких-либо изменений. Обычный рабочий день. В один прекрасный день: конец года, бюджетирование, давайте уже переходить на актуальные версии Windows. Принимаем решение: будем обновлять наши домен контроллеры 2012R2 до 2019. Всё бы просто, поднял рядом, перенёс роли и живи припеваючи. Но те, кто работал с Windows знают, что всё обычно не так радужно и стоит учитывать все подводные камни.

Имея у себя Exchange и пачку других сервисов от M$ понимаешь, что нужно садиться и читать. Открывая странички рекомендаций, форумы и прочие интересности, становится ясно, что предстоит обновление Exchange 2013 до актуальных версий.

Поняв ограничения, которые накладывают новые версии:

Работа Outlook по MAPI – минус старые клиенты
Подключение к серверу по TLS 1.2 – минус старые ОС
Что-то ещё?

Начинаем планирование обновления Exchange c 2013 на 2019. Имея довольно простую архитектуру системы, начинаешь задумываться о том, как бы всё не сломать и что получится в итоге.

Первоначальная конфигурация Exchange
Кому подробностей:

Почтовый шлюз в виде кластера от известного вендора из верхнего правого угла magic quadrant gartner
CAS-ы без дополнительных балансировщиков. Простой DNS Round Robin
Почтовая база в DAG-е на паре MBX серверов
Пользователи подключаются к CAS-ам, с той лишь разницей, что для внешних подключений используется WAP на базе Server 2019.

Поскольку в Exchange 2019 роль CAS-а отдельно не существует, а является службой на сервере Exchange понимаем, что мы получим минус 2 севера (ура экономия). Решаем запускать процесс. Не будет излишним указать план, который получился в итоге:

Установка Windows Server 2019
Установка предварительного софта (.Net, Visual C++ и т.д.)
Получить права Enterprise Administrator
Выпуск сертификата для Exchange c именами новых серверов
Подготовка AD и схемы леса (изменится SCP) – здесь почта перестаёт работать на почтовых клиентах
Установка Exchange на новые сервера по далее-далее, выбираем роль почтового сервера, ставим инструменты управления
Настройка SCP, указывающую на старые сервера Exchange – здесь почта начинает работать на почтовых клиентах
Импорт сертификатов со старых серверов на новые, биндинг их для служб, перенастройка VirtualDirectory на новых серверах Exchange
Меняем на WAP для клиентов IP CAS на новые сервера
Устанавливаем SCP на новые сервера – по факту ящики будут хранится в старой базе, но точкой подключения станут новые сервера
Организация DAG из новых серверов
Создание нового пользователя в новой DAG. Тесты с новым пользователем, миграция между DAG-ами, проверка отказоустойчивости новой DAG
Подготовка и рассылка информационного письма о смене почтового сервера администраторам пользователей Exchange
Миграция всех служебных почтовых ящиков Exchange
Миграция нескольких рабочих пользователей в новую DAG. Определить время миграции 10 ящиков
Миграция всех в новую DAG группами по 10 почтовых ящиков
Удаляем Exchange со старых серверов, тушим VM

Разбиваем всё на этапы, подготавливаем скрипты для автоматизации процессов, согласовываем время простоя. Решено – установку проводим в субботу, а дальше разберёмся. На всё про всё закладываем месяц.

Приступаем к установке:

Windows Server 2019 (не буду повторять пост одного человека, как он LAMP устанавливал)
Устанавливаем требуемые компоненты
Не забываем сохранить текущую конфигурацию Exchange
Установка Exchange. Здесь действительно далее-далее. Получаем предупреждение о том, что будет изменена схема леса, как следствие меньше, чем 2019й Exchange больше не станет – далее. В консоли администрирования отрастают новые сервера, но у части пользователей (внутренних) ломается подключение к Exchange. Хотелось бы объяснить, что произошло.
Для понимающих можно пойти дальше, всё одно мы это пофиксим при правке биндингов. А интересующимся опишу порядок подключения почтового клиента (читай Outlook) к Exchange.
Сама процедура поиска сервера отличается в зависимости от версии Outlook, но если брать современные (2013+) происходит по следующим этапам:
Поиск сервера через Service Control Point (SCP)
Поиск сервера через DNS запись autodiscover
Поиск сервера через DNS SRV запись
Естественно, всё дело в том, что значение SCP изменилось, часть пользователей начало подключаться через новые Exchange сервера к почтовой базе, а там сертификтаты самоподписанные. Чтобы решить эту проблему экспортируем сертификат со старого сервера через браузер или через Shell при помощи командлета Export-ExchangeCertificate. В дальнейшем импортируем на новые сервера и настраиваем биндинг на нужные нам службы. Кроме всего прочего, задаём параметры VirtualDirectory для серверов. Можно править как в браузере, так и через Shell при помощи Get-OutlookAnywhere, Get-ClientAccessService, Get-OwaVirtualDirectory, Get-OabVirtualDirectory, Get-ECPVirtualDirectory и т.д.
После завершения данных настроек мы получаем работающую инфраструктуру, где пользователи подключаются к почте как через новые, так и через старые сервера.

Промежуточная конфигурация Exchange
Наступила рабочая неделя, пошли отлавливать косяки. Поскольку с конечными пользователями работают администраторы на филиалах, то первыми о сбоях сообщают им. Как ни странно, проблем почти нет. Начинаем менять DNS для переключения точек входа пользователей на новые сервера. И практически сразу находим несколько очень интересных кейсов:
Пользователи с 2007 офисом не подключаются к новым серверам
Пользователи под Windows 7 не подключаются к новым серверам
Не работает OWA через новые сервера (после ввода кредов крутится сообщение owa still working on it)
Начинаем решение по мере появления проблем:
Администраторам ещё раз сообщаем – офис минимум 2010 с KB2899591
Windows 7 – пока не очевидно, приписываем локальные hosts, указывающие на старые сервера
OWA – проблема решилась путём простого поиска по запросу wap exchange 2019 still working on it. Как оказалось нужно было добавить вот такой ключик в реестре на WAP:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp\EnableDefaultHttp2 Value: 0
Проблема с Windows 7 в качестве клиента решалась практически неделю, но оказалась в самом очевидном месте. После установки тестовой машины, и прогона кучи тестов было выяснено, что сервер отфутболивает попытки подключения, а Wireshark помог разобраться почему. Оказалось, что Exchange Server 2019 по умолчанию работается TLS 1.2, в то время как Windows 7 такое может только после патчей. Ставим на клиенты KB3140245 и Microsoft EasyFix 51044, удаляем старые записи в hosts файле – профит.
Следующим этапом будет разворачивание новой DAG. Мануалов миллион. Процедура выглядит следующим образом:
Берём базу на одном из новых серверов. Перемещаем её на отдельный диск с внятным названием. Используем Move-DatabasePath.
Создаём DAG. Используем New-DatabaseAvailabilityGroup, где в качестве свидетеля используем всё тот же север, который является свидетелем для старой DAG, но с другой папкой.
После создания DAG добавляем в неё новые сервера используя Add-DatabaseAvailabilityGroupServer, после чего добавляем копию базы данных на второй сервер через Add-MailboxDatabaseCopy.
Проверяем полученный результат: Get-MailboxDatabaseCopyStatus
По факту на данном этапе мы готовы к миграции. Начинаем тестирование, проверки отказоустойчивости и прочие полезные вещи. Не забываем начать добавить новые сервера в резервное копирование. Всё проходит успешно.
Мигрируем системные почтовые ящики:
Get-Mailbox -Arbitration -Server MBX1 | New-MoveRequest -TargetDatabase DB2
Запускаем миграцию. Ввиду того, что у нас лес с кучей доменов, а глобальный каталог растянут по всем контроллерам в лесу, то необходимо использовать конкретный домен контроллер, а через web данная операция невозможна. Выбираем десяток пользователей и идём в Shell.
New-MoveRequest -Identity User1 -DomainController domain.local -TargetDatabase DB2 -BadItemLimit 10
Get-MoveRequest -DomainController domain.local | Get-MoveRequestStatistics
Get-MoveRequest -DomainController domain.local -MoveStatus Completed | Remove-MoveRequest -DomainController domain.local
Мигрируем потихоньку пользователей, смотрим как оно идёт, периодически ловим сбои при миграции. Очень помогает интересный синтаксис.
Get-MoveRequest -DomainController domain.local -movestatus Failed | Get-moverequeststatistics | select DisplayName,SyncStage,Failure*,Message,PercentComplete,largeitemsencountered,baditemsencountered | ft -autosize
Возникла проблема с зависанием миграции. Всё что гуглилось, попадало под запрос Move Exchange mailbox FailedOther stops at 95%. И решение, которое никак не задокументировано, но работает
Get-MoveRequest -Identity User1 -DomainController domain.local | Set-MoveRequest -MoveOptions skipKnownCorruptions,skipFolderPromotedProperties -DomainController domain.local
Get-MoveRequest -Identity User1 -DomainController domain.local | Resume-MoveRequest -DomainController domain.local
У пользователя после миграции появились пустые папки, которые он раньше удалял, повторил операцию – всё продолжило работать.

Итоговоая конфигурация Exchange
Вот так прошёл наш переезд. В целом на всё про всё ушло 2 недели. Плюс неделя на подготовку. Из неучтённого – возникла проблема с календарями. Пользователи, находящиеся в старой базе Exchange, не видели календари пользователей в новой базе. Разбираться не стали, просто завершили миграцию и по окончании у всех всё заработало. По завершении миграции просто удалили Exchange со старых серверов через установку/удаление программ и потушили VM.
Из полезного. Изменился формат хранения индексов БД Exchange, они сейчас хранятся в самой БД, что обеспеченивает лучшее быстродействие (читай поиск), а также исчезает необходимость проверки данных индексов, поскольку используется другая ифраструктура. Увеличилась безоасность подключения клиентов, ввиду использования TLS 1.2. Появился интерфейс OWA оптимизированный для мобильных устрйоств.