stage migration, exchange and autodiscover infrastructure | part 1#2 | part 35#36

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

http://o365info.com/stage-migration-exchange-and-autodiscover-infrastructure-part-1-of-2-part-35-of-36


https://il.linkedin.com/in/eyaldoron1

http://o365info.com/

http://o365info.com/connecting-users-to-their-exchange-online-mailbox-stage-migration-solving-the-mystery-part-2-of-2-part-36-of-36


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 – [email protected] , 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

– [email protected]






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 server\s (the local Exchange on-Premises server\s).






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 –

[email protected]

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 – [email protected] , 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 – [email protected]

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

– [email protected]

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 – [email protected], 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 –

[email protected]

When we create a new Outlook mail profile using this E-mail address

([email protected]), 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, exchange and autodiscover infrastructure | part 1#2 | part 35#36

Documents