In Exchange 2013, I am utilizing a multi-role server that has both
the Client Access Server and Mailbox Server roles. We’ll want to head to
the mail flow section in the Exchange Administration Center (EAC) that
you can access by going to https://OWA.domain.com/ECP.
Once in this mail flow section, we’ll click the tab called receive connectors which will allow us to see all receive connectors that exist.
As you can see, there are connectors for FrontendTransport and connectors for HubTransport. FrontEndTransport belongs to the Client Access Server Role and the HubTransport role belongs to the Mailbox Server role.
Let’s take a look at the “Default B-E15DAG1″ receive connector that belongs to the HubTransport role as well as the “Default Frontend B-E15DAG1″ that belongs to the FrontendTransport role.
Taking a look at the “Default FrontEnd B-E15DAG1″, we can see that the connector listens on port 25 as we would expect.
Taking a look at the “Default B-E15DAG1″ receive connector, we can see it listens on port 2525 which is something we haven’t seen before.
All mail flow should come into the Frontend Transport which then delivers it to the appropriate mailbox server where the mailboxes exist. On a multi-role server, these two roles cannot utilize the same ports as they are two different services. What this means is, when creating a relay connector, this connector must be created on the Client Access Server role that owns the Frontend Transport because this service is the service that owns port 25. If you try to create a receive connector on the Mailbox Server role that owns the HubTransport service, mail flow may work temporarily, but it will eventually fail due to both the FrontendTransport and HubTransport services fighting each other for port 25. Obviously if the Client Access Server and Mailbox Server roles are on different servers, it’s not an issue.
To create our relay connector, we’ll choose the + symbol to create a new Receive Connector.
Give the connector a name and be sure to choose Frontend Transport and Custom. Click Next.
The default settings here are fine. We want port 25 due to what I mentioned above. Click Next.
In the remote network settings, it is important to ensure that you remove 0.0.0.0-255.255.255.255. We want to explicitly define what servers are allowed to relay to ensure our server does not turn into an open relay for everybody. In my case, I am going to add 192.168.50.2 which may be a printer, custom application, etc… But the server that owns 192.168.50.2 would need to relay. Once this is done, click Finish.
Once the relay connector is created, open its properties, go to security, and make sure you check Anonymous Users.
So what really happens when you place a check mark in the Anonymous users group in the above screenshot? A lot of people are afraid to place a checkmark in that box in fear that anonymous users will be able to relay off your Exchange Server. This is NOT the case.
When you place a checkmark in that box, the following permissions are given to the Anonymous Logon group:
To activate Anonymous users to use this connector for relaying, you must issue the following command: Get-ReceiveConnector “Receive Connector Name” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”
The command should be easy enough to read, but what it essentially does is retrieve the receive connector that you created, add a permission into Active Directory for the Anonymous Logon group, and assign that group the Ms-Exch-SMTP-Accept-Any-Recipient permission for that group on that connector. Once this is done, any server IPs you added to the Remote Network settings will be allowed to relay off your server utilizing port 25.
Now you may be thinking, why should I create this new connector? Well, Exchange will always look to see how specific you are on a connector. So let’s say we have a SharePoint Server at 192.168.119.150. We would create a relay connector and allow ONLY 192.168.119.150 to relay. So when Exchange receives SMTP from an address of 192.168.119.150, it will see there are a few connectors. One being the Default Receive Connector and one being the Relay Connector. The Default Receive Connector allows connections from any IP Address while the Relay Connector only allows connections from 192.168.119.150. Because you explicitly set the address on your Relay Connector, that is given higher preference in serving that SMTP connection from SharePoint and your SharePoint Server will now be able to relay off of Exchange (even though you can configure SharePoint to authenticate, but still just giving an example).
Now, for servers that will have a lot of relay traffic, there are some more steps you need to do on your Receive Connector. If you see that you have mail flow issues where things periodically work with relaying and sometimes they don’t, it’s recommended to run the following commands on your Relay Connector.
Set-ReceiveConnector -identity “Relay Connector Name” -TarpitInterval 00:00:00
Set-ReceiveConnector -identity “Relay Connector Name” -ConnectionTimeout 00:30:00
Set-ReceiveConnector -identity “Relay Connector Name” -ConnectionInactivityTimeout 00:20:00
Set-ReceiveConnector -identity “Relay Connector Name” -MaxAcknowledgementDelay 00:00:00
Set-ReceiveConnector -identity “Relay Connector Name” -MaxInboundConnection 10000
Set-ReceiveConnector -identity “Relay Connector Name” -MaxInboundConnectionPercentagePerSource 100
Set-ReceiveConnector -identity “Relay Connector Name” -MaxInboundConnectionPerSource unlimited
So in my case, I would run the following command which would allow me to do Get-ReceiveConnector and pipe into Set-ReceiveConnector to make all the modifications in one command:
Get-ReceiveConnector -Identity “Relay Connector Name” | Set-ReceiveConnector -TarpitInterval 00:00:00 -ConnectionTimeout 00:30:00 -ConnectionInactivityTimeout 00:20:00 -MaxAcknowledgementDelay 00:00:00 -MaxInboundConnection 10000 -MaxInboundConnectionPercentagePerSource 100 -MaxInboundConnectionPerSource unlimited
If you are wondering what the default settings were, I ran the following to view the defaults before running Set-ReceiveConnector.
Once in this mail flow section, we’ll click the tab called receive connectors which will allow us to see all receive connectors that exist.
As you can see, there are connectors for FrontendTransport and connectors for HubTransport. FrontEndTransport belongs to the Client Access Server Role and the HubTransport role belongs to the Mailbox Server role.
Let’s take a look at the “Default B-E15DAG1″ receive connector that belongs to the HubTransport role as well as the “Default Frontend B-E15DAG1″ that belongs to the FrontendTransport role.
Taking a look at the “Default FrontEnd B-E15DAG1″, we can see that the connector listens on port 25 as we would expect.
Taking a look at the “Default B-E15DAG1″ receive connector, we can see it listens on port 2525 which is something we haven’t seen before.
All mail flow should come into the Frontend Transport which then delivers it to the appropriate mailbox server where the mailboxes exist. On a multi-role server, these two roles cannot utilize the same ports as they are two different services. What this means is, when creating a relay connector, this connector must be created on the Client Access Server role that owns the Frontend Transport because this service is the service that owns port 25. If you try to create a receive connector on the Mailbox Server role that owns the HubTransport service, mail flow may work temporarily, but it will eventually fail due to both the FrontendTransport and HubTransport services fighting each other for port 25. Obviously if the Client Access Server and Mailbox Server roles are on different servers, it’s not an issue.
To create our relay connector, we’ll choose the + symbol to create a new Receive Connector.
Give the connector a name and be sure to choose Frontend Transport and Custom. Click Next.
The default settings here are fine. We want port 25 due to what I mentioned above. Click Next.
In the remote network settings, it is important to ensure that you remove 0.0.0.0-255.255.255.255. We want to explicitly define what servers are allowed to relay to ensure our server does not turn into an open relay for everybody. In my case, I am going to add 192.168.50.2 which may be a printer, custom application, etc… But the server that owns 192.168.50.2 would need to relay. Once this is done, click Finish.
Once the relay connector is created, open its properties, go to security, and make sure you check Anonymous Users.
So what really happens when you place a check mark in the Anonymous users group in the above screenshot? A lot of people are afraid to place a checkmark in that box in fear that anonymous users will be able to relay off your Exchange Server. This is NOT the case.
When you place a checkmark in that box, the following permissions are given to the Anonymous Logon group:
- Ms-Exch-SMTP-Submit
- Ms-Exch-SMTP-Accept-Any-Sender
- Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender
- Ms-Exch-Accept-Headers-Routing
To activate Anonymous users to use this connector for relaying, you must issue the following command: Get-ReceiveConnector “Receive Connector Name” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”
The command should be easy enough to read, but what it essentially does is retrieve the receive connector that you created, add a permission into Active Directory for the Anonymous Logon group, and assign that group the Ms-Exch-SMTP-Accept-Any-Recipient permission for that group on that connector. Once this is done, any server IPs you added to the Remote Network settings will be allowed to relay off your server utilizing port 25.
Now you may be thinking, why should I create this new connector? Well, Exchange will always look to see how specific you are on a connector. So let’s say we have a SharePoint Server at 192.168.119.150. We would create a relay connector and allow ONLY 192.168.119.150 to relay. So when Exchange receives SMTP from an address of 192.168.119.150, it will see there are a few connectors. One being the Default Receive Connector and one being the Relay Connector. The Default Receive Connector allows connections from any IP Address while the Relay Connector only allows connections from 192.168.119.150. Because you explicitly set the address on your Relay Connector, that is given higher preference in serving that SMTP connection from SharePoint and your SharePoint Server will now be able to relay off of Exchange (even though you can configure SharePoint to authenticate, but still just giving an example).
Now, for servers that will have a lot of relay traffic, there are some more steps you need to do on your Receive Connector. If you see that you have mail flow issues where things periodically work with relaying and sometimes they don’t, it’s recommended to run the following commands on your Relay Connector.
Set-ReceiveConnector -identity “Relay Connector Name” -TarpitInterval 00:00:00
Set-ReceiveConnector -identity “Relay Connector Name” -ConnectionTimeout 00:30:00
Set-ReceiveConnector -identity “Relay Connector Name” -ConnectionInactivityTimeout 00:20:00
Set-ReceiveConnector -identity “Relay Connector Name” -MaxAcknowledgementDelay 00:00:00
Set-ReceiveConnector -identity “Relay Connector Name” -MaxInboundConnection 10000
Set-ReceiveConnector -identity “Relay Connector Name” -MaxInboundConnectionPercentagePerSource 100
Set-ReceiveConnector -identity “Relay Connector Name” -MaxInboundConnectionPerSource unlimited
So in my case, I would run the following command which would allow me to do Get-ReceiveConnector and pipe into Set-ReceiveConnector to make all the modifications in one command:
Get-ReceiveConnector -Identity “Relay Connector Name” | Set-ReceiveConnector -TarpitInterval 00:00:00 -ConnectionTimeout 00:30:00 -ConnectionInactivityTimeout 00:20:00 -MaxAcknowledgementDelay 00:00:00 -MaxInboundConnection 10000 -MaxInboundConnectionPercentagePerSource 100 -MaxInboundConnectionPerSource unlimited
If you are wondering what the default settings were, I ran the following to view the defaults before running Set-ReceiveConnector.
No comments:
Post a Comment