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.
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
authentication
Encryptio
n
supported
?
Encrypte
d 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 trust
Yes, using
TLS
Yes
Edge Transport
server to Hub
Transport server
25/TCP (SMTP) Direct trust Direct trust
Yes, using
TLS
Yes
Edge Transport
server to Edge
Transport server
25/TCP SMTP
Anonymous,
Certificate
Anonymous,
Certificate
Yes, using
TLS
Yes
Mailbox server to
Hub Transport
server via the
Microsoft Exchan
ge Mail
Submission
Service
135/TCP (RPC)
NTLM. If the
Hub Transport
and the
Mailbox server
roles are on the
same server,
Kerberos is
NTLM/Kerber
os
Yes, using
RPC
encryption
Yes
used.
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/Kerber
os
Yes, using
RPC
encryption
Yes
Unified
Messaging server
to Hub Transport
server
25/TCP (SMTP) Kerberos Kerberos
Yes, using
TLS
Yes
Microsoft Exchan
ge 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 (Kerbero
s),
53/TCP/UDP (DNS),
135/TCP (RPC netlogo
n)
Kerberos Kerberos
Yes, using
Kerberos
encryption
Yes
Active Directory
Rights
Management
Services (AD
RMS) access from
Hub Transport
server
443/TCP (HTTPS)
NTLM/Kerber
os
NTLM/Kerber
os
Yes, using
SSL
Yes*
SMTP clients to
Hub Transport
server (for
example, end-
users using
Windows Live
Mail)
587 (SMTP)
25/TCP (SMTP)
NTLM/Kerber
os
NTLM/Kerber
os
Yes, using
TLS
Yes
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:
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 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 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 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, 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.
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
authentication
Supported
authentication
Encryptio
n
supported
?
Encrypte
d 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 Kerberos
Yes, using
Kerberos
encryption
Yes
Admin
remote
access
(Remote
Registry)
135/TCP (RPC)
NTLM/Kerbero
s
NTLM/Kerbero
s
Yes, using
IPsec
No
Admin
remote
access
(SMB/File)
445/TCP (SMB)
NTLM/Kerbero
s
NTLM/Kerbero
s
Yes, using
IPsec
No
Availabilit
y Web
service
(Client
Access to
Mailbox)
135/TCP (RPC)
NTLM/Kerbero
s
NTLM/Kerbero
s
Yes, using
RPC
encryption
Yes
Clustering
135/TCP (RPC) See
Notes on Mailbox
Servers after this table.
NTLM/Kerbero
s
NTLM/Kerbero
s
Yes, using
IPsec
No
Content
indexing
135/TCP (RPC)
NTLM/Kerbero
s
NTLM/Kerbero
s
Yes, using
RPC
encryption
Yes
Log
shipping
64327 (customizable)
NTLM/Kerbero
s
NTLM/Kerbero
s
Yes No
Seeding 64327 (customizable)
NTLM/Kerbero
s
NTLM/Kerbero
s
Yes No
Volume
shadow
copy
service
(VSS)
backup
Local Message Block
(SMB)
NTLM/Kerbero
s
NTLM/Kerbero
s
No No
Mailbox
Assistants
135/TCP (RPC)
NTLM/Kerbero
s
NTLM/Kerbero
s
No No
MAPI
access
135/TCP (RPC)
NTLM/Kerbero
s
NTLM/Kerbero
s
Yes, using
RPC
Yes
encryption
Microsoft
Exchange
Active
Directory
Topology
service
access
135/TCP (RPC)
NTLM/Kerbero
s
NTLM/Kerbero
s
Yes, using
RPC
encryption
Yes
Microsoft
Exchange
System
Attendant
service
legacy
access
(Listen to
requests)
135/TCP (RPC)
NTLM/Kerbero
s
NTLM/Kerbero
s
No No
Microsoft
Exchange
System
Attendant
service
legacy
access to
Active
Directory
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
Microsoft
Exchange
System
Attendant
service
legacy
access (As
MAPI
client)
135/TCP (RPC)
NTLM/Kerbero
s
NTLM/Kerbero
s
Yes, using
RPC
encryption
Yes
Offline
address
book
(OAB)
accessing
Active
Directory
135/TCP (RPC) Kerberos Kerberos
Yes, using
RPC
encryption
Yes
Recipient
Update
Service
135/TCP (RPC) Kerberos Kerberos
Yes, using
RPC
encryption
Yes
RPC access
Recipient
update to
Active
Directory
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
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 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.
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 port, 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
authentication
Supported
authentication
Encryptio
n
supported
?
Encrypte
d by
default?
Active Directory
access
389/TCP/UDP (LDAP)
,
3268/TCP (LDAP GC)
,
88/TCP/UDP (Kerbero
s),
53/TCP/UDP (DNS),
135/TCP (RPC netlogo
Kerberos Kerberos
Yes, using
Kerberos
encryption
Yes
n)
Autodiscover
service
80/TCP,
443/TCP (SSL)
Basic/Integrate
d Windows
authentication
(Negotiate)
Basic, Digest,
NTLM,
Negotiate
(Kerberos)
Yes, using
HTTPS
Yes
Availability
service
80/TCP,
443/TCP (SSL)
NTLM/Kerber
os
NTLM,
Kerberos
Yes, using
HTTPS
Yes
Outlook
accessing OAB
80/TCP,
443/TCP (SSL)
NTLM/Kerber
os
NTLM/Kerber
os
Yes, 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
POP3
110/TCP (TLS),
995/TCP (SSL)
Basic,
Kerberos
Basic,
Kerberos
Yes, using
SSL, TLS
Yes
IMAP4
143/TCP (TLS),
993/TCP (SSL)
Basic,
Kerberos
Basic,
Kerberos
Yes, using
SSL, TLS
Yes
Outlook Anywhe
re (formerly
known as RPC
over HTTP )
80/TCP,
443/TCP (SSL)
Basic
Basic or
NTLM
Yes, using
HTTPS
Yes
Exchange
ActiveSync
application
80/TCP,
443/TCP (SSL)
Basic
Basic,
Certificate
Yes, using
HTTPS
Yes
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/Kerber
os
Negotiate
(Kerberos with
fallback to
NTLM or
optionally
Basic,)
POP/IMAP
plain text
Yes, using
IPsec
No
Client Access
server to
Exchange 2010
RPC. See Notes on
Client Access Servers.
Kerberos
NTLM/Kerber
os
Yes, using
RPC
encryption
Yes
Mailbox server
Client Access
server to Client
Access server
(Exchange
ActiveSync)
80/TCP,
443/TCP (SSL)
Kerberos
Kerberos,
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
SSL
Yes
Client Access
server to Client
Access server
(Exchange Web
Services)
443/TCP (HTTPS) Kerberos Kerberos
Yes, using
SSL
Yes
Client Access
server to Client
Access server
(POP3)
995 (SSL) Basic Basic
Yes, using
SSL
Yes
Client Access
server to Client
Access server
(IMAP4)
993 (SSL) Basic Basic
Yes, using
SSL
Yes
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
SSL
Yes
Note:
Integrated Windows authentication (NTLM) isn't 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 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 server.
Note:
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
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 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
Transpo
Dynam
ic RPC
Bin\MSExchangeADTopologyService.exe
rt,
Mailbox
,
Unified
Messagi
ng
MSExchangeMonitoring -
RPC (TCP-In)
Client
Access,
Hub
Transpo
rt, Edge
Transpo
rt,
Unified
Messagi
ng
Dynam
ic RPC
Bin\Microsoft.Exchange.Management.Monitoring.
exe
MSExchangeServiceHost -
RPC (TCP-In)
All roles
Dynam
ic RPC
Bin\Microsoft.Exchange.ServiceHost.exe
MSExchangeServiceHost -
RPCEPMap (TCP-In)
All roles
RPC-
EPMap
Bin\Microsoft.Exchange.Service.Host
MSExchangeRPCEPMap
(GFW) (TCP-In)
All roles
RPC-
EPMap
Any
MSExchangeRPC (GFW)
(TCP-In)
Client
Access,
Hub
Transpo
rt,
Mailbox
,
Unified
Messagi
ng
Dynam
ic RPC
Any
MSExchange - IMAP4
(GFW) (TCP-In)
Client
Access
143,
993
(TCP)
All
MSExchangeIMAP4 (TCP-
In)
Client
Access
143,
993
(TCP)
ClientAccess\PopImap\Microsoft.Exchange.Imap4
Service.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.Pop3S
ervice.exe
MSExchange - OWA
(GFW) (TCP-In)
Client
Access
5075,
5076,
5077
(TCP)
All
MSExchangeOWAAppPoo
l (TCP-In)
Client
Access
5075,
5076,
5077
(TCP)
Inetsrv\w3wp.exe
MSExchangeAB-RPC
(TCP-In)
Client
Access
Dynam
ic 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
Dynam
ic RPC
System32\Svchost.exe
MSExchangeRPC - RPC
(TCP-In)
Client
Access,
Mailbox
Dynam
ic RPC
Bing\Microsoft.Exchange.RpcClientAccess.Servic
e.exe
MSExchangeRPC -
PRCEPMap (TCP-In)
Client
Access,
Mailbox
RPC-
EPMap
Bing\Microsoft.Exchange.RpcClientAccess.Servic
e.exe
MSExchangeRPC (TCP-
In)
Client
Access,
Mailbox
6001
(TCP)
Bing\Microsoft.Exchange.RpcClientAccess.Servic
e.exe
MSExchangeMailboxRepli
cation (GFW) (TCP-In)
Client
Access
808
(TCP)
Any
MSExchangeMailboxRepli
cation (TCP-In)
Client
Access
808
(TCP)
Bin\MSExchangeMailboxReplication.exe
MSExchangeIS - RPC
(TCP-In)
Mailbox
Dynam
ic RPC
Bin\Store.exe
MSExchangeIS
RPCEPMap (TCP-In)
Mailbox
RPC-
EPMap
Bin\Store.exe
MSExchangeIS (GFW)
(TCP-In)
Mailbox
6001,
6002,
6003,
6004
(TCP)
Any
MSExchangeIS (TCP-In) Mailbox
6001
(TCP)
Bin\Store.exe
MSExchangeMailboxAssis
tants - RPC (TCP-In)
Mailbox
Dynam
ic RPC
Bin\MSExchangeMailboxAssistants.exe
MSExchangeMailboxAssis
tants - RPCEPMap (TCP-
In)
Mailbox
RPC-
EPMap
Bin\MSExchangeMailboxAssistants.exe
MSExchangeMailSubmissi
on - RPC (TCP-In)
Mailbox
Dynam
ic RPC
Bin\MSExchangeMailSubmission.exe
MSExchangeMailSubmissi
on - RPCEPMap (TCP-In)
Mailbox
RPC-
EPMap
Bin\MSExchangeMailSubmission.exe
MSExchangeMigration -
RPC (TCP-In)
Mailbox
Dynam
ic RPC
Bin\MSExchangeMigration.exe
MSExchangeMigration -
RPCEPMap (TCP-In)
Mailbox
RPC-
EPMap
Bin\MSExchangeMigration.exe
MSExchangerepl - Log
Copier (TCP-In)
Mailbox
64327
(TCP)
Bin\MSExchangeRepl.exe
MSExchangerepl - RPC
(TCP-In)
Mailbox
Dynam
ic RPC
Bin\MSExchangeRepl.exe
MSExchangerepl - RPC-
EPMap (TCP-In)
Mailbox
RPC-
EPMap
Bin\MSExchangeRepl.exe
MSExchangeSearch - RPC
(TCP-In)
Mailbox
Dynam
ic RPC
Bin\Microsoft.Exchange.Search.ExSearch.exe
MSExchangeThrottling -
RPC (TCP-In)
Mailbox
Dynam
ic RPC
Bin\MSExchangeThrottling.exe
MSExchangeThrottling -
RPCEPMap (TCP-In)
Mailbox
RPC-
EPMap
Bin\MSExchangeThrottling.exe
MSFTED - RPC (TCP-In) Mailbox
Dynam
ic RPC
Bin\MSFTED.exe
MSFTED - RPCEPMap
(TCP-In)
Mailbox
RPC-
EPMap
Bin\MSFTED.exe
MSExchangeEdgeSync -
RPC (TCP-In)
Hub
Transpo
rt
Dynam
ic RPC
Bin\Microsoft.Exchange.EdgeSyncSvc.exe
MSExchangeEdgeSync -
RPCEPMap (TCP-In)
Hub
Transpo
rt
RPC-
EPMap
Bin\Microsoft.Exchange.EdgeSyncSvc.exe
MSExchangeTransportWor
ker - RPC (TCP-In)
Hub
Transpo
rt
Dynam
ic RPC
Bin\edgetransport.exe
MSExchangeTransportWor
ker - RPCEPMap (TCP-In)
Hub
Transpo
rt
RPC-
EPMap
Bin\edgetransport.exe
MSExchangeTransportWor
ker (GFW) (TCP-In)
Hub
Transpo
rt
25, 587
(TCP)
Any
MSExchangeTransportWor
ker (TCP-In)
Hub
Transpo
rt
25, 587
(TCP)
Bin\edgetransport.exe
MSExchangeTransportLog
Search - RPC (TCP-In)
Hub
Transpo
rt, Edge
Transpo
rt,
Mailbox
Dynam
ic RPC
Bin\MSExchangeTransportLogSearch.exe
MSExchangeTransportLog
Search - RPCEPMap
(TCP-In)
Hub
Transpo
rt, Edge
Transpo
rt,
Mailbox
RPC-
EPMap
Bin\MSExchangeTransportLogSearch.exe
SESWorker (GFW) (TCP-
In)
Unified
Messagi
ng
Any Any
SESWorker (TCP-In)
Unified
Messagi
ng
Any UnifiedMessaging\SESWorker.exe
UMService (GFW) (TCP-
In)
Unified
Messagi
ng
5060,
5061
Any
UMService (TCP-In)
Unified
Messagi
ng
5060,
5061
Bin\UMService.exe
UMWorkerProcess (GFW)
(TCP-In)
Unified
Messagi
ng
5065,
5066,
5067,
5068
Any
UMWorkerProcess (TCP-
In)
Unified
Messagi
ng
5065,
5066,
5067,
5068
Bin\UMWorkerProcess.exe
UMWorkerProcess - RPC
(TCP-In)
Unified
Messagi
ng
Dynam
ic 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 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 Works. For more information about
creating Windows Firewall rules for dynamic RPC, see Allowing Inbound Network
Traffic that Uses Dynamic RPC.