Introduction

Avant tout lancement de migration, il faut avoir conçu une topologie complète de la forêt cible que l'on désire. En effet les différences entre NT 4.0 et Windows 2003 sont considérables du fait -entre autre- de la présence du serveur LDAP Active Directory dans ce dernier.

Il faut donc avant d'aborder la procédure avoir mis sur papier :

• Le type de forêt
• Le nombre de domaines
• La présence ou non de plusieurs sites physiques
• La disposition des Contrôleurs de domaines et catalogues globaux
• La structure des OU

Cette section ne fait pas partie du présent document, mais de nombreuses informations sont disponibles sur les sites référencés en annexe, tout comme un autre billet donnant quelques éléments de design d'architecture.

1. Préparation des domaines source et cible avant migration

1.1. Phase préparatoire : Création du premier domaine de la nouvelle forêt (PDNF)

L'objectif de cette phase est la création de la nouvelle forêt, afin de conduire la migration par restructuration vers celle-ci. Pour créer cette forêt, il faut procéder en 3 temps :

• installation de Windows 2003 sur un serveur adéquatement dimentionné (penser surtout à la quantité de ram, l'espace disque et la connectivité. Au vu de la puissance des CPU actuels, un quadcore ne sert pas à grand chose)
• Installation et configuration d'un DNS sous cette machine afin de gérer les enregistrements dynamiques et sécurisés 
• Lancement de l'installation d'active directory

Ce premier domaine est la fondation de l'infrastructure Active Directory visée. Celui ci doit être créé avant toute migration de domaine existant.

1.1.a Recommandation à l'installation

• Lancer l'assistant d'installation. Choisir le système de fichier NTFS, mettre une adresse IP statique et un masque qui correspondent à ceux de votre réseau 
• Dans les paramètres TCP/IP mettre son adresse en tant que serveur DNS (pas 127.0.0.1, la vraie IP de la machine)
• Installer les support tools et ressource kits dans la foulée.

1.1.b Installation d'Active Directory

Lancer l'assistant d'installation sur l'ordinateur. celui-ci crée la base de données Active Directory et initialise les données de l'annuaire. Il installe et configure aussi le service DNS si celui-ci n'était pas déjà configuré.

A noter : Bien que l'assistant puisse installer DNS tout seul, j'ai toujours eu pour habitude de conseiller une installation préalable du service, juste "au cas où". De même, bien qu'un Bind bien configuré puisse jouer le rôle de DNS pour AD (Les forums linux en parleront d'ailleurs mieux que moi), je préfère aussi rester sur un DNS MS pour Active Directory, quite à utiliser le Bind comme redirecteur pour les ressources non windows.

1.1.c Vérifications post installation

Pour vérifier que l'installation d'Active Directory s'est déroulée correctement :

• Vérifier l'observateur d'événements
• Lancer dcdiag.exe et netdiag.exe pour analyser le rapport d'erreur
• Dans les paramètres du DNS, vérifier que _msdcs. forest_root_nom_domaine et forest_root_nom_domaine ont bien été créés.
• Vérifier que DomainDnsZones et ForestDnsZones existent.

Vérifier que les résolutions de nom normale et récursive (si configurée) fonctionnent correctement.

1.2. Préparation de la mise à jour du domaine NT 4.0 vers le PDNF

Afin de réussir le processus de migration des ressources vers le nouveau domaine, et après avoir suivi toutes les étapes précédentes, procéder aux taches suivantes :

1.2.a Sauvegarder les données du domaine

Penser à sauvegarder touts les données avant de commencer la mise à jour. Cette tache peut varier en temps mais EST NECESSAIRE. Il faut au minimum sauvegarder les données du PDC et du BDC.

1.2.b Etablir des relations d'approbation entre le domaine NT 4.0 et le PDNF

Avant de migrer des ressources du domaine source, il faut s'assurer que des relations d'approbations explicites existent de part et d'autre. Celles-ci permettent aux utilitaires de migration existant comme ADMT de déplacer les objets correctement. De plus, ces relations permettent aux utilisateurs du domaine source d'accéder aux ressources du domaine cible et inversement, dans le cas d'une migration "au fil de l'eau".

A noter : Si après la relation d'approbation, vous obtenez un message spécifiant que le filtrage de Sid est activé sur le domaine cible (probable), accédez à la ligne de commande du PDNF puis utilisez l'outil NETDOM du ressource kit.
Pour se faire jetez un coup d'oeil à l'aide des commandes
netdom trust /Enable SIDHistory et netdom trust /Quarantine

1.3. Planification de migration des profiles utilisateurs

Les profiles utilisateurs enregistrent les données et informations des utilisateurs, ceux-ci sont translatés durant le processus de migration.
Seul le SID primaire est utilisé pour assigner un profile à un utilisateur, les SIDs de l'historique sont ignorés. Il faut penser à ne transvaser les profiles d'un domaine à l'autre qu'en mode d'ajout, de sorte qu'en cas d'échec, ceux-ci soient toujours disponibles sur le domaine source, sans configuration de mappage.

1.3.a Etablire des procédures administratives

Il convient de définir la façon dont les objets à migrer sont administrés pendant le processus de migration. Etablir des procédures permet de préserver les objets dans les domaines sources et destination, et ainsi permettre un retour arrière en cas d'échec.
Les procédures doivent être obligatoirement prises pour :
• Les comptes utilisateurs, y compris leur SID
• Les membres de groupes globaux

Les comptes utilisateurs

Durant le processus de migration, les comptes utilisateurs existent dans les domaines source et destination. Il faut continuer d'administrer les comptes du domaine source pendant la mise en place de la migration et utiliser l'option remplacer les comptes conflictuels dans ADMT pour re-migrer les comptes problématiques aussi souvent que nécessaire.
Ceci permet de s'assurer que les modifications faites sur un compte dans le domaine source le sont aussi dans celui du domaine cible.

Les groupes globaux

Il faut continuer d'administrer les groupes du domaine source durant le processus de migration et utiliser l'option remplacer les comptes conflictuels dans ADMT pour re-migrer les groupes problématiques aussi souvent que nécessaire.
Ceci permet de s'assurer que les modifications faites à un groupe dans le domaine source le sont aussi dans celui du domaine cible.

1.3.b Préparer les domaines source et destination pour la migration

Avant de restructurer le domaine NT 4.0, il convient de s'assurer que le domaine cible Windows 2003 fonctionne dans un mode qui accepte la réception en masse d'objets migrants.Le PDNF doit être en mode Windows 2000 natif au minimum ce qui n'est pas fait par défaut. Pour passer le PDNF en mode Windows 2000 natif :

• Lancer domaine et approbation Active Directory • Sélectionner le nouveau domaine • Clique droit et sélectionner augmenter le niveau fonctionnel du domaine • Choisir Windows 2000 natif et valider

1.3.c Installer le kit de cryptage élevé

Dans la mesure où les mots de passe utilisateurs doivent être migrés, les deux contrôleurs de domaine des domaines source et cible doivent utiliser le pack de cryptage élevé.Disposant de licences NT 4.0 françaises, il n'existe pas de pack spécifique en dehors des états unis. Pour obtenir le kit de cryptage élevé, il faut installer Internet Explorer 4.1 ou ultérieur sur le PDC du domaine source

1.3.d Etablire des comptes de migration

Afin de migrer des compte et ressources, il faut créer des comptes et leur assigner les capacités appropriées.
Dans la mesure où des relations d'approbations ont été faite dans les deux sens plus haut, la gestion de ces compte est simplifiée.

Pour créer le compte de migration lorsque une approbation bi-directionnelle existe :

• Dans le domaine cible, créer un compte d emigration, type res_migrator (histoire de ne pas utiliser le compte administrateur du domaine)
• Ajouter ce compte au groupe administrateurs du domaine
• Sur le domaine source, déléguer à ce compte (du fait de la relation d'approbation) des permissions sur les OUs concernées par la migration (exemple : users, computers.), au pire, ajoutez le dans le groupe administrateurs du domaine
• Ajouter le compte de migration au groupe administrateurs local de tous les postes et serveurs à migrer du domaine source (un script est disponible sur PM.net pour ça.

1.4. Configurer les domaines source et cibles pour migrer l'historique SID

Pour migrer l'historique SID, il faut s'assurer que les conditions ci-dessous soient respectées :

• La migration des mots de passe est activée
• Un groupe local est utilisé pour auditer les opération d'historique dans le domaine source
• Le support des clients TCP/IP est activé sur le PDC
• Des stratégies d'audit sont implémentées sur les domaines source et de destination

Afin de mener à bien ces taches, suivez les instructions suivantes :

1.4.a Activer la migration des mots de passe

Afin de migrer les mots de passe NT 4.0 grâce a ADMT, il faut utiliser un PES pour héberger les DLL de migration de mots de passe. Ce PES est un contrôleur du domaine hôte gérant le cryptage 128bits (donc PDC sur un domaine NT4).
La procédure suivante active le support de la migration de mots de passe :

Dans le domaine cible, s'assurer que le groupe par défaut Pre-Windows 2000 Compatible Access contient les groupes anonymes et tout le monde.Dans le domaine source, insérer le CD de Windows 2003 dans le lecteur du PDC et installer pwdmig.exe disponible dans le dossier \i386\admt\pwdmig .

Pour créer une clé de cryptage :

• Se connecter sur le PDNF en utilisant un compte administratif • Mettre une disquette formatée dans le lecteur • Lancer une invite de commande puis entrer

     ADMT KEY Domaine_Source A: mot_de_passe ou *

A noter : le mot de passe à entrer est optionnel, toutefois pour des raisons de sécurité il est fortement recommandé d'en entrer un. Si au lieu du mot de passe, on entre une astérisque, le mot de passe demandé ne sera pas affiché à l'écran.

Pour activer la migration de mots de passe sur le domaine source :

• Sur le PES, insérer la disquette de clé de cryptage et le CD-Rom Windows Server 2003
• Parcourir le CD-Rom jusqu'au dossier \i386\admt\pwdmig et lancer pwdmig.exe . Le mot de passe entré précédemment est demander.
• Entrer le mot de passe et terminer le processus d'installation
• Dans le registre, modifier la valeur de l'entrée DWORD AllowPasswordExport de la clé HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Control\LSA à 1.

1.4.b Initialiser ADMT Avant de lancer ADMT pour la première fois effectuer les taches suivantes :

• Créer un groupe local source_domain dans le domaine source. Celui-ci servira à l'audit et la migration de SID
• Dans le registre, créer la valeur de l'entrée DWORD TcpipClientSupport dans HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Control\LSA avec une valeur de 1
• Activer la stratégie d'audit de gestions des utilisateurs et groupes sur les domaine sources et cible.

redémarrer ensuite le PDC du domaine source.

1.5. Mise en place d' ADMT (Active Directory Migration Tool)

 Installer ADMT sur le contrôleur du PDNF. Cet utilitaire va s'occuper de migrer les différentes ressources. Pour ce faire, il suffit d'installer admigration.msi disponible sur le CD de Windows 2003 dans \i386\admt

1.5.a Lançer une simulation de migration de groupes globaux

 Avant de lancer ADMT pour la première fois vérifiez bien que les prérequis ont bien été effectués, entre autre que les clés de la base de registre soient bien positionnées.

Initialiser ADMT en lançant un test de migration des comptes de groupes avec l'option de migration de l'historique SID.

Voici le tableau des paramètres à entrer :

Page de l'assistant

Action

Tester ou effectuer des changements

Choisir Test the migration settings and migrate later

Sélection du domaine

Dans l'onglet Domaine source , taper le nom du domaine source.

Dans l'onglet Domaine cible , taper le nom du domaine cible

Sélection des groupes

Cliquer sur Ajouter .

Dans la boite de diaIogue Sélection des groupes , choisir un groupe.

Sélection de l'unité d'organisation

Cliquer sur Parcourir .

Dans la boite de dialogue Parcourir le conteneur , aller à l'OU où placer les groupes.

Options de groupe

Sélectionner l'option Effectuer la migration des identificateurs SID de groupe vers le domaine cible .

Cliquer sur Ne pas renommer les comptes .

Compte d'utilisateur

Entrer le login et mot de passe de l'utilisateur créé auparavant afin de migrer les ressources ( res_migrator )

Dans l'onglet Domaine , entrer le nom NETBIOS du domaine cible

Conflits de nommage

Cliquer sur Ignorer les comptes conflictuels et ne pas effectuer la migration .

• Quand l'assistant aura fini son exécution, vérifier les log afin de contrôler les erreurs éventuelles.

1.5.c Identifier les comptes de service

Certains contrôleurs et serveurs membres pevent exécuter des applications en utilisant un compte de service. Ce compte de service est un utilisateur standard mais qui dispose de l'autorisation Log on as a service. Nous allons tenter ici de les identifier.

ADMT ajoute ses comptes dans la liste des comptes de service ne s'exécutant pas sous le compte system local. Ils doivent être mis à jour après leur migration. Pour les identifier, suivre les étapes suivantes :

Dans l'assistant de migration des comptes de service, sélectionner les paramètres suivants :

Page de l'assistant

Action

Sélection du domaine

Dans l'onglet Domaine source, sélectionner le nom NetBIOS du domaine source.

Dans l'onglet Domaine cible , sélectionner le nom NetBIOS ou DNS du domaine cible.

Infos de mise à jour

Sélectionner Oui, mettre à jour les informations .

Sélection des comptes de service

Cliquer sur Ajouter .

Dans la liste déroulante Sélectionner Ordinateurs , choisir les noms des serveurs qui ont des comptes de service.

Cliquer sur OK puis Suivant .

Informations sur les comptes de service

Sélectionner tout compte qui n'a as besoin d'être marqué comme compte de service et cliquer sur Ignorer/inclure pour le passer à l'état Ignorer .

• Lorsque l'assistant se termine, vérifier le fichier log. Ce fichier contient des informations sur les raisons d'un éventuel échec (par exemple RC=5 permissions non valides).

2. Restructuration des comptes du domaine nt 4.0

après avoir planifié la migration , et préparé les domaines, nous allons maintenant passer à la migration proprement dite. Celle-ci peut être faite par pallié dans la mesure où les étapes stipulées plus haut ont bien été accomplies.

La restructuration des comptes NT 4.0 demande une migration des utilisateurs, des groupes et des comptes de service existant dans le domaine source. Les comptes de domaine étant liées à des ressources (partages, postes de travail...), il faudra aussi migrer celles-ci.
Dans l'ordre, il faut procéder par :

• Migrer les comptes de service
• Migrer les groupes globaux
• Migrer les comptes utilisateurs par grappe
• Migrer les comptes ordinateurs
• Effectuer les taches post migration

2.1. Migration des comptes de service

Nous allons commencer le processus de migration en transvasant les comptes de service identifiés plus haut. L'utilisation d'ADMT permet de :

• Migrer les comptes de services depuis NT 4 vers notre domaine cible
• Modifier les services de chaque serveur du domaine source, afin qu'il utilise les comptes de service du domaine cible, à la place des siens

A noter : ADMT ne met à jour que le droit log on as a service (se connecter en tant que service). Si un compte de service a d'autres droits du à son appartenance à groupe local spécifique, il faudra à la suite mettre à jour ses droits en utilisant l'assistant de transvasement de sécurité.

Pour migrer les comptes de service, après s'être logué sur le domaine cible avec le compte administrateur ( pas le compte res_migrator ), suivre les étapes suivantes :

Page de l'assistant

Action

Tester ou effectuer des changements

Choisir Effectuer la migration maintenant

Sélection du domaine

Dans l'onglet Domaine source, sélectionner le nom du domaine source. Dans l'onglet Domaine cible, sélectionner le nom du domaine cible.

Sélection des utilisateurs

Cliquer sur Ajouter . Dans la liste déroulante Sélection Utilisateurs , choisir tous les comptes de service identifiés précédemment et cliquer sur Ajouter. Cliquer sur OK .

Sélection de l'unité d'organisation

Cliquer sur Parcourir Dans la boite de dialogue Parcourir le conteneur , naviguer dans le domaine cible, et choisir le conteneur pour les comptes de service, puis cliquer sur OK.

Options de mot de passe

Choisir Mots de passe complexes .

Options de transition de compte

Choisir Activer les comptes cibles . Choisir la boite Effectuer la migration des identificateurs SID des utilisateurs vers le domaine cible .

Compte d'utilisateur

Entrer les login, mot de passe et domaine d'un membre du groupe administrateurs.

User Options

Sélectionner la case Mettre à jour les droits des utilisateurs S'assurer que Ne pas renommer les comptes est sélectionné Ne RIEN choisir d'autre.

Conflits de nommage

Sélectionner Ignorer les comptes conflictuels et ne pas effectuer la migration .

Informations de comptes de service

Choisir Migrer tous les comptes de service et mettre à jour le SCM pour les objets marqués inclure . Cliquer sur suivant

• A la fin de l'assistant, vérifier les fichiers log pour s'assurer qu'il n'y a pas d'erreur
• Lancer utilisateurs et ordinateurs pour vérifier que les comptes de services sont bien présents
• Vérifier que les applications nécessitant ces comptes fonctionnent toujours.

2.2. Migration des groupes globaux

Afin de préserver l'appartenance aux groupes, il faut migrer les groupes globaux avant les utilisateurs.

Pour migrer les groupes en utilisant ADMT, voici les étapes à suivre :

Page de l'assistant

Action

Tester ou effectuer des changements

Sélectionner Effectuer la migration maintenant

Sélection du domaine

Dans l'onglet Domaine source , sélectionner le nom NetBIOS du domaine source. Dans l'onglet Domaine cible , sélectionner le nom NetBIOS ou DNS du domaine cible.

Sélection des groupes

Cliquer sur Ajouter . Dans la boite de dialogue Sélection des groupes , choisir tous les groupes globaux à migrer (sauf les groupes prédéfinis), choisir Ajouter puis OK.

Sélection de l'unité d'organisation

Choisir le nom de l'OU ou faire Parcourir , chercher le conteneur du domaine cible vers lequel déplacer les groupes (par défaut users) et cliquer sur OK .

Options de groupe

Sélectionner Effectuer la migration des identificateurs SID de groupe vers le domaine cible . Sélectionner Ne pas renommer les comptes . S' assurer que toutes les autres options sont décochées.

Compte d'utilisateur

Entrer les login, mot de passe et domaine d'un membre du groupe administrateurs.

Conflits de nommage

Sélectionner Ignorer les comptes conflictuels et ne pas effectuer la migration

• Lorsque l'assistant a fini de s'exécuter, vérifier les fichiers log pour s'assurer qu'il n'y a pas d'erreur.
• Lancer utilisateurs et ordinateurs, et naviguer jusqu'à l'OU où les groupes ont été exportés afin de s'assurer qu'ils existent et que leurs attributs ont été correctement remappés.

2.3 Migration des comptes utilisateurs par grappe

Il s'agit commencer par le pilote d'un faible nombre d'utilisateurs pour faire des test et voir s'ils sont capables d'accéder aux ressources après la migration.

migrer ensuite le reste des utilisateurs par grappe de X, ou suivant les contraintes qui vous sont imposées (par service, étage ...). A la suite de la migration, des évènements d'audit sont créés dans les deux domaines, du fait du choix de basculer l'historique des SID.

L'utilisation de ADMT pour migrer les comptes préserve les appartenances aux groupes. Dans la mesure où un groupe ne peut contenir que des membres de son propre domaine, les utilisateurs déplacés dans le groupe cible ne sont plus membres de groupes du domaine source. C'est pourquoi ADMT place automatiquement les utilisateurs déplacés dans les copies des groupes.

ADMT gère tout seul la migration des mots de passe si la préparation vue plus haut a bien été effectuée.

Note : il n'est pas toujours possible de migrer toutes les caractéristiques des utilisateurs lors du transvasement, il faut donc tester complètement la migration afin d'identifier si une propriété particulière a été perdu pendant le processus et la rajouter.
Ainsi les caractéristiques des objets Builtin comme le compte administrateur ne sont pas migrées, il faudra les ajouter à la main.

Afin de migrer les utilisateurs correctement, suivre les instructions suivantes :

Page de l'assistant

Action

Tester ou effectuer des changements

Cliquer sur Effectuer la migration maintenant

Sélection du domaine

Dans l'onglet Domaine source , sélectionner le nom NetBIOS du domaine source. Dans l'onglet Domaine cible , sélectionner le nom NetBIOS ou DNS du domaine cible.

Sélection des utilisateurs

Cliquer sur Ajouter . Dans la boite de dialogue Sélection Utilisateurs , choisir tous les comptes utilisateurs à migrer (sauf les comptes prédéfinis), choisir Ajouter puis OK .

Sélection de l'unité d'organisation

ADMT liste ici une OU, la laisser comme telle ou corriger au choix. Puis cliquer sur OK .

Options de mot de passe

Sélectionner Migrer les mots de passe .

Options de transition de compte

Sélectionner Activer les comptes cibles . Sélectionner la case Effectuer la migration des identificateurs SID des utilisateurs vers le domaine cible .

Compte d'utilisateur

Entrer les login, mot de passe et domaine d'un membre du groupe administrateurs.

Options de l'utilisateur

Sélectionner la case Traduire les profils itinérants Sélectionner la case Mettre à jour les droits des utilisateurs Décocher la case Effectuer la migration des groupes d'utilisateurs associés Sélectionner la case Corriger les appartenances du groupe d'utilisateurs . Sélectionner la case Ne pas renommer les comptes

Conflits de nommage

Cliquer sur Ignorer les comptes conflictuels et ne pas effectuer la migration

• Lorsque l'assistant a fini son exécution, vérifier les fichiers log afin de s'assurer qu'il n'y a pas d'erreur.
• Lancer utilisateurs et ordinateurs, et naviguer jusqu'à l'OU où les utilisateurs ont été exportés afin de s'assurer qu'ils existent bien.

2.4 Migration des profiles utilisateurs

Les profiles contiennent l'état du bureau ainsi que les données utilisateurs du domaine source.
La migration de profiles tests doit immédiatement suivre celle de la grappe d'utilisateurs test, avant même de vérifier leur consistance.

Si la translation de profile d'un utilisateur échoue, celui-ci pourra certe s'authentifier sur le domaine cible mais pas acéder à ses ressources.  Si la migration des profiles itinérants soit prise en compte lors du processus de transvasement des comptes utilisateurs, il est cependant obligatoire de transvaser une copie locale de ceux-ci, afin de ne pas dépendre uniquement d'un historique Sid.

A noter : Afin de migrer correctement les profiles locaux, le compte de migration doit impérativement être membre du groupe administrateurs (local à la machine, pas celui du domaine). Vous trouverez dans les ressources des outils permettant d'automatiser ceci.

Une fois le compte de migration membre du bon groupe , lancer l'assistant de traduction de la sécurité et faire comme suit :

Page de l'assistant

Action

Tester ou effectuer des changements

Sélectionner Effectuer la migration maintenant

Options de traduction de la sécurité

Sélectionner Objets précédemment inclus dans une migration

Sélection du domaine

dans la case Domaine source , entrer le nom du domaine source.

Dans la case Domaine cible , entrer le nom du domaine cible

Sélection Ordinateur

Cliquer sur Ajouter et ajouter les ordinateurs du domaine, contenant des comptes d'ordinateur.

Traduire les objets

Sélectionner Profil des utilisateurs.

Options de traduction de la sécurité

Sélectionner Remplacer

Après la migration des profiles utilisateur locaux, il faut vérifier son succès. Pour se faire :

• Vérifier le message de statut de chaque ordinateur pour lequel une migration de profile à eu lieu.
• Pour les ordinateur dont le statut n'est pas Succès , vérifier dans les fichiers log les raison de cet échec.
• Pour chaque ordinateur dont le statut est à Succès , cliquer sur Détail de Agent et vérifier le rapport
• Utiliser l'assistant Nouvelle tentative d'exécution des taches pour relancer la procédure sur les ordinateurs qui ont posé problème.
• Tester la connexion d'un utilisateur depuis le PDNF (penser à modifier la stratégie local du contrôleur de domaine pour permettre temporairement la connexion d'un compte sans privilège.

A noter : Si une erreur du type profil non trouvé apparaît, c'est probablement q'un problème d'autorisation a eu lieu. On ne le répètera jamais assez, vérifiez bien que le compte utilisé pour la migration est bien membre du groupe administrateurs (local) de la machine d'où translater la sécurité.

2.5 migration des comptes ordinateurs

Pour chaque grappe d'utilisateurs migrée, il faut de même déplacer une grappe contenant les stations de ceux-ci, de sorte que compte utilisateur et ordinateur existent dans le domaine cible, lorsque l'utilisateur se logue.

Lors du déplacement de comptes ordinateurs entre les domaines, la base SAM se déplace aussi. Les comptes situés dans la base SAM locale (ex : les groupes locaux) se déplacent en même temps, il n'y a donc pas d'étape de plus à exécuter.

A noter : Il faut immédiatement redémarrer les stations de travail qui ont été déplacées afin que leurs ressources ne restent pas dans un état dit indéterminé. De plus, tout comme pour la translation de sécurité, il faut que le compte de migration soit membre du groupe administrateurs local de la machine à migrer.

Afin de migrer correctement les comptes ordinateurs, procéder comme suit :

Page de l'assistant

Action

Tester ou effectuer des changements

Sélectionner Effectuer la migration maintenant

Sélection du domaine

Dans l'onglet Domaine source , sélectionner le nom NetBIOS du domaine source.

Dans l'onglet Domaine cible , sélectionner le nom NetBIOS ou DNS du domaine cible.

Sélection Ordinateur

Cliquer sur Ajouter .

Dans la boite de dialogue Sélectionner Ordinateurs , choisir tous les comptes ordinateur à migrer, choisir Ajouter puis OK . .

Sélection de l'unité d'organisation

Cliquer sur Parcourir .

Dans la boite de dialogue Parcourir le conteneur , chercher le container vers lequel les ordinateurs vont être migrés, puis cliquer sur OK .

Traduire les objets

S'assurer qu'aucune case ne soit sélectionnée.

Computer Options

Dans Temps en minutes avant le redémarrage des ordinateurs à la fin de l'assistant , taper une valeur, par exemple   1.

Sélectionner Do ne pas renommer les ordinateurs.

Conflits de nommage

Sélectionner Ignorer les comptes conflictuels et ne pas effectuer la migration.

• Lorsque l'assistant a fini de s'exécuter, vérifier les fichiers log, afin de s'assurer qu'il n'y a pas d'erreur. En cas d'erreur, lancer l'assistant Nouvelle tentative d'exécution des taches pour dispatcher des agents sur les stations à problème
• Lancer utilisateurs et ordinateurs, et naviguer jusqu'à l'OU où les ordinateurs ont été exportés afin de s'assurer qu'ils existent bien.

3. Restructuration des ressources du domaine source

Restructurer les ressources du domaine NT 4 vers 2003 demande la migration de ressources tel que les stations de travail et serveurs membres, et les groupes locaux partagés vers le nouvel environnement.

3.1. Migration des stations de travail et serveurs membres

Migrer les stations de travail et les serveurs membres qui n'ont pas été migrés pendant le processus de restructuration des comptes par portions.
Ces ressources disposent de leur propre base SAM, lors de leur déplacement, leur base les suit. Les comptes situés dans la base de donnée SAM locale (comme les groupes locaux), utilisés pour permettre l'accès aux ressources sont donc aussi déplacés et n'ont pas besoin d'être migrés par ADMT.

Afin de migrer correctement les stations de travail et serveurs membres, procéder comme suit :

Page de l'assistant

Action

Tester ou effectuer des changements Sélectionner Effectuer la migration maintenant
Sélection du domaine Dans l'onglet Domaine source , sélectionner le nom NetBIOS du domaine source. Dans l'onglet Domaine cible , sélectionner le nom NetBIOS ou DNS du domaine cible.
Sélection Ordinateur Cliquer sur Ajouter . Dans la boite de dialogue Sélectionner Ordinateurs , choisir tous les comptes ordinateur à migrer, choisir Ajouter puis OK . .
Sélection de l'unité d'organisation Cliquer sur Parcourir . Dans la boite de dialogue Parcourir le conteneur , chercher le container vers lequel les ordinateurs vont être migrés, puis cliquer sur OK .
Traduire les objets S'assurer qu'aucune case ne soit sélectionnée.
Computer Options Dans Temps en minutes avant le redémarrage des ordinateurs à la fin de l'assistant , taper une valeur, par exemple   1. Sélectionner Do ne pas renommer les ordinateurs.
Conflits de nommage Sélectionner Ignorer les comptes conflictuels et ne pas effectuer la migration.

• Lorsque l'assistant a fini de s'exécuter, vérifier les fichiers log, afin de s'assurer qu'il n'y a pas d'erreur. En cas d'erreur, lancer l'assistant Nouvelle tentative d'exécution des taches pour dispatcher des agents sur les stations à problème
• Lancer utilisateurs et ordinateurs, et naviguer jusqu'à l'OU où les ordinateurs ont été exportés afin de s'assurer qu'ils existent bien.
• Si l'ordinateur n'a pas redémarré, bien que son domaine ait changé, vous pouvez le redémarrer à distance. Si son domaine d'appartenance n'a toujours pas changé, vous pouvez modifier celui-ci en le spéciafiant à la main, en utilisant l'outil Netdom ou un script automatisant le changement de domaine.

3.2 Migration des contrôleurs de domaine

Migrer les contrôleurs de domaine représente une tache plus ardue que la procédure de migration des serveurs membres, en effet :

• Les BDC NT 4.0 ne peuvent être déplacé entre deux domaines
• Tous les droits d'accès des DC sont basés sur des groupes locaux partagés qui doivent être migrés.

Pour cette raison, il ne faut migrer que les contrôleurs qui disposent de ressources partagées et rétrograder les autres et penser à migrer les BDC avant le PDC.

3.2.a Migrer les groupes Locaux Partagés

C'est la première étape avant de mettre à jour son contrôleur vers Windows 2003. A noter qu'il n'est pas nécessaire de modifier les ACL durant ce processus, celle-ci continuant de référencer le groupe local partagé dans le domaine source.

Dans la mesure ou ces groupes ont déjà été migrés vers le domaine cible avant, les utilisateurs peuvent toujours accéder aux ressources. En cas de problème il est possible de demander une re-migration des groupes a l'ADMT en relançant une procédure de migration des comptes de groupes.

3.2.b Migrer les BDC

Si un BDC ne dispose pas de ressources partagées, il suffit de le rétrograder puis le faire joindre le domaine cible. Dans le cas contraire, il faut suivre les étapes suivantes afin de ne pas perdre de données lors de la migration :

• Déconnecter un BDC du réseau, le promouvoir en PDC
• Mettre à jour ce PDC vers un contrôleur Windows 2003
• Lancer l'assistant Active Directory en lui demandant de rétrograder le PDC en serveur autonome. (cocher la case ce contrôleur est le dernier du domaine lorsqu'il s'agira du dernier)
• Joindre le(s) serveur autonome au domaine cible

Attention : penser à relancer une procédure Traduction de la sécurité pour nettoyer les dernières entrées du domaine source.

3.2.c Compléter la migration des ressources

Utiliser l'assistant Traduire la sécurité sur les serveurs membres pour nettoyer les ACLs restantes de sorte que l'historique SID du domaine source soit reporté sur le domaine cible.

Afin de migrer correctement les stations de travail et serveurs membres, procéder comme suit :

Page de l'assistant

Action

Tester ou effectuer des changements

Sélectionner Effectuer la migration maintenant

Options de traduction de la sécurité

Sélectionner Objets précédemment inclus dans une migration

Sélection du domaine

dans la case Domaine source , entrer le nom du domaine source.

Dans la case Domaine cible , entrer le nom du domaine cible

Sélection Ordinateur

Cliquer sur Ajouter et ajouter les ordinateurs du domaine, contenant des comptes d'ordinateur.

Traduire les objets

Désélectionner Profil des utilisateurs.

Cocher toutes les autres options

Options de traduction de la sécurité

Sélectionner Remplacer

3.2.d Migrer le PDC

Rétrograder le PDC restant pour finir la migration, puis y installer Windows 2003.
Durant la phase de rétrogradation et de mise à niveau vers Windows Server 2003 les ressources partagées ne seront plus disponibles du fait de la disparition du domaine.
Attention Dans le cas ou le PDC est aussi serveur de ressources (fichiers...) il est conseillé de déplacer les ressources vers un serveur membre, permettant ainsi de limiter le temps de non disponibilité des ressources partagées au seul changement de domaine de la machine et redémarrage de la machine.

A noter : Microsoft propose gratuitement l'outil graphique FSMT afin de réaliser ceci sans la moindre connaissance de scripting.

3.3 Taches post migratoires

Après avoir migré les comptes utilisateurs, groupes, . vers le domaine cible, il faut compléter le processus de migration de comptes. Pour ce faire :

• Transférer l'administration des utilisateurs et groupes vers le domaine cible.
• Stopper l'administration des utilisateurs et groupes du domaine source
• Maintenir au moins un contrôleur de domaine dans le domaine source jusqu'à la fin totale de la migration
• Sauvegarder le PDC du domaine source
• Commencer l'administration des utilisateurs et groupes du domaine cible.
• Supprimer les relations d'approbation entre le domaine NT 4.0 et le nouveau domaine.
• Supprimer le compte utilisé pour la migration
• Si un groupe ou utilisateur affiche account unknown , lancer l'assistant Traduction de la sécurité pour nettoyer les entrées.

4. Annexe

Des informations concernant la planification pré migration peuvent être trouvées sur Technet, dans Planning an Active Directory Deployment project ainsi que dans la partie détermination du design.

Des ressources complémentaires concernant la migration du domaine NT 4.0 vers 2003 peuvent être trouvées sur Technet, dans la partie restructuring Windows NT 4.0 Domains to an Active Directory Forest.