Office 365 – Distribution List Migrations Version 2.0 – Part 32

Enabling support for a custom routing domain…

In an Office 365 installation the hybrid routing domain is provisioned when the tenant is initially created. The hybrid routing domain is what is utilized to secure mail flow from on premises installations to Office 365 in a co-existence scenario. The hybrid routing domain is typically mail.tenantName.onmicrosoft.com.

 

When migration distribution lists a contact object is always provisioned for each group migrated. The contact object has a target address utilizing the mail.tenantName.onmicrosoft.com email address either assigned to the migrated distribution list or created as a part of the migration. This is done to ensure that cross premises mail flow is secure using the standard security applied to the hybrid send connector. For information on hybrid mail flow please see the following article: Office 365 – Distribution List Migrations Version 2.0 – Part 7 | TIMMCMIC (wordpress.com)

 

It is possible that customers may have customized the domain that they use for hybrid routing. This was not necessarily uncommon in very early Office 365 tenants and those that may have been upgraded from legacy live.edu tenants. In some instances the mail.tenantName.onmicrosoft.com domain is not utilized on send connectors since there is a custom routing domain in place. This would mean that post distribution list migration emails from on-premises applications could use an internet route and messages may arrive as externally non-secured.

 

Version 2.9.6.6 of the DLConversionV2 module now supports the ability to specify a custom routing domain. The switch -customRoutingDomain is optional and available in both single, multiple, and multiple machine migrations. When the custom routing domain is specified the module will post migration look for the presence of this address in the SMTP proxy address list. If the address is not present an attempt to create the address using the alias of the distribution list and the custom routing domain is attempted. If the stamping of this address is successful, the migration will proceed. If an address collision is detected then a random prefix is generated and combined with the remote routing domain.

 

Once the remote address is determined the mail contact on-premises for the migrated distribution list will utilize this address as a target address. If all send connectors are properly configured mail that uses this custom routing domain and target address will arrive in Office 365 as trusted and secure.

 

Here is an example of implementing custom routing domains with a migration. To begin prior to migration this is the list of email addresses assigned to the group being migrated in Office 365.

 

PS C:\> Get-DistributionGroup atestgroup416 | fl *emailaddresses*

 

EmailAddresses : {SMTP:aTestGroup416@domain.com, smtp:aTestGroup416@domain.mail.onmicrosoft.com,

smtp:aTestGroup416@timmcmic.onmicrosoft.com, X500:/o=domain Home/ou=Exchange Administrative Group

(FYDIBOHF23SPDLT)/cn=Recipients/cn=4be6ea76f04b48f5bdfad29be341b41a-aTestGr}

 

In this migration our custom routing domain is domain.net. The command utilized to migrate the distribution group:

 

Start-DistributionListMigration -groupSMTPAddress atestgroup416@domain.com -globalCatalogServer azure-dc-0.home.domain.com -activeDirectoryCredential $cred -activeDirectoryAuthenticationMethod kerberos -aadConnectServer azure-dirsync-0.home.domain.com -aadConnectCredential $cred -aadConnectAuthenticationMethod kerberos -exchangeServer azure-mail-0.home.domain.com -exchangeCredential $cred -exchangeAuthenticationMethod kerberos -exchangeOnlineCredential $cred -azureADCredential $cred -logFolderPath c:\temp -dnNoSyncOU “OU=DoNotSync,OU=MigrationTest,OU=DLConversion,DC=home,DC=domain,DC=com” -enableHybridMailflow:$TRUE -customRoutingDomain “domain.net”

 

At the conclusion of the distribution list migration the list of email addresses on the migrated distribution group now includes an address @domain.net.

 

PS C:\> Get-DistributionGroup atestgroup416 | fl *emailaddresses*

 

EmailAddresses : {smtp:aTestGroup416@domain.net, X500:/o=domain Home/ou=Exchange Administrative Group

(FYDIBOHF23SPDLT)/cn=Recipients/cn=4be6ea76f04b48f5bdfad29be341b41a-aTestGr,

smtp:aTestGroup416@timmcmic.onmicrosoft.com, SMTP:aTestGroup416@domain.com…}

 

At the conclusion of the migration the mail contact on-premises is created. In this case the enableHybridMailFlow option was set to true which triggers the full mail enablement of this contact. The target address is set to match the secondary SMTP addressed added at the custom routing domain.

 

[PS] C:\>Get-MailContact atestgroup416-migratedbyscript | fl *address*

 

ExternalEmailAddress : SMTP:ATESTGROUP416@domain.NET

AddressListMembership : {}

EmailAddresses : {SMTP:aTestGroup416-MigratedByScript@domain.com}

HiddenFromAddressListsEnabled : True

EmailAddressPolicyEnabled : False

PrimarySmtpAddress : aTestGroup416-MigratedByScript@domain.com

WindowsEmailAddress : aTestGroup416-MigratedByScript@domain.com

 

This change is specific to environments that already have a custom routing domain defined for cross-premises mail flow in a hybrid environment. If you do not have a customized configuration the defaults should be utilized. In environments that have run the updated hybrid configuration wizard and have a custom routing domain the default routing domain of mail.tenantName.onmicrosoft.com should be on the appropriate send connector allow you to utilize defaults.