Skip to content

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

The article series include the following articles:

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 an extended period such as Weeks or even months.

Throughout the above time, the organization mail infrastructure will be “scattered” throughout the Exchange on-Premises infrastructure and, the Exchange Online infrastructure until the mail migration completed.

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 particular user is completed; there are two user mailboxes at the same time.

  • One user mailbox that hosted on the Exchange on-Premises infrastructure.
  • One user mailbox that is hosted on 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 “previous 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 primary 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 located at the Exchange Online).

To be able to implement the “redirection mechanism”, we will need to convert the Exchange on-Premises user mailbox into mail contact that includes 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 underlying assumption is that we will use some 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 perform 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 migrated to the cloud.
  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 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 of the Autodiscover process and, Outlook will starts again the Autodiscover process, by addressing the Exchange Online mail infrastructure.

Sound a little complicated?

Yes, I agree.

From my experience, the biggest 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.

The poppers of the current article and the next article is to review the particular 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 builds on a concept, in which the user mailbox 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 hosted on the Exchange on-Premises server and additional mailbox that 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 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 Exchange on-Premises server and at the same time, an additional mailbox that hosted on the Exchange Online server.

Stage migration scenario -The duplicated identity of the migrated users

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 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 possible 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 migrated to Exchange Online.

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

Exchange on-Premises infrastructure -The default Autodiscover infrastructure

Preventing the Outlook client from connecting the Exchange on-Premises CAS server

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 migrated to the cloud.

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 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 migrated to the “cloud”.

Stage migration - The user mailbox is only copied to the cloud and not moved to the cloud

The stage migration user mailbox syndrome

Organization user reports about a strange phenomenon in which mail that sent to him doesn’t reach his mailbox, but he can send E-mail to external recipients.

Here is the simple answer to this problem – when implementing stage mail migration, the mail routing is updated so, every mail that 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 sent to the particular 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 send to the user redirected to his “Exchange Online mailbox” and not to his Exchange on-Premises mailbox!

The optional solution for Outlook clients in a Stage migration environment

So now, after we are aware of the possible 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 classified into two types- server side and client side.

The optional solution for Outlook clients in a Stage migration environment

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.

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 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 for routing 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 send to the particular user.

The second operation that we will need to implement is – creating a new mail-enabled a user (MEU), that will serve as “representative” for the migrated mailbox 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 migrated to Exchange Online.

When Alice connects the Exchange On-Premise, because Alice doesn’t have anymore 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

Note: This “server-side side solution”, can be implemented by using a PowerShell script that we can download from the Office 365 community website or additional option is to write a PowerShell or implemented a manual procedure.

The optional solution for Outlook clients in a Stage migration environment - Server Side Exchange On-Premise

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

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

The optional solution for Outlook clients in a Stage migration environment - The redirection process

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.

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

In our scenario, we want to prevent the Outlook client from connecting the local Active Directory.

Let’s supposed that we found a way to “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 from the recipient E-mail address and uses 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).

Scenario 1 - Stage migration - Internal recipient need access to his Exchange Online mailbox

External Autodiscover process

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 located in a public network.

The difference is that now, the user cannot use the Autodiscover method that 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).

Scenario 2 - Stage migration - External recipient need access to his Exchange Online mailbox

The “client side” solution

The “client side” solution in a stage migration environment includes two options:

Option 1: update local configuration files

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 hostname to an IP address of Office 365 components that will redirect the Autodiscover client to the Exchange Online server.
The optional solution for Outlook clients in a Stage migration environment - Client Side User Desktop

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.

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

The optional solution for Outlook clients in a Stage migration environment
o365info Team

o365info Team

This article was written by our team of experienced IT architects, consultants, and engineers.

This Post Has 0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *