Exchange network ports reference. Exchange network ports reference Exchange ports to connect

26.06.2020 Interesting

From Rosalab Wiki

Appointment

This guide describes how to connect various mail clients to the Microsoft Exchange server. The goal is to get a system that matches Microsoft Outlook in functionality.

Input data

The examples use Microsoft Exchange 2010 (v14.03.0361.001) Service Pack 3 Update RollUp 18. Testing is performed within the corporate network. The external mail addresses for the mail server are specified on the DNS servers. The following should be running on the Exchange server:

OWA (Outlook Web Access) - a web client for accessing the Microsoft Exchange Community Server
OAB (Offline Address Book) - offline address book
EWS (Exchange Web Services) is a service that provides access to mailbox data stored in Exchange Online (as part of Office 365) and on-premises Exchange (starting with Exchange Server 2007)

Exchange Server Settings

Authentication is critical to the success of non-Microsoft clients on Exchange 2010. You can view its parameters on the Exchange server with the CAS (Client Access Server) role. Start the IIS Manager snap-in and click the Sites tab / Default Web Site. Pay attention to authentication in three components:

OWA - State " Switched on" for " Basic authentication" and " Windows Authentication»:

OAB - State " Switched on" for " Basic authentication" and " Windows Authentication»:

EWS - State " Switched on" for " Anonymous authentication», « Basic authentication" and " Windows Authentication»:

Interlayers (intermediaries) and auxiliary utilities

DavMail

Some email clients cannot directly connect to Microsoft Exchange and require the use of an interlayer (intermediary). In this example, a proxy server is used as an intermediary DavMail.

Install DavMail by gaining administrator rights with su or sudo:

sudo urpmi davmail

Run DavMail:

On the "Main" tab in the " OWA (Exchange) URL"Enter the address of your server in the format" https: // /EWS/Exchange.asmx "or a link to OWA

in the format "https: // / owa ".

Remember the port numbers “ Local IMAP port" and " Local SMTP port". In this example, these are 1143 and 1025, respectively.

So as not to manually start the server every time DavMail, you need to add its call to startup.

Go to the menu " System Settings -> Startup and Shutdown -> Autostart", Click the [ Add application] and enter "davmail" in the search bar, then click [ OK]:

Now local proxy DavMail will start automatically at system startup. If its icon in the "System Tray" bothers you, you can hide it. To do this, in the file .davmail.properties, edit the line davmail.server = false, changing false to true:

Sudo mcedit / home /<имя_пользователя>/.davmail.properties

Mail clients to connect to Exchange

Now you can start configuring your email clients.

Thunderbird

Mozilla thunderbird is the main email client for ROSA Linux distributions and is most likely already installed on your system and ready to go. If not, you can install it from the ROSA repositories. This example uses version 52.2.1.

Install Thunderbird:

sudo urpmi mozilla-thunderbird

Add a Russian-language interface:

sudo urpmi mozilla-thunderbird-ru

Install the lightning add-on to use calendars:

sudo urpmi mozilla-thunderbird-lightning

Run Thunderbird.

In chapter " Accounts" in point " Create an account»Select« Email". A welcome window will appear.

In the window that opens, click on the [ Skip this and use my existing mail].

In the window " Setting up a mail account"Enter in the fields" Your name», « Email address mail" and " Password»Your credentials.

Click [ Continue]. The program will try to find connections (unsuccessfully) and an error message will appear:

Here you will need the port numbers that you remembered when setting up DavMail.

For categories " Incoming" and " Outgoing"Change the server name to" localhost ".
Indicate for " IMAP"Port 1143, and for" SMTP"- port 1025.
In field " Username"Specify the UPN (User Principal Name) - the user's domain name in the format" [email protected] ".
Click on the [ Retest].

If you enter the correct credentials, there will be no errors. The system may prompt you to accept the Exchange Server certificate. If this does not happen, you may have turned off the interface too soon. DavMail.

Create a user's calendar

In the category " Accounts"Select the item" Create a new calendar».
In the window that appears, select the value " Online" and press [ Further].
Select the format " CalDAV"And in the field" The address"Enter" http: // localhost: 1080 / users / / calendar ":

Creating an address book

The address book Thunderbird does not support CardDAV and can only be connected to the Exchange Server LDAP directory.

Open existing address books by clicking the [ The address book] and selecting the item " File -> New -> LDAP Directory».

Specify the following parameters in the wizard window:
- Name- any suitable name
- Server name- localhost
- Root element (Base DN)- ou = people
- Port- 1389 (from Davmail)
- Username (Bind DN)- UPN username

Click [ OK]. The program will ask you to enter a password.

Go to the options menu Thunderbird... In the category " Drafting"Select the tab" Addressing"And under the text" When entering an address, search for suitable mailing addresses in "check the box" Directory Server”By choosing the name of your address book.

Evolution

A mail client is also available in the ROSA repositories Evolution(This example uses version 3.16.4).

Install Evolution:

sudo urpmi evolution

Install the connector Exchange compatible with version 2007 and later:

sudo urpmi evolution-ews

Run Evolution.

In the wizard window, click the [ Next] until you go to the " Account».
Fill in the fields “ Full name" and " Email».
On the tab “ Receiving mail"In the list" Server type"Select" Exchange Web Services ".
For the name, specify the user's UPN name in the format "[email protected]".
In field " Host URL"Enter" https: // MailServerNameExchange/EWS/Exchange.asmx .
In field " OAB URL»Enter the URL of the offline address book.
Select "Basic" as the type of authentication.

Upon successful configuration, the program will ask for a password:

After entering the password Evolution will get access to your mailbox, address book and calendars.

For any questions related to this article, please contact [email protected]

If you're trying to add your Outlook.com account to another email application, you might need POP, IMAP, or SMTP settings for Outlook.com. You can find them below or by following the link Set up POP and IMAP on Outlook.com.

If you want to add your Outlook.com account to a smart device, such as a camera to secure home computers, you need an app password. For more information, see Add your Outlook.com account to another email app or smart device.

POP, IMAP, and SMTP settings for Outlook.com

If you want to add your Outlook.com account to another email program that supports POP or IMAP, use the following server settings.

Notes:

IMAP server name Outlook.Office365.com

IMAP port: 993

IMAP encryption method TLS

Outlook.office365.com POP server name

POP port: 995

POP encryption method TLS

SMTP server name SMTP.Office365.com

SMTP port: 587

SMTP encryption method STARTTLS

Turn on POP access in Outlook.com

If you want to use POP to access your mail in Outlook.com, you'll need to enable it.

Change the settings of your mail provider

If you are trying to connect another account to Outlook.com using POP, you may need to change some of your email provider's settings in order to establish a connection that may have been blocked.

For Gmail accounts with POP access,.

For Yahoo POP accounts, follow the steps below.

If you are using other email providers, you should contact them for instructions to unblock the connection.

Outlook.com IMAP Connection Errors

If you've configured your Outlook.com account as IMAP on multiple email clients, you might be receiving a connection error. We are working on a fix and will update this article if we have more information. For now, try the following solution:

If you are using Outlook.com to access an account using a domain other than @live. com, @hotmail. com or @outlook. com, you won't be able to sync your IMAP accounts. To fix this issue, delete the connected IMAP account in Outlook.com and reconfigure it as a POP connection. For instructions on how to reconfigure your account to use POP, contact your email account provider.

If you're using a GoDaddy account, follow these instructions to change your GoDaddy account settings to use a POP connection. If using POP does not solve the problem, or you want to enable IMAP (disabled by default), you should contact the service

In this article, we will walk you through how to configure static RPC ports for RPC Client Access, Exchange Address Book, and Public Folder Access in Exchange 2010.

Let's say 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 Outlook client connects to the CAS server via RPC, which means that any port from the free range of ports can be used at the network level. It's no secret that in Windows Server 2008 and 2008 R2, the range 49152-65535 is used as the dynamic port range for RPC connections (in previous versions of Windows Server, RPC ports were used in the range 1025-65535).

To avoid turning firewalls into 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 can reduce memory consumption on load balancers (especially HLB) and simplify their configuration (no need to specify large port ranges).

In Exchange 2010, you can set static ports for the RPC Client Access service as well as the Exchange Address Book service. Outlook communicates with these services through the MAPI interface.

Static Port for Exchange 2010 RPC Client Access Service

The Exchange 2010 RPC Client Access virtual service is associated with the RPC Client Access service to which Outlook MAPI clients connect in Exchange 2010. When an Outlook client connects to Exchange, on Exchange 2010 Client Access, the RPC Client Access service uses the TCP End Point Mapper (TCP / 135) port and a random port from the RPC dynamic port range (6005-59530) for inbound connections

To set a static port for the RPC Client Access service in Exchange 2010, open the following key in the Registry Editor:

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ MSExchangeRPC

Create a new key named ParametersSystem inside which create a parameter of type REG_DWORD With name TCP / IP Port... The TCP / IP Port parameter specifies the static port for the RPC Client Access service. In the Microsoft documentation, it is recommended to select a port in the range 59531 - 60554, and use this value on all CAS servers (we specified port 59532, of course, it should not be used by any other software).

After the static port jobs have been completed, the Microsoft Exchange RPC Client Access service must be restarted for the changes to take effect.

Restart-Service MSExchangeRPC

Static Port for Exchange 2010 Address Book Service

In Exchange 2010 prior to SP1, a custom configuration file was used to set the static port for the Exchange 2010 Address Book service Microsoft.exchange.addressbook.service.exe.config... After the release of Exchange 2010 SP1, you can set a static port for 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. We recommend that you use any free port in the range 59531-60554 and continue to 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.

Configuring a Static Port for Connecting to Shared Folders

Shared 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 done on all servers with the Mailbox role that contain a database of public 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 parameter of type REG_DWORD named TCP / IP Port... Set its value: TCP / IP Port = 59532.

After statically setting the port for public folders, you must restart the Microsoft Exchange RPC Client Access service on each mailbox server.

Checking Static Port Usage Between Outlook and Exchange 2010

After making the changes, let's check that Outlook connects to the static RPC ports we specified. To do this, restart Outlook on the client machine, and then run the command from the command line:

Netstat -na

Applies to: Exchange Server 2010 SP1

Section was last modified: 2011-04-22

This section provides port, authentication, and encryption information for all data paths used in Microsoft Exchange Server 2010. The Notes section after each table clarifies or identifies non-standard authentication or encryption methods.

Transport servers

In Exchange 2010, there are two server roles that provide message transport functionality: Hub Transport and Edge Transport.

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			Encryption support
Between two Hub Transport servers			Yes, via TLS (Transport Layer Security)
Hub Transport to Edge Transport	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 using a certificate	Yes, using TLS
From a Mailbox server to Microsoft Exchange Mail Submission Service	NTLM. If the Hub Transport server role and the Mailbox server role are running on the same server, Kerberos is used.		Yes, using RPC encryption
Hub Transport Server to Mailbox Server via MAPI	NTLM. If the Hub Transport server role and the Mailbox server role are installed on the same server, Kerberos is used.		Yes, using RPC encryption
			Yes, using TLS
Microsoft Exchange EdgeSync service from Hub Transport server to Edge Transport server			Yes, using LDAP over SSL (LDAPS)
Accessing Active Directory from a Hub Transport server
Accessing Active Directory Rights Management Services (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

Transport Server Notes

All traffic between Hub Transport servers is encrypted using 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 authentication, Exchange 2010 uses direct trust... Direct trust means that the presence of a certificate in Active Directory or Active Directory Lightweight Directory Services (AD LDS) validates the authenticity of the certificate. Active Directory is considered a trusted storage engine. When using direct trust, it doesn't matter if you are using a self-signed certificate or a certificate signed by a certification authority. When an Edge Transport server subscribes to an Exchange organization, the Edge Subscription publishes the Edge Transport server's certificate to Active Directory so that Hub Transport servers can validate it. Microsoft Exchange EdgeSync adds a set of Hub Transport server certificates to Active Directory Lightweight Directory Services (AD LDS) for the Edge Transport server to validate.
EdgeSync uses a secure LDAP Hub Transport server connection to subscribed Edge Transport servers on TCP port 50636. AD LDS also listens on TCP port 50389. This port does not use SSL. You can use LDAP utilities to connect to this port and validate AD LDS information.
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 the inbound SMTP session to Exchange. By default, Exchange 2010 also tries to use TLS for all remote connections.
The authentication methods for traffic between Hub Transport servers and Mailbox servers are different if the Hub Transport server and Mailbox server roles are installed on the same computer. Local mail transfers use Kerberos authentication. Remote mail transmission uses NTLM authentication.
Exchange 2010 also supports domain security. Domain Security is a set of features in Exchange 2010 and Microsoft Outlook 2010 that provide a low-cost alternative to S / MIME and other solutions for securing message transmission over the Internet. Domain security provides a way to control secure communication paths between domains on the Internet. Once these secure paths are configured, messages from an authenticated sender that have successfully passed through them appear to Outlook and Outlook Web Access users as "domain-protected" messages. For more information, see Understanding Domain Security.
Many agents can run on both Hub Transport servers and Edge Transport servers. Typically, anti-spam agents use information from the local computer on which they run. Thus, virtually no interaction with remote computers is required. An exception to this is recipient filtering. Recipient filtering requires a call to AD LDS or Active Directory. We recommend that you perform recipient filtering on an Edge Transport server. In this case, the AD LDS directory is on the same computer where the Edge Transport server role is installed, so a remote connection is not required. If Recipient Filtering is installed and configured on a Hub Transport server, you must have access to Active Directory.
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 merged safelist or recipient filtering recipient data is forced to the on-premises AD LDS directory by using Microsoft Exchange EdgeSync.
Information Rights Management (IRM) agents on Hub Transport servers connect to Active Directory Rights Management Services (AD RMS) servers in your organization. Active Directory Rights Management Services (AD RMS) is a web service that is recommended to be secured with SSL. You connect to AD RMS servers using HTTPS and use Kerberos or NTLM for authentication, depending on your AD RMS server configuration.

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

Mailbox servers

On Mailbox servers, the use of NTLM or Kerberos authentication depends on the user context or process within which the Exchange Business Logic Layer consumer is running. 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 lines 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 communicate with external applications and processes.

If an Exchange Business Logic Layer consumer is running in the context of the on-premises system, Kerberos is always the authentication method for the consumer to access the Exchange store. The Kerberos authentication method is used because the recipient must be authenticated using the Local System computer account and authenticated two-way trust is required.

If the recipient of the Exchange Business Logic Layer is not running in the context of the 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 port information, authentication, and data path encryption for Mailbox servers.

Data paths for Mailbox servers

Data path	Required ports	Default authentication	Supported Authentication Method	Encryption support	Default data encryption
	389 / TCP / UDP (LDAP), 3268 / TCP (LDAP GC), 88 / TCP / UDP (Kerberos), 53 / TCP / UDP (DNS), 135 / TCP (RPC network login)			Yes, with Kerberos encryption
Administrative Remote Access (Remote Registry)				Yes, with IPsec
Administrative remote access (SMB, files)				Yes, with IPsec
Availability Web Service (Mailbox Client 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

Unified Messaging Servers

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 or Kerberos authentication. Therefore, when using IP-based authentication, the IP addresses of the connections are used as the authentication mechanism for unencrypted (TCP) connections. When used in Unified Messaging, IP-based authentication checks whether a 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 required 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 Unified Messaging servers and other servers.

Data Paths for Unified Messaging Servers

Data path	Required ports	Default authentication	Supported Authentication Method	Encryption support
Accessing Active Directory	389 / TCP / UDP (LDAP), 3268 / TCP (LDAP GC), 88 / TCP / UDP (Kerberos), 53 / TCP / UDP (DNS), 135 / TCP (RPC network login)			Yes, with Kerberos encryption
Unified Messaging Telephony (IP PBX / VoIP Gateway)	5060 / TCP, 5065 / TCP, 5067 / TCP (non-secure), 5061 / TCP, 5066 / TCP, 5068 / TCP (secure), dynamic port from 16000-17000 / TCP (control), dynamic UDP ports from the range 1024-65535 / UDP (RTP)	By IP address	By IP address, MTLS	Yes, via SIP / TLS, SRTP
Unified Messaging 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
Unified Messaging Server to Client Access Server (Play 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 determine the IP address of the physical IP gateway or IP PBX. When you determine the IP address of a UM IP gateway object, the IP address is added to the list of valid IP gateways or IP PBXs (also called SIP Session Participants) that the UM server is allowed to communicate with. After you create a UM IP gateway, you can associate it with the UM dial plan. Mapping a UM IP gateway to a dial plan enables UM servers that are mapped to a dial plan to use IP address-based authentication to communicate with the IP gateway. If a UM IP gateway was not created or configured to use the correct IP address, authentication will fail and UM servers will not accept connections from the IP address of that IP gateway. In addition, when implementing 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 with an FQDN, you must also add a host record for that gateway to the forward DNS lookup zone.
In Exchange 2010, the Unified Messaging server can communicate over port 5060 / TCP (unsecured) or over port 5061 / TCP (secured), and it can be configured to use both ports.

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

Windows Firewall Rules Created by Exchange 2010 Setup

Windows Firewall with Advanced Security is a computer-based stateful 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-client communication in each server role. Therefore, you no longer need to use the Security Configuration Wizard to configure these settings. For more information on Windows Firewall with Advanced Security, see Windows Firewall with Advanced Security and IPsec.

The following table lists the Windows firewall rules generated by Exchange Setup, including the ports that are open in 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 Inbound)	Client Access Server	5075, 5076, 5077 (TCP)	Inetsrv \ w3wp.exe
MSExchangeAB RPC (TCP Inbound)	Client Access Server	Dynamic RPC
MSExchangeAB-RPCEPMap (TCP Inbound)	Client Access Server		Bin \ Microsoft.Exchange.AddressBook.Service.exe
MSExchangeAB-RpcHttp (TCP Inbound)	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 Inbound)	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 Inbound)	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, Edge Transport, Mailbox server		Bin \ MSExchangeTransportLogSearch.exe
SESWorker (GFW) (TCP Inbound)	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 Internet Information Services installed, Windows opens the 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 lets you specify the process or service to which the 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 reasons, an additional rule is also created that is not limited to this process. You can disable or remove non-process-restricted rules and save the corresponding process-restricted rules if your current deployment environment supports them. Rules that are not limited 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 RPCs connect to the RPC endpoint mapper to retrieve 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 RPC, Exchange 2010 Setup creates two firewall rules for that process. One rule allows communication with the RPC endpoint mapper, and the second allows communication with a dynamically assigned endpoint. For more information on remote procedure calls, see the article. For more information on how to create Windows Firewall rules for dynamic RPC, see the article.
For more information, see Microsoft Knowledge Base Article 179442

Exchange Server and firewalls

Firewalls for mail servers (Exchange Server), ports for mail servers, front-end and back-end mail servers, virtual servers SMTP, POP3, IMAP4

As with any computer connected to the Internet, the computer hosting 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 easiest option is to install a mail server on a computer that is also a proxy server / firewall, and then open the necessary ports on the interface facing the Internet. This is usually the case for small organizations;

· Another option is to install a mail server in the local network and configure it to work through a proxy server. To do this, you can bind a public ip to the mail server and pass it through the proxy, or use tools such as port mapping 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 put a front-end Exchange Server in it (this 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, for the mail server, it is necessary to ensure communication at least on the TCP 25 (SMTP) and UDP 53 (DNS) ports. Other ports that may be required by Exchange Server depending on your network configuration (all are TCP):

80 HTTP - for access to the Web interface (OWA)

· 88 Kerberos authentication protocol — if Kerberos authentication is used (rarely);

· 102 MTA .X .400 connector over TCP / IP (if the 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 administration of Exchange using standard System Manager tools;

· 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 secured over SSL.

563 NNTP (SSL)

636 LDAP (SSL)

993 IMAP4 (SSL)

995 POP3 (SSL)

· 3268 and 3269 - queries to the global catalog server (search in Active Directory and check membership in universal groups).

It makes no sense to cover the Exchange Server interface facing the inside of the organization with a firewall - it will be used to interact with domain controllers, administration utilities, backup systems, etc. For an interface open to the Internet, it is recommended to leave ports 53 (if Exchange will resolve hostnames itself, rather than redirecting requests to the local DNS server) and 25. Very often, customers need to access their mailboxes from the outside (from home, during a business trip, and etc.). The best solution in this situation is to configure OWA (the default Web interface for access to Exchange Server, available at http: // servername / exchange) to work over SSL and open access only on port 443. In addition to resolving issues with secure authentication and encryption of messages automatically resolves the issue of SMTP Relay (more on that later) and the situation when a user accidentally downloads work email to the mail client folders on his home computer, and then at work cannot find these messages (not to mention storing work mail at home is a security breach).

New feature introduced in Exchange Server. starting from version 2000, the ability to use multiple virtual SMTP and POP3 servers with different security settings. For example, the SMTP server that interacts with the Internet can be configured with heightened security and strict delivery restrictions, and the SMTP server used by users within the organization can be configured to the highest performing and user-friendly settings.

It is also necessary to mention a certain confusion in terminology - very often message filtering systems are called firewalls for Exchange, which will be discussed below.