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?
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?
ASKER
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
@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.
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.
ASKER
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)
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...