Solved

migration batch fails in Office 365 Exchange migration from Exchange 2003

Posted on 2014-07-17
6
2,436 Views
Last Modified: 2014-07-27
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
0
Comment
Question by:Reece Dodds
  • 3
  • 3
6 Comments
 
LVL 5

Expert Comment

by:Adam Ray
ID: 40203828
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...
0
 
LVL 7

Author Comment

by:Reece Dodds
ID: 40203887
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.
0
 
LVL 5

Accepted Solution

by:
Adam Ray earned 500 total points
ID: 40205143
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.
0
[Webinar] Disaster Recovery and Cloud Management

Learn from Unigma and CloudBerry industry veterans which providers are best for certain use cases and how to lower cloud costs, how to grow your Managed Services practice in IaaS clouds, and how to utilize public cloud for Disaster Recovery

 
LVL 7

Assisted Solution

by:Reece Dodds
Reece Dodds earned 0 total points
ID: 40213094
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.
0
 
LVL 5

Expert Comment

by:Adam Ray
ID: 40213409
@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.
0
 
LVL 7

Author Closing Comment

by:Reece Dodds
ID: 40222268
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)
0

Featured Post

Is Your AD Toolbox Looking More Like a Toybox?

Managing Active Directory can get complicated.  Often, the native tools for managing AD are just not up to the task.  The largest Active Directory installations in the world have relied on one tool to manage their day-to-day administration tasks: Hyena. Start your trial today.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Microsoft Office Picture Manager was included in Office 2003, 2007, and 2010, but not in Office 2013. Users had hopes that it would be in Office 2016/Office 365, but it is not. Fortunately, the same zero-cost technique that works to install it with …
Read this checklist to learn more about the 15 things you should never include in an email signature.
In this Micro Video tutorial you will learn the basics about Database Availability Groups and How to configure one using a live Exchange Server Environment. The video tutorial explains the basics of the Exchange server Database Availability grou…
This lesson covers basic error handling code in Microsoft Excel using VBA. This is the first lesson in a 3-part series that uses code to loop through an Excel spreadsheet in VBA and then fix errors, taking advantage of error handling code. This l…

911 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

23 Experts available now in Live!

Get 1:1 Help Now