Active Directory Migration – Exchange First

Most Active Directory migrations deal with the consolidation of domains or the incorporation of new business units.

The most important goal of these projects is the possible improvement of cooperation and collaboration.
To achieve that as fast as possible, an Exchange First migration should be considered.

Two Possibilities for Active Directory and Exchange Migrations

If you follow the most frequently used migration strategy, benefits of improved cooperation and collaboration will be achieved very late in the project. The reason is that computers need to be migrated first. In this article I am going to start with comparing the two strategies and then explain “Exchange First” a bit more into detail.

If you want us to help you with your Exchange migration – contact us at firstattribute.com
 

Migrate computers first: the most common migration strategy

1. Migration of the user accounts and groups
2. Migration of the computers > afterwards users are logged onto the target domain
3. Migration of mailboxes
4. Realization of improved cooperation

After the computer migration is completed, the email migration can be started. And finally the advantages of a joint Active Directory Domain/ Exchange Organisation become apparent for the user. But usually the computer migration takes some time. So you have to wait that time to see the projects benefits become real.

With a little trick you can run the email migration before the computer migration, a so called Exchange First migration. This way benefits can already be realized at an earlier stage of the project.
 

Order of the migration steps with “Exchange First”

1. Migration of the user accounts and groups
2. Migration of the mailboxes
3. Realization of improved cooperation
4. Migration of the computers > afterwards users are logged onto the target domain

Exchange First

Exchange First Migration uses a technical feature of Exchange – the Resource Forest.
In a Resource Forest you have deactivated user accounts with mailboxes that are converted into so-called “linked mailboxes”. During the conversion, a “linked master account” with automatic full access to the mailbox is entered. It is the user account from the source domain. Technically, you recognize these user accounts from the SID entered into the attribute “msExchMasterAccountSid“. The mailbox changes its properties “RecipientTypeDetails” from “UserMailbox” to “LinkedMailbox“.

After the migration, users log onto their computers in the source domain with their usual user account and use the migrated mailbox in the target environment.

Quest Migration Manager for Exchange supports this strategy and can automatically set up deactivated user accounts and linked mailboxes. And we support you: Exchange Migration with QMM
 

Known problems

With a „linked mailbox“, all important mailbox functions like shared calendar work normally. Problems can occur when there are already active user accounts in the source domain. That can happen in case of a company-wide application requiring a user account in the target domain. These accounts cannot be provided with a “linked mailbox” because they need to be deactivated. Activated user accounts get a normal “UserMailbox” and no “linked master account” is entered. Thus, the user account from the source domain does not have access. By allocating “full mailbox access” and “send-as” for the source domain user account, the problem seems to be solved, unfortunately only from the outside. As long as the user from the source domain solely works with his or her personal mailbox, everything is fine. Even accessing “shared mailboxes” is possible in case the respective authorizations are set for the account from the source domain. Accessing shared folders like for example calendars, is not possible.

Why? In the authorization for the calendar, the target domain-mailbox is set because only entries from the address book are possible. Authorizing a mailbox from a different Exchange Organisation (source) is not possible. As soon as the authorized mailbox is a “linked mailbox”, Exchange recognizes the user from the source domain by its SID and allows access. Experiments with a “linked mailbox” and a subsequently reactivated user account do not lead to success.
 

Solution

The only solution for already existing activated user accounts in the target domain known to me is configuring the Outlook profile with the option “Always prompt for logon credentials. With that setting, Outlook always asks for user name, domain and password with every start. Here, target domain-user account can be used for logon and Exchange allows access to the mailbox or shared calendar.