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 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 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 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 |
|
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 |
Kerberos |
Yes, 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/Kerberos |
Yes, using SSL |
Yes* |
|
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 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 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 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 |
Kerberos |
Yes, using Kerberos encryption |
Yes |
|
Admin remote access (Remote Registry) |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Yes, using IPsec |
No |
|
Admin remote access (SMB/File) |
445/TCP (SMB) |
NTLM/Kerberos |
NTLM/Kerberos |
Yes, using IPsec |
No |
|
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/Kerberos |
Yes, using IPsec |
No |
|
Content indexing |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
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 Assistants |
135/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/Kerberos |
Yes, 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), 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/Kerberos |
NTLM/Kerberos |
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 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), 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 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 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 |
Kerberos |
Yes, using Kerberos encryption |
Yes |
|
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, Kerberos |
Yes, using HTTPS |
Yes |
|
Mailbox Replication Service (MRS) |
808/TCP |
Kerberos/NTLM |
Kerberos, NTLM |
Yes, using RPC encryption |
Yes |
|
Outlook accessing OAB |
80/TCP, 443/TCP (SSL) |
NTLM/Kerberos |
NTLM/Kerberos |
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 Anywhere (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/Kerberos |
Negotiate (Kerberos with fallback to NTLM or optionally Basic,) POP/IMAP plain text |
Yes, using IPsec |
No |
|
Client Access server to Exchange 2010 Mailbox server |
RPC. See Notes on Client Access Servers. |
Kerberos |
NTLM/Kerberos |
Yes, using RPC encryption |
Yes |
|
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) 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.
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 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 |
Kerberos |
Yes, using Kerberos 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 address |
By 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 SSL |
Yes |
|
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 |
Kerberos |
Yes, using TLS |
Yes |
|
Unified Messaging server to Mailbox server |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Yes, using RPC encryption |
Yes |
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, Mailbox, Unified Messaging |
Dynamic RPC |
Bin\MSExchangeADTopologyService.exe |
|
MSExchangeMonitoring - RPC (TCP-In) |
Client Access, Hub Transport, Edge Transport, Unified Messaging |
Dynamic RPC |
Bin\Microsoft.Exchange.Management.Monitoring.exe |
|
MSExchangeServiceHost - RPC (TCP-In) |
All roles |
Dynamic 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 Transport, Mailbox, Unified Messaging |
Dynamic 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.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 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) (TCP-In) |
Client Access |
808 (TCP) |
Any |
|
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, 6003, 6004 (TCP) |
Any |
|
MSExchangeIS (TCP-In) |
Mailbox |
6001 (TCP) |
Bin\Store.exe |
|
MSExchangeMailboxAssistants - RPC (TCP-In) |
Mailbox |
Dynamic RPC |
Bin\MSExchangeMailboxAssistants.exe |
|
MSExchangeMailboxAssistants - RPCEPMap (TCP-In) |
Mailbox |
RPC-EPMap |
Bin\MSExchangeMailboxAssistants.exe |
|
MSExchangeMailSubmission - RPC (TCP-In) |
Mailbox |
Dynamic RPC |
Bin\MSExchangeMailSubmission.exe |
|
MSExchangeMailSubmission - RPCEPMap (TCP-In) |
Mailbox |
RPC-EPMap |
Bin\MSExchangeMailSubmission.exe |
|
MSExchangeMigration - RPC (TCP-In) |
Mailbox |
Dynamic 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 |
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 (TCP-In) |
Mailbox |
RPC-EPMap |
Bin\MSExchangeThrottling.exe |
|
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 (TCP-In) |
Hub Transport |
RPC-EPMap |
Bin\Microsoft.Exchange.EdgeSyncSvc.exe |
|
MSExchangeTransportWorker - RPC (TCP-In) |
Hub Transport |
Dynamic RPC |
Bin\edgetransport.exe |
|
MSExchangeTransportWorker - RPCEPMap (TCP-In) |
Hub Transport |
RPC-EPMap |
Bin\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 RPC |
Bin\MSExchangeTransportLogSearch.exe |
|
MSExchangeTransportLogSearch - RPCEPMap (TCP-In) |
Hub Transport, Edge Transport, Mailbox |
RPC-EPMap |
Bin\MSExchangeTransportLogSearch.exe |
|
SESWorker (GFW) (TCP-In) |
Unified Messaging |
Any |
Any |
|
SESWorker (TCP-In) |
Unified Messaging |
Any |
UnifiedMessaging\SESWorker.exe |
|
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, 5067, 5068 |
Any |
|
UMWorkerProcess (TCP-In) |
Unified Messaging |
5065, 5066, 5067, 5068 |
Bin\UMWorkerProcess.exe |
|
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.