Sunday, January 11, 2015

Office 365 - Hybrid Migration - Part 5: Mailbox migration

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...

  1. The migrated mailbox replaces the corresponding mail user in Office 365.
  2. 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 ( 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:

Note: 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:


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 -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:
" "

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 "" -Remote -RemoteHostName "" -TargetDeliveryDomain -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



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.

1 comment:

  1. "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."

    Update: this may no longer be a limitation.