Exchange 2013 transport role won’t start unless custom receive connector is disabled

exchange-2013windows-server-2012-r2

We have one Exchange 2013 server (EX13 – Exchange 2013 SP1 on Win2012R2). CAS and MBX roles installed. When I start the server up, the Microsoft Exchange Transport service does not start. I figured out that if I disable my custom “Receive Connector” that allows internal devices to relay mail off the server, then the service will start. The receive connector shows up in EAC with Role as HubTransport. If you look at the properties of the receive connector, on the security section the only box in the Authentication area that is checked is TLS. In Permission Groups only Anonymous users is checked. If you go to the scoping section, in the first box are all of the IP Addresses of the devices that relay off the server, and the bottom box (Network adapter bindings) is one default entry of “(All available IPv4) Port 25”).

Also in “Receive Connectors” there are 5 other default connectors that I did not add. They are:

Client Frontend EX13 (FrontendTransport) – bound to port 587

Client Proxy EX13 (HubTransport) – bound to port 465

Default Frontend EX13 (FrontendTransport) – bound to port 25

Default EX13 (HubTransport) – bound to port 2525

Outbound Proxy Frontend EX13 (Frontend Transport) – bound to port 717

My suspicion is the “Default Frontend EX13” receive connector is causing the problem because it is also bound to port 25. This is further supported by the fact that I can also start the Microsoft Exchange Transport service if I first stop the Microsoft Exchange Frontend Transport service, as if they are arguing over who gets port 25! Do I even need the Default Frontend EX13 receive connector? Why is it there? I am doing my best to try and wrap my head around all of this, so if someone could explain the differences between all of these connectors I would greatly appreciate it!

Best Answer

Exchange needs to be able to select ONE receive connector for every incoming connection.

It checks two parameters for the incoming connection:

  1. The IP port number the connection is trying to reach. And

  2. The IP address the connection is coming from.

In order for the transport to run correctly you need to ensure that no two connectors conflict on those two parameters.

So in your case the "Default Frontend" connector is already bound to (port 25 AND any address) and now you add another custom receive connector bound to (port 25 and some specific addresses). These two conflict because for the specific addresses they would both want to be responsible and that causes your problem with the transport service.

Solution: Please exclude the specific addresses that you configured in your custom receive connector from the Default Frontend connector scoping.

Related Topic