In this article, we'll learn how to configure static RPC ports for the RPC Client Access, Exchange Address Book, and Public Folder Access services in Exchange 2010.
Imagine that we have a complex organization with Exchange Server 2010 SP1 (or higher), which includes . CAS servers are usually located on a network that is separated by firewalls from the networks from which users are expected to access (Outlook networks). The connection of the Outlook client to the CAS server occurs via RPC, which means that on network layer any port in the free port range can be used. It's no secret that in Windows Server 2008 and 2008 R2 use 49152-65535 as dynamic port range for RPC connections (previous Windows versions Server used RPC ports in the range 1025-65535).
To keep firewalls from becoming a "sieve", it is desirable to narrow the range of RPC ports used, ideally by making them static on each Client Access Server in the Client Access array. In addition, the use of static RPC ports allows you to reduce memory consumption on load balancers (especially HLB) and simplify their configuration (no need to specify large port ranges).
In Exchange 2010, the RPC Client Access service as well as the Exchange Address Book service can be set to static ports. Outlook communicates with these services through the MAPI interface.
Static port for the Exchange 2010 RPC Client Access service
The Exchange 2010 RPC Client Access virtual service is associated with the RPC Client Access service that Outlook MAPI clients connect to in Exchange 2010. When an Outlook client connects to Exchange, on an Exchange 2010 Client Access server, the RPC Client Access service uses the TCP End Point Mapper port (TCP/135) and a random port from the RPC dynamic port range (6005-59530) for incoming connections
In order to set a static port for the RPC Client Access service in Exchange 2010, you need to open the section in the registry editor:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeRPC
Create a new key named ParametersSystem, inside which create a type parameter REG_DWORD With name TCP/IP port. The TCP/IP Port setting specifies a static port for the RPC Client Access service. The Microsoft documentation recommends choosing a port in the range 59531 - 60554 , and using this value on all CAS servers (we specified port 59532, of course, it should not be used by any other software).
After static port assignments, you must restart the Microsoft Exchange RPC Client Access service for the changes to take effect.
Restart-Service MSExchangeRPC
Static port for the Exchange 2010 Address Book service
Prior to SP1, Exchange 2010 used a special configuration file to set the static port of the Exchange 2010 Address Book service Microsoft.exchange.addressbook.service.exe.config. After the release of Exchange 2010 SP1, you can set the static port of this service through the registry. To do this, open the registry editor and go to the branch:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeAB\Parameters
Create a new parameter RpcTcpPort(of type REG_SZ) and give it the port number that you want to fix for the Exchange Address Book service. It is recommended to use any free port in the range 59531-60554 and then use it on all Exchange 2010 Client Access servers in the domain. We will set RpcTcpPort=59533
After that, you need to restart the Microsoft Exchange Address Book service
Restart-Service MSExchangeAB
Important: When migrating from Exchange 2010 RTM to SP1, this key must be set manually, it is not automatically inherited.
Setting up a static port for connecting to shared folders
Public folders are accessed from an Outlook client directly through the RPC Client Access service on a server with the Mailbox role. This setting must be carried out on all servers with the Mailbox role that contain the database shared folders(similar to CAS servers). Open registry editor and go to branch
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeRPC
Create a new key named ParametersSystem, inside which create a REG_DWORD type parameter named TCP/IP port. Set its value: TCP/IP Port = 59532.
After setting the public folder port statically, you need to restart the Microsoft Exchange RPC Client Access service on each mailbox server.
Verify static port usage between Outlook and Exchange 2010
After the changes have been made, check that Outlook connects to the static RPC ports we specified. To do this, on the client machine, restart Outlook, and then in command line run the command:
Netstat -na
Applicable to: Exchange Server 2010 SP1
Section last modified: 2011-04-22
This section provides information about ports, authentication, and encryption for all data paths used in Microsoft Exchange Server 2010. The "Notes" section after each table clarifies or defines non-standard authentication or encryption methods.
Transport servers
In Exchange 2010, there are two server roles that perform message transport functions: a Hub Transport server and an Edge Transport server.
The following table provides information about ports, authentication, and data path encryption between these transport servers and other Exchange 2010 servers and services.
Data paths for transport servers
| Data Path | Required ports | Encryption Support | |||
|---|---|---|---|---|---|
|
Between two Hub Transport servers |
Yes, with TLS (Transport Layer Security) |
||||
|
From a Hub Transport server to an Edge Transport server |
direct trust |
direct trust |
Yes, using TLS |
||
|
From an Edge Transport server to a Hub Transport server |
direct trust |
direct trust |
Yes, using TLS |
||
|
Between two Edge Transport servers |
Anonymous, certificate authentication |
Anonymously, with a certificate |
Yes, using TLS |
||
|
From the server mailboxes via the Microsoft Exchange Mail Submission Service |
NTLM. If the Hub Transport server role and the Mailbox server role are running on the same server, the Kerberos protocol is used. |
Yes, using RPC encryption |
|||
|
From a Hub Transport server to a Mailbox server via MAPI |
NTLM. If the Hub Transport server role and the Mailbox server role are installed on the same server, the Kerberos protocol is used. |
Yes, using RPC encryption |
|||
|
Yes, using TLS |
|||||
|
Microsoft Exchange EdgeSync service from a Hub Transport server to an Edge Transport server |
Yes, using LDAP over SSL (LDAPS) |
||||
|
Access Active Directory from a Hub Transport server |
|||||
|
Accessing the Active Directory Rights Management Service (AD RMS) from a Hub Transport server |
Yes, with SSL |
||||
|
SMTP clients to a Hub Transport server (for example, end users using Windows Live Mail) |
Yes, using TLS |
Notes for Transport Servers
- All traffic between Hub Transport servers is encrypted using Transport Layer Security (TLS) and the self-signed certificates installed by Exchange 2010 Setup.
- All traffic between Edge Transport servers and Hub Transport servers is authenticated and encrypted. Mutual TLS is used as the authentication and encryption mechanism. Instead of X.509 validation, Exchange 2010 uses direct trust. Direct trust means that the presence of a certificate in Active Directory Services or Active Directory Lightweight Directory Services (AD LDS) verifies the authenticity of the certificate. The Active Directory directory service is considered a trusted storage mechanism. When direct trust is used, it does not matter if a self-signed certificate or a certificate signed by a CA is used. When you subscribe an Edge Transport server to an Exchange organization, the Edge Subscription publishes the Edge Transport server's certificate to the Active Directory directory service so that Hub Transport servers can verify it. The Microsoft Exchange EdgeSync service adds a set of Hub Transport server certificates to Active Directory Lightweight Directory Services (AD LDS) so that the Edge Transport server can validate them.
- EdgeSync uses a secure LDAP connection from a Hub Transport server to subscribed Edge Transport servers on TCP port 50636. Active Directory Lightweight Directory Services also listens on TCP port 50389. Connections to this port do not use SSL. You can use LDAP utilities to connect to this port and check AD LDS data.
- By default, traffic between Edge Transport servers located in two different organizations is encrypted. Exchange 2010 Setup creates a self-signed certificate and enables TLS by default. This allows any sending system to encrypt an incoming SMTP session to Exchange. By default, Exchange 2010 also attempts to use TLS for all remote connections.
- The authentication methods for traffic between Hub Transport servers and Mailbox servers are different when the Hub Transport and Mailbox server roles are installed on the same computer. Local mail transfer uses Kerberos authentication. Remote mail transfer uses NTLM authentication.
- Exchange 2010 also supports domain security. Domain Security is a set of Exchange 2010 and Microsoft Outlook 2010 features that provide a low-cost alternative to S/MIME and other Internet messaging security solutions. Domain security provides a way to manage secure communication paths between domains on the Internet. Once these secure paths are configured, messages successfully sent through them from an authenticated sender appear to Outlook and Outlook Web Access users as "domain-level protected" messages. For more information, see Domain security overview.
- Many agents can run on both Hub Transport servers and Edge Transport servers. Typically, protection agents junk mail use information local computer on which they are executed. Thus, interaction with remote computers. The exception is recipient filtering. Recipient filtering requires an AD LDS or Active Directory call. We recommend that you perform recipient filtering on an Edge Transport server. In this case, the AD LDS directory is on the same computer that has the Edge Transport server role installed, so no remote connection is required. If recipient filtering is installed and configured on a Hub Transport server, access to the Active Directory directory service is required.
- The Protocol Analysis agent is used by the Sender Reputation feature in Exchange 2010. This agent also connects to various external proxy servers to determine inbound message paths for suspicious connections.
- All other anti-spam features use data that is collected, stored, and available only on the local computer. Typically, data such as the combined safe senders list or recipient data for recipient filtering is pushed to the on-premises AD LDS directory by using the Microsoft Exchange EdgeSync service.
- Information Rights Management (IRM) agents on Hub Transport servers connect to Active Directory Rights Management Services (AD RMS) servers in the organization. Active Directory Rights Management Service (AD RMS) is a web service that we recommend securing with SSL. Connections to AD RMS servers are made using HTTPS and are authenticated using either Kerberos or NTLM, depending on the configuration of the AD RMS server.
- Log rules, transport rules, and message classification rules are stored in Active Directory and accessed by the Logging agent and the Transport Rules agent on Hub Transport servers.
Mailbox servers
On Mailbox servers, whether NTLM or Kerberos authentication is used depends on the user context or process that the Exchange business logic layer consumer is running under. In this context, consumers are any applications or processes that use the Exchange business logic layer. As a result, in the column Default authentication tables Data paths for Mailbox servers many rows have a value NTLM/Kerberos.
The Exchange business logic layer is used to access and interact with the Exchange store. The Exchange business logic layer is also called from the Exchange store to interact with external applications and processes.
When an Exchange business logic layer consumer runs in the Local System context, the consumer's authentication method for accessing the Exchange store is always Kerberos. The Kerberos authentication method is used because the recipient must be authenticated using account computer "Local System" and requires two-way trust with authentication.
If the Exchange business logic layer recipient is not running in the context of Local System, the authentication method is NTLM. For example, when an administrator runs an Exchange Management Shell cmdlet that uses the Exchange business logic layer, NTLM authentication is used.
RPC traffic is always encrypted.
The following table provides information about ports, authentication, and data path encryption for Mailbox servers.
Data paths for Mailbox servers
Data Path Required ports Default authentication Supported authentication method Encryption Support Data encryption by default 389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC Net Logon)
Yes, using Kerberos encryption
Administrative remote access (remote registry)
Yes, using IPsec
Administrative remote access (SMB, files)
Yes, using IPsec
Availability Web Service (Client Mailbox Access)
Yes, using RPC encryption
Clustering
Yes, using RPC encryption
Between Client Access servers (Exchange ActiveSync)
80/TCP, 443/TCP (SSL)
Kerberos, certificate authentication
Yes, using HTTPS
Yes, using a self-signed certificate
Between Client Access servers (Outlook Web Access)
80/TCP, 443/TCP (HTTPS)
Yes, with SSL
Client Access Server to Client Access Server (Exchange Web Services)
Yes, with SSL
Client Access Server to Client Access Server (POP3)
Yes, with SSL
Client Access Server to Client Access Server (IMAP4)
Yes, with SSL
Office Communications Server to Client Access server (when Office Communications Server and Outlook Web App integration is enabled)
5075-5077/TCP (IN), 5061/TCP (OUT)
mTLS (required)
mTLS (required)
Yes, with SSL
Notes for Client Access servers
Servers unified system messaging
IP gateways and IP PBXs only support certificate authentication, which uses Mutual TLS authentication to encrypt SIP traffic and IP address-based authentication for SIP or TCP connections. IP gateways do not support NTLM and Kerberos authentication. Therefore, when using IP address-based authentication, the authentication mechanism for unencrypted connections (TCP) uses the IP addresses of the connections. When used in Unified Messaging, IP-based authentication checks whether the given IP address is allowed to connect. The IP address is configured on the IP gateway or IP PBX.
IP gateways and IP PBXs support Mutual TLS to encrypt SIP traffic. After successfully importing and exporting the necessary trusted certificates, the IP gateway or IP PBX will request a certificate from the Unified Messaging server and then request a certificate from the IP gateway or IP PBX. The exchange of trusted certificates between the IP gateway or IP PBX and the Unified Messaging server allows both devices to communicate securely using Mutual TLS.
The following table provides port, authentication, and encryption information for data paths between UM servers and other servers.
Data paths for Unified Messaging servers
Data Path Required ports Default authentication Supported authentication method Encryption Support Data encryption by default Accessing Active Directory
389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC Net Logon)
Yes, using Kerberos encryption
UM Dial-in (IP PBX/VoIP Gateway)
5060/TCP , 5065/TCP, 5067/TCP (in non-secure mode), 5061/TCP, 5066/TCP, 5068/TCP (in secure mode), dynamic port range 16000-17000/TCP (management), dynamic UDP ports from the range 1024-65535/UDP (RTP)
By IP address
By IP address, MTLS
Yes, using SIP/TLS, SRTP
UM Web Service
80/TCP, 443/TCP (SSL)
Integrated Windows Authentication (Negotiate)
Yes, with SSL
From a Unified Messaging server to a Client Access server
5075, 5076, 5077 (TCP)
Integrated Windows Authentication (Negotiation)
Basic, Digest, NTLM, Negotiate (Kerberos)
Yes, with SSL
UM Server to Client Access Server (Playback on Phone)
Dynamic RPC
Yes, using RPC encryption
From a Unified Messaging server to a Hub Transport server
Yes, using TLS
From a Unified Messaging server to a Mailbox server
Yes, using RPC encryption
Notes for Unified Messaging Servers
- When you create a UM IP gateway object in Active Directory, you must define the IP address of the physical IP gateway or IP PBX. When you determine the IP address of the UM IP gateway object, the IP address is added to the list of valid IP gateways or IP PBXs (also known as SIP session participants) that the UM server is allowed to communicate with. After you create a UM IP gateway, you can associate it with a UM dial plan. Mapping a UM IP gateway to a dial plan allows UM servers that are mapped to a dial plan to use IP address-based authentication to communicate with the IP gateway. If the UM IP gateway has not been created or configured to use the correct IP address, authentication will fail and the UM servers will not accept connections from the IP address of that IP gateway. In addition, if you implement Mutual TLS, an IP gateway or IP PBX, and Unified Messaging servers, the UM IP gateway must be configured to use a fully qualified domain name (FQDN). After you configure a UM IP gateway using the FQDN, you must also add a host record for the gateway to the forward DNS lookup zone.
- In Exchange 2010, the Unified Messaging server can communicate on port 5060/TCP (non-secure) or port 5061/TCP (secure), and can be configured to use both ports.
For more information, see Understanding UM VoIP Security and Understanding Protocols, Ports, and Services in Unified Messaging .
rules Windows firewall created by Exchange 2010 Setup
Windows Firewall with Advanced Security is a stateful computer-based firewall that filters inbound and outbound traffic based on firewall rules. Exchange 2010 Setup creates Windows Firewall rules to open the ports required for server and client communication in each server role. Therefore, you no longer need to use the SCW to configure these settings. For more information about Windows Firewall with Advanced Security, see Windows Firewall with Advanced Security and IPsec.
The following table lists the Windows Firewall rules, generated by the program Exchange installations, including the ports that are open on each server role. You can view these rules by using the Windows Firewall with Advanced Security MMC snap-in.
Rule name Server Roles Port Program MSExchangeADTopology - RPC (TCP inbound)
Dynamic RPC
Bin\MSExchangeADTopologyService.exe
MSExchangeMonitoring - RPC (TCP inbound)
Client Access server, Hub Transport server, Edge Transport server, Unified Messaging server
Dynamic RPC
Bin\Microsoft.Exchange.Management.Monitoring.exe
MSExchangeServiceHost - RPC (TCP inbound)
Dynamic RPC
Bin\Microsoft.Exchange.ServiceHost.exe
MSExchangeServiceHost - RPCEPMap (TCP Inbound)
Bin\Microsoft.Exchange.Service.Host
MSExchangeRPCEPMap (GFW) (TCP inbound)
MSExchangeRPC (GFW) (TCP inbound)
Client Access server, Hub Transport server, Mailbox server, Unified Messaging server
Dynamic RPC
MSExchange - IMAP4 (GFW) (TCP inbound)
Client Access Server
MSExchangeIMAP4 (TCP inbound)
Client Access Server
ClientAccess\PopImap\Microsoft.Exchange.Imap4Service.exe
MSExchange - POP3 (FGW) (TCP inbound)
Client Access Server
MSExchange - POP3 (TCP inbound)
Client Access Server
ClientAccess\PopImap\Microsoft.Exchange.Pop3Service.exe
MSExchange - OWA (GFW) (TCP inbound)
Client Access Server
5075, 5076, 5077 (TCP)
MSExchangeOWAAppPool (TCP-in)
Client Access Server
5075, 5076, 5077 (TCP)
inetsrv\w3wp.exe
MSExchangeAB RPC (TCP inbound)
Client Access Server
Dynamic RPC
MSExchangeAB-RPCEPMap (TCP-in)
Client Access Server
Bin\Microsoft.Exchange.AddressBook.Service.exe
MSExchangeAB-RpcHttp (TCP-in)
Client Access Server
6002, 6004 (TCP)
Bin\Microsoft.Exchange.AddressBook.Service.exe
RpcHttpLBS (TCP inbound)
Client Access Server
Dynamic RPC
System32\Svchost.exe
MSExchangeRPC - RPC (TCP inbound)
Dynamic RPC
MSExchangeRPC - PRCEPMap (TCP inbound)
Client Access Server, Mailbox Server
Bing\Microsoft.Exchange.RpcClientAccess.Service.exe
MSExchangeRPC (TCP inbound)
Client Access Server, Mailbox Server
Bing\Microsoft.Exchange.RpcClientAccess.Service.exe
MSExchangeMailboxReplication (GFW) (TCP inbound)
Client Access Server
MSExchangeMailboxReplication (TCP inbound)
Client Access Server
Bin\MSExchangeMailboxReplication.exe
MSExchangeIS - RPC (TCP inbound)
Mailbox server
Dynamic RPC
MSExchangeIS RPCEPMap (TCP inbound)
Mailbox server
MSExchangeIS (GFW) (TCP inbound)
Mailbox server
6001, 6002, 6003, 6004 (TCP)
MSExchangeIS (TCP inbound)
Mailbox server
MSExchangeMailboxAssistants - RPC (TCP inbound)
Mailbox server
Dynamic RPC
MSExchangeMailboxAssistants - RPCEPMap (TCP Inbound)
Mailbox server
Bin\MSExchangeMailboxAssistants.exe
MSExchangeMailSubmission - RPC (TCP inbound)
Mailbox server
Dynamic RPC
MSExchangeMailSubmission - RPCEPMap (TCP Inbound)
Mailbox server
Bin\MSExchangeMailSubmission.exe
MSExchangeMigration - RPC (TCP inbound)
Mailbox server
Dynamic RPC
Bin\MSExchangeMigration.exe
MSExchangeMigration - RPCEPMap (TCP inbound)
Mailbox server
Bin\MSExchangeMigration.exe
MSExchangerepl - Log Copier (TCP inbound)
Mailbox server
Bin\MSExchangeRepl.exe
MSExchangerepl - RPC (TCP inbound)
Mailbox server
Dynamic RPC
Bin\MSExchangeRepl.exe
MSExchangerepl - RPC-EPMap (TCP-in)
Mailbox server
Bin\MSExchangeRepl.exe
MSExchangeSearch - RPC (TCP inbound)
Mailbox server
Dynamic RPC
Bin\Microsoft.Exchange.Search.ExSearch.exe
MSExchangeThrottling - RPC (TCP inbound)
Mailbox server
Dynamic RPC
Bin\MSExchangeThrottling.exe
MSExchangeThrottling - RPCEPMap (TCP inbound)
Mailbox server
Bin\MSExchangeThrottling.exe
MSFTED - RPC (TCP inbound)
Mailbox server
Dynamic RPC
MSFTED - RPCEPMap (TCP-in)
Mailbox server
MSExchangeEdgeSync - RPC (TCP inbound)
Hub Transport Server
Dynamic RPC
MSExchangeEdgeSync RPCEPMap (TCP inbound)
Hub Transport Server
Bin\Microsoft.Exchange.EdgeSyncSvc.exe
MSExchangeTransportWorker - RPC (TCP inbound)
Hub Transport Server
Dynamic RPC
Bin\edgetransport.exe
MSExchangeTransportWorker - RPCEPMap (TCP inbound)
Hub Transport Server
Bin\edgetransport.exe
MSExchangeTransportWorker (GFW) (TCP inbound)
Hub Transport Server
MSExchangeTransportWorker (TCP inbound)
Hub Transport Server
Bin\edgetransport.exe
MSExchangeTransportLogSearch - RPC (TCP inbound)
Dynamic RPC
MSExchangeTransportLogSearch - RPCEPMap (TCP inbound)
Hub Transport server, Edge Transport server, Mailbox server
Bin\MSExchangeTransportLogSearch.exe
SESWorker (GFW) (TCP-in)
Unified Messaging Server
SESWorker (TCP inbound)
Unified Messaging Server
UnifiedMessaging\SESWorker.exe
UMService (GFW) (TCP inbound)
Unified Messaging Server
UMService (TCP inbound)
Unified Messaging Server
Bin\UMService.exe
UMWorkerProcess (GFW) (TCP inbound)
Unified Messaging Server
5065, 5066, 5067, 5068
UMWorkerProcess (TCP inbound)
Unified Messaging Server
5065, 5066, 5067, 5068
Bin\UMWorkerProcess.exe
UMWorkerProcess - RPC (TCP inbound)
Unified Messaging Server
Dynamic RPC
Bin\UMWorkerProcess.exe
Notes on Windows Firewall Rules Created by Exchange 2010 Setup
- On servers with IIS installed, Windows opens HTTP (port 80, TCP) and HTTPS (port 443, TCP) ports. Exchange 2010 Setup does not open these ports. Therefore, these ports are not listed in the previous table.
- In Windows Server 2008 and Windows Server 2008 R2, Windows Firewall with Advanced Security allows you to specify a process or service for which a port is open. This is more secure because the port can only be used by the process or service specified in the rule. Exchange Setup creates firewall rules with the specified process name. In some cases, for compatibility purposes, an additional rule is also created that is not limited to this process. You can disable or remove non-process-restricted rules and keep the corresponding process-restricted rules if your current deployment environment supports them. Rules not restricted to processes can be distinguished by the word (GFW) in the name of the rule.
- Many Exchange services use remote procedure calls (RPC) to communicate. Server processes that use remote procedure calls connect to the RPC endpoint mapper to obtain dynamic endpoints and register them in the endpoint mapper database. RPC clients interact with the RPC Endpoint Mapper to determine the endpoints used by the server process. By default, the RPC Endpoint Mapper listens on port 135 (TCP). When you configure Windows Firewall for a process that uses remote procedure calls, Exchange 2010 Setup creates two firewall rules for that process. One rule allows communication with the RPC endpoint mapper, and the second rule allows communication with a dynamically assigned endpoint. For more information about remote procedure calls, see the article. For more information about creating Windows Firewall rules for dynamic remote procedure call, see the article.
For more information, see Microsoft Knowledge Base Article 179442
www.microsoft.com
Article Exchange 2013 Front End Transport Service is the first in a series of articles covering how Exchange Server 2013 Transport Services works. This article will focus on Front End Transport Service on Client Access servers.
In the 2013 version of the Exchange server, there were quite strong changes in the architecture and now there are only two main roles - the mailbox server (Mailbox Server or MBX for short) and the client access server (Client Access Server - CAS). Standing apart is the role of the Edge Transport server. Service Exchange 2013 Front End Transport located on CAS servers and acts as a proxy.
This is the first article in a series on how the Exchange 2013 transport pipeline services work, but here's the full list:
As well as articles on managing the logging of these services:
Don't forget the official documentation.
You can find more information on configuring and administering Exchange 2013 on my blog in the main topic article -.
It just so happens that there are now quite a few transport services in Exchange 2013 that have similar names but are fundamentally different in purpose and how they work. Here are all these services:
- Front End Transport Service on Client Access servers (Display name is Microsoft Exchange FrontEnd Transport, abbreviated as MSExchangeFrontEndTransport);
- Transport Service on Mailbox servers (Display name is Microsoft Exchange Transport, abbreviated to MSExchangeTransport);
- Mailbox Transport Service on mailbox servers (Really includes two services - Microsoft Exchange Mailbox Transport Delivery and Microsoft Exchange Mailbox Transport Submission, abbreviated names - MSExchangeDelivery and MSExchangeSubmission, respectively);
- Transport service on Edge Transport servers (Display name is Microsoft Exchange Transport, abbreviated as MSExchangeTransport).
At the same time, only the second and fourth services perform comparable functionality, the rest differ fundamentally. Together, they all form the transport pipeline, which is the heart of the mail server.
transport conveyor
In general, the transport pipeline looks like this:
In the context of this article, we are interested in the upper part of the illustration, which shows the Client Access Server:
There is one nuance in this scheme. The fact is that, by default, MBX servers can independently send mail out through port 25 SMTP. To ensure that a Send connector always sends mail to the Internet through Client Access servers, you must explicitly set the Send connector parameter to FrontendProxyEnabled into meaning $true(or in the EAC check the box Proxy through the Client Access server in the properties of the Send connector). It is from this configuration that I will build on in the future.
Below I will try to bring some clarity to the principle of operation. Exchange 2013 servers with the CAS role.
Principle of operation
Front End Transport(in Microsoft terminology - Front End Transport Service) does not process message content, does not use a message queue, and does not interact with the Mailbox Transport service. In other words, Exchange 2013 servers with only the CAS role do not store data either permanently (using a database) or temporarily (in a message processing queue).
However, the Front End Transport service has its own transport agents (see figure - Protocol Agents). Agents allow you to extend the functionality of an Exchange mail server by adding custom code to the message processing logic. Agents are invoked when SMTP events occur. These events, in turn, are generated at one stage or another of message processing as they pass through the transport pipeline. It is worth noting that most of the agents present by default are hidden or their settings cannot be controlled. The functionality of agents on CAS servers is quite limited and is fully present only for the MBX and Edge roles.
Send and receive connectors
On the diagram (see above) Front End Transport Service we denote the client access server on each incoming and outgoing connection corresponding port, resulting in the following representation:
A separate receive connector is responsible for listening for connections on each port indicated in the diagram, of which three pieces are created by default when the CAS role is installed:
In addition to connectors that are visible and accessible to the administrator, there are also hidden system Send connectors:
- Inbound Proxy Internal Send Connector (SMTP 25/2525 in )
- Client Proxy Send Connector (SMTP received on port 587 in Transport service on Mailbox servers to port 465)
By the way, the first connector in the Russian version of Exchange Server 2013 will have the name Internal send connector for input. conn. proxy servers, and second - Client proxy send connector. This is just in case, so as not to come to a stupor at the first meeting with these connectors.
As a result, we get the following complete table:
| Name | Purpose | Port | Direction |
| Default Frontend |
Reception | 25 | From external servers |
| Outbound Proxy Frontend |
Reception | 717 | From MBX servers |
| Client Frontend |
Reception | 587 | From external clients, secure connection |
| Client Proxy Send Connector | Sending | 465 | To MBX servers |
| Inbound Proxy Internal Send Connector | Sending | 25/2525 | To MBX servers. Only connections accepted on port 587 |
| Manually created Send connector | Sending | 25 | To external servers |
Let's transfer the names of the connectors to the diagram Front End Transport Service.
Exchange Server and FirewallsFirewalls (firewalls) for mail servers (Exchange Server), mail server ports, front-end and back-end mail servers, virtual servers SMTP, POP3, IMAP4
Like any computer connected to the Internet, the computer that hosts the mail server must be protected with a firewall. At the same time, the options for installing a mail server in terms of network configuration can be very different:
· The simplest option is to install a mail server on a computer that is also a proxy/firewall, and then open the necessary ports on the interface facing the Internet. Typically, this scheme is used in small organizations;
Another option is to install the mail server in local network and configure it to work through a proxy server. To do this, you can bind public ip to the mail server and pass it through a proxy or use port mapping tools on the proxy server. Many proxy servers have special wizards or predefined rules for organizing such a solution (for example, in ISA Server). This option is used in most organizations.
· Another fundamental possibility is to create a DMZ and place in it front-end Exchange Server (such a possibility has appeared since version 2000) or SMTP Relay based on another Exchange Server or, for example, sendmail on *nix. Usually used in networks of large organizations.
In any case, the mail server must ensure communication on at least TCP port 25 (SMTP) and UDP port 53 (DNS). Other ports that may be required by Exchange Server depending on your network configuration (all TCP):
80 HTTP - to access the Web interface (OWA)
· 88 Kerberos authentication protocol - if Kerberos authentication is used (rare);
· 102 MTA .X .400 connector over TCP /IP (if X .400 connector is used for communication between routing groups);
· 110 Post Office Protocol 3 (POP 3) - for client access;
· 119 Network News Transfer Protocol (NNTP) - if newsgroups are used;
135 Client /server communication RPC Exchange administration - standard RPC port for remote Exchange administration standard means system manager;
· 143 Internet Message Access Protocol (IMAP) - for customer access;
· 389 LDAP - to access the directory service;
· 443 HTTP (Secure Sockets Layer (SSL)) (and below) - the same protocols protected by SSL.
563 NNTP (SSL)
636 LDAP (SSL)
993 IMAP4 (SSL)
995 POP3 (SSL)
· 3268 and 3269 - requests to the global catalog server (search in Active Directory and checking membership in universal groups).
It makes no sense to close the Exchange Server interface facing inside the organization with a firewall - it will be used to interact with domain controllers, administration utilities, systems Reserve copy etc. For an interface exposed to the Internet, it is recommended to leave ports 53 (if Exchange will resolve hostnames itself, and not forward requests to local server DNS) and 25. Very often, clients need to access their mailboxes from outside (from home, during a business trip, etc.). The best solution in this situation is to configure OWA (the web interface for accessing Exchange Server, which is installed by default, available at http://server_name/exchange) to work over SSL and allow access only on port 443. In addition to resolving issues with secure authentication and message encryption automatically solves the issue with SMTP Relay (more on that later) and the situation when a user accidentally downloads a working email to mail client folders on home computer, and then at work he cannot find these messages (not to mention the fact that storing work mail at home is a security breach).
A new feature introduced in Exchange Server . since version 2000, the ability to use multiple virtual SMTP and POP3 servers with different security settings. For example, the SMTP server that communicates with the Internet can be configured for enhanced security and strict delivery restrictions, while the SMTP server that users within the organization use can be configured for maximum performance and user-friendliness.
It is also necessary to mention a certain confusion in terminology - very often firewalls for Exchange are called message filtering systems, which will be discussed below.
[This article is a preliminary document and is subject to change in future releases. Blank sections are included as placeholders. If you would like to write a review, we would love to receive it. Send it to us at email address [email protected]]
Applicable to: Exchange Server 2016
Information about the network ports that Exchange 2016 uses for client access and mail flow.
This topic provides information about the network ports used by Microsoft Exchange Server 2016 to communicate with email clients, Internet mail servers, and other services that are located outside of your on-premises Exchange organization. Before you begin, consider the following ground rules.
We do not support limiting or modifying network traffic between internal Exchange Servers, between internal Exchange Servers and internal Lync or Skype for Business servers, or between internal Exchange Servers and internal Active Directory domain controllers in any of the topology types. If you are using firewalls or network devices that can restrict or modify this network traffic, you must set up rules to allow free and unrestricted communications between these servers (rules that allow network traffic to and from any port, including random RPC ports, and any protocol). , which doesn't change a single bit).
Edge Transport servers are almost always in the perimeter network, so network traffic between the Edge Transport server and the Internet, and between the Edge Transport server and the internal Exchange organization, is expected to be limited. These network ports are described in this section.
You are expected to restrict network traffic between external clients and services and the internal Exchange organization. You can also restrict traffic between internal clients and internal Exchange servers. These network ports are described in this section.
Content
Network ports required for clients and services
Network ports required for mail flow (no Edge Transport servers)
Network ports required for mail flow with Edge Transport servers
Network ports required for hybrid deployments
Network ports required for Unified Messaging
The network ports that email clients need to access mailboxes and other services in the Exchange organization are described at next diagram and in the table.
Notes.
The destination for these clients and services is the Client Access services on the Mailbox server. In Exchange 2016, Client Access Services (external) and internal services are installed together on the same Mailbox server. See the section for more information.
Although the diagram shows clients and services from the Internet, the concepts are the same for internal clients (for example, clients in an account forest accessing Exchange servers in a resource forest). Similarly, there is no Source column in the table because the source can be any location external to the Exchange organization (for example, the Internet or an account forest).
Edge Transport servers do not participate in network traffic associated with these clients and services.
| Purpose | Ports | Notes |
|---|---|---|
Encrypted web connections are used by the following clients and services. Autodiscover service Exchange ActiveSync Exchange Web Services (EWS) Distributing Offline Address Books Outlook Anywhere (RPC over HTTP) MAPI Outlook over HTTP Outlook on the web | 443/TCP (HTTPS) | EWS Reference for Exchange |
Unencrypted web connections are used by the following clients and services. Publish your calendar to the web Outlook on the web (redirect to port 443/TCP) Autodiscovery (fallback when port 443/TCP is unavailable) | 80/TCP (HTTP) | Whenever possible, we recommend that you use encrypted web connections on port 443/TCP to protect credentials and other data. However, some services must be configured to use unencrypted web connections on port 80/TCP to Client Access services on Mailbox servers. For more information about these clients and services, see the following articles. |
IMAP4 clients | 143/TCP (IMAP), 993/TCP (Secure IMAP) | IMAP4 is disabled by default. See the section for more information. The IMAP4 service in Client Access services on the Mailbox server proxies connections to the internal IMAP4 service on the Mailbox server. |
POP3 Clients | 110/TCP (POP3), 995/TCP (secure POP3) | By default, the POP3 protocol is disabled. See the section for more information. The POP3 service in Client Access services on the Mailbox server proxies connections to the internal POP3 service on the Mailbox server. |
SMTP clients (with authentication) | 587/TCP (Authenticated SMTP) | The default Receive connector is "Client Frontend Note. If you have email clients that can only send authenticated SMTP messages on port 25, you can change the binding value of this Receive connector to also listen for authenticated SMTP messages on port 25. |
To the begining
Network ports required for mail flow
Outgoing mail
25/TCP (SMTP)
Mailbox server
Internet (all)
By default, Exchange doesn't create Send connectors that allow you to send mail to the Internet. You must create the Send connectors manually. See the section for more information.
Outgoing mail (if it is sent through an external transport service)
25/TCP (SMTP)
Mailbox server
Internet (all)
Outbound mail is sent through the external transport service only if the Send connector setting is enabled Proxy through the Client Access server in the EAC, or the -FrontEndProxyEnabled $true parameter in the Exchange Management Shell.
In this case, the default Receive connector "Outbound Proxy Frontend
DNS server for mail next hop name resolution (not shown)
53/UDP, 53/TCP (DNS)
Mailbox server
DNS server
To the begining
A subscribed Edge Transport server installed in the perimeter network affects mail flow in the following ways:
Mail from an Exchange 2016 or Exchange 2013 Edge Transport server first enters the External Transport service and then is routed to the Transport service on the Exchange 2016 Mailbox server.
Mail from an Exchange 2010 Edge Transport server always goes directly to the Transport service on an Exchange 2016 Mailbox server.
Outbound mail from the Exchange organization never goes through the external transport service on Mailbox servers. It always redirects from the Transport service on the Mailbox server of the subscribed Active Directory site to the Edge Transport server (regardless of the version of Exchange on the Edge Transport server).
Incoming mail is redirected from the Edge Transport server to the Mailbox server of the subscribed Active Directory site. This means the following:
The network ports required for mail flow in Exchange organizations with Edge Transport servers are described in the following diagram and table.
| Purpose | Ports | A source | Purpose | Notes |
|---|---|---|---|---|
Incoming mail - from the Internet to an Edge Transport server | 25/TCP (SMTP) | Internet (all) | The default Receive connector named Default Internal Receive Connector <имя пограничного транспортного сервера> " on the Edge Transport server listens for anonymous SMTP mail on port 25. |
|
Inbound mail - from the Edge Transport server to the internal Exchange organization | 25/TCP (SMTP) | Edge Transport Server | The default Send connector named "EdgeSync - Inbound to Default Receive Connector "Default Frontend |
|
Outbound mail - from an internal Exchange organization to an Edge Transport server | 25/TCP (SMTP) | Mailbox servers in a subscribed Active Directory site | Outgoing mail always bypasses the External Transport service on Mailbox servers. Mail is relayed from the Transport service on any Mailbox server in a subscribed Active Directory site to an Edge Transport server by using an implicit and invisible intra-organizational Send connector that automatically routes mail between Exchange servers in the same organization. Default internal Receive connector |
|
Outgoing mail - from the Edge Transport server to the Internet | 25/TCP (SMTP) | Edge Transport Server | Internet (all) | The default Send connector named "EdgeSync - with <имя сайта Active Directory> to the Internet" relays outgoing mail on port 25 from the Edge Transport server to the Internet. |
EdgeSync Synchronization | 50636/TCP (Secure LDAP) | Mailbox servers in the subscribed Active Directory site that participate in EdgeSync synchronization | Edge Transport Servers | If an Edge Transport server is subscribed to an Active Directory site, all Mailbox servers that currently exist in the site participate in EdgeSync synchronization. But if you add more Mailbox servers later, they won't automatically participate in EdgeSync synchronization. |
DNS server for next hop name resolution (not shown) | 53/UDP, 53/TCP (DNS) | Edge Transport Server | DNS server | See Name Resolution. |
Sender Reputation Open Proxy Detection (not shown) | see notes | Edge Transport Server | Internet | By default, the protocol analysis agent uses open proxy discovery as one of the conditions for calculating the reputation level of the source messaging server. See the article for more information. The following TCP ports are used to check the source messaging servers for an open proxy server: Also, if your organization uses a proxy server to control outbound Internet traffic, you must determine the proxy server name, type, and TCP port required to access the Internet and detect an open proxy server. You can also disable open proxy detection. See the section for more information. |
To the begining
Name resolution
Name resolution
DNS next-hop mail resolution is a fundamental part of the mail flow in any Exchange organization. Exchange servers responsible for receiving incoming mail or delivering outgoing mail must be able to resolve both internal and external hostnames in order to properly route mail. All internal Exchange servers must be able to resolve internal hostnames in order to properly route mail. There are many various ways development of the DNS infrastructure, but the important result is ensuring proper name resolution for the next hop across all Exchange servers.