В предыдущей записи цикла статей про миграцию мы завершили установка серверов почтовых ящиков и теперь у нас вполне себе функционирующая среда с Exchange 2010. Однако, у нас еще не настроен ряд момент – внешние и внутренние URL адреса, сертификаты, коннектор отправки и балансировка HTTP/HTTPS траффика. Первоначальная настойка Microsoft Exchange 2010 как раз предназначена для этого.
На этом первоначальная настойка Microsoft Exchange 2010 будет завершена и мы перейдем к этапу планирования миграции на Exchange 2016.
Настройка внутренних и внешних URL адресов виртуальных директорий
В Exchange 2010 у нас присутствуют следующие виртуальные директории:
- ActiveSync Virtual Directory. Виртуальная директория для протокола ActiveSync. В осносном это подключение мобильных устройств.
- Autodiscover Virtual Directory. Предназначена для сервиса автоматического конфигурирования внутренних клиентов.
- Ecp Virtual Directory. Виртуальная директория веб-консоли управления.
- Oab Virtual Directory. Предназначения для хранения файлов оффлайн адресной книги.
- Owa Virtual Directory. Виртуальная директории веб версии Outlook.
- PowerShell Virtual Directory. Виртуальная директория веб-версии PowerShell.
- WebServices Virtual Directory. Виртуальная директория веб-сервисов Exchange.
У каждой из виртуальных директория (за исключением виртуальной службы автообнаружения) в настройках необходимо указать URL адрес, который будут использовать внутренние клиенты и URL адрес, который будут использовать внешние клиенты. Этот URL адрес может быть одинаковый как для внутренних клиентов, так и для внешних клиентов. В нашем случае будет именно так.
В дальнейшем для мы будем использовать URL вида https://mail.itproblog.ru.
Для имени mail.itproblog.ru мы чуть ниже настроим отдельный виртуальных сервис на нашем балансировщике сетевой нагрузки, а пока же зарегистрируем запись типа A на нашем DNS сервере:
Первым шагом скорректируем параметры URL адреса сервера автообнаружения:
Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://mail.itproblog.ru/Autodiscover/Autodiscover.xmlВыполним настройку виртуальной директории для ActiveSync:
Get-ActiveSyncVirtualDirectory | Set-ActiveSyncVirtualDirectory -InternalUrl https://mail.itproblog.ru/Microsoft-Server-ActiveSync -ExternalUrl https://mail.itproblog.ru/Microsoft-Server-ActiveSyncНастроим виртуальную директорию веб консоли управления (ECP):
Get-EcpVirtualDirectory | Set-EcpVirtualDirectory -InternalUrl https://mail.itproblog.ru/ecp -ExternalUrl https://mail.itproblog.ru/ecpПропишем наши URL адреса на виртуальной директории оффлайн адресной книги:
Get-OabVirtualDirectory | Set-OabVirtualDirectory -InternalUrl http://mail.itproblog.ru/OAB -ExternalUrl http://mail.itproblog.ru/OABУкажем необходимые нам URL адреса на виртуальаной директории Outlook Web Access:
Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -InternalUrl https://mail.itproblog.ru/OWA -ExternalUrl https://mail.itproblog.ru/OWAСкорректируем параметры URL адресов для виртуальной директории PowerShell:
Get-PowerShellVirtualDirectory | Set-PowerShellVirtualDirectory -InternalUrl http://mail.itproblog.ru/powershell -ExternalUrl http://mail.itproblog.ru/powershellИ последним шагом скорректируем адрес виртуальной директории веб сервисов Exchange:
Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -InternalUrl https://mail.itproblog.ru/Exchange.asmx -ExternalUrl https://mail.itproblog.ru/Exchange.asmxИмпорт и привязка сертификатов
Для корректной работы HTTPS сервисов и службы обнаружения нам необходим сертификат, который будет доверенным для наших клиентов Outlook. Потому что после установки Exchange привязывает к веб-сервисам самоподписанный сертификат и наши клиенты будут получать сообщение о том, что у них нет доверия к этому сертификату:
Вариант с использованием самоподписанного сертификата мы рассматривать не будем. В остальных случаях у вас будет два варианта:
- Купить коммерческий сертификат на год или более.
- Выпустить бесплатный сертификат от Let-s Encrypt на 3 месяца. Что мы и сделаем. Мы выпустим wildcard сертификат на имя *.itproblog.ru
После того, как мы выпустим наш сертификат необходимо установить его в локальное хранилище сертификатов компьютера на серверах клиентского доступа и балансировщике сетевой нагрузки.
Импорт сертификата на сервера клиентского доступа
Для импорта сертификата на сервера клиентского доступа выполните следующие шаги:
1. Запустить MMC консоль управления сертификатами для локального компьютера:
2. В контекстом меню персонального контейнера выбрать пункт для импорта сертификата:
3. Выполнить все шаги мастера импорта сертификатов.
4. Сертификат должен отобразиться в локальном хранилище сертификатов:
5. Выполнить импорт сертификата на все сервера клиентского доступа Exchange.
Привязка сертификата к сервисам Exchange
Импорт сертификата – это лишь половина дела. Далее их нужно указать – какие сервисы будут использовать наш сертификат:
1. Запустим Exchange Management Shell на первом сервере клиентского доступа и посмотрим на список наших сертификатов:
Get-ExchangeCertificate | fl Subject,Services,Thumbprint
2. Находим наш свежевыпущенный сертификат и привязываем его ко всем сервисам:
Get-ExchangeCertificate -Thumbprint "5CEC8544D4743BC279E5FEA1679F79F5BD0C2B3A" | Enable-ExchangeCertificate -Services IMAP, POP, IIS, SMTP
3. Перезапускаем сервер IIS:
iisreset4. Выполняем аналогичные действия на втором сервере клиентского доступа.
Настройка балансировки SMTP траффика
Далее нам необходимо настроить балансировку SMTP и HTTP/HTTPS траффика согласно руководству вендора нашего балансировщика. Общая схема балансировки сетевого траффика будет выглядеть следующим образом:
После того, как мы скорректировали адреса веб сервисов и виртуальных директорий Exchange и указали во всех случаях имя mail.itproblog.ru, нам необходимо настроить виртуальный сервис на нашем балансировщике сетевой нагрузки, которые будет принимать подключения и распределять их непосредственно по серверам.
Вот тут есть подробное руководство по балансировке SMTP на Kemp LoadMaster.
Что для этого нужно сделать:
1. Перейти в веб-интерфейс управления нашим балансировщиком:
https://10.10.10.150/2. Перейти в раздел создания нового виртуального сервиса и указать IP-адрес (10.10.10.161 – для имени mail.itproblog.ru), порт и соответствующий шаблон:
3. Перейти в диалоговое окно добавления реальных серверов:
4. Добавим наш первый сервер с ролью Hub Transport:
5. И второй сервер с ролью Hub Transport:
6. Теперь проверим статус нашего виртуального сервиса для балансировки SMTP траффика:
Как мы видим – общее состояние всего сервиса и его отдельных сервером работоспособное.
Настройка балансировка HTTPS траффика
После того, как мы настроили балансировку SMTP траффика нам необходимо настроить балансировку HTTP/HTTPS траффика.
Наш балансировщик в лице KEMP LoadMaster может выполнять балансировку в разных конфигурация: без разгрузки SSL, с разгрузкой SSL, без преаутентификации, с преаутентификацией и т.д.
Мы будем использовать конфигурацию без преаутентификации и разгрузки SSL (without SSL Offload and ESP).
За опорную документацию по настройке мы будем использовать руководство от вендора.
Итого, что нам нужно сделать:
1. Перейти в веб-интерфейс управления нашим балансировщиком:
https://10.10.10.150/2. Перейти в раздел создания нового виртуального сервиса и указать IP-адрес (10.10.10.161 – для имени mail.itproblog.ru), порт и соответствующий шаблон:
3. В созданном виртуальном сервисе убедится, что в секции стандартных настроек установлены следующие параметры:
4. Убедится, что в секции виртуальных серверов установлены следующие настройки:
Пара комментариев. Параметры Checked Port и URL определяют как балансировщик понимает – жив ли сервис или нет на реальном сервере, т.е. балансировщик проверяет адрес вида https://10.10.10.155/owa и если получает отчет вида 200 OK, то делает заключение, что реальный сервер жив и продолжает балансировать траффик на него. Если же он получает ответ с ошибкой, то балансировщик исключает этот реальный сервер из пула для балансировки.
Как можно сделать вывод – если у нас “отвалится” OWA, то и “отвалится” все остальное. Это не есть хорошо, но для целей демонстрации это решение нам подходит. Это решение может также подойти и для небольших развертываний в производственной среде. К тому же первоначальная настойка Microsoft Exchange 2010 для тестовой среды не подразумевает очень тонкой настройки балансировки. Однако, если у вас большая организация Exchange, то все же лучше настроить отдельный сервис для каждой виртуальной директории, как указано в руководстве балансировщика.
5. Теперь нам необходимо добавить наши реальные сервера в наш виртуальный сервис для балансировки HTTP/HTTPS траффика. Добавим первый сервер клиентского доступа:
6. И добавим второй сервер клиентского доступа:
7. Теперь посмотрим состояние наших виртуальных сервисов:
Наши сервисы находятся в работоспособном состоянии. Также обратите внимание, что шаблон для балансировки HTTPS траффика добавил еще один сервис – он будет выполнять редирект HTTP запросов на HTTPS.
Если параметры балансировки были настроены корректно, то при переходе по следующему URL вы должны попасть на страницу OWA:
https://mail.itproblog.ru/owa/
Настройка коннектора отправки и приема электронной почты
Настройка коннектора отправки электронной почты
Для того, чтобы пользователи Exchange могли отправлять почту во внешний мир нам необходимо настроить коннектор отправки электронной почты.
Что нужно для настройки этого коннектора:
1. Запустить консоль управления Exchange и перейти в соответствующий раздел настроек:
2. Запустим мастер создания нового коннектора отправки.
3. Укажем имя коннектора:
4. Этот коннектор будет использоваться для отправки писем на любой адрес. Укажем это (* в строке пространства имен):
5. У нас нет промежуточных смарт хостов и мы будет отправлять почту напрямую в конечную почтовую систему. Указываем это:
6. Разрешим обоим нашим серверам отправлять почту во внешний мир через этот коннектор:
7. Подтвердим создание нового коннектора.
Настройка коннектора приема электронной почты
Теперь нам необходимо немного скорректировать коннекторы приема электронной почты – задать имя, которым сервер будет представляться и разрешить прием писем на 25 TCP порту от анонимных пользователей.
1. Запустить консоль управления Exchange и перейти в соответствующий раздел настроек:
2. На вкладке “Permission Group” разрешим использование этого коннектора группе анонимных пользователей, чтобы наш сервер мог принимать внешнюю почту.
3. Сохраним внесенные изменения.
4. Сделаем аналогичные настройки для коннектора “Default CAS02”:
4. Сохраним внесенные изменения.
Настройка публикации SMTP и HTTPS во внешний мир
Теперь нам осталось только опубликовать наш сервер Exchange во внешний мир и настроить необходимые DNS записи во внешней зоне.
Публикация сервера Exchange во внешний мир
Тут все крайне сильно зависит от текущей инфраструктуры. Кто-то конфигурирует NAT правило, кто-то конфигурирует публикацию через TMG (да, да – он еще местами встречает 🙂 ), кто-то использует AD FS + WAP. Тут нет какого-то универсального решения, но есть общие требования:
- Весь траффик пришедший снаружи по порту TCP 25 должен будет перенаправлять на наш виртуальный сервер mail.itproblog.ru (10.10.10.161).
- Весь траффик пришедший снаружи по порту TCP 443 должен будет перенаправлять на наш виртуальный сервер mail.itproblog.ru (10.10.10.161).
В моем случае – это просто NAT правило в настройках маршрутизатора:
В вашем случае это может быть совсем другое решение.
Настройка DNS записей во внешней зоны
Для того, чтобы наш почтовый сервер могу принимать внешнюю почту и предоставлять возможность автоматического получения параметров подключения для внешних клиентов (через механизм автообнаружения) во внешней DNS зоне нам понадобятся следующие записи:
| Имя | Тип Записи | Значение | Комментарии |
| A | IP-адрес почтового сервера | DNS запись почтового сервера | |
| autodiscover | A | IP-адрес почтового сервера | DNS запись для работы служб автообнаружения |
| @ | MX | IP-адрес почтового сервера | DNS запись для маршрутизации входящей почты |
| @ | TXT | v=spf1 a mx -all | SPF запись для фильтрации нежелательной почты |
В нашем случае получился следующий перечень DNS записей:
В ваше случае имена и IP-адреса, соответственно, будут конкретно под вашу инфраструктуру.
При правильной настройке теперь вы можете как отправлять электронную почту во внешний мир, так и принимать почту от внешнего мира.
Заключение
Первоначальная настойка Microsoft Exchange 2010 завершена – мы настроили сертификаты, коннектор отправки, указали корректные внутренние и внешние URL адреса, настроили балансировку SMTP и HTTPS траффика, а также опубликовали наш Exchange наружу – теперь мы можем принимать и отправлять письма во внешний мир.
В следующей записи мы поговорим о требованиях к инфраструктуре для начал миграции на Exchange 2016.