0

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!

Rich701
  • 163
  • 1
  • 1
  • 8
  • There is an event in the Application log MSExchangeTransport - 1019 - SmtpReceive - Failed to start listening (Error: 10048). Binding: 0.0.0.0:25. – Rich701 Oct 07 '14 at 19:00

3 Answers3

0

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.

Claus Christensen
  • 156
  • 3
0

So I ended up solving this myself. The problem was the “Default Frontend (FrontendTransport) is assigned to the CAS role while the custom receive connector I created was assigned to the MBX role (HubTransport). The services were fighting over port 25. You CAN have multiple receive connectors bound to port 25, but they need to be assigned to the same role.

My solution was to export the ip addresses on the custom connector I created on the HubTransport role, then delete it. I recreate a new receive connector and choose the Frontend Transport in the Role section, then used EMS to add the ip addresses I exported into it. Problem solved.

*I referenced this article to help with exporting the ip addresses out of the custom connector I had created so I didn't have to add them all back in manually (I had about 30).

http://terenceluk.blogspot.com/2010/11/how-do-i-exportimport-exchange-20072010.html

Thanks for the help!

Rich701
  • 163
  • 1
  • 1
  • 8
0

I had the same problem here at the hospital, but a different solution.

We have two web server front end machines for a patient portal at my hospital. I needed to set up a relay receive connector for those interfaces. After I did it, the Microsoft Exchange Transport service would not start.

I tried what Rich701 suggested as a solution, however it still didn't work for me. The Microsoft Exchange Transport service would not start.

Taking a cue from his original post:

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!

I set the Microsoft Exchange Frontend Transport service to "automatic-delayed" in the service properties. Voila! The Microsoft Exchange Transport service, AND the Microsoft Exchange Frontend Transport service don't argue anymore. The Exchange Server 2013 services are back up.

Lætitia
  • 2,085
  • 22
  • 33
Longrider
  • 1
  • 1
  • I'm curious, after a few weeks, did this solution still hold up for you? I'm only asking because for my issue (I need to put my way back hat on to try and remember my work on this) i think i tried something like your solution. It worked, but only for a few minutes... – Rich701 Sep 09 '16 at 17:10
  • 1
    Yes it is still working. – Longrider Sep 12 '16 at 14:25