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

  • Article

 

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.

  1. 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.

  2. 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.

  3. 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 )

    New-MoveRequest

    -Identity johndoe@tailspintoys.com

    -RemoteCredential $RemoteCredentials

    -TargetDeliveryDomain 'tailspintoys.com'

    -RemoteGlobalCatalog dcx01.contoso.com

    -RemoteLegacy

    • With MRSProxy enabled in the source (on a server e2010.contoso.com )

    New-MoveRequest

    -Identity johndoe@tailspintoys.com

    -RemoteCredential $RemoteCredentials

    -TargetDeliveryDomain 'tailspintoys.com'

    -RemoteGlobalCatalog dcx01.contoso.com

    -Remote

    -RemoteHostName 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.

    Source forest:

    User Mailbox> Mail User ( MEU )

    Target forest:

    Mail User (MEU) > User Mailbox

    Before Move:

    21 Pre Mailbox Move

    Move Command:

22 mailbox move

After Move:

  1. 23 Post mailbox Move

    Note: Issues to be aware of when moving across forests

    1. Outlook nickname cache is best cleared ( from the client side )
    1. Update OAB & replicate to the CAS servers. Have the users wait till it downloads or ask them to manually download the OAB.
    1. Depending on how end-users have created their outlook rules, it could break. You might need to re-create the outlook rules.
    1. Shared mailboxes + their users & manager + delegate sets should be moved together. you cannot have a manager in one forest & delegate in a different forest
    2. 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
    1. "Suspend this move when it is ready to complete" option is not available when moving across forest.

    Additional Reading.

    https://technet.microsoft.com/en-us/library/dd351123.aspx

    https://blogs.technet.com/b/exchange/archive/2010/08/10/3410619.aspx

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 johndoe@tailspintoys.local

  • 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 johndoe@tailspintoys.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 johndoe@fabrikam.local 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

  • new-SendConnector

  • -Name 'source_to_target'

  • -Usage 'Internet'

  • -AddressSpaces 'SMTP:*.tailspintoys.local;1'

  • -IsScopedConnector $false

  • -DNSRoutingEnabled $false

  • -SmartHosts 'ex01.fabrikam.com'

  • -SmartHostAuthMechanism 'None'

  • -UseExternalDNSServersEnabled $false

  • -SourceTransportServers 'ex01.contoso.com'

  • Target receive connector

  • new-ReceiveConnector

  • -Name 'source_to_target'

  • -Usage 'Internet'

  • -Server 'EX01.fabrikam.com'

  • -Bindings '0.0.0.0:25'

  • -RemoteIPRanges '10.10.10.103'

  • target_to_source_and_internet mailflow

  • target send connector

  • new-SendConnector

  • -Name 'target_to_source_and_internet'

  • -Usage 'Internet'

  • -AddressSpaces 'SMTP:*;1'

  • -IsScopedConnector $false

  • -DNSRoutingEnabled $false

  • -SmartHosts 'ex01.contoso.com'

  • -SmartHostAuthMechanism 'None'

  • -UseExternalDNSServersEnabled $false

  • -SourceTransportServers 'EX01.fabrikam.com'

  • source receive connector

  • new-ReceiveConnector

  • -Name 'target_to_source_and_internet'

  • -Usage 'Custom'

  • -Server 'Ex01.contoso.com'

  • -Bindings '0.0.0.0:25'

  • -RemoteIPRanges '10.10.10.11'

  • -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

  • I hope to cover these in future blogs, time permitting.

  • Additional Reading Link1 Link2 Link3

  • Thank you for reading this far & I hope this blog was useful for your cross-forest migration.

  • Next Blog: How Groups can be migrated across forests & what kind of issues can crop up.