Migration de domaine AD

Moué

Je pense plutôt au ciment hondrois ... ce sont des économies de bouts de chandelle et puis les murs se lézardent !

Bah le truc c'est que c'est une boite dont on s'est séparé y a 4 ans, qu'on gardait sous tutelle et qu'on reprend. La politique interne a pas changé si ce n'est en bien, ca devrait donc aller.

krizzeur a dit:

Moué

Je pense plutôt au ciment hondrois ... ce sont des économies de bouts de chandelle et puis les murs se lézardent !

Cliquez pour agrandir...

Pas compris

Bref en vm admt fait ca comme un grand. Maintenant en prod ca va etre une autre histoire, je peux le sentir.

YoupiDollarZ a dit:

Bref en vm admt fait ca comme un grand. Maintenant en prod ca va etre une autre histoire, je peux le sentir.

Cliquez pour agrandir...

Bof, ADMT 99% du boulot est fait en amont, sous forme de planning et de configuration. La migration en elle même c'est bullshit si tu as bien préparé.

Le problème principale et de bien tenir compte de tout les aspect utilisateur, je te conseil de faire un teste en condition réelle avec des key users, afin d'être sur de ne passer a coté de rien.

ben15 aka pOiRe a dit:

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

Cliquez pour agrandir...

Il faut voir aussi ce que les utilisateurs pouvaient installer sur leurs machines dans l'ancien AD.

S'il y a un lot limité d'applications (office, applications métier/compta/etc. ...), c'est jouable, mais si les utilisateurs avaient la possibilité d'installer leur propres outils (genre OpenOffice au lieu de MS Office, Photoshop, etc. ...), tomber sur des machines vierges, ça risque de faire grincer des dents.

Surtout dans une boite qui vient de se faire racheter et où les utilisateurs sont déjà sans doute un peu "insecure" (oui, JCVD style, je tomber plus sur l'équivalent fr).

Dans ce cas, c'est de quoi faire pèter le support Level 1 du dépertement IT.

Je dirais qu'un migration, c'est 1 tiers technique, 1 tiers comm' et 1 tiers politique.

Ouais, beaucoup de comm' et de conflits ridicules qui ne touchent pas à l'IT... c'est désolant

Jereck a dit:

Il faut voir aussi ce que les utilisateurs pouvaient installer sur leurs machines dans l'ancien AD.

S'il y a un lot limité d'applications (office, applications métier/compta/etc. ...), c'est jouable, mais si les utilisateurs avaient la possibilité d'installer leur propres outils (genre OpenOffice au lieu de MS Office, Photoshop, etc. ...), tomber sur des machines vierges, ça risque de faire grincer des dents.

Surtout dans une boite qui vient de se faire racheter et où les utilisateurs sont déjà sans doute un peu "insecure" (oui, JCVD style, je tomber plus sur l'équivalent fr).

Dans ce cas, c'est de quoi faire pèter le support Level 1 du dépertement IT.

Je dirais qu'un migration, c'est 1 tiers technique, 1 tiers comm' et 1 tiers politique.

Cliquez pour agrandir...

Je ne te parle pas d'une machine vierge, quand je parle d'image c'est une matrice avec drivers, application de base (office,...).

En plus de cela, toutes les applications métier doivent être "packagé" au préalable pour pouvoir être déployé sur demande vers les machines qui le requiert.

Installer des truc a la mains on fait ça dans une boite de 10 personnes, je ne pense pas que c'est le cas ici.

YoupiDollarZ a dit:

Ouais, beaucoup de comm' et de conflits ridicules qui ne touchent pas à l'IT... c'est désolant

Cliquez pour agrandir...

Les réfractaires aux changements, tu va en rencontrer toute ta carrière.

Quand c'est le end-user isolé, tu peux lui forcer la main ... quand c'est l'(ex-)responsable IT, là, tu va en chier

ben15 aka pOiRe a dit:

Je ne te parle pas d'une machine vierge, quand je parle d'image c'est une matrice avec drivers, application de base (office,...).

En plus de cela, toutes les applications métier doivent être "packagé" au préalable pour pouvoir être déployé sur demande vers les machines qui le requiert.

Cliquez pour agrandir...

Si dans l'ancienne boite, les utilisateurs avaient la main sur une certaine quantité de personalisations (pas grand chose, ne serait-ce que l'image de desktop, les raccourcis sur le bureau, etc. ...), même si tous les outils "métier" sont disponibles, ils auraont la sensation de repartir de zéro.

ben15 aka pOiRe a dit:

Installer des truc a la mains on fait ça dans une boite de 10 personnes, je ne pense pas que c'est le cas ici.

Cliquez pour agrandir...

Tu serais bien surpris

Jereck a dit:

Les réfractaires aux changements, tu va en rencontrer toute ta carrière.

Quand c'est le end-user isolé, tu peux lui forcer la main ... quand c'est l'(ex-)responsable IT, là, tu va en chier

Cliquez pour agrandir...

C'est pour ça que je suis également étonné que ce type de boulot soit donné a un stagiaire. Il te faut un sponsor de la direction en béton pour mener ça a bien, pour imposer la nouvelle politique au users.

Jereck a dit:

Si dans l'ancienne boite, les utilisateurs avaient la main sur une certaine quantité de personalisations (pas grand chose, ne serait-ce que l'image de desktop, les raccourcis sur le bureau, etc. ...), même si tous les outils "métier" sont disponibles, ils auraont la sensation de repartir de zéro.


Tu serais bien surpris

Cliquez pour agrandir...

Dans le fond on est d'accord, mais en réalité, on est obligé de bousculer un peux les utilisateurs pour avancer.

Des gens pas content yen aura toujours, d'autre p-e verront ce nouveau départ d'une manière positive, j'en suis sur.

ben15 aka pOiRe a dit:

Installer des truc a la mains on fait ça dans une boite de 10 personnes, je ne pense pas que c'est le cas ici.

Cliquez pour agrandir...

J'ai pas dit que c'était The boite non plus hein
On fait beaucoup "par héritage du passé" on va dire
Ca c'est un problème auquel je vais devoir me frotter plus tard.

Ici j'ai un petit problème. Ma machine fraichement migrée de domaine se connecte très bien en user@domainesource alors que j'ai coupé l'ancien DC mais quand je me loggue en user@domainecible, il me répond qu'aucun serveur ne peut traiter ma demande d'ouverture de session.

Une idée? Le client, le pc sont bien dans mon dc cible.

Je pense qu'en domaine source il se loggue sans authentification à l'AD et qu'en domaine cible il ne sait pas du tout le contacter.

C'est tout con, mais la config IP de ta machine envoie bien vers le serveur DNS de ton nouveau domaine ?

Jereck a dit:

Les réfractaires aux changements, tu va en rencontrer toute ta carrière.

Quand c'est le end-user isolé, tu peux lui forcer la main ... quand c'est l'(ex-)responsable IT, là, tu va en chier

Cliquez pour agrandir...

La plus grande préoccupation en sortant de réunion c'est que le login de l'user allait changer (pas son login hein mais le user @sociétéprécédente en @ sociétérachat, une histoire d'état)

Jereck a dit:

C'est tout con, mais la config IP de ta machine envoie bien vers le serveur DNS de ton nouveau domaine ?

Cliquez pour agrandir...

Ouep, j'ai fait une gpo pour que les pc interrogent les deux dns. Et son ip est correcte car j'ai qu'un seul dhcp dans mon labo.

Edit: j'ai rien dit, il a une ip en 169.254... J'vais creuser l'histoire
Edit²: couper l'ancien DC qui fait office de dhcp, c'est pas une bonne idée

Ca fonctionne en tout cas

Bon j'ai un petit problème relationnel, l'admin de la boite rachetée va "perdre" ses droits d'admins car on ne peut/veut pas lui donner les accès d'admin du domaine. Est ce qu'un user avec des droits sur son UO pourrait correspondre a ce qu'il faisait avant (ajout suppression d'users, groupes, droits, partages,etc.)
Si c'est possible de faire "comme si" il était admin mais uniquement de son UO, je ferai passer la pillule. Avec une mmc configurée pour son user, ça doit être faisable non? Si vous avez des conseils ou des liens ils sont les bienvenus

J'ai pas tout lu de la discussion, mais ce que je sais c'est que migré 2 AD, ça marche pas bien mieux vaut le faire à l'ancienne, à la main. Ou alors bonne chance avec les groupe après! Pour MDP, j'en ai mis une dizaine en place depuis l'année passée, si tu veut avoir un conseil ou un best case, n'hésite pas!

Salut les jeunes !

Je réup le topic car il y a du changement.
Je vais essayer de la faire claire et concise. L'idée était de migrer leur AD au sein d'une UO de notre domaine et de déléguer le contrôle de cette UO à leur informaticien.

Déjà ca ne leur plait pas pour plusieurs raisons:

• Il ne veulent pas dépendre de nous et devoir se logguer avec user@maisonmère (l'astuce était de faire un suffixe upn pour leur UO).
• Au niveau de leur admin, une délégation semble assez limitée pour qu'il ai les droits "comme avant" genre si il veut intégrer une machine au domaine, il lui faut les droits d'admin du domaine.
• L'informaticien ne dépend pas de notre service et ne peut avoir nos accès admin du domaine car il aurait une vue non plus sur son UO mais sur tout le domaine.
• Autre souci, si jamais on se re-sépare de cette boite (et c'est là que la comm' de folie a fait tout son boulot, c'est que c'est fort probable que ca arrive et je l'ai su aujourd'hui) c'est que ca va être le super boxon pour détacher cette uo de notre AD proprement.

C'est surtout ce dernier point qui influence vers le sous domaine.

Du coup la solution du mono domaine tombe un peu à l'eau et on est obligé de faire un domaine enfant comme ca pour l'IT de l'autre boite, cela ne changera rien pour lui.

Pour moi par contre comment ca va se passer ? Car dans mes cours et sur le internet tout le monde semble promouvoir le mono domaine.
Je peux migrer leur AD dans ce sous domaine ? Quel est le type d'approbation interdomaine à mettre en place?

Bref si vous avez des suggestions à ce sujet, j'écoute volontiers vos conseils et remarques.

Merci d'avance.

Si tu recommences à zéro fait un domaine root (neutre)(et root secondaire sur un autre site) avec deux enfants, chacun est full admin dans son domaine enfant.
Pour le root, coupe le mot de passe en trois, vous deux et un autre responsable de la boîte, de sorte que deux personnes suffisent à avoir le code en entier, personne ne doit connaître le mot de passe root en entier, ou qq part dans un coffre accessible par le/les bigboss.
Le jour ou une modif est nécessaire sur le root/foret deux des trois personnes doivent être présente pour le loguer en admin root.
Firewall entre vous, et mettez en place une politique de sécurité en commun, pour pas qu'un de vous soit la faille du tout...
Au moins là, des domaines enfants peuvent être créer ou supprimer, à l'avenir, sans devoir tout mettre à plat.
Si tu passes en Exchange pense le de la même manière, un root et chaque domaine son/ses Exchange.
Chaque sous domaine doit avoir sa propre connexion internet, ainsi que pour la messagerie, chacun sa sortie et entrée à part, pour éviter que votre opérateur ne bloque pas toutes la foret si qqn merde avec sa messagerie...

Si une nouvelle séparation est fort probable, un split de forêt sera quand même beaucoup de boulot.

Dans ce cas, je resterais sur un simple trust bidirectionnel.

En fait quels sont les besoins fonctionnel ? car merger pour merger je vois pas l’intérêt.

Ben