Exchange network ports reference. Connecting email clients to Microsoft Exchange Server Exchange ports

💖 Like it? Share the link with your friends

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

For purposes of configuring firewalls or for troubleshooting communications issues, it may be useful to know what TCP/UDP ports Exchange 2000 Server and Exchange 2000 Conferencing Server are using. This article is also true for Exchange Server 2003 installations.

Protocol: LDAP

  • Port (TCP/UDP): 389 (TCP)
  • Description: Lightweight Directory Access Protocol (LDAP), used by Active Directory, Active Directory Connector, and the Microsoft Exchange Server 5.5 directory.

Protocol: LDAP/SSL

  • Port (TCP/UDP): 636 (TCP)
  • Description: LDAP over Secure Sockets Layer (SSL). When SSL is enabled, LDAP data that is transmitted and received is encrypted.
  • To enable SSL, you must install a Computer certificate on the domain controller or Exchange Server 5.5 computer.

Protocol: LDAP

  • Port (TCP/UDP): 379 (TCP)
  • Description: The Site Replication Service (SRS) uses TCP port 379.

Protocol: LDAP

  • Port (TCP/UDP): 390 (TCP)
  • Description: While not a standard LDAP port, TCP port 390 is the recommended alternate port to configure the Exchange Server 5.5 LDAP protocol when Exchange Server 5.5 is running on a Microsoft Windows 2000 Active Directory domain controller.

Protocol: LDAP

  • Port (TCP/UDP): 3268 (TCP)
  • Description: Global catalog. The Windows 2000 Active Directory global catalog (which is really a domain controller “role”) listens on TCP port 3268. When you are troubleshooting issues that may be related to a global catalog, connect to port 3268 in LDP.

Protocol: LDAP/SSL

  • Port (TCP/UDP): 3269 (TCP)
  • Description: Global catalog over SSL. Applications that connect to TCP port 3269 of a global catalog server can transmit and receive SSL encrypted data. To configure a global catalog to support SSL, you must install a Computer certificate on the global catalog.

Protocol: IMAP4

  • Port (TCP/UDP): 143 (TCP)
  • Description: Internet Message Access Protocol version 4, may be used by “standards-based” clients such as Microsoft Outlook Express or Netscape Communicator to access the e-mail server. IMAP4 runs on top of the Microsoft Internet Information Service (IIS) Admin Service (Inetinfo.exe), and enables client access to the Exchange 2000 information store.

Protocol: IMAP4/SSL

  • Port (TCP/UDP): 993 (TCP)
  • Description: IMAP4 over SSL uses TCP port 993. Before an Exchange 2000 server supports IMAP4 (or any other protocol) over SSL, you must install a Computer certificate on the Exchange 2000 server.

Protocol: POP3

  • Port (TCP/UDP): 110 (TCP)
  • Description: Post Office Protocol version 3, enables “standards-based” clients such as Outlook Express or Netscape Communicator to access the e-mail server. As with IMAP4, POP3 runs on top of the IIS Admin Service, and enables client access to the Exchange 2000 information store.

Protocol: POP3/SSL

  • Port (TCP/UDP): 995 (TCP)
  • Description: POP3 over SSL. To enable POP3 over SSL, you must install a Computer certificate on the Exchange 2000 server.

Protocol: NNTP

  • Port (TCP/UDP): 119 (TCP)
  • Description: Network News Transport Protocol, sometimes called Usenet protocol, enables “standards-based” client access to public folders in the information store. As with IMAP4 and POP3, NNTP is dependent on the IIS Admin Service.

Protocol: NNTP/SSL

Port (TCP/UDP): 563 (TCP)

Description: NNTP over SSL. To enable NNTP over SSL, you must install a Computer certificate on the Exchange 2000 Server.

Protocol: HTTP

  • Port (TCP/UDP): 80 (TCP)
  • Description: Hyper-Text Transfer Protocol is the protocol used primarily by Microsoft Outlook Web Access (OWA), but also enables some administrative actions in Exchange System Manager. HTTP is implemented through the world wide Web Publishing Service (W3Svc), and runs on top of the IIS Admin Service.

Protocol: HTTP/SSL

  • Port (TCP/UDP): 443 (TCP)
  • Description: HTTP over SSL. To enable HTTP over SSL, you must install a Computer certificate on the Exchange 2000 server.

Protocol: SMTP

  • Port (TCP/UDP): 25 (TCP)
  • Description: Simple Mail Transfer Protocol, is the foundation for all e-mail transport in Exchange 2000. The SMTP Service (SMTPSvc) runs on top of the IIS Admin Service. Unlike IMAP4, POP3, NNTP, and HTTP, SMTP in Exchange 2000 does not use a separate port for secure communication (SSL), but rather, employs an “in-band security sub-system” called Transport Layer Security (TLS).

Protocol: SMTP/SSL

  • Port (TCP/UDP): 465 (TCP)
  • Description: SMTP over SSL. TCP port 465 is reserved by common industry practice for secure SMTP communication using the SSL protocol. However, unlike IMAP4, POP3, NNTP, and HTTP, SMTP in Exchange 2000 does not use a separate port for secure communication (SSL), but rather, employs an “in-band security sub-system” called Transport Layer Security (TLS) . To enable TLS to work on Exchange 2000, you must install a Computer certificate on the Exchange 2000 server.

Protocol: SMTP/LSA

  • Port (TCP/UDP): 691 (TCP)
  • Description: The Microsoft Exchange Routing Engine (also known as RESvc) listens for routing link state information on TCP port 691. Exchange 2000 uses routing link state information to route messages and the routing table is constantly updated. The Link State Algorithm (LSA) propagates outing status information between Exchange 2000 servers. This algorithm is based on the Open Shortest Path First (OSPF) protocol from networking technology, and transfers link state information between routing groups by using the X-LSA-2 command verb over SMTP and by using a Transmission Control Protocol (TCP) connection to port 691 in a routing group.

Protocol: RVP

  • Port (TCP/UDP): 80 (TCP)
  • Description: RVP is the foundation for Instant Messaging in Exchange 2000. While RVP communication begins with TCP port 80, the server quickly sets up a new connection to the client on an ephemeral TCP port above 1024. Because this port is not known in advance, issues exist when you enable Instant Messaging through a firewall.

Protocol: IRC/IRCX

  • Port (TCP/UDP): 6667 (TCP)
  • Description: Internet Relay Chat (IRC) is the chat protocol. IRCX is the extended version offered by Microsoft. While TCP port 6667 is the most common port for IRC, TCP port 7000 is also very frequently used.

Protocol: IRC/SSL

  • Port (TCP/UDP): 994 (TCP)
  • Description: IRC (or Chat) over SSL. IRC or IRCX over SSL is not supported in Exchange 2000.

Protocol: X.400

  • Port (TCP/UDP): 102 (TCP)
  • Description: ITU-T Recommendation X.400 is really a series of recommendations for what an electronic message handling system (MHS) should look like. TCP port 102 is defined in IETF RFC-1006, which describes OSI communications over a TCP/IP network. In brief, TCP port 102 is the port that the Exchange message transfer agent (MTA) uses to communicate with other X.400-capable MTAs.

Protocol: MS-RPC

  • Port (TCP/UDP): 135 (TCP)
  • Description: Microsoft Remote Procedure Call is a Microsoft implementation of remote procedure calls (RPCs). TCP port 135 is actually only the RPC Locator Service, which is like the registrar for all RPC-enabled services that run on a particular server. In Exchange 2000, the Routing Group Connector uses RPC instead of SMTP when the target bridgehead server is running Exchange 5.5. Also, some administrative operations require RPC. To configure a firewall to enable RPC traffic, many more ports than just 135 must be enabled.

For additional information, click the article numbers below to view the articles in the Microsoft Knowledge Base:

XADM: Setting TCP/IP Port Numbers for Internet Firewalls

XCON: Configuring MTA TCP/IP Port # for X.400 and RPC Listens

Protocol: T.120

  • Port (TCP/UDP): 1503 (TCP)
  • Description: ITU-T Recommendation T.120 is a series of recommendations that define data conferencing. Data conferencing is implemented on the server side as a Conferencing Technology Provider (CTP) in the Multipoint Control Unit (MCU), which is one component of the Exchange Conferencing Services (ECS). Data conferencing is implemented on the client side as Chat, Application Sharing, Whiteboard, and File Transferring in Microsoft NetMeeting.

Protocol: ULS

  • Port (TCP/UDP): 522 (TCP)
  • Description: User Locator Service is a type of Internet directory service for conferencing clients, such as NetMeeting. Exchange 2000 Server and Exchange 2000 Conferencing Server do not implement a ULS, but rather take advantage of Active Directory for directory services (by TCP port 389).

Protocol: H.323 (Video)

  • Port (TCP/UDP): 1720 (TCP)
  • Description: ITU-T Recommendation H.323 defines multimedia conferencing. TCP port 1720 is the H.323 (video) call setup port. After a client connects, the H.323 server negotiates a new, dynamic UDP port to be used for streaming data.

Protocol: Audio

  • Port (TCP/UDP): 1731 (TCP)
  • Description: Audio conferencing is enabled in much the same way as H.323 video conferencing is enabled in Exchange 2000 Server. After clients connect to TCP port 1731, a new dynamic port is negotiated for further streaming data.

Applicable to: Exchange Server 2010 SP1

Section last modified: 2011-04-22

This section provides information about ports, authentication, and encryption for all data paths used in Microsoft Exchange Server 2010. The "Notes" section after each table clarifies or defines non-standard authentication or encryption methods.

Transport servers

In Exchange 2010, there are two server roles that perform message transport functions: a Hub Transport server and an Edge Transport server.

The following table provides information about ports, authentication, and data path encryption between these transport servers and other Exchange 2010 servers and services.

Data paths for transport servers

Data Path Required ports Encryption support

Between two Hub Transport servers

Yes, with TLS (Transport Layer Security)

From a Hub Transport server to an Edge Transport server

direct trust

direct trust

Yes, using TLS

From an Edge Transport server to a Hub Transport server

direct trust

direct trust

Yes, using TLS

Between two Edge Transport servers

Anonymous, certificate authentication

Anonymously, with a certificate

Yes, using TLS

From a Mailbox server to via the Microsoft Exchange Mail Submission Service

NTLM. If the Hub Transport server role and the Mailbox server role are running on the same server, the Kerberos protocol is used.

Yes, using RPC encryption

From a Hub Transport server to a Mailbox server via MAPI

NTLM. If the Hub Transport server role and the Mailbox server role are installed on the same server, the Kerberos protocol is used.

Yes, using RPC encryption

Yes, using TLS

Microsoft Exchange EdgeSync service from a Hub Transport server to an Edge Transport server

Yes, using LDAP over SSL (LDAPS)

Access Active Directory from a Hub Transport server

Accessing the Active Directory Rights Management Service (AD RMS) from a Hub Transport server

Yes, with SSL

SMTP clients to a Hub Transport server (for example, end users using Windows Mail live)

Yes, using TLS

Notes for Transport Servers

  • All traffic between Hub Transport servers is encrypted using Transport Layer Security (TLS) and the self-signed certificates installed by Exchange 2010 Setup.
  • All traffic between Edge Transport servers and Hub Transport servers is authenticated and encrypted. Mutual TLS is used as the authentication and encryption mechanism. Instead of X.509 validation, Exchange 2010 uses direct trust. Direct trust means that the presence of a certificate in Active Directory Services or Active Directory Lightweight Directory Services (AD LDS) verifies the authenticity of the certificate. The Active Directory directory service is considered a trusted storage mechanism. When direct trust is used, it does not matter if a self-signed certificate or a certificate signed by a CA is used. When you subscribe an Edge Transport server to an Exchange organization, the Edge Subscription publishes the Edge Transport server's certificate to the Active Directory directory service so that Hub Transport servers can verify it. The Microsoft Exchange EdgeSync service adds a set of Hub Transport server certificates to Active Directory Lightweight Directory Services (AD LDS) so that the Edge Transport server can validate them.
  • EdgeSync uses a secure LDAP connection from a Hub Transport server to subscribed Edge Transport servers on TCP port 50636. Active Directory Lightweight Directory Services also listens on TCP port 50389. Connections to this port do not use SSL. You can use LDAP utilities to connect to this port and check AD LDS data.
  • By default, traffic between Edge Transport servers located in two different organizations is encrypted. Exchange 2010 Setup creates a self-signed certificate and enables TLS by default. This allows any sending system to encrypt an incoming SMTP session to Exchange. By default, Exchange 2010 also attempts to use TLS for all remote connections.
  • The authentication methods for traffic between Hub Transport servers and Mailbox servers are different when the Hub Transport and Mailbox server roles are installed on the same computer. Local mail transfer uses Kerberos authentication. Remote mail transfer uses NTLM authentication.
  • Exchange 2010 also supports domain security. Domain Security is a set of Exchange 2010 and Microsoft Outlook 2010 features that provide a low-cost alternative to S/MIME and other Internet messaging security solutions. Domain security provides a way to manage secure communication paths between domains on the Internet. Once these secure paths are configured, messages successfully sent through them from an authenticated sender appear to Outlook and Outlook Web Access users as "domain-level protected" messages. For more information, see Domain security overview.
  • Many agents can run on both Hub Transport servers and Edge Transport servers. Typically, anti-spam agents use information local computer on which they are executed. Thus, interaction with remote computers. The exception is recipient filtering. Recipient filtering requires an AD LDS or Active Directory call. We recommend that you perform recipient filtering on an Edge Transport server. In this case, the AD LDS directory is located on the same computer where the Edge Transport server role is installed, so remote connection not required. If recipient filtering is installed and configured on a Hub Transport server, access to the Active Directory directory service is required.
  • The Protocol Analysis agent is used by the Sender Reputation feature in Exchange 2010. This agent also connects to various external proxy servers to determine inbound message paths for suspicious connections.
  • All other anti-spam features use data that is collected, stored, and available only on the local computer. Typically, data such as the combined safe senders list or recipient data for recipient filtering is pushed to the on-premises AD LDS directory by using the Microsoft Exchange EdgeSync service.
  • Information Rights Management (IRM) agents on Hub Transport servers connect to Active Directory Rights Management Services (AD RMS) servers in the organization. Active Directory Rights Management Service (AD RMS) is a web service that we recommend securing with SSL. Connections to AD RMS servers are made using HTTPS and are authenticated using either Kerberos or NTLM, depending on the configuration of the AD RMS server.
  • Log rules, transport rules, and message classification rules are stored in Active Directory and accessed by the Logging agent and the Transport Rules agent on Hub Transport servers.

    Mailbox servers

    On Mailbox servers, whether NTLM or Kerberos authentication is used depends on the user context or process that the Exchange business logic layer consumer is running under. In this context, consumers are any applications or processes that use the Exchange business logic layer. As a result, in the column Default authentication tables Data paths for Mailbox servers many rows have a value NTLM/Kerberos.

    The Exchange business logic layer is used to access and interact with the Exchange store. The Exchange business logic layer is also called from the Exchange store to interact with external applications and processes.

    If the Exchange business logic layer consumer is running in the context local system, the authentication method for consumer access to the Exchange store is always Kerberos. The Kerberos authentication method is used because the recipient must be authenticated using account computer "Local System" and requires two-way trust with authentication.

    If the Exchange business logic layer recipient is not running in the context of Local System, the authentication method is NTLM. For example, when an administrator runs an Exchange Management Shell cmdlet that uses the Exchange business logic layer, NTLM authentication is used.

    RPC traffic is always encrypted.

    The following table provides information about ports, authentication, and data path encryption for Mailbox servers.

    Data paths for Mailbox servers

    Data Path Required ports Default authentication Supported authentication method Encryption support Data encryption by default

    389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC Net Logon)

    Yes, using Kerberos encryption

    Administrative remote access(remote registry)

    Yes, using IPsec

    Administrative remote access (SMB, files)

    Yes, using IPsec

    Availability Web Service (Client Mailbox Access)

    Yes, using RPC encryption

    Clustering

    Yes, using RPC encryption

    Between Client Access servers (Exchange ActiveSync)

    80/TCP, 443/TCP (SSL)

    Kerberos, certificate authentication

    Yes, using HTTPS

    Yes, using a self-signed certificate

    Between Client Access servers (Outlook Web Access)

    80/TCP, 443/TCP (HTTPS)

    Yes, with SSL

    Client Access Server to Client Access Server (Exchange Web Services)

    Yes, with SSL

    Client Access Server to Client Access Server (POP3)

    Yes, with SSL

    Client Access Server to Client Access Server (IMAP4)

    Yes, with SSL

    Office Communications Server to Client Access server (when Office Communications Server and Outlook Web App integration is enabled)

    5075-5077/TCP (IN), 5061/TCP (OUT)

    mTLS (required)

    mTLS (required)

    Yes, with SSL

    Notes for Client Access servers

    Servers unified system messaging

    IP gateways and IP PBXs only support certificate authentication, which uses Mutual TLS authentication to encrypt SIP traffic and IP address-based authentication for SIP or TCP connections. IP gateways do not support NTLM and Kerberos authentication. Therefore, when using IP address-based authentication, the authentication mechanism for unencrypted connections (TCP) uses the IP addresses of the connections. When used in Unified Messaging, IP-based authentication checks whether the given IP address is allowed to connect. The IP address is configured on the IP gateway or IP PBX.

    IP gateways and IP PBXs support Mutual TLS to encrypt SIP traffic. After successfully importing and exporting the necessary trusted certificates, the IP gateway or IP PBX will request a certificate from the Unified Messaging server and then request a certificate from the IP gateway or IP PBX. The exchange of trusted certificates between the IP gateway or IP PBX and the Unified Messaging server allows both devices to communicate securely using Mutual TLS.

    The following table provides port, authentication, and encryption information for data paths between UM servers and other servers.

    Data paths for Unified Messaging servers

    Data Path Required ports Default authentication Supported authentication method Encryption support Data encryption by default

    Accessing Active Directory

    389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC Net Logon)

    Yes, using Kerberos encryption

    UM Dial-in (IP PBX/VoIP Gateway)

    5060/TCP , 5065/TCP, 5067/TCP (in non-secure mode), 5061/TCP, 5066/TCP, 5068/TCP (in secure mode), dynamic port range 16000-17000/TCP (management), dynamic UDP ports from the range 1024-65535/UDP (RTP)

    By IP address

    By IP address, MTLS

    Yes, using SIP/TLS, SRTP

    UM Web Service

    80/TCP, 443/TCP (SSL)

    Integrated verification Windows Authentication(Negotiate)

    Yes, with SSL

    From a Unified Messaging server to a Client Access server

    5075, 5076, 5077 (TCP)

    Integrated Windows Authentication (Negotiation)

    Basic, Digest, NTLM, Negotiate (Kerberos)

    Yes, with SSL

    UM Server to Client Access Server (Playback on Phone)

    Dynamic RPC

    Yes, using RPC encryption

    From a Unified Messaging server to a Hub Transport server

    Yes, using TLS

    From a Unified Messaging server to a Mailbox server

    Yes, using RPC encryption

    Notes for Unified Messaging Servers

    • When you create a UM IP gateway object in Active Directory, you must define the IP address of the physical IP gateway or IP PBX. When you determine the IP address of the UM IP gateway object, the IP address is added to the list of valid IP gateways or IP PBXs (also known as SIP session participants) that the UM server is allowed to communicate with. After you create a UM IP gateway, you can associate it with a UM dial plan. Mapping a UM IP gateway to a dial plan allows UM servers that are mapped to a dial plan to use IP address-based authentication to communicate with the IP gateway. If the UM IP gateway has not been created or configured to use the correct IP address, authentication will fail and the UM servers will not accept connections from the IP address of that IP gateway. In addition, if you implement Mutual TLS, an IP gateway or IP PBX, and Unified Messaging servers, the UM IP gateway must be configured to use a fully qualified domain name (FQDN). After you configure a UM IP gateway using the FQDN, you must also add a host record for the gateway to the forward DNS lookup zone.
    • In Exchange 2010, the Unified Messaging server can communicate on port 5060/TCP (non-secure) or port 5061/TCP (secure), and can be configured to use both ports.

    For more information, see Understanding UM VoIP Security and Understanding Protocols, Ports, and Services in Unified Messaging .

    rules Windows firewall created by Exchange 2010 Setup

    Windows Firewall with Advanced Security is a stateful computer-based firewall that filters inbound and outbound traffic based on firewall rules. Exchange 2010 Setup creates Windows Firewall rules to open the ports required for server and client communication in each server role. Therefore, you no longer need to use the SCW to configure these settings. For more information about Windows Firewall with Advanced Security, see Windows Firewall with Advanced Security and IPsec.

    The following table lists the Windows Firewall rules that are generated by Exchange Setup, including the ports that are open on each server role. You can view these rules by using the Windows Firewall with Advanced Security MMC snap-in.

    Rule name Server Roles Port Program

    MSExchangeADTopology - RPC (TCP inbound)

    Dynamic RPC

    Bin\MSExchangeADTopologyService.exe

    MSExchangeMonitoring - RPC (TCP inbound)

    Client Access server, Hub Transport server, Edge Transport server, Unified Messaging server

    Dynamic RPC

    Bin\Microsoft.Exchange.Management.Monitoring.exe

    MSExchangeServiceHost - RPC (TCP inbound)

    Dynamic RPC

    Bin\Microsoft.Exchange.ServiceHost.exe

    MSExchangeServiceHost - RPCEPMap (TCP Inbound)

    Bin\Microsoft.Exchange.Service.Host

    MSExchangeRPCEPMap (GFW) (TCP inbound)

    MSExchangeRPC (GFW) (TCP inbound)

    Client Access server, Hub Transport server, Mailbox server, Unified Messaging server

    Dynamic RPC

    MSExchange - IMAP4 (GFW) (TCP inbound)

    Client Access Server

    MSExchangeIMAP4 (TCP inbound)

    Client Access Server

    ClientAccess\PopImap\Microsoft.Exchange.Imap4Service.exe

    MSExchange - POP3 (FGW) (TCP inbound)

    Client Access Server

    MSExchange - POP3 (TCP inbound)

    Client Access Server

    ClientAccess\PopImap\Microsoft.Exchange.Pop3Service.exe

    MSExchange - OWA (GFW) (TCP inbound)

    Client Access Server

    5075, 5076, 5077 (TCP)

    MSExchangeOWAAppPool (TCP-in)

    Client Access Server

    5075, 5076, 5077 (TCP)

    inetsrv\w3wp.exe

    MSExchangeAB RPC (TCP inbound)

    Client Access Server

    Dynamic RPC

    MSExchangeAB-RPCEPMap (TCP-in)

    Client Access Server

    Bin\Microsoft.Exchange.AddressBook.Service.exe

    MSExchangeAB-RpcHttp (TCP-in)

    Client Access Server

    6002, 6004 (TCP)

    Bin\Microsoft.Exchange.AddressBook.Service.exe

    RpcHttpLBS (TCP inbound)

    Client Access Server

    Dynamic RPC

    System32\Svchost.exe

    MSExchangeRPC - RPC (TCP inbound)

    Dynamic RPC

    MSExchangeRPC - PRCEPMap (TCP inbound)

    Client Access Server, Mailbox Server

    Bing\Microsoft.Exchange.RpcClientAccess.Service.exe

    MSExchangeRPC (TCP inbound)

    Client Access Server, Mailbox Server

    Bing\Microsoft.Exchange.RpcClientAccess.Service.exe

    MSExchangeMailboxReplication (GFW) (TCP inbound)

    Client Access Server

    MSExchangeMailboxReplication (TCP inbound)

    Client Access Server

    Bin\MSExchangeMailboxReplication.exe

    MSExchangeIS - RPC (TCP inbound)

    Mailbox server

    Dynamic RPC

    MSExchangeIS RPCEPMap (TCP inbound)

    Mailbox server

    MSExchangeIS (GFW) (TCP inbound)

    Mailbox server

    6001, 6002, 6003, 6004 (TCP)

    MSExchangeIS (TCP inbound)

    Mailbox server

    MSExchangeMailboxAssistants - RPC (TCP inbound)

    Mailbox server

    Dynamic RPC

    MSExchangeMailboxAssistants - RPCEPMap (TCP Inbound)

    Mailbox server

    Bin\MSExchangeMailboxAssistants.exe

    MSExchangeMailSubmission - RPC (TCP inbound)

    Mailbox server

    Dynamic RPC

    MSExchangeMailSubmission - RPCEPMap (TCP Inbound)

    Mailbox server

    Bin\MSExchangeMailSubmission.exe

    MSExchangeMigration - RPC (TCP inbound)

    Mailbox server

    Dynamic RPC

    Bin\MSExchangeMigration.exe

    MSExchangeMigration - RPCEPMap (TCP inbound)

    Mailbox server

    Bin\MSExchangeMigration.exe

    MSExchangerepl - Log Copier (TCP inbound)

    Mailbox server

    Bin\MSExchangeRepl.exe

    MSExchangerepl - RPC (TCP inbound)

    Mailbox server

    Dynamic RPC

    Bin\MSExchangeRepl.exe

    MSExchangerepl - RPC-EPMap (TCP-in)

    Mailbox server

    Bin\MSExchangeRepl.exe

    MSExchangeSearch - RPC (TCP inbound)

    Mailbox server

    Dynamic RPC

    Bin\Microsoft.Exchange.Search.ExSearch.exe

    MSExchangeThrottling - RPC (TCP inbound)

    Mailbox server

    Dynamic RPC

    Bin\MSExchangeThrottling.exe

    MSExchangeThrottling - RPCEPMap (TCP inbound)

    Mailbox server

    Bin\MSExchangeThrottling.exe

    MSFTED - RPC (TCP inbound)

    Mailbox server

    Dynamic RPC

    MSFTED - RPCEPMap (TCP-in)

    Mailbox server

    MSExchangeEdgeSync - RPC (TCP inbound)

    Hub Transport Server

    Dynamic RPC

    MSExchangeEdgeSync RPCEPMap (TCP inbound)

    Hub Transport Server

    Bin\Microsoft.Exchange.EdgeSyncSvc.exe

    MSExchangeTransportWorker - RPC (TCP inbound)

    Hub Transport Server

    Dynamic RPC

    Bin\edgetransport.exe

    MSExchangeTransportWorker - RPCEPMap (TCP inbound)

    Hub Transport Server

    Bin\edgetransport.exe

    MSExchangeTransportWorker (GFW) (TCP inbound)

    Hub Transport Server

    MSExchangeTransportWorker (TCP inbound)

    Hub Transport Server

    Bin\edgetransport.exe

    MSExchangeTransportLogSearch - RPC (TCP inbound)

    Dynamic RPC

    MSExchangeTransportLogSearch - RPCEPMap (TCP inbound)

    Hub Transport server, Edge Transport server, Mailbox server

    Bin\MSExchangeTransportLogSearch.exe

    SESWorker (GFW) (TCP-in)

    Unified Messaging Server

    SESWorker (TCP inbound)

    Unified Messaging Server

    UnifiedMessaging\SESWorker.exe

    UMService (GFW) (TCP inbound)

    Unified Messaging Server

    UMService (TCP inbound)

    Unified Messaging Server

    Bin\UMService.exe

    UMWorkerProcess (GFW) (TCP inbound)

    Unified Messaging Server

    5065, 5066, 5067, 5068

    UMWorkerProcess (TCP inbound)

    Unified Messaging Server

    5065, 5066, 5067, 5068

    Bin\UMWorkerProcess.exe

    UMWorkerProcess - RPC (TCP inbound)

    Unified Messaging Server

    Dynamic RPC

    Bin\UMWorkerProcess.exe

    Notes on Windows Firewall Rules Created by Exchange 2010 Setup

    • On servers with IIS installed, Windows opens HTTP (port 80, TCP) and HTTPS (port 443, TCP) ports. Exchange 2010 Setup does not open these ports. Therefore, these ports are not listed in the previous table.
    • AT Windows Server In Windows 2008 and Windows Server 2008 R2, Windows Firewall with Advanced Security allows you to specify the process or service for which a port is open. This is more secure because the port can only be used by the process or service specified in the rule. Exchange Setup creates firewall rules with the specified process name. In some cases, for compatibility purposes, an additional rule is also created that is not limited to this process. You can disable or remove non-process-restricted rules and keep the corresponding process-restricted rules if your current deployment environment supports them. Rules not restricted to processes can be distinguished by the word (GFW) in the name of the rule.
    • Many Exchange services use remote procedure calls (RPC) to communicate. Server processes that use remote procedure calls connect to the RPC endpoint mapper to obtain dynamic endpoints and register them in the endpoint mapper database. RPC clients interact with the RPC Endpoint Mapper to determine the endpoints used by the server process. By default, the RPC Endpoint Mapper listens on port 135 (TCP). When you configure Windows Firewall for a process that uses remote procedure calls, Exchange 2010 Setup creates two firewall rules for that process. One rule allows communication with the RPC endpoint mapper, and the second rule allows communication with a dynamically assigned endpoint. For more information about remote procedure calls, see the article. Learn more about creating Windows Firewall rules for dynamic remote call procedures, see the article.

      For more information, see Microsoft Knowledge Base Article 179442

Recently I had to saw the Microsoft Exchange server, and then prescribe rules on the firewall for its ports. So before that, I had to figure out for a long time what ports Microsoft Exchange uses to work. I managed to learn something on the forums, but I had to check and find out something myself, so if I missed some used port of the exchange, write in the comments.

SMTP TCP: 25
The SMTP service uses TCP port 25.

DNS TCP/UDP: 53
DNS listens on port 53. Domain controllers use this port.

HTTP TCP: 80
HTTP Server Port.

POP3 TCP: 110
Post Office Protocol version 3 (POP3).

NNTP TCP: 119
Network News Transfer Protocol (NNTP).

MSRPC TCP/UDP: 135
Microsoft RPC and Locator service - LOC-SRV

IMAP4 TCP: 143
Internet Message Access Protocol (IMAP).

LDAP TCP/UDP: 379
The Site Replication Service (SRS).

LDAP TCP/UPD: 389
Lightweight directory access protocol (LDAP) used by Microsoft Active Directory® directory service, Active Directory Connector, and the Microsoft Exchange Server 5.5 directory.

LDAP TCP/UDP: 390
This is the recommended alternate port to configure the Exchange Server 5.5 LDAP protocol when Exchange Server 5.5 is running on an Active Directory domain controller.

HTTP/SSL TCP: 443
HTTP over SSL.

SMTP/SSL:465
SMTP over SSL. TCP port 465 is reserved by common industry practice for secure SMTP communication using the SSL protocol.

NNTP/SSL TCP: 563
NNTP over SSL.

LDAP/SSL TCP/UDP: 636
LDAP over Secure Sockets Layer (SSL).

LSA TCP: 691
The Microsoft Exchange Routing Engine service (RESvc) listens for routing link state information on this port.

IMAP4/SSL TCP: 993
IMAP4 over SSL.

POP3/SSL TCP: 995
POP3 over SSL.

LDAP TCP: 3268
global catalog. The Windows 2000 and Windows Server 2003 Active Directory global catalog (a domain controller "role") listens on TCP port 3268.

LDAP/SSLPort TCP: 3269
Global catalog over SSL. Applications that connect to TCP port 3269 of a global catalog server can transmit and receive SSL encrypted data.

If you're trying to add your Outlook.com account to another email application, you may need POP, IMAP, or SMTP settings for Outlook.com. You can find them below or follow the link POP and IMAP setup on Outlook.com.

If you want to add your Outlook.com account to a smart device, such as a home security camera, you'll need an app password. For more information, see Add your Outlook.com account to another email app or smart device.

POP, IMAP, and SMTP settings for Outlook.com

If you want to add an Outlook.com account to another mail program that supports POP or IMAP, use the following server settings.

Notes:

    IMAP server name Outlook.Office365.com

    IMAP Port: 993

    IMAP encryption method TLS

    Outlook.office365.com POP server name

    POP port: 995

    POP Encryption Method TLS

    SMTP server name smtp.office365.com

    SMTP port: 587

    SMTP encryption method STARTTLS

Turn on POP access in Outlook.com

If you want to access mail in Outlook.com using the POP protocol, you'll need to turn it on.

Change your mail provider settings

If you are trying to connect another account to Outlook.com using the POP protocol, you may need to change some of your email provider's settings in order to make a connection that may have been blocked.

    For Gmail accounts with POP access, .

    For Yahoo accounts with POP access, follow the steps below.

    If you are using other email providers, you should contact them for instructions on how to unblock the connection.

Outlook.com IMAP connection errors

If you've set up your Outlook.com account as IMAP in multiple email clients, you might be getting a connection error message. We're working on a fix and will update this article if we have more information. For now, try the following solution:

If you use Outlook.com to access an account that uses a domain other than @live. com, @hotmail. com or @outlook. com, you won't be able to sync accounts using IMAP. To resolve this issue, remove the connected IMAP account in Outlook.com and reconfigure it as a POP connection. For instructions on how to reconfigure your account to use POP, contact your email account provider.

If you're using a GoDaddy account, follow these instructions to change your GoDaddy account settings to use a POP connection. If using the POP protocol did not solve the problem, or you need to enable the IMAP protocol (disabled by default), you should contact the service

Exchange Server and Firewalls

Firewalls (firewalls) for mail servers (Exchange Server), mail server ports, front-end and back-end mail servers, virtual servers SMTP, POP3, IMAP4

Like any computer connected to the Internet, the computer that hosts the mail server must be protected with a firewall. However, installation options mail server in terms of network configuration can be very different:

· The simplest option is to install a mail server on a computer that is also a proxy/firewall, and then open the necessary ports on the interface facing the Internet. Typically, this scheme is used in small organizations;

Another option is to install the mail server in local network and configure it to work through a proxy server. To do this, you can bind public ip to the mail server and pass it through a proxy or use port mapping tools on the proxy server. Many proxy servers have special wizards or predefined rules for organizing such a solution (for example, in ISA Server). This option is used in most organizations.

· Another fundamental possibility is to create a DMZ and place in it front-end Exchange Server (such a possibility has appeared since version 2000) or SMTP Relay based on another Exchange Server or, for example, sendmail on *nix. Usually used in networks of large organizations.

In any case, the mail server must ensure communication on at least TCP port 25 (SMTP) and UDP port 53 (DNS). Other ports that may be required by Exchange Server depending on your network configuration (all TCP):

80 HTTP - to access the Web interface (OWA)

· 88 Kerberos authentication protocol - if Kerberos authentication is used (rare);

· 102 MTA .X .400 connector over TCP /IP (if X .400 connector is used for communication between routing groups);

· 110 Post Office Protocol 3 (POP 3) - for client access;

· 119 Network News Transfer Protocol (NNTP) - if newsgroups are used;

135 Client /server communication RPC Exchange administration - standard RPC port for remote administration Exchange using standard System Manager tools;

· 143 Internet Message Access Protocol (IMAP) - for customer access;

· 389 LDAP - to access the directory service;

· 443 HTTP (Secure Sockets Layer (SSL)) (and below) - the same protocols protected by SSL.

563 NNTP (SSL)

636 LDAP (SSL)

993 IMAP4 (SSL)

995 POP3 (SSL)

· 3268 and 3269 - requests to the global catalog server (search in Active Directory and checking membership in universal groups).

It makes no sense to close the Exchange Server interface facing inside the organization with a firewall - it will be used to interact with domain controllers, administration utilities, systems Reserve copy etc. For an interface exposed to the Internet, it is recommended to leave ports 53 (if Exchange will resolve hostnames itself, and not forward requests to the local DNS server) and 25. Very often, clients need to contact their mailboxes from the outside (from home, during a business trip, etc.). The best solution in this situation, configure OWA (the web interface for accessing the Exchange Server, which is installed by default, is available at http://server_name/exchange) to work over SSL and open access only on port 443. In addition to solving issues with secure authentication and message encryption automatically solves the issue with SMTP Relay (more on that later) and the situation when a user accidentally downloads a working email to mail client folders on home computer, and then at work he cannot find these messages (not to mention the fact that storing work mail at home is a security breach).

New Opportunity, which was introduced in Exchange Server . since version 2000, the ability to use multiple virtual SMTP and POP3 servers with different security settings. For example, the SMTP server that communicates with the Internet can be configured for enhanced security and strict delivery restrictions, while the SMTP server that users within the organization use can be configured for maximum performance and user-friendliness.

It is also necessary to mention a certain confusion in terminology - very often firewalls for Exchange are called message filtering systems, which will be discussed below.

tell friends