Миграция с Exchange 2010 на 2019. Часть 18. Переключение HTTP/HTTPS и SMTP траффика и миграция почтовых ящиков

В прошлый раз мы завершили настройку и предварительную подготовку серверов Exchange 2019. Наш следующий шаг – переключение HTTP/HTTPS и SMTP траффика. После этого мы будем выполнять миграцию наших почтовых ящиков.

Детали каждого из этих шагов будут приведены ниже.

Переключение SMTP траффика

Поговорим про SMTP траффик. Его можно разделить на две большие категории:

  1. Внутренний SMTP траффик.
  2. Внешний SMTP траффик.

Далее мы будем рассматривать внешний SMTP траффик и корректировать его параметры. По большому счету, по части внешнего SMTP траффика нас интересует два момента:

  1. Внешний исходящий траффик от наших клиентов, т.к. в процессе его маршрутизации используется коннектор отправки. На текущий момент там добавлены только два сервера – MBX03 и MBX04 (Exchange 2016).
  2. Внешний входящий траффик, т.к. он распределяется нашим балансировщиком между серверами MBX03 и MBX04 (Exchange 2016).

Приступим к настройке параметров внешнего SMTP траффика.

Важное предупреждение – весь процесс перенастройки маршрутизации SMTP может занять от 30 минут до пары часов, с учетом применения изменений и репликации Active Directory. Настоятельно рекомендую делать это в нерабочее время.

Корректировка параметров коннектора отправки

Для корректировки параметров коннектора отправки выполните следующие действия:

1. Открыть веб панель управления Exchange. В нашем случае это следующий адрес:

https://mail.itproblog.ru/ecp/

2. Перейти в раздел настройки коннектора отправки – “Mail Flow” – “Send Connectors”:

3. Открыть свойства коннектора и добавить сервера MBX05 и MBX06 и удалить сервера MBX03 и MBX04:

4. Подтвердить внесенные изменения.

Теперь наша почта должна отправляться через сервера Exchange 2016 и мы должны видеть примерно следующее в заголовках наших писем:

Delivered-To: pochta_roma@mail.ru
Return-path: <roman@itproblog.ru>
Received-SPF: pass (mx287.i.mail.ru: domain of itproblog.ru designates x.x.x.x as permitted sender) client-ip=x.x.x.x; envelope-from=roman@itproblog.ru; helo=MBX06.itproblog.ru;
Received: from [x.x.x.x] (port=33294 helo=MBX06.itproblog.ru)
	by mx287.i.mail.ru with esmtp (envelope-from <roman@itproblog.ru>)
	id 1ld742-00029Y-IT
	for pochta_roma@mail.ru; Sun, 02 May 2021 11:02:55 +0300
Received: from MBX03.itproblog.ru (10.10.10.162) by MBX06.itproblog.ru
 (10.10.10.168) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.2.858.5; Sun, 2 May 2021
 01:02:37 -0700
Received: from MBX04.itproblog.ru (10.10.10.163) by MBX03.itproblog.ru
 (10.10.10.162) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2242.4; Sun, 2 May
 2021 01:02:34 -0700
Received: from MBX04.itproblog.ru ([fe80::c03b:b006:232e:f4ac]) by
 MBX04.itproblog.ru ([fe80::c03b:b006:232e:f4ac%12]) with mapi id
 15.01.2242.008; Sun, 2 May 2021 01:02:34 -0700

Корректировка параметров балансировки SMTP траффика

Внешний SMTP траффик у нас приходит на наш балансировщик KEMP LoadMaster. Далее он балансируется на сервера MBX03 и MBX04. Нам необходимо удалить сервера Exchange 2016 из нашего виртуального сервиса для SMTP и добавить туда сервера Exchange 2016.

Выполним следующие шаги:

1. Запустить консоль управления нашим балансировщиком

https://10.10.10.150/

2. Перейти в раздел виртуальных сервисов и открыть виртуальный сервис “Exchange SMTP” для редактирования:

3. Удалим сервера Exchange 2016 из списка реальных серверов:

4. Добавим сервера Exchange 2019 в наш виртуальный сервис:

Переключение HTTP/HTTPS траффика

Переключение HTTP/HTTPS приходит на нашем балансировщике сетевой нагрузки KEMP LoadMaster. Он балансирует HTTP/HTTPS между серверами MBX03 и MBX04. Нам необходимо удалить сервера Exchange 2016 из нашего виртуального сервиса для переключение HTTP/HTTPS и добавить туда сервера Exchange 2019.

При аутентификации в веб сервисах (например, OWA или ECP) Exchange 2019 будет перенаправлять траффик на сервера Exchange 2016.

Подробнее про перенаправление (redirect) и проксирование (proxy) в Exchange 2016 можно ознакомится вот тут. Механизм проксирования и перенаправления для Exchange 2019 работает также как и для 2016 версии.

Что нам нужно:

1. Запустить консоль управления нашим балансировщиком

https://10.10.10.150/

2. Перейти в раздел виртуальных сервисов и открыть виртуальный сервис “ExchangeHTTPS” для редактирования:

3. Удалим сервера Exchange 2016 из списка реальных серверов:

4. Добавим сервера Exchange 2019 в наш виртуальный сервис:

Переключение HTTP/HTTPS траффика завершено.

Миграция почтовых ящиков

Теперь наша организация Exchange 2016 готова к началу миграции почтовых ящиков на почтовые базы Exchange 2019. Перед миграцией основной части почтовых ящиков нам необходимо перенести системные почтовые ящики и почтовый ящик учетной записи администратора системы Exchange.

Перенос системных почтовых ящиков

Под системными почтовыми ящиками мы будем подразумевать следующее:

  • Системные почтовые ящики Exchange 2016. Например, arbitration mailbox, monitoring mailbox.
  • Почтовый ящик администратора системы Exchange.

Итого нам необходимо перенести следующие системные почтовые ящики:

1. Почтовые ящики арбитрации:

Get-Mailbox -Arbitration

2. Почтовые ящики аудита:

Get-Mailbox -AuditLog

3. Почтовые ящики поиска:

Get-Mailbox DiscoverySearchMailbox* 

4. Почтовый ящик нашего администратора системы Exchange – roman@itproblog.ru.

Для переноса arbitration mailbox выполним следующий командлет в Exchange Management Shell на любом сервере Exchange 2019:

Get-Mailbox -Arbitration | New-MoveRequest -TargetDatabase DB05

Посмотреть статус миграции можно следующим командлетом:

Get-MoveRequest

Более детальную статистику можно посмотреть следующим командлетом:

Get-MoveRequest | Get-MoveRequestStatistics

Теперь перенесем почтовый ящик аудита:

Get-Mailbox -AuditLog | New-MoveRequest -TargetDatabase DB05

И перенесем почтовый ящик поиска:

Get-Mailbox DiscoverySearchMailbox* | New-MoveRequest -TargetDatabase DB05

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

Get-MoveRequest | Where status -eq "Completed" | Remove-MoveRequest

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

Для переноса почтового ящика администратора Exchange в почтовую базу Exchange 2019 выполним следующий командлет на сервере Exchange 2019:

Get-Mailbox -Identity roman | New-MoveRequest -TargetDatabase DB05

Статус и процент завершения можно проверить следующим командлетом:

Get-MoveRequest | Get-MoveRequestStatistics

После того, как процесс переноса будет завершен мы удалим запрос на перенос почтового ящика администратора Exchange следующим командлетом:

Get-MoveRequest | Where status -eq "Completed" | Remove-MoveRequest

Миграция почтовых ящиков пользователей

Для миграции почтовых ящиков пользователей мы можем использовать несколько способов:

  1. Миграция через веб-интерфейс управления.
  2. Миграция через командлеты PowerShell.

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

Миграция почтовых ящиков пользователей через веб-интерфейс управления

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

1. Перейти в веб-интерфейс администрирования:

https://mail.itproblog.ru/ecp/

2. Перейти в раздел “Recipients” – “Migration”:

3. Указать, что мы собираемся перенести почтовый ящик в другую почтовую базу:

4. Мы будем переносить пользователя u1:

5. Укажем имя для нашего пакета переноса ящиков и укажем, что мы будет переносить как оперативный почтовый ящик, так и архивный почтовый ящик:

6. По окончанию работ письмо будет отправлено на почтовый адрес пользователя roman и, когда пакет переноса дойдет до стадии финализации, работы по переносу продолжатся автоматически:

Отслеживать детальную информацию по процессу переноса и текущий статус мы можем в том же разделе “Recipients” – “Migration”:

Миграция через использование командлетов PowerShell

Мы можем запускать перенос почтовых ящиков через модуль Exchange для PowerShell.

Давайте перенесем наши оставшиеся почтовые ящики именно через PowerShell. Что нам нужно сделать:

1. Запустить модуль Exchange Management Shell на одном из серверов Exchange 2019.

2. В наших почтовых базах, которые расположены на серверах Exchange 2016 остались следующие почтовые ящики:

Get-Mailbox -Database DB03
Get-Mailbox -Database DB04

3. Для создания запросов на перенос этих почтовых ящиков выполним следующие командлеты:

Get-MailboxDatabase DB03 | Get-Mailbox | New-MoveRequest -TargetDatabase DB05
Get-MailboxDatabase DB04 | Get-Mailbox | New-MoveRequest -TargetDatabase DB06

4. Отслеживать статус и текущий процент завершения переноса почтовых ящиков можно следующим командлетом:

Get-MoveRequest | Get-MoveRequestStatistics

После успешного завершения миграции все запросы на перенос должны иметь статус “Completed”:

Перенос почтовых ящиков завершен.

Заключение

Мы рассмотрели заключительные шаги по переносу основной части рабочей нагрузки с Exchange 2016 на 2019 – почтовых ящиков. Предварительно мы выполнили переключение потока входящей и исходящей почты организации на сервера Exchange 2019.

Перенос почтовых ящиков мы можем выполнять как через графический интерфейс администрирования, так и через Exchange Management Shell.

Последний шаг, который на остается выполнить с серверами Exchange 2016 (и это будет самый последний шаг всей миграции с Exchange 2010 на Exchange 2019) – это вывести их из эксплуатации. Чем мы и займемся в следующей публикации.

Миграция с Exchange 2010 на 2019. Часть 18. Переключение HTTP/HTTPS и SMTP траффика и миграция почтовых ящиков: 2 комментария

    1. Добрый день! Да, концепция именно внутренней работы Exchange с общими папками сильно поменялась при переходе с Exchange 2010 на Exchange 2013. К тому же из коробки прям бесшовного процесса миграции общих папок не предлагается. Почему не рассматривалась миграция общих папок? Думаю, в первую очередь из-за того, что в тех миграциях, в которых я участвовал (даже миграции порядка 2-3 тысяч почтовых ящиков) общие папки либо не использовали совсем, либо от них отказывались в процессе миграции. Вот как-то не очень они прижились они в российских реалиях. Я не говорю, что их совсем не использую, но используют не так уж часто. Пожалуй, об отсутствии описания миграции общих папок я укажу в самой первой статье.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *