Bonjour,
 
J'ai pour projet la migration de domaine et de controleur, en effet, je passe d'un windows server 2003 r2 à un 2008 r2, j'en profite pour changer
de nom de domaine, l'actuel n'étant plus raccord avec les différentes fusions de la société.  
Ne disposant que d'une journée off-production, je souhaite utiliser ADMT (active directory migration tool) afin de récupérer les infos suivantes :  
 
 - Utilisateurs et mdp associés
 - Groupes  
 - Ordinateurs (qui changeront de domaine par le dhcp à la nouvelle connexion)
 - GPO's
 
Le serveur actuel a pour rôle DNS, DHCP, fichiers
 
Le serveur 2008 est actuellement installé et controlleur de domaine du nouveau, domaine2.net
 
Est ce qu'une âme charitable et éveillée aurait des conseils pour la préparation du nouveau serveur, de sorte que je puisse, en un minimum de temps, le mettre en production?
 
Merci d'avance

bonjour, combien avez vous de postes. Car si vous partez si un nouveau domaine il faudra sortir tout les postes de l'ancien domaine et les réintégrer dans le nouveau. C'est long et les effet de bord peuvent être important.
 
Aurélien.

Salut Aurélien,  
J'ai actuellement 400 postes, apparement ADMT me permet de migrer les postes de l'ancien AD vers le nouveau en changeant de domaine, il me suffirait alors d'utiliser la propagation par DHCP pour que les postes suivent de manière transparente.

Non ça n'a rien à voir. Il faut migrer les postes vers le nouveau domaine

Oui c'est ce que je voulais dire en fait, ADMT migre les postes de l'ancien vers le nouveau domaine. Ensuite lorsqu'un poste démarre, il attrape le dhcp qui lui envoie un paquet pour changer le domaine de connexion (pour que l'utilisateur n'ai rien à faire)

le dhcp sert à rien

Oui?
 
Explicitation : Je migre les postes du domaine A au domaine B.
L'utilisateur démarre son pc, l'invite de connexion va garder le domaine d'origine, il me faut donc qu'automatiquement, il puisse le modifier.
Je puis donc utiliser le serveur DHCP pour effectuer celà avec une mise à jour dynamique de l'hôte DNS.
 
Ou il y a un moyen plus simple?

l'invité de connexion va prendre la liste des domaines du poste pas plus pas moins, la liste des domaines n'est pas donné par DHCP
 
La mise à jour dynamique dns sert juste à ce que le serveur dns soit mis à jour avec le nouveau nom de la machine, c'est soit le client qui le met à jour, soit le dhcp mais ça n'entre en rien dans le processus de choix des domaine au logon.
 
La seule chose à faire c'est que la machine utilise un serveur dns surlequel ta zone du domaine B soit atteignable (pour la migration et après biensur) (soit en changeant le serveur dns sur le poste, soit en configurant des forwarder, soit en configurant le dhcp pour qu'il pointe vers le nouveau serveur dns)

Dans tous les cas, je te conseille de maqueter ça avant. Une migration AD c'est pas anodin et si tu veux le faire en un jour (je sais pas le nb de user et de poste, de groupe, de serveurs) mais il aura fallu bien le documenter, tester, industrialisé si c'est pas un petit environnement.
 
Monte toi un DC dans chaque domaine, un serveur admt, qq postes de travail et fais les migrer avant

"soit en configurant le dhcp pour qu'il pointe vers le nouveau serveur dns"
C'est ce que je disai oui ^^
 
 
  C'est justement pour mettre en place mon projet que je cherche ce genre d'infos en plus de la documentation déjà glanée.
  J'ai déjà bien évidemment toutes les grandes lignes, me reste juste ce genre de petits détails cons qui pourraient faire grimper la durée de migration (déjà assez courte comme ça).
 Pour info, J'ai 400 postes et autant d'utilisateurs, compris en une 20aine de groupes, ainsi que 40 serveurs.  
 

Il n'y a qu'un contrôleur ? Qu'un domaine/forêt ?
 
Toute la partie infra (sauvegarde, antivirus, wsus, kms...) est déjà compatible avec l'archi de la nouvelle forêt ? Qu'est-ce qui est prévu pour la messagerie/les applicatifs/réseau ?
 
Il y a énormément de choses à contrôler avant une telle bascule quand même.

Actuellement deux contrôleurs, le second étant réplicat. Une fois la migration faite, je l'utiliserai en réplicat du nouveau PDC.
 
Il n'y a qu'un seul domaine et une seule forêt. Les sites distants sont reliés par VPN et fibres optique pour les plus proches. Chaque site distant possède son propre sous réseau avec sa propre étendue dhcp.
 
Le serveur antivirus (Fsecure) sera reparamétré dans la même journée. (Le but étant de le changer de domaine, et changer le domaine cible des hôtes, si les postes ne changent pas de netbios (le domaine étant configuré plus en amont, il n'y a pas d'autres modifs à faire)
 
Le serveur WSUS sera le controleur de domaine himself
 
Je reconfigure cette même journée (qui englobe la nuit par ailleurs) à la main la conf du dns et dhcp (les multiples fusions ayants entrainés un tas d'entrées obsolètes.  
 
J'ai déjà zoné la partie du SAN pour être monté sur le nouveau serveur, en plus de l'ancien pour la partie appli.  
Le reste des applis métiers étant sur des serveurs UNIX joignables par un serveur intranet lui même sur unix (pas de changement de domaine urgentissime du coup)
 
Alors les sauvegardes, c'est un serveur TSM qui est utilisé, avec des sauvegardes sur bande par connexion IP (la moitié étant des serveurs red hat), plus des sauvegardes sur NAS par un VLAN (serveurs sous bladecenter avec deux interfaces LAN).
 
La messagerie sera l'étape numéro 2, je passe d'un serveur OCSM (oracle) sur serveur red hat, à un exchange 2010 sur 2008 server. J'ai chopé un programme fourni par les bons soins de windows pour migrer les boites d'un serveur IMAP à exchange. En attendant, la messagerie sera toujours accessible par l'intranet.
 
L'étape 3 sera la mise en place de deux serveurs Terminal servers sous 2008, histoire de déployer des postes clients léger dans les sites distants (Le VPN étant un peu léger niveau bande passante).

Tu veux dire quoi par "réplicat" ? C'est un DC R/W standard ? Comment sont répartis tes rôles FSMO ?
 
Tu as prévu une solution de secours en cas de gros plantage, surtout au moment du renommage de domaine ?
 
Pour la partie infra il faut vérifier si elle est compatible avec le nouveau serveur en 2008 R2 (et l'Exchange 2010), et envisager en plan de migration pour chacune des solutions. Et WSUS sur un DC c'est une mauvaise idée.
 
Et en plus tu rajoutes un migration Exchange 2010 par-dessus...et la mise en place de serveurs RDS en plus (d'ailleurs ce sera du 2008 R1 ou du 2008 R2) ?
 
Donc en gros tu as quatre projets à part entière :
 
- Migration AD 2003 vers 2008 R2
- Changement de nom de domaine
- Migration Exchange
- Archi RDS 2008
 
Tu peux rajouter un cinquième projet, la migration de l'infra (j'entends par là WSUS/sauvegarde/antivirus, mais on peut aussi inclure GPO liées/firewalling) pour qu'elle soit compatible avec tout ça...
 
Tout ça en même temps et en un jour, tu oublies    Si tu veux faire tout çà proprement et sans casse il vaut mieux partir sur un mois de boulot (ce qui ne signifie pas un mois de coupure de prod).
 

Exact, un controleur standard utilisé en réplication ad. Les rôles FSMO ne sont pas répartis, seulement sur le PDC.
 
Tous les serveurs sont des 2008 R2 x64, un seul sera en 2008 R2 x86 (pour une appli compta déjà opérationnelle : c'était en fait la phase 0 ^^)
 
J'ai donc effectivement 4 projets à part entière, je compte faire les 2 1ers en une journée et une nuit, le reste ultérieurement (le reste pouvait se faire pendant la prod).  
 
La migration de tout ce qui est nécessaire sur l'infra se fera aussi pendant la prod, et n'est pas vraiment génant à l'heure actuelle. Je t'avouerai que c'est surtout les 2 1ers points qui sont transpirogènes actuellement !
 
Edit : WSUS sur DC est effectivement une mauvaise idée, je la placerai sur un autre serveur

Je ne sais pas si cela peut t'aider ou si tu l'as déjà eu mais j'ai déniché un tuto de migration de domaine vers un 2008. Je ne sais pas si ça correspond à ton cas exactement mais pourquoi pas ? http://www.kerviguen.fr/Tutoriel-M [...] 289a11bd74
 
(drap )

Il n'y a pas de 2008 R2 en x86, et quand tu dis tous les serveurs ce sont tes 40 serveurs de prod ?
Pas de risque d'incompatibilité (je pense à la partie Kerberos notamment) entre tes serveurs Unix et les futurs contrôleurs ?
Ce qui est flou aussi, c'est que tantôt tu mentionnes un renommage de domaine, tantôt une migration, ce n'est pas la même chose.

 
 
Pour le DHCP on peut propager les sufixes de domaines des  domaines cela aide a la résolution de nom.
Sinon pour la partie ADMT si l'approbation et les résolution de noms fonctionne le DHCP est une question mineure qu'il faut gérer avant ou après mais pas pendant la période de migration des postes.

A lire j'ai l'impression que tu n'es pas au clair entre ADMT, DHCP , DNS , AD...
le DHCP n'a rien a voir avoir la migration des machines.
 
Je ne comprend pas pourquoi tu as pris un .net pour le nouveau domaine, c'est pas recommandé pour un réseau interne mets plutôt un .local.
 
Pour la préparation il te faut déja voir
- les niveaux fonctionnelles des domaines sources et destinations, pas plus de  niveaux d'écart pour l'ADMT
- attention si ton contrôleur de domaine fait serveur de fichier tu ne peux le migrer vers le nouveau domaine il faut utiliser une autre méthode robocopy c'est tout simple tout con et ca marche bien pour ce cas.
 
Après il faut que tu vois tout tes serveurs de prod que tu sache bien si t'as des serveurs d'appli si des services tournent avec des comptes de domaines par exemple pour réfléchir au différente contrainte.
A noter que les PDC existent plus depuis longtemps, il reste juste un rôle AD emulateur PDC.
 
Je confirme comme les autres mettre un Wsus sur un dc est une grosse bétise.
 

Non c'est bien ce que tu dis qui n'est pas recommandé.

J'ai pas compris le sens, mais on utilise pas de nom dns interne qui puisse être en conlit avec des nom dns externes soit tu fais un sous domaine d'un domaine que tu possède soit tu mets avec le nom interne le .local et c'est bien une recommandation microsoft

Microsoft recommande une extension externe (dont tu as acheté le domaine bien entendu).
 
Microsoft ne recommande pas l'extension .local qui peut poser problème dans certains cas.
 
Splu clair je pense  

http://technet.microsoft.com/fr-fr [...] 6(v=ws.10)
 
Recherche sur la page espace de nom dns interne
Lors du choix de la méthode d'intégration des espaces de noms, déterminez lequel des scénarios suivants ressemble le plus à votre situation et à l'utilisation proposée pour DNS :
 
Un espace de noms DNS interne, utilisé uniquement sur votre réseau.
Un espace de noms DNS interne avec une référence et un accès à un espace de noms externe, tel qu'une référence ou un transfert à un serveur DNS sur Internet.
Un espace de noms DNS utilisé uniquement sur un réseau public tel qu'Internet.
 
Je ne vois pas sur quoi tu t'appuies pour dire cela, Microsoft dit qu'il ne faut pas de chevauchement. Donc soit tu utilise un nom interne tel que .local soit tu achète un nom de domaine et tu crée un sous domaine pour ton ad afin de ne pas utiliser le même nom en interne qu'en externe.
Je ne vois pas dans quel cas cela peut créer des problèmes, normalement tu n'expose pas ton domaine directement en externe donc tu n'as pas besoin de nom internet. Mais surtout tu ne mets pas de nom internet dont tu n'es pas propriétaire.

Regarde là : http://blogs.technet.com/b/askds/a [...] aspx#local
et là : http://markparris.co.uk/2011/03/08 [...] ffice-365/

 
Je reste que pour moi l'élément important et que le nom de domaine reste unique et domaine2.net ne l'est pas. Et il ne faut pas utiliser de nom simple mondomaine par exemple, il faut mettre un sufixe.
 
Pour le bug avec mac qui utilisait aussi le .local je n'ai pas été confronté.  
 
Après le mieux si tu achète mondomaine.net et que tu fais un AD monad.mondomaine.net mais pas domaine2.net .  
J'admets que dans ce cas tu es sur de l'unicité du nom
 
 
 
 
 

 
Je n'ai pas pu finir mon post ce matin, reste que dans ce cas tu ne peux céder ton nom principal, ce qui a été le cas pour ma boite par exemple, qui a été séparé en 2 et la boite principale à revendu la 2 ème qui était propriétaire du nom.
Je suis conscient des problèmes en cas de fusion des société entre autre lié à l'utilisation de .local. Par contre en cas de cission il te faut garantir que tu conserve ton nom externe.
Mais pour une petite société ces cas ne sont pas fréquent et insurmontable.
Je donc dans l'ordre il est préférable de mettre  
monad.mondomaine.net  
sinon il vaut mieux mettre monad.mondomaine.local que monad.domaine.net si tu ne possède pas de domaine domaine.net
si tu possède domaine.net ne t'en sépare pas.

+1
 
Et pour changer des postes d'un domaine en un autre si toutefois le mot de passe admin local est le même partout.
 Utilise la commande NETDOM qui te permettra de faire "DEJOINDRE" et JOINDRE des ordinateurs dans un domaine.

Je trouve que même 1 mois de boulot c'est juste...    avec les effets de bords, paufiné les détails, etc...

 
1 jour c'est un peu cour pour la migration effective,
Mais c'est sur que la prépa des domaines l'ADMT etc .. cela te prends déja du temps.
1 mois de travail au total avec 2 à 3 jours de migration effectives c'est faisable en fonction des applis, et si tu maitrise ADMT.
 
Si tu maitrise pas et que tu n'as pas de temps la presta externe par un habitué de l'ADMT est la moins risqué.

L'ADMT ser jsutement a déplacer tes postes en remettant à jour toute les acl et autres éléments. Il marche pas trop mal si bien maitrisé.  
Pas besoin de netdom.

@Demes83 : Merci je vais zieuter ça, et merci pour vos réponses
 
Alors, les serveurs logiciels utilisés en prod sont sur unix avec interface web accessible depuis l'intranet (lui aussi sur unix), il me suffira de leur créer une entrée dans la zone de recherche direct du serveur DNS pour que les utilisateurs n'y voient que du feu.
 
  Pour être plus clair, il s'agit à la fois d'une migration, et d'un renommage de nom de domaine. Je change de serveur, et j'en profite pour changer de nom de domaine. Esperant être plus clair
 
 Je n'ai jamais dit que DHCP avait à voir avec la migration ^^. J'ai dit que j'utiliserai la fonctionnalité de propagation de suffixe DNS du nouveau serveur DHCP (que je configurerai à la main).
 
J'ai déjà mis le niveau fonctionnel de la forêt en 2003.
Alors comme (mal) dit plus haut, j'utilise un SAN pour le stockage, il me suffit donc de "zoner" la LUN créée vers le nouveau serveur en plus de l'ancien (chose déjà faite).

Bon courage

Merci bien
Je viens de faire les 1ers tests avec un groupe local bidon et un utilisateur bidon, tout se passe nickel, idem pour l'accès aux ressources.

Note cela pourrait être interressant quelques jours avant la migration de diminuer la durée du bail.
 
Donc tu ne renomme pas ton domaine mais tu migre vers un domaine d'un autre nom.
 
Essaie de mettre le même niveau de domaine pendant la migration. Si tu veux augmenter le niveau du domaine destination fait le post migration.
 
Tes Linux utilise une authentification AD et ou des requetes LDAP ? Pose toi la question pour tous les équipements, copieur multifonction par exemple, service Windows qui tournerai avec un compte de domaine etc ...
 
Si tu peux prendre de la presta tu peux très bien te faire assisté pour la mise en place de l'µADMT et géré le déplcement toi même.

Je t'avouerai que mon amour immodéré pour le stress et les déodorants me pousse à faire tout par moi même
 
Oui j'augmenterai le niveau de domaine plus tard, il me restera encore quelques serveurs 2003 en place en attendant une prochaine MAJ du parc (l'année prochaine).
 
Mes linux n'utilisent pas d'authentification AD, ni partages NFS et la seule requête LDAP est utilisée pour le trombinoscope de la boite, dont ils vont devoir se passer quelques temps (reste à savoir si son existence était réellement connue...)
 
La question est par contre posée de manière concrète pour les imprimantes, en effet, une partie des tirages est géré en auto par des serveurs linux, et je n'ai pas retrouvé le "Service d'impression pour UNIX", est il géré nativement par 2008?
 
 
 

http://technet.microsoft.com/fr-fr [...] 31857.aspx
voir service lpd, mais je ne suis pas expert la dessus

Ah merci, ça a effectivement l'air d'être ça, je ferai quelques test pour confirmer ça !

Ca sert à rien de noyer le poisson et de me faire dire ce que je n'ai pas dis    
 
Ce qui est recommandé, c'est mondomaine.tld ou sousdomaine.mondomaine.tld (en ayant acheté les domaines), pas mondomaine.local comme tu l'as écrit plus haut. Le cas Apple est très spécifique, le cas de migration vers Office 365 l'est beaucoup moins, surtout pour les petites boîtes.
 
Maintenant dans la vie dans l'immense majorité des cas societe.local, societe.lan fonctionnent sans problèmes.
 
Pour ce qui est de privilégier monad.mondomaine.net à mondomaine.net, pour avoir travailler avec les deux ils ont chacun avantages et inconvénients mais je manque d'infos pour me faire une idée plus précise du meilleur choix.  

Pour l'histoire d'Office 365 tu veux parler d'ajout du suffixe UPN ? C'est rien, suffit de le changer sur l'utilisateur

Je n'ai pas compris pour noyer le poisson.  
Pour moi il n'y a pas de problème avec le .local  si ce n'est que tu n'as pas de garanti qu'il soit unique. Mais Microsoft ne peut garantir qu'un .local est unique donc a chacun de voir.
 
Pour moi mondomaine.local et mieux que mondomaine.fr surtout si tu ne veux pas prendre de domaine. Ce qui était le post de départ prendre domaine2.net comme il est précisé dans le premier post quand tu n'as pas le domaine c'est pas le meilleur choix.
 
 
 
 
Si tu prends certain libre par exemple ENI : Windows 2008 Services de domaine ils parlent encore du .local (peut-être qu'il ferait de le faire disparaître , mais autre débat)
 
Enfin note que sur SBS2008 Microsoft te demande avec l'assistant un nom de domaine qu'il sufixe systématiquement en .local.

"Prendre domaine2.net comme il est précisé dans le premier post quand tu n'as pas le domaine c'est pas le meilleur choix. "
 
Nous nous comprenons bien, mais le domaine est déjà acquis depuis plusieurs années (fusion à froid )
 
  Si une âme érrante aurai déjà eu affaire avec ADMT, j'aurais bien besoin de son expérience pour la migration des hôtes :
 
La migration des groupes locaux et utilisateurs se sont bien passés, j'ai déjà quelques utilisateurs sur le nouveau domaine et les tests sont plus que concluants.
Ca coince par contre sur la migration des postes, le poste selectionné se place bien dans le nouveau domaine, mais l'agent admt refuse apparement de s'installer sur l'hôte pour le changement... Il peut s'agir d'un problème de droits mais aucune option ne me permets de d'utiliser un profil admin de l'ancien domaine...
Quelqu'un aurait une idée? Merci d'avance