Ако се опитвате да добавите своя акаунт в 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 метод за криптиранеНАЧАЛО

Включете 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 клиентски достъп, 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 Server се използваха RPC портове в диапазона 1025-65535).

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

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

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

Виртуалната услуга на Exchange 2010 RPC Client Access е свързана с услугата RPC Client Access, към която се свързват клиентите на Outlook MAPI в Exchange 2010. Когато клиент на Outlook се свърже с Exchange, на сървър за клиентски достъп на Exchange 2010, услугата RPC Client Access използва порта на TCP End Point Mapper (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 клиентски достъп. Документацията на Microsoft препоръчва да изберете порт в диапазона 59531 - 60554 и да използвате тази стойност на всички CAS сървъри (указахме порт 59532, разбира се, той не трябва да се използва от друг софтуер).

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

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

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

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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeAB\Parameters

Създайте нов параметър RpcTcpPort(от тип REG_SZ) и му дайте номера на порта, който искате да коригирате за услугата Exchange Address Book. Препоръчително е да използвате всеки свободен порт в диапазона 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 има две сървърни роли, които изпълняват функции за транспортиране на съобщения: транспортен сървър на концентратор и сървър на Edge Transport.

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

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

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

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

Целият трафик между транспортните сървъри на концентратора се криптира с помощта на защита на транспортния слой (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 добавя набор от сертификати за транспортен сървър на концентратора към 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 и Mailbox Server са инсталирани на един и същ компютър. Прехвърлянето на локална поща използва удостоверяване на 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, така че не се изисква отдалечена връзка. Ако филтрирането на получателите е инсталирано и конфигурирано на транспортен сървър на хъб, е необходим достъп до услугата на директория Active Directory.
Агентът за анализ на протокола се използва от функцията за репутация на подателя в Exchange 2010. Този агент също се свързва с различни външни прокси сървъри, за да определи пътищата на входящи съобщения за подозрителни връзки.
Всички други функции против нежелана поща използват данни, които се събират, съхраняват и са достъпни само на локалния компютър. Обикновено данни като комбинирания списък на безопасни податели или данни за получатели за филтриране на получатели се изпращат към локалната AD LDS директория чрез използване на услугата Microsoft Exchange EdgeSync.
Агентите за управление на правата на информация (IRM) на сървърите на Hub Transport се свързват със сървърите на Active Directory Rights Management Services (AD RMS) в организацията. Услугата за управление на правата на Active Directory (AD RMS) е уеб услуга, която препоръчваме да бъде защитена със SSL. Връзките към AD RMS сървърите се осъществяват чрез HTTPS и се удостоверяват с помощта на Kerberos или NTLM, в зависимост от конфигурацията на AD RMS сървъра.

Правилата за регистрационни файлове, правилата за транспорт и правилата за класификация на съобщенията се съхраняват в Active Directory и имат достъп от агента за регистриране и транспортния агент на транспортните сървъри на Hub.

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

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

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

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

Ако получателят на слоя на бизнес логиката на Exchange не работи в контекста на локална система, методът за удостоверяване е NTLM. Например, когато администратор стартира командлет на 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 PBX поддържат само удостоверяване на сертификат, което използва взаимно TLS удостоверяване за криптиране на SIP трафик и удостоверяване, базирано на IP адрес за SIP или TCP връзки. IP шлюзовете не поддържат NTLM и Kerberos удостоверяване. Следователно, когато се използва удостоверяване, базирано на IP адрес, механизмът за удостоверяване за некриптирани връзки (TCP) използва IP адресите на връзките. Когато се използва в Unified Messaging, IP-базирано удостоверяване проверява дали даденият IP адрес е разрешен за свързване. IP адресът е конфигуриран на IP шлюза или IP PBX.

IP шлюзовете и IP PBX поддържат взаимен TLS за криптиране на SIP трафик. След успешно импортиране и експортиране на необходимите доверени сертификати, IP шлюзът или IP PBX ще поиска сертификат от сървъра за Unified Messaging и след това ще поиска сертификат от 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 шлюз)	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 (договаряне)	Основен, Дайджест, NTLM, Договаряне (Kerberos)	Да, със SSL
UM сървър към сървър за клиентски достъп (възпроизвеждане на телефон)	Динамичен RPC			Да, използвайки RPC криптиране
От сървър за унифицирани съобщения към сървър за транспортен център				Да, използвайки TLS
От сървър за унифицирани съобщения към сървър на пощенска кутия				Да, използвайки RPC криптиране

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

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

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

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

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

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

Име на правилото	Сървърни роли	Порт	Програма
MSExchangeADTopology - RPC (входящ TCP)		Динамичен RPC	Bin\MSExchangeADTopologyService.exe
MSExchangeMonitoring - RPC (входящ TCP)	Сървър за клиентски достъп, сървър за транспортен център, сървър Edge Transport, сървър за унифицирани съобщения	Динамичен 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-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 входящи)	Сървър на пощенска кутия		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 - Копирна машина (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)	Хъб транспортен сървър, 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 Setup създава правила за защитна стена с посоченото име на процес. В някои случаи, за целите на съвместимостта, се създава и допълнително правило, което не се ограничава до този процес. Можете да деактивирате или премахнете правила, които не са ограничени от процеси и да запазите съответните правила с ограничени процеси, ако текущата ви среда за внедряване ги поддържа. Правилата, които не са ограничени до процеси, могат да бъдат разграничени с думата (GFW)в името на правилото.
Много услуги на Exchange използват отдалечени извиквания на процедури (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 сървъри, между вътрешни 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 Web Services (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)	Конекторът за получаване по подразбиране е „Client Frontend " във външната транспортна услуга прослушва съобщения от удостоверени SMTP клиенти на порт 587. Забележка. Ако имате имейл клиенти, които могат да изпращат само удостоверени SMTP съобщения на порт 25, можете да промените обвързващата стойност на този конектор за получаване, за да слушате и за удостоверени SMTP съобщения на порт 25.

Към началото

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

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

25/TCP (SMTP)

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

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

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

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

25/TCP (SMTP)

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

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

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

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

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)	Интернет (всички)		Конекторът за получаване по подразбиране с име Вътрешен конектор за получаване по подразбиране <имя пограничного транспортного сервера> " на Edge Transport сървъра слуша за анонимна SMTP поща на порт 25.
Входяща поща - от Edge Transport сървъра към вътрешната организация на Exchange	25/TCP (SMTP)	Edge транспортен сървър		Конекторът за изпращане по подразбиране с име „EdgeSync – Входящ към " Препраща входящата поща на порт 25 към всеки сървър на пощенска кутия в абонирания сайт на Active Directory. За повече информация вижте . Конектор за получаване по подразбиране „Fronend по подразбиране " в услугата за външен транспорт на сървъра за пощенска кутия прослушва цялата входяща поща (включително поща от сървърите на Exchange 2016 и Exchange 2013 Edge Transport) на порт 25.
Изходяща поща - от вътрешна организация на Exchange до Edge Transport сървър	25/TCP (SMTP)	Сървъри за пощенски кутии в абониран сайт на Active Directory		Изходящата поща винаги заобикаля услугата за външен транспорт на сървърите на пощенски кутии. Пощата се препраща от транспортната услуга на всеки сървър на пощенска кутия в абониран сайт на Active Directory към Edge Transport сървър чрез използване на неявен и невидим вътрешно-организационен конектор за изпращане, който автоматично насочва пощата между сървърите на Exchange в една и съща организация. Вътрешен конектор за получаване по подразбиране на Edge Transport сървъра слуша SMTP поща на порт 25 от транспортната услуга на всеки сървър на пощенска кутия в абонирания сайт на Active Directory.
Изходяща поща - от Edge Transport сървъра към Интернет	25/TCP (SMTP)	Edge транспортен сървър	Интернет (всички)	Конекторът за изпращане по подразбиране с име "EdgeSync - с <имя сайта Active Directory> към Интернет" препраща изходящата поща на порт 25 от Edge Transport сървъра към Интернет.
EdgeSync синхронизация	50636/TCP (защитен LDAP)	Сървъри за пощенски кутии в абонирания сайт на Active Directory, които участват в синхронизирането на EdgeSync	Edge транспортни сървъри	Ако Edge Transport сървър е абониран за сайт на Active Directory, всички сървъри за пощенски кутии, които в момента съществуват в сайта, участват в синхронизирането на EdgeSync. Но ако добавите още сървъри за пощенски кутии по-късно, те няма да участват автоматично в синхронизирането на EdgeSync.
DNS сървър за разделяне на името на следващия хоп (не е показано)	53/UDP, 53/TCP (DNS)	Edge транспортен сървър	DNS сървър	Вижте разделителна способност на името.
Репутация на подателя Откриване на отворен прокси (не е показано)	виж бележките	Edge транспортен сървър	интернет	По подразбиране агентът за анализ на протокола използва откриване на отворен прокси като едно от условията за изчисляване на нивото на репутация на изходния сървър за съобщения. Вижте статията за повече информация. Следните 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)
Описание: Лек протокол за достъп до директория (LDAP), използван от Active Directory, Active Directory Connector и директорията на Microsoft Exchange Server 5.5.

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

Порт (TCP/UDP): 636 (TCP)
Описание: LDAP през слой за защитени гнезда (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)
Описание: Протокол за достъп до интернет съобщения версия 4, може да се използва от „базирани на стандарти“ клиенти като Microsoft Outlook Express или Netscape Communicator за достъп до сървъра за електронна поща. IMAP4 работи върху административната услуга на Microsoft Internet Information Service (IIS) (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 Admin Service и позволява на клиента достъп до хранилището за информация на Exchange 2000.

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

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

Протокол: NNTP

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

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

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

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

Протокол: HTTP

Порт (TCP/UDP): 80 (TCP)
Описание: Протоколът за трансфер на хипертекст е протоколът, използван предимно от 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. За разлика от 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 Routing Engine (известен също като 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 е портът, който агентът за прехвърляне на съобщения (MTA) на Exchange използва за комуникация с други MTA, съвместими с X.400.

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

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

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

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

XCON: Конфигуриране на MTA TCP/IP порт № за X.400 и RPC Listens

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

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

Протокол: ULS

Порт (TCP/UDP): 522 (TCP)
Описание: Услугата User Locator е вид услуга за интернет директории за конферентни клиенти, като 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, се договаря нов динамичен порт за по-нататъшно поточно предаване на данни.