In Part I of this guide I’ve explained the process of cross-forest migration and the differences between using ADMT first or using Prepare-MoveReuqest.Ps1 script first, I’ve also explained the migration scenario and the current environment.

Starting from this part we will talk about migration challenges and the best way to address these challenges.

 

A quick reminder of the current environment:

 

First Challenge: ADMT First Then Prepare-MoveRequest.Ps1:

As explained in Part I, we need to migrate user accounts and mailboxes from the source forest to the target forest. However in the target forest (tailspin.com) we already have user accounts created manually for users in the source forest (egypt.tailspin.com), so each user in egypt.tailspin.com has two user accounts:

• Primary Account: AD User in the Egypt forest used for Windows logon, email and everything.
• Secondary Account: AD user account created in Tailspin.com forest used for other applications hosted in tailspin, this user used to grant permissions and create profiles on Terminal Service servers.

 

So the main target is we need to use the existing users in the target forest (tailspin.com), the consequences of this decision as follow:

1. We can’t use the script first; the script in this scenario will create a new disabled Mail Enabled User (MEU), and will ignore the existing user account.
2. We will have to run ADMT first to synchronize the password, migrate SID history, and other AD attributes from the source forest to the target forest.
3. We need to provide prepare-moverequest.ps1 with attribute that links the user in the target forest with the user in the source forest, so when the script runs it will merge all the properties from the source account to the target account and will not create a new user.

 

Before going to the detailed steps, let’s see the history and the relation between ADMT and Prepare-MoveRequest.Ps1:

• ADMT and Exchange Attributes: By default ADMT doesn’t migrate Exchange attributes including “mail”, “proxyAddresses”, anything started by msexch. The reason behind that because when ADMT transfers Exchange attributes (e.g. homeMDB, homeMTA, showInAddressBook, msExch*) that will make the target user looks like a legacy mailbox in the target domain. This leaves the target account in an invalid state (e.g. homeMDB still points to the old forest) which is unexpected for the PrepareMoveRequest.ps1 script. To prevent this, Exchange attributes are excluded from ADMT.
• In Exchange RTM, running ADMT first and then running the PrepareMoveRequest script: When a user is created via ADMT, the PrepareMoveRequest script doesn't work since there are no proxyAddresses for the script to match the source forest user with the target forest user (the script is looking for some attributes in the target account and try to match it with the source account).

The recommended approach was to copy at least 1 proxy address using ADMT. Even after doing that and using the -UseLocalObject parameter, the script will only copy the 3 mandatory parameters (msExchMailboxGUID, msExchArchiveGUID, msExchArchiveName). This is not very useful as the other mandatory attributes are not copied.

• In SP1, a new switch has been added –OverwriteLocalObject which mainly designed when running ADMT first scenario. ADMT can copy the SIDhistory, password, and proxyAddresses, and the PrepareMoveRequest script can attach the source account with the target account and sync the other email attributes. In this case, it will copy attributes from source to target, so it's the opposite of UseLocalObject.

 

PrepareMoverRequest.ps1:

The PrepareMoveRequest.ps1 script can identify and match existing accounts in the target forest based on their SMTP address (proxyAddresses attribute).

 

The script will only use the existing target accounts if all the following are true:

• The target account has a value in proxyAddresses which matches one of the proxyAddresses of the source account.
• The target account is a mail enabled user (healthy MEU that can be retrieves with Get-MailUser command, which means it must have mail attributes like 'mail', 'ExternalEmailAddress', etc).
• You need to specify the -UseLocalObject parameter in the script. (and –OverwriteLocalObject)

 

If all these are true, the script will copy further attributes needed (especially msExchMailboxGUID) to the target account so that the move request can process the accounts.

If one of the above items is missing, the script will duplicate by creating a new disabled Mail Enabled User (MEU), and no error will be returned, using the script in verbose mode will let you see the details.

 

Based on that the steps to solve this challenge should be:

1. Select the user or patch of users to be migrated.

2. Delete any Mail Contact for the users in the target forest.

3. Use ADMT to migrate the user account (merge) from source forest to target forest, this is required to get SID History and sync the password.

Once ADMT migration is completed we should have normal user accounts with SIDHistory as the following snapshot:

 

4. Make the user (or patch of users) Mail Enabled User (MEU) (by running Enable-MailUser), setting ExternalEmailAddress matches the same email address of the user in the source forest (this will be the anchor to associate the user in the target forest with the user in the source forest).

The following snapshot shows how to do it for bulk users using (Import-CSV)

 

We have a very simple csv file that contains two fields as the following snapshot:

 

Now we should have a healthy MEU ready for Prepare-MoveRequest, the following snapshot shows the LDAP properties of this user account:

Check the proxyAddresses, mail, and mailNickname.

 

5. Use Prepare-MoveRequest.Ps1 with –uselocalobject and –overwritelocalobject, so the script will use the existing user account and overwrite the attributes in the target account by the attributes in the source account and most importantly migrate all the required attributes, so the MEU is ready to move the mailbox.

Again we can do it for bulk users by using (Import-CSV), the following snapshot shows the command in verbose mode:

Check the first two lines, local account has been found and the anchor (proxyAddresses) has been used to identify it, then Merge will be done, last line indicates that the process is successfully completed.

Now we have MEU ready to move the mailbox.

 

In this part we solved the first challenge, in the next part we will continue with the second challenge before moving to the technical steps of the migration.

 

Exchange 2010 Cross-Forest Migration Step by Step Guide – Part I

Exchange 2010 Cross-Forest Migration Step by Step Guide – Part II

Exchange 2010 Cross-Forest Migration Step by Step Guide – Part III