Hybrid-style Exchange migrations with multiple Office 365 tenants

Sep 19, 2018 | Blog | 0 comments

Generally, when migrating to the cloud the most appropriate way of accomplishing this is to use the Hybrid Configuration Wizard. This tool creates mail connectors, organisation relationships and prepares your Exchange On-Premises organisation for migrating to Office 365.

In some scenarios, however, it might not be possible to use Exchange Hybrid to do this. One such scenario is when you are hosting multiple organisations within a single Exchange environment – like many hosted email providers do, and plan to migrate each organisation to its own Office 365 tenant. When that’s the case you will not be able to use Exchange Hybrid – but you will be able to utilise some of the features, like mailbox moves, mail flow and federation by manually configuring these.

In this step by step guide, we will walk through the process of creating this configuration using PowerShell within Exchange.

Our example Exchange and hosted environment

Our example environment is a hosted environment, with a number of customers running from a single Exchange 2013+ organisation and a single Active Directory.

As you’ll see in the screenshot below, All About 365 and Exchange Labs are both hosted within their own Organisational Unit within Active Directory and have their own unique user accounts – and unique domain names.

Azure Active Directory Organisational Units

Azure Active Directory Organisational Units

Within the Exchange environment this translates into accepted domains of allabout365.com and exchangelabs.co.uk:

Exchange Environment Accepted Domains

Exchange Environment Accepted Domains

Each organisation also uses their own email address policy for each organisation, resulting in a clearly defined split of users, email address domains and other configuration data.

Exchange Email Address Policy

Exchange Email Address Policy

From each organisation’s perspective, they are completely separate. In addition to this, Address Book Policies and other configuration is utilised to enforce that split – and logically this has led the hoster to the conclusion that moving to Office 365 is a logical step.

Our example Office 365 tenants

As a pre-requisite for the Exchange Online migration, Office 365 tenants have been created and set up for each organisation.

The All About 365 organisation has a new tenant set up, under the name customertenant1.onmicrosoft.com.

All About 365 Office 365 Tenant

All About 365 Office 365 Tenant

The Exchange Labs organisation also has a new Office 365 tenant – under the name customertenant2.onmicrosoft.com.

Exchange Labs Tenant

Exchange Labs Tenant

In advance of the Exchange migration, Azure AD Connect has been installed multiple times, once for each organisation. As part of the configuration, filtering has been used to ensure that unique objects are synchronised to each tenant. In the below example, All About 365 has only the AllAbout365 OU synchronised to its respective tenant.

Azure Active Directory Connect - Domain and OU Filtering

Azure Active Directory Connect – Domain and OU Filtering

Exchange On-Premises Initial Setup and Configuration

For the purposes of this migration, we’ll be configuring the basics. Mail flow will route via on-premises, following its existing path, and we’ll continue to use on-premises Autodiscover (set up using SRV records, in this example) to allow for Hybrid client connectivity.

We’ll also assume that basic pre-requisites for Hybrid migration – firewall rules for mail flow between the Office 365 tenant and the Exchange servers used for transport; and HTTPS publishing of Autodiscover and EWS URLs, and correctly published Autodiscover is in-place. Normal Exchange Hybrid pre-requisites must be performed.

Before we configure each individual tenant, we’ll need to make a number of one-time configuration changes. These include changes that only need to be applied once, or where we need to create objects like a Send Connector that we’ll re-use as we approach each Office 365 tenant.

As part of our initial configuration we’ll implement the following:

  • Set up of Federated Sharing organisation metadata, using a default namespace (in this example, goodmanuk.com – we’ll pretend that that’s the hoster’s domain)
  • Creation of the first organisation relationship, to use for Federated Sharing.
  • Enablement of the MRS Proxy, for mailbox moves.
  • Creation of the Send Connector (again, using a default address space – in this example we’ll pretend that the hoster has their own tenant, stevegoodman.onmicrosoft.com)
  • Configuration of default Receive Connectors to allow cloud-based mail from Office 365 tenants.

As we progress through each tenant set up, Federated Sharing, Org Relationships and Send Connectors will be updated.

First, open up an Exchange Management Shell.

We’ll get started with Federated Sharing by configuring a new Federation Trust, if one doesn’t already exist within the organisation:

# Configure Federated Sharing
New-ExchangeCertificate -FriendlyName "Exchange Federated Sharing" -DomainName $env:USERDNSDOMAIN -Services Federation -KeySize 2048 -PrivateKeyExportable $true -SubjectKeyIdentifier $ski
Get-ExchangeCertificate | ?{$_.FriendlyName -eq "Exchange Federated Sharing"} | New-FederationTrust -Name "Microsoft Federation Gateway"

Set-Federationtrust -Identity 'Microsoft Federation Gateway' -RefreshMetadata:$false
Set-FederatedOrganizationIdentifier -AccountNamespace "goodmanuk.com" -DelegationFederationTrust 'Microsoft Federation Gateway' -Enabled:$true -DefaultDomain "goodmanuk.com"

Next, we’ll enable the MRS proxy. We perform this task across all Exchange servers that run the Client Access role (or for 2016 onwards, all Mailbox servers).

This will enable Exchange Server to allow connections from external servers, such as Office 365, and initiate Mailbox moves.

# Enable MRS Proxy
Get-WebServicesVirtualDirectory -ADPropertiesOnly | Set-WebServicesVirtualDirectory -MRSProxyEnabled:$True

Enabling connections in Exchange Server from External Servers

Enabling connections in Exchange Server from External Servers

We’ll also configure a new Send Connector specifically for Office 365-destined mail. This will use the default tenant we discussed earlier, and be updated on a per-tenant basis.

For inbound mail from Office 365, our Exchange 2013+ environment will need the Default Receive Connector updated for each server, as shown in the example below.

# Configure Mail Flow
New-SendConnector -Name 'Outbound to Office 365' -AddressSpaces "stevegoodman.mail.onmicrosoft.com" -SourceTransportServers "SG-EX01" -DNSRoutingEnabled:$true -TLSDomain 'mail.protection.outlook.com' -RequireTLS:$true -TLSAuthLevel 'DomainValidation' -ErrorPolicies 'Default' -TLSCertificateName "<I>CN=DigiCert SHA2 Secure Server CA, O=DigiCert Inc,C=US<S>CN=mail.goodmanuk.com, O=Steve Goodman, L=Nuneaton, C=GB" -CloudServicesMailEnabled:$true -Fqdn $null

Set-ReceiveConnector -Identity "SG-EX01\Default Frontend SG-EX01" -TLSCertificateName "<I>CN=DigiCert SHA2 Secure Server CA, O=DigiCert Inc,C=US<S>CN=mail.goodmanuk.com, O=Steve Goodman, L=Nuneaton, C=GB" -TLSDomainCapabilities "mail.protection.outlook.com:AcceptCloudServicesMail"

Enabling Inbound mail from Office 365

Enabling Inbound mail from Office 365

Per-Tenant configuration in Office 365 and in Exchange

With the on-premises environment ready, we’ll configure our first Office 365 tenant. To perform the configuration, we’ll use an Exchange Management Shell that also has a connection set up to Exchange Online from the same session.

In the example below, it’s for All About 365 and we’ll configure the following variables to use as we run each script block.

# Per Tenant Details
$TenantName = "customertenant1.mail.onmicrosoft.com"
$DomainName = "allabout365.com"

Our first task is to grab the Federated Domain Proof for the domain name we’ll use within this tenant. We can grab that using the following command.

# Get and set Domain Proof
Get-FederatedDomainProof -DomainName $DomainName

Federated Domain Proof

Federated Domain Proof

Grab the Proof record, and add this as a TXT record to DNS, similar to the example below:

Updating DNS Records

Updating DNS Records

Next, we’ll connect to Exchange Online PowerShell. In the example below, we use the Prefix parameter to add a Cloud prefix to all Exchange Online commands. For example Get-Mailbox will become Get-CloudMailbox. This helps us to differentiate between environments as we run the commands below.

# Connect to Exchange Online
$O365Credential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $O365Credential -Authentication Basic -AllowRedirection
Import-PSSession $Session -DisableNameChecking -Prefix Cloud

Our first step within the tenant is to enable organisation customisation. This is a pre-requisite for Hybrid type functionality:

# Initial Tenant Readiness in Office 365
Enable-CloudOrganizationCustomization

Enable Organisation Customisation

Enable Organisation Customisation

After enabling customisation, we’ll find that the tenant.mail.onmicrosoft.com accepted domain is available in addition to the standard tenant.onmicrosoft.com address. This is key for our Hybrid-style routing and free/busy.

Accepted Tenant Domains

Accepted Tenant Domains

Next, after checking our TXT record is in DNS and propagated, we’ll add our Federated Domain:

# Add Federated Domain
Add-FederatedDomain -DomainName $DomainName

Adding Federated Domain

Adding Federated Domain

To facilitate Free/Busy information to be shared from on-premises to Office 365, we’ll create a new Org Relationship. This will be used to control free/busy and federated sharing between the on-premises hosted environment and this Office 365 tenant. We’ll create an individual sharing relationship for each tenant, to allow more control over per-customer sharing settings.

The example below creates an organisation relationship with Office 365 URLs hard coded. When we create it, we add the tenant.mail.onmicrosoft.com name – when lookups occur on premises, they’ll use the targetAddress on the migrated mailbox to find where to look up free/busy information.

Additionally, take a note of the permissions levels and access levels specified within the command parameters, and update accordingly.

# Configure Organization Relationship in Office 365
New-CloudOrganizationRelationship -Name "O365 to Hosted" -TargetApplicationUri "FYDIBOHF25SPDLT.goodmanuk.com" -TargetAutodiscoverEpr "https://mail.goodmanuk.com/autodiscover/autodiscover.svc/WSSecurity" -Enabled:$true -DomainNames $DomainName
Set-CloudOrganizationRelationship -Identity "O365 to Hosted" -FreeBusyAccessEnabled:$true -FreeBusyAccessLevel 'LimitedDetails' -MailTipsAccessEnabled:$true -MailTipsAccessLevel 'All' -DeliveryReportEnabled:$true -PhotosEnabled:$true
Set-CloudFederatedOrganizationIdentifier -DefaultDomain $TenantName -Enabled:$true

Permission and Access Levels

Permission and Access Levels

Back in Office 365, we’ll configure a new organisation relationship in our tenant, configured to point back to the on-premises Exchange hosted environment.

As you’ll see, we’re specifying the ApplicationURI from our Federated Org Identifier and the full TargetAutoDiscover EPR to assist with discovery of web services URLs.

# Configure Organization Relationship in Office 365
New-CloudOrganizationRelationship -Name "O365 to Hosted" -TargetApplicationUri "FYDIBOHF25SPDLT.goodmanuk.com" -TargetAutodiscoverEpr "https://mail.goodmanuk.com/autodiscover/autodiscover.svc/WSSecurity" -Enabled:$true -DomainNames $DomainName
Set-CloudOrganizationRelationship -Identity "O365 to Hosted" -FreeBusyAccessEnabled:$true -FreeBusyAccessLevel 'LimitedDetails' -MailTipsAccessEnabled:$true -MailTipsAccessLevel 'All' -DeliveryReportEnabled:$true -PhotosEnabled:$true
Set-CloudFederatedOrganizationIdentifier -DefaultDomain $TenantName -Enabled:$true

Configure Organisation Relationship in Office 365

Configure Organisation Relationship in Office 365

With our organisation relationship configuration complete, we’ll begin with mail flow and email address policy configuration.

First, we’ll create new Remote Domains on-premises and Accepted Domains. These will use the tenant name and allow us to assign tenant.mail.onmicrosoft.com style secondary addresses to recipients.

The second part of the command updates the relevant Email Address policies, and you are likely to have to update the script example accordingly. In our example environment, we’ve named the Email Address Policy to match the unique domain.

# Configure Recipient Settings
New-RemoteDomain -Name $TenantName -DomainName $TenantName
New-AcceptedDomain -DomainName $TenantName -Name $TenantName
$EmailAddressPolicy = Get-EmailAddressPolicy $DomainName
$NewTemplates = $EmailAddressPolicy.EnabledEmailAddressTemplates+="smtp:%m@$($TenantName)"
Set-EmailAddressPolicy -Identity $DomainName -ForceUpgrade:$true -EnabledEmailAddressTemplates:$NewTemplates
Update-EmailAddressPolicy -Identity $DomainName -UpdateSecondaryAddressesOnly:$true

Configure Recipient Settings

Configure Recipient Settings

Next, we’ll update the on-premises Send Connector to include the tenant.mail.onmicrosoft.com address for this particular tenant to ensure messages bound for the tenant use the correct connector:

# Configure Send Connector
$SendConnector = Get-SendConnector "Outbound to Office 365"
$AddressSpaces = $SendConnector.AddressSpaces + $TenantName
Set-SendConnector -Identity "Outbound to Office 365" -AddressSpaces $AddressSpaces

Configure Send Connector

Configure Send Connector

Back in our Office 365 tenant, we’ll perform similar configuration. We’ll create new Inbound and Outbound connectors and use a combination of the DNS name for the on-premises smart hosts, and the combined Issuer and Subject name of the certificate to validate that environment is the one it claims to be. The Outbound connector specified here mimics Centralized Transport.

You’ll need to update this script block with values from your own environment:

# Set up Office 365 Connectors
New-CloudInboundConnector -Name "Inbound from Hosted" -ConnectorType 'OnPremises' -RequireTLS:$true -SenderDomains $DomainName -TLSSenderCertificateName "<I>CN=DigiCert SHA2 Secure Server CA, O=DigiCert Inc,C=US<S>CN=mail.goodmanuk.com, O=Steve Goodman, L=Nuneaton, C=GB" -CloudServicesMailEnabled:$true

New-CloudOutboundConnector -Name "Outbound to Hosted" -AllAcceptedDomains $True -SmartHosts "mail.goodmanuk.com" -ConnectorType 'OnPremises' -TLSSettings 'DomainValidation' -TLSDomain "mail.goodmanuk.com" -CloudServicesMailEnabled:$true -RouteAllMessagesViaOnPremises:$True -UseMxRecord:$false -RecipientDomains:*

Set Up Office 365 Connectors

Set Up Office 365 Connectors

Finally, with mail routing and federation configuration in place, we’ll create a Migration Endpoint in the tenant. This will be used to migrate mailboxes to Office 365 and uses an on-premises AD account with the rights described here. We’ll use the New-MigrationEndPoint cmdlet to perform this step:

# Set up Migration Endpoint
$ExchangeCredential=Get-Credential
New-CloudMigrationEndpoint -ExchangeRemoteMove -Name HostedExchange -RemoteServer mail.goodmanuk.com -Credentials $ExchangeCredential

Set Up Migration Endpoint

Set Up Migration Endpoint

Repeating for additional tenants

For each subsequent tenant, we’ll use the complete script block as shown in the example below. This will be updated with relevant customer tenant and domain name information. Any changes you make to the example configuration above will need to be reflected here, also.

# Per Tenant Details
$TenantName = "customertenant1.mail.onmicrosoft.com"
$DomainName = "allabout365.com"

# Get and set Domain Proof
Get-FederatedDomainProof -DomainName $DomainName

# Connect to Exchange Online
$O365Credential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $O365Credential -Authentication Basic -AllowRedirection
Import-PSSession $Session -DisableNameChecking -Prefix Cloud

# Initial Tenant Readiness in Office 365
Enable-CloudOrganizationCustomization

# Add Federated Domain
Add-FederatedDomain -DomainName $DomainName

# Create a new Organization Relationship on-premises
New-OrganizationRelationship -Name $TenantName -TargetApplicationUri 'outlook.com' -TargetAutodiscoverEpr "https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity" -Enabled:$true -DomainNames $TenantName
Set-OrganizationRelationship -Identity $TenantName -MailboxMoveEnabled:$true -FreeBusyAccessEnabled:$true -FreeBusyAccessLevel 'LimitedDetails' -ArchiveAccessEnabled:$true -MailTipsAccessEnabled:$true -MailTipsAccessLevel 'All' -DeliveryReportEnabled:$true -PhotosEnabled:$true -TargetOwaURL "http://outlook.office365.com/owa/"

# Configure Organization Relationship in Office 365
New-CloudOrganizationRelationship -Name "O365 to Hosted" -TargetApplicationUri "FYDIBOHF25SPDLT.goodmanuk.com" -TargetAutodiscoverEpr "https://mail.goodmanuk.com/autodiscover/autodiscover.svc/WSSecurity" -Enabled:$true -DomainNames $DomainName
Set-CloudOrganizationRelationship -Identity "O365 to Hosted" -FreeBusyAccessEnabled:$true -FreeBusyAccessLevel 'LimitedDetails' -MailTipsAccessEnabled:$true -MailTipsAccessLevel 'All' -DeliveryReportEnabled:$true -PhotosEnabled:$true
Set-CloudFederatedOrganizationIdentifier -DefaultDomain $TenantName -Enabled:$true

# Configure Recipient Settings
New-RemoteDomain -Name $TenantName -DomainName $TenantName
New-AcceptedDomain -DomainName $TenantName -Name $TenantName
$EmailAddressPolicy = Get-EmailAddressPolicy $DomainName
$NewTemplates = $EmailAddressPolicy.EnabledEmailAddressTemplates+="smtp:%m@$($TenantName)"
Set-EmailAddressPolicy -Identity $DomainName -ForceUpgrade:$true -EnabledEmailAddressTemplates:$NewTemplates
Update-EmailAddressPolicy -Identity $DomainName -UpdateSecondaryAddressesOnly:$true

# Configure Send Connector
$SendConnector = Get-SendConnector "Outbound to Office 365"
$AddressSpaces = $SendConnector.AddressSpaces + $TenantName
Set-SendConnector -Identity "Outbound to Office 365" -AddressSpaces $AddressSpaces

# Set up Office 365 Connectors
New-CloudInboundConnector -Name "Inbound from Hosted" -ConnectorType 'OnPremises' -RequireTLS:$true -SenderDomains $DomainName -TLSSenderCertificateName "<I>CN=DigiCert SHA2 Secure Server CA, O=DigiCert Inc,C=US<S>CN=mail.goodmanuk.com, O=Steve Goodman, L=Nuneaton, C=GB" -CloudServicesMailEnabled:$true
New-CloudOutboundConnector -Name "Outbound to Hosted" -AllAcceptedDomains $True -SmartHosts "mail.goodmanuk.com" -ConnectorType 'OnPremises' -TLSSettings 'DomainValidation' -TLSDomain "mail.goodmanuk.com" -CloudServicesMailEnabled:$true -RouteAllMessagesViaOnPremises:$True -UseMxRecord:$false -RecipientDomains:*

# Set up Migration Endpoint
$ExchangeCredential=Get-Credential
New-CloudMigrationEndpoint -ExchangeRemoteMove -Name HostedExchange -RemoteServer mail.goodmanuk.com -Credentials $ExchangeCredential

Start your Exchange Migration to Office 365

Content and Code specialise in all things Office 365 and Exchange Migrations are our bread and butter. Whether your organisation is in the early stages of planning to migrate to Office 365, or want an award winning Microsoft partner to deliver your Exchange migration project. Book a consultation with one of our dedicated consultants.

BOOK YOUR CONSULTATION

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

RELATED POSTS:

Announcement: Content and Code will be joining IT Lab

Today we're delighted to announce that Content and Code will be joining IT Lab. The coming together of these two great companies represents an amazing opportunity for our clients. We've always been about changing the way the world works. Helping our clients digitally...

read more

Ignite Announcements: Modern SharePoint, Teams, Search

Continuing with our top announcements from Ignite, we saw again Microsoft focus on the improvements around Modern Teamwork capabilities and a renewed effort to improve the modern SharePoint experience. We mentioned in our first Ignite announcements post that Microsoft...

read more

Day 1 – Microsoft Ignite Keynotes and Announcements

We’re excited to have a dedicated team from across Content and Code in attendance at this year’s Microsoft Ignite in Orlando, Florida. We were very keen to ensure that we covered all basis this time round. To ensure that we can add value to each and every one of our...

read more