3. Moving the Active Directory account using ADMT
ADMT is a great tool for Migrating and Restructuring Active Directory Domains ( user accounts, passwords, groups & group membership, computer accounts & much more.)
However It is very important to note that ADMT DOES NOT touch Exchange attributes.
ADMT can be executed before prepare-move request, after prepare-move request or skipped if we want to use a linked account.
Assuming Prepare-move request was executed first, when executing ADMT we need to merge the account with an existing MEU.
Below are screen grabs of the ADMT wizard. the critical options are highlighted.
If ADMT is run prior to the Prepare-MoveRequest.ps1 script is executed, we would need to execute Prepare-MoveRequest.ps1 with the -OverWriteLocalObject Switch.
Further reading Link
4. The Actual Move of Mailboxes.
MRSProxy or NO MRSProxy
MRSProxy encapsulates all communication between the organizations in HTTPS packets thus making the move seamless.
Assuming the source forest has Exchange 2010 SP2 or above, enable MRSProxy in the source forest.
Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -MRSProxyEnabled $true -MRSProxyMaxConnections 50
Details can be found Here
In the event that the source forest does NOT have an Exchange 2010 server, we cannot use the MRSProxy. So we skip the above step & use the -remotelegacy in lieu of -remote switch in the move command.
Command to Move the Mailbox across the forests ( pull the mailbox from source forest to the target forest )
First save the credentials in two variables:
( target forest )
$LocalCredentials = Get-Credential
( source forest )
$RemoteCredentials = Get-Credential
Then execute the command based on whether the source forest has MRSProxy enabled or not.
- With MRSProxy DISABLED in the source ( even if there is a E2010 server in the source )
- With MRSProxy enabled in the source (on a server e2010.contoso.com )
Note: -RemoteHostName is the E2010 servers where we have enabled the MRSProxy
When the above commands are executed, it will result in the source mailbox turning into a Mail User ( MEU) & the Target Mail User (MEU) into a user mailbox.
User Mailbox> Mail User ( MEU )
Mail User (MEU) > User Mailbox
Having prepared the environment, moving the mailbox should now be a breeze. Given that Moving mailbox is a large topic, so In order to keep this blog concise, I shall jump straight to the command & explain only what is relevant.
Note: Issues to be aware of when moving across forests
- Outlook nickname cache is best cleared ( from the client side )
- Update OAB & replicate to the CAS servers. Have the users wait till it downloads or ask them to manually download the OAB.
- Depending on how end-users have created their outlook rules, it could break. You might need to re-create the outlook rules.
- Shared mailboxes + their users & manager + delegate sets should be moved together. you cannot have a manager in one forest & delegate in a different forest
- This Mailbox pull will result in the source mailboxes being hard deleted. Ensure you have a backup in case you need to retrieve the mailbox
- "Suspend this move when it is ready to complete" option is not available when moving across forest.
5. Ensuring Mail flow between source & target during the co-existence phase.
The Method described below would work fine if we have to migrate all the mailboxes from the source forest to the target forest rapidly & in one scheduled activity. This is because both the source & target forest are authoritative for the same SMTP domain.
This drawback ( of having to move all the mailboxes in one scheduled outage ) would be acceptable if the number of mailboxes is small or the actual move would happen in a short span of time. However this is not a common scenario as most migrations would take several hours if not days or weeks.
In the event that the move of mailbox takes several hours, days or weeks, we would need to have e-mail flowing between the source forest, ( mailboxes which are going to be migrated ) & the target forest ( mailboxes which have already been migrated ) Thus a migrated user can send an e-mail to a user who is yet to be migrated & vice-versa.
The additional steps to achieve this would involve:
1. Add a new accepted domain e.g. @tailspintoys.local in the target forest and also add this domain as a secondary SMTP address to the target forest objects.
Thus we have an additional secondary SMTP e-mail address of firstname.lastname@example.org
set-emailaddresspolicy -id "Default Policy" -enabledemailaddresstemplates SMTP:@tailspintoys.com,smtp:@tailspintoys.local
update-emailaddresspolicy -id "Default Policy"
2. Modify the move command used earlier. Change the TargetDeliveryDomain to tailspintoys.local
e.g. New-MoveRequest -Identity email@example.com -RemoteCredential $RemoteCredentials -TargetDeliveryDomain 'tailspintoys.local' -RemoteGlobalCatalog dcx01.contoso.com -RemoteLegacy
Thus the Target address on the MEU in the source forest after the mailbox is moved will be firstname.lastname@example.org besides the expected proxy addresses.
Once Executed, we will now have the MEU in the source having a target address of tailspintoys.local
3. Create appropriate connectors for mail flow.
In order to have e-mail flowing between the two forests we would need to configure connectors in both the forests. This procedure could vary depending on how the existing mail flow is configured.
Here are the PowerShell commands used in my lab:
source_to_target mail flow
Source send connector
Target receive connector
target send connector
source receive connector
-AuthMechanism 'Tls, ExternalAuthoritative'
-PermissionGroups 'AnonymousUsers, ExchangeServers'
Note1: usage = internet as this would not require authentication.
Note2: RemoteIPRanges is the IP address of the server used in the send connector matching this receive connector. This will result in only the identified server being able to send e-mail over this receive connector.
Note3: For this example I have chosen to create a separate send & receive connector in both the forests. However you could also achieve this by modifying the existing receive connectors instead of creating new receive connectors.
6. Additional configuration needed.
- AutoDiscovery for outlook clients ( also used by free-busy ) Reference link
- Free-busy / Availability information.
- Redirecting OWA across forests
- Linked mailboxes
- Shared / Resource mailboxes