Chat now with support
Chat with Support

On Demand Migration for Email Current - User Guide

Introduction Preparing Migrations Test and Pilot Migrations Configuring and Running Migrations Post Migration Third Party Assessments and Certifications Glossary

Source Email Service

Source Email Service

Refer to the sections below for mail routing instructions specific to your source email service.

Important: Mail routing is not supported by POP/Hotmail and IMAP source email services.

Exchange 2007/2010/2013/2016/2019

Exchange 2007/2010/2013/2016/2019

 

Note: To enable the CPUU integration feature on the source Exchange Server 2007, you should turn on and configure the WebDAV API access for your Exchange Server 2007. For more details, please see Updating Outlook Client Profiles.

When migrating from on-premises Exchange server to Office 365, you can use the Microsoft directory synchronization solution together with ODME. For more details about how to convert mail-enabled users created by Microsoft directory synchronization tool to mailbox-enabled users, please see the following article https://msdn.microsoft.com/en-us/library/azure/hh967617.aspx.

Your DNS MX records will already be set to deliver mail to your Exchange server. For Exchange to forward mail, set the targetAddress for the mailboxes that now reside on your new mail system to a subdomain that exists, and configure Exchange to route to target mail system. You can do this by using the Exchange PowerShell Set-Mailbox cmdlet. In the Exchange Management Shell, use the following command:

Set-Mailbox -Identity SourceMailbox -TargetSmtpAddress TargetUsername@ForwardingSubDomain

Where:

  • SourceMailbox is the user's SMTP address in the source system.
  • TargetUsername is the user's Target userid.
  • ForwardingSubDomain is a secondary domain that you have set up in the Target domain.

For the forwarded mail to get sent to your target system, create a new send connector to handle the forwarding domain. By using a send connector you do not need to expose this forwarding domain in your DNS. You can create a send connector in the Exchange Management Console, or you can use PowerShell in the Exchange Management Shell. To create the send connector with PowerShell, use the New-SendConnector cmdlet. The following is a simple usage of the send connector, your target system may require TLS or authentication to forward mail. You can change the Name parameter to something that better describes your connector.

New-SendConnector -Name ForwardToTarget -AddressSpaces ForwardingSubDomain -DNSRoutingEnabled $false

G Suite

G Suite

To forward mail from G Suite to Office 365, you must register your domain with both providers. You must register the domain you are using to forward mail from G Suite due to a restriction of the Google APIs used by ODME. The Google APIs will only allow forwarding addresses for registered domains or subdomains of the primary G Suite account. Adding a domain for mail destined for Office 365 may seem counter to normal migration practices, but is a required step. Please note that registering a domain with G Suite does not impact mail routing for the domain.

After registering your domain, the procedure for setting up mail routing for G Suite is the same if Office 365 is the target email service, but slightly different if the target is Exchange 2010.

For infomormation about setting up mail forwarding and available forwarding actions, see Setting Up Mail Forwarding.

Registering your Domain with Google Domains and Office 365

To set forwarding from G Suite to Office 365, you need a domain that is registered with Google Domains and with Office 365. The Google APIs used by ODME require that the domain is registered with Google Domains. To receive mail for the forwarded messages from G Suite, you need email addresses with this domain for your Office 365 Exchange accounts. The following procedures walk you through registering your forwarding domain with Google Domains and registering your domain with Office 365.

To register your domain with Google Domains:

  1. Log in to your Google Admin console (https://www.google.com/a/example.com/) and go to Domains > Add/remove domains page.
  2. Click Add a domain or a domain alias.
  3. Select the Add another domain option and enter the domain name.
  4. Click CONTINUE AND VERIFY DOMAIN OWNERSHIP.

You are prompted to sign in to your domain name provider to verify your ownership of the domain. A helper app may be available, but we recommend completing the process manually by adding a TXT record.

  1. Click Add a TXT record.
  2. Complete the steps for creating a DNS record that proves to Google that you own the domain.
  3. Return to the Google domain registration page and click Verify.

If you have entered all the information correctly you should receive a conformation message. The next step is to activate your domain.

  1. Click Continue and go to the Domains > Add/remove domains page again.

You should see your domain listed with an exclamation mark,

  1. Click Skip Google MX setup since you don't want mail to route to G Suite for this domain.
  2. In the Route mail to another server box, click I use another mail server.

Next you need to register the domain with Office 365.

To register your domain with Office 365:

  1. Go to https://portal.microsoftonline.com/ and login as an administrator to your Office 365 portal.
  2. Select Admin > Office365 and then select Domains on the left hand navigation tree.
  3. Select Add a domain and add the same domain to Office 365 that you added to G Suite.

This opens a wizard which prompts you to add another TXT record to verify ownership.

  1. After proving the domain name in the wizard, complete the remaining steps for verifying your ownership of the domain by creating another TXT record.

When finished, you should have two TXT records in my DNS, one for G Suite and one for Office 365.

  1. Return to the Office 365 portal and click Done, verify now.

If you have entered all the information correctly you should receive a conformation message.

  1. Click Finish.

The next step offered is Add users and assign licenses.

  1. Click Start step 2.
  2. Since this is a subdomain for mail routing, select I don't want to add users right now.
  3. Click Next.
  4. Click Start step 3.

This opens the “how do you want to use…” page.

  1. Check the Exchange Online option since you just want to setup this domain for Exchange Online, and then click Next.

This opens the “add these dns records” page.

  1. Follow the instructions for adding the TXT record.
  2. Add the CNAME for autodiscover.
  3. Click Done, go check.

If you have entered all the information correctly you should receive a conformation message.

 

Note: To add a subdomain to a domain that's set up for federated authentication, do the following:

  1. Connect to Windows Azure Active Directory (Windows Azure AD) by using Windows PowerShell. Connect from ADFS Core Server.
  2. Use the Connect-MSOLService cmdlet to connect to cloud with Global Administrator credential.
  3. Use the New-MSOLFederatedDomain cmdlet.
  4. The syntax to add a subdomain is as follows, where <subdomain> is the name of the subdomain that you want to add:

New-MSOLFederatedDomain -DomainName:<subdomain>"

Mail Routing between G Suite and Office 365

To set up mail routing between G Suite and Office 365, you must configure per-mailbox forwarding in conjunction with subdomain forwarding. This prevents email duplication and subdomains appearing in the Reply Address on any message, either internal or external.

To set up mail routing between G Suite and Office 365:

  1. Configure both G Suite and Office 365 to accept mail from the same domain, for example, “example.com.” For how to set up MX records for G Suite and Office 365, refer to https://support.google.com/a/answer/140034?hl=en and https://technet.microsoft.com/en-us/library/mt595791(v=exchg.150).aspx.

In addition, MX records point to G Suite. Though MX can direct email at either system, it is best to have mail delivered to the server with the largest number of users. This means that at the start of the migration, MX points to G Suite, and at the halfway point of the migration, the MX records switch to point to Office 365. Note that the system receiving the mail must know about all users in both systems.

The first step is to create two subdomains used for routing.

  1. Create an MX record for each domain, which allows each system to send mail to the other.

For example, the domain “O365.example.com” directs mail to Office 365, while the domain “gapps.example.com” directs mail to G Suite.

  1. After you create the MX records, set up each system to accept mail for the new subdomains.

In Office 365, you add this domain as a new Accepted Domain. In G Suite, you add this as a new Domain Alias.

By default, all users on G Suite will have aliases for this subdomain. However, with Office 365, you must configure each user with the routing domain, either manually or via a powershell script.

  1. Create representative mailboxes in Office 365 for each user that is presently in G Suite.

This allows users who are migrated to Office 365 to see a GAL that is populated with all the users, as well as facilitate message forwarding for users still homed in G Suite.

  1. After all the users have mailboxes in Office 365, set forwarding on them that will remain until the user is migrated.

The setting of forwarding can be done with the ODME per-user mail forwarding feature, as described in the section Setting Up Mail Forwarding.

  1. When migrating users, flip forwarding so that new mail is delivered to the Office 365 mailbox, and not the G Suite mailbox.

With the ODME per-user mail forwarding option, you now need to select to remove forwarding from the target as well as setting forwarding in the source. It is important to remove the target forwarding to prevent the creation of a mail loop.

Mail Routing between G Suite and Exchange 2010

To set up mail routing between G Suite and Exchange 2010, you must configure per-mailbox forwarding in conjunction with subdomain forwarding. This prevents email duplication and subdomains appearing in the Reply Address on any message, either internal or external.

To set up mail routing between G Suite and Exchange 2010:

  1. Configure both G Suite and Exchange 2010 to accept mail from the same domain, for example, “example.com.”

In addition, MX records point to G Suite. Though MX can direct email at either system, it is best to have mail delivered to the server with the largest number of users. This means that at the start of the migration, MX points to G Suite, and at the halfway point of the migration, the MX records switch to point to Exchange 2010. Note that the system receiving the mail must know about all users in both systems.

The first step is to create two subdomains used for routing.

  1. Create an MX record for each domain, which allows each system to send mail to the other.

For example, the domain “ex2010.example.com” directs mail to Exchange 2010, while the domain “gapps.example.com” directs mail to G Suite.

  1. After you create the MX records, set up each system to accept mail for the new subdomains.

In Exchange 2010, you add this domain as a new Accepted Domain. In G Suite, you add this as a new Domain Alias.

By default, all users on G Suite will have aliases for this subdomain. However, with Exchange 2010, you must go to the Exchange Management Console and configure the recipient policy to include this domain for all the users.

  1. Create representative mailboxes in Exchange 2010 for each user that is presently in G Suite.

This allows users who are migrated to Exchange 2010 to see a GAL that is populated with all the users, as well as facilitate message forwarding for users still homed in G Suite.

  1. After all the users have mailboxes in Exchange 2010, set forwarding on them that will remain until the user is migrated.

The setting of forwarding can be done with the ODME per-user mail forwarding feature, as described in the section Setting Up Mail Forwarding.

At this point, mail routing is configured and operational between Exchange 2010 and G Suite.

  1. When migrating users, flip forwarding so that new mail is delivered to the Exchange 2010 mailbox, and not the G Suite mailbox.

With the ODME per-user mail forwarding option, you now need to select to remove forwarding from the target as well as setting forwarding in the source. It is important to remove the target forwarding to prevent the creation of a mail loop.

Office 365 (Cloud Relay)

Office 365 (Cloud Relay)

Caution: The scenario described in this topic isn't supported in Microsoft Office 365 Beta for enterprises.

According to the current Microsoft documentation:

Update your MX record so that all mail destined for your domain will be routed to your new mail server. The instructions from Microsoft found here (login required) talk about how to route mail to the cloud. You will need to just update the MX records to redirect SMTP traffic to your Edge transport server. You can learn more about the edge transport server on https://technet.microsoft.com/en-us/library/bb124701.aspx

The Office 365 mail routing page also provides instructions for different DNS providers.

Since you have decided to route all mail to you new domain first, you also need to make sure your Primary domain is a “Shared Domain.” This will let any email addressed to mailboxes deleted from your Office 365 server to be routed to your new mail server.

To forward any new mail to your new mail system that is routed to Office 365, use the ODME per-user mail forwarding feature as described in the section Setting Up Mail Forwarding. To use the mail forwarding feature, the administrator account must be assigned the “Recipient Management” role, for example:

Add-RoleGroupMember “Recipient Manager” -Member migadmin@example.com

 

Note: When you configure mail forwarding for Office 365 in ODME, the settings will be accessible in the O365 user account page, but not in the Exchange Admin Center.

Related Documents