Exchange 2010 Network Port Reference

Transport Servers

Exchange Network Port Reference

Applies to: Exchange Server 2010 SP2

Topic Last Modified: 2011-04-28

This topic provides information about ports, authentication, and encryption for all data paths used by

Microsoft Exchange Server 2010. The Notes sections following each table clarify or define non-standard authentication or encryption methods.

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

authentication

Encryption

supported?

Encrypted by

default?

Hub Transport

server to Hub Transport server

25/TCP (SMTP) Kerberos Kerberos

Yes, using

Transport

Layer Security

(TLS)

Yes

Hub Transport

server to Edge Transport server

25/TCP (SMTP) Direct trust Direct trustYes, using

TLSYes

Edge Transport

server to Hub

Transport server

25/TCP (SMTP) Direct trust Direct trustYes, using

TLSYes

Edge Transport server to Edge

Transport server

25/TCP SMTPAnonymous, Certificate

Anonymous, Certificate

Yes, using TLS

Yes

Mailbox server to

Hub Transport server via the

Microsoft Exchange

Mail Submission Service

135/TCP (RPC)

NTLM. If the

Hub Transport

and the Mailbox server roles are

on the same

server, Kerberos is

used.

NTLM/Kerberos

Yes, using

RPC

encryption

Yes

Page 1 of 17Exchange Network Port Reference: Exchange 2010 Help

1/5/2012http://technet.microsoft.com/en-us/library/bb331973(d=printer).aspx

Notes on Transport Servers

Note:

Hub Transport to

Mailbox server via MAPI

135/TCP (RPC)

NTLM. If the

Hub Transport and the Mailbox

server roles are

on the same server,

Kerberos is

used.

NTLM/Kerberos

Yes, using

RPC encryption

Yes

Unified Messaging server to Hub

Transport server

25/TCP (SMTP) Kerberos KerberosYes, using TLS

Yes

Microsoft Exchange

EdgeSync service

from Hub Transport server to

Edge Transport

server

50636/TCP (SSL) Basic Basic

Yes, using

LDAP over SSL

(LDAPS)

Yes

Active Directory

access from Hub

Transport server

389/TCP/UDP (LDAP), 3268/TCP (LDAP GC),

88/TCP/UDP (Kerberos),

53/TCP/UDP (DNS), 135/TCP (RPC netlogon)

Kerberos Kerberos

Yes, using

Kerberos

encryption

Yes

Active Directory

Rights

Management

Services (AD RMS) access from Hub

Transport server

443/TCP (HTTPS) NTLM/Kerberos NTLM/KerberosYes, using

SSLYes*

SMTP clients to

Hub Transport server (for

example, end-

users using

Windows Live Mail)

587 (SMTP)

25/TCP (SMTP)NTLM/Kerberos NTLM/Kerberos

Yes, using

TLSYes

All traffic between Hub Transport servers is encrypted by using TLS with self-signed

certificates that are installed by Exchange 2010 Setup.

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 doing this unless absolutely required. For more information, see

Disabling TLS Between Active Directory Sites to Support WAN Optimization1.



Mailbox Servers

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 if 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 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 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. By default, Exchange 2010 also 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 with

a way to manage secure message paths between domains over the Internet. After these

secure message paths are configured, 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 Security2.

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, little 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 and no remote communication is required. When recipient filtering has been installed and configured on the

Hub Transport server, recipient filtering accesses Active Directory.

The Protocol Analysis agent is used by the Sender Reputation feature in Exchange 2010. This agent also makes various connections to outside proxy servers to determine inbound message

paths for suspect connections.

All other anti-spam functionality uses data gathered, stored, and accessed only on the local computer. Frequently, the data, such as safelist aggregation or recipient data for recipient

filtering, 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.

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


authentication

Supported

authentication

Encryption

supported?

Encrypted

by

default?

Active Directory

access

389/TCP/UDP (LDAP),

3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos),

53/TCP/UDP (DNS),

135/TCP (RPC netlogon)

Kerberos KerberosYes, using Kerberos

encryption

Yes

Admin remote

access

(Remote Registry)

135/TCP (RPC) NTLM/Kerberos NTLM/KerberosYes, using

IPsecNo

Admin

remote

access

(SMB/File)

445/TCP (SMB) NTLM/Kerberos NTLM/KerberosYes, using

IPsecNo

Availability Web service

(Client

Access to Mailbox)

135/TCP (RPC) NTLM/Kerberos NTLM/Kerberos

Yes, using

RPC

encryption

Yes

Clustering

135/TCP (RPC) See Notes

on Mailbox Servers after

this table.

NTLM/Kerberos NTLM/KerberosYes, using

IPsecNo



Content indexing


Yes, using

RPC encryption

Yes

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

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

Volume

shadow copy

service (VSS) backup

Local Message Block (SMB) NTLM/Kerberos NTLM/Kerberos No No

Mailbox

Assistants135/TCP (RPC) NTLM/Kerberos NTLM/Kerberos No No

MAPI access 135/TCP (RPC) NTLM/Kerberos NTLM/Kerberos

Yes, using

RPC encryption

Yes

Microsoft

Exchange

Active Directory

Topology

service

access

135/TCP (RPC) NTLM/Kerberos NTLM/KerberosYes, using RPC

encryption

Yes

Microsoft Exchange

System

Attendant service

legacy access

(Listen to

requests)

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

Microsoft Exchange

System

Attendant service

legacy access

to Active Directory

389/TCP/UDP (LDAP),


53/TCP/UDP (DNS),



encryption

Yes

Microsoft

Exchange

System

Attendant service


Yes, using

RPC

encryption

Yes



Notes on Mailbox Servers

Client Access Servers

legacy access

(As MAPI

client)

Offline address book

(OAB)

accessing Active

Directory

135/TCP (RPC) Kerberos Kerberos

Yes, using

RPC

encryption

Yes

Recipient

Update

Service RPC access

135/TCP (RPC) Kerberos Kerberos

Yes, using

RPC encryption

Yes

Recipient

update to Active

Directory

389/TCP/UDP (LDAP),

3268/TCP (LDAP GC),

88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS),


Kerberos Kerberos

Yes, using

Kerberos encryption

Yes

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 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 where Negotiate is listed, Kerberos is tried first, and then NTLM.

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 port, authentication, and encryption for data paths between Client Access servers and other servers and clients.

Client Access server data paths


authentication Supported

authentication Encryption supported?

Encrypted by

default?

Active Directory

access

389/TCP/UDP (LDAP),

3268/TCP (LDAP GC),

88/TCP/UDP (Kerberos),

Kerberos Kerberos

Yes, using

Kerberos

encryption

Yes



53/TCP/UDP (DNS),


Autodiscover service

80/TCP, 443/TCP (SSL)

Basic/Integrated

Windows authentication

(Negotiate)

Basic, Digest,

NTLM, Negotiate

(Kerberos)

Yes, using HTTPS

Yes

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

HTTPSYes

Outlook accessing OAB

80/TCP, 443/TCP (SSL) NTLM/Kerberos NTLM/KerberosYes, using HTTPS

No

Outlook Web App 80/TCP, 443/TCP (SSL)Forms Based Authentication

Basic, Digest,

Forms Based

Authentication, NTLM (v2 only),

Kerberos,

Certificate

Yes, using HTTPS

Yes, using

a self-signed

certificate

POP3110/TCP (TLS),

995/TCP (SSL)Basic, Kerberos Basic, Kerberos

Yes, using

SSL, TLSYes

IMAP4143/TCP (TLS), 993/TCP (SSL)

Basic, Kerberos Basic, KerberosYes, using SSL, TLS

Yes

Outlook Anywhere

(formerly known

as RPC over HTTP )

80/TCP, 443/TCP (SSL) Basic Basic or NTLMYes, using

HTTPSYes

Exchange

ActiveSync

application

80/TCP, 443/TCP (SSL) BasicBasic,

Certificate

Yes, using

HTTPSYes

Client Access

server to Unified

Messaging server

5060/TCP, 5061/TCP,

5062/TCP, a dynamic

port

By IP address By IP address

Yes, using Session

Initiation

Protocol

(SIP) over TLS

Yes

Client Access

server to a

Mailbox server that is running an

earlier version of

Exchange Server

80/TCP, 443/TCP (SSL) NTLM/Kerberos

Negotiate

(Kerberos with fallback to

NTLM or

optionally

Basic,)

Yes, using IPsec

No



Note:

POP/IMAP plain

text

Client Access

server to Exchange 2010

Mailbox server

RPC. See Notes on Client Access Servers.

Kerberos NTLM/KerberosYes, using RPC

encryption

Yes

Client Access

server to Client Access server

(Exchange

ActiveSync)

80/TCP, 443/TCP (SSL) KerberosKerberos, Certificate

Yes, using HTTPS

Yes, using

a self-signed

certificate

Client Access server to Client

Access server

(Outlook Web

Access)

80/TCP,

443/TCP (HTTPS)Kerberos Kerberos

Yes, using

SSLYes


Access server

(Exchange Web Services)

443/TCP (HTTPS) Kerberos KerberosYes, using

SSLYes

Client Access

server to Client

Access server

(POP3)

995 (SSL) Basic BasicYes, using

SSLYes


Access server

(IMAP4)

993 (SSL) Basic BasicYes, using

SSLYes

Office Communications

Server access 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, using

SSLYes

Integrated Windows authentication (NTLM) isn't supported for POP3 or IMAP4 client connectivity.

For more information, see the "Client Access Features" sections in Discontinued Features3.



Notes on Client Access Servers

Note:

Unified Messaging 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 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 running

Exchange Server 2003, it's a best practice to use Kerberos and disable NTLM authentication and Basic authentication. Additionally, it's 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 hot fix 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 server4.

Although the Knowledge Base article is specific to Exchange 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, 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, port 993/TCP is used to proxy requests regardless of whether the

connecting client uses IMAP4 and requests TLS (on port 443/TCP) or connects on port 995 using IMAP4 with SSL encryption

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.

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


authentication

Supported

authentication

Encryption

supported?

Encrypted

by

default?



Notes on Unified Messaging Servers

Active Directory

access

389/TCP/UDP (LDAP),


53/TCP/UDP (DNS),



encryption

Yes

Unified

Messaging

Phone interaction

(IP

PBX/VoIP

Gateway)

5060/TCP , 5065/TCP, 5067/TCP (unsecured),

5061/TCP, 5066/TCP,

5068/TCP (secured), a dynamic port from the range

16000-17000/TCP (control),

dynamic UDP ports from the

range 1024-65535/UDP (RTP)

By IP addressBy IP address, MTLS

Yes, using SIP/TLS,

SRTP

No

Unified

Messaging

Web Service

80/TCP, 443/TCP (SSL)

Integrated

Windows

authentication (Negotiate)

Basic, Digest,

NTLM, Negotiate

(Kerberos)

Yes, using

SSLYes

Unified

Messaging

server to Client

Access

server

5075, 5076, 5077 (TCP)

Integrated

Windows authentication

(Negotiate)

Basic, Digest,

NTLM, Negotiate (Kerberos)

Yes, using SSL

Yes

Unified

Messaging server to

Client

Access server (Play

on Phone)

Dynamic RPC NTLM/Kerberos NTLM/Kerberos

Yes, using

RPC

encryption

Yes

Unified

Messaging

server to Hub

Transport

server

25/TCP (TLS) Kerberos KerberosYes, using TLS

Yes

Unified Messaging

server to

Mailbox server


Yes, using

RPC

encryption

Yes



Windows Firewall Rules Created by Exchange 2010 Setup

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 it isn't 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 Security5 and Understanding

Protocols, Ports, and Services in Unified Messaging6.

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

need 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 IPsec7.

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, Mailbox,

Unified

Messaging

Dynamic

RPCBin\MSExchangeADTopologyService.exe

MSExchangeMonitoring - RPC

(TCP-In)

Client

Access, Hub

Transport,

Edge Transport,

Unified

Messaging

Dynamic

RPCBin\Microsoft.Exchange.Management.Monitoring.exe

MSExchangeServiceHost - RPC (TCP-In)

All rolesDynamic RPC

Bin\Microsoft.Exchange.ServiceHost.exe



MSExchangeServiceHost -

RPCEPMap (TCP-In)All roles

RPC-

EPMapBin\Microsoft.Exchange.Service.Host

MSExchangeRPCEPMap (GFW) (TCP-In)

All rolesRPC-EPMap

Any

MSExchangeRPC (GFW) (TCP-

In)

Client

Access,

Hub Transport,

Mailbox,

Unified Messaging

Dynamic

RPCAny

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

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

(TCP)

All

MSExchangeOWAAppPool (TCP-

In)

Client

Access

5075,

5076,

5077 (TCP)

Inetsrv\w3wp.exe

MSExchangeAB-RPC (TCP-In)Client

Access

Dynamic

RPCBin\Microsoft.Exchange.AddressBook.Service.exe

MSExchangeAB-RPCEPMap (TCP

-In)

Client

Access

RPC-

EPMapBin\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

RPCSystem32\Svchost.exe

MSExchangeRPC - RPC (TCP-In)

Client

Access, Mailbox

Dynamic RPC

Bing\Microsoft.Exchange.RpcClientAccess.Service.exe

MSExchangeRPC - PRCEPMap

(TCP-In)

Client

Access,

Mailbox

RPC-

EPMapBing\Microsoft.Exchange.RpcClientAccess.Service.exe

MSExchangeRPC (TCP-In)Client Access,

Mailbox

6001 (TCP)

Bing\Microsoft.Exchange.RpcClientAccess.Service.exe

MSExchangeMailboxReplication

(GFW) (TCP-In)

Client

Access

808

(TCP)Any

MSExchangeMailboxReplication (TCP-In)

Client Access

808 (TCP)

Bin\MSExchangeMailboxReplication.exe

MSExchangeIS - RPC (TCP-In) MailboxDynamic

RPCBin\Store.exe

MSExchangeIS RPCEPMap (TCP-

In)Mailbox

RPC-

EPMapBin\Store.exe

MSExchangeIS (GFW) (TCP-In) Mailbox

6001,

6002, 6003,

6004

(TCP)

Any

MSExchangeIS (TCP-In) Mailbox6001 (TCP)

Bin\Store.exe

MSExchangeMailboxAssistants -

RPC (TCP-In)Mailbox

Dynamic

RPCBin\MSExchangeMailboxAssistants.exe

MSExchangeMailboxAssistants -

RPCEPMap (TCP-In)Mailbox

RPC-

EPMapBin\MSExchangeMailboxAssistants.exe



MSExchangeMailSubmission -

RPC (TCP-In)Mailbox

Dynamic

RPCBin\MSExchangeMailSubmission.exe

MSExchangeMailSubmission - RPCEPMap (TCP-In)

MailboxRPC-EPMap

Bin\MSExchangeMailSubmission.exe

MSExchangeMigration - RPC

(TCP-In)Mailbox

Dynamic

RPCBin\MSExchangeMigration.exe

MSExchangeMigration -


RPC-

EPMapBin\MSExchangeMigration.exe

MSExchangerepl - Log Copier (TCP-In)

Mailbox64327 (TCP)

Bin\MSExchangeRepl.exe

MSExchangerepl - RPC (TCP-In) MailboxDynamic

RPCBin\MSExchangeRepl.exe

MSExchangerepl - RPC-EPMap

(TCP-In)Mailbox

RPC-

EPMapBin\MSExchangeRepl.exe

MSExchangeSearch - RPC (TCP-In)

MailboxDynamic RPC

Bin\Microsoft.Exchange.Search.ExSearch.exe

MSExchangeThrottling - RPC

(TCP-In)Mailbox

Dynamic

RPCBin\MSExchangeThrottling.exe

MSExchangeThrottling -


RPC-

EPMapBin\MSExchangeThrottling.exe

MSFTED - RPC (TCP-In) MailboxDynamic RPC

Bin\MSFTED.exe

MSFTED - RPCEPMap (TCP-In) MailboxRPC-

EPMapBin\MSFTED.exe

MSExchangeEdgeSync - RPC

(TCP-In)

Hub

Transport

Dynamic

RPCBin\Microsoft.Exchange.EdgeSyncSvc.exe

MSExchangeEdgeSync - RPCEPMap (TCP-In)

Hub Transport

RPC-EPMap

Bin\Microsoft.Exchange.EdgeSyncSvc.exe

MSExchangeTransportWorker -

RPC (TCP-In)

Hub

Transport

Dynamic

RPCBin\edgetransport.exe



Notes on Windows Firewall Rules Created by Exchange 2010 Setup

MSExchangeTransportWorker -

RPCEPMap (TCP-In)

Hub

Transport

RPC-

EPMapBin\edgetransport.exe

MSExchangeTransportWorker (GFW) (TCP-In)

Hub Transport

25, 587 (TCP)

Any

MSExchangeTransportWorker

(TCP-In)

Hub

Transport

25, 587

(TCP)Bin\edgetransport.exe

MSExchangeTransportLogSearch

- RPC (TCP-In)

Hub

Transport, Edge

Transport,

Mailbox

Dynamic

RPCBin\MSExchangeTransportLogSearch.exe

MSExchangeTransportLogSearch

- RPCEPMap (TCP-In)

Hub Transport,

Edge

Transport,

Mailbox

RPC-

EPMapBin\MSExchangeTransportLogSearch.exe

SESWorker (GFW) (TCP-In)Unified

MessagingAny Any

SESWorker (TCP-In)Unified

MessagingAny UnifiedMessaging\SESWorker.exe

UMService (GFW) (TCP-In)Unified

Messaging

5060,

5061Any

UMService (TCP-In)Unified Messaging

5060, 5061

Bin\UMService.exe

UMWorkerProcess (GFW) (TCP-

In)

Unified

Messaging

5065,

5066,

5067, 5068

Any

UMWorkerProcess (TCP-In)Unified

Messaging

5065,

5066,

5067, 5068

Bin\UMWorkerProcess.exe

UMWorkerProcess - RPC (TCP-

In)

Unified

Messaging

Dynamic

RPCBin\UMWorkerProcess.exe



Note:

On servers that have Internet Information Services (IIS) installed, Windows opens the HTTP

(port 80, TCP) and HTTPS (port 443, TCP) ports. Exchange 2010 Setup doesn't open these

ports. Therefore, these ports don't appear in the preceding table. On Windows Server 2008 and 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 purposes.

You can disable or remove the rules that aren't restricted to the processes and keep the

corresponding rules restricted to processes if your deployment supports them. The rules not restricted to processes are distinguished by the word (GFW) in the rule name.

A number of 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 configuring 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 Works8. For more information about creating Windows Firewall rules for dynamic RPC, see

Allowing Inbound Network Traffic that Uses Dynamic RPC9.

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 trusts10.

Links Table

1http://technet.microsoft.com/en-us/library/ee633456.aspx

2http://technet.microsoft.com/en-us/library/bb124392.aspx

3http://technet.microsoft.com/en-us/library/aa998911.aspx

4http://go.microsoft.com/fwlink/?linkid=3052&kbid=937031

5http://technet.microsoft.com/en-us/library/bb124092.aspx

6http://technet.microsoft.com/en-us/library/aa998265.aspx

7http://go.microsoft.com/fwlink/?LinkId=179177



10http://go.microsoft.com/fwlink/?linkid=3052&kbid=179442

Community Content

Network Ports Diagram Edit



11/1/2011

Michel de Rooij

© 2012 Microsoft. All rights reserved.

Some time ago I've created a network diagram; the diagram is available in PDF and Visio format.

http://eightwone.com/2011/04/05/exchange-2010-sp1-network-ports-diagram-v03/



Documents

Exchange 2010 Network Port Reference