When upgrading Exchange 20013 to Service Pack 1, if you have servers running both back-end and front-end roles and you run the front-end Microsoft Exchange Transport service on the server, you might experience the Microsoft Exchange Transport stopping and not restarting.
If you stop the Microsoft Exchange Transport service, you can start the front-end Microsoft Exchange Transport service. Then, when you try to start the Microsoft Exchange Transport service, that service does not start and the following events are logged in the Application log:
Source: MSExchangeTransport
Event ID: 1019
Task Category: SmtpReceive
Level: Error
Description: Failed to start listening (Error: 10048). Binding: 0.0.0.0:25.
Source: MSExchangeTransport
Event ID: 1018
Task Category: SmtpReceive
Level: Error
Description: The address is already in use. Binding: 0.0.0.0:25.
Source: MSExchangeTransport
Event ID: 1036
Task Category: SmtpReceive
Level: Error
Description: Inbound direct trust authentication failed for certificate %1. The source IP address of the server that tried to authenticate to Microsoft Exchange is [%2]. Make sure EdgeSync is running properly.
Source: MSExchange Common
Event ID: 4999
Task Category: General
Level: Error
Description: Watson report about to be sent for process id: 19848, with parameters: E12IIS, c-RTL-AMD64, 15.00.0847.032, MSExchangeTransport, M.Exchange.Net, M.E.P.WorkerProcessManager.HandleWorkerExited, M.E.ProcessManager.WorkerProcessRequestedAbnormalTerminationException, 5e2b, 15.00.0847.030. ErrorReportingEnabled: False
Source: MSExchange TransportService
Event ID: 1046
Task Category: ProcessManager
Level: Warning
Description: Worker process with process ID 18420 requested the service to terminate with an unhandled exception.
This issue occurs if there is a receive connector of Transport type HubTransport that has the binding set to port 25 on the affected Exchange 2013 server. On an Exchange 2013 server that has both back-end and front-end roles, only the FrontendTransport server-type receive connector should have the binding set to port 25.
To fix this issue, run the following cmdlet to change the connector type from HubTransport to FrontendTransport:
Set-ReceiveConnector –Identity "Receive connector name" –TransportRole FrontendTransport
Alternatively, delete and re-create the receive connector and set its role to FrontendTransport.
I had this issue with a client’s server, the internal IT team installed a new connector to relay for an app on another server.
Since the new connector defaults to Hub Transport (surely this should default to Frontend Transport) they created the new connector – mail flowed normally for the default connector until a reboot.
The new connector then seized the 0.0.0.0:25 & stopped inbound mail flow.