How-to Migration NT4-2000 with ADMT V2 by Philippe Chammartin(IC-ISC)
Interforest migration of a Windows NT4 domain in the EPFL Windows 2000 domain
First and foremost, don't be scarred by this document's length, it's mostly screenshots and as such it’s shorter than it seems.
Active Directory Migration Tool (ADMT) is a tool provided by Microsoft to migrate users, computers and files from one domain to another.
ADMT comes in two flavors, ADMT v.1 is the official tool freely available on Microsoft's website and ADMT v.2 which is the future version officially available upon the release of the Microsoft .Net servers.
ADMT v.2 provides many new features from which one will interests us greatly: Namely the ability to migrate passwords (ADMT v.1 either changes them with a complex password or changes them to the user's login) via a Password Exchange Server (PES).
The Password Exchange Server is a software that must be installed on the source's domain NT4 BDC and allows ADMT to migrate the passwords through a fully 128bit encrypted tunnel.
This document has been created by using ADMT v.2, as the graphical differences between ADMT v.1 and v.2 are completely negligible.
In this guide we'll use a standardized start environnement comprising a source domain named sourcedomain and a target domain named targetdomain.
The source domain contains:
1 Windows NT4 SP6a Primary Domain Controller named source
1 Windows NT4 SP6a Backup Domain Controller named PES
1 Windows XP SP1 Professional client named Test
2 Users JaneD and JohnD
1 Group Students containing both users above
The target domain contains:
1 Windows 2000 SP3 Server Domain Controller named target
1 Organizational Unit named MigrationOU where we'll migrate the source domain
Requirements for ADMT v.1:
1 Windows 2000 domain controller (target domain)
1 Windows NT 4 PDC SP4 (source domain)
ADMT v.1 (http://www.microsoft.com/windows2000/downloads/tools/admt/default.asp)
Additional requirements for ADMT v.2:
1 Windows NT 4 BDC SP4 with high encryption pack (comes with IE6 for example)
ADMT V.2 (available \\OLYMPE\Distribution\System\Win2003\English\All_Versions\Tools )
Installation of ADMT and configuration of both domain for the migration
Both Domain Controllers:
- No Hard drive should be mapped between the source and the target domain controller. No similar connection should be established either.
- Create a two way thrust between both domains.
On the Windows 2000 domain
On the Windows NT4 domain
3. Turn on account management auditing for both success and failure.
On the Windows 2000 domain
On the Windows NT 4 domain
- Control that the Domain Controller is in native mode
2. Install ADMT, nothing special to configure there.
- Add the target's domain admin group to the source's administrator group
Installation of the Password Export Server (only required if you plan on using AMDT v.2)
- Create the encryption key required by the PES. Put a floppy in the floppy drive and create the key by using this command line: "ADMT.exe key %Source Domain Name% %Floppy Drive Letter%: %Optional Password%"
2. Add the "Everyone" group to the "Pre-Windows 2000 Compatible Access" group on the target domain by using this command line :" NET LOCALGROUP "Pre- Windows 2000 Compatible Access" Everyone /ADD". After the migration you can use this command line " NET LOCALGROUP "Pre-Windows 2000 Compatible Access" Everyone /DELETE" to erase the "Everyone" group from the "Pre-Windows 2000 Compatible Access" group.
- Install PWDMIG on the Source BDC, will require a reboot at the beginning of the installation to update windows installer. Use the floppy containing the encryption key created on the TargetDC during the install.
- Change the AllowPasswordExport registry key value to 1 (key location: \ SYSTEM\CurrentControlSet\Control\Lsa). To disable the PES simply change that value back to 0.
So almost everything is ready to actually start the migration process, almost…
ADMT's "sober" graphical user interface
Most functions of ADMT can be accessed by right clicking the "Active Directory Migration Tool"
This guide will only cover the most important wizards that you are more likely to use, most wizards only slightly differ from each other so if you need to use one not covered here you shouldn't head in a lot of trouble.
The User Account Migration Wizard allows you to migrate one or more users.
The Group Account Migration Wizard allows you to migration on or more groups, including (or not, as you wish) their members.
The Computer Migration Wizard migrates computers from one domain to another, including (or not) the file credentials, printers, local users…
The Security Translation Wizard allows you to migrate the security credentials, printers… without migrating the computer in itself.
The two most important wizards are the Group and Computer migration wizards, as you can usually migrate your whole domain with only those two.
Each wizard's second screen (the first is a small description) allows you to either test your settings or actually apply your settings and migrate.
This allows you to control that your ADMT configuration is correct and ready for deployment. Even though quite efficient, having your settings pass the test is still not a guaranty of it working perfectly once you apply them for real.
User Account Migration Wizard first screen
Standard second screen
On ADMT's first use you are more than likely going to encounter the following errors, they simply show that ADMT will modify a few settings on your source domain and is asking you for authorization, just accept them. Be warned though that after those modifications, ADMT will need to reboot your source PDC.
One modification necessary for the SID migration to work
A second modification
The subsequent reboot request
Migrating our example source domain
A migration starts always by copying the users to the target domain, because when ADMT will migrate the computers he'll need to know which users have been migrated in the new domain to translate the file's ACLs.
I recommend using a single Target OU (our Migration OU) during the whole migration process and only after manually move your various users, groups and computers in your 2k domain OU. This because when ADMT translates file's ACLs it bases itself on the target OU to know which accounts have been migrated.
If per example you migrate your users in UsersOU and your computers in computersOU then, when ADMT will migrate your computers, he won't find your migrated users and won't migrate your computer's files ACL's.
First Step: Group and Users migration
Let's migrate our students group.
For each step there will be a screenshot and under each screen shot, if necessary, an explanation of what each function does.
First Group Account Migration Wizard's screen
Selection of the group(s) we'll migrate
Destination of the migrated groups
- Update user rights: Copies the user rights from the source domain to the target domain.
- Copy group members: Includes the group members in the migration
- Update previously migrated objects: In case of users being members of more than one group, this option will insure that every membership gets migrated.
- Fix membership of group: If you had already migrated users without migrating the groups, this option will add the missing memberships.
- Migrate group SID's to target domain: The group will keep its original SID, allowing your group members to access unmigrated resources in the source domain.
Type in domain admin account of sourcedomain.
- Ignore conflicting accounts and don't migrate: If ADMT encounters an account in the target domain with the same name as one supposed to be migrated then ADMT won't migrate it.
- Replace conflicting accounts: Overwrites conflicting accounts with source domain accounts to be migrated.
- Rename conflicting accounts by adding the following: Allows you to specify how ADMT changes the name of conflicting accounts, a good way to find conflicting accounts to manually fix them after the migration is by adding "aaa" as prefix.
Complex passwords: ADMT overwrites accounts passwords with complex generated passwords. Those passwords are outputted in a log file.
- Same as user name: Self explaining
- Migrate passwords: Self explaining. In the drop down menu, choose your PES BDC.
In case of errors, click on "View Log" to troubleshoot the problem
Second Step: Computers and Files migration
Now let's migrate the Test computer in the target domain.
On the Test computer, I have created two example files, JohnDoe's documents.txt and JaneDoe's documents.txt with the following credentials:
This to show how ADMT translates the files ACLs.
A computer migration is very similar to a user migration in most configuration screens, but there is a step more. After having migrated the computer account in the target domain, ADMT will send an agent on the computer and said agent will migrate the computer himself.
This is usually where problems happen.
The most frequent problem is that to succeed in dispatching the agent ADMT needs local logging rights on the computer to migrate.
There are two ways to achieve that:
- Grant the "log on locally" right on every computer you plan to migrate to your target domain Domain Admin (Hyena can easily do that)
- Add the source Domain Admin group (or only the domain admin account you plan to use) to the target Administrators group. Then you can log on the target DC with the source domain admin account and migrate computers from there. This means switching accounts between User/Group and File/Computer migrations as you cannot migrate user accounts with the source domain admin account.
The second solution
None of those solutions are elegant, but they are a necessary evil to achieve the migration.
Only the screens that change from the Group migration will be shown under.
Files and folders: Translates the computer file's ACLs from sourcedomain accounts to targetdomain accounts
- Local groups: Translates security on the computer's local groups
- Printers: Translates security on the computer's printers
- Registry: Translates security on the computer's registry
- Shares: Translates security on the computer's shares
- User profiles: Translates security on the profiles present on the computer.
- User rights: Translates user rights to the target domain.
After migration, a reboot is necessary this window allows you to specify how long ADMT
waits after the migration to reboot the computer.
ADMT agent running on the target computer
Notice how few files are actually modified, this is normal. Only few files contain domain level ACLs that needs to be modified (at least on a workstation).
As you can see, the Jane Doe and John Doe accounts have been successfully translated, but the rootpc account that hadn't been migrated is still on the sourcedomain, as it should be.
It is essential to migrate ALL user accounts before migrating the computers themselves, if not ADMT won’t be able to translate all the files ACL’s as it bases itself on the users contained in the target OU (in our case MigrationOU) to determine which ACL to translate or not (that’s why rootpc’s ACLs have not been translated as shown in the preceding screenshot).
Article N° 58, du 16.06.2003, par Alain Gremaud
URL de cet article : http://winad.epfl.ch/?article=58