Carve-Out Migration Guide Part 3: Migration Access Requirements

In Part 1 of this 4 part series, I provided an introduction on how companies undergoing carve-outs can effectively migrate of all their IT resources and services to a new entity. In part 2, I discussed the steps required to establish and maintain Exchange mail-flow coexistence between the Parent and NewCo organizations. Here, we take a deeper dive into migration access requirements.

When requesting access to systems within the Parent company’s IT organization during a carve-out, it’s always best to consolidate the access requests into a single, summarized document. It can appear a bit overwhelming, but going back to the Source administrators with a string of requests and follow-ups such as “Oh and could we also open port 80?” can hurt your credibility and make the admins question what the final limit to your access requirements is going to be. Our experience is that it’s best to “rip the band-aid” and have all of the difficult conversations up-front. Identifying any access requirements that will not be accommodated is also important because it will require a change in Migration tool selection or strategy.

The request requiring the most amount of effort from the Source admins is to isolate all users, groups, and computer objects being migrated in their own Organizational Unit (OU) and mailbox database. From there, a service account must be created (svc_sourcemigrator) with full control and exchange admin rights over that subset of users. This is required for some tools to function, but is also very useful when you need to make changes to objects in the source environment (such as adding SMTP addresses to existing users, creating/modifying MEUs, creating test users, etc.).

Assuming that this first request is granted, here are the remaining access requirements for each migration tool:

Provision Migrator accounts for Binary Tree (E2E) and ADMT, Provision Required Access Rights

  1. Add ADMT Migrator account (Target\svc_targetmigrator) to the Source Local Domain Builtin\Administrators group. (This is not absolutely required and will likely get denied as it’s essentially equivalent to Domain Admin; however it will make things easier if the Source admins will allow it.)
  2. Delegate ADMT Migrator account (Target\svc_targetmigrator) “Read all user information” permission on the OUs containing all computers and users to be migrated.

Create Firewall Exceptions for Binary Tree (E2E) and ADMT

  • Open ports for the ADMT console (From Target network to Source DCs):
    • 389 (TCP): LDAP
    • 1024-5000 (TCP): RPC
  • Open ports for the E2E console: (From Target network to DCs and Exchange):
    • 808 (TCP): Mailbox Replication Service
    • 53 (TCP): DNS
    • 135 (TCP): RPC End Point
    • 389 (TCP): LDAP
    • 3268: LDAP
    • >1024 (TCP): MAPI
    • 88 (TCP): Kerberos
    • 445 (TCP): Microsoft-DS Service
    • 443 (TCP): HTTPS
    • 80 (TCP): HTTP

Domain prerequisites

  • Forest trust configured to use domain-wide authentication.
  • Create a domain local security group in Users container called SOURCE$$$.
    • This specific group (with this specific name) is required for ADMT to audit SID history operations.
    • Members should not be added to this group, otherwise SID history migration will fail.
  • Disable SID filtering to allow for SID migration.
    • Netdom trust SOURCE /domain:Target.net /quarantine:No /userD:SOURCE\<DomainAdministratorAcct> /passwordD:<DomainAdminPwd>
  • Configure Audit Account Management.
    • Open the Default Domain Controllers group policy.
    • Browse to Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Audit Policy.
    • Select Audit Account Management and enable for both Success and Failure.
    • Select Audit Directory Service Access and enable for Success.
    • Click OK and close the Group Policy.
    • Run gpupdate /force on all domain controllers in SOURCE.

 Exchange Prerequisites

  • Run an exchange powershell command to give the E2E migrator account access to the Exchange 2007 metadata
    • Get-Exchange Server | where {$_.IsClientAccessServer -eq $TRUE} | ForEach-Object {Add-ADPermission -Identity $_.distinguishedname -User (Get-User -Identity svc_migrator  | select-object).identity -extendedRight ms-Exch-EPI-Impersonation}

End-user workstation Prerequisites

  • Push the following patch to all user workstations to be migrated:
  • Enable connectivity to all end user workstations (either disable Windows Firewall via GPO or push the file and print sharing firewall exception).

With all of the prerequistes in place, pre-migration staging can begin. Please stay tuned for Part 4 of this series where I’ll document the pre-migration staging process.

Your email address will not be published. Required fields are marked *

Phone: 312-602-4000
Email: marketing@westmonroepartners.com
222 W. Adams
Chicago, IL 60606
Show Buttons
Share On Facebook
Share On Twitter
Share on LinkedIn
Hide Buttons