This blog post will start with an observation.
In my on-premises Exchange environment, I was working with four users that were "mailbox enabled" some time ago:
- Aisha Bhari
- Alan Reid
- Alannah Shaw
- Alex Heyne
***
Note: these users were created with Andy Grogan's script for use in practice environments: Creating LAB users with a Powershell Script
***
That means that I had four mailboxes, one for each of the users listed above (this view is of the EMC Recipients Mailbox section) :
Note: Alex Heyne is not visible but he's there...
When the Hybrid Configuration Wizard is run, a mail user is created for each of them in Office 365. We can see this in the "Office 365 | Mailbox | Mail Contact" section of the EMC (on-premises Exchange server):
Note that these are indeed "Mail Users" even though they exist in the "Mail Contact" section.
Mailbox Migration
When we migrate the mailbox...
- The migrated mailbox replaces the corresponding mail user in Office 365.
- A mail user replaces the migrated mailbox in the on-premises Exchange environment.
Mail enabled users must be distinguished from mailbox enabled users.
Both are associated with an Active Directory account and allow a user to connect to the network.
However, the mailbox enabled user has a local mailbox.
The mail enabled user has a remote (external) mailbox.
In general, this could be a Gmail or Hotmail mailbox.
So, although the user (a consultant for example) could connect to the local network, messages for them would be sent to their externally located mailbox.
In a hybrid migration, the mail user object plays the same role: mail sent to the address in question will continue to be directed to the on-premises Exchange servers (since the MX records have not been changed) but will be redirected to the mailbox migrated to Office 365.
Note that the MX records cannot be changed until ALL the mailboxes have been moved to Office 365. As long as some mailboxes remain on-premises, we have to direct mailflow onsite.
Having provided those clarifications, we can now migrate our first mailbox.
Open the EMC and navigate to Recipient Configuration | Mailbox. Right-click on the mailbox to be migrated and select "New Remote Move Request":
The Introduction presents what will be done. If we have archive mailboxes, we can (optionally) migrate those as well:
In the next step, we have to indicate the "Mailbox Replication service proxy server". I entered the FQDN used for client access (mail.mitserv.net). We also have to enter credentials for the source forest. I used an account with enterprise administrator rights (among others):
We then enter the target domain, in my case: mitservnet.mail.onmicrosoft.com.
Note: mail.onmicrosoft.com is common to all Office 365 / Exchange Online clients.
We have a summary of the operation to be executed:
The wizard is working...
And then completes:
Troubleshooting
That's the way it is supposed to work. In fact, I did not succeed on the first try.
Despite the successful completion message (last screenshot above), the mailbox was simply not migrated. It still appeared among the on-premise mailboxes. Moreover, there was no sign of the mailbox in Exchange Online (Office 365). I attempted the migration once more: same result.
Microsoft Tech Support recommended that I attempt the migration from the command line and then view any error messages. I discovered that when using the command line I could obtain a detailed error message (as opposed to the apparent success message in the GUI).
First, we must establish a connection with Office 365...
We create a variable representing our login credentials
PS C:\> $TenantCreds = Get-Credential
Note: here we would be prompted to enter our credentials which are stored in the variable.
We then enter this command:
PS C:\> $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $TenantCreds -Authentication Basic -AllowRedirection
We will see a message like this (it is strictly informational):
WARNING: Your connection has been redirected to the following URI:
"https://pod51043psh.outlook.com/powershell-liveid?PSVersion=3.0 "
We import the session:
PS C:\> Import-PSSession $Session
Note: at this point, there is a warning about the imported commands. It has no effect on our objective so I will omit the message for concision.
In the following lines, we'll define a variable representing or login credentials once more and execute the command to migrate the mailboxes. We will then see the error message explaining why the mailbox was, in fact, NOT migrated.
PS C:\> $RemoteCredential = Get-Credential
Note: here we supply the credentials when prompted.
PS C:\> New-MoveRequest -id "aisha.bhari@mitserv.net" -Remote -RemoteHostName "mail.mitserv.net" -TargetDeliveryDomain mitservnet.mail.onmicrosoft.com -RemoteCredential $RemoteCredential
You can't use the domain because it's not an accepted domain for your organization [...].
These are my accepted domains according to Office 365:
PS C:\> Get-AcceptedDomain | fl
Name
--------
mitservnet.onmicrosoft.com
mitserv.net
mitservnet.mail.onmicrosoft.com
On-premises I have another accepted domain: mynet.lan
The solution was to remove references to this domain from the "Email addresses" tab in the user's mailbox properties. The change did not seem to take effect immediately since the migration failed once more but finally succeeded on the next attempt.
Thank you for reading the article about Office 365 - Hybrid Migration - Part 5: Mailbox migration on the blog NEW TECH If you want to disseminate this article on please list the link as the source, and if this article was helpful please bookmark this page in your web browser by pressing Ctrl + D on your keyboard keys.