KB ID 0001419
This post continues from Part-One where we connected both our domain, and on-premises Exchange server to Office 365. Now we will add our public domain, and migrate our mailboxes.
Step 3 Adding Domains to Office 365
Before proceeding you will need administrative access to your public DNS records so you can create new records.
Log into Office 365 > Admin Console.
Add a domain.
Enter your public domain name > Next.
Now you need to create a ‘Text Record” in you public domain, the TTL does not really matter but the TXT value must match exactly.
As below, once created click (Verify).
Ill manage my own DNS records > Next.
We are only concerned with Exchange > Next.
STOP: These are the DNS records you need to create if you want everything to point to Office 365, DO NOT CREATE THEM if you want your mail to still get routed to your on-premises, and you want your Autodiscover to point there. I leave everything pointing to my on-premises server!
So I DON’T create the records (below) unless I’m about to decommission an on-premises Exchange server.
If you DID want all mail and auto discover to route to Office 365 that’s fine BUT change the SPF record that Microsoft gives you to include the public IP of your on-premises server of you may start getting mail blocked.
Microsoft Suggests: “v=spf1 mx include:servers.mcsv.net ?all”
Use: “v=spf1 ip4:220.127.116.11 mx include:servers.mcsv.net ?all”
Test Mail Flow
If you have made any public DNS changes, then before you do anything else, make sure mail continues to flow in and out of your on-premises Exchange organisation as it did before!
Step 4 Mailbox Migration
Log into Office 365 and locate a user to perform a test migration on, then allocate them an office 365 licence.
Then from the Office365 Admin Center > Recipients > Migration > Add > Migrate to Exchange Online > Remote move migration > Next.
Add in your ‘Test user’ > Next.
Supply your Exchange administrative credentials > Next.
Put in your MRS proxy FQDN > Next
Note: You may see the following error
MRS Proxy Error ‘The connection to the server could not be completed’
Give the batch a name > Next.
Select an email address to be sent a migration report, Note: For the test migration I’m leaving it on ‘Manual Complete’ once Im happy I would select ‘Automatically Complete’ > New.
You can view a ‘hight level’ progress, or click the download link;
To view a more detailed report.
Note: You can connect to O365 PowerShell online, and view the migrations from command line like we normally do with an on-premises mailbox migration. See the following link;
Connect to Office 365 Exchange PowerShell
When finished complete the migration.
Viewing the same thing from PowerShell;
Now test mallow in/out from on-premises and from Office365, then make sure mail also flows between on-premises and Office 365 (both ways).
Make sure calendar sharing scheduling also works between on-premises and Office 365 mailboxes.
Once you are happy, you can migrate the rest of the mailboxes.
Related Articles, References, Credits, or External Links
What about licensing?
In what way? For Office 365 you need at least n E1 subscription for a mailbox, for each user.
Thanks for this article!! One question though and my experience with O365 is limited. When an O365 license is assigned it creates an Exchange Online mailbox right then. Would a user then have two mailboxes at that point (before migration), both online and on-prem? Does the migration take that into account and handle that? Thx!
Hi Chris, Yes as soon as you assign a licence the online mailbox is created (well the process starts, sometime it can take a while!) And yes, as long as you are following this migration method, that is taken into consideration, and it’s handled by the hybrid Exchange deployment.
Thanks Pete – this is a great article.
If I move a user mailbox from onprem to O365, does Outlook continue to just work or do I need to create a new profile?
It will continue to work, you don’t need to create a new profile. The only time you would ever need to create a new profile is, if you used a third party tool to migrate mailbox data.
Is there a way to migrate using Powershell in a hybrid environment instead of the EAC?
Yes you need to do it from your O365 PowerShell connection though, connect to your O365 Tenancy using PowerShell. Then use the following syntax
$ONPREMCREDS = Get-Credential
(Enter local DOMAIN\Username and password)
New-MoveRequest -Identity “User-Alias” -Remote -RemoteHostName LOCAL-EXCHANGE.domainname.com -TargetDeliveryDomain domain-name.onmicrosoft.com -RemoteCredential $ONPREMCREDS -BadItemLimit 1000
Thanks for the comprehensive write-up.
Question: is the process reversible if I wanted to get off of Office365?
Yes the option next to migrate TO Office Online it Migrate FROM Office Online.
I new here.
I just wanna know that if I did all setup like AAD connect, and all.
what change I should make in on-premise if I want to keep both on-premise and cloud.
do I have to remove records of on-premise exchange from domain hosting?
my scenario is to make flow from INTERNET—> O365 —> On-premise.
You can (and should) retain your onsite Exchange, mail will flow to office 365, OR on premise, and both cloud and onsite mailboxes will be able to communicate. Where the mail goes is just a DNS exercise.
Hi, Pete. I’m getting ready to do a migration for a small firm (@20 users) from Exchange 2019 on-prem to O365. Your article (and your advice) assumes that we would want to keep the on-prem server after the migration. However, in this case I don’t see any advantage (and see some disadvantages) to keeping the on-prem server.
I understand that I’d have to reconfigure the users’ Outlook profiles on their workstations. Other than that, what would the steps be to remove the hybrid config after the migration so that mail flow would be only through Exchange Online?
Many thanks as always!
Hi Deb, you only need to visit outlook if you use third party software to do the migration 🙂
You don’t have to retain the on premises Exchange server afterwards, most people do though. theres a good M$ Article on decommissioning the on-prem Exchange if that’s the way you want to go.
I did read that article. It states that if you’re using directory synchronization you “must” keep an on-prem Exchange server. Did a little more digging and discovered that the “must” is actually a “if you don’t then you may have to do some direct management of user schema attributes.” This seems to pretty much amount to making sure that the proxyAddresses attribute is properly configured and/or edit it if the user’s email alias changes. I am not afraid! I will proceed with a Hybrid migration and then remove the on-prem Exchange server.
would you mind pasting the article, please?
Thanks and thank you Pete!
Thank you very much, you are a pro!