Reprise du message précédent :

 
Ce qui me gène, c'est que vous donnez l'impression avec ton patron de chercher la méthode la plus rapide et la moins risquée, et vous avez choisi le plus long et le plus hasardeux.Je suis conscient que tu n'es pas maître de la situation.  
 
En deux heures j'aurai sécurisé l'AD avec un autre DC, même avec les utilisateurs qui travaillent.
 En une nuit j'aurai déplacé les fichiers les partages et les liens. Les partages peuvent se refaire rapidement en copiant les fichiers avec (robocopy /mir /sec ) ou du DFS et export du registre pour la partie partage. Après il reste la migration des autres produits.
 
 
Enfin avec un DC il ne faut pas croire que tout va bien, il faut utiliser les outils pour le vérifier (DCdiag, repadmin, ADReplication Status Tools, ... ) :
 
http://pbarth.fr/node/218

+1000000

et il faut aussi penser à l'avenir pour ne pas se retrouver de nouveau dans la même situation dans quelques années, mais ca il faut y réflechir aprés quand tout fonctionnera comme il faut.

Je vais direct balancer un DCdiag Lundi sa me servira de preuve qu'il vaut mieux migré en production (en espérant que sa freeze pas en cour de route). Le problème c'est que même sollicité les partages font planter le serveur par moment.
Mais je vous rejoint clairement.
Un grand merci pour vos liens que j'épluche au fur et à mesure, même si je connais les principes d'une migration un support est toujours bénéfique surtout que je suis pas bien calé avec le 2003 et des migration j'en est fait, euh 2 seulement.
Mais il y a 500 go de data (sa prend 18h pour les déplacer et je redoute le plantage du 2003 à ce moment).

On dirait qu'ici personne n'a connu une situation foireuse.
Personne n'a bossé en SSII ?

Si mais ça s'appelle le devoir de conseil

En SSII non mais dans une entreprise avec un réseau en perdition quand tu arrive et que tout le monde te dis mais non ça fonctionne nickel: oui.

Effectivement, la situation est délicate et les conseilles que je reçois me sauve quand même bien. J'ai listé tout les risques que l'on m'a dit sur ce forum et les aient envoyer par mail à mon patron.
Depuis, il m'a dit que si ça marche pas on remettra tout a plat avec le client et il paiera en conséquence.  
Grâce à vous mon patron à pris conscience des risques et me soutien si ça marche pas (bon il veut quand même tenter rien que pour la montagne économique que ça lui apporte, sauf qui visualise pas que sa peut être bancale et que la boite appel toute les semaines et là y a de gros risques que cette situation arrive).

C'est tellement fréquent comme situation

Plop, bon j'ai réussi a le mettre en domaine principale et mon 2012 a tous les droits. En revenche dcdiag m'a indiqué une erreur sur les syslogon avant la migration. Mais j'ai monter un poste sur le domaine ça se passe bien   .
 
Pour le moment il est DNS secondaire et AD principale sans les partages (pas eu le temps de finir).
 
J'ai fait plein de screen en mode tuto pour me sauver la peau à l'avenir, la commande netdom query fsmo m'a bien sauver la peau car j'avais loupé une étape.
 
Je sent qu'en prod le résultat sera pas le même.    
 
Ah oui aussi pour augmenté le niveau de fonctionnalité d'un 2003 il faut installer un utilitaire à télécharger chez crosoft, bizarrement il était déjà installer, à croire que l'ancien prestataire à tenter sa chance.  

Tu veux dire quoi par là ? Tu as fait ça en labo ?

J'ai fait un VHD de leurs serveur le WE dernier mais je refait la même en prod début décembre, je voulais savoir si c'était fonctionnel comme solution. Dans tout les cas j'ai pas trop le choix.

Mais tu les as mis sur un réseau isolé au moins ?

ton vhd va pas servir à gd chose s'il a qq jours

Oui je vais refaire toute la procédure en relançant un disk2vhd pendant la nuit du vendredi soir pour tout faire le samedi, je suis effectivement en labo isolé.
Le problème c'est que même un disk2vhd peut ne pas réussir (freeze aléatoire du serveur, ou il s'éteint), je vais quand même préparer une VM en 2012r2 en plus si tout foire.
 
Je viens de voir qu'il y a script qui mappe des lecteurs en fonction des droits de chacun.

ça sert à rien de faire un script pour ça, les gpp sont là

oui, effectivement je vais migrer les data avec les droits, si le scritp fonctionne j'aurais pas besoin de gpp sinon je les utiliserais, le problème c'est que le client m'a donné aucune précision sur qui a accès à quoi (je peut toujours le voir en fouillant l'AD et les partages mais c'est tellement le bordel).

Tu lui factures en plus, c'est une autre presta ça

 
Il y a besoin d'installer les outils sur le 2003 pour faire le DCdiag repadmin (support tools) , par contre pour augmenter le niveau fonctionnel tu peux le faire depuis domaine et approbation ou utilisateurs et ordinateurs sans outil supplémentaire ...  
 
En général on corrige les erreurs comme sysvol avant de migrer ... Il y a très peu de cas ou une migration règle des problèmes existant avant avec AD, c'est plutôt le contraire.
Faire un  environnement isolée sans activité ne valide pas grand chose. J'ai déjà corrigé des AD, 1 mois après la migration. C'est une bombe a retardement ton truc.
 
 
Après migration en plus de DCdiag + eventvwr + repadmin, vérifie que tu peux:
- créer et supprimer des objets (utilisateurs, ordi, groupes)
- modifier des groupes
- les GPOs s'appliquent bien
- tu peux adhérer un poste au domaine
- la synchro des horloges fonctionnent ( http://pbarth.fr/node/87 )
etc ...

 
C'est une formation accéléré aux mauvaises pratiques dans un environnement réaliste. C'est le client qui va finir par le facturer (lol) ...
 
Pardon ...

bon, je crois y a une étape qui est mal passé, j'ai mis mon 2003 en pause environ 30 minutes et la plus dns ni d'AD. pourtant mon 2012 est bien serveur principal pour tout. Mais effectivement les 2 VM on eu 30 minutes d'écart (s'était avant de partir hier donc je verrais aujourd'hui).
 
Dans la logique sa veux dire que le 2012 est toujours dépendant du 2003

ça veut dire quoi mettre en pause 30 minutes ?

En même temps faire ce genre d'opérations dans les pires conditions possibles, il te faudrait un miracle pour que ça fonctionne

J'avais mis la VM en pause 30 minutes, mais j'ai résolue le problème (il fallait juste que je fasse changer de contrôleur de domaine dans l'AD de 2012).
 
J'ai tenter de modifier le mot de passe d'un user (j'ai son ordi qui est monter sur le domaine de leur entreprise, mais il communique pas avec mon AD 2012 ).  
 
Je me suis dis que le meilleur test est de prendre un pc monter sur leur domain pour voir si j'ai une bonne migration, ben j'ai changer son mdp et il veut rien savoir.

on met jamais en pause une VM ...
Tu l'éteins mais tu la met jamais en pause.
 
Et tu as migré les FSMO ?
Comment tu gères la synchro du temps ?
Les flux réseaux sont ouverts ?
Les PC utilisent le 2012 en serveur DNS ?

Je mettrais plus jamais une VM en pause effectivement.
le netdow query FSMO me dit que tout est sur le 2012R2
le 2012 est actuellement DNS principal et logiquement AD principal mais pour que les modifications d'AD soit pris en compte il faut que je passe par le 2003 .
Pour la synchro je l'est activé dans VM et tous fonctionne
 
en gros la modification de mdp d'un user dans l'AD du 2012:
changement mdp ad 2012 avec 2003 éteint = fail
changement mdp ad 2012 avec 2003 allumé = ok
Dans l'AD si on fait clic droit sur l'AD  
il y a changer de contrôleur de domaine (je met le 2012)  
il y a aussi changer de domaine (du 2012 ça me met ne répond pas)  
du 2003 ça fonctionne mais je vois qu'entre parenthèse il y a toujours le 2003) je suppose que mon problème vient de là.
Pourtant dans domaine et approbation sur les 2 srv c'est bien le 2012 .

si ton 2012 est vraiment PDC emulator il doit synchro son temps sur une source externe (GPS ou un serveur ntp externe)
Et je pense que tes DC communiquent mal, dcdiag t'en dira surement plus ^^ tout comme les event logs

Et potentiellement passer par un seize des FSMO sur le 2012...faudrait voir l'état de ton AD

 
Avec plusieurs DC les DCs doivent répliquer, jamais de pause !!! Avec un seul c'est plus simple (c'est pour cela que ca que tu as pu avec un peu de bonheur faire ton vhd) .
Il ne faut pas utiliser de pause, de snapshot sur un DC avant 2012 ce n'est pas supporté dans des conditions précises (cela ne veut pas dire que c'est bien de le faire après).
Dans l'annuaire AD tu as des éléments liés à la machine pour la réplication. Dans les DNS tu as également des infos dans la zone de la forêt.
Vérifie les horloges, pas plus de 5 minutes d'écart, corrige si nécessaire. configure la synchro de temps sur le 2012. Tu as regardé le lien précédent : http://pbarth.fr/node/87  
 
Les 2 DCs utilisent le même DNS primaire ? Sinon fait les pointer sur le même pour être sur qu'ils voient la même chose .tu peux faire un nslookup pour vérifier la résolution de nom ?  
Le 2012 est catalogue global ?
 AD est multi maître, ca n'existe pas AD principal depuis Windows 2000.
Les rôles FSMO sont des rôles particuliers, en dehors de l'émulateur PDC qui est utilisé en priorité pour les réplications urgentes (changement de mdp), l'indisponibilité des autres rôles n'est pas une priorité.
Erreurs dans :
DCdiag ?
repadmin /showrepl ?

Ouai j'ai regarder lien d'avant et dans les services du 2003 j'ai pas temps internet
j'ai tenter un net start win32time (il me sort que sa n'existe pas)
 
le DCdiag m'a sortie une erreur 1753
le repadmin me sort des erreurs de mappage depuis cette fameuse pause.
sa me servira de leçon.
 
En plus du système totalement installable du 2003 je crois j'ai tous casser.
 
La bonne nouvelle c'est que le client est ok pour refaire toute son infrastructure (mais en 2 fois ).  
Il est en attente de devis pour migré sage sur un 2012R2
Se serait tellement plus simple .
 
mon AD sur le 2012 ne communique pas en direct avec les postes user il faut le 2003 qui en plus est DHCP ;/.
 
J'ai voulus remettre tout les droits au 2003 pour recommencer ma migration, j'ai nettoyer l'AD du 2012 avec ce lien
https://www.it-connect.fr/retrograd [...] rver-2012/
 
Mais depuis l'AD du 2003 est plus joignable, je suis sur que j'étais pas loin d'y arriver. J'ai le VHD d'origine du 2003, je pense tout recommencer quand j'aurais terminé avec un autre client.

Je ne comprends pas de quoi tu parles ...
Ne mélangé pas DHCP , AD etc ...
Le lien que tu mets c'est pour supprimer un DC quand ca va.
Quand tu supprimes un DC les modifications et les liens de réplications doivent être purger sur le DC restant. Du coup ça ne marche pas toujours. Il faut des fois faire un forceremoval voir un metadata cleanup (a partir de 2008 c'est plus simple ).  http://pbarth.fr/node/94
 
Tu veux dire quoi par remettre les droits sur le 2003  ?
Sinon pour les erreurs dcdiag et repadmin il faut plus de détail pour te guider.

 
Je parlais du DHCP du 2003 car je n'ai pas précisé qu'il avait ce rôle et je sais pas si sa peut crée des problèmes avec l'AD.
En revenche je me demande si c'est normale de pas avoir de service serveur de temps sur un 2003?
 
Ah, oui j'a retrouvé des script qui date de 1996 et il semblerait que ce 2003 est une migration d'un 2000 voir NT4   .

Si tu as un serveur de temps, il est géré par un autre service que w32tm. Laisse tomber, tu n'as pas les compétences suffisantes et tu viens de tout péter, passe à autre chose.

 
Non ton DHCP n'a pas d'impact avec les contrôleurs de domaine qui doivent être en IPFixe.  
Les migrations précédentes n'ont pas de lien avec le problème de migration.
Je pense qu'il devait y avoir des erreurs dans le DCdiag du 2003 même avant d'ajouter le 2012. Dans tous les cas lors d'une migration c'est impératif de vérifier et corriger avant l'ajout de nouveau serveur.  
Lors d'un PtoV d'un DC il y a plein d'enregistrement DNS et d'autres truc a vérifier et valider, avant de passer à la suite.
Même si mettre la VM en pause a compliqué ton affaire, je ne suis pas convaincu de la bonne santé juste avant. Sincèrement ce serait un miracle si tout était propre pour quelqu'un qui ne maîtrise pas encore AD.

Je vais faire un dcdiag sur le serveur principal de départ et un repadmin, mais je suis persuadé qu'il y avait un problème à la base, je souviens avoir vue une erreur dans le sysvol (que j'ai ignorer car je suis partie chez un autre client qui s'est fait attaquer tout le réseau, enfin bref je suis rentrer j'étais perdu sur mon serveur). Faire 30 truc a la fois sa fous le bordel .

 
Va falloir m'expliquer pourquoi  j'ai retrouver mon serveur 2003 avec 30 minutes de retard  
Et j'aurais toutes les compétences nécessaire je vous embêterais pas  

Sur le server en prod DCdiag c'est ok (mais pas sur ma VM, donc effectivement les clone d'un AD, vous aviez raison c'est dead, et grace a ça mon boss est ok pour refaire une infra en repartant de zero mais je vais quand même tenter l'expérience en VM c'est toujours bon de savoir se qui coince dans cette situation).
le repadmin /showrepl sur la ligne Site option j'ai (none). logique vue qu'il est seul.

on te l'a dit plus haut, pour faire un p2V d'un DC, il faut le faire a froid.
et même dans ce cas, ya pas mal de trucs a refaire derrière et surtout sans garantie d'y arriver a la fin
 
ton décalage de 30mn, c'est normal.
t'as mis la VM en pause 30mn.
 
de base sur 2003, le serveur de temps se base sur l'horloge système.
ya pas de synchro externe (a configurer a la main)

 
Pour cloner un DC c'est pas impossible mais cela demande beaucoup d'expérience( sur les enregistrement DNS, des services AD, sur la réplication etc... ).  
C'est encore plus casse tête si tu as plusieurs DC, car il y a des liens de réplication et il y a un lien entre les infos dans l'annuaire et les infos de la machine . Quand tu fais une clonage du disque et que tu recréé une nouvelle machine avec les infos de l'autre, il y a forcément du travail et pas de place pour le hasard.
Je suis quasi certain que lorsque tu as crée ta VM 2003 avec le disque, il y avait des erreurs dans DCDiag.
 
 Et si c'est une forêt multi-domaines, la c'est juste un gros délire ...
 
Dans tous les cas cela demande de bonnes conséquences, c'est long, c'est risqué, c'est pas recommandé, alors que la migration classique fonctionne plutôt bien, ça va assez vite avec un risque minime ...
Si tu veux vraiment progresser, apprend déjà les mécanismes de la migrations classiques. Ne passe pas à l'étape suivante avant d'avoir un DCdiag propre.
Si cela t'interesse :
https://becomeitexpert.com/produit/ [...] e-edition/

Effectivement, il y a 2 DNS en plus des problèmes de compatibilité entre le 2003 et hyperviseur (que se soit hyper-V ou Vmware = pas de carte réseau au démarrage, l'installation des tool's réduit les performances (écran bleu direct sur un ESX pour les Tool's)).
 
Et redémarrer 2 DNS sans carte réseau crée directement des erreurs.
Je fini ce livre
https://www.amazon.fr/gp/product/27 [...] UTF8&psc=1
 et je pense attaquer le tien.
 
Au niveau des VM je pense mettre la synchro du 2003 avec l'hyperviseur pour me servir de serveur de temps?

Bon, j'ai retenter sous VMware sur mon ordi, j'ai pris seulement C: faute de place, je n'ai donc pas les data mais c'est pas prévu de les migré de cette manière.
Démarrage de la VM, comme dab pas de carte réseau, installation des tool's je remet l'ip du serveur et le dns il me sort ça:
 

J'ai bien compris que l'IP est attribué à une autre carte (qui n'existe plus) mais c'est l'IP du dns.
 
Je lance un DCdiag (2 erreurs, surement les data):

 
Ensuite l'autre erreur:

 
A la fin il me sort  
failed test sytemlog
 
Je précise que je n'ai pas eu autant d'erreurs précédemment.
Mais la je retest tout au propre je n'ai donc rien modifier, j'ai juste le C: sans les DATA (D.

 
Tu as remis la bonne IP du 2003 ?  C'est normal que tu as un avertissement il reste des traces dans le registre Windows de l'ancienne carte réseau qui n'est plus détecté et qui a la même IP.
https://blogs.technet.microsoft.com [...] remove-it/
Au niveau de DCdiag , il faut comprendre qu'il remonte systématiquement les erreurs sur les 24 dernières heures de l'observateur d'événement. Et il y a forcément eu des erreurs au premier démarrage. Donc pour DCdiag il faut obtenir un DCDiag propre et s'assurer qu'il n'y a pas d'erreurs 24 heures après.
Certaines personnes, vide les journaux d’événement et redémarre le serveur, afin d'analyser que les nouvelles erreurs.  
 
Pour l'erreur sysvol si l'erreur persiste, tu peux essayer de faire une restauration autoritaire de sysvol sur ce DC même si c'est le seul :
https://support.microsoft.com/fr-fr [...] tion-servi
 
Tu prends la moitié de ton serveur (c: ) et tu essaye au petit bonheur la chance d'en faire un DC viable.
 
Vouloir apprendre à faire du ski en commençant par le hors piste sur les plus hauts sommets des Alpes , faut du courage !  
 
Bon après une fois que tu connais la méthode classique avec risque limité et assez rapide, tu trouves moins d'attrait à faire quelques choses de long, délicat , hasardeux et risqué.