Office 365 – Distribution List Migration Version 2.0 – Part 16

Mail flow issues with centralized mail transport enabled and migrated distribution groups.

When establishing a hybrid installation with Exchange Online administrators could enable centralized mail flow. For information on routing scenarios and centralized mail transport please see the following – Transport routing in Exchange hybrid deployments | Microsoft Docs.

 

When migrating distribution groups to Office 365 having centralized mail transport enabled may result in messages to internal users appearing to come from external. In order for this to happen the messages must have originated from the on-premises organization originally and one or more recipients must still reside in the on-premises organization.

 

Let us examine a sample scenario where this may apply.

 

• A distribution list is migrated to Exchange Online.
• A device on-premises is configured to relay email through the on-premises organization.
• A user scans a document on the device and addresses it to the migrated distribution list.
• The on-premises Exchange organization receives the email and matches it to the dynamic distribution group for the migrated distribution list.
• The dynamic distribution group is expanded to the single recipient mail contact for the migrated distribution list.
• The mail contact has a target address matching a connector (mail.onmicrosoft.com) and the email is sent to Office 365 through the hybrid connector.
• The email reaches Office 365 where the mail.onmicrosoft.com address is matched to the migrated distribution group.
• The migrated distribution group is expanded and on-premises mailboxes are members of the group.
• Exchange Online delivers the messages to Office 365 mailboxes.
• Exchange Online sends the messages to the on-premises mailboxes via MX based routing.
• The public MX record refers to the on-premises Exchange organization.
• A transport rule in the on-premises Exchange organization marks the messages with subject EXTERNAL.
• The messages are delivered to the on-premises mailboxes.

 

In this instance Exchange Online routed the messages as if they were destined for the internet even if they were destined for an internal domain. It would appear on the surface as if the connectors or centralized routing was bypassed. This is by design. The original message originated through the on-premises organization already. In normal distribution list terms, the on-premises recipients would have been included in the on-premises expansion and the message delivered. In this case they were not since the expansion occurred in Office 365. The message had already traversed the on-premises organization therefore transport does not send it back down the hybrid connector but rather uses MX based routing to deliver the messages. This is a side effect of migrating distribution groups with centralized mail transport enabled.

 

Are there any creative workarounds to ensuring that this does not happen? Honestly after spending several days trying transport rules with this or that I simply did not come up with a solution that worked. The transport rules generally fired after addresses were reviewed or expansion was preformed which eliminated a lot of the predicates that would be required to make this work. There was not, in my opinion, a satisfactory combination of rules that allowed this to work as expected. For many customers this is not an issue as most if not all of their mailboxes have been migrated to Exchange Online. For some other questions they had no idea why they had centralized mail transport enabled and it was not necessary. Disabling centralized mail transport is certainly a good way to deal with this.

 

What I did do is add an additional switch to the migration command to call this scenario out. There is new code in updated modules which pulls all outbound connectors from Exchange Online. If any connector is found to have the RouteAllMessagesViaOnPremsies set to TRUE, the migration will fail unless the -overrideCentralizedMailTransportEnabled switch is specified and set to $TRUE. This is not necessarily a fix but is a logged acknowledgement that centralized mail transport is present and that it could have unattended mail flow side effects depending on the distribution lists being migrated.