none
Migration AD RRS feed

  • Question

  • bonjour,

    Suite à une migration de l'AD entre 2 serveurs 2012R2, je n'ai pas de partage Netlogon sur le serveur de destination.

    habituellement, je modifie la base de registre et la clé Burflag sur le serveur d'origine pour régler ce problème.

    Mais, dans HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters du serveur d'origine, je n'ai ... rien, si ce n'est un pauvre sysvol avec rien dedans !!!

    Les sauvegarde ne remontent pas assez loin pour régler le problème.Sinon, tout fonctionne correctement.

    Avez-vous une idée pour "reconstruire" la base de registre??

    Merci

    Cordialement

    Yves

    mercredi 26 septembre 2018 07:43

Réponses

  • Un événement d'avertissement s'est produit. ID de l'événement :
             0x800503EC
                Temps généré : 09/26/2018   10:36:16
                Chaîne d'événement :
                Le pilote de périphérique IPMI a tenté de communiquer normalement av
    ec le périphérique BMC IPMI. Cependant, la communication a échoué en raison du d
    épassement d'un délai. Vous pouvez augmenter les délais associés au pilote de pé
    riphérique IPMI.

    Ca c'est un avertissement. Tu as forcément d'autres erreurs plus significatif. Tu as fait sur les 2 serveurs ou juste l'ancien. Ton erreur sysvol doit  laisser des traces dans Dcdiag. Peut-être même la cause.

    Et repadmin ?


    Je sais que j'ai commis une erreur en lançant la migration sans vérif, mais bon...

    L'important c'est de comprendre et progresser. On a tous fait les même erreurs, juste pas au même moment...

    Et qu'entends-tu par:  "Ensuite il faut dépanner sysvol" 

    Remettre en route la réplication de fichier
    Puisque c'est du DFS-R :

    http://www.pbarth.fr/node/135


    mercredi 26 septembre 2018 09:46
    Modérateur
  • Conseil 

    1 - refaites un DCdiag  +  repadmin  /showrepl avant de supprimer l'ancien, on doit pouvoir rester 24 sans erreur significatif. 

    2 - vérifier et mettre à jour tous  les DNS primaire et secondaire partout, 

    3- la patiente, il ne faut jamais être trop pressé pour rétrograder l'ancien, l'AD peut très bien remplir son rôle alors qu'il reste des soucis sur l'ancien. 


    mercredi 26 septembre 2018 13:06
    Modérateur

Toutes les réponses

  • Bonjour yversrsi

    Regarde si ce lien peut t'aider

    https://social.technet.microsoft.com/Forums/fr-FR/8675729a-e827-4fea-b4a5-8c9144ff3e37/dossier-sysvoldomain-ne-contient-plus-de-dossier-avec-mon-nom-de-domaine?forum=windowsserver2008fr

    résumé

    Pour commencer il existe 2 méthode de réplication pour sysvol :

    - NTFRS (old)  si le domaine a été créé avec un niveau fonctionnelle inférieur à 2008
    - DFS-R si il a été crée avec 2008 ou supérieur ou s'il a été migré en dfs-r par DFSMIG

    Donc ta solution va dépendre du type de réplication:

    A lire :
    http://www.pbarth.fr/node/75

    La clé BurFlags de ton lien c'est que pour du NTFRS, la méthode est différente pour DFS-R
    http://www.pbarth.fr/node/135

    Tu peux déterminer le type de réplication avec la commande 
    dfsrmig /getglobalstate 

    si la réponse est démarrer (pas encore démarrer) ou préparer alors c'est NTFRS
    si c'est redirigé ou éliminée c'est du DFS-R

    De plus il existe deux façon de restaurer :
    -autoritaire, sur un DC source qui est fiable tu lui indique de faire une restauration autoritaire, tous les autres DCs vont récupérer le contenu chez lui
    -non autoritaire, sur un DC particulier qui a des soucis tu fait une restauration non autoritaire, il va récupérer le contenu sur un des autres DCs

    Si tu lance une restauration autoritaire depuis à partir d'un DC HS qui n'a plus rien dans sysvol et ben tu n'auras plus rien sur les autres ...

    Tu as des sauvegardes de l'état du système ?


    "Marquer comme réponse" les réponses qui ont résolu votre problème



    mercredi 26 septembre 2018 07:50
  • Merci pour ta réponse,

    Le niveau fonctionnel est 2008r2

    La commande dfsrmig donne:

         État global actuel de DFSR : « Éliminé »

         Réussi.

    J'ai des sauvegardes de l’état du système mais qui ne remonte pas assez loin.

    Je vais regarder ton lien sur la méthode pour DFS-R

    Je me permettrais de revenir si jamais je ne m'en sors pas.

    Merci

    mercredi 26 septembre 2018 08:22
  • Le premier outil que l'on utilise lorsqu'on fait une migration AD c'est Dcdiag. Le deuxième c'est repadmin /showrepl pour vérifier la réplication de l'annuaire.

    On les utilise avant pour vérifier l'état. Des erreurs en amont entraîne quasi systématiquement des problèmes.

    Pendant la migration. Et après ... A consommer sans modération.

    Tu peux exécuter ces commandes sur ton DCs ?

    Il peut y avoir des soucis par exemple si sur le nouveau serveur tu as en tant  que DNS  primaire dans IPV6 "::1"(lui même adresse de bouclage en ipv6) 

    Avant la conf AD comme il n'a pas encore le rôle DNS il utilise le DNS configuré sur IPV4. 

    Au moment de la conf AD, on ajoute en général le rôle DNS et il devient serveur DNS. Mais le contenu des zones intégrés AD n'est pas encore à jour.

    Au redémarrage il utilise en priorité IPV6 mais il ne peut pas résoudre tant que la réplication n'est pas terminée. Il ne peut pas répliquer tant qu'il n'y a pas de résolution DNS. LEs conséquences sont pas de message indiquant la fin de la réplication initiale dans l'observateur d'événement. Pas de syncho sysvol et il ne monte pas les partages netlogon et sysvol. 

    Il suffit d'enlever "::1" de IPV6 et de faire un repadmin /syncall. Ensuite il faut dépanner sysvol.

    Bien évidement il peut y avoir d'autres causes.

    Il n'y a que très peu de chose qui ne se voit pas au dcdiag.


    Il est possible de faire un DCdiag avec que les erreurs sur tous les DC en une fois :

    http://www.pbarth.fr/node/218

    Il est possible d'utiliser AD Replication Status Tool plutôt que repamin :

    https://www.microsoft.com/en-us/download/details.aspx?id=30005

    Sinon, tout fonctionne correctement.

    Tout fonctionne grâce à l'ancien DC. C'est un peu pour cela que j'insiste souvent sur le principe qu'il n'y a pas de DC principal et que c'est multimaitre, car les services continus même en cas de problème sur un DC de manière relativement transparente. Et souvent on constate l'anomalie à la suppression de l'ancien DC. AD est multimaitre sauf quelques rôles, une anomalie sur un DC ne donne pas forcément d'impact visible du côté de l'utilisateur.






    mercredi 26 septembre 2018 08:35
    Modérateur
  • J'ai des sauvegardes de l’état du système mais qui ne remonte pas assez loin.

    En génral on ne revient jamais loin en arrière avec les sauvegardes de l'AD. Si tu as un soucis avec un DC tu peux conserver un DC viable et nettoyer les métadonnées.

    http://www.pbarth.fr/node/94

    A savoir les comptes d'ordi change de mot de passe automatiquement tous les 30 jours. 

    Si tu reviens de 30 jours en arrière, tu peux refaire l'adhésion aou réinitialiser les MDP sur tous le parc. Acec 10 PC ca passe avec 10000, tu t'es donnée du boulot pour rien.

    Quand tu reviens en arrière il faudra recréer , modifier tous ceux qui a été fait depuis la sauvegarde. Si tu recrée un utilisateur il n'aura pas le même identifiants SID que le précédent, il pourra en obtenir un qui a été utilisé par quelqu'un d'autre et qui dispose de droits ce qui crée un problème

    On va restaurer un DC que s'il n'y a plus de DC viables, si l'AD est corrompu ou si une des limites est atteinte.

    La méthode de restauration doit supporté la restauration de l'état du système.

    https://becomeitexpert.com/produit/active-directory-sauvegarde-restauration-1er-edition/



    mercredi 26 septembre 2018 08:45
    Modérateur
  •    

     bonjour,

    Je sais que j'ai commis une erreur en lançant la migration sans vérif, mais bon...

    Le DCdiag donne quelques avertissements:

    Un événement d'avertissement s'est produit. ID de l'événement :
             0x800503EC
                Temps généré : 09/26/2018   10:36:16
                Chaîne d'événement :
                Le pilote de périphérique IPMI a tenté de communiquer normalement av
    ec le périphérique BMC IPMI. Cependant, la communication a échoué en raison du d
    épassement d'un délai. Vous pouvez augmenter les délais associés au pilote de pé
    riphérique IPMI.

    Et qu'entends-tu par:  "Ensuite il faut dépanner sysvol"

    Merci pour ta réponse

    Yves

    mercredi 26 septembre 2018 08:49
  • Un événement d'avertissement s'est produit. ID de l'événement :
             0x800503EC
                Temps généré : 09/26/2018   10:36:16
                Chaîne d'événement :
                Le pilote de périphérique IPMI a tenté de communiquer normalement av
    ec le périphérique BMC IPMI. Cependant, la communication a échoué en raison du d
    épassement d'un délai. Vous pouvez augmenter les délais associés au pilote de pé
    riphérique IPMI.

    Ca c'est un avertissement. Tu as forcément d'autres erreurs plus significatif. Tu as fait sur les 2 serveurs ou juste l'ancien. Ton erreur sysvol doit  laisser des traces dans Dcdiag. Peut-être même la cause.

    Et repadmin ?


    Je sais que j'ai commis une erreur en lançant la migration sans vérif, mais bon...

    L'important c'est de comprendre et progresser. On a tous fait les même erreurs, juste pas au même moment...

    Et qu'entends-tu par:  "Ensuite il faut dépanner sysvol" 

    Remettre en route la réplication de fichier
    Puisque c'est du DFS-R :

    http://www.pbarth.fr/node/135


    mercredi 26 septembre 2018 09:46
    Modérateur
  • Merci pour vos réponses qui m'ont vraiment aidé à comprendre pas mal de choses.

    J'ai suivi le lien http://www.pbarth.fr/node/135 et avec un peu de patience la synchro entre mes deux serveurs se fait correctement et j'ai bien le Sysvol et Netlogon sur le nouveau serveur.

    Je vais redémarrer mes serveurs cette nuit, migrer mes rôles FSMO sur le nouveau serveur et rétrograder l'ancien.

    Si vous avez des conseils supplémentaires, n'hésitez pas, j'ai beaucoup appris aujourd'hui, MERCI

    A bientôt


    • Modifié yvesrsi mercredi 26 septembre 2018 12:58
    mercredi 26 septembre 2018 12:48
  • Conseil 

    1 - refaites un DCdiag  +  repadmin  /showrepl avant de supprimer l'ancien, on doit pouvoir rester 24 sans erreur significatif. 

    2 - vérifier et mettre à jour tous  les DNS primaire et secondaire partout, 

    3- la patiente, il ne faut jamais être trop pressé pour rétrograder l'ancien, l'AD peut très bien remplir son rôle alors qu'il reste des soucis sur l'ancien. 


    mercredi 26 septembre 2018 13:06
    Modérateur