top of page

Внедрение Exchange 2013 (2016).

Курс 20341.

Меню изучения Exchange 2013

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

Exchange Server 2010: Быстрый старт.

https://www.youtube.com/watch?v=OBEn2wQICM0

Заметки к ролику:

- подготавливайте схему и проводите установку под одной учёткой. После установки, если будете логиниться под другой, будут проблемы с правами. Новую учетку надо добавлять в группы Exchange в AD;

- Configure Client Access server external domain. На этапе установке вас спросят имя, по которому ваши пользователи смогут обращаться к вашему почтовому серверу из сети Интернет (имя сервера Client Access снаружи). Client Access это сервер, к которому подключаются ваши клиенты (неважно, снаружи или изнутри). Снаружи это имя будет другое. Например внутри, Client Access имя будет типа Exchange.adatum.local, а снаружи к нему будут подключаться как к  mail.adatum.ru. Соответственно, если на этапе установки вы знаете по какому имени он будет доступен снаружи (обычно mail.имя_вашего_домена), то можете смело это имя указывать в процессе установки. Если не знаете, можете пропустить этот момент. Разница в том, что когда вы указываете внешнее имя Client Access, то мастер установки пропишет это имя во всех необходимых настройках. Если не указываете, пробегаетесь после установки вручную.

​

​

​

​

Введение.

В Exchange 2013 есть три роли: Mailbox, CAS и Edge. Отсутствует роль Hub Transport, которая была в 2010. Она отвечала за маршрутизацию сообщений внутри компании и наружу. Сейчас этот функционал фактически реализован на Mailbox.

В Exchange 2016 осталось две роли: Mailbox и Edge. Т.е. все внутренние роли объединены в один Mailbox сервер. Edge отвечает за фильтрацию спама и является своеобразным SMTP Relay'ем. Проще говоря в 2016 у нас есть внутренний сервер и опциональный пограничный, которого может и не быть, если вы используете сторонние решения.

​

Модуль 4.

CAS.

​

CAS (синий прямоугольник на рисунке) - это прокси, через который идут все подключения. Неважно, совмещены ли у вас роли или нет. Всё равно все подключения идут через службу клиентского доступа.

Начнём слева направо.

OWA (Outlook Web App) - это доступ через браузер. Подключение идет к веб-серверу CAS по 443 порту. CAS проксирует на Mailbox по тому же 443 порту. Т.е. https вошло и https ушло. Проксирование может осуществляться и в рамках одного сервера.

Outlook, и внешний и внутренний, всегда подключается по 443 порту. Проксируется аналогично OWA.

EAS (Exchange Active Sync) - это подключение с мобильных телефонов. Подключение аналогично.

EAC (Exchange Administrative Center) - админка. 

PowerShell подключается аналогично.

POP3 и IMAP не используют 443 порт. Они идут к собственным сервисам на CAS'е и проксируются по тем же по протоколам POP3 и IMAP на Mailbox.

SMTP. Есть интересный момент. На картинке показано, что он проксируется. Но это необязательно. Дело в том, что Mailbox - это полностью функциональный транспортный сервер. Ему никто не нужен, он может все сценарии обрабатывать сам. Но, у вас внешний SMTP-трафик может проксироваться через CAS. Т.е. почта из интернета проходит на CAS, CAS её проксирует на Mailbox, Mailbox её принимает. Причём CAS для всех сценариев является тонким прокси. Т.е. если Mailbox отваливается, работать ничего не будет - почта не придёт, клиент не подключиться и прочее. У CAS'а нет БД, где он может держать почту, пока Mailbox недоступен. Он просто будет рубить сессии. Итого, вариант проксирования SMTP через CAS (и из интернета и в интернет) является опциональным.  Т.е. может быть, а может не быть. Вопрос: зачем тогда разные варианты? У вас к Exchange открыт доступ снаружи (ну как минимум для клиентских подключений). Если у вас роли разные (отдельно CAS, отдельно Mailbox), для клиентских подключений вы открываете доступ к CAS'у. Чтобы не открывать никакого доступа к Mailbox'у, вы можете проксировать почту через CAS, а порты на Mailbox'е не будут доступны из интернета. Знайте, CAS никак не участвует в роутинге почты внутри вашей организации. Всё что он может - это проксирование из интернета на Mailbox, а с Mailbox'а в интернет. 

UM (unified messaging). В отличии от клиентских подключений здесь другой сценарий. Например Lync Server или Skype for Business Server ломится на CAS и его редиректит на Mailbox. Не проксирует, а именно редиректит. Это характерно только для UM подключений.

​

Autodiscover. Автообнаружение.

Логика работы:

У нас есть сервер Exchange (вернее, если роли разделяем, то CAS, если не разделяем, то просто назовём Exchange). На сервере Exchange есть веб-сервер IIS. В IIS есть специальная директория Autodiscover. В этой директории лежит файл Autodiscover.xml.

Клиент, который хочет настроиться, запрашивает с сервера Exchange файл Autodiscover.xml. Сервер Exchange собирает под клиента файл Autodiscover.xml, включая туда все необходимые имена, по которым клиент может подключиться (внутри, снаружи, через Outlook, через Active Sync и т.д.) для доступа к различному функционалу (веб-сервисам, офлайн адресной книге и прочее).

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

Если клиент внутренний (доменный), то он уже аутентифицирован. В логике работы Outlook (начиная с 2007) заложено, что нужно обратиться к КД и запросить у него объект SCP (Service Connection Point). SCP содержит ссылку на адрес подключения к Autodiscover.xml изнутри. Эта ссылка прописывается в AD при установке Exchange. Для каждого CAS сервера будет своя ссылка. Посмотреть эту ссылку можно через ADSIEdit, либо в EMS командой Get-ClientAccessServer | fl *URI*

При настроенном Outlook'e можно увидеть эту ссылку, нажав ПКМ на иконке Outlook в трее при зажатой клавише Ctrl, и выбрать "Проверить автоконфигурацию эл. почты" (Test E-mail AutoConfiguration). В появившемся окне выберите только галку "Использовать автоопределение" (Use AutoDiscover) и нажмите "Проверка" (Test). На вкладке "Журнал" (Log) будет отображена ссылка на файл. 

Если клиент внешний, то ситуация сложнее, т.к. он не аутентифицирован. 

Внешний клиент в почтовой программе набирает адрес своей эл.почты и пароль и нажимает Далее. После этих действий начинается процедура автообнаружения. Её работу рассмотрим на примере домена contoso.com:

1. После того как вы указали адрес эл.почты, клиент по https запросу идёт к корню домена (https://contoso.com/Autodiscover/Autodiscover.xml). В большинстве случаев клиент не сможет таким образом подключиться к CAS, т.к.  contoso.com обычно ведёт на ваш публичный сайт и имя contoso.com с вашим Exchange никак не связано.

2. Когда вариант1 не срабатывает, клиент делает https запрос к записи Autodiscover (https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml). Если в DNS есть запись autodiscover, то всё проходит успешно и клиент получает заветный xml-файл.

Итого. Чтобы у вас заработало автообнаружение снаружи, вы должны добавить в DNS запись типа A, которое будет разрешать имя autodiscover во внешний IP-адрес, по которому ваш CAS доступен по 443 порту.

Если у вас несколько CAS-серверов, вам надо создать несколько записей autodiscover, каждая из которых разрешается в IP-адрес конкретного CAS. 

​

Подключиться к службе автообнаружения это одно. Но служба автообнаружения должна вернуть корректные имена для подключения внутри и снаружи. Эти имена надо прописать.

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

1. Outlook. Внешний и внутренний. Т.к. мы работаем с Exchange 2013, вариант подключения называется RPC over HTTP (и изнутри и снаружи). Кстати, в 2016 (или в 2013 с последним кумулятивным пакетом) для свежих клиентов будет доступен вариант  MAPI over HTTP (и изнутри и снаружи) и он является предпочитаемым. Т.е. если у вас Exchange 2016 и 2016-е клиенты, будет именно этот вариант.  И RPC over HTTP и MAPI over HTTP это 443 порт. Пусть вас не смущает, что указывается HTTP. Так везде пишется в документации. По факту используется HTTPS (т.е. тот же HTTP, только с шифрованием).  

2. Active Sync. Внешний и внутренний.

3. OAB (офлайн адресная книга). Внешняя и внутренняя.

4. EWS (Exchange Web Services, Exchange веб-сервисы). Внешние и внутренние.

5. OWA. Внешняя и внутренняя.

6. ECP (Exchange Control Panel). Внешний и внутренний.

Итак, давайте прописывать настройки.

Сразу определяемся, что имя подключения и изнутри и снаружи будет одно. Так просто удобнее. Т.е. mail.adatum.com. В этом случае помните, что внутри это имя должно разрешаться во внутренний IP-адрес, снаружи во внешний IP-адрес. 

Итак, заходим на CAS-сервер и через консоль EMC прописываем настройки.

 

1. Outlook. 

Командой Get-OutlookAnywhere -Server lon-cas1 посмотрим настройки для нашего сервера lon-cas1 (OutlookAnywhere это подключение Outlook'а изнутри и снаружи через RPC over HTTP).

Обратите внимание на скриншот выше. Внутренне имя задано (но его надо менять), а внешнее нет.

Указываем внутреннее и внешнее имя:

Get-OutlookAnywhere -Server lon-cas1  | Get-OutlookAnywhere -InternalHostName mail.adatum.com -ExternalHostName mail.adatum.com

Но OutlookAnywhere потребует ввода дополнительных параметров, поэтому предыдущая команда целиком будет выглядеть:

Get-OutlookAnywhere -Server lon-cas1  | Get-OutlookAnywhere -InternalHostName mail.adatum.com -ExternalHostName mail.adatum.com -InternalClientRequireSsl $true -ExternalClientRequireSsl $true -InternalClientAuthenticationMethod Negotiate -ExternalClientAuthenticationMethod Negotiate

 

-InternalClientRequireSsl $true - внутренние клиенты требуют шифрования

-ExternalClientRequireSsl $true - внешние клиенты требуют шифрования

-InternalClientAuthenticationMethod Negotiate - внутренний способ аутентификации =  Negotiate (Negotiate это согласование, т.е. изначально используется Kerberos, а если не получилось, то NTLM). Версии ранее Exchange 2013 не поддерживают метод Negotiate.

​

С Outlook закончили. Идём дальше.

​

2. Active Sync.

Вводим:

Get-ActiveSyncVirtualDirectory -Server lon-cas1  | fl *URL*

Эта команда покажет виртуальные директории.

Как видим, внутренний URL задан, а внешний нет.

Указываем их:

Get-ActiveSyncVirtualDirectory -Server lon-cas1  | set-ActiveSyncVirtualDirectory -InternalUrl "https://mail.adatum.com/Microsoft-Server-ActiveSync" -ExternalUrl "https://mail.adatum.com/Microsoft-Server-ActiveSync"

​

3. OAB.

Get-OabVirtualDirectory -Server lon-cas1  | fl *URL*

Указываем внутренний и внешний URL:

Get-OabVirtualDirectory -Server lon-cas1  | set-OabVirtualDirectory -InternalUrl "https://mail.adatum.com/OAB" -ExternalUrl "https://mail.adatum.com/OAB"

​

3. EWS.

Get-WebServicesVirtualDirectory -Server lon-cas1  | fl *URL*

Get-WebServicesVirtualDirectory -Server lon-cas1  | set-WebServicesVirtualDirectory -InternalUrl "https://mail.adatum.com/EWS/Exchange.asmx" -ExternalUrl "https://mail.adatum.com/EWS/Exchange.asmx"

​

Все эти действия можно сделать и через графический интерфейс.

Давайте на примере OWA посмотрим, как это сделать. 

Во вкладке Servers переходим в Virtual Directories. В выпадающем списке выбираем наш CAS. И можем выбрать, к примеру, OWA.

Итак, мы сейчас поменяли все клиентские подключения (6 пунктов, описанных выше). Но есть ещё одно подключение​ - это подключение к внутренней службе автообнаружения. По умолчанию оно идёт по имени сервера. Это имя тоже нужно поменять, потому что если будет подключение по другому имени, его нужно будет добавлять в сертификат, а это неудобно. 

Командой Get-ClientAccessServer | fl *URL* получаем информацию, откуда берётся Autodiscover.

И меняем ссылку командой Get-ClientAccessServer | Set-ClientAccessServer -AutodiscoverServiceInternalUri "https://mail.adatum.com/Autodiscover/Autodiscover.xml".

Проверяем результат предыдущей командой Get-ClientAccessServer | fl *URL*

Итак, настройки прописали. Теперь надо разобраться с DNS и сертификатами.

Идём на КД и во внутренней зоне DNS создаем запись mail, которая разрешается в IP-адрес (такой же как у lon-cas1). 

Клиенты шифруют абсолютно все коммуникации с вашим сервером. Внутри или снаружи - без разницы. Всё шифруется. А для расшифрования используется сертификат. Какие есть варианты:

1. Сгенерировать самоподписанный сертификат. Т.е. взять какую-нибудь утилиту, типа SelfSSL и сгенерировать сертификат. Но такой вариант я не рассматриваю. Самоподписанный сертификат не будет никому доверенный. Кстати у Exchange есть самоподписанный сертификат, но он используется не для шифрования. Итого, вариант с самоподписанным сертификатом - плохой вариант.

2. Использовать свой CA, развернув AD CS. Вариант нормальный, но у него есть недостаток. При подключении снаружи, все внешние клиенты будут ругаться, что сервер, к которому они подключаются, используют недоверенный сертификат и т.д. Итого придётся бегать за каждым клиентом и запихивать ему корневой сертификат своего центра в доверенные.

 3. Купить коммерческий сертификат и не париться.

P.S. Сертификат вам нужен один на все типы подключений. Но можно использовать и различные, для каждого типа подключения (т.е. отдельно будет для POP/IMAP, отдельно для 443 и прочее). Смысла особого в этом нет. Проще использовать один.

Есть ещё вариант - бесплатные сертификаты.

Гуглим WoSign Free, переходим на сайт и получаем у китайских друзей сертификат бесплатно. С такими сертификатами могут возникнуть проблемы на старых клиентах (н-р необновленная Win7). Косяк в том, что сертификат показывается как недоверенный.

Есть ещё контора StartSSL, где можно получить бесплатный сертификат.

По бесплатным сертификатам можете почитать статью http://itband.ru/2016/02/certificate-free/

​

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

Как видите, в списке уже есть сертификаты. Но нас они не интересуют.

​

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

Чтобы сгенерировать запрос на сертификат, жмём + в окне на скриншоте выше. Выбираем, какой сертификат мы хотим - из CA или самоподписанный.

На следующей странице вводим имя сертификата, т.е. как он будет отображаться у вас в консоли. Укажем, к примеру, Exchange New Certificate. На следующей странице указываем, будет ли сертификат Wildcard'ным, т.е. *.vashdomain. Exchange поддерживает  Wildcard'ные сертификаты. Но нам это не надо. Хотя, если у вас один почтовый домен, то можно использовать. Не ставим галку. Выбираем сервер, на котором будет сгенерирован сертификат. В нашем случае lon-cas1.

В следующем окне,  Exchange вытаскивает из конфига все имена, которые вы прописали.

​

​

Эти имена будут в сертификате. Практически везде будет mail.adatum.com, который мы указывали во всех настройках. Единственное, что мы не меняли, это имена для подключения POP и IMAP. Поэтому, как видите, напротив них имя lon-cas1.

Идём дальше. На следующей странице можно убрать имена. Уберём короткие имена (например, lon-cas1), т.к. они нам не нужны. Оставляем mail.adatum.com, как имя для подключения (выделен жирным). Под ним будут autodiscover-имена для каждого домена. Лишние уберём, оставив только то, что касается adatum.

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

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

Жмём финиш и переходим в папку. В ней мы увидим файл-запрос, который можно посмотреть обычным блокнотом.

С этим файлов мы идём на центр сертификации.

Заходим на ЦС через браузер http://lon-dc1/certsrv и кликаем Request a certificate.

Помните, что для Exchange-сервера используются сертификаты компьютера плюс сертификаты шаблона веб-сервер. Поэтому переходим в Advanced certificate request и выбираем "Получить сертификат на основе кодировки base-64". 

В появившемся окне вставляем текст из файла с запросом и выбираем шаблон сертификата Web Server. 

Нажимаем Submit и получаем сертификат с открытым ключом. Закрытый ключ сгенерирован на сервере, где вы запускали процедуру получения сертификата. Т.е. на вашем ЦС.

Оставляем DER encoded и нажимаем Download certificate. Сохраняем его в нашу шару. Возвращаемся в админку Exchange.

Как видим, запрос, который мы сгенерировали, находится в статусе "в ожидании". Нажимаем Complete и указываем путь до сертификата, который лежит в нашей шаре.

Итак, сертификат готов, но пока никем не используется. Открываем его и на вкладке services указываем, под какие службы он будет использоваться. Если вы хотите, чтобы его использовали Outlook, OWA, ActiveSync, надо поставить единственную галку IIS.

После таких операций, как привязка сертификата, изменение имён, по которым подключаются клиенты, не забывайте на Exchange перезапускать веб-сервер. Делается это через PS командой iisreset. Причем если у вас несколько серверов (н-р отдельно CAS, отдельно Mailbox), то перезапуск надо делать на обоих.

Также помните, что клиенту необходимо добавить в доверенные центры сертификат вашего ЦС. Он имеет расширение .crt и лежит в \\имя_вашего_ЦС в папке CertEnroll.   

Имена, по которым клиенты будут подключаться и сертификаты лучше настраивать заранее, до подключения клиентов. И вот почему. Итак, мы выполнили настройки, сделали сертификаты. Перезапускаем Outlook. И начинается геморрой. При запуске он скорее всего ругнётся, что имя в сертификате не соответствует имени по которому мы подключаемся. Поэтому надо сделать Repair подключения. В Outlook идём в настройку учетных записей и там жмакаем Repair (Восстановить), чтобы Outlook подхватил новые настройки. Иногда это может и не помочь и придётся заново создавать почтовый профиль (через панель управления удаляем старый). После пересоздания профиля, запускаем Outlook и если всё работает проверяем настройки. ПКМ+Ctrl в трее на Outlook -> Состояние подключения. И тут можно увидеть, по какому адресу мы коннектимся. Также ПКМ на иконке и выбираем Проверить автоконфигурацию. На вкладке XML будут все имена, которые мы ранее прописывали. Поэтому, если вдруг возникнет ошибка (а вы уверены, что всё прописали, привязали сертификат), что имена в сертификате не соответствуют, надо смотреть вкладку XML. Копируем содержимое вкладки XML и вставляем в блокнот. Поиском ищем, по какому имени ломится Outlook. И вероятно вы найдёте косяк. Н-р это имя указано в настройках OWA. И вы действительно вспоминаете, что OWA перенастроить забыли. Так что идёте и прописываете.

Итого, запоминайте процедуру:

1. Определиться с именами.

2. Пройтись по всем директориям и прописать имена.

3. Выдать и привязать, где нужно, сертификат.

bottom of page