Bonjour,
 
Quelle méthode vous privilégieriez pour migrer des AD vers 2003 ou 2008 vers 2012 ?
 
Cas 1:  
J'achete un serveur AD.
J'installe un 3 AD dans la foret. (nouvelle ip, nouveau nom de serveur)
Je DC Promo le DC1.
Je formate et j'installe 2012 puis jointure.
Je dcpromo le dc2.
 
Cas 2:
Je dcpromo le DC2 par exe,  
Je formate puis windows 2012
Je redonne la meme ip et le meme nom
et je fais pareil pour le dc1
 
Cas 3:
Je dcpromo le DC2 par exe,  
Je formate puis windows 2012
Je change le nom et l'adresse ip
et je fais pareil pour le dc1
 
Autre cas???

Je ne comprends pas grand chose à ton vocabulaire...une jointure ? dcpromodre ?
 
Et cela dépend des cas, mais généralement installer un serveur neuf avec son propre nom et ip, puis le promouvoir est plutôt une bonne façon de faire. Tout dépend du contexte de la migration.

Oui j'aurais du poser ma question différemment :
jointure = ajouter un contrôleur de domaine dans un domain existant
 
Dans le cas où ils ne veulent pas achter de serveur, le cas 2 ou le cas 3 ?
 

Commencer par vérifier si le matériel sera compatible et correctement dimensionné, puis cas 3 sauf exception.

 
 
Le matériel dans l'ensemble est correcte.
Le cas 3 il m’embête juste pour les machines qui ont les dns en "dure".
Ensuite j'ai fait quasiment l'analyse de tout et j'ai quelques soucis avec le niveau fonctionnel de certains domaines qui sont toujours en 2000.
 
 

Juste pour poser les choses : dans mon entreprise nous avons 2 serveurs AD, ils sont tous 2 serveurs DNS (comprendre : déclarés sur les PC et autres équipements du parc).
Cette infrastructure est par nature redondante : si l'un des deux serveurs AD est indisponible, la résolution DNS s'effectue sur l'autre et les clients se connectent aux serveurs qui sont disponibles.
Dans cette configuration, pour migrer un serveur, on retire le rôle de contrôleur de domaine à l'un des serveurs puis on le retire du domaine. On positionne le nouveau serveur avec l'adresse IP du serveur qui à été enlevé, on l'ajoute au domaine et on installe le rôle de serveur AD (pour le domaine concerné). On n'a donc jamais d'interruption de service.
Si on souhaite augmenter le niveau fonctionnel, il faut d'abord que les 2 serveurs AD soient avec des OS qui sont supportés puis on fait un upgrade.
ATTENTION : il faut penser à déplacer les rôles FMSO lorsqu'on retire un contrôleur de domaine !

et la configuration ntp du pdc

 
Merci j'ai pas de pb pour migrer etc, et de plus la technet est trés bien faites ... (c'est plus sur la méthodologie best practice si tu n'avais pas de sous et que tu devais migrer )  
Mais lorsque tu réinstalles, tu remets la même ip ?

En principe, un DC pour le migrer tu le deprom du domaine pour le faire redevenir une machine lambda en IP fixe avec son NDD propre, tu fait la migration, tu le repromote, tu le test en prod, tu le passe PDC avec l'autre qu'a pas encore été migré en secondaire et tu test la charge
Donc oui, tu garde la même IP, si le niveau fonctionnel est pas le même, tu pourra avoir des bugs de connec, a savoir que si t'as des machines sur le DC non mis a jour, elles pourraient avec des comportements différents, donc c'est pas trop conseillé de mixer mais j'ai rarement vue de soucis a ce niveau là (dans le sens que si tu fait ta migration en principe tu doit forcer la reconnexion des machines sur le PDC au moment de son promote, donc personne sur le DC pas encore migré sauf en cas de gros pépin)
 
Donc oui, tu laisse la même IP, t'as pas de 3e DC qui entre en jeux.
Pour le coup de retirer la machine totalement du domaine et de la migrer en offline, je suis pas trop d'accord. Mais globalement si tu respecte (et relit avec le doigt) se qu'on dit Jean et Dam', je vois pas où est le problème ?
T'es pas certains que toutes les machines soient bien avec DC1 et que t'en ai avec juste DC2 en hard ? Ben revérifie, c'est ton taff

 
Oui mon taff, ou bien les taffs de mes collègues plutôt... Je ne connais pas toute l'architecture... j'ai un parc > 1000 clients sur différent site et différent pays etc...  
Je suis entrain de faire l'analyse et faire mes recommendations... j'avais juste besoin d'un rafraichissement sur la méthode.... mais bon la pluspart je vais avoir besoin de faire un renouvellement de matériel...  
 
Evidemment je vais monter en niveau fonctionnel les domaines avant la migration... de toute façon je n'ai pas le choix
 
"T'es pas certains que toutes les machines soient bien avec DC1 et que t'en ai avec juste DC2 en hard ?"
Je pensais que  les machines se connectaient sur les DC qui repondaient le plus rapidement.
Tu aurais une commande pour vérifier?
 
et question pour les "anciens" comme moi, vous vous rappelez comment vous avez migré du Windows 2000 ? C'est trop loin dans mes souvenirs

Tu n'es pas obligé de monter un niveau fonctionnel avant (ou après) migration, ça dépend des prérequis MS.

 
si obligé pour le 2012 tu ne peux pas sinon poursuivre l'installation. Le 2003 il aime pas ça

L'autre solution que j'ai vu de temps en temps c'est :
 
DC1 a IP1
DC2 a IP2
Les machines ont en dur (enfin les serveurs, switchs, printers and co) IP1 et 2 en dur en serveur DNS.
 
Tu veux maj DC1 :
Tu transfères les FSMO sur DC2, reconfigure le NTP si DC1 était le PDC sur le DC2
Tu unpromo DC1 (mais laisse le DNS en attendant en zone secondaire)
Tu changes l'ip de DC1 en IP3
Tu rajoutes IP1 sur DC2 (pour les cas des équipements à la con qui ont en fait que DC1 en serveur DNS ...)
Tu enlèves DNS de DC1
Tu formattes DC1
Tu installes DC1
Tu ajoutes le DNS et réplique les zones
Tu vires IP1 de DC2
Tu ajoutes IP1 sur DC1
Tu installes AD
Tu rebascules les FSMO and co si besoin
Tu check les logs

Pas mal ça.
J'y avais pas pensé...  
 

 
J'ai migrée vers bind, samba, nfs et dhcpd :x
Pour la vérification, tu liste les machines actives de ton AD, tu doit avoir un champ qui t'indique quel DC elles utilisent, sinon, la technique barbare que les user aiment pas, c'est de forcer la déconnexion des machines au moment de virer le DC, tu vire le DC et si la machine arrive pas a se reco, c'est qu'elle a été enregistrée en hard sur le DC viré, le technicien doit être capable de la remettre en 30 secondes chrono avec les paramètres qui vont bien.

 
1/ Ca n'existe pas
2/ ça ne veut rien dire

Oui c'est ce que je me suis dit...  
 

Un DC a différent rôle : DNS, DHCP, gestion des droits et partage, ben a partir de là si tu rentre les infos DNS d'un DC particulier alors que t'en a deux, ta machine tu pourra pas la logger sur le domaine <_<
 
Avec sysinternals PsLoggedOn, et NET SESSION | FIND /C "\\", tu fait les croisements d'info ? <_<
Et NET VIEW peu te sortir tout les champs que tu veux, faut juste savoir l'utiliser. <_<
 
Sans oublier Netdom Query http://technet.microsoft.com/en-us [...] 35089.aspx

WTF ?  

 
 
Ca sent le bricolage... merci pour la réponse... mais je pense que je vais resté dans le "classique" et la best practice.
Sans t'offenser, je ne comprends pas pourquoi tu me montres ces outils... je n'ai pas un problème de technique mais de méthodologie.
 

 
T'es tellement abstrait dans AD que tu sais même plus a quoi correspondent les procédures de logon dans un client informatique lambda ?
DHCP/DNS déjà c'est les services de base avant de parler d'AD, DC, etc ...
Donc pour la refaire au ralentit, ta machine, elle va pas se logger par rapport a une IP, généralement elle doit déjà savoir résoudre des noms, et donc le DC va avoir le compte machine pour ça et pusher les informations DNS via DHCP (ou n'importe quel autre protocole pour le faire mais sous windows je connais pas grand chose d'autre, hormis justement rentrer les informations "en dur" ) avant que l'utilisateur puisse ne serait-ce qu'avoir l'invite de login. Si tu rentre un DNS, que ce DNS n'existe plus sur le réseau, ben pas d'accès au domaine : la machine ne pourrai pas aller chercher se qui lui faut dans une majorité de cas, vue que les administrateurs ne savent pas faire de fallback ou installer des GP et faire des déploiements en masse pour vérifier
Faire rentrer une machine sur un domaine ne veux pas dire qu'elle va systématiquement récupérer les policy a jour en permanence, faut un script pour faire cette vérif, donc certaines configurations, non check, peuvent passer outre et ne plus pouvoir se logger sur le domaine (le DNS n'est qu'un exemple, c'est extensible a tout les éléments qu'un AD peut fournir)
Si tu veux un AD il te faut : un serveur DNS, un serveur DHCP, un serveur LDAP, des partages sous samba* ou nfs*, le tout sous identification kerberos, retire l'accès a tes clients au LDAP, au DHCP, ou au DNS et pouf le client est bloqué.

 
Il est temps que tu arrêtes la drogue hein. Pas besoin de DHCP pour un AD, pas besoin de samba ou de nfs non plus, ensuite oui l'IP a de l'importance dans la séquence de login puisqu'elle permet de déterminer le site et donc le contrôleur de domaine cible. Pour le reste je n'arrive pas à le traduire en français cohérent
Tu racontes juste n'importe quoi là

Je n'osais pas l'écrire.

Hello si tu migre de 2003 a 2008R2 et que tu as  plusieurs site.
Si tu as des sites avec aucune salle info mais que tu veux mettre un DC pour accélérer l'auth.
Regarde les DC role Read-Only Domain Controler (RODC)
ça te permet d'envoyer l'auth de certain groupe sur un DC.
Si on te pique le PC seul ces user doivent être changé.
Tous les comptes admin ne sont pas stockésur un RODC
module 10 de la formation 6425c "improve the security of authentification in an AD DS domain"
 
Regarde pour la réplication
Change la synchro du SYSVOL, utilise le DFS-R qui est plus stable que celui mis de base
Voir doc microsoft formation 6425C L12-17
tu devrais trouver
 
j'espére que ma petite contribution t'aidera.

Merci oui ca fait des rappels... mais de toute façon cette partie.. je vais faire faire par mes collègues de chaque site.  
 
C'est juste un rappel au cas où ils aient besoin de soutient.
En fait le projet global est refonte entière de l'architecture AD.
Et la premiere etape est de mettre tous au meme niveau Windows. L'autre étape c'est, je pense, mono foret multi domaine.
 
merci pour le "course" AD, j'ai le droit d'y accéder sur le e-learning.

Mono forêt mono domaine si tu peux, des domaines multiples c'est vraiment galère à gérer.

 
   
 
C'pas un peu le boulot de l'admin sys justement ça ? Avec des compétences qui sont normalement niveau technicien ?    
 
En fait du coup, m'étonne pas vos remarques.  

PsYKrO_Fred j'y suis passé par cette formation il y a 3mois.
on oubli vite si on ne pratique pas.

On n'a pas tous un admin sys.
Une architecture AD on n'y bosse pas tout les 6 mois, mais plutot une fois tous les 10ans.
Sauf bien sur, pour des énormes structure ou des SSII qui font des migrations régulièrement.
MysterieuseX <-- tu es assez hautain

Mais tu sais pas du tout de quoi tu parles en fait
Réorganiser un AD, c'est pas un projet qui démarre avec un post-it et se fait le samedi midi entre deux pastis.

A la tienne !

 
Je me suis prise une attaque ad hominem, tu voudrais que j'y répondent comment ? Si tu touche a un AD, c'est qu'en principe tu as les compétences pour comprendre qu'AD est basé sur DNS, DHCP et la résolution des noms netbios, ne pas comprendre comment migrer un DNS, c'est ne pas comprendre comment migrer AD. Alors qu'on soit sur du microsoft ou de l'AS/400, tu perd ta résolution des noms, tu peu pas associer nom<=>IP automatiquement pour un client (soit les interactions DNS/DHCP) tu peu oublier migrer ton AD et go reprendre des cours d'administration de base.
Quand bien même tu fait du statique, si tu as une réservation d'adresse : c'est du DHCP. Si t'oublie de refaire l'attribution et la réservation, ben t'aura un conflit. Bref, on va pas épiloguer, y'a encore de la perte de qualité niveau administration, c'pas nouveau

 
Il me faut 1 script et 24 heures de tests de régression pour migrer un serveur AD.

Sauf qu'on ne parle par d'un DC là, on parle d'une forêt entière, avec possible fusion de domaines

pas besoin de DHCP ...

 
C'est de l'abstraction, une "forêt" ça veux dire que dale en réseau, c'est juste un terme utilisé pour définir une hierarchie.
La base reste le domaine. Que t'ai XXX sous domaines gérés par YYY serveurs sans relations d'approbations : ton domaine = ta forêt quoi que t'en dise même si ton périmètre d'action se limite aux serveurs sur lesquels t'as les droits SUID=0.
Revenir a la base : c'est se que tu va faire. Que ton domaine soit splitté ou géré sur un point unique, distant, avec des couches et surcouches d'abstraction, on s'en fou, tu verra si tu réfléchis comme ça, tu te fera beaucoup moins de cheveux blancs et tu sera beaucoup plus efficient.
 
Se qui compte dans l'histoire c'est :
-Ton rôle de DNS : un serveur une fois mis en tant que DNS tu ne le bouge plus. Hierarchise tes DNS pour qu'ils gèrent 1 ou X branches, ou sous domaines du domaine principal, et t'aura l'équivalent de ta forêt et tes arbres.
-Attribution des IP, et résolution des noms, qu'elle se fasse sur un périmètre local, ou global (ben oui, internet c'est une forêt <_< ) c'est la même chose (les mêmes systèmes de redondance avec attribution netbios/BGP, maintien des routes en dur dans les routeurs etc ...)
 
Les relations parents/enfants/arbres/forêt etc ... A la limite on s'en fou un peu, ça peu être réglé pendant les tests de régression. "AD" c'est une couche logicielle 6/7 dans une organisation OSI avec exception de la pièce principale (DNS) qui a des relations en couche 5... C'est X.500 quoi, c'est pas non plus un truc énorme o_O
 

 
Je travaille habituellement en couche 3 a 5 moi, vous vous parlez d'un truc qui se met en place en couche 5 a 7 (vous commencez avec votre cadre DAP/LDAP)
 
Pour aller plus loin :  
 

 
La, on a deux systèmes distincts, vous vus êtes même pas dans ce cadre, votre cadre serait une division de la couche "session" a "application", j'appelle pas ça des réseaux distincts.
 
Faut arrêter de se prendre au sérieux 2 minutes quoi, AD ça reste qu'un gros DNS distribué entre plusieurs zones

Bonne chance avec un réseau de 10000 postes et des réservations que tu peu même pas avoir idée, et bonne chance pour avoir une résolution des noms automatisée sans DHCP :>

C'est quoi le rapport avec le réseau ? o_O
C'est un terme bien spécifique, qui désigne un concept précis (et pas seulement une hiérarchie) dans un environnement Active Directory. Ton histoire de modèle OSI à coucher dehors, on s'en fout ça n'a aucun rapport avec le premier post.
Renseignes-toi un minimum sur ce qu'est et ce que fait Active Directory, tu pars dans tous les sens là  

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...
 
 

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...
 
 

C'est bon ça. Tu peux me faire une quotation d'une prestation vu que tu as l'air d'être expert(e) ?
 

 
+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.
 

 
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.