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. So, I talked to a few of my peers who have a penchant for crazy things and they gave me a few ideas.
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 update and set with the user's %email@example.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 are 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 second namespace. How can we work around this?
And thus, this solution was born.
It's actually not that hard, and I may begin using it full-time as it is easier to maintain than my old subdomain method.
- Set your domain to Internal Relay
- 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.
- How to do it: Set-AcceptedDomain -Identity domain.com -DomainType InternalRelay
- Create a distribution group to exclude migrated users.
- Why we do this: During the staged migration, user mailboxes will exist in some location. 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.
- How to do it: New-DistributionGroup [email protected]
- Create Partner outbound connector
- 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.
- 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 @('184.108.40.206’)
- Create the transport rule to be used in conjunction with the connector
- 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.
- How to do it: New-TransportRule -FromScope 'InOrganization' -RouteMessageOutboundConnector ''Shared Name Space with External Entity TRSC' -ExceptIfSentToMemberOf '[email protected]' -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'