How to Migrate Out of the Forest: A Blueprint Based on C&C Migration Experience

Build a New Domain (in its own forest)

First, you need to make a hard decision with respect to the DNS name associated with your Windows domain. Do you want to keep the existing DNS name? If so, there will be a cost—more on that later. If keeping the existing name is not critical, then you’ll have an easier task. DNS policy limits departments to a single DNS zone. Additional DNS zones require approval from both your departmental chair and Terry Gray.

Option A: Retain the existing DNS name

This requires requesting a new DNS zone for a temporary period of time via . Make it clear that the additional DNS zone is temporary, specify an expected time period for the migration, and secure the approval of your department chair for the new DNS domain.

Setup your domain controllers and register DNS records for them.

At some point, you’ll need to run DDNS for both this new DNS zone and your original DNS zone. You only need to run DDNS for the duration of this process; afterwards you can turn the DNS zone over to C&C. Running DDNS is required to perform the final step in the process.

After migrating and turning off your old domain, you’ll need to rename your domain. Domain rename functionality comes with Windows Server 2003. Before the rename, make sure your original DNS zone is clear of SRV records for the old domain controllers. Then follow Microsoft’s documentation on renaming a domain.

After the domain rename, retire the temporary DNS zone you requested earlier. Notify that the DNS zone can go away. If you want to turn management of the original DNS zone (back) over to them, also negotiate a zone transfer and transfer of the ownership.

Option B: Move to a new DNS name

This requires requesting a new DNS zone via . Make it clear that the additional DNS zone will replace your existing DNS zone, so you will temporarily have more than one zone, specify an expected time period for the migration, and secure the approval of your department chair for the new DNS domain.

Setup your domain controllers and register DNS records for them.

After migrating and turning off your old domain, notify that the original DNS zone can go away. You may have other non-domain controllers in the original DNS zone. If so, you’ll need to switch their DNS registration to the new DNS zone prior to retiring your old DNS zone. That task is outside the scope of this document.

Migrate Objects to the New Domain

There are a variety of migration tools available. This document focuses on free tools available from Microsoft. You are welcome to investigate other tools and use them instead. Additional user-submitted documentation is welcomed in the community resources section of the Windows web pages. In addition, Microsoft supplies documentation for the tools discussed here, and we encourage you to consult that documentation.

Domain Trust and Setup

Create a 2-way domain trust between your original domain (henceforth referred to as the source domain) and the new domain (target domain). Get a copy of Active Directory Migration Tool (ADMT). Get a copy of Group Policy Management Console (GPMC).

Pick a computer to do all the ADMT stuff from (henceforth referred to as the ADMT console). Don't ever use a different computer; if you do need to use a different computer you’ll need to copy the underlying database that ADMT uses or your migration will have serious issues. It’s easiest to use a target domain controller. This gives you the benefit of knowing where the changes happened (for replication questions). Get an account that can do the migrations. Easiest thing to do is to add a source domain admin account to target\administrators & domain admins.

Review the ADMT Help file topic for ‘Before performing an interforest migration’. If you aren’t familiar with SIDs, you should definitely read this, and get comfortable with the concept. Make sure you meet the requirements noted in that topic. Notable steps include:

  • Create a domain local group called source$$$ (where source is the netbios name of your source domain) in the source domain.
  • The PDC of the source domain must have the registry key: HKLM\System\CurrentControlSet\Control\Lsa\TcpipClientSupport:REG_DWORD:0X1
  • The account you pick to use for migrations has domain admin in the target domain, is a member of source\administrators, and is an administrator on every computer that will be migrated.
  • Turn on account management auditing in both domains.

There are other requirements that may be relevant in non-standard situations.

Generally speaking, ADMT copies directory objects and has agents that will “reach out” to computers and fix the appropriate stuff to enable migration from one domain to another. It has the benefit of including sidhistory when migrating users and groups. This means that a migrated user or group will retain access to resources that haven’t yet been migrated. This is very important in cases where a migration can’t take place in a brief period of time.

ADMT has a test mode that allows you to see what would happen if you actually performed any of the tasks it can do. You can play around with the test mode to familiarize yourself with what ADMT can do.

ADMT creates log files for everything it does. On the ADMT console, these log files live in %systemdrive%\Program Files\Active Directory Migration Tool\Logs. By default, ADMT only keeps log files the past 20 actions. You can change this retention number at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ADMT\LogHistory.

The ADMT agent also creates a log file for everything it does. This log file is located at %systemroot%\temp\dctlog.txt. Additionally, the ADMT agent logs a summary of its actions to the Application event log. The ADMT agent installs itself as a temporary Windows service (meaning it removes itself when done), with software under %systemdrive%\Program Files\Active Directory Migration Tool\ and %systemdrive%\Program Files\OnePointDomainAgent\. The agent reports key status to the ADMT console.

The sequence in which you migrate is somewhat important, although there is some wiggle room. You’ll find that Microsoft documents lead you through a specific order. Here we’ve suggested an order that worked for us. C&C’s migrations were complicated by the fact that we had groups with members from other domains and other domains that needed access to the groups we were migrating.

Service Accounts

First, you’ll migrate users that are running as service accounts. This happens prior to migrating the computers where those services are running.

Enumerate services with service accounts with the Service Account Migration wizard by feeding it all potential computers to check. Ensure that all the pre-migration steps under the Computers topic have happened prior to doing this.

Migrate the service account(s) with the User Migration wizard, and choose to update the services that you’ve just enumerated.

On failure:

Service account migrations can fail to update the services running on computers during the user migration. This is a known bug due to replication latency. If the computer with the service contacts a DC that doesn't have the newly migrated account yet, then it fails to update its info. Via the service account migration wizard you can force an update after the user migration by choosing the 'no, use the previously collected info' option, then selecting the services that need update, and clicking the 'update SCM now' button.

The service account migration wizard is a harmless way to verify that the computer migration wizard can contact and install the ADMT agent on a computer. For servers, we ran the service account migration wizard as a pre-migration step to help ensure that scheduled migrations would happen with fewer problems.

Gotcha:

The Service Account Migration wizard only inspects services. It doesn’t inspect scheduled tasks. If you have a special account that runs scheduled tasks, then it won’t find it. And even worse, the computer migration wizard won’t find & fix it either. So plan on fixing scheduled tasks manually. Also if you have a special application that “remembers” an account’s credentials and uses them, then you’ll also need to deal with that manually. Now is a good time to deal with all those cases that are marginally “service accounts”.

Users and Groups

Decide whether to migrate passwords or reset them. If you want to migrate passwords, you’ll need to do some more configuration and setup to accommodate this. See the Optional: Password Migration section below.

Decide whether you can & want use altSecurityIdentities to hide some of the migration details from users (this requires either all kerb services or that all uwnetid passwords match the Windows equivalent password). If you choose this option, users login with . C&C chose to do this.

Pick a collision behavior: fail, rename with the prefix, overwrite. Rename with prefix makes most sense, followed by a post-migration task to search for this prefix.

Decide how to deal with global group memberships:

  • Migrate users and groups together. This is a special option of either the user migration wizard. You can choose to migrate a user and all their groups.
  • Elevate all global groups to universal, then migrate users, then migrate groups. In the case of a multi-domain forest, with group memberships from multiple domains and use of groups on resources in multiple domains, it is safest to elevate all group types to Universal, then migrate. In other words, if you are collapsing several domains, then you probably need to temporarily move to universal groups to avoid problems for the interim period.
    C&C needed to do this in our intraforest migrations.
  • Migrate users, then migrate groups. Ignore interim situation where destination user doesn't have access to a resource with source global group ACL.
    C&C did this for our interforest migrations, and scripted the user and group migration to run on a nightly basis. C&C can provide our script as an example to interested parties.

Even though you’ve migrated the users and groups, people don’t have to start using those accounts yet. In fact, we’d recommend that you not tell people about them until you migrate their computer. When their computer is migrated, then have them start using their “new” account. In the meantime, you can do testing with these new accounts to ensure for yourself that things work as expected.

Post migration:

  • Set altSecurityIdentities if used. ADMT doesn’t migrate this attribute. We’ve reported this as a bug to Microsoft, but they’ve declined to fix it. C&C has a script that automatically fixed this attribute nightly. C&C can provide our script as an example to interested parties.
  • Search for collision rename prefix if applicable.
  • Manually sync up built-in groups. ADMT doesn’t migrate the built-in groups. You’ll need to manually adjust memberships as necessary.
  • INTRAFOREST ONLY: Fix UPN if it's an intraforest user migration. This is an open bug, we’ve reported to Microsoft. Since this document is focused on interforest migrations, this isn’t a typical case you’d see.
  • INTRAFOREST ONLY: Fix LAG membership (and any other skewed attributes) if it's a delete destination user & recreate via migration scenario. In some cases, you’ll be collapsing a domain and a person will already have an account in the domain you keep. C&C found it easiest to delete the existing target account, migrate the source account, then restore any lost group memberships and other attributes.

Optional: Password Migration

Excerpt from the ADMT readme:

To set up your Password Export Server:

  1. Create a key that protects the password list:
  1. Run ADMT.exe from the command line using the key operation. The syntax for this command is ADMT.exe keySource_Domain_Namefolder: [Password] (Type ADMT.exe key at the command line for more usage information).
  2. Give the location of the key when prompted. Provide a matching password if one was given when you created the encryption key.
  1. Check the value of the AllowPasswordExport registry entry (located in HKLM\ SYSTEM\CurrentControlSet\Control\Lsa on the PES). The value must be set to 1 to allow ADMT to use that PES for password migration. You can disable a PES from supporting password migration by setting the value to 0.
  2. Add the Everyone system group to the “Pre-Windows2000 Compatible Access” group on the target domain. If this is not done, ADMT will log an “Access Denied” error. To do this, use the Active Directory Users and Computers snap-in, or use the following syntax at the command prompt on a target domain controller:

NET LOCALGROUP "Pre-Windows2000 Compatible Access" Everyone /ADD

  1. In the Active Directory Users and Computers snap-in, verify permissions on the PES server object. The PES requires that the “Pre-Windows2000 Compatible Access” group has “Read All Properties” rights on the following object:

CN=Server,CN=System,DC=<domain_name

  1. If you are running ADMT on a server running Windows Server2003, add ANONYMOUS LOGON to the “Pre-Windows2000 Compatible Access” group on the target domain. If this is not done, ADMT will log an “Access Denied” error. To do this, use the Active Directory Users and Computers snap-in, or use the following syntax at the command prompt on a target domain controller:

NET LOCALGROUP "Pre-Windows2000 Compatible Access” ANONYMOUS LOGON/ADD

Relevant KB article:

Policy and Other Stuff

Before moving computers, you need to make sure that your domain environment is replicated in the target domain.

Group policy can be migrated with the GPMC tool. There are backup, export and import functions that are documented in the help files. Additionally, you can export & import ipsec filters underlying group policy. You may need to create a mapping file to translate the specific users and groups referenced in group policy. The GPMC help and documentation is pretty explanatory.

Your domain-based DFS tree can be migrated using the DFS command line by dumping the existing configuration, search and replace your old domain name, and import.

Any code you have may need to have it’s hard-coded domain assumptions fixed. There may be other things specific to your environment that need to be moved or adjusted here.

Computers

Migrating computers will be the most time-consuming portion of your migration--and that’s with an agent that visits the computers for you! The ADMT Computer Migration wizard first copies the computer account, then it tries to deploy an agent to the computer. Frequently, it will be unable to deploy the agent to a computer (see Pre-migration tasks and On failure below), so you’ll need to remigrate that computer.

There are several product constraints you’ll need to plan around. One is the fact that all the computers you pick to migrate in a batch must be migrated to the same OU. This is very limiting, but you can easily move the computers after ADMT migrates—you just need to have a plan to keep track of this. Another is the fact that only one migration can occur on the ADMT console at a time. You’ll need to wait for completion of all the ADMT agents before starting another batch. For slow computers or computers with a lot of files or registry keys this can amount to an annoying delay. You can choose to close the computer migration wizard prior to receiving completion status on all the agents. But you won’t know their status without checking their log file, so this is only helpful when there are only a few errant computers.

Pre-migration tasks:

  • No firewalls between the ADMT console and the destination computer(s). This includes SP2 firewalls.
  • No IPSEC rules that prohibit SMB between ADMT console and the destination computer(s).
  • File and printer sharing for MS networks must be enabled.
  • Server service must be running.
  • Netbios over TCP/IP must be enabled.
  • Either
  • The computer has a valid DNS name. This DNS name can be resolved by the ADMT console. This DNS name is the value in the dnshostname attribute on the computer's account. This is usually the case for servers at the UW.

or

  • The ADMT console and the computers to be migrated are either on the same network or share a WINS server. This is usually the case for workstations at the UW, since most workstations use DHCP to obtain an IP address and the DNS name associated with the DHCP IP does not match the computer. You must delete the dnshostname attribute on the computer's account. Some actions on the computers can recreate the dnshostname attribute, so you want to delete the attribute reasonably close to the migration time.
    We found that using ldp.exe, with the modify operation, delete dnshostname attribute and just changing the DN of the target object was fairly quick for multiple computers in the same OU. But that was largely because the computer names only differed by a character or two. You might also use the AdsiEdit MMC snap-in to make this change. For a large migration, a script is desirable—and C&C did this for our larger migrations (we can share this if there’s interest. There's also a hotfix that changes this behavior. But it still tries DNS resolution first, which would introduce a substantial delay into the agent deployment process as you wait for DNS resolution to fail. So we think the best option is to kill the attribute.
  • The relevant users and groups in ACLs on the computer(s) to be migrated have already been migrated (via the same ADMT console).
  • The 'Change primary DNS suffix when domain membership changes' checkbox is set to the correct value (no reboot necessary as prompted). The ADMT agent has no control over this behavior. C&C found we needed to manually change the default setting on all servers, and left the default setting on all workstations.
  • Pick a collision behavior: fail, rename with the prefix, overwrite. Because you’ll need to remigrate many computers, we’d recommend overwrite.

Post-migration tasks: