bonjour ginji40
Vous vous aventurez par la méthodo que vous souhaitez emprunter à beaucoup de travail et de soucis. La réponse à votre besoin tient en 1 mot : ADMT (AD Migration Tool)
Un tuto ici : ADMT : outil de migration de domaine Active Directory - RDR-IT
Le principe :
- Installation Nouveau serveur, promotion en DC Dans Nouveau Domaine
- Création relation d’approbation entre ancien Domaine et nouveau Domaine
- Installation ADMT sur une machine (pas nécessairement un DC, ni un serveur).
- Conf. ADMT
- Tests
- Migration
L’AD Nouveau DC est « brut de fonderie », pas de comptes utilisateurs, pas de comptes machine, pas d’OUs, pas de groupes créés. ADMT va tout migrer : comptes users, groupes, OU, mais aussi comptes machines.
Il y a cependant quelques prérequis à vérifier. Par exemple, dans votre cas, les postes sont en DHCP, c’est donc le DHCP qui fournit le ou les DNS … et c’est c’est derniers qui fournissent aux users/Computers les enregistrements DSN de type SRV (Service Locator) et plus précisément les enregistrements SRV LDAP et Kerberos (hé oui, si vous vous demandiez comment un compte user/Computer trouvait un DC pour s’authentifier, et bien maintenant vous le savez, c’est grâce au DNS). Revenons à nos moutons. Le (les) DHCP fournit les DNS de AncienDomaine, mais il devra pendant le temps de la migration fournir également les DNS de NouveauDomaine. Il faut également prendre en compte que le DHCP fournit le Domaine DNS qui est par défaut certainement AncienDomaine.xxx. Il devra fournir également nouveauDomaine.xxx, sinon les machines une fois migrées ne pourront pas s’authentifier sur le nouveau domaine.
Avantages de cette solution :
- Pas de déplacement machine par machine (fastidieux)
- On reprend comptes, groupes, OUs.
- Pour les GPOs, on peut les exporter depuis l’ancien domaine très facilement (quelques lignes en powershell), puis sur le nouveau domaine, créer des nouvelles GPOs (vides) et Importer depuis un backup. En qq minutes, c’est fait.
- On part sur un OS propre, et un domaine à peu près propre (tout dépend de l’organisation AD en place, si vous reproduisez à l’identique une situation « pourrie », cela ne sera guère mieux à la cible).
Inconvénient :
- Il y a un travail de préparation et de tests, … mais qui prendra toujours moins de temps que « fait à la mimine ». Et que celui qui fait cela à « l’arrache » soit maudit et aille bruler dans le 7ème cercle des enfers" (version douce : qu’il change de métier).
Points d’attention :
Changer d’annuaire et migrer les comptes c’est une chose, … mais qu’en est-il des autres ressources de l’ancien domaine (Services de fichiers (Partages et HomeDir), d’impression, de mise à jour (WSUS), d’AV, et autres (GPO qui pointent sur des partages ancienDomaine par ex) ? Toujours sur l’ancien domaine. Il faudra penser à migrer et reparamétrer ces ressources. Dans un 1er temps, pas gênant, étant donné qu’il y a une relation d’approbation, un compte User/Computer dans Nouveau domaine pourra accéder à des ressources sur ancienDomaine (grâce à la relation d’approbation et au SIDHistory), mais il faut penser à migrer ces ressources. Quelque temps plus tard, … enfin c’est fait, … il n’y a plus rien qui tourne dans AncienDomaine, et bien vous pouvez éteindre les machines (je vous conseille de les laissez simplement éteintes qq sem., juste au cas ou … vous auriez oublié qq chose. Puis après ce temps de rétention « sécuritaire », soyez libre (si le Hardware tient la route encore), de les remasteriser en nouveaux serveurs … dans NouveauDomaine, de les refourguer à un broker, de vous en servir comme « oeuvre d’art vintage » et de les faire trôner dans votre salon, d’en faire un feu de joie, ou tout autre chose qui vous viendrait à l’esprit.
cordialement
Olivier
