Ако се опитвате да добавите своя акаунт в 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 достъп следвайте стъпките по-долу.

Ако използвате други доставчици на имейл, трябва да се свържете с тях за инструкции как да деблокирате връзката.

Грешки при IMAP връзка с Outlook.com

Ако сте настроили своя акаунт в 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 и Public Folder Access в Exchange 2010.

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

За да не се превърнат защитните стени в "сито", желателно е да стесните обхвата на използваните RPC портове, в идеалния случай като ги направите статични на всеки сървър за клиентски достъп в масива за клиентски достъп. В допълнение, използването на статични RPC портове ви позволява да намалите потреблението на памет при балансиращите на натоварването (особено HLB) и да опростите тяхната конфигурация (няма нужда да указвате големи диапазони на портове).

В Exchange 2010 услугата RPC Client Access, както и услугата Exchange Address Book могат да бъдат настроени на статични портове. Outlook комуникира с тези услуги чрез интерфейса MAPI.

Статичен порт за услугата Exchange 2010 RPC Client Access

Виртуалната услуга за RPC клиентски достъп на Exchange 2010 е свързана с услугата RPC клиентски достъп, към която клиентите на Outlook MAPI се свързват в Exchange 2010. Когато клиент на Outlook се свърже с Exchange, на сървър за клиентски достъп на Exchange 2010, услугата за клиентски достъп за RPC използва порта за съпоставяне на крайната точка на TCP (TCP/135) и произволен порт от обхвата на динамичния RPC порт (6005-59530) за входящи връзки

За да зададете статичен порт за услугата RPC Client Access в Exchange 2010, трябва да отворите секцията в редактора на системния регистър:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeRPC

Създайте нов ключ с име ПараметриСистема, вътре в който създайте параметър тип REG_DWORDС име TCP/IP порт. Настройката TCP/IP Port указва статичен порт за услугата RPC Client Access. Документацията на Microsoft препоръчва избор на порт в диапазона 59531 - 60554 и използване на тази стойност на всички CAS сървъри (ние посочихме порт 59532, разбира се, той не трябва да се използва от друг софтуер).

След задаване на статични портове трябва да рестартирате услугата за клиентски достъп на Microsoft Exchange RPC, за да влязат в сила промените.

Рестартирайте услугата MSExchangeRPC

Статичен порт за услугата адресна книга на Exchange 2010

В Exchange 2010 преди SP1, специален конфигурационен файл Microsoft.exchange.addressbook.service.exe.config. След пускането на Exchange 2010 SP1 можете да зададете статичния порт на тази услуга чрез системния регистър. За да направите това, отворете редактора на системния регистър и отидете до клона:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeAB\Parameters

Създайте нов параметър RpcTcpPort(от тип REG_SZ) и му дайте номера на порта, който искате да коригирате за услугата адресна книга на Exchange. Препоръчително е да използвате всеки свободен порт в диапазона 59531-60554 и след това да го използвате на всички сървъри за клиентски достъп на Exchange 2010 в домейна. Ще зададем RpcTcpPort=59533

След това трябва да рестартирате услугата Microsoft Exchange Address Book

Рестартирайте услугата MSExchangeAB

Важно:Когато мигрирате от Exchange 2010 RTM към SP1, този ключ трябва да бъде зададен ръчно, той не се наследява автоматично.

Настройка на статичен порт за свързване към споделени папки

Публичните папки са достъпни от клиент на Outlook директно чрез услугата RPC Client Access на сървър с ролята на пощенска кутия. Тази настройка трябва да се направи на всички сървъри с ролята на пощенска кутия, които съдържат базата данни споделени папки(подобно на CAS сървърите). Отворете редактора на системния регистър и отидете на клона

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeRPC

Създайте нов ключ с име ПараметриСистема, вътре в който създайте параметър тип REG_DWORD с име TCP/IP порт. Задайте неговата стойност: TCP/IP порт = 59532.

След като зададете статично порта на публичната папка, трябва да рестартирате услугата Microsoft Exchange RPC Client Access на всеки сървър на пощенска кутия.

Проверете използването на статичен порт между Outlook и Exchange 2010

След промениНека проверим дали Outlook се свързва към статичните RPC портове, които посочихме. За да направите това, рестартирайте Outlook на клиентската машина и след това изпълнете следната команда в командния ред:

Netstat -на

Приложим за: Exchange Server 2010 SP1

Последна промяна на раздела: 2011-04-22

Този раздел предоставя информация за портове, удостоверяване и шифроване за всички пътища за данни, използвани в Microsoft Exchange Server 2010. Разделът „Бележки“ след всяка таблица изяснява или дефинира нестандартни методи за удостоверяване или шифроване.

Транспортни сървъри

В Exchange 2010 има две сървърни роли, които изпълняват функции за транспортиране на съобщения: Hub Transport server и Edge Transport server.

Следващата таблица предоставя информация за портове, удостоверяване и шифроване на пътя на данните между тези транспортни сървъри и други сървъри и услуги на Exchange 2010.

Пътища за данни за транспортни сървъри

Път на данни	Необходими портове			Поддръжка на криптиране
Между два Hub Transport сървъра				Да, с TLS (сигурност на транспортния слой)
От Hub Transport сървър към Edge Transport сървър		пряко доверие	пряко доверие	Да, с помощта на TLS
От Edge Transport сървър към Hub Transport сървър		пряко доверие	пряко доверие	Да, с помощта на TLS
Между два Edge Transport сървъра		Анонимен, удостоверяване на сертификат	Анонимно, с удостоверение	Да, с помощта на TLS
От сървър на пощенска кутия до чрез услугата за изпращане на поща на Microsoft Exchange		NTLM. Ако ролята на сървъра Hub Transport и ролята на сървъра на пощенската кутия се изпълняват на един и същи сървър, се използва протоколът Kerberos.		Да, използвайки RPC криптиране
От Hub Transport сървър към сървър на пощенска кутия чрез MAPI		NTLM. Ако ролята на сървъра Hub Transport и ролята на сървъра на пощенската кутия са инсталирани на един и същи сървър, се използва протоколът Kerberos.		Да, използвайки RPC криптиране
				Да, с помощта на TLS
Услуга Microsoft Exchange EdgeSync от Hub Transport сървър към Edge Transport сървър				Да, използвайки LDAP през SSL (LDAPS)
Достъп до Active Directory от Hub Transport сървър
Достъп до услугата за управление на права на Active Directory (AD RMS) от Hub Transport сървър				Да, със SSL
SMTP клиенти към Hub Transport сървър (например крайни потребители, използващи Windows Live Mail)				Да, с помощта на TLS

Бележки за транспортни сървъри

• Целият трафик между Hub Transport сървъри е шифрован с помощта на Transport Layer Security (TLS) и самоподписаните сертификати, инсталирани от Exchange 2010 Setup.
• Целият трафик между Edge Transport сървъри и Hub Transport сървъри е удостоверен и криптиран. Взаимният TLS се използва като механизъм за удостоверяване и криптиране. Вместо проверка на X.509, Exchange 2010 използва пряко доверие. Директно доверие означава, че наличието на сертификат в Active Directory Services или Active Directory Lightweight Directory Services (AD LDS) проверява автентичността на сертификата. Справочната услуга на Active Directory се счита за доверен механизъм за съхранение. Когато се използва директно доверие, няма значение дали се използва самоподписан сертификат или сертификат, подписан от CA. Когато абонирате Edge Transport сървър към организация на Exchange, Edge Subscription публикува сертификата на Edge Transport сървъра в услугата за директория на Active Directory, така че Hub Transport сървърите да могат да го проверят. Услугата Microsoft Exchange EdgeSync добавя набор от сертификати на Hub Transport сървър към Active Directory Lightweight Directory Services (AD LDS), така че сървърът Edge Transport да може да ги валидира.
• EdgeSync използва защитена LDAP връзка от Hub Transport сървър към абонирани Edge Transport сървъри на TCP порт 50636. Active Directory Lightweight Directory Services също слуша на TCP порт 50389. Връзките към този порт не използват SSL протокол. Можете да използвате LDAP помощни програми, за да се свържете с този порт и да проверите AD LDS данните.
• По подразбиране трафикът между Edge Transport сървъри, разположени в две различни организации, е шифрован. Настройката на Exchange 2010 създава самоподписан сертификат и активира TLS по подразбиране. Това позволява на всяка изпращаща система да шифрова входяща SMTP сесия към Exchange. По подразбиране Exchange 2010 също се опитва да използва TLS за всички отдалечени връзки.
• Методите за удостоверяване на трафика между Hub Transport сървъри и сървъри на пощенска кутия са различни, когато ролите на Hub Transport и сървъра на пощенска кутия са инсталирани на един и същи компютър. Локалният пренос на поща използва Kerberos удостоверяване. Отдалеченото прехвърляне на поща използва NTLM удостоверяване.
• Exchange 2010 също поддържа сигурност на домейна. Защитата на домейна е набор от функции на Exchange 2010 и Microsoft Outlook 2010, които предоставят евтина алтернатива на S/MIME и други решения за сигурност на интернет съобщенията. Сигурността на домейна предоставя начин за управление на сигурни комуникационни пътища между домейни в Интернет. След като тези защитени пътеки са конфигурирани, съобщенията, изпратени успешно чрез тях от удостоверен подател, се показват на потребителите на Outlook и Outlook Web Access като „защитени на ниво домейн“ съобщения. За повече информация вижте Общ преглед на сигурността на домейна.
• Много агенти могат да работят както на Hub Transport сървъри, така и на Edge Transport сървъри. Обикновено анти-спам агентите използват информация локален компютървърху които се изпълняват. По този начин практически не се изисква взаимодействие с отдалечени компютри. Изключение е филтрирането на получатели. Филтрирането на получатели изисква извикване на AD LDS или Active Directory. Препоръчваме ви да извършите филтриране на получатели на Edge Transport сървър. В този случай директорията AD LDS е на същия компютър, на който е инсталирана ролята на Edge Transport server, така че не е необходима отдалечена връзка. Ако филтрирането на получатели е инсталирано и конфигурирано на Hub Transport сървър, се изисква достъп до услугата за директория на Active Directory.
• Агентът за анализ на протокола се използва от функцията за репутация на изпращача в Exchange 2010. Този агент също се свързва с различни външни прокси сървъри, за да определи пътищата на входящото съобщение за подозрителни връзки.
• Всички други анти-спам функции използват данни, които се събират, съхраняват и са достъпни само на локалния компютър. Обикновено данни като комбинирания списък с безопасни податели или данни за получатели за филтриране на получатели се прехвърлят към локалната AD LDS директория с помощта на услугата Microsoft Exchange EdgeSync.
• Агентите за управление на правата за информация (IRM) на Hub Transport сървъри се свързват със сървърите на услугите за управление на правата на Active Directory (AD RMS) в организацията. Услугата за управление на правата на Active Directory (AD RMS) е уеб услуга, която препоръчваме да защитите с SSL. Връзките към AD RMS сървъри се осъществяват чрез HTTPS и се удостоверяват чрез Kerberos или NTLM, в зависимост от конфигурацията на AD RMS сървъра.
• Правилата за регистриране, транспортните правила и правилата за класифициране на съобщенията се съхраняват в Active Directory и до тях има достъп агентът за регистриране и агентът за транспортни правила на Hub Transport сървъри.

  Сървъри за пощенски кутии

  На сървърите на пощенски кутии дали се използва NTLM или Kerberos удостоверяване зависи от потребителския контекст или процеса, под който се изпълнява потребителят на слоя на бизнес логиката на Exchange. В този контекст потребители са всички приложения или процеси, които използват слоя бизнес логика на Exchange. В резултат на това в колоната Удостоверяване по подразбиранемаси Пътища за данни за сървъри на пощенски кутиимного редове имат стойност NTLM/Kerberos.

  Слоят на бизнес логиката на Exchange се използва за достъп и взаимодействие с магазина на Exchange. Слоят на бизнес логиката на Exchange също се извиква от магазина на Exchange, за да взаимодейства с външни приложения и процеси.

  Когато потребител на ниво бизнес логика на Exchange работи в контекста на локалната система, методът за удостоверяване на потребителя за достъп до хранилището на Exchange винаги е Kerberos. Използва се методът за удостоверяване Kerberos, тъй като получателят трябва да бъде удостоверен чрез компютърния акаунт „Локална система“ и изисква двупосочно доверие с удостоверяване.

  Ако получателят на слоя бизнес логика на Exchange не работи в контекста на локална система, методът за удостоверяване е NTLM. Например, когато администратор изпълнява cmdlet на Exchange Management Shell, който използва слоя бизнес логика на Exchange, се използва NTLM удостоверяване.

  RPC трафикът винаги е криптиран.

  Следващата таблица предоставя информация за портове, удостоверяване и шифроване на пътя на данните за сървъри на пощенски кутии.

  Пътища за данни за сървъри на пощенски кутии

  Път на данни	Необходими портове	Удостоверяване по подразбиране	Поддържан метод за удостоверяване	Поддръжка на криптиране	Криптиране на данни по подразбиране
  	389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC Net Logon)			Да, използвайки 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 Web Services)				Да, със SSL
  Сървър за клиентски достъп към сървър за клиентски достъп (POP3)				Да, със SSL
  Сървър за клиентски достъп към сървър за клиентски достъп (IMAP4)				Да, със SSL
  Office Communications Server към сървър за клиентски достъп (когато интеграцията на Office Communications Server и Outlook Web App е активирана)	5075-5077/TCP (IN), 5061/TCP (OUT)	mTLS (задължително)	mTLS (задължително)	Да, със SSL

  Бележки за сървъри за клиентски достъп

  Сървъри за унифицирани съобщения

  IP шлюзовете и IP телефонните централи поддържат само автентификация със сертификати, която използва взаимно TLS удостоверяване за шифроване на SIP трафик и удостоверяване на базата на IP адрес за SIP или TCP връзки. IP шлюзовете не поддържат NTLM и Kerberos удостоверяване. Следователно, когато се използва удостоверяване, базирано на IP адрес, механизмът за удостоверяване за некриптирани връзки (TCP) използва IP адресите на връзките. Когато се използва в Unified Messaging, удостоверяването на базата на IP проверява дали на дадения IP адрес е разрешено свързване. IP адресът е конфигуриран на IP шлюза или IP PBX.

  IP шлюзовете и IP PBX поддържат Mutual TLS за криптиране на SIP трафик. След успешно импортиране и експортиране на необходимите доверени сертификати, IP шлюзът или IP PBX ще поиска сертификат от сървъра за унифицирани съобщения и след това ще поиска сертификат от IP шлюза или IP PBX. Обменът на доверени сертификати между IP шлюза или IP PBX и сървъра за унифицирани съобщения позволява на двете устройства да комуникират сигурно, използвайки Mutual TLS.

  Следната таблица предоставя информация за порт, удостоверяване и шифроване за пътища на данни между UM сървъри и други сървъри.

  Пътища за данни за сървъри за унифицирани съобщения

  Път на данни	Необходими портове	Удостоверяване по подразбиране	Поддържан метод за удостоверяване	Поддръжка на криптиране	Криптиране на данни по подразбиране
  Достъп до Active Directory	389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC Net Logon)			Да, използвайки Kerberos криптиране
  UM Dial-in (IP PBX/VoIP Gateway)	5060/TCP, 5065/TCP, 5067/TCP (в незащитен режим), 5061/TCP, 5066/TCP, 5068/TCP (в защитен режим), динамичен обхват на портовете 16000-17000/TCP (управление), динамичен UDP портове от диапазона 1024-65535/UDP (RTP)	По IP адрес	Чрез IP адрес, MTLS	Да, използвайки SIP/TLS, SRTP
  UM уеб услуга	80/TCP, 443/TCP (SSL)	Интегрирано Windows удостоверяване (договаряне)		Да, със SSL
  От сървър за унифицирани съобщения до сървър за клиентски достъп	5075, 5076, 5077 (TCP)	Интегрирано Windows удостоверяване (договаряне)	Basic, Digest, NTLM, Negotiate (Kerberos)	Да, със SSL
  UM сървър към сървър за клиентски достъп (възпроизвеждане на телефон)	Динамичен RPC			Да, използвайки RPC криптиране
  От сървър за унифицирани съобщения до сървър Hub Transport				Да, с помощта на TLS
  От сървър за унифицирани съобщения до сървър за пощенска кутия				Да, използвайки RPC криптиране

  Бележки за сървъри за унифицирани съобщения

  • Когато създавате обект на UM IP шлюз в Active Directory, трябва да дефинирате IP адреса на физическия IP шлюз или IP PBX. Когато определите IP адреса на обекта на UM IP шлюз, IP адресът се добавя към списъка с валидни IP шлюзове или IP PBX (известни също като участници в SIP сесия), с които UM сървърът има право да комуникира. След като създадете IP шлюз за UM, можете да го свържете с план за набиране на UM. Съпоставянето на UM IP шлюз към план за набиране позволява на UM сървъри, които са нанесени към план за набиране, да използват удостоверяване, базирано на IP адрес, за да комуникират с IP шлюза. Ако UM IP шлюзът не е създаден или конфигуриран да използва правилния IP адрес, удостоверяването ще бъде неуспешно и UM сървърите няма да приемат връзки от IP адреса на този IP шлюз. Освен това, ако внедрите Mutual TLS, IP шлюз или IP PBX и сървъри за унифицирани съобщения, UM IP шлюзът трябва да бъде конфигуриран да използва пълно квалифицирано име на домейн (FQDN). След като конфигурирате UM IP шлюз с помощта на FQDN, трябва също да добавите запис на хост за шлюза към зоната за директно DNS търсене.
  • В Exchange 2010 сървърът за унифицирани съобщения може да комуникира на порт 5060/TCP (незащитен) или порт 5061/TCP (защитен) и може да бъде конфигуриран да използва и двата порта.

  За повече информация вижте Разбиране на UM VoIP сигурността и Разбиране на протоколи, портове и услуги в Unified Messaging.

  Правила на защитната стена на Windows, създадени от инсталацията на Exchange 2010

  Защитната стена на Windows в режим повишена сигурносте компютърно-базирана защитна стена, която филтрира входящия и изходящия трафик въз основа на правилата на защитната стена. Настройката на Exchange 2010 създава правила на защитната стена на Windows, за да отвори портовете, необходими за комуникация между сървър и клиент във всяка сървърна роля. Следователно вече не е необходимо да използвате SCW, за да конфигурирате тези настройки. За повече информация относно защитната стена на Windows с разширена защита вижте Защитна стена на Windows с разширена защита и IPsec.

  Следващата таблица изброява правилата на защитната стена на Windows, генерирани от програматаИнсталации на Exchange, включително портовете, които са отворени на всяка сървърна роля. Можете да прегледате тези правила, като използвате MMC модула за защитна стена на Windows с разширена защита.

  Име на правилото	Сървърни роли	Порт	програма
  MSExchangeADTopology - RPC (TCP входящ)		Динамичен RPC	Bin\MSExchangeADTopologyService.exe
  MSExchangeMonitoring - RPC (TCP входящ)	Сървър за клиентски достъп, Hub Transport сървър, Edge Transport сървър, Unified Messaging сървър	Динамичен RPC	Bin\Microsoft.Exchange.Management.Monitoring.exe
  MSExchangeServiceHost - RPC (TCP входящ)		Динамичен RPC	Bin\Microsoft.Exchange.ServiceHost.exe
  MSExchangeServiceHost - RPCEPMap (TCP Inbound)			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-in)	Сървър за клиентски достъп	5075, 5076, 5077 (TCP)	inetsrv\w3wp.exe
  MSExchangeAB RPC (TCP входящ)	Сървър за клиентски достъп	Динамичен RPC
  MSExchangeAB-RPCEPMap (TCP-in)	Сървър за клиентски достъп		Bin\Microsoft.Exchange.AddressBook.Service.exe
  MSExchangeAB-RpcHttp (TCP-in)	Сървър за клиентски достъп	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 Inbound)	Сървър на пощенска кутия		Bin\MSExchangeMailboxAssistants.exe
  MSExchangeMailSubmission - RPC (TCP входящ)	Сървър на пощенска кутия	Динамичен RPC
  MSExchangeMailSubmission - RPCEPMap (TCP Inbound)	Сървър на пощенска кутия		Bin\MSExchangeMailSubmission.exe
  MSExchangeMigration - RPC (TCP входящ)	Сървър на пощенска кутия	Динамичен RPC	Bin\MSExchangeMigration.exe
  MSExchangeMigration - RPCEPMap (TCP входящ)	Сървър на пощенска кутия		Bin\MSExchangeMigration.exe
  MSExchangerepl - Копирно устройство на журнал (TCP входящ)	Сървър на пощенска кутия		Bin\MSExchangeRepl.exe
  MSExchangerepl - RPC (TCP входящ)	Сървър на пощенска кутия	Динамичен RPC	Bin\MSExchangeRepl.exe
  MSExchangerepl - RPC-EPMap (TCP-in)	Сървър на пощенска кутия		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-in)	Сървър на пощенска кутия
  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 входящ)	Hub Transport сървър, Edge Transport сървър, сървър на пощенска кутия		Bin\MSExchangeTransportLogSearch.exe
  SESWorker (GFW) (TCP-in)	Сървър за унифицирани съобщения
  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)в името на правилото.
  • Няколко Обменни услугиизползвайте извиквания на отдалечени процедури (RPC) за комуникация. Сървърните процеси, които използват извиквания на отдалечени процедури, се свързват с RPC картографа на крайна точка, за да получат динамични крайни точки и да ги регистрират в базата данни на картографа на крайна точка. RPC клиентите взаимодействат с RPC Endpoint Mapper, за да определят крайните точки, използвани от сървърния процес. По подразбиране RPC Endpoint Mapper слуша на порт 135 (TCP). Когато конфигурирате защитната стена на Windows за процес, който използва извиквания на отдалечени процедури, настройката на Exchange 2010 създава две правила за защитна стена за този процес. Едно правило позволява комуникация с картографа на RPC крайна точка, а второто правило позволява комуникация с динамично присвоена крайна точка. За повече информация относно извикванията на отдалечени процедури вижте статията. За повече информация относно създаването на правила на защитната стена на Windows за динамично извикване на отдалечена процедура вижте статията.

    За повече информация вижте статия 179442 от базата знания на Microsoft

[Тази статия е предварителен документ и подлежи на промяна в бъдещи версии. Празните секции са включени като контейнери. Ако искате да напишете отзив, ще се радваме да го получим. Изпратете ни го по имейл [имейл защитен]]

Приложим за: Exchange Server 2016

Информация за мрежовите портове, които Exchange 2016 използва за клиентски достъп и пощенски поток.

Тази тема предоставя информация за мрежовите портове, използвани от Microsoft Exchange Server 2016 за комуникация с имейл клиенти, сървъри за интернет поща и други услуги, които се намират извън вашия местна организацияРазмяна. Преди да започнете, разгледайте следните основни правила.

Ние не поддържаме ограничаване или модифициране на мрежов трафик между вътрешни сървъри на Exchange, между вътрешни сървъри на Exchange и вътрешни сървъри на Lync или Skype за бизнеса, или между вътрешни сървъри на Exchange и вътрешни контролери на домейни на Active Directory във всеки от типовете топология. Ако използвате защитни стени или мрежови устройства, които могат да ограничават или променят този мрежов трафик, трябва да настроите правила, които да позволяват свободни и неограничени комуникации между тези сървъри (правила, които позволяват мрежов трафик към и от всеки порт, включително произволни RPC портове и всякакви протокол). , което не променя нито един бит).

Edge Transport сървърите са почти винаги в периметърната мрежа, така че се очаква мрежовият трафик между Edge Transport сървъра и интернет, както и между Edge Transport сървъра и вътрешната организация на Exchange, да бъде ограничен. Тези мрежови портове са описани в този раздел.

От вас се очаква да ограничите мрежовия трафик между външни клиенти и услуги и вътрешната организация на Exchange. Можете също да ограничите трафика между вътрешни клиенти и вътрешни сървъри на Exchange. Тези мрежови портове са описани в този раздел.

Съдържание

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

Мрежови портове, необходими за потока на пощата (без Edge Transport сървъри)

Мрежови портове, необходими за пощенски поток с Edge Transport сървъри

Мрежови портове, необходими за хибридно внедряване

Мрежови портове, необходими за Unified Messaging

Мрежовите портове, от които имейл клиентите се нуждаят за достъп до пощенски кутии и други услуги в организацията на Exchange, са описани в следващата диаграма и таблица.

Бележки.

Дестинацията за тези клиенти и услуги са услугите за клиентски достъп на сървъра на пощенската кутия. В Exchange 2016 услугите за клиентски достъп (външни) и вътрешните услуги се инсталират заедно на един и същ сървър на пощенска кутия. Вижте раздела за повече информация.

Въпреки че диаграмата показва клиенти и услуги от Интернет, концепциите са същите за вътрешни клиенти (например клиенти в гора от акаунти, осъществяващи достъп до сървъри на Exchange в гора от ресурси). По същия начин в таблицата няма колона „Източник“, тъй като източникът може да бъде всяко местоположение извън организацията на Exchange (например интернет или гора от акаунти).

Edge Transport сървърите не участват в мрежовия трафик, свързан с тези клиенти и услуги.

Предназначение	Портове	Бележки
Шифрованите уеб връзки се използват от следните клиенти и услуги. Услуга за автоматично откриване Exchange ActiveSync Уеб услуги на Exchange (EWS) Разпространение на офлайн адресни книги Outlook навсякъде (RPC през HTTP) MAPI Outlook през HTTP Outlook в мрежата	443/TCP (HTTPS)	EWS справка за обмен
Нешифрованите уеб връзки се използват от следните клиенти и услуги. Публикувайте своя календар в мрежата 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)	Конекторът за получаване по подразбиране е „Клиентски интерфейс " във външната транспортна услуга слуша за съобщения от удостоверени SMTP клиенти на порт 587. Забележка. Ако имате имейл клиенти, които могат да изпращат само удостоверени SMTP съобщения на порт 25, можете да промените стойността на обвързване на този конектор за получаване, за да слушате и удостоверени SMTP съобщения на порт 25.

Към началото

Мрежови портове, необходими за потока на пощата

Изходяща поща

25/TCP (SMTP)

Сървър на пощенска кутия

Интернет (всички)

По подразбиране Exchange не създава конектори за изпращане, които ви позволяват да изпращате поща до интернет. Трябва да създадете конекторите за изпращане ръчно. Вижте раздела за повече информация.

Изходяща поща (ако е изпратена чрез външна транспортна услуга)

25/TCP (SMTP)

Сървър на пощенска кутия

Интернет (всички)

Изходящата поща се изпраща през външната транспортна услуга само ако настройката за конектор за изпращане е активирана Прокси през сървъра за клиентски достъпв EAC или параметъра -FrontEndProxyEnabled $true в обвивката за управление на Exchange.

В този случай конекторът за получаване по подразбиране „Изходящ прокси фронтенд " във външната транспортна услуга слуша за изходяща поща от транспортната услуга на сървъра на пощенската кутия. За повече информация вижте .

DNS сървър за разрешаване на имена на следващ хоп за поща (не е показано)

53/UDP, 53/TCP (DNS)

Сървър на пощенска кутия

DNS сървър

Към началото

Абониран Edge Transport сървър, инсталиран в периметърната мрежа, влияе върху потока на пощата по следните начини:

Изходящата поща от организацията на Exchange никога не преминава през външната транспортна услуга на сървърите на пощенските кутии. Той винаги пренасочва от транспортната услуга на сървъра на пощенската кутия на абонирания сайт на Active Directory към сървъра Edge Transport (независимо от версията на Exchange на сървъра Edge Transport).

Входящата поща се пренасочва от сървъра Edge Transport към сървъра на пощенската кутия на абонирания сайт на Active Directory. Това означава следното:

• Пощата от Exchange 2016 или Exchange 2013 Edge Transport сървър първо влиза във външната транспортна услуга и след това се насочва към транспортната услуга на сървъра на пощенската кутия на Exchange 2016.

  Пощата от сървър на Exchange 2010 Edge Transport винаги отива директно към транспортната услуга на сървър на пощенска кутия на Exchange 2016.

Мрежовите портове, необходими за потока на пощата в организации на Exchange с Edge Transport сървъри, са описани в следващата диаграма и таблица.

Предназначение	Портове	Източник	Предназначение	Бележки
Входяща поща - от Интернет към Edge Transport сървър	25/TCP (SMTP)	Интернет (всички)		Конекторът за получаване по подразбиране, наречен Default Internal Receive Connector <имя пограничного транспортного сервера> " на сървъра Edge Transport слуша за анонимна SMTP поща на порт 25.
Входяща поща - от сървъра Edge Transport до вътрешната организация на Exchange	25/TCP (SMTP)	Граничен транспортен сървър		Конекторът за изпращане по подразбиране, наречен „EdgeSync – Inbound to " Препредава входяща поща на порт 25 към всеки сървър на пощенска кутия в абонирания сайт на Active Directory. За повече информация вижте . Конектор за получаване по подразбиране „Външен интерфейс по подразбиране " във външната транспортна услуга на сървъра на пощенската кутия слуша за цялата входяща поща (включително поща от сървъри Exchange 2016 и Exchange 2013 Edge Transport) на порт 25.
Изходяща поща - от вътрешна организация на Exchange към Edge Transport сървър	25/TCP (SMTP)	Сървъри на пощенски кутии в абониран сайт на Active Directory		Изходящата поща винаги заобикаля услугата за външен транспорт на сървърите на пощенските кутии. Пощата се предава от транспортната услуга на всеки сървър на пощенска кутия в абониран сайт на Active Directory към Edge Transport сървър чрез използване на скрит и невидим вътрешноорганизационен конектор за изпращане, който автоматично насочва пощата между сървърите на Exchange в същата организация. Вътрешен конектор за получаване по подразбиране на крайния транспортен сървър слуша за SMTP поща на порт 25 от транспортната услуга на всеки сървър на пощенска кутия в абонирания сайт на Active Directory.
Изходяща поща - от сървъра Edge Transport към Интернет	25/TCP (SMTP)	Граничен транспортен сървър	Интернет (всички)	Конекторът за изпращане по подразбиране, наречен "EdgeSync - с <имя сайта Active Directory> към интернет" препредава изходяща поща на порт 25 от сървъра Edge Transport към интернет.
EdgeSync Синхронизация	50636/TCP (защитен LDAP)	Сървъри на пощенски кутии в абонирания сайт на Active Directory, които участват в синхронизирането на EdgeSync	Гранични транспортни сървъри	Ако Edge Transport сървър е абониран за сайт на Active Directory, всички сървъри на пощенски кутии, които в момента съществуват в сайта, участват в синхронизирането на EdgeSync. Но ако добавите още сървъри на пощенска кутия по-късно, те няма да участват автоматично в синхронизирането на EdgeSync.
DNS сървър за разрешаване на името на следващия хоп (не е показано)	53/UDP, 53/TCP (DNS)	Граничен транспортен сървър	DNS сървър	Вижте Разрешаване на имена.
Репутация на изпращача Откриване на отворен прокси (не е показано)	виж бележките	Граничен транспортен сървър	интернет	По подразбиране агентът за анализ на протоколи използва открит прокси сървър като едно от условията за изчисляване на нивото на репутация на сървъра за съобщения източник. Вижте статията за повече информация. Следните TCP портове се използват за проверка на изходните сървъри за съобщения за отворен прокси сървър: Освен това, ако вашата организация използва прокси сървър за контрол на изходящия интернет трафик, трябва да определите името на прокси сървъра, типа и TCP порта, необходими за достъп до интернет и откриване на отворен прокси сървър. Можете също да деактивирате откриването на отворен прокси. Вижте раздела за повече информация.

Към началото

Резолюция на имената

Резолюция на имената

Разрешаването на поща след DNS е основна част от пощенския поток във всяка организация на Exchange. Exchange сървърите, отговорни за получаване на входяща поща или доставка на изходяща поща, трябва да могат да разрешават вътрешни и външни имена на хостове, за да маршрутизират правилно пощата. Всички вътрешни сървъри на Exchange трябва да могат да разрешават вътрешни имена на хостове, за да маршрутизират правилно пощата. Има много различни начини за проектиране на вашата DNS инфраструктура, но важният резултат е да се гарантира, че следващият хоп е разрешен правилно на всички Exchange сървъри.

Какви TCP и UDP портове използва моят Exchange 2000/2003 сървър?

За целите на конфигуриране на защитни стени или за отстраняване на комуникационни проблеми може да е полезно да знаете какви TCP/UDP портове използват Exchange 2000 Server и Exchange 2000 Conferencing Server. Тази статия е вярна и за инсталации на Exchange Server 2003.

Протокол: LDAP

• Порт (TCP/UDP): 389 (TCP)
• Описание: Lightweight Directory Access Protocol (LDAP), използван от Active Directory, Active Directory Connector и директорията на Microsoft Exchange Server 5.5.

Протокол: LDAP/SSL

• Порт (TCP/UDP): 636 (TCP)
• Описание: LDAP през Secure Sockets Layer (SSL). Когато SSL е активиран, LDAP данните, които се предават и получават, са криптирани.
• За да активирате SSL, трябва да инсталирате компютърен сертификат на домейн контролера или компютъра с Exchange Server 5.5.

Протокол: LDAP

• Порт (TCP/UDP): 379 (TCP)
• Описание: Услугата за репликация на сайт (SRS) използва TCP порт 379.

Протокол: LDAP

• Порт (TCP/UDP): 390 (TCP)
• Описание: Въпреки че не е стандартен LDAP порт, TCP порт 390 е препоръчителният алтернативен порт за конфигуриране на LDAP протокола на Exchange Server 5.5, когато Exchange Server 5.5 работи на Microsoft Windows 2000 Active Directory домейн контролер.

Протокол: LDAP

• Порт (TCP/UDP): 3268 (TCP)
• Описание: Глобален каталог. Глобалният каталог на Windows 2000 Active Directory (което всъщност е „роля“ на домейн контролер) слуша TCP порт 3268. Когато отстранявате проблеми, които може да са свързани с глобален каталог, свържете се към порт 3268 в LDP.

Протокол: LDAP/SSL

• Порт (TCP/UDP): 3269 (TCP)
• Описание: Глобален каталог през SSL. Приложенията, които се свързват към TCP порт 3269 на сървър за глобален каталог, могат да предават и получават SSL криптирани данни. За да конфигурирате глобален каталог да поддържа SSL, трябва да инсталирате компютърен сертификат в глобалния каталог.

Протокол: IMAP4

• Порт (TCP/UDP): 143 (TCP)
• Описание: Internet Message Access Protocol версия 4, може да се използва от „базирани на стандарти“ клиенти като Microsoft Outlook Expressили Netscape Communicator за достъп до сървъра за електронна поща. IMAP4 работи върху Microsoft Internet Information Service (IIS) Admin Service (Inetinfo.exe) и позволява достъп на клиента до хранилището на информация на Exchange 2000.

Протокол: IMAP4/SSL

• Порт (TCP/UDP): 993 (TCP)
• Описание: IMAP4 през SSL използва TCP порт 993. Преди сървър на Exchange 2000 да поддържа IMAP4 (или който и да е друг протокол) през SSL, трябва да инсталирате компютърен сертификат на сървъра на Exchange 2000.

Протокол: POP3

• Порт (TCP/UDP): 110 (TCP)
• Описание: Post Office Protocol версия 3, позволява на „базирани на стандарти“ клиенти като Outlook Express или Netscape Communicator за достъп до сървъра за електронна поща. Както при IMAP4, POP3 работи върху услугата за администриране на IIS и позволява достъп на клиента до хранилището на информация на Exchange 2000.

Протокол: POP3/SSL

• Порт (TCP/UDP): 995 (TCP)
• Описание: POP3 през SSL. За да разрешите POP3 през SSL, трябва да инсталирате компютърен сертификат на сървъра Exchange 2000.

Протокол: NNTP

• Порт (TCP/UDP): 119 (TCP)
• Описание: Протоколът за мрежов транспорт на новини, понякога наричан протокол Usenet, позволява „базиран на стандарти“ клиентски достъп до публични папки в хранилището за информация. Както при IMAP4 и POP3, NNTP зависи от IIS Admin Service.

Протокол: NNTP/SSL

Порт (TCP/UDP): 563 (TCP)

Описание: NNTP през SSL. За да активирате NNTP през SSL, трябва да инсталирате компютърен сертификат на Exchange 2000 Server.

Протокол: HTTP

• Порт (TCP/UDP): 80 (TCP)
• Описание: Hyper-Text Transfer Protocol е протоколът, използван предимно от Microsoft Outlook Web Access (OWA), но също така позволява някои административни действия в Exchange System Manager. HTTP се внедрява чрез World Wide Web Publishing Service (W3Svc) и работи върху IIS Admin Service.

Протокол: HTTP/SSL

• Порт (TCP/UDP): 443 (TCP)
• Описание: HTTP през SSL. За да разрешите HTTP през SSL, трябва да инсталирате компютърен сертификат на сървъра Exchange 2000.

Протокол: SMTP

• Порт (TCP/UDP): 25 (TCP)
• Описание: Simple Mail Transfer Protocol е основата за целия транспорт на електронна поща в Exchange 2000. SMTP услугата (SMTPSvc) работи върху IIS Admin Service. За разлика от IMAP4, POP3, NNTP и HTTP, SMTP в Exchange 2000 не използва отделен порт за защитена комуникация (SSL), а по-скоро използва „вътрешна подсистема за сигурност“, наречена Защита на транспортния слой (TLS).

Протокол: SMTP/SSL

• Порт (TCP/UDP): 465 (TCP)
• Описание: SMTP през SSL. TCP порт 465 е запазен от обичайната индустриална практика за защитена SMTP комуникация, използваща SSL протокола. Въпреки това, за разлика от IMAP4, POP3, NNTP и HTTP, SMTP в Exchange 2000 не използва отделен порт за защитена комуникация (SSL), а по-скоро използва „вътрешна подсистема за сигурност“, наречена Защита на транспортния слой (TLS). . За да разрешите TLS да работи на Exchange 2000, трябва да инсталирате компютърен сертификат на сървъра на Exchange 2000.

Протокол: SMTP/LSA

• Порт (TCP/UDP): 691 (TCP)
• Описание: Механизмът за маршрутизиране на Microsoft Exchange (известен също като RESvc) слуша информация за състоянието на връзката за маршрутизиране на TCP порт 691. Exchange 2000 използва информация за състоянието на връзката за маршрутизиране, за да маршрутизира съобщенията и таблицата за маршрутизиране се актуализира постоянно. Алгоритъмът за състояние на връзката (LSA) разпространява информация за състоянието на изход между сървърите на Exchange 2000. Този алгоритъм се основава на протокола Open Shortest Path First (OSPF) от мрежовата технология и прехвърля информация за състоянието на връзката между групите за маршрутизиране чрез използване на командния глагол X-LSA-2 през SMTP и чрез използване на връзка с протокол за контрол на предаването (TCP) към порт 691 в група за маршрутизиране.

Протокол: RVP

• Порт (TCP/UDP): 80 (TCP)
• Описание: RVP е основата за незабавни съобщения в Exchange 2000. Докато RVP комуникацията започва с TCP порт 80, сървърът бързо настройва нова връзка към клиента на ефимерен TCP порт над 1024. Тъй като този порт не е известен предварително, възникват проблеми, когато активирате незабавни съобщения през защитна стена.

Протокол: IRC/IRCX

• Порт (TCP/UDP): 6667 (TCP)
• Описание: Internet Relay Chat (IRC) е протоколът за чат. IRCX е разширената версия, предлагана от Microsoft. Докато TCP порт 6667 е най-често срещаният порт за IRC, TCP порт 7000 също се използва много често.

Протокол: IRC/SSL

• Порт (TCP/UDP): 994 (TCP)
• Описание: IRC (или чат) през SSL. IRC или IRCX през SSL не се поддържат в Exchange 2000.

Протокол: X.400

• Порт (TCP/UDP): 102 (TCP)
• Описание: Препоръката на ITU-T X.400 всъщност е поредица от препоръки за това как трябва да изглежда една система за обработка на електронни съобщения (MHS). TCP порт 102 е дефиниран в IETF RFC-1006, който описва OSI комуникации през TCP/IP мрежа. Накратко, TCP порт 102 е портът, който агентът за прехвърляне на съобщения на Exchange (MTA) използва, за да комуникира с други поддържащи X.400 MTA.

Протокол: MS-RPC

• Порт (TCP/UDP): 135 (TCP)
• Описание: Microsoft Remote Procedure Call е реализация на Microsoft за извиквания на отдалечени процедури (RPC). TCP порт 135 всъщност е само RPC Locator Service, който е като регистратор за всички RPC-активирани услуги, които се изпълняват на определен сървър. В Exchange 2000 съединителят на групата за маршрутизиране използва RPC вместо SMTP, когато целевият предмостов сървър работи с Exchange 5.5. Освен това някои административни операции изискват RPC. За да конфигурирате защитна стена да активира RPC трафик, трябва да бъдат активирани много повече портове от само 135.

За допълнителна информация щракнете върху номерата на статиите по-долу, за да видите статиите в базата знания на Microsoft:

XADM: Задаване на номера на TCP/IP портове за интернет защитни стени

XCON: Конфигуриране на MTA TCP/IP порт # за X.400 и RPC слушания

Протокол: T.120

• Порт (TCP/UDP): 1503 (TCP)
• Описание: ITU-T Препоръка T.120 е поредица от препоръки, които дефинират конферентната връзка с данни. Конферентната връзка с данни се изпълнява от страната на сървъра като доставчик на конферентна технология (CTP) в многоточковия контролен блок (MCU), който е един от компонентите на услугите за конферентна връзка на обмена (ECS). Конферентната връзка с данни се изпълнява от страна на клиента като чат, споделяне на приложения, бяла дъска и прехвърляне на файлове в Microsoft NetMeeting.

Протокол: ULS

• Порт (TCP/UDP): 522 (TCP)
• Описание: Услугата за локализиране на потребители е вид интернет директория за клиенти за конференции, като NetMeeting. Exchange 2000 Server и Exchange 2000 Conferencing Server не прилагат ULS, а по-скоро се възползват от Active Directory за справочни услуги (чрез TCP порт 389).

Протокол: H.323 (видео)

• Порт (TCP/UDP): 1720 (TCP)
• Описание: ITU-T Препоръка H.323 дефинира мултимедийни конференции. TCP порт 1720 е портът за настройка на H.323 (видео) повикване. След като клиент се свърже, H.323 сървърът договаря нов, динамичен UDP порт, който да се използва за поточно предаване на данни.

Протокол: Аудио

• Порт (TCP/UDP): 1731 (TCP)
• Описание: Аудиоконференциите са активирани по почти същия начин, както H.323 видеоконференциите са активирани в Exchange 2000 Server. След като клиентите се свържат към TCP порт 1731, се договаря нов динамичен порт за по-нататъшно поточно предаване на данни.