Миграция с Exchange 2010 на 2019. Часть 11. Первоначальная настройка Exchange 2016 и создание группы высокой доступности

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

  1. Импорт и привязка сертификатов.
  2. Настройка служб автообнаружения.
  3. Настройка виртуальных директорий.
  4. Конфигурирование Outlook Anywhere.
  5. Переименование и перемещение почтовых баз.
  6. Создание группы высокой доступности.

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

Импорт и привязка сертификатов

Для корректной работы HTTPS сервисов и службы обнаружения нам необходим сертификат, который будет доверенным для наших клиентов Outlook. Потому что после установки Exchange привязывает к веб-сервисам самоподписанный сертификат и наши клиенты будут получать сообщение о том, что у них нет доверия к этому сертификату:

Вариант с использованием самоподписанного сертификата мы рассматривать не будем. В остальных случаях у вас будет два варианта:

  1. Купить коммерческий сертификат на год или более.
  2. Выпустить бесплатный сертификат от Let-s Encrypt на 3 месяца.
  3. Использовать сертификаты от внутреннго ЦС. Это может быть инфраструктура PKI на базе Windows Server, либо же другое решение. Однако, это накладывает определённые дополнительные трудозатраты. Как минимум нужно вручную импортировать сертификат корневого ЦС на мобильные клиенты при публикации сервисов наружу (десктопные/мобильные клиента, OWA и т.д.).

Поскольку мы уже выпускали бесплатный сертификат для нашего сервера Exchange 2010, то мы будем использовать его.

Предварительно либо экспортируйте этот сертификат с одного из серверов Exchange 2010, либо найдите исходный PFX файл с открытым и закрытым ключом.

Импорт сертификата на сервера клиентского доступа

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

1. Запустить MMC консоль управления сертификатами для локального компьютера на первом сервер Exchange 2016:

2. В контекстом меню персонального контейнера выбрать пункт для импорта сертификата:

3. Выполнить все шаги мастера импорта сертификатов.

4. Сертификат должен отобразиться в локальном хранилище сертификатов:

5. Выполнить импорт сертификата на все сервера клиентского доступа Exchange.

Привязка сертификата к сервисам Exchange

Импорт сертификата – это лишь половина дела. Далее их нужно указать – какие сервисы будут использовать наш сертификат:

1. Запустим Exchange Management Shell на первом сервере Exchange 2016 и посмотрим на список наших сертификатов:

Get-ExchangeCertificate | fl Subject,Services,Thumbprint

2. Находим необходимый нам сертификат и привязываем его ко всем сервисам:

Get-ExchangeCertificate -Thumbprint "5CEC8544D4743BC279E5FEA1679F79F5BD0C2B3A" | Enable-ExchangeCertificate -Services  IMAP, POP, IIS, SMTP

3. Перезапускаем сервер IIS:

iisreset

4. Выполняем аналогичные действия на втором сервере Exchange 2016.

Настройка службы автообнаружения

Теперь посмотрим, как выглядят настройки служб автообнаружения после добавления серверов Exchange 2016 в нашу организацию:

Get-ClientAccessService | fl identity, *uri*

Мы видим, что на серверах Exchange 2016 (MBX03 и MBX04) службы автообнаружения ведут не на имя, которое мы настроили ранее (mail.itproblog.ru), а на собственные имена серверов:

Напомню, что мы используем пространство имен mail.itproblog.ru.

Скорректируем имена службы автообнаружения:

Get-ClientAccessService -Identity MBX03 | Set-ClientAccessService -AutoDiscoverServiceInternalUri https://mail.itproblog.ru/Autodiscover/Autodiscover.xml

Get-ClientAccessService -Identity MBX04 | Set-ClientAccessService -AutoDiscoverServiceInternalUri https://mail.itproblog.ru/Autodiscover/Autodiscover.xml

Проверим теперь адреса служб автообнаружения для всех наших серверов Exchange:

Get-ClientAccessService | fl identity, *uri*

Теперь все имена настроены корректно, и мы перейдем к настройке виртуальных директорий.

Настройка виртуальных директорий

В Exchange 2016 у нас присутствуют следующие виртуальные директории:

  1. ActiveSync Virtual Directory. Виртуальная директория для протокола ActiveSync. В осносном это подключение мобильных устройств.
  2. MAPI Virtual Directory. Эта виртуальная директория появилась в Exchange 2013 SP1. Используется современными клиентами Outlook (начиная с Outlook 2013 SP1) для подключения к почтовым ящикам через MAPI/HTTP. Этот метод подключения пришел на замену RPC over HTTP.
  3. Autodiscover Virtual Directory. Предназначена для сервиса автоматического конфигурирования внутренних клиентов.
  4. Ecp Virtual Directory. Виртуальная директория веб-консоли управления.
  5. Oab Virtual Directory. Предназначения для хранения файлов оффлайн адресной книги.
  6. Owa Virtual Directory. Виртуальная директории веб версии Outlook.
  7. PowerShell Virtual Directory. Виртуальная директория веб-версии PowerShell.
  8. WebServices Virtual Directory. Виртуальная директория веб-сервисов Exchange.

У каждой из виртуальных директория (за исключением виртуальной службы автообнаружения) в настройках необходимо указать URL адрес, который будут использовать внутренние клиенты и URL адрес, который будут использовать внешние клиенты. Этот URL адрес, может быть одинаковый как для внутренних клиентов, так и для внешних клиентов. В нашем случае будет именно так.

Как было сказано выше, мы будем использовать URL вида https://mail.itproblog.ru.

Выполним настройку виртуальной директории для ActiveSync:

Get-ActiveSyncVirtualDirectory -Server MBX03 | Set-ActiveSyncVirtualDirectory -InternalUrl "https://mail.itproblog.ru/Microsoft-Server-ActiveSync" -ExternalUrl "https://mail.itproblog.ru/Microsoft-Server-ActiveSync"

Get-ActiveSyncVirtualDirectory -Server MBX04 | Set-ActiveSyncVirtualDirectory -InternalUrl "https://mail.itproblog.ru/Microsoft-Server-ActiveSync" -ExternalUrl "https://mail.itproblog.ru/Microsoft-Server-ActiveSync"

Выполним настройку виртуальной директории для MAPI:

Get-MapiVirtualDirectory -Server MBX03 | Set-MapiVirtualDirectory -InternalUrl "https://mail.itproblog.ru/mapi" -ExternalUrl "https://mail.itproblog.ru/mapi"

Get-MapiVirtualDirectory -Server MBX04 | Set-MapiVirtualDirectory -InternalUrl "https://mail.itproblog.ru/mapi" -ExternalUrl "https://mail.itproblog.ru/mapi"

Настроим виртуальную директорию ECP:

Get-EcpVirtualDirectory -Server MBX03 | Set-EcpVirtualDirectory -InternalUrl "https://mail.itproblog.ru/ecp" -ExternalUrl "https://mail.itproblog.ru/ecp"

Get-EcpVirtualDirectory -Server MBX04 | Set-EcpVirtualDirectory -InternalUrl "https://mail.itproblog.ru/ecp" -ExternalUrl "https://mail.itproblog.ru/ecp"

Настроим виртуальную директорию OWA:

Get-OwaVirtualDirectory -Server MBX03 | Set-OwaVirtualDirectory -InternalUrl "https://mail.itproblog.ru/owa" -ExternalUrl "https://mail.itproblog.ru/owa"

Get-OwaVirtualDirectory -Server MBX04 | Set-OwaVirtualDirectory -InternalUrl "https://mail.itproblog.ru/owa" -ExternalUrl "https://mail.itproblog.ru/owa"

Затем настроим виртуальную директорию автономной адресной книги:

Get-OabVirtualDirectory -Server MBX03 | Set-OabVirtualDirectory -InternalUrl "https://mail.itproblog.ru/OAB" -ExternalUrl "https://mail.itproblog.ru/OAB"

Get-OabVirtualDirectory -Server MBX04 | Set-OabVirtualDirectory -InternalUrl "https://mail.itproblog.ru/OAB" -ExternalUrl "https://mail.itproblog.ru/OAB"

Нам остается настроить виртуальную директорию для PowerShell:

Get-PowerShellVirtualDirectory -Server MBX03 | Set-PowerShellVirtualDirectory -InternalUrl "http://mail.itproblog.ru/powershell" -ExternalUrl "http://mail.itproblog.ru/powershell"

Get-PowerShellVirtualDirectory -Server MBX04 | Set-PowerShellVirtualDirectory -InternalUrl "http://mail.itproblog.ru/powershell" -ExternalUrl "http://mail.itproblog.ru/powershell"

Последним шагом конфигурируем виртуальную директорию веб-сервисов:

Get-WebServicesVirtualDirectory -Server MBX03 | Set-WebServicesVirtualDirectory -InternalUrl "https://mail.itproblog.ru/EWS/Exchange.asmx" -ExternalUrl "https://mail.itproblog.ru/EWS/Exchange.asmx"

Get-WebServicesVirtualDirectory -Server MBX04 | Set-WebServicesVirtualDirectory -InternalUrl "https://mail.itproblog.ru/EWS/Exchange.asmx" -ExternalUrl "https://mail.itproblog.ru/EWS/Exchange.asmx"

Настройка виртуальных директорий для серверов Exchange 2016 завершена.

Конфигурирование Outlook Anywhere

Первоначальная настройка Exchange 2016 также включает в себя настройку пространства имен для Outlook Anywehere (OA). OA позволяет клиентам Outlook подключаться к своим почтовым ящикам за пределами локальной сети (без использования VPN).

Проверим текущие настройки AO для первого сервера Exchange 2016:

Get-OutlookAnywhere -Server MBX03 | fl *host*

Как можно увидеть на скриншоте выше пространство имен OA отличается от нашего пространства имен mail.itproblog.ru. Скорректируем его для обоих серверов Exchange 2016:

Get-OutlookAnywhere -Server MBX03 | Set-OutlookAnywhere -InternalHostname "mail.itproblog.ru" -ExternalHostname "mail.itproblog.ru" -ExternalClientsRequireSsl $true -ExternalClientAuthenticationMethod NTLM -InternalClientsRequireSsl $true

Get-OutlookAnywhere -Server MBX04 | Set-OutlookAnywhere -InternalHostname "mail.itproblog.ru" -ExternalHostname "mail.itproblog.ru" -ExternalClientsRequireSsl $true -ExternalClientAuthenticationMethod NTLM -InternalClientsRequireSsl $true

Настройка Outlook Anywhere завершена.

Переименование и перемещение баз данных

Перед настройкой Database Availability Group нам нужно будет выполнить некоторые подготовительные работы:

  1. Дать более понятное имя почтовым базам.
  2. Переместить файлы почтовых баз на отдельный выделенный диск.

Сейчас у нас по одной на каждом сервере Exchange 2016. Посмотреть их мы можем следующим командлетом:

Get-MailboxDatabase

Переименование почтовой базы состоит из двух шагов: переименование объекта базы данных в конфигурации и переименование физических файлов на системе хранения.

Сначала переименуем наши почтовые базы в конфигурации:

Get-MailboxDatabase -Identity "Mailbox Database 0974770101" | Set-MailboxDatabase -Name DB03
Get-MailboxDatabase -Identity "Mailbox Database 1626184921" | Set-MailboxDatabase -Name DB04

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

Мы совместим процесс переименование физических файлов почтовой базы и процесс переноса физических файлов почтовой базы на отдельный выделенный диск. В нашем случае необходимо выполнить следующий командлет на первом сервере Exchange 2016 (MBX03):

Move-DatabasePath -Identity DB03 -EdbFilePath e:\DB03\db03.edb -LogFolderPath e:\DB03

Нас предупредят о том, что на время переноса почтовая база будет недоступна:

Теперь наша почтовая база расположена на нужном нам диске и наименована так, как мы и просили:

Выполним аналогичный командлет на втором сервере Exchange 2016 (MBX04):

Move-DatabasePath -Identity DB04 -EdbFilePath e:\DB03\db04.edb -LogFolderPath e:\DB04

Переименование и перемещение почтовых баз завершено.

Создание группы высокой доступности

Последним подготовительным шагом для наших серверов Exchange 2016 станет процесс создания группы высокой доступности (Database Availability Group – DAG).

Высокоуровнево процесс создания группы высокой доступности состоит из следующим шагов:

  1. Создание группы высокой доступности в конфигурации.
  2. Добавление почтовых серверов в группу высокой доступности.
  3. Настройка дополнительных копий почтовых баз.

Database Availability Group в основе своей использует Windows Server Failover Clustering. Поскольку наши сервера версии Windows Server 2012, то нам будет достаточно реакции Standard. Для Windows Server 2016 также будет достаточно редакции Standard.

Важный момент – поскольку у нас всего два почтовых сервера, то кворум они собрать не смогут и им нужен сервер свидетель. Поскольку размещать свидетеля на контроллере домена далеко не самая хорошая практика (даже в тестовой среде), то мы подготовим отдельный сервер – SRV01.

Более подробно про кворумы можно почитать в документации на сайте Microsoft.

Подготовка сервера свидетеля

Наш новый сервер будет рядовым сервером в домене. Назовем его SRV01. Операционная система – Windows Server 2012 R2.

С сервером SRV01 нам необходимо выполнить следующие действия:

1. Установить и выполнить первоначальную настройку Windows Server 2012 R2.

2. Выполнить настройку IP-адресации (10.10.10.164).

3. Установить все обновления для ОС.

4. Присоединить сервера к домену itproblog.ru.

5. Добавить группу Active Directory “Exchange Trusted Subsystem” в группу локальных администраторов.

Создание группы высокой доступности в конфигурации

Первый шаг создания DAG на сервере Exchange 2016 – создание объекта группы высокой доступности в конфигурации Exchange. Создадим группу высокой доступности:

New-DatabaseAvailabilityGroup -Name DAG02 -WitnessServer SRV01.itproblog.ru

Если при создании группы высокой доступности Exchange будет ругаться на то, что он не может создать директорию на сервере свидетеле, как показано ниже:

В таком случае вам необходимо либо отключить брандмауэр на сервере свидетеле, либо включить следующие правила брандмауэра:

Добавление почтовых серверов в группу высокой доступности

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

Добавим первый сервер:

Add-DatabaseAvailabilityGroupServer -Identity DAG02 -MailboxServer MBX03

В процессе добавления почтового сервера в группу высокой доступности будут установлены все необходимые дополнительные компоненты, в т.ч. Windows Server Failover Clustering.

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

Add-DatabaseAvailabilityGroupServer -Identity DAG02 -MailboxServer MBX04

Посмотрим теперь на нашу группу высокой доступности:

Get-DatabaseAvailabilityGroup -Identity DAG02

Мы видим, что оба наших сервера представлены в колонке “Member Server”, т.е. оба сервера были успешно добавлены в группу высокой доступности.

Настройка дополнительных копий почтовых баз

Мы создали группу высокой доступности, добавили в неё оба почтовых сервера, но это еще не обеспечивает нам никакой защиты наших почтовых баз. Чтобы наши почтовые базы были доступны в случае потери почтового сервера, на котором они расположены необходимо настроить дополнительные копии почтовых баз. Займемся этим.

Основная суть в том, чтобы, например, для почтовой базы DB03, которая расположена на сервере MBX03, создать дополнительную копию на сервере MBX04. В случае выхода из строя сервера MBX03, почтовая база DB03 будет автоматически активирована на сервере MBX04. Аналогичное справедливо и для почтовой базы DB04 на сервере MBX04.

Создадим дополнительную копию почтовой базы DB03 на сервере MBX04. Выполним следующий командлет:

Add-MailboxDatabaseCopy -Identity DB03 -MailboxServer MBX04

Теперь создадим дополнительную копию почтовой базы DB04 на сервере MBX03. Выполним следующий командлет:

Add-MailboxDatabaseCopy -Identity DB04 -MailboxServer MBX03

Первоначальная настройка Exchange 2016 Database Availability Group завершена, но еще давайте посмотрим в конфигурацию дополнительных копий баз данных:

Get-MailboxDatabaseCopyStatus -Server MBX03
Get-MailboxDatabaseCopyStatus -Server MBX04

Мы видим, что для почтовой базы DB03 создано две копии:

  1. На сервере MBX03. Это основная копию и её статус “Mounted”, т.е. она смонтирована на сервере MBX03, т.к. в соответствующей колонке “Status” для сервера MBX03 указано значение “Mounted”.
  2. На сервере MBX04. Это дополнительная копия, т.к. в соответствующей колонке “Status” для сервера MBX04 указано значение “Healthy”. В случае непредвиденной аварии сервер MBX04 готов подхватить базу.

Нулевые значения в колонках “Copy Queue Length” и “Replay Queue Length” говорят о том, что почтовая база успешно реплицируется между серверами MBX03 и MBX04.

Настройка группы высокой доступности завершена.

Заключение

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

Теперь у нас все готово для начала процесса переключения всего траффика электронной почты, HTTP/HTTPS трафика на почтовые сервера Exchange 2016 с последующей миграцией непосредственно почтовых ящиков. Этим мы и займемся в следующий раз.

Миграция с Exchange 2010 на 2019. Часть 11. Первоначальная настройка Exchange 2016 и создание группы высокой доступности: 2 комментария

  1. Добрый день.
    Спасибо за подробную серию статей по миграции Exchange.
    Вопрос уточнение: почему вы не указываете третий вариант с сертификатом для Exchange, когда его можно выдать из локального центра сертификации, имея котроллер домена?

    1. Добрый день! Справедливое замечание. Добавлю соответствующий пункт. Подавляющее большинство развертываний Exchange, с которыми мне приходилось работать использовали сертификат от коммерческого центра сертификации, т.к. либо часть сервисов (десктопные/мобильные клиента, OWA и т.д.), либо все публикуются наружу для внешнего доступа. Сервера, которые использовали сертификаты от внутреннего ЦС можно пересчитать по пальцам одной руки. Можно, конечно, опубликовать сервисы и сертификатом от внутреннего ЦС, но это накладывает определённые дополнительные трудозатраты. Как минимум нужно вручную импортировать сертификат корневого ЦС на мобильные клиенты. Думаю, из-за этого сразу и не указал.

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

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