Exchange Network Port Reference http://unifiedpeople.ru/exch2010help.en/html/fec09455-e99e-42eb-8b3...

Exchange Server 2010

Exchange Network Port Reference

Expand All Language Filter: All

Exchange Server 2010 > Security >

Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

Topic Last Modified: 2012-09-25

This topic provides information about ports, authentication, and encryption for all data paths that are used by Microsoft Exchange Server 2010. The “Notes”
sections that follow each table clarify or define non-standard authentication or encryption methods.

Transport Servers

Exchange 2010 includes two server roles that perform message transport functionality: Hub Transport server and Edge Transport server.

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

Transport server data paths

Data path Required ports Default authentication Supported Encryption Encrypted
authentication supported? by default?
Hub Transport server to Hub 25/TCP (SMTP) Kerberos Kerberos Yes, using Yes
Transport server Transport Layer
Security (TLS)

Hub Transport server to Edge 25/TCP (SMTP) Direct trust Direct trust Yes, using TLS Yes
Transport server

Edge Transport server to Hub 25/TCP (SMTP) Direct trust Direct trust Yes, using TLS Yes
Transport server

Edge Transport server to Edge 25/TCP (SMTP) Anonymous, Certificate Anonymous, Yes, using TLS Yes
Transport server Certificate

Mailbox server to Hub Transport 135/TCP (RPC) NTLM. If the Hub Transport NTLM/Kerberos Yes, using RPC Yes
server via the and the Mailbox server roles encryption
Microsoft Exchange Mail are on the same server,
Submission Service Kerberos is used.

Hub Transport to Mailbox server 135/TCP (RPC) NTLM. If the Hub Transport NTLM/Kerberos Yes, using RPC Yes
via MAPI and the Mailbox server roles encryption
are on the same server,
Kerberos is used.

Unified Messaging server to Hub 25/TCP (SMTP) Kerberos Kerberos Yes, using TLS Yes
Transport server

Microsoft Exchange EdgeSync 50636/TCP (SSL) Basic Basic Yes, using LDAP Yes
service from Hub Transport over SSL
server to Edge Transport server (LDAPS)

Active Directory access from Hub 389/TCP/UDP (LDAP), 3268/ Kerberos Kerberos Yes, using Yes
Transport server TCP (LDAP GC), 88/TCP/ Kerberos
UDP (Kerberos), 53/TCP/UDP (DNS), encryption
135/TCP (RPC netlogon)

Active Directory Rights 443/TCP (HTTPS) NTLM/Kerberos NTLM/Kerberos Yes, using SSL Yes*
Management Services (AD RMS)
access from Hub Transport
server

SMTP clients to Hub Transport 587 (SMTP) NTLM/Kerberos NTLM/Kerberos Yes, using TLS Yes
server (for example, end-users
using Windows Live Mail) 25/TCP (SMTP)

Notes on Transport Servers

All traffic between Hub Transport servers is encrypted by using TLS with self-signed certificates that are installed by Exchange 2010 Setup.

Note:

1 of 7 05-03-2024, 11:21
Exchange Network Port Reference http://unifiedpeople.ru/exch2010help.en/html/fec09455-e99e-42eb-8b3...

In Exchange 2010, TLS can be disabled on Hub Transport servers for internal SMTP communication with other Hub Transport servers in the same
Exchange organization. We don't recommend that you do this unless it is absolutely required. For more information, see Disabling TLS Between
Active Directory Sites to Support WAN Optimization.
All traffic between Edge Transport servers and Hub Transport servers is authenticated and encrypted. Mutual TLS is the underlying mechanism for
authentication and encryption. Instead of using X.509 validation, Exchange 2010 uses direct trust to authenticate the certificates. Direct trust
means that the presence of the certificate in Active Directory or Active Directory Lightweight Directory Services (AD LDS) acts as validation for the
certificate. Active Directory is considered a trusted storage mechanism. When direct trust is used, it doesn't matter whether the certificate is self-
signed or signed by a certification authority (CA). When you subscribe an Edge Transport server to the Exchange organization, the Edge
Subscription publishes the Edge Transport server certificate in Active Directory for the Hub Transport servers to validate. The Microsoft Exchange
EdgeSync service updates AD LDS together with the set of Hub Transport server certificates for the Edge Transport server to validate.

EdgeSync uses a secure LDAP connection from the Hub Transport server to subscribed Edge Transport servers over TCP 50636. AD LDS also
listens on TCP 50389. Connections to this port don't use SSL. You can use LDAP utilities to connect to the port and to check AD LDS data.

By default, traffic between Edge Transport servers in two different organizations is encrypted. Exchange 2010 Setup creates a self-signed
certificate, and TLS is enabled by default. This allows any sending system to encrypt the inbound SMTP session to Exchange. Also by default,
Exchange 2010 tries TLS for all remote connections.

Authentication methods for traffic between Hub Transport servers and Mailbox servers differ when the Hub Transport server roles and Mailbox
server roles are installed on the same computer. When mail submission is local, Kerberos authentication is used. When mail submission is remote,
NTLM authentication is used.

Exchange 2010 also supports Domain Security. Domain Security refers to the functionality in Exchange 2010 and Microsoft Outlook 2010 that
provides a low-cost alternative to S/MIME or other message-level, over-the-Internet security solutions. Domain Security provides you a way to
manage secure message paths between domains over the Internet. After you configure these secure message paths, messages that have
successfully traveled over the secure path from an authenticated sender are displayed to Outlook and Outlook Web Access users as "Domain
Secured." For more information, see Understanding Domain Security.

Many agents can run on Hub Transport servers and Edge Transport servers. Generally, anti-spam agents rely on information that's local to the
computer on which the agents run. Therefore, a minimum of communication with remote computers is required. Recipient filtering is the
exception. Recipient filtering requires calls to either AD LDS or Active Directory. As a best practice, run recipient filtering on the Edge Transport
server. In this case, the AD LDS directory is on the same computer as the Edge Transport server. Therefore, no remote communication is required.
When recipient filtering has been installed and configured on the Hub Transport server, recipient filtering accesses Active Directory.

The Sender Reputation feature in Exchange 2010 uses the Protocol Analysis agent. This agent also makes various connections to outside proxy
servers to determine inbound message paths for suspect connections.

All other anti-spam functionality uses such data as safelist aggregation and recipient data for recipient filtering. This data is gathered, stored, and
accessed only on the local computer. Frequently, the data is pushed to the local AD LDS directory by using the Microsoft Exchange EdgeSync
service.

Information Rights Management (IRM) agents on Hub Transport servers make connections to Active Directory Rights Management Services (AD
RMS) servers in the organization. AD RMS is a Web service that's secured by using SSL as a best practice. Communication with AD RMS servers
occurs by using HTTPS, and Kerberos or NTLM is used for authentication, depending on the AD RMS server configuration.

Journal rules, transport rules, and message classifications are stored in Active Directory and accessed by the Journaling agent and the Transport
Rules agent on Hub Transport servers.

Mailbox Servers

Whether NTLM or Kerberos authentication is used for Mailbox servers depends on the user or process context that the Exchange Business Logic layer consumer is
running under. In this context, the consumer is any application or process that uses the Exchange Business Logic layer. As a result, many entries in the Default
Authentication column of the Mailbox server data paths table are listed as NTLM/Kerberos.

The Exchange Business Logic layer is used to access and communicate with the Exchange store. The Exchange Business Logic layer is also called from the
Exchange store to communicate with external applications and processes.

If the Exchange Business Logic layer consumer is running as Local System, the authentication method is always Kerberos from the consumer to the Exchange
store. Kerberos is used because the consumer must be authenticated by using the Local System computer account, and a two-way authenticated trust must
exist.

If the Exchange Business Logic layer consumer isn't running as Local System, the authentication method is NTLM. For example, NTLM is used when you run an
Exchange Management Shell cmdlet that uses the Exchange Business Logic layer.

The RPC traffic is always encrypted.

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

Mailbox server data paths

Data path Required ports Default Supported Encryption Encrypted by
authentication authentication supported? default?
Active Directory access 389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/ Kerberos Kerberos Yes, using Yes
TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/ Kerberos
TCP (RPC netlogon) encryption

Admin remote access (Remote 135/TCP (RPC) NTLM/Kerberos NTLM/Kerberos Yes, using IPsec No
Registry)

Admin remote access (SMB/ 445/TCP (SMB) NTLM/Kerberos NTLM/Kerberos Yes, using IPsec No
File)

Availability Web service (Client 135/TCP (RPC) NTLM/Kerberos NTLM/Kerberos Yes, using RPC Yes
Access to Mailbox) encryption

Clustering 135/TCP (RPC) See Notes on Mailbox Servers NTLM/Kerberos NTLM/Kerberos Yes, using IPsec No
after this table.

Content indexing 135/TCP (RPC) NTLM/Kerberos NTLM/Kerberos Yes, using RPC Yes
encryption

2 of 7 05-03-2024, 11:21
Exchange Network Port Reference http://unifiedpeople.ru/exch2010help.en/html/fec09455-e99e-42eb-8b3...

Log shipping 64327 (customizable) NTLM/Kerberos NTLM/Kerberos Yes No

Seeding 64327 (customizable) NTLM/Kerberos NTLM/Kerberos Yes No

Volume shadow copy service Local Message Block (SMB) NTLM/Kerberos NTLM/Kerberos No No
(VSS) backup

Mailbox Assistants 135/TCP (RPC) NTLM/Kerberos NTLM/Kerberos No No

MAPI access 135/TCP (RPC) NTLM/Kerberos NTLM/Kerberos Yes, using RPC Yes
encryption

Microsoft Exchange Active 135/TCP (RPC) NTLM/Kerberos NTLM/Kerberos Yes, using RPC Yes
Directory Topology service encryption
access

Microsoft Exchange System 135/TCP (RPC) NTLM/Kerberos NTLM/Kerberos No No

Attendant service legacy access
(Listen to requests)

Microsoft Exchange System 389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/ Kerberos Kerberos Yes, using Yes
Attendant service legacy access TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/ Kerberos
to Active Directory TCP (RPC netlogon) encryption

Microsoft Exchange System 135/TCP (RPC) NTLM/Kerberos NTLM/Kerberos Yes, using RPC Yes
Attendant service legacy access encryption
(As MAPI client)

Offline address book (OAB) 135/TCP (RPC) Kerberos Kerberos Yes, using RPC Yes
accessing Active Directory encryption

Recipient Update Service RPC 135/TCP (RPC) Kerberos Kerberos Yes, using RPC Yes
access encryption

Recipient update to Active 389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/ Kerberos Kerberos Yes, using Yes
Directory TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/ Kerberos
TCP (RPC netlogon) encryption

Notes on Mailbox Servers

The Clustering data path listed in the preceding table uses dynamic RPC over TCP to communicate cluster status and activity between the
different cluster nodes. The Cluster service (ClusSvc.exe) also uses UDP/3343 and randomly allocated, high TCP ports to communicate between
cluster nodes.

For intra-node communications, cluster nodes communicate over User Datagram Protocol (UDP) port 3343. Each node in the cluster periodically
exchanges sequenced, unicast UDP datagrams with every other node in the cluster. The purpose of this exchange is to determine whether all
nodes are running correctly, and also to monitor the health of network links.

Port 64327/TCP is the default port used for log shipping. Administrators can specify a different port for log shipping.

For HTTP authentication in which Negotiate is listed, Kerberos is tried first, and then NTLM.

Client Access Servers

Unless noted, client access technologies, such as Outlook Web App, POP3, or IMAP4 are described by the authentication and encryption from the client
application to the Client Access server.

The following table provides information about ports, authentication, and encryption for data paths between Client Access servers and other servers and clients.

Client Access server data paths

Data path Required ports Default Supported authentication Encryption Encrypted by
authentication supported? default?
Active Directory access 389/TCP/UDP (LDAP), 3268/ Kerberos Kerberos Yes, using Yes
TCP (LDAP GC), 88/TCP/ Kerberos
UDP (Kerberos), 53/TCP/ encryption
UDP (DNS), 135/
TCP (RPC netlogon)

Autodiscover service 80/TCP, 443/TCP (SSL) Basic/Integrated Basic, Digest, NTLM, Yes, using Yes
Windows Negotiate (Kerberos) HTTPS
authentication
(Negotiate)

Availability service 80/TCP, 443/TCP (SSL) NTLM/Kerberos NTLM, Kerberos Yes, using Yes
HTTPS

Mailbox Replication Service (MRS) 808/TCP Kerberos/NTLM Kerberos, NTLM Yes, using RPC Yes
encryption

Outlook accessing OAB 80/TCP, 443/TCP (SSL) NTLM/Kerberos NTLM/Kerberos Yes, using No
HTTPS

Outlook Web App 80/TCP, 443/TCP (SSL) Forms Based Basic, Digest, Forms Yes, using Yes, using a
Authentication Based Authentication, HTTPS self-signed
NTLM (v2 only), certificate
Kerberos, Certificate

POP3 110/TCP (TLS), 995/TCP (SSL) Basic, Kerberos Basic, Kerberos Yes, using SSL, Yes
TLS

3 of 7 05-03-2024, 11:21
Exchange Network Port Reference http://unifiedpeople.ru/exch2010help.en/html/fec09455-e99e-42eb-8b3...

IMAP4 143/TCP (TLS), 993/TCP (SSL) Basic, Kerberos Basic, Kerberos Yes, using SSL, Yes
TLS

Outlook Anywhere (formerly known 80/TCP, 443/TCP (SSL) Basic Basic or NTLM Yes, using Yes
as RPC over HTTP ) HTTPS

Exchange ActiveSync application 80/TCP, 443/TCP (SSL) Basic Basic, Certificate Yes, using Yes
HTTPS

Client Access server to Unified 5060/TCP, 5061/TCP, 5062/TCP, By IP address By IP address Yes, using Yes
Messaging server a dynamic port Session
Initiation
Protocol (SIP)
over TLS

Client Access server to a Mailbox 80/TCP, 443/TCP (SSL) NTLM/Kerberos Negotiate (Kerberos Yes, using IPsec No
server that is running an earlier with fallback to NTLM or
version of Exchange Server optionally Basic,) POP/
IMAP plain text

Client Access server to Exchange RPC. See Notes on Client Access Kerberos NTLM/Kerberos Yes, using RPC Yes
2010 Mailbox server Servers. encryption

Client Access server to Client 80/TCP, 443/TCP (SSL) Kerberos Kerberos, Certificate Yes, using Yes, using a
Access server (Exchange HTTPS self-signed
ActiveSync) certificate

Client Access server to Client 80/TCP, 443/TCP (HTTPS) Kerberos Kerberos Yes, using SSL Yes
Access server (Outlook Web
Access)

Client Access server to Client 443/TCP (HTTPS) Kerberos Kerberos Yes, using SSL Yes
Access server (Exchange Web
Services)

Client Access server to Client 995 (SSL) Basic Basic Yes, using SSL Yes
Access server (POP3)

Client Access server to Client 993 (SSL) Basic Basic Yes, using SSL Yes
Access server (IMAP4)

Office Communications Server 5075-5077/TCP (IN), 5061/TCP mTLS (Required) mTLS (Required) Yes, using SSL Yes
access to Client Access server (OUT)
(when Office Communications
Server and Outlook Web App
integration is enabled)

Note:
Integrated Windows authentication (NTLM) is not supported for POP3 or IMAP4 client connectivity. For more information, see the "Client Access Features"
sections in Discontinued Features.

Notes on Client Access Servers

In Exchange 2010, MAPI clients such as Microsoft Outlook connect to Client Access servers.

The Client Access servers use many ports to communicate with Mailbox servers. With some exceptions, those ports are determined by the RPC
service, and they aren't fixed.

For HTTP authentication where Negotiate is listed, Kerberos is tried first, and then NTLM.

When an Exchange 2010 Client Access server communicates with a Mailbox server that runs Microsoft Exchange Server 2003, it's a best practice
to use Kerberos and disable NTLM authentication and Basic authentication. It's also a best practice to configure Outlook Web App to use forms-
based authentication with a trusted certificate. For Exchange ActiveSync clients to communicate through the Exchange 2010 Client Access server
to the Exchange 2003 back-end server, Windows Integrated Authentication must be enabled on the Microsoft-Server-ActiveSync virtual directory
on the Exchange 2003 back-end server. To use Exchange System Manager on an Exchange 2003 server to manage authentication on an Exchange
2003 virtual directory, download and install the hotfix referenced in Microsoft Knowledge Base article 937031, Event ID 1036 is logged on an
Exchange 2007 server that is running the CAS role when mobile devices connect to the Exchange 2007 server to access mailboxes on an
Exchange 2003 back-end server.

Note:
Although the Knowledge Base article is specific to MicrosoftExchange Server 2007, it's also applicable to Exchange 2010.
When a Client Access server proxies POP3 requests to another Client Access server, the communication occurs over port 995/TCP. This is true
regardless of whether the connecting client uses POP3 and requests TLS (on port 110/TCP) or connects on port 995/TCP using SSL. Similarly, for
IMAP4 connections, the requesting server uses port 993/TCP to proxy requests regardless of whether the connecting client uses IMAP4 and
requests TLS (on port 443/TCP) or connects to port 995 using IMAP4 with SSL encryption

Client Access Server Connectivity

In addition to having a Client Access server in every Active Directory site that contains a Mailbox server, it’s important to avoid restricting traffic between
Exchange servers. Make sure that all defined ports that are used by Exchange are open in both directions between all source and destination servers. The
installation of a firewall between Exchange servers or between an Exchange 2010 Mailbox or Client Access server and Active Directory isn’t supported. However,
you can install a network device if traffic isn’t restricted and all available ports are open between the various Exchange servers and Active Directory.

Unified Messaging Servers

IP gateways and IP PBXs support only certificate-based authentication that uses mutual TLS for encrypting SIP traffic and IP-based authentication for Session
Initiation Protocol (SIP)/TCP connections. IP gateways don't support either NTLM or Kerberos authentication. Therefore, when you use IP-based authentication,
the connecting IP address or addresses are used to provide authentication mechanism for unencrypted (TCP) connections. When IP-based authentication is used
in Unified Messaging (UM), the UM server verifies that the IP address is allowed to connect. The IP address is configured on the IP gateway or IP PBX.

4 of 7 05-03-2024, 11:21
Exchange Network Port Reference http://unifiedpeople.ru/exch2010help.en/html/fec09455-e99e-42eb-8b3...

IP gateways and IP PBXs support mutual TLS for encrypting SIP traffic. After you successfully import and export the required trusted certificates, the IP gateway
or IP PBX will request a certificate from the UM server, and then it will request a certificate from the IP gateway or IP PBX. Exchanging the trusted certificate
between the IP gateway or IP PBX and the UM server enables the IP gateway or IP PBX and UM server to communicate over an encrypted connection by using
mutual TLS.

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

Unified Messaging server data paths

Data path Required ports Default Supported Encryption Encrypted
authentication authentication supported? by default?
Active Directory 389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/ Kerberos Kerberos Yes, using Yes
access UDP (Kerberos), 53/TCP/UDP (DNS), 135/ Kerberos
TCP (RPC netlogon) encryption

Unified Messaging 5060/TCP , 5065/TCP, 5067/TCP (unsecured), 5061/TCP, By IP address By IP address, Yes, using No
Phone interaction (IP 5066/TCP, 5068/TCP (secured), a dynamic port from the MTLS SIP/TLS, SRTP
PBX/VoIP Gateway) range 16000-17000/TCP (control), dynamic UDP ports
from the range 1024-65535/UDP (RTP)

Unified Messaging 80/TCP, 443/TCP (SSL) Integrated Windows Basic, Digest, Yes, using Yes
Web Service authentication NTLM, Negotiate SSL
(Negotiate) (Kerberos)

Unified Messaging 5075, 5076, 5077 (TCP) Integrated Windows Basic, Digest, Yes, using Yes
server to Client authentication NTLM, Negotiate SSL
Access server (Negotiate) (Kerberos)

Unified Messaging Dynamic RPC NTLM/Kerberos NTLM/Kerberos Yes, using Yes

server to Client RPC
Access server (Play encryption
on Phone)

Unified Messaging 25/TCP (TLS) Kerberos Kerberos Yes, using TLS Yes
server to Hub
Transport server

Unified Messaging 135/TCP (RPC) NTLM/Kerberos NTLM/Kerberos Yes, using Yes

server to Mailbox RPC
server encryption

Notes on 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 (Private Branch
eXchange). When you define the IP address on the UM IP gateway object, the IP address is added to a list of valid IP gateways or IP PBXs (also
called SIP peers) that the UM server is allowed to communicate with. When you create the UM IP gateway, you can associate it with a UM dial
plan. Associating the UM IP gateway with a dial plan allows the Unified Messaging servers that are associated with the dial plan to use IP-based
authentication to communicate with the IP gateway. If the UM IP gateway has not been created, or if it is not configured to use the correct IP
address, authentication fails and the UM servers don't accept connections from that IP gateway's IP address. Also, when you implement mutual
TLS and IP gateway or IP PBX and UM servers, the UM IP gateway must be configured to use the FQDN. After you configure the UM IP gateway
with an FQDN, you must also add a host record to the DNS forward lookup zone for the UM IP gateway.

In Exchange 2010, a UM server can either communicate on port 5060/TCP (unsecured) or on port 5061/TCP (secured), and can be configured to
use both.

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

Windows Firewall Rules Created by Exchange 2010 Setup

Windows Firewall with Advanced Security is a stateful, host-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 on each server role. Therefore, you no longer have to use the
Security Configuration Wizard (SCW) to configure these settings. To learn more about Windows Firewall with Advanced Security, see Windows Firewall with
Advanced Security and IPsec.

This table lists the Windows Firewall rules created by Exchange Setup, including the ports opened on each server role. You can view these rules using the
Windows Firewall with Advanced Security MMC snap-in.

Rule name Server roles Port Program

MSExchangeADTopology - RPC (TCP-In) Client Access, Hub Transport, Dynamic RPC Bin\MSExchangeADTopologyService.exe
Mailbox, Unified Messaging

MSExchangeMonitoring - RPC (TCP-In) Client Access, Hub Transport, Dynamic RPC Bin\Microsoft.Exchange.Management.Monitoring.exe
Edge Transport, Unified
Messaging

MSExchangeServiceHost - RPC (TCP-In) All roles Dynamic RPC Bin\Microsoft.Exchange.ServiceHost.exe

MSExchangeServiceHost - RPCEPMap All roles RPC-EPMap Bin\Microsoft.Exchange.Service.Host

(TCP-In)

MSExchangeRPCEPMap (GFW) (TCP-In) All roles RPC-EPMap Any

MSExchangeRPC (GFW) (TCP-In) Client Access, Hub Transport, Dynamic RPC Any
Mailbox, Unified Messaging

MSExchange - IMAP4 (GFW) (TCP-In) Client Access 143, 993 (TCP) All

MSExchangeIMAP4 (TCP-In) Client Access 143, 993 (TCP) ClientAccess\PopImap\Microsoft.Exchange.Imap4Service.exe

MSExchange - POP3 (FGW) (TCP-In) Client Access 110, 995 (TCP) All

5 of 7 05-03-2024, 11:21
Exchange Network Port Reference http://unifiedpeople.ru/exch2010help.en/html/fec09455-e99e-42eb-8b3...

MSExchange - POP3 (TCP-In) Client Access 110, 995 (TCP) ClientAccess\PopImap\Microsoft.Exchange.Pop3Service.exe

MSExchange - OWA (GFW) (TCP-In) Client Access 5075, 5076, 5077 All
(TCP)

MSExchangeOWAAppPool (TCP-In) Client Access 5075, 5076, 5077 Inetsrv\w3wp.exe

(TCP)

MSExchangeAB-RPC (TCP-In) Client Access Dynamic RPC Bin\Microsoft.Exchange.AddressBook.Service.exe

MSExchangeAB-RPCEPMap (TCP-In) Client Access RPC-EPMap Bin\Microsoft.Exchange.AddressBook.Service.exe

MSExchangeAB-RpcHttp (TCP-In) Client Access 6002, 6004 (TCP) Bin\Microsoft.Exchange.AddressBook.Service.exe

RpcHttpLBS (TCP-In) Client Access Dynamic RPC System32\Svchost.exe

MSExchangeRPC - RPC (TCP-In) Client Access, Mailbox Dynamic RPC Bin\Microsoft.Exchange.RpcClientAccess.Service.exe

MSExchangeRPC - PRCEPMap (TCP-In) Client Access, Mailbox RPC-EPMap Bin\Microsoft.Exchange.RpcClientAccess.Service.exe

MSExchangeRPC (TCP-In) Client Access, Mailbox 6001 (TCP) Bin\Microsoft.Exchange.RpcClientAccess.Service.exe

MSExchangeMailboxReplication (GFW) Client Access 808 (TCP) Any

(TCP-In)

MSExchangeMailboxReplication (TCP-In) Client Access 808 (TCP) Bin\MSExchangeMailboxReplication.exe

MSExchangeIS - RPC (TCP-In) Mailbox Dynamic RPC Bin\Store.exe

MSExchangeIS RPCEPMap (TCP-In) Mailbox RPC-EPMap Bin\Store.exe

MSExchangeIS (GFW) (TCP-In) Mailbox 6001, 6002, Any

6003, 6004 (TCP)

MSExchangeIS (TCP-In) Mailbox 6001 (TCP) Bin\Store.exe

MSExchangeMailboxAssistants - RPC Mailbox Dynamic RPC Bin\MSExchangeMailboxAssistants.exe

(TCP-In)

MSExchangeMailboxAssistants - Mailbox RPC-EPMap Bin\MSExchangeMailboxAssistants.exe

RPCEPMap (TCP-In)

MSExchangeMailSubmission - RPC Mailbox Dynamic RPC Bin\MSExchangeMailSubmission.exe

(TCP-In)

MSExchangeMailSubmission - Mailbox RPC-EPMap Bin\MSExchangeMailSubmission.exe

RPCEPMap (TCP-In)

MSExchangeMigration - RPC (TCP-In) Mailbox Dynamic RPC Bin\MSExchangeMigration.exe

MSExchangeMigration - RPCEPMap Mailbox RPC-EPMap Bin\MSExchangeMigration.exe

(TCP-In)

MSExchangerepl - Log Copier (TCP-In) Mailbox 64327 (TCP) Bin\MSExchangeRepl.exe

MSExchangerepl - RPC (TCP-In) Mailbox Dynamic RPC Bin\MSExchangeRepl.exe

MSExchangerepl - RPC-EPMap (TCP-In) Mailbox RPC-EPMap Bin\MSExchangeRepl.exe

MSExchangeSearch - RPC (TCP-In) Mailbox Dynamic RPC Bin\Microsoft.Exchange.Search.ExSearch.exe

MSExchangeThrottling - RPC (TCP-In) Mailbox Dynamic RPC Bin\MSExchangeThrottling.exe

MSExchangeThrottling - RPCEPMap Mailbox RPC-EPMap Bin\MSExchangeThrottling.exe

(TCP-In)

MSFTED - RPC (TCP-In) Mailbox Dynamic RPC Bin\MSFTED.exe

MSFTED - RPCEPMap (TCP-In) Mailbox RPC-EPMap Bin\MSFTED.exe

MSExchangeEdgeSync - RPC (TCP-In) Hub Transport Dynamic RPC Bin\Microsoft.Exchange.EdgeSyncSvc.exe

MSExchangeEdgeSync - RPCEPMap Hub Transport RPC-EPMap Bin\Microsoft.Exchange.EdgeSyncSvc.exe

(TCP-In)

MSExchangeTransportWorker - RPC Hub Transport Dynamic RPC Bin\edgetransport.exe

(TCP-In)

MSExchangeTransportWorker - Hub Transport RPC-EPMap Bin\edgetransport.exe

RPCEPMap (TCP-In)

MSExchangeTransportWorker (GFW) Hub Transport 25, 587 (TCP) Any

(TCP-In)

MSExchangeTransportWorker (TCP-In) Hub Transport 25, 587 (TCP) Bin\edgetransport.exe

MSExchangeTransportLogSearch - RPC Hub Transport, Edge Dynamic RPC Bin\MSExchangeTransportLogSearch.exe

(TCP-In) Transport, Mailbox

MSExchangeTransportLogSearch - Hub Transport, Edge RPC-EPMap Bin\MSExchangeTransportLogSearch.exe

RPCEPMap (TCP-In) Transport, Mailbox

SESWorker (GFW) (TCP-In) Unified Messaging Any Any

SESWorker (TCP-In) Unified Messaging Any UnifiedMessaging\SESWorker.exe

6 of 7 05-03-2024, 11:21
Exchange Network Port Reference http://unifiedpeople.ru/exch2010help.en/html/fec09455-e99e-42eb-8b3...

UMService (GFW) (TCP-In) Unified Messaging 5060, 5061 Any

UMService (TCP-In) Unified Messaging 5060, 5061 Bin\UMService.exe

UMWorkerProcess (GFW) (TCP-In) Unified Messaging 5065, 5066, Any

5067, 5068

UMWorkerProcess (TCP-In) Unified Messaging 5065, 5066, Bin\UMWorkerProcess.exe

5067, 5068

UMWorkerProcess - RPC (TCP-In) Unified Messaging Dynamic RPC Bin\UMWorkerProcess.exe

Notes on Windows Firewall Rules Created by Exchange 2010 Setup

On servers that have Internet Information Services (IIS) installed, Windows opens the HTTP port (port 80, TCP) and HTTPS port (port 443, TCP).
Exchange 2010 Setup doesn't open these ports. Therefore, these ports don't appear in the preceding table.

In Windows Server 2008 and in Windows Server 2008 R2, Windows Firewall with Advanced Security allows you to specify the process or service
for which a port is opened. This is more secure because it restricts usage of the port to the process or service specified in the rule. Exchange
Setup creates firewall rules with the process name specified. In some cases, an additional rule that isn't restricted to the process is also created
for compatibility. You can disable or remove the rules that aren't restricted to the processes, and then keep the corresponding rules restricted to
processes if your deployment supports them. The rules that are not restricted to processes are distinguished by the word (GFW) in the rule
name.

Many Exchange services use remote procedure calls (RPCs) for communication. Server processes that use RPCs contact the RPC Endpoint Mapper
to receive dynamic endpoints and register those endpoints in the Endpoint Mapper database. RPC clients contact 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 it configures the
Windows Firewall for a process that uses RPCs, Exchange 2010 Setup creates two firewall rules for the process. One rule allows communication
with the RPC Endpoint Mapper, and the other rule allows communication with the dynamically assigned endpoint. To learn more about RPCs, see
How RPC Works. For more information about creating Windows Firewall rules for dynamic RPC, see Allowing Inbound Network Traffic that Uses
Dynamic RPC.

Note:
You can't modify the Windows Firewall rules created by Exchange 2010 Setup. You can create custom rules based on them, and then disable or delete them.

For more information, see Microsoft Knowledge Base article 179442, How to configure a firewall for domains and trusts.

© 2010 Microsoft Corporation. All rights reserved.

Перевести на английский

7 of 7 05-03-2024, 11:21