Migration de domaine AD

YoupiDollarZ

Je suis un ananas
Avis aux admins et autres pros de win serveur,

Je suis stagiaire et je dois migrer un domaine suite à un rachat de boite.
L'idée est que l'on va intégrer leur AD au notre et avoir un seul domaine.

Est ce que vous avez des conseils par rapport à la marche à suivre ?
J'ai testé un migration d'un domaine vers un autre en vm via l'utilitaire ADMT. Ca marche pas mal.
Cependant j'aurais plusieurs questions. Une fois les UO, groupes, users migrés. Que fait on au niveau du DC source? Rename du domaine ou on le retire de l'ancien domaine pour l'inclure au domaine cible ?

J'aimerais aussi créer un admin limité pour que l'admin de la boite rachetée puisse administrer seulement l'UO de "sa boite". J'ai vu qu'il était possible de créer des délégations d'une UO à un user ou à un groupe. Cependant (d'après ce que j'ai lu) il le fera via une console MMC et il n'aura donc plus la main sur le DC physiquement.
Avant il l'administrait via l'admin du domaine en rdp mais ici avec l'intégration de la boite, il n'est pas membre de l'équipe IT de la boite mère (mentalité publique...). Comment pouvoir lui donner des droits semblables et une utilisation semblable sans qu'il utilise "notre" compte de domaine?

Si vous avez d'autres conseils, ils sont les bienvenus !

Merci.
 

krizzeur

Elite
Salut,

Combien de comptes à migrer? Si ça se limite à de la PME, je me casse pas la tête à mettre en place un process de migration via admt.

Un exchange est en route? Quid des ressources dans l'ancien domaine? J'imagine qu'elles doivent êtres migrées dans le domaine de dest?

En général dans les grosses organisations, trust entre les domaines le temps de migrer les comptes (admt) et ensuite les ressources de l'ancien domaine vers new domain. Ensuite clean SID, olds groups AD et puis un simple switch off des anciens DCS.

Concernant la délégation il y a un délégation wizard pas trop mal fait. Idéalement, tu fais une groupe qui a des droits spécifiques et tu lui envoie un compte admin membre de ce groupe qui a des droits délégués.
 
Mes réponses en vrac :

  • Effectivement ADMT est la solution, tu peux aussi le coupler à PES (Password export server) afin de migrer les mots de passes utilisateurs dans la foulée.
  • Soit tu fais tous les utilisateurs en un coup (BigBang), soit tu peux faire un "trust one way" afin d'interconnecter tes domaines dans un premier temps, pour ensuite faire une migration progressive avec ADMT. De toute façon PES requiert un trust pour fonctionner (si je me souviens bien).
  • Lorsque la migration ADMT est terminée, a savoir que tu as migré tous tes utilisateurs du domaine A vers B, plus besoin de l'ancien domaine A, tu peux le démanteler complètement.
  • Pour l'administration, je ne ferais pas forcément une délégation, il suffit de mettre les droit au type au niveau de l'OU racine qu'il doit gérer
  • Effectivement à partir du moment ou tu ne le mets pas dans le compte "domain admin", il ne pourras pas s’authentifier en local RDP sur le domain controller. il faudra lui installer les RSAT tools sur un PC ou sur un autre serveur.
C'est un début, je suis dispo pour t'aider si faut entrer plus dans les détails.
Ben
 
1er
OP
YoupiDollarZ

YoupiDollarZ

Je suis un ananas
Merci pour vos réponses :)
J'ai moins de 80 comptes à migrer (et encore...).
Pas d'exchange on bosse avec Lotus notes.

Qu'est ce que tu entends par clean SID? Via admt je migre les SIDs, j'ai cru comprendre qu'ils seront identiques à l'ancien domaine.

J'utilise aussi PES mais il faut que la GPO des passwd source et cible soit raccord sinon ça va merder...

Pour le trust, je ne me suis pas cassé la tête, j'ai fait un bidirectionnel.

Qu'en est il une fois la migration terminée? Rename du domaine ou formatage et intégration propre au domaine cible?
 

Jereck

Α & Ω
Staff
C'est pas pour le temps que ça prends de formatter et de réinstaller Windows.

Si tu te contente de le sortir de l'ancien et de le remettre dans le nouveau, tu risque de garder des crasses, et tout, évite.
 
  • J'aime
Les réactions: Nouk
1er
OP
YoupiDollarZ

YoupiDollarZ

Je suis un ananas
C'est pas pour le temps que ça prends de formatter et de réinstaller Windows.

Si tu te contente de le sortir de l'ancien et de le remettre dans le nouveau, tu risque de garder des crasses, et tout, évite.
C'est ce que je me suis dit aussi, autant partir sur une base saine :)
 
Qu'en est il une fois la migration terminée? Rename du domaine ou formatage et intégration propre au domaine cible?

Je ne comprend pas trop ce que tu veux dire par la, ton domaine source n'aura plus de raison d'être, pourquoi veux-tu le nommer ou l'intégrer ?

Quand tes utilisateurs sont migré tu peux le shooté.
 
Je ne comprend pas trop ce que tu veux dire par la, ton domaine source n'aura plus de raison d'être, pourquoi veux-tu le nommer ou l'intégrer ?

Quand tes utilisateurs sont migré tu peux le shooté.

EDIT : Ok je penses avoir compris, tu parles des desktop. Je partirais aussi sur une install propre. Par contre pour 80 machines, ne le fait pas a la mains, fait une image (regarde MDP et sysprep) unique que tu déploie sur toutes les machines en PXE.
 
1er
OP
YoupiDollarZ

YoupiDollarZ

Je suis un ananas
Non en fait, j'aimerais inclure l'ancien DC comme dc du domaine cible ^^

Donc le formater et l'intégrer au domaine cible, tout simplement = )
 
Non en fait, j'aimerais inclure l'ancien DC comme dc du domaine cible :p

Donc le formater et l'intégrer au domaine cible, tout simplement = )

Oui alors réinstalle le proprement, même OS et même niveau de patch que celui de ton domaine cible, ensuite tu le promote en DC dans ce dernier.
 
1er
OP
YoupiDollarZ

YoupiDollarZ

Je suis un ananas
Ok super,
Au niveau SID, j'active l'historique SID et d'après ce que je vois il conserve son ancien SID ainsi que celui du domaine cible?
Car d'après ce que j'ai lu, si il ne garde pas son ancien SID, cela va poser des problèmes d'accès aux ressources (groupes pas content si != SID )
 
Ok super,
Au niveau SID, j'active l'historique SID et d'après ce que je vois il conserve son ancien SID ainsi que celui du domaine cible?
Car d'après ce que j'ai lu, si il ne garde pas son ancien SID, cela va poser des problèmes d'accès aux ressources (groupes pas content si != SID )
Le SID history c'est uniquement si tu fais un parallel run, a savoir si tes utilisateurs migré dans le nouveau domaine, doivent toujours accéder a des ressources présente dans l'ancien domaine.

Par exemple un serveur de fichiers , une mailbox exchange ou un print server.
Si tu migres tout d'un coup (bigbang un weekend par example) pour moi tu n'as pas besoin du SID history.
 
Ah super alors. Maintenant que tu me le dis, ca me parait logique :p

Ca doit être effectivement pour assurer le service de fonctionner.
Il faudra que je regarde aussi pour voir si ADMT sera capable de dire aux postes clients de passer du domaine source au domaine cible.

A première vue oui.

http://blog.thesysadmins.co.uk/admt-series-11-computer-migration-wizard.html
Par expérience, autant ADMT migre bien les utilisateurs, autant je te le déconseille pour les PC, ça va marcher mais tu vas traîner des merdes et au finale tu devra quand même tout redéployer.

C'est le genre de truc qui risque de te plomber une migration rondement menée!

Je te conseille de redéployer toutes les machines avec l'image standard de ta société, si elle n'en a pas, d'en créer une. En PXE multicast, ca te prendra 2h pour tout redéployer.

Ensuite tu configures tous les mapping Drives/printers/... par GPO pour tes nouveaux utilisateurs, histoire que leur eenvironnement de travail soit complet, fonctionnel, neuf et rapide au premier login!

Le succès d'une migration dépend du ressenti utilisateur, ne l’oublie pas!

Ben
 
1er
OP
YoupiDollarZ

YoupiDollarZ

Je suis un ananas
Ah, ca risque d'être chiant ca = /

Le truc c'est que la boite est répartie sur 3 sites... Ca va pas faciliter la chose ca...
 
Ah, ca risque d'être chiant ca = /

Le truc c'est que la boite est répartie sur 3 sites... Ca va pas faciliter la chose ca...

Après c'est mon expérience personnelle, ça peut dépendre fortement en fonction des machines, de l'OS, de l’environnement utilisateurs, des applications utilisées et de la complexité de l'infra, .....

En gros ça vaut la peine de le tester en LAB dans ton environnement pour voir si c'est viable.

Quand je dis que le plus propre c'est de repartir a zéro, ca ne veut pas dire que ça marche pas. C'est un peux comme mettre à jour XP en 7, ça marche, mais tout le monde te conseillera de réinstaller !
 
1er
OP
YoupiDollarZ

YoupiDollarZ

Je suis un ananas
Ma chance c'est que tout le parc à migrer est en seven. Pas de vieux xp cra-dégueux :)
 

krizzeur

Elite
Mode big bang ça peut se faire si tu as un environnement très bien géré et où le niveau informatique des utilisateurs est bon (c-a-d qui s'y retrouvent facilement après une migration)

Vu comme ça, je la ferai en mode trusted forest, new accounts (+sid history), migration des machines par shots géographique par exemple. Une fois tout l'ancien parc migré dans nouveau domaine (idéalement nouvelle matrice), tu migres tes ressources.

Btw, comment ça se fait qu'un stagiaire doit piloter ce genre de projet? Ce n'est pas une attaque personnelle qui mets en doute tes compétences mais plutôt envers la boite qui t'encadre dans ton stage. Dans tous les cas, c'est très bien pour ton CV :)
 
1er
OP
YoupiDollarZ

YoupiDollarZ

Je suis un ananas
Btw, comment ça se fait qu'un stagiaire doit piloter ce genre de projet? Ce n'est pas une attaque personnelle qui mets en doute tes compétences mais plutôt envers la boite qui t'encadre dans ton stage. Dans tous les cas, c'est très bien pour ton CV :)
J'suis en master :cool: et j'ai déjà fait mon stage de bachelier chez eux ;)
Ils me connaissent et la confiance règne :)
 
Ma chance c'est que tout le parc à migrer est en seven. Pas de vieux xp cra-dégueux :)
En fait l'avantage de repartir a zéro, au delà des problèmes potentiels liés à la migration, est de t’assurer que les postes que tu récupères rentre dans le caneva de ta policy IT d'un point de vue :
  • Sécurité : patches, antivirus, permissions
  • Support : remote assistance, ...
  • Applicative : tu risques d'emmener des application non supporté / tolérée.
  • Licenses
  • Inventaire/asset
  • .....
C'est un peux comme si je venais avec mon PC perso dans ton entreprise et que je demandais de le joindre au domaine, ça ferai chier l'admin système car il n'a pas le contrôle dessus.

Après encore une fois c'est vous qui voyez mais quand le boulot est bien fait imager un PC c'est trivial et rapide.

Certaines sociétés font ça par défaut quand tu as un problème, ils ne cherche même -> ré image direct.
 
Haut