В прошлом году мы приняли давно назревшее решение об обновлении домена и Exchange на 2019. Работа очень объёмная, процесс длится уже больше года. Рассказываем, как мы готовили и настраивали сервера.

Статья вышла объёмная, так что разбили её на две части.

Содержание:

1. Введение

2. Подготовка и ввод новых контроллеров домена.

3. Upgrade «Свидетеля» — WITNESS и «Портала» — SRV

4. Подготовка Серверов Exchange 2019

   4.1. Установка Серверов

   4.2. Включить MAPI/HTTP. (Подробнее)

   4.3. Подготовить схему и AD

   4.4. Установка серверов 2019

   4.5. Autodiscover и настройка SCP (Service Connection Point) на серверах на EX01 и EX02

5. Настройка Серверов Exchange 2019

   5.1. Общие настройки

   5.2. Настроить коннекторы приема

   5.3. Настройка сертификатов

   5.4. Настройка сертификатов для POP\IMAP

   5.5. Настройка сертификатов для коннектора приема

   5.6. Настройка виртуальных каталогов

   5.7. Проверка работы почтовых протоколов\виртуальных каталогов

   5.8. Проверка клиентов Outlook

   5.9. Проверка внешних клиентов

   5.10. Устанавливаем SCP и DNS для EX01 и EX02

Часть 2 (Миграция почтовых ящиков, Удаление серверов Exchange 2013 – EX1 и EX2, Обновление пограничных серверов EDGE)

В Cloud4Y все сервера Windows Server 2013 R2. Exchange версия 2013 CU23 Mar23SU. Есть пограничные сервера EDGE1 и EDGE2. И еще есть Web-портал для клиентов - SRV.

Текущая и планируемая конфигурация:

Как видно из таблицы большинство новых серверов, включая новые контроллеры домена, получат IP-адреса старых серверов. Сделано это, чтобы не переписывать маршруты на маршрутизаторах, фаерволах, сервисах и документации.

2. Подготовка и ввод новых контроллеров домена.

Разворачиваем два новых сервера 2019 с ролями AD и DNS. Устанавливаем все обновления. И повышаем до уровня Domain Controller.

Контроллеры домена DC-01 и DC-02 изначально поднимаем с новыми IP-адресами. После нужно убедится, что они работают без ошибок:

• dcdiag.exe /s:<КД> и dcdiag /s:<КД> /test:dns /v

• repadmin /replsummary

• nslookup\Resolve-DnsName(PowerShell)

• указать вручную у одиночного клиента IP DNS на IP DC-01\DC-02

Далее передаем FSMO-роли. Всего их пять:

Чтобы не перегружать статью, где это возможно, буду давать ссылки: Передача/захват ролей FSMO на другой контроллер домена Active Directory

Далее поднимаем уровень домена (оснастка «Active Directory Users and Computers») и леса (оснастка «Active Directory Domains and Trusts»).

Теперь можно выключить старые контроллеры домена DC1 и DC2  и понаблюдать. Если будут ошибки, включаем — разбираемся.

Далее нужно вывести старые контроллеры DC1 и DC2  по одному. Закончили работы с одним, переходим к следующему. Понижаем  до рядового сервера и выключаем.

Пора поменять IP-адреса DC-01 и DC-02 на x.y.2.2 и x.y.3.2. Подробней тут.

Выполняем команды:

3. Upgrade «Свидетеля» — WITNESS и «Портала» — SRV

На этих серверах просто сделали — «In‑Place Upgrade», то есть установку ОС 2019 поверх 2012 R2 с сохранением параметров и приложений. Предварительно было проведено тестирование с копией ВМ.

Также машины повторно были введены в домен, так как возникала ошибка авторизации доменных пользователей.

4. Подготовка Серверов Exchange 2019

1. Установка Серверов:

Разворачиваем два сервера Windows Server 2019 EX01 и EX02. Устанавливаем необходимые пакеты:

• NET Framework 4.8

• Visual C++ Redistributable Package for Visual Studio 2012

• Visual C++ Redistributable Package for Visual Studio 2013

• Unified Communications Managed API 4.0.

• IIS URL Rewrite Module

И необходимые компоненты(PowerShell):

Install-WindowsFeature Server-Media-Foundation, NET-Framework-45-Core, 
NET-Framework-45-ASPNET, NET-WCF-HTTP-Activation45, NET-WCF-Pipe-Activation45, 
NET-WCF-TCP-Activation45, NET-WCF-TCP-PortSharing45, RPC-over-HTTP-proxy, 
RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, 
RSAT-Clustering-PowerShell, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, 
Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, 
Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, 
Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, 
Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, 
Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, 
Web-WMI, Windows-Identity-Foundation, RSAT-ADDS

2. Включение MAPI/HTTP. (Подробнее)

Перед вводом новых серверов, было принято решение включить протокол «MAPI». Так как протокол не новый, проверенный временем, и к тому же с 31 октября  2017 в Exchange Online закончилась поддержка «RPC over HTTP».

Здесь страница поддержки протокола «MAPI», таблица ниже:

Есть три версии протоколаMAPI, пример Outlook Connection:

• Первая — «MAPI\RPC», другие названия: «RPC», «MAPI протокол», «Exchange RPC», «Outlook‑Exchange Transport Protocol». Ссылка;

• Вторая — «Outlook Anywhere» или «RPC over HTTP». Где тот же «MAPI\RPC» заворачивался в HTTP трафик;

• Третья — «MAPI over HTTP» или просто «MAPI», есть некоторая путаница с первой версией — «MAPI протокол». Так же Outlook Connection обозначает его как «HTTP». Представлен в Мае 2014. Впервые появился в Exchange 2013 SP1 и Outlook 2013 SP1.

Проверяем настройки виртуального каталога:

Get-MapiVirtualDirectory

И устанавливаем внутренний и внешний Url:

Set-MapiVirtualDirectory -InternalUrl DC-01.domen.ru -ExternalUrl mail.domen.ru

Set-MapiVirtualDirectory -InternalUrl DC-02.domen.ru -ExternalUrl mail.domen.ru

Включаем «MAPI over HTTP» и проверяем:

Set-OrganizationConfig -MapiHttpEnabled $true

Get-OrganizationConfig | fl *MAPI*

Проверяем:

Test-OutlookConnectivity -ProbeIdentity OutlookMapiHttpSelfTestProbeTest-MapiConnectivity

При подключении по «MAPI over HTTP» в Outlook Connection, в столбце «Protocol», должно быть «HTTP»:

3. Подготовить схему и AD:

Далее нужно расширить схему и подготовить Active Directory(AD) — Ваша учетная запись должна быть членом групп безопасности «Администраторы схемы» и «Администраторы предприятия».

Единственный поддерживаемый способ расширения схемы для Exchange — использовать Setup.exe с /PrepareSchema, /PrepareAD или автоматически с помощью мастера установки Exchange.

.\setup.exe /PrepareSchema IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF

.\setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF

4. Установка серверов 2019:

Далее просто устанавливаем Exchange 2019 на два сервера EX01 и EX02. При установке будет проведена проверка необходимых пакетов и компонентов, которые мы установили в пункте 5.1. Выбираем роль: «Mailbox role».

Установка простая, просто нажимаем «далее — далее». Перезагружаем сервера.

5. Autodiscover и настройка SCP (Service Connection Point) на серверах на EX01 и EX02:

SCP точка подключения создается для каждого CAS-сервера и хранится в AD. Соответственно внутренние клиенты получают ее из AD. Во внутренней сети клиенты Outlook для получения Autodiscover.xml используют SCP(только при неудаче, переходят к “не доменной логике”):

• Клиент пытается разрешить в DNS стандартные URL`ы службы AutoDiscover:
  https://<domen>/autodiscover/autodiscover.xml
  https://autodiscover.<domen>/autodiscover/autodiscover.xml

• Если по протоколу HTTPS стандартные URL`ы не отвечают, то осуществляется попытка выполнить метод GET на указанные выше URL`ы по протоколу HTTP. Этот метод применяется только для редиректа на HTTPS-сайт;

• В случае очередной неудачи, клиент пытается получить из DNS SRV-запись службы Autodiscover. SRV запись вида «_autodiscover._tcp.<domen>» может указывать на любой другой URL, например, тот, который используется для OWA, ActiveSync и т.п. (https://mail. <domen>/autodiscover/autodiscover.xml)

• Если все предыдущие попытки не увенчались успехом, то клиент пытается найти локальный XML-файл с настройками.

Подробнее, еще и еще.

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

Необходимо изменение имен SCP(временно) для новых серверов сразу после установки на имена серверов Exchange 2013.

Текущая конфигурация SCP на Exchange 2013:

Меняем SCP в Exchange 2019:

$exuri1 = (Get-ClientAccessServer ex1).AutoDiscoverServiceInternalUri.AbsoluteUri

$exuri2 =(Get-ClientAccessServer ex2).AutoDiscoverServiceInternalUri.AbsoluteUriSet-ClientAccessServer -Identity ex01 -AutodiscoverServiceInternalURI

$exur1Set-ClientAccessServer -Identity ex02 -AutodiscoverServiceInternalURI

$exur2

Теперь SCP EX01 и EX02 указывает на SCP Exchange 2013:

5. Настройка Серверов Exchange 2019

1. Общие настройки:

Проверяем текущую конфигурацию:

Делаем основные настройки:

• Активация: Set-ExchangeServer {Host-name} -ProductKey 12345-12345-12345-12345-12345

• Установка запуска служб POP3\IMAP — Авто, если нам требуется работать по POP3\IMAP.

• Создаем DAG — «D AG19» на новых серверах EX01 и EX02.
  Exchange не поддерживает DAG с разными версиями Exchange. Поэтому при обновлении, создаем новый DAG и мигрируем mailbox’ы из старого(DAG01) в новый (DAG19)

Проверяем текущую конфигурацию DAG:

DAG19 - использует модель «IP-less», на это указывает IP-адрес 255.255.255.255. То есть «IP-less DAG» не используется IP, CNO в Active Directory и AAP(Administrative Access Point) - управление такого кластера(DAG) только через PowerShell.

Чтобы  на старых серверах Exchange использовать административный портал(ECP) с поддержкой Exchange 2019 нужно к адресу добавить «?ExchClientVer=15.2».

Пример: https://localhost/ecp?ExchClientVer=15.2.

2. Настроить коннекторы приема:

По умолчанию при установке создается пять коннекторов приема: два «HubTransport» и три «FrontEnd». Подробнее. 

FrontEnd-коннектор принимают письма извне и передают их транспортной службе(Hub Transport Service). Для  того, чтобы наши новые сервера начали принимать и обрабатывать почту, нужно, чтобы конфигурация коннекторов на новых серверах совпадала с таковой на старых. Обычно конфигурацию коннекторов не меняют за  исключением коннекторов  «Default Frontend <ServerName>» и  «Client Frontend <ServerName>»(порты 25 и 587). Иногда создают дополнительные коннекторы.

Проверим текущую конфигурацию коннекторов для EX01:

Сравнение в табличном виде коннекторов «Default Frontend <ServerName>» и  «Client Frontend <ServerName>» на всех MBX\CAS-серверах:

Get-ReceiveConnector '*\Client Frontend*'  | Select * | OGV

Get-ReceiveConnector '*\Default Frontend*'  | Select * | OGV

Для установки параметра(ов) коннектора используем «Set-ReceiveConnector».

Те параметры которые отсутствуют или отличаются на новых серверах, устанавливаем в ECP(доступны не все параметры) или с  помощью командлета «Set-ReceiveConnector».

3. Настройка сертификатов:

Проверим текущую конфигурацию Сертификатов для EX1:

«CN=*.domen.ru» сертификат должен быть на всех CAS\MBX серверах. Остальные сертификат для каждого сервера могут иметь различные «отпечатки». Если сервер является челеном «IP-less DAG», то будет еще «CN=CLIUSR» сертификат.

Сертификаты берем с серверов Exchange 2013 -  EX1 или EX2. Сертификат экспортируем (с закрытым ключом) и импортируем(*.pfx) сертификат на новых серверах в «Personal\Certificates». Используем «Manage computer certificates» — «certlm.msc»

Привязываем в «IIS\Default Web Site» → «Bindings», все протоколы «HTTPS» на серверах EX01 и EX12:

Перезапускаем IIS на обоих серверах:

iisreset /noforce

4. Настройка сертификатов для POP\IMAP:

Проверяем текущую конфигурацию POP\IMAP для EX01:

Параметры  «X509CertificateName» и «ExternalConnectionSettings» не установлены..

Устанавливаем «X509CertificateName» и «ExternalConnectionSettings» для EX01:

Set-PopSettings  -Server EX01 -X509CertificateName mail.domen.ru -ExternalConnectionSettings 'mail.domen.ru:995:SSL'

Set-ImapSettings -Server EX01 -X509CertificateName mail.domen.ru -ExternalConnectionSettings 'mail.domen.ru:993:SSL'

Проверяем конфигурацию POP\IMAP для EX01:

Конфигурация должна совпадать на всех CAS\MBX серверах.

После установки перезапускаем службы: 

• MSExchangePop3

• MSExchangePop3BE

• MSExchangeImap4

• MSExchangeImap4BE

«X509CertificateName» указываем сертификат(домен\поддомен, на который распространяется действие нашего сертификата), который будет использоваться для шифрования соединения.

«ExternalConnectionSettings» — параметры подключения для внешних клиентов. В моем случае разрешен доступ только по защищенному(SSL) IMAP\POP.

Если у нас не «WildCard-сертификат», то сертификат, еще нужно назначить службе POP\IMAP в ECP или используя команду:

Enable-ExchangeCertificate -Server EX01 -Thumbprint XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX -Services POP,IMAP

5. Настройка сертификатов для коннектора приема

Если мы еще хотим установить сертификат(выданный доверенной третьей стороной) на коннектор приема, для шифрования входящего SMTP-соединения. Нужно установить параметр «TlsCertificateName» коннектор приема. Обычно этот коннектор использует 25 порт и называется «Default Frontend <ServerName>». По умолчанию параметр «TlsCertificateName» равен $null и используется самоподписанный сертификат.

Проверим текущую конфигурацию коннекторов «Default Frontend»:

Параметры  «TlsCertificateName»  не установлены..

Установим параметр  «TlsCertificateName» на EX01 или EX02:

$cert = Get-ExchangeCertificate -Thumbprint XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

$tlscertificatename = "<i>$($cert.Issuer)<s>$($cert.Subject)" 

Set-ReceiveConnector "EX01\Default Frontend EX01" -TlsCertificateName $tlscertificatename

Set-ReceiveConnector "EX02\Default Frontend EX02" -TlsCertificateName $tlscertificatename

Еще раз проверим текущую конфигурацию коннекторов «Default Frontend»:

6.Настройка виртуальных каталогов:

У нас есть несколько виртуальных каталогов, так как после установки Exchange Server они устанавливаются с параметрами по-умолчанию. Нужно проверить все виртуальные каталоги. Чаще всего изменить требуется только внешнюю ссылку(«External Url»). 

В таблице на примере сервера EX01 перечислены командлеты и внутренняя/внешняя ссылка на каталог, которая должна быть установлена:

Таблица командлетов настройки виртуальных каталогов в PowerShell на примере EX01.

Внешнюю ссылку(«External Url») можно настроить в ECP сразу на все виртуальные каталоги:

или использовать PowerShell если требуется более гибкая конфигурация виртуальных каталогов:

Get-OutlookAnyWhere | ft Server, External*, Internal* -AutoSize

Get-EcpVirtualDirectory | ft Server, External*, Internal* -AutoSize

Get-OwaVirtualDirectory | ft Server, External*, Internal* -AutoSize

Get-WebServicesVirtualDirectory | ft Server, External*, Internal* -AutoSize

Get-ActiveSyncVirtualDirectory | ft Server, External*, Internal* -AutoSize

Get-OabVirtualDirectory | ft Server, External*, Internal* -AutoSize

Get-OutlookAnyWhere | ft Server, External*, Internal* -AutoSize

Get-MapiVirtualDirectory | ft Server, External*, Internal* -AutoSize

Проверка и сравнение настроек виртуальных каталогов для всех CAS\MBX - серверов.

Проверка и сравнение настроек виртуального каталога OutlookAnyWhere для всех CAS\MBX - серверов.

 Установка виртуальных каталогов для EX01:

Set-OutlookAnywhere EX01 -InternalHostname ex01.domen.ru -ExternalHostname mail.domen.ru

Set-EcpVirtualDirectory -InternalURL https://ex01.domen.ru/ecp -ExternalURL https://mail.domen.ru/ecp

Set-OwaVirtualDirectory -InternalURL https://ex01.domen.ru/owa -ExternalURL https://mail.domen.ru/owa

Set-WebServicesVirtualDirectory -InternalURL https://ex01.domen.ru/EWS/Exchange.asmx -ExternalURL https://mail.domen.ru/EWS/Exchange.asmx

Set-ActiveSyncVirtualDirectory -InternalURL https://ex01.domen.ru/Microsoft-Server-ActiveSync -ExternalURL https://mail.domen.ru/Microsoft-Server-ActiveSync

Set-OabVirtualDirectory -InternalURL https://ex01.domen.ru/oab -ExternalURL https://mail.domen.ru/oab

Set-MapiVirtualDirectory -InternalURL https://ex01.domen.ru/mapi -ExternalURL https://mail.domen.ru/mapi

Также, можно использовать готовый скрипт «Get-ExchangeURL.ps1», «Config-ExchangeURL.ps1».

7. Проверка работы почтовых протоколов\виртуальных каталогов.

Для проверки можно использовать командлеты «TestConnectivity». Но в Exchange 2016\2019, Microsoft рекомендует использовать новый командлет «Invoke-MonitoringProbe». Помимо этого командлеты «TestConnectivity» нужно выполнять на том же сервере, где находится тестируемый почтовый ящик иначе результат завершится ошибкой, но работают они быстрее «Invoke-MonitoringProbe». Тестируемый почтовый ящик можно не указывать, но тогда используется почтовый ящик, созданный с помощью  «New-TestCasConnectivityUser.ps1».

 Исключение командлеты:

• «Test‑MAPIConnectivity» — нет привязки к тестируемому mailbox»у;

• «Test‑OutlookConnectivity» — это просто обертка «Invoke‑MonitoringProbe»;

• «Test‑OWAConnectivity» — Только Exchange 2010, устарел;

Перечень командлетов «TestConnectivity»:

#testing POP3

Invoke-MonitoringProbe EX01 POP\PopCTPProbe

Invoke-MonitoringProbe POP.Proxy\PopProxyTestProbe

Invoke-MonitoringProbe POP.Protocol\PopDeepTestProbe

Invoke-MonitoringProbe POP.Protocol\PopSelfTestProbe

#testing IMAP4

Invoke-MonitoringProbe IMAP\ImapCTPProbe

Invoke-MonitoringProbe IMAP.Proxy\ImapProxyTestProbe

Invoke-MonitoringProbe IMAP.Protocol\ImapDeepTestProbe

Invoke-MonitoringProbe IMAP.Protocol\ImapSelfTestProbe

#testing ActiveSync

Invoke-MonitoringProbe ActiveSync\ActiveSyncCTPProbe

Invoke-MonitoringProbe ActiveSync.Proxy\ActiveSyncProxyTestProbe

Invoke-MonitoringProbe ActiveSync.Protocol\ActiveSyncDeepTestProbe

Invoke-MonitoringProbe ActiveSync.Protocol\ActiveSyncSelfTestProbe

#testing EWS

Invoke-MonitoringProbe EWS.Proxy\EwsProxyTestProbe

#testing ECP

Invoke-MonitoringProbe ECP.Proxy\EcpProxyTestProbe

#testing OAB

Invoke-MonitoringProbe OAB.Proxy\OABProxyTestProbe

#testing OWA

Invoke-MonitoringProbe OWA.Proxy\OWAProxyTestProbe

Invoke-MonitoringProbe OWA.Protocol\OwaDeepTestProbe

Invoke-MonitoringProbe OWA.Protocol\OwaSelfTestProbe

Invoke-MonitoringProbe OWACalendar.Proxy\OWACalendarProxyTestProbe

#testing Autodiscover

Invoke-MonitoringProbe Autodiscover.Proxy\AutodiscoverProxyTestProbe

#testing RPC\MAPI

Invoke-MonitoringProbe Outlook.Proxy\OutlookProxyTestProbe

Invoke-MonitoringProbe Outlook.Protocol\OutlookRpcSelfTestProbe

Invoke-MonitoringProbe OutlookMapiHttp.Protocol\OutlookMapiHttpSelfTestProbe

8. Проверка клиентов Outlook:

После настройки коннекторов приема, сертификатор, виртуальных каталогов нужно убедится, что клиенты могут подключаться и получать\отправлять почту. Но, чтобы не нарушить работу других пользователей в случае ошибки, нужно направить тестируемого клиент на Exchange 2019. Для этого прописать в файле hosts клиента наши сервера EX01 или EX02:

192.168.2.3       mail.domen.ru        #ex01

#192.168.3.3       mail.domen.ru        #ex02

Нам нужно убедится, что оба сервера способны обрабатывать подключения пользователей и получение\отправку почты, поэтому сначала проверяем EX01, потом EX02.

Запускаем Outlook, делаем первичную настройку и проверяем различные протоколы подключения: POP3\IMAP4\MAPI.

После того как убедимся, что каждый и EX01, и EX02 обрабатывают подключения Outlook по всем протоколам, можем добавлять в DNS новые сервера и убрать старые.

Этот метод подходит для проверки, как внутренних, так и внешних клиентов. Соответственно при проверке внешних клиентов, новые сервера, также должны быть прописаны во внешнем DNS.

9. Проверка внешних клиентов:

Microsoft предоставляет инструмент для детального анализа TestConnectivity. TestConnectivity позволяет подробно анализировать все протоколы Exchange и дает детальный лог ошибок. Конечно к серверам Exchange должен быть доступ извне:

10. Устанавливаем SCP и DNS для EX01 и EX02.

Теперь нужно вернуть SCP для серверов Exchange 2019, измененный в пункте 5.5.

Меняем SCP в Exchange 2019:

Set-ClientAccessServer -Identity ex01 -AutodiscoverServiceInternalURI ex01.domen.ru

Set-ClientAccessServer -Identity ex02 -AutodiscoverServiceInternalURI ex02.domen.ru

Проверяем SCP:

В DNS, в альяс mail.domen.ru добавляем A-записи IP EX01 и EX02 и убираем ex1 и ex2. Если У Вас есть внешние клиенты, то же самое делаем во внешнем DNS. После это клиенты будут подключаться к Exchange 2019, но проксироваться будут на Exchange.2013. И в таком(смешанном) режиме мы можем находится довольно долго, пока не мигрируем все почтовые ящики в Exchange 2019.

Продолжение следует....

Читать Часть 2