Freigeben über


Moving to a new forest and retaining the same SMTP domain ( with native scripts ) - Part I

The purpose of this blog is to document how a cross-forest migration is done with native Exchange 2010 tools. Another reason I am writing this blog is that I did not find this method documented either in the Microsoft community content nor on the internet. ( Same SMTP domain but Different AD Domain / forest )

This Blog is a meant to be very concise & to the point article on how to go about the migration using built-in tools like ADMT & Prepare-MoveRequest.ps1 script which can be freely downloaded from the Microsoft website & is included with Exchange 2010 Service Pack 1 respectively.

This Method of co-existence & migration could be classified as Short co-existence with a One-way GAL synchronization.

To start with we need to get some basics crystal clear.

1. Some Basics

a. proxyaddresses & targetaddress

proxyaddresses is the main attribute where e-mail address information is kept. When you open the properties of a recipient in Outlook and look at the "E-mail Addresses" tab, you are looking at this attribute. This is a multi-valued string containing all the addresses that represent the recipient.

e.g. SMTP:user101@tailspintoys.com, smtp:johndoe@tailspintoys.com,X400:c=US;a= ;p=contoso;o=Exchange;s=user101

clip_image002

targetAddress

In contacts and mail-enabled users (MEU) this attribute will point to a mailbox outside the Exchange organization, for example, to a Hotmail account or to another's company address.

clip_image004

Source & for further reading : Link

b. Mail Enabled User ( MEU )

Also Known As: Mail User /Mail-Enabled Active Directory user.

A mail user is similar to a mail contact, except that a mail user has Active Directory logon credentials and can access resources. Thus a MEU represents a user outside the Exchange organization. Each mail user has an external e-mail address. All messages sent to the mail user are routed to this external e-mail address & for this it uses the targetAddress attribute mentioned earlier in this Blog.

A MEU does not appear different from a mailbox in the GAL.

Source & further reading Link , Link ,Link

 

2. Preparing for the actual mailbox move to the target forest.

To move a mailbox from an Exchange 2003/07/10 Server to another Exchange 2010 forest, the target forest must contain a valid mail-enabled user (MEU) with a specified set of Active Directory attributes.

There are several ways to Create this MEU in the target forest ( ILM/ FIM / Custom Scripts / Prepare-MoveRequest.ps1 )

For a list of mandatory & optional attributes see this Link. In this blog I shall cover only the Prepare-MoveRequest.ps1

Prepare-MoveRequest.ps1

When executed some of the things this Script does is:

a. Creates a disabled "Mail User" in the target forest & copies proxyaddresses attribute from the source forest to target forest. ( besides other attributes )

b. Stamps the targetaddress attribute of the target object.

c. Append the LegacyExchangeDN value from the source forest object as a X500 Proxy address of the target object.

d. Append the LegacyExchangeDN value from the target forest object as an X500 Proxy address of the source object.

 

Lets take a look at each of these points in more detail.

a. Creates a disabled "Mail User" in the target forest & copies proxyaddresses attribute from the source forest to target forest. ( besides other attributes )

The following diagram shows the output when Prepare-MoveRequest.ps1 is executed.

3

The following diagram shows the Mail User created in the target forest.

 

4

The following diagram shows the disabled Mail User in the target forest.

 

5 - highlight the fabrikam part

The following diagram shows the LegacyExchangeDN attribute of the Mail User in the target forest.

6

b. Stamps the targetaddress attribute of the target object.

The following diagram shows the targetaddress attribute of the Mail User in the target forest.

7

c. Append the LegacyExchangeDN value from the source forest object as a X500 Proxy address of the target object.

The following diagram shows the LegacyExchangeDN from the source forest being appended as the x500 Proxy address in the target forest.

8

The following diagram shows the x500 proxy address on the target MEU

9

d. Append the LegacyExchangeDN value from the target forest object as an X500 Proxy address of the source object.

The following diagram shows the LegacyExchangeDN from the target forest being appended as the x500 Proxy address in the source forest.

10

The following diagram shows the LegacyExchangeDN from the target forest as a x500 proxy in the source forest.

11

The following diagram shows the empty targetAddress in the source forest.

12

Syntax:

.\Prepare-MoveRequest.ps1 -RemoteForestDomainController dcx01.contoso.com -RemoteForestCredential $RemoteCredentials -LocalForestDomainController dc01.fabrikam.com -LocalForestCredential $LocalCredentials -TargetMailuserOU "OU=mig,DC=fabrikam,DC=com" -verbose -identity johndoe

You need to define $LocalCredentials & $RemoteCredentials before executing the above command.

For this we can use:

(Target Forest )

$LocalCredentials = Get-Credential

(Source Forest )

$RemoteCredentials = Get-Credential

Note: In the examples shown above, Contoso.com is the Source forest & Fabrikam.com is the target forest. @tailspintoys.com is the SMTP domain used in both the source & target forests.

( It is advisable to use the -verbose switch to log any possible warning & errors. )

Important considerations:

a. A very critical point to note is that by adding the LegacyExchangeDN value as an X500 proxy address in the opposing forests, ensures that replying to any e-mails prior to the migration will not result in an NDR. ( Exchange does not necessarily use the SMTP address when replying to e-mails from internal users )

b. This Script DOES NOT copy the password & the SID ( For that you need to use ADMT).

c. Prepare-MoveRequest.ps1 should be run prior to ADMT. Thus ADMT would need to be executed with the "Migrate and Merge Conflicting Objects" option selected. ( more details in ADMT section )

d. If executed for all users in the Organization, this can effectively be used to populate the GAL in the target forest prior to moving the mailbox from source to target.

As seen in the Below screenshot, a MEU is not distinguishable in the GAL of the target forest )

13

For further reading on the Prepare-MoveRequest.ps1 script see Link

…To be continued in Part II

Moving to a new forest and retaining the same SMTP domain ( with native scripts ) - Part II

Comments

  • Anonymous
    January 01, 2003
    Linked mailboxes are ideally used when the AD account & mailbox are sitting in seperate forests. you do not need to use linked mailboxes when both are in the same forests. From what you describe, Domain A & B are in a single forest so no need for linked mailbox.

  • Anonymous
    November 23, 2012
    Thanks for sharing the thoughts to deal the special case

  • Anonymous
    January 09, 2013
    Thanks a lot for sharing. It´s really an excellent guide (the best I have found) I have to migrate same way (Exchange 2010 to Exchange 2010), but AD user will be migrated to a child domain A and mailbox to a different child domain B. Then linked mailbox will be required. How should I address it? Thanks for you time replying

  • Anonymous
    August 11, 2013
    how can we can we migrate Security groups and distribution groups in cross forest and how coexistence will happen

  • Anonymous
    February 23, 2016
    I am looking to move my mailboxes from 2010 to 2013. I'm being brought in late to this migration and am looking to see what my options might be.

    If I someone has already stood up User accounts (not disabled user not mail enabled) and contacts for the source mailboxes (for mail flow,) will I have to delete the contacts (exporting out the legacyexchangeDNs to apply to the target mailboxes) in order to run this prepare script? I am betting that I would need to remove the target orgs contacts since the SMTP addresses will conflict with the source mailboxes primary address.
    Will the prepare script negatively modify the target user accounts or is it better to use ADMT? Will ADMT change the user accounts so that they can't be used? (the new target forest AD accounts are in use now.) Does the new version of ADMT play nicer with Exchange migrations?

    Any help would be appreciated.