Friday, October 10, 2014

Multi Organization O365 migrations - SMTP routing and Criteria Based Routing

When migrating three disparate email organizations into a single Office 365 tenant, one of the major hurdles in this was ensuring that once we have the first organization ( migrated, the tenant is essentially in production, and while we are planning on turning up and licensing users for the next organization (, we realized the problems this would cause.

The second organization is large.  Very large.  So we need to pre-stage data into mailboxes that could take days or even weeks.

The SMTP routing issue presented
If users from were to attempt to email, the messages would deliver to their mailbox in the tenant.   The same will be true when and are in production and is pre-staging

We considered blanking out the mail attribute in AD to avoid this and just pre-stage to their tenant email address ( but too many other AD integrated applications relied on that field so that was not an option.

We began looking around in DirSync filtering for ways to blank the mail attribute by pairing it to an unused AD attribute in Active Directory.  This is NOT AT ALL recommended.

Microsoft does not support modification or operation of the Directory Sync tool outside of those actions formally documented.  The actions documented below in this article are supported. 
Unsupported actions include:
    • Opening the underlying FIM Sync Engine to modify Connector configuration  
    • Manually controlling the frequency and/or ordering of Synchronization Run Profiles or changing the attributes that are synchronized to the cloud. 
Any of these actions may result in an inconsistent or unsupported state of the Directory Sync tool and as a result, Microsoft cannot provide technical support for such deployments / usage of the tool.
Filtering configurations applied to your directory synchronization instance aren’t saved when you install or upgrade to a newer version. If you are upgrading to a newer version of directory synchronization, you must re-apply filtering configurations after you upgrade, but before you run the first synchronization cycle.

That seems like very clear and strong language.  It's not supported, and if you change anything it might also break if and when you patch DirSync.

So without putting the customer in an unsupported space, how can we address the presenting mail routing issue? 

Enter Criteria Based Routing!

Two basic steps here:

  1. Create an Outbound Connector for the domain
    1. On the Delivery section, specify "Route mail through smart hosts" and manually enter the existing MX records for the domain
    2. On the "Scope" section, select "Use for Criteria Based Routing (CBR)"
  2. Create a Transport Rule
    1. Apply this rule if: The recipient is.. located inside the organization
    2. And: A recipient's domain is..
    3. Use the following outbound connector.. Select the connector created in Step 1

That's it.  Now you can license mailboxes with their correct SMTP addresses, pre-stage data, and they will NOT receive any SMTP traffic until you disable or remove the connector and the rule.  Which in addition is a much easier cutover day task than to be changing users or DirSync configurations en masse.

Hope this helps you, please post if it does!

Update 3/30/2015
This procedure only works if the domain name you are configuring the rule for is in the mailbox's PRIMARY SMTP address.   If it is a secondary SMTP address, the rule won't fire, as when someone checks names, it will default to their primary.


TechnoMusic said...

So how does this work when you start flipping mailboxes over to o365 i.e. this method seems either on/off for all If had 10000 mailboxes I presume it is not going to be possible to flip these over a weekend especially if they are spread across time zones... therefore the flip over from on-premise to O365 would need to be done in bunches.
The only way we saw of achieving this was to create a connector in o365 for that sent mail for custom address i.e to on-premise mailboxes. Then as we created a pre-staged mailbox we applied a forwardersmtp address to each mailbox to forward to on-premise for each mailbox which then used the connector. Then wehen it came to doing the incremental transfer and flipping users over to O365 we simply removed the o365 forwarder for each mailbox. This avoided us having to use the big bang approach.

Chris Lehr said...

TechnoMusic: When doing a very large organization there are two issues. First, the time to get all data in. Second, depending on requirements, having the "being loaded" users in the address book may or may not be desirable. With the CBR in this blog, they were in the AB, but routed to their current mail servers.

I tend to try and avoid tricky mail routing because the end user expectation for other things to work complicates things (free busy/sharing, etc)