Якщо ви намагаєтеся додати ваш обліковий запис на Outlook.com до іншої поштової програми, вам можуть знадобитися параметри POP, IMAP або SMTP для Outlook.com. Ви можете знайти їх нижче або за посиланням Налаштування POP та IMAP на Outlook.com.

Якщо ви хочете додати свій обліковий запис Outlook.com на інтелектуальний пристрій, наприклад, на камеру для захисту домашніх комп'ютерів, вам знадобиться пароль програми. Щоб отримати додаткові відомості, див. Додавання облікового запису Outlook.com до іншої поштової програми або інтелектуального пристрою.

Параметри POP, IMAP та SMTP для Outlook.com

Якщо потрібно додати обліковий запис Outlook.com до іншої поштової програми, яка підтримує протокол POP або IMAP, використовуйте наведені нижче параметри сервера.

Примітки:

Ім'я сервера IMAP Outlook.Office365.com

Порт IMAP: 993

Метод шифрування IMAP TLS

Outlook.office365.com ім'я сервера POP

POP-порт: 995

Метод шифрування POP TLS

Ім'я сервера SMTP SMTP.Office365.com

Порт SMTP: 587

Метод шифрування SMTP STARTTLS

Увімкніть доступ до протоколу POP в Outlook.com

Якщо ви хочете отримувати доступ до пошти в Outlook.com через POP, вам потрібно включити його.

Змініть установки вашого поштового провайдера

Якщо ви намагаєтеся підключити інший обліковий запис до Outlook.com за допомогою протоколу POP, вам може знадобитися змінити деякі налаштування вашого поштового провайдера, щоб налагодити підключення, яке могло бути заблоковане.

Для облікових записів Gmail з доступом до протоколу POP, .

Для облікових записів Yahoo з доступом до протоколу POP виконайте наведені нижче дії .

Якщо Ви користуєтеся іншими постачальниками електронної пошти, зверніться до них за інструкціями для розблокування підключення.

Outlook.com Помилки підключення за протоколом IMAP

Якщо ви налаштували обліковий запис Outlook.com як IMAP у кількох поштових клієнтах, можливо, ви отримуєте повідомлення про помилку підключення. Ми працюємо над виправленням та оновлюємо цю статтю, якщо ми маємо додаткові відомості. В даний час спробуйте наступне рішення:

Якщо ви використовуєте Outlook.com для доступу до облікового запису, який використовує домен, відмінний від @live. com, @hotmail. com або @outlook. com, ви не зможете синхронізувати облікові записи за протоколом IMAP. Щоб вирішити цю проблему, видаліть підключений обліковий запис IMAP в Outlook.com і переналаштуйте його як підключення POP. Інформацію щодо повторного настроювання облікового запису для використання POP можна отримати у постачальника облікового запису електронної пошти.

Якщо ви використовуєте обліковий запис GoDaddy, дотримуйтеся вказівок, щоб змінити параметри облікового запису GoDaddy для використання з'єднання POP . Якщо використання протоколу POP не вирішило проблему, або необхідно увімкнути протокол IMAP (відключено за замовчуванням), зверніться до служби

У цій статті ми розберемося з тим, як настроїти статичні порти 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

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

  • При створенні в Службі каталогів Active Directory об'єкта шлюзу IP єдиної системи обміну повідомленнями необхідно визначити 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

[Ця стаття є попереднім документом і може бути змінена в майбутніх випусках. Порожні розділи включені як заповнювачі. Якщо ви хочете написати відгук, ми будемо раді отримати його. Надішліть його нам на електронну адресу [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 required for 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 - з <имя сайта Active Directory> в Інтернет" ретранслює вихідну пошту порту 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.

What TCP and UDP ports does my Exchange 2000/2003 Server use?

Для того, щоб configuring firewalls or for troubleshooting communications issues, it may be useful to know what TCP/UDP ports Exchange 2000 Server і Exchange 2000 Conferencing Server є using. Цей article is also true for Exchange Server 2003 installations.

Protocol: LDAP

• Port (TCP/UDP): 389 (TCP)
• Description: Lightweight Directory Access Protocol (LDAP), використовуваний Active Directory, Active Directory Connector, і Microsoft Exchange Server 5.5 directory.

Protocol: LDAP/SSL

• Port (TCP/UDP): 636 (TCP)
• Description: LDAP over Secure Sockets Layer (SSL). Коли SSL є можливим, LDAP data that is transmitted and received is encrypted.
• Щоб відключити SSL, ви повинні налаштовувати комп'ютерний certificate на домашній контролер або Exchange Server 5.5 комп'ютера.

Protocol: LDAP

• Port (TCP/UDP): 379 (TCP)
• Description: Служба технічної підтримки (SRS) використовує TCP port 379.

Protocol: LDAP

• Port (TCP/UDP): 390 (TCP)
• Description: Коли не є стандартний LDAP port, TCP port 390 is recommended alternate port to configure the Exchange Server 5.5 LDAP protocol when Exchange Server 5.5 is running on a Microsoft Windows 2000 Active Directory domain controller.

Protocol: LDAP

• Port (TCP/UDP): 3268 (TCP)
• Description: Global catalog. Windows 2000 Active Directory Global Catalog (який є справжнім домашнім контролером “роля”) літерами на TCP port 3268. Якщо ви рекомендуєте,що потрібно повідомити про те, що глобальний каталог, connect to port 3268 в LDP.

Protocol: LDAP/SSL

• Port (TCP/UDP): 3269 (TCP)
• Description: Global catalog over SSL. Applications that connect to TCP port 3269 of a global catalog server може transmit and receive SSL encrypted data. Натисніть на логічний каталог для підтримки SSL, ви повинні налаштовувати Computer certificate on the Global catalog.

Protocol: IMAP4

• Port (TCP/UDP): 143 (TCP)
• Description: Internet Message Access Protocol Version 4, який може бути використаний як “standards-based” clients such as Microsoft Outlook Express або Netscape Communicator для доступу до електронної пошти. IMAP4 runs on top of Microsoft Internet Information Service (IIS) Admin Service (Inetinfo.exe), і достатній клієнт access to the Exchange 2000 information store.

Protocol: IMAP4/SSL

• Port (TCP/UDP): 993 (TCP)
• Description: IMAP4 через SSL використовує TCP port 993. За допомогою сервера Exchange 2000 IMAP4 (або будь-якого іншого протоколу) над SSL, ви повинні налаштовувати комп'ютерний контроль на сервері Exchange 2000.

Protocol: POP3

• Port (TCP/UDP): 110 (TCP)
• Description: Post Office Protocol version 3, що надає “standards-based” clients such as Outlook Express або Netscape Communicator для доступу до e-mail server. Як з IMAP4, POP3 runs на top of IIS Admin Service, і достатній клієнт access to the Exchange 2000 information store.

Protocol: POP3/SSL

• Port (TCP/UDP): 995 (TCP)
• Description: POP3 over SSL. Доступно до POP3 через SSL, ви повинні налаштовувати комп'ютерний certificate на сервері Exchange 2000.

Protocol: NNTP

• Port (TCP/UDP): 119 (TCP)
• Description: Network News Transport Protocol, деякі звані Usenet protocol, належним чином “standards-based” client access to public folders in the information store. Як з IMAP4 і POP3, NNTP є залежним від IIS Admin Service.

Protocol: NNTP/SSL

Port (TCP/UDP): 563 (TCP)

Description: NNTP over SSL. Для того, щоб NNTP over SSL, ви повинні install a Computer certificate на Exchange 2000 Server.

Protocol: HTTP

• Port (TCP/UDP): 80 (TCP)
• Description: Hyper-Text Transfer Protocol використовується для протоколу, що використовується в основному за допомогою Microsoft Outlook Web Access (OWA), але також може бути деякі адміністративні рішення в Exchange System Manager. HTTP реалізується через World Wide Web Publishing Service (W3Svc), і керує top of IIS Admin Service.

Protocol: HTTP/SSL

• Port (TCP/UDP): 443 (TCP)
• Description: HTTP over SSL. Доступно до HTTP over SSL, ви повинні налаштовуватися на комп'ютері certificate на сервері Exchange 2000.

Protocol: SMTP

• Port (TCP/UDP): 25 (TCP)
• Description: Simple Mail Transfer Protocol, є повідомлення для всіх електронних пошти в Exchange 2000. SMTP Service (SMTPSvc) runs on top of IIS Admin Service. Unlike IMAP4, POP3, NNTP, і HTTP, SMTP в Exchange 2000 не може використовуватися в окремому port for secure communication (SSL), but rather, employs an “band security sub-system” називається Transport Layer Security (TLS).

Protocol: SMTP/SSL

• Port (TCP/UDP): 465 (TCP)
• Description: SMTP over SSL. TCP port 465 is reserved common industry practice for secure SMTP communication using the SSL protocol. Хоча, unlike IMAP4, POP3, NNTP, і HTTP, SMTP в Exchange 2000 не може використовуватися в окремому порту для захисту інформації (SSL), а інші, трудяться в “band security sub-system” називається Transport Layer Security (TLS) . Щоб відключити TLS для роботи на Exchange 2000, ви повинні налаштовувати комп'ютерний certificate на сервері Exchange 2000.

Protocol: SMTP/LSA

• Port (TCP/UDP): 691 (TCP)
• Description: У Microsoft Exchange Routing Engine (як відомо, як RESvc) літери для повідомлень електронної пошти інформації на TCP port 691. Exchange 2000 використовується routing link status information to route messages and routing table is constantly updated. The Link State Algorithm (LSA) propagates outing status information between Exchange 2000 servers. Цей algorithm базується на Open Shortest Path First (OSPF) Protocol з мережевими технологіями, і transfers link state information між routing groups by using the X-LSA-2 Command Verb over SMTP and by using Transmission Control Protocol (TCP) connection to port 691 в routing group.

Protocol: RVP

• Port (TCP/UDP): 80 (TCP)
• Description: RVP є підтримкою для Instant Messaging в Exchange 2000. У той час як RVP комунікацій починається з TCP port 80, сервер підключається до нового підключення до клієнта на ephemeral TCP port до 1024. Because thisn port issues exist when you enable Instant Messaging через firewall.

Protocol: IRC/IRCX

• Port (TCP/UDP): 6667 (TCP)
• Description: Internet Relay Chat (IRC) - це chat protocol. IRCX is the extended version offered by Microsoft. Коли TCP port 6667 є найбільш спільний port для IRC, TCP port 7000 є також дуже frequently used.

Protocol: IRC/SSL

• Port (TCP/UDP): 994 (TCP)
• Description: IRC або SSL. IRC або IRCX над SSL не підтримується в Exchange 2000.

Protocol: X.400

• Port (TCP/UDP): 102 (TCP)
• Description: ITU-T Recommendation X.400 є реально series recomendations for what electronic message handling system (MHS) should look like. TCP port 102 is defined в IETF RFC-1006, який містить OSI communications over a TCP/IP network. В brief, TCP port 102 is the port that the Exchange agent transfer (MTA) використовується для комунікації з іншими X.400-capable MTAs.

Protocol: MS-RPC

• Port (TCP/UDP): 135 (TCP)
• Description: Microsoft Remote procedure Call є Microsoft implementation of remote procedure calls (RPCs). TCP port 135 є фактично тільки RPC Locator Service, який є як реєстратор для всіх RPC-обслуговуваних служб, які працюють на окремому сервері. В Exchange 2000, Routing Group Connector використовує RPC instead of SMTP when the target bridgehead server is running Exchange 5.5. Also, деякі administrative operations require RPC. Щоб configure firewall до enable RPC traffic, багато mores ports than just 135 must be enabled.

Для додаткових відомостей, клацніть статті номерів для перегляду елементів в Microsoft Knowledge Base:

XADM: Setting TCP/IP Port Numbers for Internet Firewalls

XCON: Конфігурація MTA TCP/IP Port # for X.400 and RPC Listens

Protocol: T.120

• Port (TCP/UDP): 1503 (TCP)
• Description: ITU-T Recommendation T.120 є основою recommendations, що define data conferencing. Data conferencing is implemented on the server side as Conferencing Technology Provider (CTP) в Multipoint Control Unit (MCU), який є одним з компонентів Exchange Conferencing Services (ECS). Data conferencing is implemented on the client side as Chat, Application Sharing, Whiteboard, and File Transferring in Microsoft NetMeeting.

Protocol: ULS

• Port (TCP/UDP): 522 (TCP)
• Description: User Locator Service є типом інтернет-ресурсів для конференційних клієнтів, так як NetMeeting. Exchange 2000 Server і Exchange 2000 Конференц-сервер не є реалізованим на ULS, але є доступом до Active Directory для служб directory (by TCP port 389).

Protocol: H.323 (Video)

• Port (TCP/UDP): 1720 (TCP)
• Description: ITU-T Recommendation H.323 defines multimedia conferencing. TCP port 1720 є H.323 (video) call setup port. Після клієнтів підключення, сервер H.323 невідповідає новий, динамічний UDP port буде використано для streaming data.

Protocol: Audio

• Port (TCP/UDP): 1731 (TCP)
• Description: Audio conferencing is enabled in much the same way as H.323 video conferencing is enabled in Exchange 2000 Server. Після clients connect to TCP port 1731, а новий dynamickий port is negotiated for further streaming data.