Freigeben über

Configure Coexistence Mail Routing without a Secondary Routing Domain

  • Artikel

Recently, I had to work with a customer whose existing mail host was (surprise) not excited to configure a secondary domain for us to help migrate out of the hosted environment.

To give a little background, when we configure a traditional hybrid environment (I love using those terms together), we are configuring two disparate environments to share a single address space.  We do this by adding the namespace of the Office 365 tenant as a secondary name space (tenant.mail.onmicrosoft.com) to the on-premises Email Address Policy.Then, when a mailbox gets moved from on-premises to the cloud, the targetAddress attribute is updated with the user's %alias%@tenant.mail.onmicrosoft.com address (which is also used by AutoDiscover to redirect Outlook clients to the correct mailbox).

Messages destined for the migrated mailbox then forwarded on to the onmicrosoft.com namespace.  It's pretty simple, conceptually.

So what happens when you're coming from a foreign mail system and can't establish a shared namespace?  I've solved this problem before by adding a secondary namespace on the foreign system and then managing a table of mailbox forwarding between the two namespaces (tenant.onmicrosoft.com on our side; migration.domain.com on the foreign source), and that has worked well for several migrations.

My current dilemma was a bit more complex--a vendor of a hosted mail system that won't add a secondary namespace.  How can we work around this?

And thus, this solution was born.

It's actually not that hard to configure.

So, connect via PowerShell to your Office 365 tenant, and then ...

  1.  Set your domain to Internal Relay.
    1. Why we do this: For any objects that are synchronized from on-premises AD but do not have mailboxes (or cloud-only IDs that have not yet been licensed), we need to configure the system to route via MX to another host for delivery.  Typically, this is used in hybrid environments where recipients could be either on-premises or in cloud.  In this case, we're just using it because some recipients aren't in-cloud.
    2. How to do it: Set-AcceptedDomain -Identity domain.com -DomainType InternalRelay
  2. Create a distribution group to exclude migrated users.
    1. Why we do this: During the staged migration, user mailboxes will exist in some location (for in-flight users, they'll exist in both the source and the destination).  We need a mechanism to determine who is really “migrated” and who is still having mailbox data synchronized.  We will have to manually manage the membership of this group.
    2. How to do it: New-DistributionGroup -Name "Migrated Users" -PrimarySmtpAddress Migrated@domain.com
  3. Create a "Partner" outbound connector.
    1. Why we do this:  All mail destined for non-migrated recipients in the shared namespace is going to get forwarded out this connector to the foreign system.
    2. How to do it: New-OutboundConnector -Enabled:$true -ConnectorType 'Partner' -AllAcceptedDomains:$false -IsTransportRuleScoped:$true -Name 'Shared Name Space with External Entity TRSC' -CloudServicesMailEnabled:$false -Comment 'TransportRule Scoped Connector for shared namespace domain.com' -TlsSettings $null -TlsDomain $null -UseMXRecord:$false -RecipientDomains $null -SmartHosts @('1.2.3.4’)
  4. Create the transport rule to be used in conjunction with the connector
    1. Why we do this: We need use a rule to determine how to handle mail.  Mail for non-migrated users will get routed to the new outbound connector that was just created (step 3); mail for migrated users (determined by the group membership in step 2) will be delivered locally.
    2. How to do it:  New-TransportRule -SentToScope 'InOrganization' -RouteMessageOutboundConnector 'Shared Name Space with External Entity TRSC' -ExceptIfSentToMemberOf 'migrated@domain.com' -Name 'Coexistence' -StopRuleProcessing:$false -Mode 'Enforce' -Comments 'Redirect in-org mail to Foreign Server except for members of a specific group' -RuleErrorAction 'Ignore' -SenderAddressLocation 'Header' -SetSCL '-1'
  5. Create a transport rule to allow mail from the source system to bypass spam filtering
    1. Why we do this: Mail being forwarded from the source system might be seen as junk, so we want to make sure it gets though..
    2. How to do it:  New-TransportRule -SenderIPRanges @('1.2.3.4') -Name 'Inbound from Shared Namespace' -StopRuleProcessing:$false -RuleErrorAction 'Ignore' -SenderAddressLocation 'Header' -SetSCL '-1'

And the magic happens.

For third-party migrations, you can now enable mailbox licenses in Office 365 and begin synchronizing mail.  As users are completed for cutover, simply add them to the group "migrated" (or whatever you called it in Office 365) and mail will no longer be routed to that connector destined for the source environment.  On the source side, configure the migrated mailbox to forward to %alias%@tenant.mail.onmicrosoft.com (as we do in hybrid).  Once the mailbox migration is complete, you can move the MX to Office 365 and then clean up your environment:

  • Remove the Transport Rules created in steps 4 and 5.
  • Remove the Outbound Connector created in step 3.
  • Remove the distribution group created in step 2.
  • Set the shared domain namespace to Authoritative.
  • Discontinue use of the foreign system.

For additional information with overall strategies for 3rd-party mail migrations, please see https://technet.microsoft.com/en-us/library/dn720476%28v=exchg.150%29.aspx.

For these steps compiled into a script, please visit the TechNet Script Gallery page at https://gallery.technet.microsoft.com/Configure-Coexistence-670a265c.

Comments

  • Anonymous
    June 28, 2016
    Thanksalways interesting