migration batch fails in Office 365 Exchange migration from Exchange 2003

I'm attempting a Staged Migration from Exchange 2003 on-prem to Office 365's Exchange Online and I think I have all of the preparation complete yet the migration batch I've created (just one mailbox) fails with the error "A valid source email address ourdomain.onmicrosoft.com couldn't be found on the target."

I have searched for information on this and most results point to the need for the Exchange Online domain(s) to be added as a UPN on our Exchange 2003 AD and SMTP addresses for the Exchange Online to be added to the users that are being migrated.  I've done this and it still fails with the same error.

I had a suggestion by Alan Hardisty that maybe our domain hasn't been set as the default domain in O365.
I've checked and it is, but the status says "setup in progress" (screenshot below).  When I click "complete setup" and go through the steps, the only thing remaining is to add the MX record for O365.  Surely I don't want to do this until the staged migration is complete right?

Am I missing an important step in my on-prem preparation or in the migration batch creation?

domains section
Reece DoddsAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Adam RayCommented:
How many mailboxes do you have to migrate?

Getting the migration tools to work properly can be a huge pain. Depending on the number of mailboxes you have it may be easier/faster to do each mailbox individually/manually.

It may not be an elegant solution, but if it makes more sense in your situation...
Reece DoddsAuthor Commented:
roughly 85.
I managed to get one migrated successfully shortly after I posted this question - it was a brand new account I created on-prem and in the cloud purely for testing.
I am now retrying my 1.2GB account now (after making the necessary changes) and will report back.
One thing I did notice when testing the successfully migrated account in OWA is that while the account can send email to external addresses (gmail etc), it cannot send emails to accounts on the same exchange domain (that are still on the on-prem server).  
How do I overcome this problem?  Is it as simple as having all of the users with O365 user accounts as well as on-prem?  Because I currently only have two O365 user accounts... the one that has successfully migrated and the one (my account) that is migrating now.
Adam RayCommented:
With that many mailboxes, it may be worth trying to get the migration tool to work.

I've migrated a handful of domains/accounts from SBS/Exchange 2003 to O365. Most of them had a dozen or less mailboxes. There are several ways to do it and the way I do it can be modified slightly to work with the batch migration tool. But it may or may not be the best choice for your situation. For what it's worth, the routine that caused the least amount of friction for me is as follows:

(Disclaimer, this is not a step by step, just a rough outline. There are implications to email flow and mailbox availability so be sure to be comfortable with the details before you start making changes.)

Prep work:
After the public domain is setup in O365 and set as the default domain, set MX records back so that mail is directly delivered to your on-premise server.
Create a send connector (in O365) that routes all email being sent TO the internal domain of your on-premise server (e.g. ourdomain.local) via a smarthost (the public IP of your on-premise server.)
Optional step (because DNS delivery should work just fine) but helpful to see the symmetry: Create a send connector on your on-premise server to route all mail sent TO ourdomain.onmicrosoft.com directly to the one of the MX servers already setup for that domain.
Create all mailboxes, dist groups, etc. in O365 with @ourdomain.com as the primary email address and @ourdomain.onmicrosoft.com as a secondary address.
In 0365, create one contact for every mailbox, dist group, etc. who's "external" address is the internal address of your on-premise server. E.G. If the user's email is userone@ourdomain.com create a contact who's name is onsite-userone and who's external email is userone@ourdomain.local. Set it to hide from Address Lists if you like. (I prepend this contact's name with 'onsite-' so that it is guaranteed to be unique and so they group together alapbetically for easy reference.
Repeat the previous step on your on-premise server, but name the contact o365-userone and set its external address to userone@ourdomain.onmicrosoft.com
In O365, set all mailboxes, dist groups, etc to forward (not keeping a local copy) to its associated contact. E.G. In 0365, userone@ourdomain.com forwards to the internal-userone contact (userone@ourdomain.local).

Steps to perform when migrating each mailbox individually/manually (again, can be modified for use with the batch migration tool):
In O365, turn off the forwarding from userone to internal-userone. (Wait until the individuals user's mailbox migration is complete before deleting the internal-userone contact, so that you can quickly re-enable the forwarding if you have to roll-back their migration.
On your on premise server set userone's mailbox to forward to the O365-userone (userone@ourdomain.onmicrosoft.com) contact and not keep a local copy.
On the user's computer:
use Outlook to export their mailbox to a PST.
Create a new default Outlook profile and connect the user to the O365 account/service. I always use cached exchange mode/tell outlook 2013 to "all" mail available offline, it is important for the particular way I migrate users. (This step can cause hangups, especially depending on what your autodiscover settings are, so don't plan on being able to always sail through this step.
Use Nirsoft's NK2EDIT if you want to migrate the autocomplete cache. Be sure to delete all non SMTP entries before migrating.
Put Outlook into offline mode; import the PST into the new Outlook profile. (Outlook will be unresponsive while it is copying/importing to the local OST.)
Put Outlook back online so it will sync the imported/copied mail up to the Exchange server. (Be prepared for Outlook to be unresponsive for as long at the total upload/sync takes.--In theory it should do it in the background in the real world I found it tied up Outlook at least half of the time. Users can use O365 webmail during this time.) Also be sure to pay attention to how many syncs/uploads you have going at once as to not overload your upstream Internet bandwidth.
Reconfigure mobile devices to work with O365.

After everything has been migrated:
Change MX records again so that mail goes directly to O365.
Follow procedures for retiring your on-premise server and removing Exchange form AD.
Cleanup any of the remaining "temporary" contact forwards.

Notes: This process can streamlined and/or email can be routed using not authoritative connectors. But, for me at least, taking the little bit of extra time to work through the process of the symmetrical contacts to forward email between the two systems during the migration prevents other complications and helps keep track of progress.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
The Ultimate Tool Kit for Technolgy Solution Provi

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy for valuable how-to assets including sample agreements, checklists, flowcharts, and more!

Reece DoddsAuthor Commented:
Thanks for the tips.

I'm successfully progressing through and am now about 50% through.
It turns out that the error/problem this question is about was actually that my account (the first Exchange Online account) was created incorrectly in the portal and as such, was failing.  I deleted it and started fresh by creating the User in O365 admin (rather than creating a "contact" in Exchange admin - which is where I think I went wrong).
I assigned an EO license to the user and then switched to Exchange admin and restarted the migration batch.
It completed successfully.

I have been systematically using small migration batches to import users into O365 each week night by using a CSV to create the user accounts in O365 and a CSV for the migration batch.  
Some users have been migrated not using a batch though.  For these users, I created their O365 account then followed your export (using Outlook) from on-prem to PST > create O365 profile in Outlook > import PST.  For this method, I needed to us the asdiedit.msc tool on the on-prem server to change the TargetAddress to SMTP: user@domain.onmicrosoft.com.

One other thing I note with the staged migration that is important, if you are keeping some user mailboxes functioning on the on-prem server whilst other users are being migrated...  in order for email from the O365 Exchange to deliver to the on-prem Exchange, you should NOT create O365 user accounts for the users staying on-prem until you are migrating them.  You also need to change the default domain in O365 (ie. domain.com) from Authoritative to Internal Relay (ignore the message about creating an Outbound Connector - this is only required if you have changed your MX records to point to O365 - which you haven't).

Once all mailboxes have been migrated to O365, you change the MX records and change the domain type back from Internal Relay to Authoritative.
Adam RayCommented:
@reecem27 As an FYI for someone reading this thread in the future: In the last couple paragraphs of your comment when you spoke about note creating the users in O365 until you were actively migrating them and setting the domain as an Internal Relay...

That is one of the other ways of the "several ways" I referenced but did not describe. It's probably even a more popular way of doing it than they way I described. It's a bit easier as there isn't as much "bookkeeping" involved for every mailbox migration, but I stopped doing it that way because--at least in my experience--that approach can be a bit more glitchy during the migration. (I don't want to get into writing another novelette about it, but most of the glitches come from the Outlook clients of users yet to be migrated (e.g. GAL doesn't update, they send emails via the old MAPI addresses in their autocomplete cache that no longer exist--because the on-site mailbox has been deleted after the migration, etc.)

...But if that process worked for you, great!

P.S. One thing to be aware of no matter what process you used to migrate: In general a user will not be able to "reply" to an email received before they were migrated if the recipient is another internal user. The message will bounce back. Consider this simplified scenario:

You migrate your entire organization from on-premise exchange to O365 at 12am Sat morning. Monday morning UserA sees an email that he received from UserB at 10pm Friday and an email received 8am Sun morning. UserA (separately) replies to both emails. The 10pm Friday email will bounce, the 8am Sun email will get delivered. (If UserA looked back in their history and replied to an email sent by UserB 6 months ago it would also bounce.) The reason is that when you migrate to O365 the "hidden" MAPI address changes and the old one no longer exists (and the MAPI address is embedded in the email FROM field, i.e. not stored as an SMTP address or looked up on the fly.) I have heard talk of being able to add the "old" MAPI address to all users via a recipient policy (in older versions of Exchange,) but even if it is possible in O365 (only chance would be through Exchange PowerShell) I'm sure it would be a huge pain in the *** to get it working. I just tell people "If you reply to an email from before the migration date (that is going to an internal user) you must delete their address that gets pre-populated in the TO field and retype it.) Note: Reply to pre-migration emails that are sent to external address go through without any issue.
Reece DoddsAuthor Commented:
Your tips helped a lot - especially for the export>import method.  This was useful when the account migration needed a higher bandwidth for the upload than the migration tool allowed (ie. it'd do a 1GB mailbox in 2hrs rather than 9hrs - we only have a 90KB/s upload)
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Office 365

From novice to tech pro — start learning today.