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
firstname.lastname@example.org. 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
email@example.com 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 firstname.lastname@example.org. 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 email@example.com 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
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
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:
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
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.
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.
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.
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
firstname.lastname@example.org. 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
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.
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
Optional: Password Migration
Excerpt from the ADMT readme:
To set up your Password Export Server:
1. Create a key that protects the password list:
a. Run ADMT.exe from the command line using the key operation. The syntax
for this command is ADMT.exe key Source_Domain_Name folder:
[Password] (Type ADMT.exe key at the command line for more usage
b. Give the location of the key when prompted. Provide a matching password if
one was given when you created the encryption key.
2. 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.
3. Add the Everyone system group to the “Pre-Windows 2000 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-Windows 2000 Compatible Access" Everyone /ADD
4. In the Active Directory Users and Computers snap-in, verify permissions on the
PES server object. The PES requires that the “Pre-Windows 2000 Compatible
Access” group has “Read All Properties” rights on the following object:
5. If you are running ADMT on a server running Windows Server 2003, add ANONYMOUS
LOGON to the “Pre-Windows 2000 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
NET LOCALGROUP "Pre-Windows 2000 Compatible Access” ANONYMOUS
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.
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.
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
File and printer sharing for MS networks must be enabled.
Server service must be running.
Netbios over TCP/IP must be enabled.
o 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
o 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
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.
If ADMT reports any errors or has an unknown status, check the agent logs. For
complete with errors, you can drill down to the logs from within ADMT as long as
the computer is up. Otherwise, check %systemroot%\temp\dctlog.txt.
Frequently the ADMT agent will fail to deploy. Re-verify all the pre-migration tasks.
One quick test is to try connecting to \\computername\admin$. This checks both name
resolution, connectivity, all the SMB-related pre-requisites, and permissions at the
same time. If you pass that quick test, make sure the dnshostname attribute hasn‟t
resurfaced, then try again. We saw several cases where the agent wouldn‟t deploy on
the first pass for no good reason, but deployed fine on a second attempt.
Demote the old DCs
When the domain migration is done, demote all domain controllers in the old domain.
Demotion of the final domain controller will require an enterprise admin. Send email to
help@cac to get this assistance.
Before each demotion, remember to make a copy of the netlogon.dns file. After the
demotion, send this file to email@example.com and ask them to remove all the
DNS records within it. If you are turning off the servers after demotion or planning to
rename them, you may also want to request changes to the A and PTR records. Finally,
there may be an A record for the Windows domain itself that points at the IP address for
the domain controllers. If so, have this record removed as well.