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

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

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

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

• Работа Outlook по MAPI – минус старые клиенты

• Подключение к серверу по TLS 1.2 – минус старые ОС

• Что-то ещё?

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

 Кому подробностей:

• Почтовый шлюз в виде кластера от известного вендора из верхнего правого угла 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 (в моём случае хватает и его, но M$ по этому случаю говорит "Your account needs to be a member of both the Schema Admins and Enterprise Admins security groups" )

• Выпуск сертификата для 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 и т.д.

  После завершения данных настроек мы получаем работающую инфраструктуру, где пользователи подключаются к почте как через новые, так и через старые сервера.

  

  Наступила рабочая неделя, пошли отлавливать косяки. Поскольку с конечными пользователями работают администраторы на филиалах, то первыми о сбоях сообщают им. Как ни странно, проблем почти нет. Начинаем менять DNS для переключения точек входа пользователей на новые сервера. И практически сразу находим несколько очень интересных кейсов:

• Пользователи с 2007 офисом не подключаются к новым серверам

• Пользователи под Windows 7 не подключаются к новым серверам

• Не работает OWA через новые сервера (после ввода кредов крутится сообщение owa still working on it)

  Начинаем решение по мере появления проблем:

• Администраторам ещё раз сообщаем – офис минимум 2010 с KB2899591

• Windows 7 – пока не очевидно, приписываем локальные hosts, указывающие на старые сервера

• OWA – проблема решилась путём простого поиска по запросу wap exchange 2019 still working on it. Как оказалось нужно было добавить вот такой ключик в реестре на WAP:
  HKLM\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

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

  

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

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