In a Cross Forest, the steps to migrate users are quite complicated and even in the official articles of Technet there is no clear recommendation on which approach to take .. From an experience, I mention and simplify which way to go and how to use Powershell to make your life easy in such projects.

This article presumes that you have set up all the initial steps for the Cross Forest migration to work:

– Configure DNS resolution and trust between two AD forests.

– Create and configure Send connector between Source.com and Target.com

– Create and configure Availability service between Source.com and Target.com

– Configured Public Certificates between both CAS Servers or installed self-signed CA certs.

In order for two Cross Forest Exchange users to send an E-mail to one another before or during Cross forest migration; Each forest has to have the other forest’s users as external contacts on their Exchange environment to ease the finding of any particular user in that other organization and avoid X500 errors after the migration. During the migration, this process is critical and very important to be up to date in order to not mess users included in distribution groups before, during and after user migration from source to target forests.

For Cross Forest user migration, User has to be prepared via Microsoft’s own prepare-moverequest Powershell which is included in the $Exscript directory that prepares the target user’s attributes (Before or after ADMT copy) for the migration using the Powershell script new-moverequest.

However, before that user is migrated and before doing the prepare move request the user must have their user object mail user enabled in order to get all the proper attributes for the move request to work which means the Contact has to either be deleted or lose the SMTP which is going to be enabled on the mail-enabled user.

For this process and in a big environment a tool, 3rd party or a script must be used to hasten the migration of users otherwise it would take ages and would be a very problematic process.

User Creation

Using ADMT then Prepare-Moverequest script

Starting with the creation of target user using ADMT or by Prepare-MoveRequest Script, If ADMT is used prior to PrepareMoveRequest. The target user will have exchange attributes migrated and mail-user enabled by default but due to some incomplete or incorrect attributes, the user will most probably have a corrupted mail user object that needs to be disabled and re-enabled with the proper mail address.

Using Prepare-MoveRequest before ADMT

In the case of using Prepare-Moverequest the user will be created in the target forest properly without any issue but will not have their SIDHistory copied so after the creation of the user account ADMT must be used to copy user’s SIDHistory with Exchange attributes excluded.

Note:

– This method has an advantage over using ADMT first, Users don’t have to create a new outlook profile in order to use their target mailbox after migration.

– You don’t have to mail-enable the user.

Mail-Enabling User

The first step for the migration to work is to Mail enable the user in the target forest. Assuming you have a user called tim@source.com the user gets his AD Object copied to the target forest with ADMT and user gets his UPN changed from tim@source.com to tim@target.local automatically, still the user will get his SIDhistory and the Groups he’s in if groups are migrated prior to that, however, in some rare cases that I have seen while doing this kind of project the SIDHistory might not get copied and you might not notice that unless you take a very close look at the log that ADMT is generating for you.

In the script I am attaching below and prior to preparing the user for migration, I added a script to bulk check user list for SIDHistory. The script below will disable mailuser that’s migrated with ADMT and show you their SIDHistory attribute in order to double check before you migrate their mailbox.

$Users = import-csv -path “C:\List\List1.csv”

foreach ($User in $Users)

{

$Identity = $User.Alias

$UIdentity = $User.Sam

$Mail = $User.Proxy

$NProxy = $User.NewProxy

#Before Migration, Show if user has SIDHistory or Not, If not don’t migrate User

In this case, the user will be ready for the prepare moverequest script to work and get his source Exchange attributes to be copied to the target one.

Prepare-MoveRequest for Single mailbox

The Prepare-Moverequest Powershell is pretty easy to use for a single user and all you need is to enter target and Remote credentials in a variable to use it with the command.

Once you use the script it’ll copy the source user and their Exchange attributes including Proxy Addresses, it’ll convert the LegacyExchangeDN into X500 address in the target user’s mailbox object so users in the source forest won't get any caching issue reaching to the migrated user and will set other attributes like Displayname, MailNickName..etc like in the screenshot below.

CSV Example:

Identity

Outlook.user@SourceSMTPDomain.com

Outlook.user2@SourceSMTPDomain.com

Outlook.user3@SourceSMTPDomain.com

Once the list is ready and you run the Powershell script the target CAS server would connect to the source CAS and start migration as in the following screenshot.

Once users migration is finished, On the source forest user will be converted to MailUser so non-migrated users in the source forest will still be able to send emails to this user, however, the Groups on target forest must be manually maintained and updated with users that are being migrated.

– Contacts Issue

In the target forest those two migrated users were already contacts there prior to migrating them and thus Target Forest users who have sent those two users email have the LegacyExchangeDN Address of those contacts cached in their Outlook in X500 format which will create an issue if those contacts are deleted without exporting their LegacyExchangeDN and add it to the migrated users’s ProxyAddress Attributes.

Prior to deleting those contacts, From the Target Forest, I have exported their info to CSV with the following attributes.

Name, Alias, PrimarySMTPAddress and LegacyExchangeDN Attribute using the following Powershell script

The PowerShell will export contacts in the following format and in order to import them you’ll need to bulk edit the file using Notepad or Notepad++

In notepad replace “/o= with X500:/o=

and Replace all “ with nothing

After you save the file in the target forest, Only in the condition of migrating Source users to the target forest use the following script to Import those users’ LegacyExchangeDN as X500 to their migrated Mailbox objects.

Featured Post

Has cyber security been a challenge in your government organization? Are you looking to improve your government's network security? Learn more about how to improve your government organization's security by viewing our on-demand webinar!

If you, like me, have a dislike for using Online Subscription anti-spam services, then this video series is for you. I have an inherent dislike of leaving decisions such as what is and what isn't spamming to other people or services for me and insis…