Работаем в облаке на базе Hyper-V, часть 2: развертывание Exchange Server

Привет! Сегодня разберём как установить exchange server 2016 с нуля. Всё нижесказанное также относится и к 2013 exchange. Миграция описана в статье Миграция с exchange server 2007 на 2013 отличий от миграции с 2010 или 2013 на 2016 нет.

Предварительные требования:

1. NET Framework 4.7.1
2. компоненты из статьи KB3206632 базы знаний Майкрософт
3. распространяемый пакет Visual C++ для Visual Studio 2012
4. распространяемый пакет Visual C++ для Visual Studio 2013
5. Microsoft Unified Communications Managed API 4.0, среда выполнения Core (64-разрядная версия)

6. Install-WindowsFeature RSAT-ADDS

7. Install-WindowsFeature NET-Framework-45-Features, Server-Media-Foundation, 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

Миграция возможно минимум с exchange 2010 CU11. Контроллеры домена и уровень леса не менее Windows Server 2008 R2. Оперативная память – Почтовый ящик: не менее 8 ГБ.  Пограничный транспортный сервер: не менее 4 ГБ.

ОС windows server 2012 или windows server 2016.

В нашем случае будет идеальный вариант – чистый контроллер домена и чистая система, обе windows server 2016.

Устанавливаем компоненты:

Теперь можно устанавливать exchange server 2016. В принципе, установщик всё сделает за вас. Каких то особых требований, кроме описанных выше, нет. Если вы ставите сервер в существующую среду 2010 или 2013, то также никаких дополнительных действий не требуется. После установки они будут сосуществовать вместе, текущую инфраструктуру и работу почты данная установка не затронет.

Ставим галочки:

В этом случае установщик сам до установит недостающие компоненты, расширит схему AD выполнит подготовку. Имя организации – это имя раздела, в котором будут хранится настройки exchange в текущем лесу. Если в процессе установки у вас ошибка “Windows Server-Gui-Mgmt-Infra not installed” значит вы пытаетесь установить версию exchange до CU3. Скачиваем версию с последним CU. На текущий момент – CU12.

Не пугаемся названия – Cumulative Update 12 for Exchange Server это полноценный дистрибутив с последними обновлениями.

Как видим, установщик сам расширит схему и подготовит AD.

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

Подготовка AD, создание нужных контейнеров и объектовE:Setup.exe /IAcceptExchangeServerLicenseTerms /PrepareAD /OrganizationName:”First organization”

Если в процессе установки возникли ошибки, нам сильно поможет C:ExchangeSetupLogsExchangeSetup.log.

В случае если установка завершилась успешно, переходим по ссылке https://localhost/ecp и радуемся.

В принципе, можно создавать пользователей, и пользоваться почтой через owa, внутри организации она уже работает полноценно. Для отправки нам нужно создать коннектор отправки, он находится в “поток обработки почты – соединители отправки”. Тип коннектора – выбираем internet.

Адресное пространство – ставим звездочку. Это значит, что на все домены почта будет оправляться через этот коннектор. Если же мы хотим что бы почта на определенный домен отправлялась через специфический сервер – то создаём еще один коннектор. Затраты – приоритет отправки, сначала почта будет отправляться через коннектор с приоритетом 1, если условия совпадают.

Исходный сервер – если у нас несколько серверов, например в разных сайтах, и мы хотим отправлять почту со всех серверов exchange только через один, выбираем его в этом пункте. В нашем примере у  нас один сервер, естественно мы его и указываем.

И так – теперь мы можем отправлять почту в интернет. Но возникнет проблема – почти все наши письма будут помечены как спам. Почему так происходит? Потому что основные антиспам проверки включают в себя PTR запись, она должна совпадать с именем сервера, которым он представляется.

Переходим в нас тройки созданного коннектора, пункт “определение области”, и укажите FQDN имя, через которое ваш сервер будет доступен во внешних DNS. Также нужно написать провайдеру, что бы он прописал PTR запись на ваш внешний IP.

Первое дело сделано. Второй важный шаг – это настроить SPF запись. Про это можно прочитать в моей статье STOP SPAM. PTR, SPF, DKIM, DMARC

DKIM и DMARC можете настроить по своему усмотрению. Теперь наша почта должна доходить до адресата без проблем. Проверить корректность настроек можно с помощью сайта https://www.mail-tester.com/.

Переходим к коннекторам приёма. Эта штука определяет, как и кто может отправлять почту в наше систему. Приём почты разрешен для домена по умолчанию, он указан сразу.

То есть если домен у вас local, то естественно для маршрутизации в интернете нам нужен существующий, например hobbycomp.ru. Добавляем его в обслуживаемые домены. Тип – заслуживающий доверия. Письма,отправленные извне на этот домен будут обрабатываться, а если адреса не существует отклоняться. Если выбрать внутренняя ретрансляция – то если адресат не обнаружен, письма будут пересылаться дальше, например на другой сервер, указанный в коннекторе отправке, если внешняя ретрансляция – наличие пользователя проверяться не будет, просто будет пересылаться дальше.

Не забываем создать Политику адресов электронной почты, она находится в разделе “поток обработки почты”. Она нужна для того, что бы все новые сотрудники сразу создавались с нужным нам адресом почты, например имя.фамилия”домен.ру

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

Переменная	Значение
%d	Краткое имя
%g	Имя
%i	Буква отчества
%m	Псевдоним Exchange
%s	Фамилия
% _x_g	Первые буквы x первого имени. Например, %2g первые две буквы с именем не используются.
% _x_s	Первые буквы x фамилии. Например, %2s использует первые две буквы фамилии.

Продолжаем про коннекторы приёма. В них мы указываем: IP адреса с которых сервер принимает почту, на каких интерфейсах слушать порт приёма (25-й по дефолту) каких пользователей обслуживать – анонимных, или только с аутентификацией.

Коннектор по умолчанию default frontend настроен на приём писем со всех IP адресов, в том числе и от анонимных пользователей.  От анонимных – это значит что любой пользователь может прислать нам письмо на заслуживающий доверия домен.

Что бы это работало, рекомендую снять галку взаимная проверка подлинности, если у сервера будет самоподписанный (не доверенный) сертификат – письмо до вас не дойдёт.

Также на всех коннекторах включите ведение журнала – это очень поможет выявлять неполадки.

Нужные нам журналы хранятся здесь – C:Program FilesMicrosoftExchange ServerV15TransportRolesLogsFrontEndProtocolLog

Архитектура exchange сервера обычно предполагает наличие перед ним front end сервера ,который бы осуществлял фильтрацию писем на спам и вирусы. Встроенный функционал сервера в этом смысле слабоват.

Можно использовать exim, postfix, Cisco ESA. Лично мне нравится postfix, можно использовать его в связке с ClamAV и Spamassasin. Неплохое бесплатное решение.

В этом случае коннектор приёма настраиваем на приём только с одного IP – IP нашего front end сервера. Для принтеров, различных программ типа 1С создаём отдельный коннектор с IP нужного нам сервера, и анонимным приёмом. Отправлять в этом случае можно будет с любого несуществующего адреса в нашем домене, на адреса опять же в нашем домене (использовать для оповещений, без обратной связи). Если мы хотим отправлять письма на внешние адреса – нам нужно будет создать либо учетную запись с ящиком, и указать учетные данные при отправке.

В веб интерфейсе нам доступна только малая часть настроек, всё остальное скрыто в EMS.

Например, вот вывод всех настроек дефолтного коннектора приёма:

Get-ReceiveConnector -Identity "Default Frontend EX01" | fl

RunspaceId : 0b4604c3-bfef-4b7b-b8b6-b55b79d9f894AuthMechanism : Tls, Integrated, BasicAuth, BasicAuthRequireTLS, ExchangeServerBanner :BinaryMimeEnabled : TrueBindings : {[::]:25, 0.0.0.0:25}ChunkingEnabled : TrueDefaultDomain :DeliveryStatusNotificationEnabled : TrueEightBitMimeEnabled : TrueSmtpUtf8Enabled : TrueBareLinefeedRejectionEnabled : FalseDomainSecureEnabled : TrueEnhancedStatusCodesEnabled : TrueLongAddressesEnabled : FalseOrarEnabled : FalseSuppressXAnonymousTls : FalseProxyEnabled : FalseAdvertiseClientSettings : FalseFqdn : ex01.test.localServiceDiscoveryFqdn :TlsCertificateName :Comment :Enabled : TrueConnectionTimeout : 00:10:00ConnectionInactivityTimeout : 00:05:00MessageRateLimit : UnlimitedMessageRateSource : IPAddressMaxInboundConnection : 5000MaxInboundConnectionPerSource : 20MaxInboundConnectionPercentagePerSource : 2MaxHeaderSize : 256 KB (262,144 bytes)MaxHopCount : 60MaxLocalHopCount : 12MaxLogonFailures : 3MaxMessageSize : 36 MB (37,748,736 bytes)MaxProtocolErrors : 5MaxRecipientsPerMessage : 200PermissionGroups : AnonymousUsers, ExchangeServers, ExchangeLegacyServersPipeliningEnabled : TrueProtocolLoggingLevel : VerboseRemoteIPRanges : {::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff, 0.0.0.0-255.255.255.255}RequireEHLODomain : FalseRequireTLS : FalseEnableAuthGSSAPI : FalseExtendedProtectionPolicy : NoneLiveCredentialEnabled : FalseTlsDomainCapabilities : {}Server : EX01TransportRole : FrontendTransportRejectReservedTopLevelRecipientDomains : FalseRejectReservedSecondLevelRecipientDomains : FalseRejectSingleLabelRecipientDomains : FalseAcceptConsumerMail : FalseSizeEnabled : EnabledTarpitInterval : 00:00:05AuthTarpitInterval : 00:00:05MaxAcknowledgementDelay : 00:00:30AdminDisplayName :ExchangeVersion : 0.1 (8.0.535.0)Name : Default Frontend EX01DistinguishedName : CN=Default Frontend EX01,CN=SMTP Receive Connectors,CN=Protocols,CN=EX01,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=test,DC=localIdentity : EX01Default Frontend EX01Guid : e569491e-7fd2-4c48-b43b-6bd4e76ebf96ObjectCategory : test.local/Configuration/Schema/ms-Exch-Smtp-Receive-ConnectorObjectClass : {top, msExchSmtpReceiveConnector}WhenChanged : 16.03.2019 13:42:54WhenCreated : 16.03.2019 13:42:54WhenChangedUTC : 16.03.2019 10:42:54WhenCreatedUTC : 16.03.2019 10:42:54OrganizationId :Id : EX01Default Frontend EX01OriginatingServer : dc01.test.localIsValid : TrueObjectState : Unchanged

Многие параметры говорят сами за себя, например MaxRecipientsPerMessage:200 значит что на этом коннекторе возможен приём для максимум  200 получателей, а MessageRateLimit : Unlimited о том что количество принимаемых писем в секунду не ограничено.

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

Get-ReceiveConnector | fl Name,MessageRateLimit

Name : Default EX01MessageRateLimit : Unlimited

Name : Client Proxy EX01MessageRateLimit : 5

Name : Default Frontend EX01MessageRateLimit : Unlimited

Name : Outbound Proxy Frontend EX01MessageRateLimit : Unlimited

Name : Client Frontend EX01MessageRateLimit : 5

Теперь поговорим об еще одном важном аспекте – сертификатах. Сертификаты прежде всего нужны нам для подключения outlook к серверу, и для подключения через браузер, без уведомления о том, что сайт небезопасен.

Давайте разберёмся, что такое сертификат, и как он работает. По сути это ключ, две половинки которого называются закрытый и открытый ключ. То что зашифровано одним ключом можно расшифровать другим, и наоборот. Закрытый ключ хранится только на сервере, открытый же доступен всем. Когда мы генерируем сертификат с помощью нашего внутреннего центра сертификации, он подписан его корневым сертификатом. А корневой сертификат имеется в доверенных на всех компьютерах домена, поэтому ошибок не возникает. Как только мы пытаемся подключится с компьютера, на котором данного корневого сертификата нет – получаем ошибку. Если устраивает такой вариант, когда мы можем всем пользователям установить свой корневой сертификат – то тогда используем его. Как развернуть внутренний центр сертификации описано в моей статье Установка Certification Authority

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

Как установить сертификат на примере внутреннего центра сертификации. Заходим в раздел серверы – сертификаты. Выбираем “создать запрос на сертификат, подписанный центром сертификации”.

Проходим через мастер, важный момент выбор имён, которые будут использоваться в сертификате. Я рекомендую использовать единое пространство имен как внутри, так и снаружи. На внутреннем DNS создать  зоны mail.hobbycomp.ru и autodiscover.hobbycomp.ru, для работы хватит этих двух имен. Если планируется раздельное пространство имен – они должны присутствовать в сертификате.

Сохраняем запрос на сертификат, сохранить можно на сетевую шару. теперь у нас есть ожидающий запрос. Это значит, что сгенерирован закрытый ключ, он хранится на сервере, а нам нужно подписать наш сертификат с открытыми данными корневым сертификатом центра сертификации. Для этого идём на веб интерфейс центра сертификации. https://server/certsrv

Выбираем запрос сертификата – расширенный запрос сертификата, открываем блокнотом сохраненный запрос на сертификат, и вставляем в поле сохранённый запрос. Шаблон сертификата выбираем веб сервер.

В интерфейсе с сертификатами сервера, выбираем “выполнить”, и подсовываем полученный сертификат. Путь также указываем в формате сетевой шары.

Назначаем новый сертификат службам IIS и SMTP.

На выходе получаем валидный сертификат, для тех устройств на которых установлен корневой сертификат.

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

Вкладка серверы – виртуальные каталоги. В настройках нужно прописать имя сервера, для простоты опять же рекомендуется использовать одинаковые имена для внешних и внутренних адресов. Если у вас один сервер – особо не заморачиваемся. Если вы мигрируете на новый сервер, или у вас их несколько – тут схема будет действовать следующим образом. Для OWA, если пользователь будет в базе на одном сервере, а подключается на другой, будет срабатывать редирект на другой сервер. В остальных случаях, если внутреннее имя сервера не прописано, должно работать проксирование с одного сервера на другой.

Для каталога autodoscover адрес нужно задать через EMS. Задаётся только внутренний адрес, это будет адрес SCP – service connection point, outlook вытащит его из active directory.

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

Get-ClientAccessService | fl AutoDiscoverServiceInternalUri

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

Если у Вас есть вопросы, задавайте их на форуме, или ниже в комментариях.

Базовая настройка Exchange Server является обязательной задачей после установки продукта. О том как выполнить установку, какие необходимо учесть нюансы можно ознакомится по следующей ссылке. Весь процесс базовой настройки разбит по кейсам, итог выполнения которых — работоспособный Exchange сервер. Будут реализованы возможности отправки и получения электронной почты, а также выполнены условия для подключения клиентов. Виду объема необходимой конфигурации, весь материал разбит на две статьи. В первой части рассматриваются следующие вопросы:

• Добавление обслуживаемого домена (accepted domains)
• Настройка соединителя отправки (send connector)
• Настройка внешних URL адресов Exchange сервера

Во второй:

• Выпуск SSL сертификатов для Exchange сервера
• Настройка политики адресов электронной почты

Добавление обслуживаемого домена (accepted domains)

Обслуживаемый домен (accepted domains) — это домен, который используется Exchange организацией для получения и отправки почтового трафика. В рамках него (типы Authoritative и Internal Relay) могут формироваться почтовые адреса пользователей, общих почтовых ящиков, групп распространения и других объектов Exchange которым возможно назначить почтовый адрес. По умолчанию, сразу же после развертывания, доступен лишь один обслуживаемый домен:

Имя его соответствует домену Active Directory. Всего существует три типа обслуживаемых доменов:

1. Уполномоченный домен (Authoritative)
2. Домен внутренней ретрансляции (InternalRelay)
3. Внешний домен ретрансляции (ExternalRelay)

Домены первого типа полностью обслуживаются Exchange организацией. При поступлении на него входящего письма происходит поиск почтового адреса в глобальном каталоге Active Directory. В случае его отсутствия будет возвращен NDR (Not Delivery Report).

Домен внутренней ретрансляции применяется тогда, когда адресное пространство используется совместно с другой почтовой инфраструктурой. Логика работы такая же, как и в первом типе, но при отсутствии почтового адреса в глобальном каталоге возможно перенаправление письма на другой SMTP шлюз.

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

Если письмо будет доставляться в Exchange организацию, а домен получателя отсутствует в обслуживаемых доменах, оно автоматически будет отклонено с ошибкой 550 5.7.54 SMTP; Unabletorelayrecipientinnon—accepteddomain.

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

Настройка соединителя отправки (send connector)

В Exchange инфраструктуре коннекторы или соединители выполняют задачи обработки входящего и исходящего почтового потока, также участвуют внутри транспортного потока Exchange. Чтобы почтовая инфраструктура могла взаимодействовать с внешними системами по протоколу SMTP, необходимо создать новый соединитель отправки. Для этого следует перейти в раздел почтовый поток (mailflow), во вкладку исходящие почтовые соединители (sendconnectors)

Как и в случае с обслуживаемыми доменами, существует несколько типов исходящих почтовых соединителей:

• Внутренний (Internal)
• Внешний (Internet)
• Партнерский (Partner)

Внутренний соединитель отправки используется для ретрансляции почтового потока внутри почтовой организации. Например, в сочетании с доменом внутренней ретрансляции.

Внешний тип предполагает отправку почты во вне организации, например удаленному почтовому серверу через Интернет.

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

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

На следующей странице необходимо указать каким образом будет осуществляться отправка почты. Либо используя MX записи, либо выделенный смарт-хост в виде внешнего почтового релея.

Внизу страницы присутствует чек-бокс с включением конфигурации Use the external DNS lookup settings on servers with transport roles. Задействование данной опции позволит не использовать конфигурацию DNS серверов сетевого интерфейса Exchange сервера, а применить настройки из конфигурации самого сервера. Они задаются на странице Servers, в первом же разделе Servers:

Необходимая вкладка называется DNS lookups:

Следующий шаг заключается в задании адресного пространства, за которое ответственен соединитель. В случае если создаваемый тип соединителя внутренний или партнерский, задаться конкретный почтовый домен. Например, partnerdomain.com. Если же используется *, коннектор будет обсуживать все существующее пространство имен. Если в конфигурации присутствует несколько коннекторов, один из которых обслуживает пространство *, а второй с partnerdomain.com, приоритет получит последний.

Чек-бокс Scopedsendconnector даст возможность привязать коннектор к определенному сайту Active Directory, в котором находится сам Exchange. Для базовой настройки Exchange инфраструктуры этот параметр не требуется.

Задание адресного пространства выглядит следующим образом:

Далее, задаем сервер или сервера Exchange которые могут использовать данный соединитель:

В моем случае, у меня один и едиснтвенный Exchange сервер с ролью Hub Transport Service:

Конфигурация исходящего соединителя завершена:

Важно учесть, что со стороны сети, Exchange сервер должен иметь доступ по 25-му порту в Интернет (NAT). На Exchange сервер должен быть «проброшен» сделан DNAT с 25-го порта с публичного IP.  Публичный IP используемый в NAT и DNAT должны совпадать.

Помимо правильной сетевой конфигурации необходимо корректно настроить публичную DNS зону почтового домена. Для обмена с внешними почтовыми системами необходимо добавить два типа записей — MX и А.

• Запись типа А должна иметь значение внешнего IP адреса, с которого сделан DNAT на приватный адрес Exchange сервера. В случае применения пограничного Edge сервера, DNAT делается на него;
• MX запись указывает на A запись.

Настройка внешних URL адресов Exchange сервера

Базовая настройка Exchange Server не заканчивается добавлением обслуживаемого домена и настройкой соединителей. Необходимо задать корректные URL адреса для подключения клиентов. Для этого перейдем в настройки конфигурации:

Выберем сервер и нажмем на «карандаш» открыв страницу настроек. Далее, необходимо перейти в настройки OutlookAnywhere и задаем внешний домен для подключения клиентов:

Данный домен, в последствии, будет использоваться для публикации Exchange сервера. Этот процесс будет описан в будущей статье.

Задание внешнего домена требуется и для веб каталогов Exchange сервера. Для этого необходимо перейти в конфигурацию virtual directories и найти «гаечный ключ»:

На открывшейся странице задаем необходимую конфигурацию:

Задание внешнего домена по которому будет доступна Exchange инфраструктура необходимо для дальнейшего выпуска SSL сертификатов.

На этом пока все. Если у вас возникли какие-либо вопросы, пожалуйста, пишите в комментарии.

Базовая настройка Exchange Server 2019. Часть 2

• Tutorial

Часть 1: знакомство с панелью управления Часть 2: развертывание Exchange ServerЧасть 3: хранилище Storage Spaces На прошлой неделе мы познакомились с порталом управления облачной инфраструктурой на базе Azure Pack, научились создавать виртуальную сеть и виртуальные машины. Сегодня будет разворачивать и настраивать Exchange Server из шаблона. Содержание

Разворачиваем виртуальную машину с ролью Active DirectoryРазворачиваем виртуальную машину с ролью Exchange Server 2013Проверка корректного запуска служб Exchange ServerНастройка DNS зоны и правил форвардинга портовНастройка кластера баз данных серверов ExchangeНастройка клиентского доступаКонфигурация почтового транспорта

В ходе нашего эксперимента будем создавать ИТ-инфраструктуру со следующими характеристиками:

Имя домена Active Directory: cloud-v.datalinecentre.ruВнешнее DNS-имя: cloud-v.datalinecentre.ruКонтроллер домена 1: MSK-DC01 (2 CPU/2Gb RAM/40 HDD)Контроллер домена 2: MSK-DC02 (2 CPU/2Gb RAM/40 HDD)Exchange сервер c ролью почтовых ящиков и клиентского доступа 1: MSK-EXH01 (4CPU/8Gb RAM/50Gb+170Gb HDD)Exchange сервер c ролью почтовых ящика и клиентского доступа 2: MSK-EXH02 (4CPU/8Gb RAM/50Gb+170Gb HDD)Виртуальная сеть организации: 10.10.10.0/24Метод балансировки: DNS

В рамках этого материала мы не будем создавать DMZ-сеть, но для безопасной работы боевой системы и защиты от атак извне необходимо наличие буфера между внешней сетью и интранетом.Схема нашей ИТ-инфраструктуры.

Разворачиваем виртуальную машину с ролью Active Directory

Перед установкой Microsoft Exchange Server 2013 необходимо подготовить лес Active Directory и его домены. Информация о почтовых ящиках пользователей и конфигурации серверов Exchange должна где-то храниться. Мы для этого будем использовать контроллер домена Active Directory.

1. В портале управления переходим в раздел Виртуальные машины и кликаем Создать.
2. Выбираем Роль виртуальной машины, Из коллекции.
3. Выбираем шаблон Контроллер домена Windows 2012 R2.
4. Указываем имя роли виртуальной машины.
5. Указываем параметры виртуальной машины:
   • Размер (CPU, RAM, HDD)
   • Пароль и логин локального администратора
   • Часовой пояс
   • Имя виртуальной машины
   • Виртуальную сеть

   

6. Вводим параметры создаваемого леса Active Directory и нажимаем OK.
7. Готово. Виртуальная машина с ролью Active Directory развернута. Для обеспечения отказоустойчивости рекомендуем развернуть как минимум два контроллера домена в своей инфраструктуре. Создадим вторую виртуальную машину с ролью Active Directory. Для этого воспользуемся функцией масштабирования, которая есть в панели.
8. Выбираем из списка нужную Виртуальную машину. Переходим во вкладку Масштабирование и выбираем на бегунке нужное число экземпляров. Жмем Сохранить.
9. Готово. Во вкладке Экземпляры появилась вторая виртуальная машина с ролью контроллера домена, присоединенная в существующий домен Active Directory.

Разворачиваем виртуальную машину с ролью Exchange Server 2013

Active Directory у нас есть. Обычно перед развертыванием Exchange Server нужно расширить схемы Active Directory и подготовить домены. При развертывании виртуальной машины Exchange Server из шаблона, все действия по расширению схемы и подготовке домена выполняются автоматически. Как и с Active Directory, создаем роль виртуальной машины.

1. Выбираем Из коллекции Exchange Server 2013 SP1 CU9.
2. Задаем имя роли виртуальной машины.
3. Задаем параметры виртуальной машины.
   • Размер (CPU, RAM, HDD)
   • Пароль и логин локального администратора
   • Часовой пояс
   • Имя виртуальной машины
   • Виртуальную сеть — подключаем виртуальную машину к той же сети, в которой создали ВМ с Active Directory.

   

4. Задаем параметры учетной записи.
5. Готово.
6. Как и в случае с Active Directory, создаем дополнительную виртуальную машину Exchange Server с помощью функции масштабирования.

Проверка корректного запуска служб Exchange Server

Подключаемся к нашим виртуальным машинам c Exchange Server через RDP-консоль.

1. Выделяем виртуальную машину и жмем на панели команд Подключить, Консоль.
2. Через сохраненный RDP-файл подключаемся к виртуальной машине.
3. Проверяем статус служб Exchange Server через Exchange Management Shell (EMS).
4. Выполняем команду test-servicehealth –Server “имя Exchange сервера”.
5. Также после развертывания виртуальной машины с Exchange рекомендуем пробежаться по логам на предмет ошибок.

Настройка DNS зоны и правил форвардинга портов

DNS-записи. Чтобы Exchange Server мог отправлять и принимать почту, проходить антиспам проверки, нужно добавить следующие DNS-записи во внешнюю зону. В нашем случае, записи будут выглядеть следующим образом:

A-записи:

• Autodiscover.cloud-v.datalinecentre.ru 185.99.13.17
• Autodiscover.cloud-v.datalinecentre.ru 185.99.13.19
• Mail.cloud-v.datalinecentre.ru 185.99.13.17
• Mail.cloud-v.datalinecentre.ru 185.99.13.19

MX-запись: Mail.cloud-v.datalinecentre.ru 5Txt-запись: «v=spf1 ip4:185.99.13.19 ip4:185.99.13.17 -all»

Не забудьте для A-записей добавить PTR-записи в обратной зоне провайдера, которому принадлежат внешние IP-адреса. Они нужны для прохождения антиспам проверок.Создание правил форвардинга портов. Для корректной работы сервера нам понадобятся следующие порты:

• 25/587– SMTP
• 80/443 – HTTP/HTTPS

Сюда же добавляем порты протоколов POP3 110/995 и IMAP 143/993, если планируем их использовать для подключения клиентов.

1. В портале управления заходим в раздел Сети и выбираем сеть, в которой работают машины с Exchange. Переходим во вкладку Правила.
2. Нажимаем Добавить правило.
3. Заполняем поля и сохраняем.
4. По аналогии добавляем правила для каждого внешнего IP-адреса: у нас их два (185.99.13.19 и 185.99.13.17), так как развернуто два сервера Exchange. Вот что должно получиться в итоге:

Настройка кластера баз данных серверов Exchange

Мы с вами развернули два сервера Exchange для обеспечения большей доступности. На их основе мы настроим отказоустойчивый кластер — Database Availability Group (DAG). DAG можно создать через Exchange Management Shell или Exchange Control Panel. Мы продолжим работу с EMS.

1. Подключимся к виртуальной машине через консоль, введем команду New-DatabaseAvailabilityGroup, где:
   • Name – имя группы доступности;
   • WitnessServer – сервер-свидетель;
   • WitnessDirectory – директория на сервере-свидетеле, в которой будет храниться служебная информация;
   • DatabaseAvailabilityGroupIpAddress – IP-адрес кластера.

   Важно: при четном количестве серверов в DAG необходимо иметь сервер-свидетель, который будет определять кворум в кластере. Этот сервер не может быть одним из членов кластера. В группу локальных администраторов этого сервера должна быть включена группа Exchange Trusted Subsystem. В нашем случае роль сервера-свидетеля будет выполнять контроллер домена. В продуктивной среде так делать нельзя и лучше использовать выделенный сервер. При нечетном количестве серверов в DAG сервер-свидетель не нужен.

2. Добавляем в DAG серверы msk-exh01 и msk-exh02. Выполняем команду Add-DatabaseAvailabilityGroupServer, где:
   • Identity – имя DAG группы;
   • MailboxServer – сервер с ролью почтовых ящиков, который мы хотим добавить в кластер.
3. Проверим, что сервера добавлены в кластер. Команда Get-DatabaseAvailabilityGroup.
4. Добавим пассивную копию нашей базы почтовых ящиков. Команда Add-MailboxDatabaseCopy, где:
   • Identity – имя базы, для которой необходимо создать копию;
   • Mailboxserver – имя сервера, на котором необходимо разместить копию;
   • ActivationPreference – значение, которое указывает очередность активации копии в случае внепланового выхода из строя активной копии.

   

5. Проверяем состояние копии базы командой Get-mailboxDatabaseCopy.

Наша DAG группа готова.

Настройка клиентского доступа

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

• Outlook Anywhere – это протокол, пришедший на смену протоколу RPC/TCP, недоступному начиная с Exchange Server 2013. По факту он является тем же RPC, но завернутым в HTTP, с шифрованием трафика при помощи SSL/TLS.
• Outlook Web Access (доступ через браузер)
• Протокол POP3
• Протокол IMAP
• Exchange ActiveSync (для подключения мобильных клиентов)

Все указанные способы подключения используют шифрованное соединение, требующее SAN или Wildcard SSL-сертификат. Для корректной работы с почтовым сервером, нам понадобится как минимум 2 имени в SSL сертификате. В нашем случае это имя для SMTP, HTTPS, POP, IMAP сервисов, а также имя для службы автообнаружения (autodiscover): Mail.cloud-v.datalinecentre.ru и Autodiscover.cloud-v.datalinecentre.ru.Установка сертификата. Для выпуска сертификата необходимо создать Certificate Signing Request (CSR). Данную процедуру проще всего выполнить через Exchange Control Panel (ECP):

1. Заходим в ECP.
2. Переходим в раздел Servers, вкладка Certificates. Выбираем один из наших серверов, нажимаем “+”.
3. Выбираем опцию Create a request for a certificate from certification authority.
4. Вводим Friendly name.
5. Убираем галочку для запроса wildcard сертификата, поскольку мы будем использовать SAN-сертификат.
6. Указываем, на какой сервер необходимо сохранить запрос.
7. Указываем имена, которые будет содержать наш SAN сертификат.
8. Заполняем необходимые поля.
9. Указываем путь, где будет храниться наш CSR. Жмем Finish.
10. Готово. CSR создан. На основании нашего CSR выпускаем сертификат и устанавливаем его на сервер.
11. Заходим в консоль ECP. В разделе Servers переходим во вкладку Certificates. В поле Status жмем Complete.
12. Указываем путь до папки, в которой лежит наш сертификат.
13. Сертификат добавлен. Важно, чтобы статус сертификата был Valid.
14. Теперь назначим на него сервисы SMTP, IIS, POP, IMAP. Дважды кликаем по нашему сертификату, заходим в Services и проставляем галочку напротив необходимых нам сервисов.
15. Жмем Yes при появлении предупреждения.

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

1. Открываем Microsoft Management Console (MMC), добавляем оснастку управления сертификатами компьютера.
2. Заходим во вкладку персональных сертификатов, экспортируем.
3. Выполняем экспорт приватного ключа.
   • 
   • 
   • 
   • 
4. Указываем безопасный пароль, который нужно ввести при импорте сертификата.
5. Указываем место, куда будет сохранен сертификат. Жмем Finish.
6. Экспортированный сертификат переносим на оставшийся сервер. В нашем случае это msk-exh02. Открываем MMC, добавляем оснастку управления сертификатами компьютера, заходим во вкладку персональных сертификатов, импортируем.
7. Указываем путь до сертификата.
8. Указываем пароль, который мы задали при экспорте. Также можно поставить галочку возможности экспорта приватного ключа.
9. Готово. Сертификат импортирован вместе с приватным ключом.
   • 
   • 
   • 
   • 
10. Проверим, что при заходе в OWA в браузере фигурирует корректный сертификат.
    • 
    • 
    • 
    • 

Настройка виртуальных директорий. С помощью виртуальных директорий клиенты получают доступ к OWA, ECP, адресной книге(OAB), протоколу ActiveSync, Веб службам (EWS). В нашем случае для настройки виртуальных директорий мы задаем параметр ExternalURL. Служба автообнаружения (autodiscover) будет отдавать его клиентам. Также можно указать параметр InternalURL, если в вашей организации имеются доменные клиенты, подключающиеся к Exchange в пределах локальных сетей организации. Открываем EMS и поочередно выполняем настройку виртуальных директорий с помощью команд:

1. Get-EcpVirtualDirectory | Set-EcpVirtualDirectory –externalURL “Внешний URL директории”
2. Get-OwaVirtualDirectory | Set-OwaVirtualDirectory –externalURL “Внешний URL директории”
3. Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory –ExternalURL “Внешний URL директории”
4. Set-OabVirtualDirectory | Set-OabVirtualDirectory –externalURL “Внешний URL директории”
5. Get-ActiveSyncVirtualDirectory | Set-ActiveSyncVirtualDirectory –ExternalURL “Внешний URL директории”

Настройка служб автообнаружения. Autodiscover автоматически конфигурирует клиентов Microsoft Outlook и передает параметры подключения к серверу, что существенно облегчает жизнь администраторам. Подробнее об этой службе можно почитать здесь и здесь. Служба Outlook Anywhere позволяет настроить удаленный доступ к Exchange и мобильное приложение Outlook. Для работы Outlook Anywhere требуется задать имя подключения к службе, в нашем случае это Mail.cloud-v.datalinecentre.ru. Открываем EMS и выполняем команду:Get-OutLookAnyWhere | Set-OutlookAnyWhere –ExternalHostName “внешнее имя подключения к службе” –ExternalClientRequireSsl:$true –IISAuthenticationMethods “Basic”,”NTLM”,”Negotiate” –ExternalClientAuthenticationMethod “Negotiate” Для обеспечения работы Autodiscover мы добавили 2 А-записи во внешней DNS зоне, указывающие на сервера Exchange:

• Autodiscover.cloud-v.datalinecentre.ru 185.99.13.17
• Autodiscover.cloud-v.datalinecentre.ru 185.99.13.19

Проверим, что клиенты Microsoft Outlook подключаются. Создаем профиль, указываем email адрес и пароль:

Клиенты Outlook подключаются корректно.

Конфигурация почтового транспорта

“Из коробки” сервер Exchange позволяет отправлять почту лишь внутри организации. Для отправки почты в Интернет нужно:

• Создать обслуживаемые домены. Это адресное пространство, которое обслуживает наш почтовый сервер Exchange. Можно создавать несколько доменов.
• Создать коннектор отправки. С его помощью мы можем управлять почтовым потоком, задавая различные настройки.

1. В ECP в разделе mail flow переходим во вкладку accepted domains. Жмем “+”. Указываем имя нашего домена, выбираем тип Authoritative. Сохраняем.
2. В разделе mail flow переходим во вкладку send connectors. Жмем “+”. Задаем имя и указываем тип Custom.
3. Указываем отправку через MX-записи.
4. Указываем адресное пространство. В нашем случае это “*”, означающая всё пространство доменных имен.
5. Указываем сервера, с которых будет происходить отправка почты за пределы организации Exchange. В нашем случае это оба сервера. Кликаем Add.
   • 
   • 
   • 
   • 
6. Чтобы наш сервер успешно проходил антиспам проверки, в коннекторе отправки указываем параметр FQDN HELO. Это имя, которым будет представляться наш сервер при создании SMTP-сессии. Принимающий почту сервер будет выполнять reverse dns lookup, сопоставляя имя PTR-записи с именем, которое мы указали в коннекторе отправки. При несовпадении имен, сервер-отправитель не пройдет антиспам проверку. Для настройки имени HELO заходим в параметры коннектора отправки и вводим имя нашего сервера.

Это все шаги, необходимые для базовой настройки почтового сервера из шаблона Exchange Server 2013. Задавайте вопросы в комментариях, если что-то осталось непонятным.Используемые источники:

• https://hobbycomp.ru/soft/ustanovka-exchange-server-2016-na-windows-server-2016/
• https://ait.in.ua/on-premise/exchange/bazovaya-nastrojka-exchange-server-2019-chast-1.html
• https://habr.com/post/311306/