Stage migration and connecting users to Exchange Online mailboxes

of 21 |Stage migration, Exchange and Autodiscover infrastructure | Part 1#2 | Part
35#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
Stage migration, Exchange and
Autodiscover infrastructure | Part 1#2
| Part 35#36
In the current article, we will review the subject of Exchange stage migration and
the issue of configuring new Outlook mail profile for users whom their mailbox was
migrated to the cloud.
The current article, deals with the “theoretical part”, in which we will review the
special characters of Exchange stage migration and, the “problem” that we need to
solve to be able to create a new Outlook profile that will connect the migrated users
to their Exchange Online mailbox.
The next article will include a description of a suggested solution, which can be
implemented.
Exchange Stage migration and Autodiscover infrastructure | The
article series

35#36
The article series include the following articles:
 Stage migration, Exchange and Autodiscover infrastructure | Part 1#2 | Part
35#36
 Connecting users to their Exchange Online mailbox – Stage migration – solving
the mystery | Part 2#2 | Part 36#36
When using the option of Exchange stage migration, the “final destination” is to
migrate all the existing Exchange on-Premises infrastructure to the “cloud mail”
infrastructure but, the migration process, as the name implies, will be implemented
in “stages”.
One of the main characters of Exchange stage migration is, that the mail migration
process will continue for a long period of time such as Weeks or even months.
Throughout the above period, the organization mail infrastructure will be
“scattered” throughout the Exchange on-Premises infrastructure and, the Exchange
Online infrastructure until the mail migration will be completed.

35#36
User mailbox physical location | Exchange stage migration
When we use Exchange stage migration for migrating a specific Exchange on-
Premises user mailbox, the actual meaning of the term – “mailbox migration” is
that, the user mailbox is copied to the cloud (Exchange Online).
The outcome is that after the migration of a specific user is completed, there are
two user mailboxes at the same time.
 One user mailbox that is hosted on the Exchange on-Premises infrastructure.
 One user mailbox that is hosted at the Exchange Online infrastructure.
In this scenario, we want to “connect” the users, whom his mailbox was migrated
(copied) to Exchange Online and, avoid from connecting the users to his “former
Exchange
on-Premises” mailbox.
When we use the option of Exchange Stage migration, after we have migrated a
user’s mailbox to Exchange Online, we will need to create a new Outlook mail
profile that will connect the user to his Exchange Online mailbox.
Creating a new Outlook mail profile | The need for redirecting users
to their cloud mailbox
The main problem is that when we create a new Outlook mail profile, Outlook will
automatically locate the Exchange on-Premises and connect to his Exchange on-
Premises mailbox.
The Outlook client “doesn’t know” that we have a copy of the user mailbox in the
“cloud” (Exchange Online) and, that now he needs to connect to his “cloud
mailbox”!.
Our main challenge is – to find a way that will “tell” Outlook client, how to connect
to his “new Exchange Online mailbox” instead of the existing Exchange on-Premises
mailbox.
The “formal” way of accomplishing this task is – by using an Exchange built-in
mechanism, that will redirect the Autodiscover client to the “cloud infrastructure”
(the user mailbox that is located at the Exchange Online).

35#36
To be able to implement the “redirection mechanism”, we will need to convert the
Exchange on-Premises user mailbox into mail contact that include the E-mail
address that the recipient has in the Exchange Online infrastructure.
Technically, this “conversation process” can be implemented manually, by executing
a set of commands but in reality, the basic assumption is that we will use some kind
of a solution that will help us to automate the conversation process for dozens or
even hundreds of migrated user mailboxes.
The “automation” of this process, can be implemented by using a set of PowerShell
scripts, which will help us to implement the conversation process in which we turn
Exchange on-Premises mailbox into MEU (mail-enabled user).
The purpose of this PowerShell scripts is to:
1. Delete Exchange on-Premises mailbox of users whom their mailbox was
2. Copy the recipient E-mail address.
3. Create a new MEU (mail-enabled user) that has the E-mail address of the users
whom his mailbox was migrated to the cloud + the “onmicrosoft” E-mail address.
After the complication of this step, when we create a new Outlook mail profile, the
Outlook will address by default the Exchange on-Premises server but this time,
because the Exchange on-Premises doesn’t host the user mailbox, the Exchange
on-Premises will “understand” that he needs to redirect the mail client to his “cloud
mailbox” (the onmicrosoft E-mail address).
The Exchange on-Premises will send the redirection message to the Outlook client
as part from the Autodiscover process and, Outlook will start again the
Autodiscover process, by addressing the Exchange Online mail infrastructure.
Sound a little complicated?
Yes, I agree.
From my experience, the main obstacle in this method is that the operation of
“deleting the Exchange on-Premises mailbox” doesn’t sound “right” to most of the
Exchange administrator and, most of the time, the Exchange administrator feel that
they need to find another way for accomplish the task of – connecting migrated
users to their Exchange Online mailbox, without the need to delete the existing
Exchange on-Premises mailbox.

35#36
The poppers of the current article and the next article is to review the special
characters of the Exchange stage migration relating to the subject of connecting
Outlook client to their Exchange Online mailbox by using a method that “bypass”
the “formal method” in which we are required to delete the existing Exchange on-
Premises mailboxes.
Exchange stage migration specific charters
Before we start with the description of the optional solution that we can implement
for – connecting Outlook mail client to their Exchange Online mailbox when using
the Exchange stage migration, lest review base characters of the Exchange stage
migration environment:
1. Copy instead move
Exchange stage migration is based on a concept, in which the user mailbox is
copied from the Exchange on-Premises server to the Exchange Online server. The
meaning is that technically, each of the users who participates in the migration
process has two mailboxes.
One mailbox that is hosted on the Exchange on-Premises server and additional
mailbox that is hosted on the Exchange Online server.
2. Autodiscover “pointers”
When implementing an Exchange stage migration, we don’t update existing DNS
infrastructure.
The Exchange on-Premises infrastructure continues to serve existing Exchange on-
Premises server clients.
As long as the stage migration continues, the Autodiscover infrastructure will
continue to point to the Exchange on-Premises infrastructure.
Stage migration scenario | The duplicated identity of the
migrated users
In the following diagram, we can see that each user that was migrated to the cloud
has a “double identity” + double mailbox.
For example, a user named Alice that her mailbox migrated to the cloud, have a
user account in the On-Premise Active Directory + in the Windows Azure Active
Directory.
Regarding the Exchange infrastructure, Alice has a mailbox that is hosted on the

35#36
Exchange on-Premises server and in the same time, an additional mailbox that is
hosted on the Exchange Online server.
Exchange on-Premises infrastructure | The default Autodiscover
infrastructure
As mentioned, when we implement an Exchange stage migration, the Autodiscover
infrastructure stays the same. The meaning is that an Autodiscover process that is
executed by Exchange client such as Outlook, will “lead” the Exchange client to the
Exchange on-Premises server.
At a first glance, this process seems to be logical, but in a second look, we can see a
passable problem.
After we migrate Exchange on-Premises mailbox to Exchange Online, we need to
create a new Outlook mail profile for the users whom his mailbox was migrated to
Exchange Online.

35#36
In case that we will start the process of “new Outlook mail profile”, Outlook client
will use the standard Autodiscover process, but the problem is that the
Autodiscover process will “lead” the Autodiscover client to the existing Exchange on-
Premises server instead of the Exchange infrastructure.
In the following diagram, we can see that how a user named, Alice that uses the E-
mail address – Alice@o365info.com , locate her Exchange CAS server.
In case that Alice tries to locate his Exchange CAS server from the internal network,
Alice will locate the Exchange CAS server using the Active Directory SCP that
includes the internal name of the Exchange CAS server (exo1.o365info.local in our
scenario).
In case that Alice tries to locate his Exchange CAS server from the external network,
Alice will locate the Exchange CAS server using the Autodiscover process that
implemented in a non-Active Directory environment by looking for a host name
such as – autodiscover.o365info.com
In our scenario, the query for the hostname – autodiscover.o365info.com, will lead
Alice to the Exchange on-Premises Public facing Exchange server.
Preventing the Outlook client from connecting the
Exchange on-Premises CAS server

35#36
The header of this section looks a bit strange but this is exactly what we need and
want to do.
One of the most noticeable tasks in the process of Exchange stage migration, is the
task in which we need to “enforce” users whom their mailbox was already migrated
to the cloud not to connect the Exchange on-Premises CAS server and instead,
connect the Exchange Online server.
The issue in which Outlook client connects the “wrong Exchange server” occurs
because a very simple reason – the “migrated user” doesn’t know that his mailbox
From the Autodiscover client point of view, the Autodiscover infrastructure still
“point him” to the Exchange on-Premises CAS server.
Technically, his mailbox is on the Exchange on-Premises server because if you
remember, when using the stage migration, the Exchange on-Premises mailbox is

35#36
copied to the “cloud” (Exchange Online) and not “moved” to the cloud such as when
using Hybrid environment.
In the following diagram, we can see an example of the process of mailbox
migration when using the stage migration option.
We can see that after the successful compilation of the mail migration, “Alice
mailbox” will exist in two different places – the Exchange on-Premises server + the
Exchange Online server.
Note – at the current time, there is no “Exchange built-in” solution that will help us
to “clean” the trail from the Exchange on-Premises server, by removing the
“Exchange on-Premises server mailbox” and “inform” the user that his mailbox was
migrated to the “cloud”.
The stage migration user mailbox syndrome
Organization user reports about a strange phenomenon in which mail that is sent
to him doesn’t reach his mailbox, but he can send E-mail to external recipients.

of 21 |Stage migration, Exchange and Autodiscover infrastructure | Part 1#2 |
Part 35#36
Here is the simple answer for this problem – when implementing stage mail
migration, the mail routing is updated so, every mail that is sent to the recipient
who includes is “standard public E-mail address” will automatically be forwarded to
the “cloud” (Exchange Online) using the user onmicrosoft E-mail address.
The mechanism of “automatic forwarding”, doesn’t leave a copy of the user
Exchange on-Premises mailbox, but instead, “move” the original E-mail message to
the cloud (the Exchange Online user mailbox).
The result is that after the mailbox migration, every mail that will be sent to the
specific user will “reside” on the Exchange Online mailbox.
In case that we are not implementing the required preparations, the “migrated
user” will continue to connect to his Exchange on-Premises mailbox.
This Exchange on-Premises mailbox is a “legitimate mailbox” and for this reason,
the user can continue to send E-mail to recipients, but mail that will be sent to the
user will be redirected to his “Exchange Online mailbox” and not to his Exchange
on-Premises mailbox!

Part 35#36
The optional solution for Outlook clients in a Stage
migration environment
So now, after we are aware of the passable issue, in which Outlook mail client will
continue to connect to their Exchange On-Premise mailbox instead their Exchange
Online mailbox, the obvious questions are- what we can do for fixing this problem?
The available options for the solutions are classified into two types- server side and
client side.
1. Stage migration | Server-side solution
The solution which described as- “Server Side”, is implemented by using the
following procedure.
 Deleting the Exchange On-Premise mailbox
 Create a new mail enabled user (MEU) that includes the migrated user
primary E-mail address and in the “external E-mail address,” value uses an
additional E-mail address, the Office 365 onmicrosoft E-mail address.

Part 35#36
Sound a little confusing?
The truth that this is really confusing.
As mentioned before, when we use a stage migration, the Exchange On-Premise
mailbox is copied to the cloud.
After we verify that the mailbox was successfully migrated (copied) to Exchange
Online, technically there is no need for the Exchange On-Premise mailbox.
The stage migration process doesn’t automatically delete the Exchange On-Premise
mailbox.
Suppose that after we have read this information, we decide to implement the
procedure in which we delete the Exchange On-Premise mailbox.
Any idea what will happen then?
In case that we delete the user mailbox, when we try to create a new Outlook mail
profile, the Outlook mail wizard will automatically connect to the Exchange On-
Premise server because as mention before, in a stage migration the Autodiscover
infrastructure keeps “pointing” to the Exchange On-Premise infrastructure.
In this case, Outlook client will manage to connect the Exchange On-Premise server,
but because the user mailbox was deleted, the connection attempt will fail.
Don’t forget that the Exchange On-Premise server doesn’t know or “understand”
that the user mailbox was also copied to the cloud (Exchange Online) and for this
reason, the Exchange On-Premise server doesn’t know that he needs to redirect the
recipient to his “cloud mailbox”.
In a scenario in which we only delete the Exchange On-Premise mailbox without
additional preparations such as creating a new Mail enabled user, will cause two
additional problems with the mail flow, because Exchange On-Premise is
responsible to route emails that sent to the user whom his mailbox was migrated
to his “Office 365 E-mail address”.
In case that we “just delete” the Exchange On-Premise user mailbox, Exchange on-
Premise will not know how to handle mail that will be sent to the specific user.
The second operation that we will need to implement is – creating a new mail
enabled user (MEU), that will serve as “representative” for the migrated mailbox

Part 35#36
and will have the “Office 365 recipient E-mail address” configured as the – External
E-mail address.
After we have deleted the Exchange On-Premise mailbox and after we create the
new mail enabled user (MEU), each time that Outlook client will try to connect to
the Exchange
On-Premise server, the Exchange On-Premise will provide the Outlook client his
“new E-mail address”.
For example, Alice is a user whom her mailbox was migrated to Exchange Online.
When Alice connects the Exchange On-Premise, because Alice doesn’t have any
more a mailbox and because Exchange On-Premise has a mail enabled user (MEU)
with Alice details, Exchange On-Premise will “understand” that he needs to provide
Alice her “Office 365 E-mail address”. In our scenario
– Alice@o365info2.onmicrosoft.com

Part 35#36
Note – this “server-side side solution”, can be implemented by using a PowerShell
script that we can download from the Office 365 community web site or additional
option is to write a PowerShell or implemented a manual procedure.
In case that we have implemented the “server side” solution, in which we remove
the Exchange On-Premise user mailbox + create an E-mail Enabled user with the
Office 365 email address the following scenario will be implemented:
When an external mail client tries to create a new Outlook mail profile, the Outlook
client will access the local Active Directory SCP and get the name of available
Exchange servers (the local Exchange on-Premises servers).

Part 35#36
When the Outlook client addresses the local Exchange CAS server, Exchange will
“see” that the user doesn’t have a mailbox and instead, has an E-mail Enabled user.
Exchange server will “understand”, that he needs to send a “redirection message” to
the Outlook client that includes the Office 365 E-mail address (in our scenario –
Alice@o365info2.onmicrosoft.com
The Outlook client understands that now, he will need to start the Autodiscover
process all over again by using the domain name that was extracted from the new
E-mail address.
In our scenario, Outlook will try to look for a host named
– o365info2.onmicrosoft.com and, if he cannot find such host name, he will try to
query the DNS for the following host name –autodiscover.o365info2.onmicrosoft.com
2. Stage migration | “client” side solution
Under the “client side” classification solution, we will implement solutions that will
enable us to change the default Outlook standard Outlook behavior.
The “default Outlook standard Outlook behavior” that we want to change is – the
standard Autodiscover process, in which Outlook client will locate and connect the
On-Premise Exchange CAS server.

Part 35#36
To demonstrate a standard stage migration scenario, let’s use the following
example:
The organization public domain is – o365info.com
A user named Alice that has the E-mail address – Alice@o365info.com , was migrated
to the cloud.
To be able to connect Alice to his Exchange Online mailbox, we will need to find a
solution that will prevent her Outlook client from using the “standard Autodiscover
process”, which will “lead” the Outlook client to the Exchange On-Premise server.
Internal Autodiscover process
In the following diagram, we can see that the “challenge” we are facing, when we
need to create a new Outlook mail for a user whom his mailbox was migrated to
the “cloud” (Exchange Online).
By default, in an Active Directory environment, the Autodiscover client will query
the Active Directory for the name of the local Exchange CAS server.

Part 35#36
In our scenario, we want to prevent the Outlook client from connecting the local
Active Directory.
Let’s supposed that we found a way for “block” Outlook client from connecting the
local Active Directory (number 1).
By default, Outlook (the Autodiscover client) will “revert” to the method in which he
extracts the domain name form the recipient E-mail address and use this domain
name as the host name of the Autodiscover Endpoint.
In our scenario, Outlook client is supposed to query the local DNS for host named –
o365info.com (number 2) and if he does not find an IP, the Autodiscover client will
look for a host named – autodiscover.o365info.com
Theoretically, the DNS server will provide the public IP address of the Public facing
Exchange CAS server.
And again, in our scenario, we want to prevent from Outlook to connect the local
Exchange CAS server because, we want Outlook to start the Autodiscover process
that will “lead” him to the “cloud Exchange server” (number 3).
External Autodiscover process

Part 35#36
In the following diagram, we can see the infrastructure of organization user (Alice)
that wants to create a new Outlook mail profile but this time; the user is located in
a public network.
The difference is that now, the user cannot use the Autodiscover method that is
implemented in an Active Directory environment.
In our scenario, Outlook client is supposed to query the Public DNS for host named
–o365info.com (number 1) and if he does not find an IP, the Autodiscover client will
look for a host named – autodiscover.o365info.com
The public DNS server, will provide the public IP address of the Public facing
Exchange CAS server.
And again, in our scenario, we want to prevent from Outlook to connect the local
Exchange CAS server because, we want Outlook to start the Autodiscover process
that will “lead” him to the “cloud Exchange server” (number 2).
The “client side” solution
The “client side” solution in a stage migration environment includes two options:
Option 1: update local configuration files

Part 35#36
In this option, we change the default behavior of the Outlook client by editing of OS
components – the local desktop registry and the local HOSTS file.
1. The registry updates, will include a new DWORD that will prevent from Outlook
client to use the standard Autodiscover method in an Active Directory
environment.
2. The HOSTS file update, will include a little “cheating” in which we map the
Autodiscover host name to an IP address of Office 365 components that will
redirect the Autodiscover client to the Exchange Online server.
Option 2: using the onmicrosoft E-mail address
Each of the Office 365 users who have an Exchange Online mailbox, have at least
two
E-mail addresses:
The “public E-mail address” such as – Alice@o365info.com
and, the Office 365 E-mail address.

Part 35#36
The Office 365 E-mail address is based on the Office 365 tenet name + the domain
suffix-onmicrosoft.com
In our example, the Office 365 E-mail address of Alice is
– Alice@o365info2.onmicrosoft.com
In a scenario in which we want to prevent users from connecting to the local
Exchange server, we can use a little trick, in which we provide the Office 365 E-mail
address when creating a new Outlook mail profile instead of the “standard E-mail
address”.
For example, in our scenario when we need to create a new Outlook mail profile for
the user Alice (which his mailbox was already migrated to Exchange Online), in case
that we will use the default E-mail address – Alice@o365info.com, the Autodiscover
process will use the domain name – o365info.com and, the result will be that – the
Outlook will connect to the local Exchange CAS server.
In case that we want to “tell” Outlook that we want to implement a different
Autodiscover process, we will use the “other” E-mail address that Alice has –
Alice@o365info2.onmicrosoft.com
When we create a new Outlook mail profile using this E-mail address
(Alice@o365info2.onmicrosoft.com), the Autodiscover process will be implemented in
the following way-
Outlook client, will create a DNS query looking for an Autodiscover Endpoint named
–o365info2.onmicrosoft.com and, in case that he cannot find the IP address for such
host, the Autodiscover process will “move on” to additional DNS query, looking for
an Autodiscover Endpoint named – autodiscover.o365info2.onmicrosoft.com
The host – autodiscover.o365info2.onmicrosoft.com is an Office 365 component that
will redirect the Outlook client to his Exchange Online mailbox.

Part 35#36

Stage migration and connecting users to Exchange Online mailboxes

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Stage migration and connecting users to Exchange Online mailboxes

Similar to Stage migration and connecting users to Exchange Online mailboxes (20)

More from Eyal Doron

More from Eyal Doron (20)

Recently uploaded

Recently uploaded (20)

Stage migration and connecting users to Exchange Online mailboxes