Currently, I’m often asked to migrate mailboxes or entire IT infrastructures from local data centers into the cloud. But sometimes, you’ll have to buck the trend and do something quite different. With this blog post I’m trying to explain how you can migrate your mailboxes from Exchange Online/Office 365 into your on-premise datacenter without having a hybrid configuration in place.
First of all: No, I’m not going insane. And yes, I’m still convinced of Exchange Online beeing a great messaging plattform. But there are scenarios which require you to think different. Imagine two companies which are merged together and whose mailboxes have to be consolidated on premise on the basis of compliance regulatories. If one of those companies’ mailboxes are currently running on Exchange Online this blog post might give you a push into the right direction.
Before you start – things to consider
Before you start merging your messaging infrastructures, your mail flow most likely looks somewhat similar to the following illustration:
Once an e-mail message is sent to a recipient at Contoso, the sending e-mail server will try to resolve a DNS mx record that corresponds to the e-mail domain contoso.com. The Contoso e-mail gateway will then process the message and deliver it to the on premise Exchange infrastructure. Is an e-mail message sent to a recipient at Fabricam, the mail is sent to the Microsoft cloud. What you have to consider in that context is that you will have to change internal mail flow before and external mail flow after moving mailboxes from the cloud to the on premise infrastructure.
Internal mail flow
In order to enable the on premise Exchange environment to accept e-mail messages for the fabricam.com e-mail domain the domain will have to be configured as accepted domain within Exchange Admin Center. The domain type will be set to internal relay so that Exchange will try to deliver accepted messages to an on premise mailbox or – if the recipient doesn’t have an on premise mailbox – to another messaging infrastructure, e.g. the Microsoft cloud. At the same time you will either have to configure a send connector with an address space of fabricam.com so e-mails can be forwarded to a respective mail gateway or a send connector that directly sends e-mail messages to the internet using corresponding mx records to the recipient domain. So if an e-mail is processed by the on premise Exchange organization it is either delivered to a mailbox within the Exchange org or to the target domain using the configured send connector.
In the Microsoft cloud the fabricam.com domain will also have to be configured as internal relay domain and a connector will have to be created so the cloud can accept e-mail messages to fabricam.com, try to deliver them to cloud mailboxes or – in case the mailbox is not located in the cloud – forward them to the Contoso e-mail gateway. If the recipient mailbox is not located on premise either the mail message will be forwarded to the fabricam.com mx record and then be processed all over again. We can avoid message loops by implementing recipient filtering on the Contoso e-mail gateway. Mails to fabricam.com recipients without cloud mailboxes are then bounced at the gateway if a corresponding on premise mailbox doesn’t exist.
Sender policy framework as show stopper
Strict SPF checks can prevent senders from delivering mail messages to fabricam.com mailboxes which are located within the on premise Exchange infrastructure in our scenario. SPF enables the receiving mail exchanger to check if a received mail message was sent from a server which was authorized by the sending organization’s administrator. For this purpose the sending organization’s administrator creates special DNS txt records in the respective public DNS zone. If a mail message is sent from a host which is not member of this “allow list”, the message is rejected at the receiving gateway. As soon as a mail message is relayed by Exchange Online the mail header is altered so the receiving mail gateway assumes that the mail was sent from a Microsoft IP address. In that case you should disable SPF checks for the migrating mailboxes as long as the migration takes or alter your SPF txt record to something like
v=spf1 ip4:192.168.0.1 ip4:192.168.0.2 ip4:192.168.0.3 include:spf.protection.outlook.com -all
Mailbox migration
In order to migrate cloud mailboxes to the on premise infrastructure you need corresponding Active Directory user accounts all migrated mailboxes can be connected to. First of all we connect Windows PowerShell to the cloud and export a list of all mailboxes with relevant Attributes.
$ExchangeOnlineCredential = Get-Credential ` -UserName <YourUserName> ` -Message "Enter Password" $Session = New-PSSession ` -ConfigurationName Microsoft.Exchange ` -ConnectionUri https://outlook.office365.com/powershell-liveid/ ` -Credential $ExchangeOnlineCredential ` -Authentication Basic ` -AllowRedirection Import-PSSession $Session
Get-Mailbox | SelectPrimarySMTPAddress | Export-CSV C:\Temp\CloudMailboxes.csv -NoTypeInformation
If not already done you can create Active Directory user objects based on the export. After all user account are created you’ll have to mail enable the accounts using PowerShell. Make sure that the mail user gets the same e-mail address and the same Exchange GUID as the source mailbox in the cloud since these attributes are used for matching while migrating the mailboxes. Furthermore you will need the LegacyExchangeDN attribute set as X500 email address on the new mailbox.
$NewMailboxes = Import-CSV C:\Temp\CloudMailboxes.csv `
-Delimiter ";" `
-Encoding Default
Foreach ($NewMailbox in $NewMailboxes) {
$ADUser = Get-ADUser -Filter * -Properties * | where {
$_.displayname -eq $NewMailbox.DisplaynameNew
}
If ($ADUser) {
Enable-Mailuser $ADUser.Name -ExternalEmailAddress
$NewMailbox.PrimarySMTPAddress
$Mailuser = Get-Mailuser $NewMailbox.Displayname
$LegDN = "X500:" + $NewMailbox.LegacyExchangeDN
$Mailuser.EMailAddresses += [Microsoft.Exchange.Data.CustomProxyAddress]($LegDN)
Set-Mailuser $Mailuser -ExchangeGUID $NewMailbox.GUID -EmailAddresses $Mailuser.EmailAddresses } }
Before you migrate
Before you start migrating your mailboxes you will have to enable a migration endpoint in Office 365/Exchange Online and to activate MRS Proxy on your on premise Client Access Server.
Migration
To start the migration task just click Migrate from Exchange Online in Exchange Online admin center. The wizard will quide you through the migration process and after finishing you can use your on premise mailbox.
External mail flow
All that’s left after you have migrated your mailboxes to your on premise Exchange organization is to change the mx records so new mail is sent to your own mail gateways and not to the Microsoft cloud.
I hope you got an idea of how to migrate your mailboxes the other way round and that this blog post can help you in upcoming migration projects.
Bye for now and stay tuned,
Tom
Azure and beyond 