У цій статті ми розберемося з тим, як настроїти статичні RPC порти для служб RPC Client Access, Exchange Address Book та служби доступу до спільних папок у Exchange 2010.

Уявимо, що ми маємо складну організацію з Exchange Server 2010 SP1 (або вище), в якій у тому числі є . Сервера CAS зазвичай розміщуються в мережі, відокремленій міжмережевими екранами від мереж, з яких передбачається доступ користувачів (мережі Outlook). Підключення клієнта Outlook до сервера CAS відбувається по RPC, а це означає на мережевому рівніможе бути задіяний будь-який порт із вільного діапазону портів. Не секрет, що в Windows Server 2008 і 2008 R2 як динамічний діапазон портів для RPC підключень використовується діапазон 49152-65535 (у попередніх версіях Windows Server використовували RPC порти в діапазоні 1025-65535).

Щоб не перетворювати брандмауери на «решето», бажано звузити діапазон портів, що використовуються RPC, в ідеалі, зробивши їх статичними на кожному сервері Client Access Server в масиві Client Access. Крім того, використання статичних RPC портів дозволяє знизити споживання пам'яті на пристроях балансування навантаження (особливо HLB) і спростити їх конфігурування (не потрібно вказувати великі діапазони портів).

У Exchange 2010 для служби RPC Client Access, а також для служби адресної книги Exchange можна встановити статичні порти. Outlook взаємодіє з цими службами через інтерфейс MAPI.

Статичний порт для служби Exchange 2010 RPC Client Access

Віртуальна служба Exchange 2010 RPC Client Access пов'язана зі службою доступу клієнтів RPC Client, до якої в Exchange 2010 підключаються клієнти Outlook MAPI. Коли клієнт Outlook підключається до Exchange, на сервері Exchange 2010 Client Access службою RPC Client Access для вхідних підключень використовується порт TCP End Point Mapper (TCP/135) та випадковий порт із динамічного діапазону портів RPC (6005-59530)

Щоб у Exchange 2010 для служби RPC Client Access встановити статичний порт, необхідно в редакторі реєстру відкрити розділ:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeRPC

Створіть новий ключ з ім'ям ParametersSystem, всередині якого створіть параметр типу REG_DWORD з ім'ям TCP/IP Port. У TCP/IP Port задається статичний порт для служби RPC Client Access. У документації Microsoft рекомендується вибрати порт в діапазоні 59531 - 60554 і використовувати дане значення на всіх серверах CAS (ми вказали порт 59532, природно, він не повинен використовуватися ніяким іншим ПЗ).

Після завдання статичного порту, щоб зміни набули чинності, потрібно перезапустити службу Microsoft Exchange RPC Client Access.

Restart-Service MSExchangeRPC

Статичний порт для служби Exchange 2010 Address Book

У Exchange 2010 до виходу SP1 для завдання статичного порту служби Exchange 2010 Address Book використовувався спеціальний конфігураційний файл Microsoft.exchange.addressbook.service.exe.config. Після релізу Exchange 2010 SP1 встановити статичний порт цієї служби можна через реєстр. Для цього відкрийте редактор реєстру та перейдіть у гілку:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeAB\Parameters

Створіть новий параметр RpcTcpPort (типу REG_SZ) і вкажіть номер порту, який необхідно зафіксувати для служби Exchange Address Book service. Рекомендовано використовувати будь-який вільний порт у діапазоні 59531-60554 і надалі використовувати його на всіх серверах Exchange 2010 Client Access у домені. Ми задаємо RpcTcpPort=59533

Після цього необхідно перезапустити службу Microsoft Exchange Address Book

Restart-Service MSExchangeAB

Важливо: При переході з Exchange 2010 RTM на SP1, цей ключ потрібно задавати вручну, автоматично він не успадковується.

Налаштування статичного порту для підключення до спільних папок

Доступ до спільних папок із клієнта Outlook здійснюється безпосередньо через службу RPC Client Access на сервері за участю Mailbox. Це налаштуваннянеобхідно провести на всіх серверах за участю Mailbox, які містять базу спільних папок(аналогічно до серверів CAS). Відкрийте редактор реєстру та перейдіть у гілку

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\ MSExchangeRPC

Створіть новий ключ з ім'ям ParametersSystem, всередині якого створіть параметр типу REG_DWORD з ім'ям TCP/IP Port. Вкажіть його значення: TCP/IP Port = 59532.

Задавши статично порт для спільних папок, потрібно перезапустити службу Microsoft Exchange RPC Client Access service на кожному сервері mailbox.

Перевірка використання статичних портів між Outlook та Exchange 2010

Після внесених змін перевіримо, що Outlook підключається до заданих нами статичних портів RPC. Для цього на клієнтській машині перезапустіть Outlook, а потім у командному рядкувиконайте команду:

Netstat -na

Застосовується до: Exchange Server 2010 SP1

Остання модифікація розділу: 2011-04-22

У цьому розділі наведено відомості про порти, автентифікацію та шифрування для всіх шляхів до даних, які використовуються в Microsoft Exchange Server 2010. Розділ «Примітки» після кожної таблиці уточнює або визначає нестандартні способи автентифікації або шифрування.

Транспортні сервери

У системі Exchange 2010 є дві ролі сервера, які виконують функції транспортування повідомлень: транспортний сервер-концентратор та прикордонний транспортний сервер.

У наступній таблиці наведено відомості про порти, автентифікацію та шифрування шляхів до даних між цими транспортними серверами та іншими серверами та службами Exchange 2010.

Шляхи даних для транспортних серверів Шлях даних Необхідні порти Підтримка шифрування

Між двома транспортними серверами-концентраторами				Так, за допомогою TLS (Transport Layer Security)
З транспортного сервера-концентратора на прикордонний транспортний сервер		Пряма довіра	Пряма довіра	Так, з використанням TLS
З прикордонного транспортного сервера на транспортний сервер-концентратор		Пряма довіра	Пряма довіра	Так, з використанням TLS
Між двома прикордонними транспортними серверами		Анонімно, автентифікація за допомогою сертифіката	Анонімно за допомогою сертифіката	Так, з використанням TLS
З сервера поштових скриньокчерез службу відправки пошти Microsoft Exchange		NTLM. Якщо роль транспортного сервера-концентратора та роль сервера поштових скриньок виконуються на одному сервері, використовується протокол Kerberos.		Так, за допомогою шифрування RPC
З транспортного сервера-концентратора на сервер поштових скриньок через MAPI		NTLM. Якщо роль транспортного сервера-концентратора та роль сервера поштових скриньок встановлені на одному сервері, використовується протокол Kerberos.		Так, за допомогою шифрування RPC
				Так, з використанням TLS
Служба Microsoft Exchange EdgeSync із транспортного сервера-концентратора на прикордонний транспортний сервер				Так, за допомогою LDAP через SSL (LDAPS)
Доступ Служба каталогів Active Directory із транспортного сервера-концентратора
Доступ до служби керування правами Служба каталогів Active Directory (AD RMS) з транспортного сервера-концентратора				Так, за допомогою SSL
Клієнти SMTP на транспортний сервер-концентратор (наприклад, кінцеві користувачі за допомогою пошти Windows Live)				Так, з використанням TLS

Примітки для транспортних серверів

• Весь трафік між транспортними серверами-концентраторами шифрується за допомогою протоколу TLS і сертифікатів, що самозавіряють, встановлених програмою установки Exchange 2010.
• Весь трафік між прикордонними транспортними серверами та транспортними серверами-концентраторами проходить автентифікацію та шифрується. Як механізм автентифікації та шифрування використовується Mutual TLS. Замість перевірки X.509 у Exchange 2010 для автентифікації сертифікатів використовується пряма довіра. Пряма довіра означає, що наявність сертифіката в службах Служба каталогів Active Directory або в службах Active Directory полегшеного доступу до каталогів (AD LDS) підтверджує дійсність сертифіката. Служба каталогів Active Directory вважається довіреним механізмом зберігання. Коли використовується пряма довіра, не має значення, чи застосовується сертифікат, що самозавірює, або сертифікат, підписаний центром сертифікації. При підписці прикордонного транспортного сервера на організацію Exchange прикордонна підписка публікує сертифікат прикордонного транспортного сервера в службі каталогів Active Directory, щоб транспортні сервери-концентратори могли його перевіряти. Служба Microsoft Exchange EdgeSync додає до служб Active Directory полегшеного доступу до каталогів (AD LDS) набір сертифікатів транспортного сервера-концентратора, щоб прикордонний транспортний сервер перевірив їх.
• EdgeSync використовує безпечне підключення LDAP транспортного сервера-концентратора до підписаних прикордонних транспортних серверів через порт TCP 50636. Служби Active Directory полегшеного доступу до каталогів також здійснюють прослуховування порту TCP 50389. Підключення до цього порту не використовує протокол SSL. Для підключення до цього порту та перевірки даних служб Active Directory полегшеного доступу до каталогів можна використовувати службові програми LDAP.
• За промовчанням трафік між прикордонними транспортними серверами, розташованими у двох різних організаціях, шифрується. Програма установки Exchange 2010 створює сертифікат, що самозавіряє, і за замовчуванням включає TLS. Це дозволяє будь-якій відправляючій системі шифрувати сеанс SMTP, що входить в Exchange. За промовчанням, сервер Exchange 2010 також намагається використовувати протокол TLS для всіх віддалених підключень.
• Способи автентифікації для трафіку між транспортними серверами-концентраторами та серверами поштових скриньок відрізняються, якщо ролі транспортного сервера-концентратора та сервера поштових скриньок встановлені на одному комп'ютері. При локальній передачі пошти використовується автентифікація Kerberos. Під час віддаленої передачі пошти використовується автентифікація NTLM.
• Exchange 2010 також підтримує безпеку домену. Безпека домену – це набір функцій Exchange 2010 та Microsoft Outlook 2010, які є недорогою альтернативою S/MIME та іншим рішенням для забезпечення безпеки передачі повідомлень через Інтернет. Безпека домену забезпечує спосіб керування безпечними шляхами надсилання повідомлень між доменами в Інтернеті. Після налаштування таких безпечних шляхів успішно передані по них повідомлення від відправника, що пройшов автентифікацію, відображаються для користувачів Outlook і Outlook Web Access як повідомлення, «захищені на рівні домену». Щоб отримати додаткові відомості, див. Загальні відомості про безпеку домену.
• Багато агентів можуть виконуватися як у транспортних серверах-концентраторах, і на прикордонних транспортних серверах. Як правило, агенти захисту від небажаної поштивикористовують відомості локального комп'ютера, на якому вони виконуються. Таким чином, практично не потрібна взаємодія з віддаленими комп'ютерами. Винятком є ​​фільтрація одержувачів. Для фільтрації одержувачів потрібний виклик AD LDS або Служба каталогів Active Directory. Фільтрацію одержувачів рекомендується виконувати на прикордонному транспортному сервері. У цьому випадку каталог AD LDS знаходиться на тому ж комп'ютері, на якому встановлена ​​роль прикордонного транспортного сервера, тому віддалене підключення не потрібне. Якщо функція фільтрації одержувачів встановлена ​​та налаштована на транспортному сервері-концентраторі, необхідний доступ до служби каталогів Active Directory.
• Агент аналізу протоколу використовується функцією репутації відправника Exchange 2010. Цей агент також підключається до різних зовнішніх проксі-серверів, щоб визначити шляхи вхідних повідомлень для підозрілих підключень.
• Всі інші функції захисту від небажаної пошти використовують дані, які збираються, зберігаються та доступні лише на локальному комп'ютері. Зазвичай такі дані, як об'єднаний список надійних відправників або дані одержувачів для фільтрації одержувачів, примусово надсилаються до локального каталогу AD LDS за допомогою служби Microsoft Exchange EdgeSync.
• Агенти управління правами на доступ до даних (IRM) на транспортних серверах-концентраторах виконують підключення до серверів служб управління правами Active Directory (AD RMS) в організації. Служба керування правами Active Directory (AD RMS) – це веб-служба, яку рекомендується захищати за допомогою SSL. Підключення до серверів служб керування правами Active Directory виконується за допомогою HTTPS, а для автентифікації використовується Kerberos або NTLM залежно від конфігурації сервера служб керування правами Active Directory.
• Правила журналів, правила транспорту та класифікації повідомлень зберігаються у службах Служба каталогів Active Directory, і доступ до них здійснює агент ведення журналу та агент правил транспорту на транспортних серверах-концентраторах. Сервери поштових скриньок

  На серверах поштових скриньок використання автентифікації NTLM або Kerberos залежить від контексту користувача або процесу, в рамках якого працює споживач рівня бізнес-логіки Exchange. У такому контексті споживачами є будь-які програми чи процеси, які використовують рівень бізнес-логіки Exchange. У стовпці Перевірка автентичності за умовчанням таблиці Шляхи до даних для серверів поштових скриньок для багатьох рядків вказано значення NTLM/Kerberos .

  Рівень бізнес-логіки Exchange використовується для доступу до сховища Exchange та взаємодії з ним. Рівень бізнес-логіки Exchange також викликається зі сховища Exchange для взаємодії із зовнішніми програмами та процесами.

  Якщо споживач рівня бізнес-логіки Exchange виконується в контексті локальної системи, способом автентифікації при доступі споживача до сховища Exchange завжди є Kerberos. Спосіб автентифікації Kerberos використовується через те, що справжність одержувача необхідно перевіряти з використанням облікового записукомп'ютера "Локальна система", а також потрібна двостороння довіра з автентифікацією.

  Якщо одержувач рівня бізнес-логіки Exchange виконується не в контексті локальної системи, способом автентифікації є NTLM. Наприклад, коли адміністратор запускає командлет командної консолі Exchange, що використовує рівень бізнес-логіки Exchange, застосовується автентифікація NTLM.

  Трафік RPC завжди шифрується.

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

  Шляхи даних для серверів поштових скриньок Шлях до даних Необхідні порти Перевірка автентичності за замовчуванням Підтримуваний спосіб автентифікації Підтримка шифрування Шифрування даних за умовчанням

  	389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (мережевий вхід до системи RPC)			Так, за допомогою шифрування Kerberos
  Адміністративний віддалений доступ (віддалений реєстр)				Так, за допомогою IPsec
  Адміністративний віддалений доступ (SMB, файли)				Так, за допомогою IPsec
  Веб-служба доступності (клієнтський доступ до поштової скриньки)				Так, за допомогою шифрування RPC
  Кластеризація				Так, за допомогою шифрування RPC
  Між серверами клієнтського доступу (Exchange ActiveSync)	80/TCP, 443/TCP (SSL)		Kerberos, автентифікація за допомогою сертифіката	Так, за допомогою HTTPS	Так, з використанням самозавірювального сертифіката
  Між серверами клієнтського доступу (Outlook Web Access)	80/TCP, 443/TCP (HTTPS)			Так, за допомогою SSL
  Сервер клієнтського доступу до сервера клієнтського доступу (Веб-служби Exchange)				Так, за допомогою SSL
  Сервер клієнтського доступу до сервера клієнтського доступу (POP3)				Так, за допомогою SSL
  Сервер клієнтського доступу до сервера клієнтського доступу (IMAP4)				Так, за допомогою SSL
  Сервер Office Communications Server до сервера клієнтського доступу (коли включена інтеграція Office Communications Server та Outlook Web App)	5075-5077/TCP (ВХІД), 5061/TCP (ВИХІД)	mTLS (обов'язково)	mTLS (обов'язково)	Так, за допомогою SSL

  Примітки для серверів клієнтського доступу Сервери єдиної системиобміну повідомленнями

  Шлюзи IP та УВАТС, що працюють за протоколом IP, підтримують лише автентифікацію за допомогою сертифіката, при якій використовується автентифікація Mutual TLS для шифрування трафіку SIP та автентифікація на основі IP-адреси для підключень за протоколами SIP або TCP. Шлюзи IP не підтримують автентифікацію NTLM і Kerberos. Таким чином, при використанні автентифікації на основі IP-адреси в якості механізму автентифікації для незашифрованих підключень (TCP) використовуються IP-адреси підключень. При використанні в єдиній системі обміну повідомленнями автентифікації на основі IP-адрес перевіряє, чи дозволено цій IP-адресі підключатися. IP-адреса настроюється на шлюзі IP або IP PBX.

  Шлюзи IP та УВАТС, що працюють за протоколом IP, підтримують Mutual TLS для шифрування трафіку SIP. Після успішного імпорту та експорту необхідних довірених сертифікатів шлюз IP або УВАТС, що працює за протоколом IP, запитуватиме сертифікат у сервера єдиної системи обміну повідомленнями, а потім запитуватиме сертифікат у шлюзу IP або УВАТС, що працює за протоколом IP. Обмін довіреними сертифікатами між шлюзом IP або УВАТС, що працює за протоколом IP, та сервером єдиної системи обміну повідомленнями дозволяє обом пристроям взаємодіяти безпечним каналом за допомогою Mutual TLS.

  У наступній таблиці наведено відомості про порти, автентифікацію та шифрування для шляхів даних між серверами єдиної системи обміну повідомленнями та іншими серверами.

  Шляхи даних для серверів єдиної системи обміну повідомленнями Шлях до даних Необхідні порти Перевірка автентичності за замовчуванням Підтримуваний спосіб автентифікації Підтримка шифрування Шифрування даних за умовчанням

  Доступ до служби каталогів Active Directory	389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (мережевий вхід до системи RPC)			Так, за допомогою шифрування Kerberos
  Телефонна взаємодія єдиної системи обміну повідомленнями (шлюз IP PBX/VoIP)	5060/TCP , 5065/TCP, 5067/TCP (у незахищеному режимі), 5061/TCP, 5066/TCP, 5068/TCP (у захищеному режимі), динамічний порт з діапазону 16000-17000/TCP (управління) з діапазону 1024-65535/UDP (RTP)	За IP-адресою	За IP-адресою, MTLS	Так, за допомогою SIP/TLS, SRTP
  Веб-служба єдиної системи обміну повідомленнями	80/TCP, 443/TCP (SSL)	Інтегрована автентифікація Windows (Negotiate)		Так, за допомогою SSL
  Із сервера єдиної системи обміну повідомленнями на сервер клієнтського доступу	5075, 5076, 5077 (TCP)	Вбудована автентифікація Windows (узгодження)	Звичайна, дайджест-автентифікація, NTLM, узгодження (Kerberos)	Так, за допомогою SSL
  Із сервера єдиної системи обміну повідомленнями на сервер клієнтського доступу (відтворення на телефоні)	Динамічний RPC			Так, за допомогою шифрування RPC
  Із сервера єдиної системи обміну повідомленнями на транспортний сервер-концентратор				Так, з використанням TLS
  З сервера єдиної системи обміну повідомленнями на сервер поштових скриньок				Так, за допомогою шифрування RPC

  Примітки для серверів єдиної системи обміну повідомленнями
  • При створенні об'єкта шлюзу IP єдиної системи обміну повідомленнями в Службі каталогів Active Directory необхідно визначити IP-адресу фізичного шлюзу IP або УВАТС, що працює за протоколом IP. При визначенні IP-адреси об'єкта шлюзу IP єдиної системи обміну повідомленнями IP-адреса додається до списку допустимих шлюзів IP або УВАТС, що працюють за протоколом IP (також званими учасниками SIP-сеансу), з якими можна взаємодіяти серверу єдиної системи обміну повідомленнями. Після створення шлюзу IP єдиної системи обміну повідомленнями, можна зв'язати його з абонентською групою цієї системи. Зіставлення шлюзу IP єдиної системи обміну повідомленнями з абонентською групою дозволяє серверам єдиної системи обміну повідомленнями, зіставленим з абонентською групою, використовувати автентифікацію на основі IP-адреси для взаємодії зі шлюзом IP. Якщо шлюз IP єдиної системи обміну повідомленнями не був створений або не був налаштований на використання правильної IP-адреси, то відбудеться збій автентифікації, і сервери єдиної системи обміну повідомленнями не прийматимуть підключення з IP-адреси даного шлюзу IP. Крім того, при реалізації Mutual TLS, шлюзу IP або УВАТС, що працює за протоколом IP, та серверів єдиної системи обміну повідомленнями, шлюз IP єдиної системи обміну повідомленнями необхідно налаштувати на використання повного доменного імені (FQDN). Після налаштування шлюзу IP єдиної системи обміну повідомленнями з використанням повного доменне ім'я необхідно також додати до зони прямого пошуку DNS запис вузла для цього шлюзу.
  • У версії Exchange 2010 сервер єдиної системи обміну повідомленнями може взаємодіяти через порт 5060/TCP (незахищений) або через порт 5061/TCP (захищений), і можна налаштувати для використання обох портів.

  Щоб отримати додаткові відомості, див. Загальні відомості про безпеку VoIP єдиної системи обміну повідомленнями та Загальні відомості про протоколи, порти та служби в єдиній системі обміну повідомленнями .

  Правила брандмауера Windows, створені програмою встановлення Exchange 2010

  Брандмауер Windows у режимі підвищеної безпеки - це брандмауер з відстеженням стану на основі комп'ютера, який здійснює фільтрацію вхідного та вихідного трафіку на основі правил брандмауера. Програма інсталяції Exchange 2010 створює правила брандмауера Windows для відкриття портів, необхідних для взаємодії сервера та клієнта, у кожній ролі сервера. Таким чином, більше не потрібно використовувати майстер налаштування безпеки для налаштування цих параметрів. Додаткові відомості про брандмауер Windows у режимі підвищеної безпеки див. у статті Брандмауер Windows у режимі підвищеної безпеки та IPsec (сторінка може бути англійською мовою).

  У наступній таблиці наведено правила брандмауера Windows, створювані програмоюінсталяції Exchange, включаючи порти, відкриті в кожній ролі сервера. Ці правила можна переглянути за допомогою оснащення консолі MMC брандмауера Windows у режимі підвищеної безпеки.

  Ім'я правила Ролі сервера Порт Програма

  MSExchangeADTopology - RPC (вхідний TCP)		Динамічний RPC	Bin\MSExchangeADTopologyService.exe
  MSExchangeMonitoring - RPC (вхідний TCP)	Сервер клієнтського доступу, транспортний сервер-концентратор, прикордонний транспортний сервер, сервер єдиної системи обміну повідомленнями	Динамічний RPC	Bin\Microsoft.Exchange.Management.Monitoring.exe
  MSExchangeServiceHost - RPC (вхідний TCP)		Динамічний RPC	Bin\Microsoft.Exchange.ServiceHost.exe
  MSExchangeServiceHost - RPCEPMap (вхідний TCP)			Bin\Microsoft.Exchange.Service.Host
  MSExchangeRPCEPMap (GFW) (вхідний TCP)
  MSExchangeRPC (GFW) (вхідний TCP)	Сервер клієнтського доступу, транспортний сервер-концентратор, сервер поштових скриньок, сервер єдиної системи обміну повідомленнями	Динамічний RPC
  MSExchange - IMAP4 (GFW) (вхідний TCP)	Сервер клієнтського доступу
  MSExchangeIMAP4 (вхідний TCP)	Сервер клієнтського доступу		ClientAccess\PopImap\Microsoft.Exchange.Imap4Service.exe
  MSExchange - POP3 (FGW) (вхідний TCP)	Сервер клієнтського доступу
  MSExchange - POP3 (вхідний TCP)	Сервер клієнтського доступу		ClientAccess\PopImap\Microsoft.Exchange.Pop3Service.exe
  MSExchange - OWA (GFW) (вхідний TCP)	Сервер клієнтського доступу	5075, 5076, 5077 (TCP)
  MSExchangeOWAAppPool (вхідний TCP)	Сервер клієнтського доступу	5075, 5076, 5077 (TCP)	Inetsrv\w3wp.exe
  MSExchangeAB RPC (вхідний TCP)	Сервер клієнтського доступу	Динамічний RPC
  MSExchangeAB-RPCEPMap (вхідний TCP)	Сервер клієнтського доступу		Bin\Microsoft.Exchange.AddressBook.Service.exe
  MSExchangeAB-RpcHttp (вхідний TCP)	Сервер клієнтського доступу	6002, 6004 (TCP)	Bin\Microsoft.Exchange.AddressBook.Service.exe
  RpcHttpLBS (вхідний TCP)	Сервер клієнтського доступу	Динамічний RPC	System32\Svchost.exe
  MSExchangeRPC - RPC (вхідний TCP)		Динамічний RPC
  MSExchangeRPC - PRCEPMap (вхідний TCP)	Сервер клієнтського доступу, сервер поштових скриньок		Bing\Microsoft.Exchange.RpcClientAccess.Service.exe
  MSExchangeRPC (вхідний TCP)	Сервер клієнтського доступу, сервер поштових скриньок		Bing\Microsoft.Exchange.RpcClientAccess.Service.exe
  MSExchangeMailboxReplication (GFW) (вхідний TCP)	Сервер клієнтського доступу
  MSExchangeMailboxReplication (вхідний TCP)	Сервер клієнтського доступу		Bin\MSExchangeMailboxReplication.exe
  MSExchangeIS - RPC (TCP-вхідний)	Сервер поштових скриньок	Динамічний RPC
  MSExchangeIS RPCEPMap (вхідний TCP)	Сервер поштових скриньок
  MSExchangeIS (GFW) (вхідний TCP)	Сервер поштових скриньок	6001, 6002, 6003, 6004 (TCP)
  MSExchangeIS (вхідний TCP)	Сервер поштових скриньок
  MSExchangeMailboxAssistants - RPC (вхідний TCP)	Сервер поштових скриньок	Динамічний RPC
  MSExchangeMailboxAssistants - RPCEPMap (вхідний TCP)	Сервер поштових скриньок		Bin\MSExchangeMailboxAssistants.exe
  MSExchangeMailSubmission - RPC (вхідний TCP)	Сервер поштових скриньок	Динамічний RPC
  MSExchangeMailSubmission - RPCEPMap (вхідний TCP)	Сервер поштових скриньок		Bin\MSExchangeMailSubmission.exe
  MSExchangeMigration - RPC (вхідний TCP)	Сервер поштових скриньок	Динамічний RPC	Bin\MSExchangeMigration.exe
  MSExchangeMigration - RPCEPMap (вхідний TCP)	Сервер поштових скриньок		Bin\MSExchangeMigration.exe
  MSExchangerepl - Log Copier (вхідний TCP)	Сервер поштових скриньок		Bin\MSExchangeRepl.exe
  MSExchangerepl - RPC (вхідний TCP)	Сервер поштових скриньок	Динамічний RPC	Bin\MSExchangeRepl.exe
  MSExchangerepl - RPC-EPMap (вхідний TCP)	Сервер поштових скриньок		Bin\MSExchangeRepl.exe
  MSExchangeSearch - RPC (вхідний TCP)	Сервер поштових скриньок	Динамічний RPC	Bin\Microsoft.Exchange.Search.ExSearch.exe
  MSExchangeThrottling - RPC (вхідний TCP)	Сервер поштових скриньок	Динамічний RPC	Bin\MSExchangeThrottling.exe
  MSExchangeThrottling - RPCEPMap (вхідний TCP)	Сервер поштових скриньок		Bin\MSExchangeThrottling.exe
  MSFTED - RPC (TCP-вхідний)	Сервер поштових скриньок	Динамічний RPC
  MSFTED - RPCEPMap (TCP-вхідний)	Сервер поштових скриньок
  MSExchangeEdgeSync - RPC (вхідний TCP)	Транспортний сервер-концентратор	Динамічний RPC
  MSExchangeEdgeSync RPCEPMap (вхідний TCP)	Транспортний сервер-концентратор		Bin\Microsoft.Exchange.EdgeSyncSvc.exe
  MSExchangeTransportWorker - RPC (вхідний TCP)	Транспортний сервер-концентратор	Динамічний RPC	Bin\edgetransport.exe
  MSExchangeTransportWorker - RPCEPMap (вхідний TCP)	Транспортний сервер-концентратор		Bin\edgetransport.exe
  MSExchangeTransportWorker (GFW) (вхідний TCP)	Транспортний сервер-концентратор
  MSExchangeTransportWorker (вхідний TCP)	Транспортний сервер-концентратор		Bin\edgetransport.exe
  MSExchangeTransportLogSearch - RPC (вхідний TCP)		Динамічний RPC
  MSExchangeTransportLogSearch - RPCEPMap (вхідний TCP)	Транспортний сервер-концентратор, прикордонний транспортний сервер, сервер поштових скриньок		Bin\MSExchangeTransportLogSearch.exe
  SESWorker (GFW) (вхідний TCP)	Сервер єдиної системи обміну повідомленнями
  SESWorker (вхідний TCP)	Сервер єдиної системи обміну повідомленнями		UnifiedMessaging\SESWorker.exe
  UMService (GFW) (вхідний TCP)	Сервер єдиної системи обміну повідомленнями
  UMService (вхідний TCP)	Сервер єдиної системи обміну повідомленнями		Bin\UMService.exe
  UMWorkerProcess (GFW) (вхідний TCP)	Сервер єдиної системи обміну повідомленнями	5065, 5066, 5067, 5068
  UMWorkerProcess (вхідний TCP)	Сервер єдиної системи обміну повідомленнями	5065, 5066, 5067, 5068	Bin\UMWorkerProcess.exe
  UMWorkerProcess - RPC (вхідний TCP)	Сервер єдиної системи обміну повідомленнями	Динамічний RPC	Bin\UMWorkerProcess.exe

  Примітки до правил брандмауера Windows, створених програмою інсталяції Exchange 2010
  • На серверах із встановленими службами IIS Windows відкриває порти HTTP (порт 80, TCP) та HTTPS (порт 443, TCP). Програма інсталяції Exchange 2010 не відкриває ці порти. Отже, ці порти не наведені у попередній таблиці.
  • У Windows Server 2008 та Windows Server 2008 R2 брандмауер Windows у режимі підвищеної безпеки дозволяє вказати процес або службу, для яких відкритий порт. Це безпечніше, оскільки порт може використовуватися лише процесом чи службою, зазначеної у правилі. Програма інсталяції Exchange створює правила брандмауера із зазначеним ім'ям процесу. У деяких випадках з метою сумісності також створюється додаткове правило, не обмежене цим процесом. Можна вимкнути або видалити правила, не обмежені процесами, та зберегти відповідні правила, обмежені процесами, якщо поточне середовище розгортання підтримує їх. Правила, які не обмежені процесами, можна відрізнити за словом (GFW) в імені правила.
  • Багато служб Exchange використовують для взаємодії віддалені дзвінки процедур (RPC). Серверні процеси, що використовують віддалені виклики процедур, підключаються до співставника кінцевих точок RPC для отримання динамічних кінцевих точок та реєстрації їх у базі даних зіставника кінцевих точок. Клієнти RPC взаємодіють із співставником кінцевих точок RPC для визначення кінцевих точок, що використовуються серверним процесом. За промовчанням співставник кінцевих точок RPC прослуховує порт 135 (TCP). При налаштуванні брандмауера Windows для процесу, що використовує віддалені дзвінки процедур, програма інсталяції Exchange 2010 створює для цього процесу два правила брандмауера. Одне правило дозволяє взаємодію із співставником кінцевих точок RPC, а друге дозволяє взаємодію з динамічно призначеною кінцевою точкою. Для отримання додаткових відомостей про віддалені дзвінки процедур див. статтю . Щоб отримати додаткові відомості про створення правил брандмауера Windows для динамічного віддаленого виклику процедур, див.

    Додаткові відомості див. у статті 179442 бази знань Microsoft

Www.microsoft.com

Стаття Служба Exchange 2013 FrontEnd Transportє першою в циклі статей, що оповідають про принцип роботи служб транспорту Exchange Server 2013. У цій статті мова піде про Транспортна служба переднього плануна серверах клієнтського доступу.

У 2013 версії сервера Exchange відбулися досить сильні зміни в архітектурі і тепер існує лише дві основні ролі – сервер поштових скриньок (Mailbox Server або скорочено MBX) та сервер клієнтського доступу (Client Access Server – CAS). Особливо стоїть роль прикордонного транспортного сервера (Edge Transport). Служба Exchange 2013 FrontEnd Transportрозташовується на серверах CAS та виконує функції проксі.

Це перша стаття із серії, присвяченої принципам роботи служб транспортного конвеєра Exchange 2013, а ось повний список:

А також статті з управління логуванням цих служб:

Не забувайте про офіційну документацію.

Знайти більше інформації з налаштування та адміністрування Exchange 2013 на моєму блозі ви зможете в основній статті тематики.

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

• Транспортна служба переднього плануна серверах клієнтського доступу (Відображуване ім'я - Microsoft Exchange FrontEnd Transport, скорочене - MSExchangeFrontEndTransport);
• Транспортна службана серверах поштових скриньок (Відображуване ім'я - Microsoft Exchange Transport, скорочене - MSExchangeTransport);
• Транспортна служба поштових скриньокна серверах поштових скриньок (Реально включає дві служби — Microsoft Exchange Mailbox Transport Delivery і Microsoft Exchange Mailbox Transport Submission, скорочені імена — MSExchangeDelivery і MSExchangeSubmission відповідно);
• Транспортна служба на прикордонних транспортних серверах (Ім'я, що відображається - Microsoft Exchange Transport, скорочене - MSExchangeTransport).

У цьому зіставний функціонал виконують лише друга і четверта служба, інші відрізняються принципово. Разом усі вони утворюють транспортний конвеєр, який є серцем поштового сервера.

Транспортний конвеєр

У загальному плані транспортний конвеєр виглядає так:

У контексті цієї статті нас цікавить саме верхня частина ілюстрації, на якій зображено Сервер клієнтського доступу:

У цій схемі криється один аспект. Справа в тому, що за замовчуванням сервери MBX можуть самостійно надсилати пошту назовні через порт 25 SMTP. Щоб з'єднувач відправки завжди відправляв пошту в інтернет через сервери клієнтського доступу, потрібно в явному вигляді встановити цей з'єднувач параметр FrontendProxyEnabledна значення $true(або в EAC поставити галочку на Проксі через сервер клієнтського доступуу властивостях з'єднувача відправлення). Саме від такої конфігурації я і відштовхуватимуся надалі.

Нижче я постараюся внести деякі ясності в принцип роботи серверів Exchange 2013 за участю CAS.

Принцип роботи

FrontEnd Transport(у термінології Microsoft - Служба транспорту переднього плану) не займається обробкою вмісту повідомлень, не використовує чергу повідомлень та не взаємодіє з транспортною службою поштових скриньок. Іншими словами, сервери Exchange 2013 тільки за участю CAS не зберігають у себе дані ні на постійній основі (використовуючи БД), ні на тимчасовій (у черзі обробки повідомлень).

Тим не менш, служба транспорту переднього плану має власних агентів транспорту (див. рисунок - Агенти протоколу). Агенти дозволяють розширювати функціонал поштового сервера Exchange шляхом додавання до логіки обробки повідомлень власного коду. Виклик агентів відбувається у разі виникнення подій SMTP. Ці події, у свою чергу, генеруються на тій чи іншій стадії обробки повідомлень у міру їхнього проходження через транспортний конвеєр. Варто зазначити, що більшість присутніх за умовчанням агентів приховані або їх налаштування не можна керувати. Функціонал агентів на CAS-серверах досить сильно обмежений і присутня тільки у ролей MBX і Edge.

З'єднувачі відправлення та отримання

На схемі (див. вище) Транспортної служби переднього планусервера клієнтського доступу позначимо на кожному вхідному та вихідному з'єднаннівідповідний порт, отримавши в результаті таке уявлення:

За прослуховування підключень кожного порту, позначеного на схемі, відповідає окремий з'єднувач отримання, яких за умовчанням при встановленні ролі CAS створюється три штуки:

Крім видимих ​​та доступних адміністратору з'єднувачів, існують також приховані системні з'єднувачі відправки:

• Inbound Proxy Internal Send Connector (SMTP 25/2525 )
• Client Proxy Send Connector (SMTP, прийняті на 587 порту в Транспортну службу на серверах поштових скриньокна порт 465)

До речі, перший з'єднувач у російськомовній версії Exchange Server 2013 матиме ім'я Внутрішній з'єднувач надсилання для входу. підкл. проксі-сервера, а другий - З'єднувач відправки проксі клієнта. Це про всяк випадок, щоб не прийти в ступор при першій зустрічі з цими конекторами.

У результаті отримуємо таку повну таблицю:

Назва	Призначення	Порт	Напрям
Default Frontend	Прийом	25	Від зовнішніх серверів
Outbound Proxy Frontend	Прийом	717	Від серверів MBX
Client Frontend	Прийом	587	Від зовнішніх клієнтів, захищене підключення
Client Proxy Send Connector	Надсилання	465	На сервери MBX
Inbound Proxy Internal Send Connector	Надсилання	25/2525	На сервери MBX. Тільки підключення, прийняті на 587 порту
Створений вручну з'єднувач відправки	Надсилання	25	На зовнішні сервери

Перенесемо назви з'єднувачів на схему Транспортної служби переднього плану.

Exchange Server та брандмауери

Брандмауери (файрволли) для поштових серверів (Exchange Server), порти поштових серверів, front-end та back-end поштові сервери, віртуальні сервери SMTP, POP3, IMAP4

Як і будь-який комп'ютер, підключений до Інтернету, комп'ютер, де стоїть поштовий сервер, необхідно захищати за допомогою брандмауера. При цьому варіанти встановлення поштового сервера з точки зору конфігурації мережі можуть бути різними:

· Найпростіший варіант - встановити поштовий сервер на комп'ютер, який одночасно є проксі-сервером/брандмауером, а потім на інтерфейсі, який звернений до Інтернету, відкрити необхідні порти. Зазвичай така схема застосовується у невеликих організаціях;

· Ще один варіант - встановити поштовий сервер в локальної мережіта налаштувати його роботу через проксі-сервер. Для цього можна прив'язати до поштового сервера public ip та пропускати його через проксі або скористатися засобами типу port mapping на проксі-сервері. На багатьох проксі-серверах є спеціальні майстри або заздалегідь заготовлені правила для організації такого рішення (наприклад, ISA Server). Такий варіант використовується у більшості організацій.

· Ще одна важлива можливість - створити DMZ і помістити в неї front-end Exchange Server (така можливість з'явилася, починаючи з версії 2000) або SMTP Relay на основі іншого Exchange Server або, наприклад, sendmail на *nix. Зазвичай застосовується у мережах великих організацій.

У будь-якому випадку для поштового сервера необхідно забезпечити взаємодію як мінімум на порту TCP 25 (SMTP ) і UDP 53 (DNS ). Інші порти, які можуть знадобитися Exchange Server в залежності від конфігурації вашої мережі (всі - TCP):

· 80 HTTP - для доступу на Web-інтерфейс (OWA)

· 88 Kerberos authentication protocol - якщо використовується аутентифікація Kerberos (рідко);

· 102 MTA .X .400 connector over TCP /IP (якщо використовується конектор X .400 для зв'язку між групами маршрутизації);

· 110 Post Office Protocol 3 (POP 3) – для доступу клієнтів;

· 119 Network News Transfer Protocol (NNTP) - якщо використовуються групи новин;

· 135 Client /server communication RPC Exchange administration - стандартний порт RPC для віддаленого адміністрування Exchange стандартними засобами System Manager;

· 143 Internet Message Access Protocol (IMAP) – для доступу клієнтів;

· 389 LDAP – для звернення до служби каталогів;

· 443 HTTP (Secure Sockets Layer (SSL)) (і нижче) - ті самі протоколи, захищені по SSL.

· 563 NNTP (SSL)

· 636 LDAP (SSL)

· 993 IMAP4 (SSL)

· 995 POP3 (SSL)

· 3268 and 3269 - запити до сервера глобального каталогу (пошук Active Directory і перевірка членства в universal groups).

Інтерфейс Exchange Server, звернений всередину організації, закривати брандмауером немає сенсу - по ньому відбуватиметься взаємодія з контролерами домену, утилітами адміністрування, системами резервного копіюванняі т.п. Для інтерфейсу, відкритого в Інтернет, рекомендується залишити порти 53 (якщо Exchange дозволятиме імена хостів сам, а не перенаправляти запити на локальний сервер DNS) та 25. Дуже часто клієнтам необхідно звертатися до своїх поштових скриньок ззовні (з дому, під час відрядження тощо). Найкраще рішення в цій ситуації - налаштувати OWA (Web-інтерфейс для доступу на Exchange Server, який встановлюється за замовчуванням, доступний за адресою http://ім'я_сервера/exchange) для роботи по SSL і відкрити доступ тільки по порту 443. безпечною аутентифікацією та шифруванням повідомлень автоматично вирішується питання з SMTP Relay (про це пізніше) та з ситуацією, коли користувач ненароком завантажує робочу електронну поштуу папки поштового клієнта на домашній комп'ютера потім на роботі не може ці повідомлення знайти (не кажучи вже про те, що зберігати робочу пошту вдома - порушення безпеки).

Нова можливість, яка з'явилася у Exchange Server. починаючи з версії 2000, можливість використання кількох віртуальних SMTP та POP3-серверів із різними налаштуваннями безпеки. Наприклад, той SMTP-сервер, який взаємодіє з Інтернетом, можна налаштувати на підвищений режим безпеки та суворі обмеження щодо доставки, а для SMTP-сервера, з яким працюють користувачі всередині організації, використовувати максимально продуктивні та зручні для користувачів налаштування.

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

[Ця стаття є попереднім документом і може бути змінена в майбутніх випусках. Порожні розділи включені як наповнювачі. Якщо ви хочете написати відгук, ми будемо раді отримати його. Надішліть його нам на електронну адресу [email protected].]

Застосовується до: Exchange Server 2016

Відомості про мережні порти, які Exchange 2016 використовує для клієнтського доступу та потоку обробки пошти.

У цьому розділі наведено відомості про мережні порти, які використовуються Microsoft Exchange Server 2016 для зв'язку з поштовими клієнтами, поштовими серверами в Інтернеті та іншими службами, які розташовані поза вашою локальною організацією Exchange. Перш ніж розпочати, обміркуйте такі основні правила.

Ми не підтримуємо обмеження або зміну мережного трафіку між внутрішніми серверами Exchange Server, між внутрішніми серверами Exchange Server та внутрішніми серверами Lync або Skype для бізнесу або між внутрішніми серверами Exchange Server та внутрішніми контролерами домену Active Directory в жодному з типів топологій. Якщо ви використовуєте брандмауери або мережеві пристрої, які можуть обмежити або змінити цей мережевий трафік, необхідно налаштувати правила, що забезпечують вільний та необмежений зв'язок між цими серверами (правила, що допускають вхідний та вихідний мережевий трафік на будь-який порт, включаючи випадкові порти RPC, та будь-який протокол) , який не змінює жодного біта).

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

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

Зміст

Network ports required for clients and services

Network ports потрібна для mail flow (no Edge Transport servers)

Network ports required for mail flow with Edge Transport servers

Network ports required for hybrid deployments

Network ports потрібна для Unified Messaging

Мережні порти, необхідні поштовим клієнтам для доступу до поштових скриньок та інших служб в організації Exchange, описані на наступній діаграміта у таблиці.

Примітки.

Пункт призначення для цих клієнтів та служб є служби клієнтського доступу на сервері поштових скриньок. В Exchange 2016 служби клієнтського доступу (зовнішні) та внутрішні служби встановлюються разом на одному сервері поштових скриньок. Щоб отримати додаткові відомості, див.

Хоча на діаграмі показані клієнти та служби з Інтернету, концепції однакові і для внутрішніх клієнтів (наприклад, клієнтів у лісі облікових записів, які звертаються до серверів Exchange у лісі ресурсів). Аналогічно в таблиці немає стовпця "Джерело", оскільки джерелом може бути будь-яке зовнішнє по відношенню до організації Exchange місцезнаходження (наприклад, Інтернет або ліс облікових записів).

Прикордонні транспортні сервери не беруть участь у мережевому трафіку, пов'язаному з цими клієнтами та службами.

Призначення Порти Примітки

Зашифровані підключення використовуються наступними клієнтами та службами. Служба автовиявлення Exchange ActiveSync Веб-служби Exchange (EWS) Розповсюдження автономних адресних книг Мобільний Outlook (протокол RPC через HTTP) MAPI Outlook через HTTP Outlook в Інтернеті	443/TCP (HTTPS)	Довідник EWS для Exchange
Незашифровані підключення використовуються наступними клієнтами та службами. Публікація календаря в Інтернеті Outlook в Інтернеті (перенаправлення на порт 443/TCP) Автовиявлення (відкат, коли порт 443/TCP недоступний)	80/TCP (HTTP)	По можливості рекомендуємо використовувати зашифровані веб-з'єднання через порт 443/TCP для захисту облікових та інших даних. Однак деякі служби необхідно настроїти на використання незашифрованих веб-з'єднань через порт 80/TCP до служб клієнтського доступу на серверах поштових скриньок. Для отримання додаткових відомостей про цих клієнтів і служб див. наступні статті.
Клієнти IMAP4	143/TCP (IMAP), 993/TCP (безпечний IMAP)	За замовчуванням IMAP4 вимкнено. Щоб отримати додаткові відомості, див. Служба IMAP4 у службах клієнтського доступу на сервері поштових скриньок проксує підключення до внутрішньої служби IMAP4 на сервері поштових скриньок.
Клієнти POP3	110/TCP (POP3), 995/TCP (безпечний POP3)	За промовчанням POP3 вимкнено. Щоб отримати додаткові відомості, див. Служба POP3 у службах клієнтського доступу на сервері поштових скриньок проксує підключення до внутрішньої служби POP3 на сервері поштових скриньок.
Клієнти SMTP (з автентифікацією)	587/TCP (SMTP з автентифікацією)	Стандартний з'єднувач "Client Frontend у зовнішній транспортній службі прослуховує повідомлення від клієнтів SMTP, що пройшли перевірку справжності, на порту 587. Примітка. Якщо у вас є поштові клієнти, які можуть надсилати повідомлення по протоколу SMTP з автентифікацією тільки через порт 25, то ви можете змінити значення прив'язки цього з'єднувача отримання, щоб він також відстежував відправлення повідомлень по протоколу SMTP з автентифікацією через порт 25.

На початок

Мережні порти, необхідні для потоку обробки пошти

Вихідна пошта

25/TCP (SMTP)

Сервер поштових скриньок

Інтернет (все)

За промовчанням Exchange не створює з'єднувачі відправки, які дозволяють надсилати пошту до Інтернету. Необхідно створити з'єднувачі відправки вручну. Щоб отримати додаткові відомості, див.

Вихідна пошта (якщо вона передається через зовнішню службу транспорту)

25/TCP (SMTP)

Сервер поштових скриньок

Інтернет (все)

Вихідна пошта передається через зовнішню службу транспорту, лише якщо для з'єднувача відправки увімкнено параметр Проксі через сервер клієнтського доступу в Центрі адміністрування Exchange або параметр -FrontEndProxyEnabled $true у командній консолі Exchange.

У цьому випадку з'єднувач отримання за промовчанням "Outbound Proxy Frontend " у зовнішній службі транспорту прослуховує вихідну пошту зі служби транспорту на сервері поштових скриньок. Додаткові відомості див. у статті .

DNS-сервер для дозволу імен наступного переходу пошти (не показано на малюнку)

53/UDP, 53/TCP (DNS)

Сервер поштових скриньок

DNS-сервер

На початок

Підписаний прикордонний транспортний сервер, встановлений у мережі периметра, впливає на потік обробки пошти таким чином:

Вихідна пошта з організації Exchange ніколи не проходить через зовнішню службу транспорту на серверах поштових скриньок. Вона завжди перенаправляється зі служби транспорту на сервері поштових скриньок підписаного сайту Active Directory на прикордонний транспортний сервер (незалежно від версії Exchange на прикордонному транспортному сервері).

Пошта, що входить, перенаправляється з прикордонного транспортного сервера на сервер поштових скриньок підписаного сайту Active Directory. Це означає таке:

• Пошта з прикордонного транспортного сервера Exchange 2016 або Exchange 2013 спочатку надходить до зовнішньої служби транспорту, а потім перенаправляється до служби транспорту на сервері поштових скриньок Exchange 2016.

  Пошта з прикордонного транспортного сервера Exchange 2010 завжди надходить безпосередньо до служби транспорту на сервері поштових скриньок Exchange 2016.

Мережні порти, необхідні для потоку обробки пошти в організаціях Exchange з прикордонними транспортними серверами, описуються на наведеній нижче діаграмі та таблиці.

Призначення Порти Джерело Призначення Примітки

Пошта, що входить - з Інтернету на прикордонний транспортний сервер	25/TCP (SMTP)	Інтернет (все)		Стандартний з'єднувач прийому "Внутрішній з'єднувач отримання за замовчуванням на прикордонному транспортному сервері прослуховує анонімну пошту SMTP на порту 25.
Вхідна пошта - від прикордонного транспортного сервера до внутрішньої організації Exchange	25/TCP (SMTP)	Прикордонний транспортний сервер		З'єднувач відправки за промовчанням з ім'ям "EdgeSync - Inbound to ретранслює вхідну пошту з порту 25 на будь-який сервер поштових скриньок підписаного сайту Active Directory. Додаткові відомості див. у розділі . Стандартний з'єднувач "Default Frontend у зовнішній службі транспорту на сервері поштових скриньок прослуховує всю вхідну пошту (включаючи пошту з прикордонних транспортних серверів Exchange 2016 та Exchange 2013) на порту 25.
Вихідна пошта - від внутрішньої організації Exchange на прикордонний транспортний сервер	25/TCP (SMTP)	Сервери поштових скриньок на підписаному Active Directory		Вихідна пошта завжди оминає зовнішню службу транспорту на серверах поштових скриньок. Пошта ретранслюється зі служби транспорту на будь-якому сервері поштових скриньок підписаного сайту Active Directory на прикордонний транспортний сервер за допомогою неявного та невидимого внутрішньоорганізаційного з'єднувача відправки, який автоматично перенаправляє пошту між серверами Exchange Server в одній організації. З'єднувач за промовчанням "Default internal Receive connector на прикордонному транспортному сервері прослуховує пошту за протоколом SMTP на порту 25 зі служби транспорту на будь-якому сервері поштових скриньок підписаного сайту Active Directory.
Вихідна пошта - з прикордонного транспортного сервера до Інтернету	25/TCP (SMTP)	Прикордонний транспортний сервер	Інтернет (все)	З'єднувач відправки за промовчанням з ім'ям "EdgeSync - з в Інтернет" ретранслює вихідну пошту порту 25 з прикордонного транспортного сервера в Інтернет.
Синхронізація EdgeSync	50636/TCP (безпечний LDAP)	Сервери поштових скриньок на підписаному сайті Active Directory, які беруть участь у синхронізації EdgeSync	Прикордонні транспортні сервери	Якщо прикордонний транспортний сервер підписано на сайт Active Directory, всі сервери поштових скриньок, які існують на сайті в даний момент, беруть участь у синхронізації EdgeSync. Але якщо додати інші сервери поштових скриньок пізніше, вони не будуть автоматично брати участь у синхронізації EdgeSync.
DNS-сервер для дозволу імен наступної транзитної ділянки (не показано на малюнку)	53/UDP, 53/TCP (DNS)	Прикордонний транспортний сервер	DNS-сервер	розділ Роздільна здатність імен.
Виявлення відкритого проксі-сервера у службі репутації відправників (не показано малюнку)	Див. примітки	Прикордонний транспортний сервер	Інтернет	За замовчуванням агент аналізу протоколу використовує виявлення відкритого проксі-сервера як одну з умов обчислення рівня репутації вихідного сервера обміну повідомленнями. Для отримання додаткових відомостей див . Для перевірки вихідних серверів обміну повідомленнями на наявність відкритого проксі-сервера використовуються такі TCP-порти: Крім того, якщо у вашій організації для контролю вихідного інтернет-трафіку використовується проксі-сервер, необхідно визначити ім'я, тип та TCP-порт проксі-сервера, необхідні для доступу до Інтернету та виявлення відкритого проксі-сервера. Ви також можете вимкнути виявлення відкритого проксі-сервера. Щоб отримати додаткові відомості, див.

На початок

Дозвіл імен

Дозвіл імен

Дозвіл DNS наступного переходу пошти є основною складовою потоку обробки пошти в будь-якій організації Exchange. Сервери Exchange, які відповідають за отримання вхідної пошти або доставку вихідної, повинні мати можливість дозволяти як внутрішні, так і зовнішні імена вузлів для правильної маршрутизації пошти. Усі внутрішні сервери Exchange повинні мати можливість дозволяти внутрішні імена вузлів для правильної маршрутизації пошти. Існує безліч різних способіврозробка інфраструктури DNS, але важливий результат - забезпечення правильного дозволу імен для наступного переходу на всіх серверах Exchange.