This article presumes that you have setup 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

– Configure Source.com as accepted domain in blue.com

– Install and configure ADMT server at the target domain Target.com

– Install and configure Password Encryption Server (PES) on the source domain Source.com

– Configure MRSProxy on Source and Target CAS Servers (Enabling MRSProxy, Increase limits..etc.).

– 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 have 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 goin 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 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, User don’t have to create a new outlook profile in order to use their target mailbox after migration.

– You don’t have to mailenable user.

Mail Enabling User:

The first step for the migration to work is to Mail enable 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 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

$UserSID = dsquery * -filter “&(objectcategory=user)(samaccountname=$Identity)” -attr objectsid sIDHistory

Write-host User $User.Alias has $UserSID -ForegroundColor Green -BackgroundColor Black

The CSV file format for this powershell should be as following, I will explain why in detail below

Alias,Proxy,NewProxy,NewIdentity
Alias,MailAddress@domain.com,MailAddress@domain.local,NewIdentity

In order for the Prepare-Moverequest to work we will have to MailUser enable this user by using the following script

Enable-Mailuser –Identity SamAccountName –ExternalAddress PrimarySMTPAddress

Enable-Mailuser –Identity Tim –ExternalAddress tim@domain.com

In this case 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 wont get any cache issue reaching to the migrated user and will set other attributes like Displayname, MailNickName..etc like in the screenshot below.

Script is as the following

$TargetCredentials = Get-Credential

 

$RemoteCredentials = Get-Credential

.\Prepare-MoveRequest.Ps1 -Identity UPN@targetdomain.com -RemoteForestDomainController “SourceDCHostname.SourceDC.local” -RemoteForestCredential $RemoteCredentials -LocalForestDomainController “TargetDCHostname.TargetDC.local” -LocalForestCredential $TargetCredentials -TargetMailUserOU “OU=DestinationOU,DC=TargetDC,DC=local” -UseLocalObject -OverwriteLocalObject –Verbose

Prepare-MoveRequest for Bulk mailboxes:

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.

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

Get-MailContact -result unlimited | where {$_.PrimarySmtpAddress -like *@TargetSMTPDomain.com} | select Name,Alias,Primarysmtpaddress,legacyExchangeDN | Export-Csv c:\TargetContacts.csv -notypeinfo -encoding utf8

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.

Import-CSV “C:\TargetContacts.csv” | foreach{Set-Mailbox -identity $_.Name -EmailAddresses @{add=$_.LegacyExchangeDN}}

Hope this helps and if you have any questions in mind please don’t hesitate to contact me at info@moh10ly.com or call me 320-200-9663.

Mohammed JH

In an Exchange Crossforest migration the distribution groups can be a very painful operation that would cause loss of time, lots of issues and continues headache if not solved within a timely manner.

The migration can be a long boring process that needs to be as accurate as possible to avoid any issue related to members in the group or/and Group’s Primary SMTP details.

While doing a Crossforest migration I came through through this headache and tried to seek a script that would satisfy my migration’s requirements but only thing I found is the export Powershell made by Satheshwaran Manoharan.

Export Process:

The script exports all groups and their members from the source forest, but to import there’s no option and I had to write my own script.

To make use of this script first make sure you that you have migrated the Groups with ADMT in the recommended order otherwise the migration would be problematic.

• First: Universal Groups
• Second: Global Groups
• Third: Domain Local Groups

Once groups are migrated to the target forest you can check how they look like through Exchange management shell and whether they have members added or SMTP address set.

After I checked it apparently shows that group is empty and has no Primary SMTP address associated with it.

Import Process:

In order to add members during the migration since this is a Hybrid/Coexistence migration not cutover, It took time to migrate users and therefore I have to add non-migrated users in target forest as External Contacts to the Distribution Groups and add migrated users as Mailbox users.

Then after adding the users I have to setup Primary SMTP address for the groups according to the exported CSV file from the Source Forest.

To Import users, I had to setup a CSV file with the following format:

In this format, the Display name, Alias, RecipientType and PrimarySMTPAddress belong to the User object that’s included in the group meanwhile, The Dgroup is the Distribution group’s Alias and DGSMTP is the Group’s Primary SMTP address.

The following script imports groups members to their relative groups

#########################################################################################

# If user type is Usermailbox then it’ll be in Target forest as a Contact #

#########################################################################################

$Users = Import-Csv “C:\Groups\dgs.csv”

Foreach ($User in $Users){

$GroupAlias = $User.Dgroup

$GroupSMTP = $User.DGSMTP

Write-Host “$User.Alias” has been Added to the Group $User.Dgroup -ForegroundColor Green -BackgroundColor Black

if ($User.RecipientType -Match “UserMailbox”){

Add-DistributionGroupMember -Identity $GroupAlias -Member $User.PrimarySMTP -BypassSecurityGroupManagerCheck}}

Fixing Distribution Groups Primary SMTP Address:

Since distribution groups are mostly imported without Primary SMTP address through ADMT then we’ll have to also make sure that we fix this for our groups, but what if the destination forest has similar groups or the SMTP is used already ? In order to avoid any mistake when associating the Primary SMTP address I have created a script that would check distribution groups with null value in their primary SMTP Address and copy the SMTP address to these groups avoiding any overwrite or change of the destination Distribution groups.

#########################################################################################

# Setup groups with Primary SMTP Address

#########################################################################################

$Groups = Import-Csv “C:\Groups\Group_test.csv”

Foreach ($Group in $Groups){

$GroupAlias = $Group.dgroup

$GroupSMTP = $Group.DGSMTP

if ((Get-DistributionGroup $GroupAlias | {308b10a016e19a1cd6a208cbc3961927e16fc6766a4020d3c4ef54ea17925f0f}{$_.PrimarySmtpAddress}) -match “$GroupSMTP”) {

Write-Host Group $GroupAlias already has $GroupSMTP Setup as primary SMTP address -ForegroundColor Yellow -BackgroundColor Red}else{

Set-DistributionGroup -Identity $GroupAlias -PrimarySmtpAddress $GroupSMTP -EmailAddressPolicyEnabled $False

Write-Host Group $GroupAlias has $GroupSMTP Setup as primary SMTP -ForegroundColor Green -BackgroundColor Black }}

The script will check if the groups has primary SMTP matches the one in the CSV file, if it doesn’t it’ll setup the primary SMTP address for that group with green color like in the below screenshot

You can use this script with the same CSV file that you will use for adding members to the groups too , If groups SMTP exists already you’ll get the following error

Sometimes while we do Exchange projects in big environments where there more than 10 or 15 servers we need to quickly get a particular server’s hostname or IP.

I created a simple PowerShell script that does the work for you

#Get all mailbox Exchange Servers IP address remotely

#Import Exchange Management Shell if ran from PowerShell
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

# Find Mailbox Server Roles
$Servers = Get-ExchangeServer | Where-Object {$_.Serverrole -eq “mailbox”}

# Print Servername and IP
foreach ($Server in $Servers) {Get-WmiObject -Class Win32_NetworkAdapterConfiguration -Filter IPEnabled=TRUE -ComputerName $Server | Select-Object -Property IPAddress,PsComputerName,Name}