1477 connectés

FORUM HardWare.fr

Systèmes & Réseaux Pro

Management du SI

Rafraichissement Mémoire : Migration AD 2003 ou 8 vers 2012

Recherche :

Dernière réponse
Sujet : Rafraichissement Mémoire : Migration AD 2003 ou 8 vers 2012
PsYKrO_Fred	Non je ne trouve pas ça con.... et je pense qu'au final... c'est sur ce type d'infrastructure qu'il faut se diriger.... mais bon le chemin est long...

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

PsYKrO_Fred

Non je ne trouve pas ça con.... et je pense qu'au final... c'est sur ce type d'infrastructure qu'il faut se diriger.... mais bon le chemin est long...

Je@nb

Après tu vas peut être trouvé ça con, mais c'est ce genre de scénarios où mettre en place des services en SaaS gagne de l'intérêt. Ton appli est hébergée, tu as juste à fournir une liste de nouveaux utilisateurs pour les provisionner dans l'appli et leur donner accès. Tu peux garder ton bordel non homogène en local

PsYKrO_Fred

et c'est là qu'on rigole... il y a un fossé entre les actionnaires et les responsables (DSI,...)... mais par contre au final, la volonté c'est faire une architecture 3.0 (mais on n'y est pas encore... donc en attendant le but c'est de rationaliser le parc.

Je@nb

Dans ce cas, faut voir si le DSI est bien au courant de cette orientation stratégique de rachats massifs par son management, et voir quelle vision IT la boite veut donner. Ca sort largement du technique de pure "est ce que je dois merger les ad ou pas" pour savoir dans quel mode la boite veut fonctionner : décentralisé, centralisé, fédéré etc. Chaque application peut être managée différemment (chaque boite n'a pas le même niveau de maturité sur chacun des process, il y a souvent des spécificités dans le métier, dans le pays etc.)

PsYKrO_Fred

Oui ma boite est du genre à racheter une boite de 150-200 personnes tout les ans... (du moins ca c'est vérifié depuis maintenant 5 ans)...

Ils viennent de nous racheter et je viens d'apprendre que le mois dernier ils ont rachetés une autre boite....

Nouvelle usine au portugal et je me demande s'ils ne vont pas partie en Chine... (ca m'étonnerait pas....)

Je@nb

Ouais c'est super chiant :/
Mais MS donne une procédure pour redescendre le domaine fonctionnel d'un domaine ahaha :D

nebulios

Par contre ADMT 4 n'est toujours pas disponible pour une migration vers 2012, il faut attendre encore quelqueq semaines/mois.

Je@nb

ça se script une migration admt.

Pour les nouvelles acquisitions, ça dépend bcp de la taille des boites, de leur maturités, de la fréquence des achats (j'ai vu des boites qui en rachètent d'autres chaque semaine, impossible de gérer 10 000 boites donc tu as tout intérêt à les intégrer de manière continue à ton SI sauf exceptions style d'un coup tu rachètes 3000 personnes où ça va être plus complexe)

PsYKrO_Fred

L'inconvénient pour une refonte AD entière c'est qu'il faut repasser sur tout les pcs et utilisateur... tant dis que mutli domaine les gens sont toujours habitués à se connecter aux domaines.... bon aprés on peut faire petit à petit...

Comment vous gérez les nouvelles acquisitions de société ?
- imposez de restructurer leur ad pour l'ajouter à votre domaine.
- juste une relation d'approbation inter foret?

nebulios

La cloison c'est la forêt, éventuellement l'OU avec une délégation, mais pas le domaine. Accessoirement un certain nombre d'applicatifs n'apprécient pas trop un environnement multi-domaine.

PsYKrO_Fred

skoizer a écrit :

PsYKrO_Fred tu es très diplomate

Il faudrait que j'aille en Ukraine alors:)

Trève de plaisanterie...

Merci pour le conseil Je@nb. -->

"Un domaine c'est une frontière de réplication. Ca sert juste à éviter de devoir répliquer des infos ailleurs. Ca cloisonne rien de plus que ce que tu pourrais faire avec une OU. Il vaut bien mieux faire une structure d'OU bien pensée, collant aux besoins de délégation de la boite (et non pas à l'organisation de la boite hein) que faire du multi domaine."

Je vais en prendre note... il me semblait que ça cloisonner... De toute façon, on n'y est pas encore à cette partie :)

skoizer

PsYKrO_Fred tu es très diplomate

Je@nb

PsYKrO_Fred a écrit :

Je ne pensai pas faire un troll..

Merci encore avec ces nombreux schémas mais qui ne sert à rien mise à part étaler sa connaissance.(ne voit aucune offense)
Je suis d'accord avec tout le monde : AD = AD + DNS

Et oui tu as raison mystérieusex : DHCP c'est essentiel pour un réseau d'entreprise mais n'est pas essentiel pour faire fonctionner un AD. (c'est ce qu'on essaye de te dire).
Après ici tout le monde travaille plus ou moins de la couche 1 à la couche 7 mais personne n'est expert dans une de ces couches.

Enfin comme dit nebulos, ca pars dans tous les sens...

+1 ça part dans tous les sens. C'est un vrai dialogue de sourd. AD ok c'est un ensemble de technos qui parlent ensemble (DNS, IP/IPv6, Kerberos, LDAP, CIFS) mais faut pas débattre de chaque composants. Une forêt, un arbre, un domaine dans AD ça a une signification précise, un rôle précis. Et non Internet n'est pas une forêt, ça veut juste rien dire.

PsYKrO_Fred a écrit :

Je le verrai dans l'étape 2. Ce qui me plait dans le multi domaine (domaine enfant je parle) c'est le cloisonnement des sous filliales. Vu qu'il y a déjà un admin sur quasiment tout les sites...

Un domaine c'est une frontière de réplication. Ca sert juste à éviter de devoir répliquer des infos ailleurs. Ca cloisonne rien de plus que ce que tu pourrais faire avec une OU. Il vaut bien mieux faire une structure d'OU bien pensée, collant aux besoins de délégation de la boite (et non pas à l'organisation de la boite hein) que faire du multi domaine.