Using exchange control panel (ecp) to manage an exchange organization (part 1)

Неограниченные возможности масштабирования

Exchange Server 2016 обладает практически неограниченными возможностями масштабирования, он может объединять сотни тысяч пользователей под одним почтовым доменом. В организации может быть установлено неограниченное количество почтовых серверов, сами сервера могут быть разбросаны географически по всему миру, каждый из серверов может содержать ящики различных пользователей. Причём администраторам не придётся настраивать маршрутизацию почты, Exchange это сделает автоматически на основании топологии сайтов Active Directory. Как и Exchange Server 2013, Exchange 2016 имеет ролевую модель, что позволяет ещё больше распределять нагрузку и повышать гибкость администрирования.

Introduction

In this article series I will be discussing all options available through the ECP and in this first article I’ll start with the User and Mailbox section covering mailbox, contacts and distribution group management.

The ECP authentication by default follows the Outlook Web App settings but we can manage that separately on the Client Access Server, Exchange Control Panel tab as shown in Figure 01.

Figure 01

So, if you have already configured your Outlook Web App and it is working like a charm, let’s try the https://yourdomain.com/ECP and here you will get access to the management stuff using the same authentication process that we would use to access Outlook Web App. The main page is similar to the one shown in Figure 02, where we have four categories: Users & Groups, Roles & Auditing, Mail Control, Phone & Voice and each one of them has sub categories.

Figure 02

If you are already logged on in Outlook Web App, you can click Options and then See all Options, and then click on the option Manage Myself and change to My Organization. All areas that the current user has access will be available to be managed through the web interface.

Шаг 9. Изменение индекса старшина членов

Чтобы изменить атрибут членов msDS-HABSeniorityIndex, используйте оснастку ADSI Edit или служебную программу LDAP.

В этом примере Дэвид Гамильтон (David Hamilton), Rajesh M. Patel (Rajesh M. Patel) и Ами Ламбертс ( Amy Simon Hamilton) принадлежат к организации с именем Corporate Office. Эти пользователи создаются в подразделении Contoso-dom.Contoso.com/Users. Дэвид Гамильтон является вице-президентом организации. Компания хочет отобразить Дэвида Гамильтона в верхней части списка участников, чтобы сотрудники могли легко понять, кто управляет этой организацией.

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

Откройте ADSI Edit, разверните контекст именования по умолчанию, а затем разверните подразделение OU=User, в котором создается объект пользователя Дэвид Гамильтон.
Щелкните правой кнопкой мыши CN=David Hamilton и выберите пункт «Свойства».
В диалоговом окне «Свойства CN=David Hamilton » перейдите на вкладку » Редактор атрибутов «. В разделе «Атрибуты » найдите msDS-HABSeniorityIndex и нажмите кнопку «Изменить «. Снимок экрана для этого этапа приведен ниже.
В редакторе целочисленных атрибутов введите целочисленное значение, определенное для пользователя (например , 100), и нажмите кнопку «ОК».
В диалоговом окне «Свойства CN=David Hamilton» нажмите кнопку «ОК».
Повторите шаги 2–5 для другого члена. В этом примере повторите шаги 2–5 для Rajesh M. Patel с индексом старшести 50 и для Ами Ламбертс с индексом старшести 10.

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

Configure EWS, Autodiscover, OWA, OAB, ECP on Exchange Server 2010

Select the “Use AutoDiscover” and click Test..

Above one is a success one..If failed, do the below. The Exchange Web Service (EWS) is the web service that allows access to the Out of Office service. If either the internal or external URL for the EWS is missing or incorrect, OOF will fail and other services may not work as expected. Using Exchange Management Shell, check the URLs assigned to the web service virtual directory using the Get-WebServicesVirtualDirectory command

First goto CAS server

Type the following Power Shell command for EWS (Exchange Web Service)

Copy code Get-WebServicesVirtualDirectory |fl identity,internalurl,externalurl

You will get the result like below

If this is not correct, you need to fix it.. This has to be done on Powershell command on the CAS server.

To do that…Copy code

C:\Windows\system32>Get-WebServicesVirtualDirectory |fl identity,internalurl,externalurl

Now you can see that the URL has been fixed. This is for Web Services.

Now for Autodiscovery….

C:\Windows\system32>Get-AutodiscoverVirtualDirectory

To see the settings

C:\Windows\system32>Get-ClientAccessServer |fl identity,autodiscoverserviceinternaluri

RESULT

To FIX it..

Now for the Outlook Web Apps, Exchange Control Panel, Exchange ActiveSync, Offline Address book…you have to go to Exchange Management Console (EMC)

Goto one of the CAS server
Open EMC
Goto Server Configuration
Select Client Access
On the Middle top pannel, you can see the CAS server listed.
Select one, on the bottom pannel, you will see like below.

Select each tab and then right click on the object and change the path as required. Once you done with the first CAS servr, do the same for the second as well.

Thats it…you are good to go for production.

Настройка балансировка HTTPS траффика

После того, как мы настроили балансировку SMTP траффика нам необходимо настроить балансировку HTTP/HTTPS траффика.

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

Мы будем использовать конфигурацию без преаутентификации и разгрузки SSL (without SSL Offload and ESP).

За опорную документацию по настройке мы будем использовать

Итого, что нам нужно сделать:

1. Перейти в веб-интерфейс управления нашим балансировщиком:

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:

Типы использования соединителей получения

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

При создании соединителей получения в Центре администрирования Exchange мастер предлагает выбрать значение Тип для соединителя. При использовании командлета New-ReceiveConnector в командной консоли Exchange используется параметр Usage с одним из доступных значений (например, ), или назначенный параметр для типа использования (например, ).

Тип использования можно указать только при создании соединителей получения. Создав соединитель, вы можете изменить доступные механизмы проверки подлинности и группы разрешений в Центре администрирования Exchange или с помощью командлета Set-ReceiveConnector в командной консоли Exchange.

Доступные типы использования представлены в приведенной ниже таблице.

Тип использования	Назначенные группы разрешений	Доступные механизмы проверки подлинности	Comments
Client	Пользователи Exchange ()	Безопасность транспортного уровня ()Обычная проверка подлинности ()Предлагать обычную проверку подлинности только после запуска TLS ()Интегрированные проверка подлинности Windows ()	Используется клиентами POP3 и IMAP4, которым требуется отправлять электронные сообщения по протоколу SMTP с проверкой подлинности. При создании соединителя получения с этим типом использования в Центре администрирования Exchange или командной консоли Exchange невозможно выбрать привязки локальных IP-адресов и TCP-порт. По умолчанию этот тип использования привязан ко всем локальным IPv4- и IPv6-адресам для TCP-порта 587. Вы можете изменить эти привязки после создания соединителя. Этот тип использования недоступен на пограничных транспортных серверах.
Пользовательские	Не выбрано ()	Безопасность транспортного уровня ()	Используется в сценариях с несколькими лесами для получения почты от сторонних серверов обмена сообщениями, а также для внешней ретрансляции. Создав соединитель получения с этим типом использования, необходимо добавить группы разрешений в Центре администрирования Exchange или командной консоли Exchange.
Внутренний	Устаревшие серверы Exchange ()Серверы Exchange ()	Безопасность транспортного уровня ()проверка подлинности Exchange Server ()	Используется в сценариях с несколькими лесами для получения почты от предыдущих версий Exchange или от сторонних серверов обмена сообщениями либо на пограничных транспортных серверах для получения исходящей почты из внутренней организации Exchange. При создании соединителя получения с этим типом использования в Центре администрирования Exchange или командной консоли Exchange невозможно выбрать привязки локальных IP-адресов и TCP-порт. По умолчанию соединитель привязан ко всем локальным IPv4- и IPv6-адресам для TCP-порта 25. Вы можете изменить эти привязки после создания соединителя. Группа разрешений недоступна на пограничных транспортных серверах.
Интернет	Анонимные пользователи ()	Безопасность транспортного уровня ()	Используется для получения почты из Интернета. При создании соединителя получения с этим типом использования в Центре администрирования Exchange или командной консоли Exchange невозможно выбрать удаленные IP-адреса. По умолчанию соединитель принимает удаленные подключения со всех IPv4-адресов (0.0.0.0-255.255.255.255). Вы можете изменить эти привязки после создания соединителя.
Партнер	Партнеры ()	Безопасность транспортного уровня ()	Используется для настройки защищенного соединения с внешним партнером (взаимная проверка подлинности TLS, также называемая защитой на уровне домена).

Сокращение затрат на оборудование, программное обеспечение и обслуживание

Как бы это не было парадоксально, но даже если у вас уже развёрнут Exchange Server 2013 или тем более Exchange Server 2007, переход на Exchange Server 2016 позволит сэкономить прямые затраты на оборудование, программное обеспечение и поддержку ИТ-инфраструктуры.

Сокращение затрат на оборудование. В Exchange Server 2016 была значительно переработана система ввода/вывода обращений к дисковой подсистеме. Таким образом, удалось на 75% сократить нагрузку на дисковую подсистему по сравнению с Exchange Server 2007, и на 50% по сравнению с Exchange Server 2013. И если раньше для почтовой базы требовались дорогие дисковые массивы RAID 10 на базе дисков SCSI или SAS, то теперь можно обойтись простыми SATA дисками, объединёнными в массивы RAID 5. Кроме того, ранее для построения кластера Exchange Server 2003 требовалось обязательное наличие сети хранения данных SAN и дисковых массивов iSCSI или FC, которые стоят десятки тысяч долларов. Также в таком кластере была единая точка отказа – это сам дисковый массив. Можно было конечно приобрести отказоустойчивые массивы с аппаратной репликацией данных, но это уже цены порядка сотен тысяч долларов. Всё это более не требуется, если вы внедряете кластер на базе Exchange Server 2016. Технология DAG сама по себе обеспечивает репликацию данных, и для неё вообще не требуется сети хранения данных SAN и общего дискового массива. А в качестве кворума может использоваться простая общая папка. Но даже если брать CCR кластер на базе Exchange Server 2007, получалось, что один сервер активный, а второй сервер пассивный. Т.е. вы покупали 2 мощных сервера, а 99% процентов времени работал только один, а второй просто простаивал, потребляя электроэнергию. В Exchange Server 2016 при использовании DAG, все сервера работают одновременно и являются активными.

Сокращение затрат на программное обеспечение. Ранее для построения кластера Exchange Server 2007 требовалось приобрести, как минимум 2 Exchange Server 2007 Enterprise Edition, стоимостью около 4000$ каждый, для роли Mailbox и 2 Exchange Server 2007 Standard Edition стоимостью 700$ каждый для ролей Client Access и HUB Transport. Теперь кластер Exchange Server 2016 может быть построен на базе Exchange Server 2016 Standard Edition. Кроме того теперь все роли могут быть совмещены на одном сервере, и по сути кластер можно построить, приобретя всего 2 сервера Exchange Server 2016 Standard за 700$ каждый (при использовании программного или аппаратного балансировщика нагрузки для роли Client Access).

Сокращение затрат на обслуживание. Как уже говорилось выше, Exchange Server 2016 имеет ряд средств, снимающих нагрузку с системных администраторов. Например подсказки Mail Tips, сообщают пользователю о проблемах или возможных ошибках, ещё при создании письма, до его отправки. Это позволяет значительно сократить число обращений в службу поддержки. Внедрив MS Exchange Server, пользователи сами смогут восстанавливать ошибочно удалённые сообщения, не обращаясь к системному администратору, чтобы тот восстановил их письмо из резервной копии. В Exchange Server 2016 каждому пользователю стала доступна специальная панель управления ECP (Exchange Control Panel), которая позволяет пользователям поменять свой доменный пароль, просматривать отчёты о доставке отправленных и полученных им сообщений, создавать и управлять группами рассылки, а также управлять своими смартфонами. И всё это можно сделать без участия системного администратора. Ежедневно в службу поддержки приходят запросы о том, что сотруднику отправили письмо, а оно не дошло, или наоборот пользователь отправлял письмо клиенту, а тот его не получил. В Exchange Server 2016 пользователи сами могут просмотреть отчёт о доставке и увидеть, что случилось с их письмом. Часто достаточно трудно добиться и проконтролировать, чтобы сотрудники использовали стандартную принятую в компании форму подписи в письмах электронной почты. В Exchange 2016 системные администраторы могут настроить динамические подписи для сообщений электронной почты, для всех сотрудников сразу. Так, например, сотрудникам отдела кадров можно делегировать управление контактной информацией.

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

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

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

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

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

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

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

В качестве сервера свидетеля мы будем использовать сервер SRV01. Операционная система – Windows Server 2012 R2. Этот сервер мы использовали в качестве сервера свидетеля при настройке DAG для Exchange 2016, т.е. все необходимые шаги по его подготовке мы уже выполнили. Если один и тот же сервер выступает в качестве свидетеля для нескольких DAG, то для каждой группы высокой доступности создается своя отдельная директория:

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

1. Установить и выполнить первоначальную настройку операционной системы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основная суть в том, чтобы, например, для почтовой базы DB05, которая расположена на сервере MBX05, создать дополнительную копию на сервере MBX06. В случае выхода из строя сервера MBX05, почтовая база DB05 будет автоматически активирована на сервере MBX06. Аналогичное справедливо и для почтовой базы DB06 на сервере MBX06.

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

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

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

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

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

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

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

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

Первоначальная настройка Exchange 2019 включает в себя настройку виртуальных директорий. В Exchange 2019 у нас присутствуют следующие виртуальные директории:

ActiveSync Virtual Directory. Виртуальная директория для протокола ActiveSync. В осносном это подключение мобильных устройств.
MAPI Virtual Directory. Эта виртуальная директория появилась в Exchange 2013 SP1. Используется современными клиентами Outlook (начиная с Outlook 2013 SP1) для подключения к почтовым ящикам через MAPI/HTTP. Этот метод подключения пришел на замену RPC over HTTP.
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.

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

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

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

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

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

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

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

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

Разрешения соединителя получения

Как правило, разрешения применяются к соединителям получения с помощью групп разрешений. Однако вы можете настраивать детализированные разрешения для соединителя получения с помощью командлетов Add-ADPermission и Remove-ADPermission.

Разрешения соединителя получения назначаются субъектам безопасности с помощью групп разрешений для соединителя. Когда клиент или сервер SMTP создает подключение к соединителю получения, разрешения этого соединителя определяют, принимается ли соединение и как оно обрабатывается.

Доступные разрешения соединителя получения представлены в приведенной ниже таблице.

Разрешение соединителя получения	Описание
	Управляет хранением заголовков лесов Exchange в сообщениях. Имена заголовков лесов начинаются с X-MS-Exchange-Forest-. Если разрешение не предоставлено, все заголовки лесов удаляются из сообщений.
	Управляет сохранением заголовков организаций Exchange в сообщениях. Имена заголовков организаций начинаются с X-MS-Exchange-Organization-. Если это разрешение не предоставлено, все заголовки организаций удаляются из сообщений.
	Управляет сохранением заголовков Received и Resent-* в сообщениях. Если разрешение не предоставлено, все эти заголовки удаляются из сообщений.
	Позволяет клиентам и серверам SMTP обходить фильтрацию спама.
	Позволяет клиентам и серверам SMTP отправлять сообщения больше максимального размера, настроенного для соединителя получения.
	Позволяет клиентам и серверам SMTP ретранслировать сообщения через соединитель получения. Если это разрешение не предоставлено, соединитель получения принимает только те сообщения, которые отправлены получателям в обслуживаемых доменах, настроенных для организации Exchange.
	Позволяет клиентам и серверам SMTP обходить проверку адреса отправителя на спуфинг, для которой обычно требуется, чтобы электронный адрес отправителя находился на обслуживаемом домене, настроенном для организации Exchange.
	Указывает, будут ли сообщения от клиентов и серверов SMTP рассматриваться как прошедшие проверку подлинности. Если это разрешение не предоставлено, то сообщения из этих источников определяются как внешние (непроверенные). Этот параметр важен для групп рассылки, настроенных для приема почты только от внутренних получателей (например, параметр RequireSenderAuthenticationEnabled для группы имеет значение ).
	Разрешает доступ к соединителю получения для отправителей, электронные адреса которых находятся на уполномоченных доменах, настроенных для организации Exchange.
	Позволяет клиентам и серверам SMTP отправлять команды XEXCH50 соединителю отправки. Большой двоичный объект X-EXCH50 использовался старыми версиями Exchange (Exchange 2003 и более ранними) для хранения данных Exchange в сообщениях (например, о вероятности нежелательной почты).
	Это разрешение необходимо для отправки сообщений соединителям получения. Если это разрешение не предоставлено, команды MAIL FROM и AUTH не будут выполняться.

Примечания.

Помимо задокументированных разрешений, существуют разрешения, которые назначаются всем субъектам безопасности в группе разрешений серверов Exchange (), кроме . Эти разрешения зарезервированы для внутреннего использования в корпорации Майкрософт и представлены здесь исключительно в справочных целях.
Имена разрешений, содержащиеся в составе функции брандмауэра заголовков . Дополнительные сведения см. в разделе Брандмауэр заголовков.

Действия с разрешениями соединителей получения

Чтобы просмотреть разрешения, назначенные субъектам безопасности соединителя получения, используйте следующий синтаксис в командной консоли Exchange:

Например, чтобы просмотреть разрешения, назначенные всем субъектам безопасности соединителя получения Client Frontend Mailbox01, выполните следующую команду:

Чтобы просмотреть разрешения, назначенные только субъекту безопасности в соединителе получения с именем Default Mailbox01, выполните следующую команду:

Чтобы добавить разрешения для субъекта безопасности, используйте следующий синтаксис:

Чтобы удалить разрешения субъекта безопасности, используйте следующий синтаксис:

Настройка коннектора отправки и приема электронной почты

Настройка коннектора отправки электронной почты

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

Что нужно для настройки этого коннектора:

1. Запустить консоль управления Exchange и перейти в соответствующий раздел настроек:

2. Запустим мастер создания нового коннектора отправки.

3. Укажем имя коннектора:

4. Этот коннектор будет использоваться для отправки писем на любой адрес. Укажем это (* в строке пространства имен):

5. У нас нет промежуточных смарт хостов и мы будет отправлять почту напрямую в конечную почтовую систему. Указываем это:

6. Разрешим обоим нашим серверам отправлять почту во внешний мир через этот коннектор:

7. Подтвердим создание нового коннектора.

$Невнимательность + кривые руки + новые технологии = owa\ecp logon loop. — exchange server field notes$

Настройка коннектора приема электронной почты

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

1. Запустить консоль управления Exchange и перейти в соответствующий раздел настроек:

2. На вкладке “Permission Group” разрешим использование этого коннектора группе анонимных пользователей, чтобы наш сервер мог принимать внешнюю почту.

3. Сохраним внесенные изменения.

4. Сделаем аналогичные настройки для коннектора “Default CAS02”:

4. Сохраним внесенные изменения.

Вход в Центр администрирования Exchange

URL-адрес Центра администрирования Exchange управляется виртуальным каталогом Службы IIS (IIS) под названием ECP, который располагается в службах клиентского доступа (интерфейсных службах) на сервере почтовых ящиков. Да, виртуальный каталог называется ECP, а не EAC.

Внутренний URL-адрес. По умолчанию это значение содержит полное доменное имя (FQDN) сервера Exchange в формате . Например, . Чтобы получить доступ к EAC в веб-браузере на самом сервере Exchange Server, можно использовать значение .
Внешний URL-адрес. По умолчанию это значение не настроено. Для подключения к Центру администрирования Exchange через Интернет, необходимо настроить указанные ниже параметры.
- Внешний URL-адрес для виртуального каталога ECP. Дополнительные сведения см. в разделе в статье Настройка потока обработки почты и клиентского доступа на серверах Exchange Server.
- Соответствующую запись в общедоступном DNS.
- Сертификат TLS, содержащий или соответствующий записи имени узла. Скорее всего, это будет сертификат альтернативного имени субъекта (SAN) или сертификат с подстановочными знаками, так как большинство клиентских служб доступны на одном веб-сайте на сервере Exchange Server. Дополнительные сведения см. в статье .
  
  После настройки параметров общее значение внешнего URL-адреса для EAC будет выглядеть так: .
  
  Примечание. Внешним пользователям, подключающимся к Outlook в Интернете (ранее Outlook Web App), также требуется доступ к EAC для доступа к собственной странице параметров. Вы можете отключить доступ внешнего администратора к EAC, но при этом разрешить пользователям доступ к странице параметров в Outlook в Интернете. Дополнительные сведения см. в статье Отключение доступа к Центру администрирования Exchange.

Самый простой способ найти значения внутренних и внешних URL-адресов для Центра администрирования Exchange (без использованиявиртуальных каталоговсерверов> в самом EAC) — использовать командлет Get-EcpVirtualDirectory в командной консоли Exchange. Сведения о том, как открыть командную консоль Exchange в локальной организации Exchange, см. в статье Open the Exchange Management Shell.

В приведенных примерах показано, как найти значения внутренних и внешних URL-адресов виртуальных каталогов Центра администрирования Exchange в вашей организации.

Чтобы найти значения для всех серверов Exchange в организации, выполните следующую команду:
Чтобы найти значения для сервера под названием Mailbox01, выполните следующую команду:
Чтобы найти значение для виртуального каталога под названием «ecp (веб-сайт по умолчанию)» на сервере под названием Mailbox01, выполните следующую команду:

Дополнительные сведения см. в статье Get-EcpVirtualDirectory.

В Exchange 2016, если вы находитесь в среде сосуществования с Exchange 2010, расположение почтового ящика управляет поведением по умолчанию для открытия EAC или ECP:

Если ваш почтовый ящик находится на сервере почтовых ящиков Exchange 2010, то по умолчанию для Exchange 2010 открывается панель управления Exchange. Вы можете войти в Центр администрирования Exchange, добавив версию Exchange в URL-адрес (значение версии 15 как для Exchange 2013, так и для Exchange 2016). Например, для доступа к EAC через службы клиентского доступа (внешний интерфейс) на сервере почтовых ящиков с именем Mailbox01 используйте следующий URL-адрес: .
Если почтовый ящик находится на сервере почтовых ящиков Exchange 2016 и вы хотите получить доступ к ECP на сервере клиентского доступа Exchange 2010 с именем CAS01, используйте следующий URL-адрес: .

Заключение

В этой публикации была рассмотрена установка и первоначальная настройка Exchange 2019. Мы рассмотрели довольно тривиальный вариант развертывания, но именно он позволит вам понять основные шаги на всех этапах установки. Мы рассмотрели предварительную подготовку инфраструктуры Active Directory для установки первого сервера Exchange. Далее мы выполнили непосредственно установки нашего первого сервера Exchange. В заключении мы настроили минимальные основные параметры Exchange, чтобы наш сервер электронной почты мог как отправлять электронную почту во внешний мир, так и принимать электронную почту из сети Интернет.

Надеюсь, что статья будет вам полезна, а в следующих публикация мы рассмотрим процесс обновления сервера Exchange – установку актуального Update Rollup и обновлений безопасности Exchange.