Forum Discussion
Centralized mail transport and sending outgoing messages directly from EXO
Hello,
You can use Rule Based send connectors but in order to implement your migration incrementally you would need to do something similar to this.
1. Create a send connector that will route email to your on-premises exchange and configure the Use of connector to "Only when I have a transport rule setup that redirects message to this connector"
2. Create a transport rule that scopes the messages that you want to have sent to your On-Premises Exchange. For example: you could configure the rule to only use this connector when the messages have an external destination address domain.
3. Disable Centralized Mail Routing. You have to do this or the centralized mail routing configuration will continue to send all of your mail to on-premises via your default Hybrid Connector.
Note:- Once enabled, Exchange Online will send all outbound mail to the on-premises environment first, even if there is a matching send connector in Exchange Online that could handle the mail directly.
- The on-premises Exchange then routes the mail to its final destination, whether that’s an external recipient or another internal mailbox.
So be aware that this is not a "non-change" from a routing perspective. Mail sent between two of your recipients will no longer be sent to on-premises exchange first and then routed back to you Exchange Online. It will go directly to the recipient. You will notice this if you look at your transport logs Exchange on premises or message traces in your Exchange Online Tenant.
At this point your outbound mail will still be routed to your on-premises service but will do so based on the Mail Flow rule and the new connector you have setup.
Now you can start modifying the mail flow rule to implement your roll out. For example you could add a " Except If" clause to your transport rule and include specific senders or members of a group in that Except clause.
Doing so would cause their mail to be sent from Microsoft default sending connector. (this is not visible but its always there).
This how we implemented this change in our Hybrid Exchange Environment.
William_Holmes Dan_Snape , thank you for your responses.
We have all mailboxes in the cloud, full migration from on-prem was done some time ago, but we have still the hybrid/centralized mail flow in action. Emails sent from my M365 mailbox to Gmail for example, goes this path:
EXO --> Exchange on-prem --> 3rd-party on-prem gateway --> Internet.
As we want to decomm the on-prem infrastructure, the goal is to move to the "direct" routing, means:
EXO --> Internet.
The trick with connector sounds interesting. To fully clarify it - mail flow is controlled via the default "your organization" type connector, created by Hybrid Configuration Wizard in the past. This connector is set to send all emails (domains = *) to our on-prem Exchange. I could in theory change use of this connector to "Only when I have a transport rule set up..." and play with Transport Rule, for example by creating a rule like this:
Sender: external
Do the following: use the default connector
Except if: sender belongs to a group
If I understand correctly, emails from these excluded users, as they are not in the scope of any connector, are routed directly to the outside - is this correct way of thinking?
Best Regards
Marcin
Hello,
You can use Rule Based send connectors but in order to implement your migration incrementally you would need to do something similar to this.
1. Create a send connector that will route email to your on-premises exchange and configure the Use of connector to "Only when I have a transport rule setup that redirects message to this connector"
2. Create a transport rule that scopes the messages that you want to have sent to your On-Premises Exchange. For example: you could configure the rule to only use this connector when the messages have an external destination address domain.
3. Disable Centralized Mail Routing. You have to do this or the centralized mail routing configuration will continue to send all of your mail to on-premises via your default Hybrid Connector.
Note:- Once enabled, Exchange Online will send all outbound mail to the on-premises environment first, even if there is a matching send connector in Exchange Online that could handle the mail directly.
- The on-premises Exchange then routes the mail to its final destination, whether that’s an external recipient or another internal mailbox.
So be aware that this is not a "non-change" from a routing perspective. Mail sent between two of your recipients will no longer be sent to on-premises exchange first and then routed back to you Exchange Online. It will go directly to the recipient. You will notice this if you look at your transport logs Exchange on premises or message traces in your Exchange Online Tenant.
At this point your outbound mail will still be routed to your on-premises service but will do so based on the Mail Flow rule and the new connector you have setup.
Now you can start modifying the mail flow rule to implement your roll out. For example you could add a " Except If" clause to your transport rule and include specific senders or members of a group in that Except clause.
Doing so would cause their mail to be sent from Microsoft default sending connector. (this is not visible but its always there).
This how we implemented this change in our Hybrid Exchange Environment.Thanks for the reply - it sounds reasonable and we'll take this path probably.
Regarding this step: 1. Create a send connector that will route email to your on-premises exchange - such connector exists already, created automatically in the past, when HCW was running. So we have to just switch its mode, so it's activated by a Transport Rule.
Best Regards
Marcin
Hello Marcin K.
I would not modify the hybrid connector; I would create a new one that was rules based. Connectors essentially from the most specific to the least specific. I tend to make incremental changes and then confirm the expected changes in the logs. It is easier to back changes out using this process, should something go wrong.
In step one it is permissible to have two parallel connectors. The only issue with this is Microsoft's verification might fail if you set up something ambiguous because the test mails may not use the connector you are testing.However, with a rules-based connector there is not any ambiguity because the rules evaluation precedes the routing steps. The rule will unambiguously pick your rules based connector.