EPFL > VPSI > IT > EXAPP - Site d'information: WinAD (Windows Active Directory)
 

  Affiche tous les articles

 Mode d'emploi du moteur de recherche  Rechercher : 
Moteur de recherche
Home page
Accréditation
Activation MS
AD c'est quoi ?
AD PowerShell
Authentifications
Autorisations DHCP
bugs
Conseils AD
DCs Sécurité
Délégations OUs
Domaine SC
Gaspar
GPO
Grp-Staff
KMS
Migrations
Outils
· Enable the Disk Cleanup tool 2012R2
· Rearming Sysprep
· Apply Images Using DISM
· Désactiver la couche 6to4 (IPV6) sur Windows 7 ,8 ,2008 ,2012
· Check MachineConf
· AD Users & Computers : afficher l'onglet "additional account info" sur OS 64 bits
· CMD for AD 2000/3/8 Dsget
· ShellRunas for VISTA
· Déléguer la gestion des services
· Mise à jour automatique avec Software Update Services pour Windows 2000, XP et 2003
· SUBINACL modifier les permissions & permuter les SID
· ADMT-V2 (Active Directory Migration Toll)
· How-to Migration NT4-2000 with ADMT V2 by Philippe Chammartin(IC-ISC)
· Outils pour la gestion de l'Active Directory (support tools)
· "Replication Access Was Denied"
· LES INDISPENSABLES Outils de support Active Directory
· commandes de Windows 2000
· NETDOM Déplacer des comptes machines d'un domaine à un autre
· MOVETREE pour déplacer des USERS d'un domaine2000 à un autre
· Installation des outils de support de Windows 2000 sur un ordinateur Windows 2000 Server
· Outils de migration de Domaines et OU
Procès verbaux
Profiles Itinérants
PWAD
Règles de nommage
Restaurations DC Fac
ServerAD2003
ServerAD2008
Seven
Students
synchro
toto1
Trucs et Astuces
Win 8.1
WinAD
Windows 10
Windows 8
Windows Server
Wins
Work Shop
  Afficher une version imprimable de ce document dans une nouvelle fenêtre
 
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

 

 

Introduction:

 

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)

1 floppy

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:

 

 

  1. No Hard drive should be mapped between the source and the target domain controller. No similar connection should be established either.
  2. 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


 

 

TargetDC:

 

  1. Control that the Domain Controller is in native mode

   2.   Install ADMT, nothing special to configure there.


 

 

 

SourceDC:

 

  1. 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)

TargetDC:

 

  1. 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.

 

SourcePES:

 

  1. 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.

 

  1. 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.

 

 

Using ADMT

 

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"

                                                            ADMT's functions

 

 

 

 

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

 

                                                Final result


 

 

 

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:

  1. Grant the "log on locally" right on every computer you plan to migrate to your target domain Domain Admin (Hyena can easily do that)
  2. 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.
 

                                                       Self explaining.

 

 

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).

                                             Finished

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).

 

Philippe Chammartin

vlip@bluewin.ch

 

 

Article N° 58, du 16.06.2003, par Alain Gremaud
URL de cet article : http://winad.epfl.ch/?article=58

© 2017 VPSI - EXAPP - TC