Salut tout le monde,
 
 
 
Je change actuellement mon ancien AD physique pour le passer en virtuel. Je repasse donc par une réinstallation complète et non un Converter.
Par contre j'ai besoin de reprendre l'IP de mon ancien physique, est-ce que cela pose problème ? (en gardant le physique étaient bien sur).
 
 
Très bonne journée à vous tous,

"étaient" = "éteint" ?
 
J'ai du mal à saisir.
Tu vas recréer un domaine de zéro ou effectuer une migration des rôles du DC actuel (physique) vers le nouveau (virtualisé) ?

A noter que lorsqu'on refait un domaine avec le même nom de domaine, de contrôleur de domaine, il faut tout de même réintégrer les postes dans le nouveau domaine et remettre en place les comptes et les profils utilisateurs.
La méthode habituelle est de migrer son AD vers des contrôleurs de domaine plus récent avant de rétrograder les anciens. Cela évite de tout refaire.
La méthode du "cochon" c'est de faire un PtoV du DC.
 
Voir :
http://pbarth.fr/node/89
 

+10000

Tu monte ta VM, la met dans la foret AD, lui donne le role dns et ensuite tu la promouvois master du domaine

Quand a reprendre l'ip de l'ancien physique pourquoi as tu besoin de cela?

 
 
Il n'y a strictement rien de "cochon" à réaliser un P2V d'un DC.

Oula j'ai pas vu la grosse faute et je n'ai pas était clair du tout.
 
En gros j'ai un seul domaine qui ne bouge pas, j'ai juste rajouter deux DC qui sont déjà intégrés au domaine.
 
J aimerai donc eteindre l'ancien, et utiliser son ip pour attribuer à un des nouveaux. Est-ce que cela pose problème ? (Uniquement l'IP pas le nom).
 

Mais tu as bien migré tous les rôles sur les nouveaux DCs ?
 
En plus d'AD : DNS, rôles FSMO, DHCP, etc.
 
L'ancien ne contient plus d'autres rôles qu'AD ?
Si oui, tu le rétrogrades puis tu le retires du domaine si tu veux. Là tu changes son IP.
Tu vérifies dans la zone DNS de ton AD qu'il n'y a plus trace de son IP et oui alors tu peux attribuer son IP à un autre.
CF https://technet.microsoft.com/fr-fr [...] s.10).aspx

Oui j'ai encore 17 autres DCs de disponible, il a juste du DHCP, DNS, NAP etc.... mais que j'ai migré déjà sur mes nouveaux DCs.
 
C'était surtout pour savoir si ça pose ou non problème de réattribuer à un nouveau DC une ip qui a déjà était attribué. Même si je me doutais qu'il y avait pas de raison, mais c'était plus pour savoir s'il y avait des subtilités avant de le faire

C'est clairement déconseillé, trop de risques pour zéro intérêt.

Tu fais un dcpromo inverse propre, tu sors la machine du domaine, tu vérifies que la réplication a fait son boulot et à partir de là aucun souci pour réutiliser l'IP.

"C'est clairement déconseillé, trop de risques pour zéro intérêt."
 
 
Le truc chiant c'est de reprendre dans mon cas :
 
- DHCP (bon ça va encore)
- NaP (pareil)
- Serveur d'impression (plus galère car installer dans toute la boite)
 
 
J'ai hésité justement à cause surtout du serveur d'impression à Convertir la machine existante. Même si les 2008 R2 les gères bien ce type de conversion, si je peux faire autrement ça m'arrange
 
 
 

   
Bien s'assurer que la réplication a fait le boulot, que les entrées DNS ont dégagées etc.

 
Quels risques ?
 
Zéro intérêt ?
Bien si, virtualiser un DC sur un serveur physique dont on veut se débarrasser (trop vieux, risque de panne, prend de la place, etc.).
Le DC une fois en VM fait partie de l'infra de virtualisation, plus récente, avec tolérance de panne, monitoring via l'hyperviseur, sauvegarde niveau VM, etc.

Le risque d'avoir son AD en vrac et/ou une machine inutilisable.
Si tu veux avoir une VM DC bah tu l'installes la promote et zou c'est fait. Pas besoin de faire de P2V. S'il y a bien un rôle qui se déplace bien c'est lui.

Tu parles d'un AD en vrac simplement après P2V ?
ou si restauration d'un snapshot/sauvegarde sur une VM avec AD ?

Il est sûr que si la VM ne contient qu'AD, autant réinstaller de zéro sur une VM et répliquer AD.

Mais là je me place dans le cas où le serveur physique ne contient pas qu'AD mais d'autres rôles/applis.
Alors certes c'est pas bien. Certes il faudra certainement repartir sur des OS propres avec les rôles scindés, mais dans un 1er temps, je ne vois pas de problème à faire le P2V d'un serveur avec AD.
Et cela permet de s'affranchir du serveur physique rapidement s'il pose problème.
Bien sûr il faut respecter certains principes : pas le faire tourner en même temps que le physique qu'on aurait oublié d'éteindre, pas de restauration (snaspshot, sauvegarde) n'importe comment pour éviter les USN rollback.

Du moment où tu allumes ta VM et la relie au réseau, tu peux considérer que ton serveur physique est mort (ou s'il doit être allumé c'est hors réseau)
Du moment tu allumes ton physique et le relie au réseau, tu peux considérer que ton image disque que tu as créé est obsolète et ne doit pas du tout être utilisée en vm.
 
Donc déjà c'est P2V offline hors réseau obligatoire.
Après souvent le P2V c'est pas clean, tu as des résidus de drivers, de filter drivers, de config de carte réseau et j'ai vu beaucoup de problèmes suites à des cartes fantômes qui ont pas été supprimées. Donc idéalement avant de faire ton P2V tu nettoies le serveur physique pour avoir un truc assez agnostique. Sauf que du coup tu perds l'intérêt du P2V d'avoir un snapshot de ton serveur.
 
Je priviligerai plutôt un déplacement rôle par rôle (qui est de toute façon la cible) qu'un P2V. De toute façon tu vas devoir le faire, donc autant le faire directement.
 
Tu peux toujours migrer l'AD et laisser les autres rôles sur le serveur en ayant dépromu le DC en simple serveur. (dans une moindre mesure, certains softs n'aiment pas ça)

On est OK que le P2V d'un AD n'est pas la panacée et implique des précautions sans appel.
 
Après cela reste possible et cela peut dépanner dans certains cas complexes car avec peu de moyen humains/budgétaires.

Peu de moyens humains veut souvent dire que la personne ne maitrise pas les implications du P2V sur un AD et ça va à la catastrophe.

 
Si tu as un seul DC dans une forêt mono-domaine et que tu fais un PtoV a froid en arrêtant les services aux utilisateurs .... Et dans la mesure ou tu as une bonne expérience pour corriger les DNS et nettoyer l'annuaire...  
 
Maintenant si tu migres l'AD avec une méthode classique, tu rétrograde l'ancien en serveur membre ...  Tu peux aussi faire un PtoV de serveur membre.
Après si tu as d'autres appli, il faut voir pour chaque appli si elle supportera le PtoV. Un vieux logiciel non maintenu dont l'activation est lié au Hardware par exemple.
 
 
Le PtoV d'un serveur avec licence OEM pose aussi la question de la licence ...

 
Houla !
 
Dans ton 1er cas, je ne vois pas le besoin de nettoyer/corriger DNS et AD.
 
Dans ton second cas, je ne veux pas voir la tronche des applis après une rétrogradation du serveur en membre du domaine

C'est sur que la simplicité c'est le P2V, après je vais en profiter je pense pour refaire le découpage des rôles qui ont été fait.
 
Car la pour le moindre reboot je perds 4 à 5 rôles sur mon infra ....

 
En général sur le premier cas, avec un DC tout seul il n'y a pas trop de problème, néanmoins j'ai déja eu l'occasion de corriger ...
Avec plusieurs DC, la méthode représente un risque inutile et elle peut être lourde est hasardeuse si on ne maîtrise pas. Risque nettement supérieur à une migration classique à chaud sans interruption de service.  
 
 
Sinon tu parles de quoi comme appli ?  Quel lien avec le fait de rétrograder le DC ?
 
Tu peux essayer de te convaincre que c'est propre , si cela te fait plaisir ...
 
 

 
Je ne vois pas ce que tu veux corriger après avoir P2V un DC.
Tu retrouves l'AD/DNS dans l'état exact où tu l'avais laissé.
 
Sinon niveau appli, je ne parle pas de paint bien sûr, plutôt de ce qu'on trouve parfois sur un DC de TPE/PME, c'est à dire Exchange, du SQL Server, un ERP, que sais-je.
Le serveur rétrogradé, les droits, comptes et stratégies locales ne sont plus les mêmes. Ca risque de franchement mal se passer pour ce type d'applis.

 
C'est tellement simple  que Vmware en fait des articles :
https://kb.vmware.com/s/article/1006996  
 
 
 
Si tu fais un PtoV d'un DC qui a d'autres applications et si une des applications ne fonctionne pas tu ne pourra pas faire de retour en arrière en utilisant ton serveur source. Surtout si ton DC virtualisé à répliqué avec d'autres.
 
Ca n'a jamais été une bonne idée de mettre Exchange sur un DC en dehors de l'environnement packagé (SBS par exemple).
 
Certaines erreurs lors du P2V du DC ne sont pas vu de suite par les administrateurs et peuvent te mettre dans des difficultés bien après la convertion.
 

 
C'est sur elle est super propre ta machine virtualisé avec des traces de l'ancien matériel, des outils de gestion du fabricant de l'ancien matériel etc... Ca se nettoie mais ce n'est surement pas plus propre que de faire un DC avec la méthode classique.

 
T'es sur de toi pour le côté simple ? t'es sur de maîtriser tous les éléments ?  
Avec 17 DCs ?  
 
Sérieux c'est plus complexe et plus long que d'ajouter un DC proprement ...  
 
T'as prévue de faire un PtoV a chaud sans reboot ? Si un reboot c'est déja du stress  pour toi ! bonne chance.
 
En plus qu'elle est l'intérêt si c'est pour tout refaire après en séparant les rôles ?  
 

Phil je crois que tu as oublié de regarder l'ensemble des rôles, s'il y avait que le DC ça serait même ultra simple.
 
Par contre oui ça reste la simplicité quand dessus tu as du :
 
- DHCP (avec un pour mon lan et l'autre TEL)
- NPS (mes switchs et bornes oui l'utilisent pour authentifier les gens)
- Serveur d'impressions (refaire les chemins ou GPO en espérant pas avoir de résidus d'imprimante).
 
Ce sont des rôles toujours un peu galère à migrer, car ça implique pas mal de tâche à faire en plus, et en espérant que ça se passe bien. Et il me sert aussi à mes fortinet pour le VPN users.
 
 
Donc oui ça resterait plus simple pour moi de le faire en P2V, mais comme tu as bien lu Phil (LOL) j'ai dit que je le faisais pas en P2V pour autant.
 
 
"Si un reboot c'est déja du stress  pour toi ! bonne chance."  <<< tu as vu ou  qu'un reboot c'était du stress pour moi ? Phil, pas la peine d'inventer des choses pour essayer de te donner raison. Je crois que sur le P2V des AD chacun a son avis sur le sujet.

 
Quels risques ? Notamment de déclencher un USN rollback si l'opération se passe mal.
 
Active Directory fait partie des très rares applications qui intègre nativement la haute dispo, donc il ne faut pas la gérer comme une appli standard, où un P2V serait justifier.
Tu ajoutes un nouveau DC propre, tu rétrogrades l'ancien, c'est plus facile, plus rapide, le risque minimal, l'interruption de service aussi. Il n'y a aucun argument pour le P2V sans dans quelques cas extrêmes.

Exchange et SQL Server sur un DC ce n'est pas supporté.

"Exchange et SQL Server sur un DC ce n'est pas supporté"
 
Bon moi ce n'est pas mon cas pour le coup, mais il ne faut pas oublier que toutes les sociétés n'ont pas les moyens de respecter les best pratice Microsoft (ou autre).
 
Après oui je suis d'accord, mettre en plus trop de rôle c'est une belle misère pour migrer par la suite .....

C'est pas toujours un problème de moyens.
Tu as beaucoup de personnes qui viennent installer des logiciels et qui se fichent de l'environnement car souvent ils ne s'occupent pas de la partie infra.
Un jour j'ai eu un prestataire qui avait des erreurs dans la désinstallation du SQL d'un SBS pour installer sa version de SQL à la place.
Je lui ai dit que c'est probablement que le SQL était essentiel au fonctionnement du SBS mais cela ne semblait pas le dérangeait de le supprimer.

Best practice != support
 
Là c'est pas de support du tout, on est loiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiin du best practice.
Tu appelles MS la seule réponse qu'ils vont te donner c'est réinstallez dans un environnement supporté, fin de la discussion.

Regarde le post de Je@nB, "Best practices" et "pas supporté car générateur de tonnes de merde" ce n'est pas pareil.

Oui après je sais pas s'ils sont comme ça sur tous les rôles, par exemple mettre du DHCP + Gestion certificat avec le rôle AD est-ce qu'ils peuvent dire non en cas de besoin de support ?
 
Car effectivement il y a des produits comme Exchange, TMG etc... où pour le coup c'est clair. Mais pour les rôles même sur un Windows serveur, est-ce qu'il y a un truc écrit sur ça ?  (mise à part le fait qu'il parait logique de pas forcément trop grouper les rôles).

Tu as toutes ces infos sur Technet.

 
Personne ne dit que c'est propre. Je dis que c'est possible.

 
Oui enfin comme pour toutes opérations, tu peux te prendre des pains.
Et des KB Vmware en a plein plein qui sont à appliquer même si tu as tout bien fait dans les règles.
 
Enfin, comme pour le P2V d'un DC, je n'indique pas que c'est propre d'avoir un Exchange ou autre sur un DC, je dis que ça existe.

 
Oui on le sait tous.

Oui il y a pas que des entreprises au courants des bests Pratice de Microsoft (ne parlons même pas des licences .....)

 
Et ben voilà je me place dans les "cas extrêmes"
Il faut saisir que les boites sont légions où le DC héberge des tas d'autres rôles/applis et qui tourne sur un (pseudo) serveur dont le RAID est en dégradé ou sans RAID avec des backups inexistants.
Dans ces cas là, cela représente un moindre risque de virtualiser de suite le DC.
Car scinder les rôles, créer x serveurs, n'est pas toujours, loin de là, possible. C'est un travail nettement plus important et donc coûteux avec le prérequis de maîtriser les migrations des applis.
 
Moi ce qui m'ennuie c'est de lire que P2V un DC c'est impossible et que plus rien ne va marcher etc.
On laisse entendre que le P2V va aller modifier l'OS ou les applis. Il n'en est rien.
Il présente un nouveau matériel dont l'OS va avoir les pilotes en natif ou via les tools (pour vmware).
Il restera peut-être des applis de gestion de l'ancien serveur. Et alors ? On les supprime.