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.
Nice article, thanks for sharing.
ReplyDeleteMoving To Sydney | Moving To New York
I worked on getting my receive connector to work for many hours. I was having the same issues you mentioned. Restarting the transport service did not fix my issue though. I decided to use your method even though my two custom connectors needed to use 587 and 25. These connectors worked once I applied the powershell command to the connector after setting it up in the ECP. I combined both connectors to use 587 and didnt mess with the connector that uses 25.
ReplyDeleteThank you for the workaround. It fixed my issue and fixed my headache as well. Hopefully MS can fix their product so this is not necessary eventually.
Problem is that the receive connector wizard defaults to hubtransport instead of frontend transport. Haven't tried this with the just reelased CU2 though.
ReplyDeleteWould you recommend changing the relay connectors to the default hub transport setup after installing the CU2?
ReplyDeleteHave played with these thing for a while. upgraded system to CU2 , fresh install of CU2 but it always works best when you create your receiveconnector tied to the frontend transport service. So I would not use the HUB/backend transport for receiveconnectors.
ReplyDeleteHi!
ReplyDeleteI've setup a new "internet receive connector", that's basically a TLS on annonymous over port 25, thats it. Restarting Transport service makes the server accepting mail from outside again, but in a couple of hours it stops working.
I'm not really sure what connector of the original default ones should be disabled or deleted.
The Default Frontend seems to be the logical choice, but will it be needed for any other services?
/Janne
Your problem looks very much like the one mentioned in the blog.
Deletewhen you created the new receiveconnector, did you connect it to Frontend transport ? this is what you should do.
Yes I did connect it to the frontend transport.
ReplyDeleteI also set the default frontend connector to disabled, and since that It has been alive as it should. Not sure if this will get me any other trouble later on since it seems the default frontend has some other settings, that the new internet receive frontend don't.
If needed to disable the default frontend receive connector to get it working, you probably had some conflicting settings between it and your new receive connector. Have you specified correct remote IP ranges for your receive connector?
ReplyDeleteAnd yes, most likely there are configuration differences in security between the receive connectors.