Scenario: Exchange 2013 server with both mailbox and client access role combined.
You create a receive connector and scope it down to some specific IP addresses for applications running on servers with the specified IP. You configure to allow anonymous relay on the connector.
Applications on server are happy since they can now anonymously submit and relay messages off your Exchange installation to Internet.
Suddenly after a few hours, applications cannot send and relay mail.
Luckily you have protocol logging enabled and discover that your newly created connector is not used anymore. some more troubleshooting later and you desperately restart Exchange transport service. After the restart mail flow is restored the way you want.
But again after some hours, mail flow stops. further investigation shows that exactly the same thing has happened again, another restart of Exchange transport get things going.
Solution: Restart the transport service with a few hours interval, nahh don’t think so. Exchange 2013 is brand new and should work, and before the migration you had the exact configuration with Exchange 2010 server.
Real solution: I very simple. remove the old receive connector and create a new one, but connect it against the frontend transport instead of the default Hub transport (backend).
Transport system has been running fine as it should for a couple of weeks now. I believe this is a bug in the transport service and the symptom is selecting the wrong receive connector when there is an incoming connection to Exchange.
It makes sense to connect receive connectors and possibly send connectors against frontend (CAS server) but I think it should work equally fine if you select the backend (mailbox server) especially when the backend is the default option when using Exchange Admin Center.
