Carve-out migration guide part 5: Phased migrations

Here, in the final part of the series, I'll document the steps involved in each phased migration.

With all of the preparation work complete, it's finally time for the fun part: actual migrations. When dealing with more than 50 users, it usually makes the most sense to break the users into chunks and migrate each chunk in separate phases. This is largely due to support requirements; no matter how much preparation or testing is done beforehand, some users will encounter issues post-migration. It's typical to have users who have trouble logging in, or some third party applications that don't handle the user profile migration well. IT support staff should be expecting a larger-than-normal call volume on the morning after each migration and ideally they will be on-site to provide desk-side support.

With these considerations taken into account, the phased migrations are executed as follows:

STEP 1: Prepare to Migrate Workstations

The first step is to identify the list of machine names to be migrated and ensure that it matches a physical inventory taken by the on-site resource. It is very helpful for the on-site resource to create a map of where all of the machines are in order to quickly find any computers that are having issues. In order to minimize any failed migrations, a pre-flight check should be executed to check for any issues known to cause problems with ADMT migration. I've used a pre-flight script that checks the following:

• Communication via ping

  • Any computers not responding need to be tracked down by an on-site resource to determine the cause. They are typically asleep or powered off.

• Free Disk Space

  • ADMT requires 1 GB of free space in order to perform the migration.

  • Additionally, if the workstations are being patched post-migration (recommended), then there must be enough free space to accommodate all Windows Update packages.

• Necessary Windows XP hotfixes

  • If any of the following hotfixes are missing on Windows XP, the workstation migration will fail.

    • KB944043 - Netlogon Update for Environments with RODCs (required in order for ADMT to migration XP systems, even if RODCs are not deployed) http://support.microsoft.com/kb/944043

    • KB944505 - DFS Client Update http://support.microsoft.com/KB/944505

    • KB968730 - Crypto Engine Update to Support SHA256 Certificate Enrollment http://support.microsoft.com/kb/968730

    • KB2535512 - Security Update for DFS Client http://support.microsoft.com/kb/2535512

Once all machines are responding, patched, and showing enough free disk space, all computers should be restarted via script in order to clear any locked profiles. Once all machines are back online, the migration can begin.

STEP 2: Migrate Workstations

Workstation migrations should be performed all at once. The "Post-Check" status is the ultimate sign of success or failure. "Failed" or being stuck at "Not Started" are both indicators that the migration failed. The potential reasons for failure, in order of likelihood, are the following:

• The required hotfixes are not installed (for XP)

• Target\Svc_targetmigrator is not a local administrator

• The wireless adapter or secondary NIC has not been disabled

• Windows Firewall has not been disabled

• The remote registry, server, workstation, and/or netlogon services are not running

If all of those potential issues are addressed and the workstation still will not migrate, check the logs on the ADMT server (C:\Windows\ADMT\Logs) to try and determine the root cause.

It's important to note that migrating AD Computer objects from the Source domain does not disable or remove the Source objects (although that is an option) so it's possible for users to log on to the source domain from their machine post-migration. This will cause a new local user profile to be created (because the original profile was migrated) and cause some confusion for the user. In order to eliminate this issue, consider setting ADMT to disable Source accounts as they're migrated. If that's not an option, communicate to users that they must log on to the Target domain and run a script post-migration to set the default domain accordingly. 

STEP 3: Migrate Email

Email migrations for all users at each site should be performed all at once. Please refer to the BinaryTree E2E documentation for migration instructions. Be sure and set the "Bad Item Limit" to 50 to avoid any corrupt emails causing the migration to fail. The details of any failed migrations can be seen in the Application Event Viewer. The potential reasons for a failed mail migration are, in order of likelihood:

• The mail-enabled user on the Target Exchange servers does not contain @target.net as an SMTP address.

• The “Bad Item Limit” is not set high enough.

• The mailbox being moved is larger than the target database will allow.

If all of these potential issues are addressed and the mail still will not migrate, dig through the event viewer on the E2E server to try and determine the root cause.

As E2E migrates mailboxes, it automatically creates MEUs on the Source domain to enable coexistence mailflow.

STEP 4: Reconfigure Outlook and Activesync Devices

With all of the workstations cut over to the Target domain, Outlook clients will no longer be able to communicate with the Source Exchange servers. This is a non-issue for Outlook 2007 and above, as those user profiles will try and autodiscover their new mail server and succeed in finding the Target Exchange servers. For Outlook 2003, however, the user profile has to be updated manually.

BinaryTree offers an Outlook Profile Update Service (OPUS), but it is not designed for cross-forest migrations and therefore will not work. You can deploy a .PRF file to update local Outlook profiles, but this will cause a new profile to be created and therefore cause every user to re-download their .OST file (assuming they are all using Cached Mode). This could potentially put too much load on network site links.

The best solution uses what I have termed "the poor man's autodiscover" and involves editing the hosts file of each workstation running Outlook 2003. I'm normally no fan of adding hosts file entries, but this solution is very effective. A startup script is deployed via GPO which checks for Outlook 2003 and, in cases where it is present, adds an entry to the hosts file pointing the namespace for the Source Exchange server to the IP address of a Target mailbox server. For example:

mail.source.net  10.10.75.12

This causes Outlook to connect directly to one of the Target mailbox servers and then Exchange automatically reconfigures Outlook to connect to the Target CAS Array. If the hosts file entry were to point Outlook directly to the Target CAS Array, Outlook would not reconfigure itself as it would appear that nothing has changed. This would work, but is not ideal because Outlook would always rely on that hosts file entry to function going forward. By pointing Outlook to a mailbox server, Outlook is forced to reconfigure itself (similar to autodiscover) and the hosts file entry is no longer needed and can therefore be removed.

Activesync devices will also need to be re-pointed to the new exchange environment. This is simply performed by changing the Exchange server from mail.source.com to mail.target.com and adjusting the user's credentials accordingly.

With workstations and mailboxes migrated and email clients reconfigured, the migration is finally complete! Congratulations! Repeat this process for each "chunk" of users and all that remains is to end coexistence and cut off all ties to the source organization. The steps for this final process are as follows:

Email

1. Confirm that there are no outstanding mailboxes which need to be migrated

2. Migrate and merge all mail-enabled groups one final time to update Distribution List memberships

3. Make Target Hub Transport Servers authoritative for Target.com

4. Point MX records for Target.com to the Target Exchange servers

5. Deploy a public autodiscover record for Target.com

6. Remove send connector to Source Exchange servers

7. Have the Source domain admins remove their send connector to Target Exchange servers

Active Directory

1. Ensure that all fileshares have been migrated

2. Removed DNS Conditional Forwarders for the Source domain

3. Have Source domain admins remove the DNS Conditional Forwarders for the Target domain

4. Verify that all workstations were migrated via network traffic logs and migrate any outstanding workstations

5. Remove trust to Source domain

With the Active Directory and Exchange coexistence features removed, the Target organization is completely free-standing and independent of the Source org. Carve-out complete!