ADMT (Active Directory Migration Tool)

 

Présentation

Il arrive que l’on rencontre des situations où il est nécessaire de revoir l’ensemble de l’organisation. C’est le cas par exemple lors de la fusion ou de la scission d’une entreprise.  Il s’agit d’une opération de migration des objets Active Directory d’un domaine vers un autre.

L’outil de migration Active Directory Migration Tool permet d’effectuer cette opération.

Cette suite d’article a pour but de présenter cet outil et fait référence au guide de migration ADMT  disponible à l’adresse http://www.microsoft.com/fr-fr/download/details.aspx?id=19188.

 

Que peut-on faire ?

 

L’image ci-dessous nous présente quelques possibilités de l’outil :

A gauche nous avons le domaine source avec des utilisateurs, des groupes et des ordinateurs. A droite le domaine cible. L’opération permet de migrer ses différents éléments tout en autorisant le compte du nouveau domaine de continuer à accéder aux ressources partagées du domaine source. La migration en elle-même ne donne pas accès aux utilisateurs du domaine source à des ressources du domaine cible.

Pour comprendre le principe il faut déjà définir certains attributs d’un objet AD (utilisateurs, ordinateurs ou groupe). Chaque objet AD possède un identifiant unique dans l’environnement (SID), comme par exemple : « S-1-5-12–7623811015-3361044348-030300820-1013 ». La partie en rouge est identique pour l’ensemble du domaine alors que la partie en bleue est unique pour chaque objet du domaine. Lorsqu’un objet est authentifié par un contrôleur de domaine il obtient un « jeton d’accès ». Son jeton d’accès contient son SID ainsi que tous les SID de tous les groupes auxquels il appartient directement ou par imbrication de groupe (c’est pour cela qu’il faut rouvrir la session lorsqu’on ajoute un utilisateur dans un groupe). La migration ADMT permet d’ajouter à ce jeton son historique SID venant de l’ancien domaine ainsi celui des groupes auxquels il appartient afin qu’il puisse accéder aux ressources qui n’ont pas encore été migré vers le nouvel AD.

 

Nous en déduisons déjà qu’il est préférable de migrer les utilisateurs puis les ordinateurs et en dernier les serveurs de ressource. Cela permet de faire une migration progressive et de conserver l’accès aux ressources pour les utilisateurs déjà migrés et ceux travaillant encore avec le compte du domaine source.

 

Note : sur Windows 7 et supérieur vous pouvez exécuter la commande « whoami /groups », pour voir les groupes auxquels vous appartenez.

Migration intra forêt ou inter forêt

 

-          la migration inter forêt permet de créer une nouvelle forêt AD et d’y créer un clone de l’objet source. Dans ce type de scénario l’objet existe dans le domaine cible et dans le domaine source. Il est possible de désactiver l’utilisateur du domaine source lors de la migration ou de planifier sa désactivation automatique au bout d’un certain nombre de jours.

 

-          la migration inter domaine permet de déplacer un objet d’un domaine vers un autre domaine dans la même forêt. Il s’agit cette fois-ci d’un déplacement de l’objet car celui-ci n’existera plus dans le domaine source.

Les versions ADMT

Il existe différentes versions d’ADMT permettant de couvrir une majorité de scénarios, mais il faut bien comprendre que toutes les combinaisons entre domaines source et domaine cible ne sont pas possibles.

 

 

Ce tableau extrait du guide de migration ADMT( http://www.microsoft.com/fr-fr/download/details.aspx?id=19188) permet d’identifié les possibilités :

Version d'ADMT

Plate-forme d'installation

Conditions requises pour le domaine source

Conditions requises pour le domaine cible

Objets de migration de l'ordinateur pris en charge

ADMT v3.0 (http://go.microsoft.com/fwlink/?LinkID=68791)

Windows Server 2003

Les domaines source peuvent contenir des contrôleurs de domaine qui exécutent Windows NT, Windows 2000 Server ou Windows Server 2003. Aucun niveau fonctionnel minimum de domaine n'est requis pour un domaine source.

Le niveau fonctionnel minimum de domaine cible est Windows 2000 natif.

Permet de migrer des ordinateurs qui exécutent Windows 2000 Professional, Windows XP, Windows NT 4, Windows 2000 Server et Windows Server 2003.

ADMT v3.1 (http://go.microsoft.com/fwlink/?LinkId=121732)

Windows Server 2008

Les domaines source peuvent contenir des contrôleurs de domaine qui exécutent Windows 2000 Server, Windows Server 2003, ou Windows Server 2008. Aucun niveau fonctionnel minimum de domaine n'est requis pour un domaine source mais ADMT v3.1 ne peut pas être utilisé pour migrer des objets à partir de domaines Windows NT 4.

Le niveau fonctionnel minimum de domaine cible est Windows 2000 natif.

Si le domaine cible a des contrôleurs de domaine qui exécutent Windows Server 2008 R2, utilisez ADMT v3.2.

Remarque

Il existe des problèmes connus qui surviennent lorsque vous utilisez ADMT v3.1 pour migrer des objets vers un domaine qui a des contrôleurs de domaine Windows Server 2008 R2. Pour plus d'informations, voir l'article 976659 de la Base de connaissances Microsoft (http://go.microsoft.com/fwlink/?LinkId=182290).

Permet de migrer des ordinateurs qui exécutent Windows 2000 Professional, Windows XP, Windows Vista, Windows 2000 Server, Windows Server 2003 et Windows Server 2008.

ADMT v3.2 (http://go.microsoft.com/fwlink/?LinkId=186197)

Windows Server 2008 R2

Le niveau fonctionnel minimum de domaine source est Windows Server 2003.

Le niveau fonctionnel minimum de domaine cible est Windows Server 2003.

Permet de migrer des ordinateurs qui exécutent Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2008 et Windows Server 2008 R2.

 

Nous remarquons :

-depuis un domaine NT4 il n’est possible d’utiliser que la version 3.0. La migration ne peut se faire que vers un domaine avec un niveau fonctionnel Windows 2000 natif et l’outil de migration ne peut être installé que sur une version 2003. Nous constatons donc qu’il n’est pas forcément possible de migrer un domaine ancien vers des environnements récents dans une étape unique.

- la dernière version publié au moment d’écrire cet article (3.2) ne fait pas référence à Windows 2012 et 2012 R2. Néanmoins il est possible de migrer vers des contrôleurs de domaine en 2012 ou 2012R2. Si vous êtes dans ce cas consulter l’article : http://technet.microsoft.com/en-us/library/active-directory-migration-tool-versions-and-supported-environments(v=ws.10).aspx

 

 

Avant de commencer :

-          planifier votre migration et faites le point sur l’ensemble de vos applications,

-          exécuter des sauvegardes régulières de vos contrôleurs de domaine incluant l’état du système. Pour plus de détails sur la partie sauvegarde Active Directory vous pouvez consulter l’article suivant : http://pbarth.fr/node/15

-          déchiffrez les fichiers utilisant le système EFS faute de quoi vous risquez de perdre l’accès au contenu

-          vérifier la synchronisation des horloges entre le domaine source et cible. L’authentification Kerberos est dépendante de la synchronisation des horloges et pourrait échouer. Vous pouvez consulter l’article suivant pour comprendre comment géré la synchro des horloges dans un domaine AD : http://pbarth.fr/node/87

 

 

Exchange :

 

Si vous disposez d’un environnement Exchange il est possible de migrer les boîtes aux lettres vers un environnement Exchange 2010 ou 2013. Ce n’est pas l’objectif de cet article néanmoins vous trouverez quelques pistes dans les liens suivants.

http://jaxelos.wordpress.com/2011/11/23/interforest-migration-with-admt-3-2-and-exchange-2010-interforest-migration-2/

http://blogs.technet.com/b/exchange/archive/2010/08/10/3410619.aspx

Tags: 

Theme: 

Annee: 

Commentaires

ADMT - cas d'utilisation

Bonjour Philippe,
Merci pour cet article.
En effet, je compte mener une opération de restructuration de mon architecture AD en utilisant ADMT.
En effet, l'entreprise où je travaille est repartie sur 4 regions. Chaque région a mis en place sa forêt AD basée sur le nom de domaine abc.com , on se retrouve donc avec 4 forêts indépendantes qui portent le même nom de domaine.

Notre objectif est d'unifier tout ça dans une forêt unique qui s'appellera soc.local

Je pense que ADMT fait bien l'affaire?

Sinon, qu'en est-il de la jonction des postes utilisateurs à la nouvelle forêt ?
Vont-ils retrouver leurs sessions?
Merci

ADMT - cas d'utilisation

on se retrouve donc avec 4 forêts indépendantes qui portent le même nom de domaine.
Le fait que les 4 domaines portent le même nom ne vous simplifiera pas la migration. Vous ne pouvez avoir qu'une approbation avec un nom précis à un moment donné. Il vous faudra migrer progressivement chaque entreprise. Oui les utilisateurs retrouvent leur environnement en migrant les postes dans la nouvelle forêt.

Migration AD

Bonjour Philippe,
Merci pour ton retour rapide!
Je commence déjà à réfléchir à propos d'un plan de travail qui peut se résumer en ce qui suit:

1. Création du nouveau serveur Contrôleur de Foret principal soc.local
2. Mise en place de la machine ADMT
3. Création de la relation d'Approbation entre soc.local la première forêt abc.com
4. migration via ADMT des objets AD depuis abc.com vers site1.soc.local
5. Jonction des machines de abc.com au domaine site1.soc.local
6. Suppression de l'approbation [soc.local , abc.com],
7. Eradication de la forêt abc.com (1er site)
8. reprise des etapes 3-7 pour la forêt abc.com (2ème site) pour une migration vers site2.soc.local
9. reprise des etapes 3-7 pour la forêt abc.com (3ème site) pour une migration vers site3.soc.local
10. reprise des etapes 3-7 pour la forêt abc.com (4ème site) pour une migration vers site4.soc.local

Qu'en pensez vous?

Hello,

Hello,
Je n'ai pas compris tu veux faire une forêt avec 4 domaines ? Si oui sache que le domaine racine est particulier car il contient des groupes de sécurité privilégié dans la forêt (admin de l'entreprise, du schéma etc ...). Au niveau AD il n'y pas de nécessite à faire un domaine par site. La question du multi-domaine dépend avant tout de la façon d'administrer les environnements et des limites de sécurité. Comment as-tu prévu de gérer les utilisateurs (centralisé), les accès ? les ressources centralisés ? ou chaque site est indépendant ?

Gestion Multisites

Bonjour Philippe,

De part notre répartition géographique, nous avons aujourd'hui une équipe locale par région qui gère sa forêt d'une façon autonome.

D'autre part, et pour des raisons de performances, nous souhaitons garder un controleur de domaine au niveau de chaque région, pour éviter des problèmes de congestion du WAN,

C'est pour cela que j'ai pensé à une organisation multidomaine?

Par contre, les principaux objectifs que nous comptons atteindre c'est :

- Harmoniser les politiques GPO sur tous les postes utilisateurs,
- Avoir une seule source pour l'authentification,
- Permettre l'intégration avec d'autre système (Messagerie / Bases de données / Filtrage de Contenu)

Vous voyez que le multidomaine n'est pas un bon choix?

Merci

Re Gestion Multisites

Vous pouvez n'avoir qu'un domaine et des contrôleurs de domaines sur chaque site. Cela ne crée pas de congestion en soi. La partie performance va dépendre de la répartition des applications. Si a côté vous mettez un seul serveur de ficher sur le site principale vous verrez que ce n'est pas l'AD qui vous posera le plus de problème. Même question si vous utiliser un intranet ou un serveur de messagerie centralisé. Les serveurs d'impressions doivent être géré par site.

La gestion décentralisé est un argument a prendre en compte qui oriente vers un environnement multi domaine. Sachez que les scénarios de Disaster Recovery sont un peu plus lourd avec plusieurs domaines. Il est préférable d'avoir au moins 2 DC par domaine avec des sauvegardes de l'état du système. Il peut aussi s'avérer utile de créer un domaine racine neutre vu que ce dernier dispose des groupes privilégiés au niveau de la forêt.

Restructuration AD

Bonjour Philippe;

Merci beaucoup pour ta collaboration, je tiendrais compte de tes précieuse remarques.

Bonne journée

Droits quite à une migration

Bonjour,
J'ai suivi tes précieux conseils, et j'ai commencé à migrer mes groupes, quelques user, quelques PC. Tout c'est bien passé, les attributs sont bon, les SID historique correspondent aux SID sources, etc etc
Sauf que, les droits depuis le domaine final, vers le domaine source ne fonctionnent pas.
J'ai lu et relu, rien n'y fait. Bien sur les "builtin" fonctionnent.
Une idée ??
merci

Perte des droits sur le domaine source

Bonjour,
j'ai suivi à la lettre tes conseils, et je t'en remercie. Une fois les premier éléments migrés, je ne peux accéder à mes fichiers du domaine source.
J'ai vérifié les attributs user, group.. et les SID Historiques correspondent aux SID du domaine source.

une idée
encore merci

Re : Perte des droits sur le domaine source

Tu as bien vérifié dans ton approbation que le SID Filtering est désactivé ? Ce paramètre de sécurité activé par défaut lors de la création d'une approbation empêche l'utilisation du Sid History. Lorsqu'il est désactivé l'approbation apparaît avec un avertissement. Dans le cas d'une migration ADMT il faut le désactiver pour que l'utilisateur migré puisse utilisé son SID History afin d'accéder à la ressource dans le domaine source.
Voir :
http://pbarth.fr/node/108

Migration et consolidation

Bonjour Philippe,

J'ai une question a propos d'une migration inteforet et intraforet.
Nous allons réorganiser l'active directory en implémentant une nouvelle convetion de nommage avec un nouveau modele de délégation.

Devons nous migrer les groupes locaux qui donnent accès au ressources avec les mêmes noms au début et ensuite changer le nom des groupes vers la nouvelle convention de nommage ? une fois biensûr que nous sommes sures que les accès sont consérvés ,quels sont les attribut a changer si c'est le cas ?

Merci d'avance pour l'eclaircissement :) j'aurais surement d'autres question par la suite :)

Migration et consolidation

Bonjour Philippe,

J'ai une question a propos d'une migration inteforet et intraforet.
Nous allons réorganiser l'active directory en implémentant une nouvelle convetion de nommage avec un nouveau modele de délégation.

Devons nous migrer les groupes locaux qui donnent accès au ressources avec les mêmes noms au début et ensuite changer le nom des groupes vers la nouvelle convention de nommage ? une fois biensûr que nous sommes sures que les accès sont consérvés ,quels sont les attribut a changer si c'est le cas ?

Re ; Migration et consolidation

D'abord désolé pour la lenteur de la réponse. Comme tu peux le voir les commentaires sont soumis à approbation avant d'être visible. Comme plus de 99% des commentaires sont publicitaires et en anglais, le tri représente pas mal de temps. Je n'ai pas tout compris sur la question. Quand tu parles de groupes locaux tu parles de groupes de domaines ou de groupes locaux aux postes. Sinon il est préférable de procéder par étapes et de ne pas tout mélanger lors de l'ADMT. Humainement c'est plus simple de traiter un point après l'autre.
quels sont les attributs à changer si c'est le cas .
Tu parles pour renommer les groupes. Renommer un groupe n'a pas d'incidence directe sur les droits.
Les droits sont gérés par rapport au SID des groupes, identifiant unique qui ne change pas.
Seules des requêtes LDAP utilisant les noms des groupes, peuvent poser problème. Par exemple avec SCCM si tu fais un regroupement basé sur une requête et qui recherche les membres d'un groupe par le nom.
Pour renommer il suffit de faire un clic droit renommer dans la console utilisateurs et ordinateurs...
Nouveau Texte

Droit sur dossier migré

Bonjour et merci de ce fantastique article qui m' a bien servi. J'ai une question à propos des droits des user sur les dossiers migré sur le nouveau serveur de fichier.
J'ai donc effectué ma migration (groupe, user, AD) et ensuite copié les data via Robocopy. Hors sur le domaine de destination je vois bien mes users de l'ancien domaine et tant que le user se logue sur l'ancien domaine il à accès aux fichiers. S'il se logue sous le nouveau domaine il n'a plus d'accès aux data. Lorsque je regarde les droits NTFS je vois bien les groupes de l'ancien domaine avec mes users mais là il faut que j'entre les nouveaux groupes de mon nouveau domaine. Si je ne le fais pas à la main pas d'accès aux users.
Peut on "transformer" les groupes du domaine A.local en B.local ? Quel moyen avons nous pour le faire automatiquement ?
Merci

RE : Droit sur dossier migré

Les permissions NTFS et les groupes sont normalement migré par ADMT. En générale on migre les serveurs de ressources à la fin pour que les utilisateurs de l'ancien et du nouveau puisse y accéder. La migration d'un serveur de fichier se passe comme pour un autre poste du domaine.

Si tu migres les fichiers et les partages manuellement tu dois remettre les bons droits.

Salut et merci pour ce

Salut et merci pour ce Feedback rapide.

L'ancien serveur de fichier c'est le contrôleur de domaine donc impossible à migrer comme pour un poste. J'ai lu plus loin sur ton site qu'il fallait désactiver le SID Filtering. Cela pourrait peut être venir de là ? Qu'en penses tu ?

En tout cas je récupère bien les droits de l'ancien domaine sur le nouveau, pas de soucis la dessus et via ADMT oui je récupère les groupes et les users (et je migre les postes avec).

Lorsque tu dis "Si tu migres les fichiers et les partages manuellement tu dois remettre les bons droits." tu le fais bien avec robocopy et le /SEC ? c'est bien cela ?

<p>J'ai lu plus loin sur ton

<p>J'ai lu plus loin sur ton site qu'il fallait désactiver le SID Filtering. Cela pourrait peut être venir de là ? Qu'en penses tu ?</p>

Oui si SID Filtering n'est pas dédactivé sur l'approbation les utilisateurs migré sur le nouveau domaine ne peuvent pas accéder à une ressource de l'ancien domaine.

SID Filtering

Hello Philippe

Merci pour ce feedback, je bosse la dessus today

Merci

Migration windows xp sp3 X86 depuis admt 3.2

Bonjour, La migration depuis admt 3.2 fonctionne très bien sauf pour des PC en Windows XP SP3 32 bits. Avez-vous des pré requis ou un retour d'expérience. Merci.

Migration windows xp sp3 X86 depuis admt 3.2

Désolé pour le retard de réponse: En fait ce n'est pas un soucis de Windows xp: je migre un domaine Windows 2003 vers un nouveau domaine Windows 2008 R2: Les premières migrations se sont bien déroulées, hors depuis quelques jours , la migration des PC ne fonctionnes plus , en fait dans les logs tout est migré sauf que le PC en cours de migration ne redémarre pas et ne s'inscrit pas dans le nouveau domaine, par contre son nom d'ordinateur apparaît bien dans le nouveau domaine, dans les logs admt j'ai ce message d'erreur à la fin du fichier : ERR3:7075 L'affiliation au domaine n'a pas pu être modifié, hr=8007054a Cette opération n’est permise que pour le contrôleur principal du domaine.

Ajouter un commentaire

Bloc brute

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.
CAPTCHA
Cette question empêche les soumissions de spam automatisées. Merci de votre compréhension
Image CAPTCHA
Enter the characters shown in the image.