none
Replications Sites AD

    Question

  • Bonjour à tous,

    voici l'infrastructure de mon client:

    un site AD boulogne:

    - Serveur hôte hyper-V, Active Directory domain1.local (primaire), + 2 VM domain2.local et domain3.local (primaires)

    un site AD Lyon:

    - Serveur hôte hyper-v, Activre Directory domain1.local (secondaire), +2 VM domain2.local et domain3.local (secondaires)

    Sur les 2 sites AD, des utilisateurs sont présents. il y a une réplication DFSR pour le domain2.local et domain3.local.

    j'ai remarqué il y a 3 jours qu'un problème était présent quand un utilisateur m'a expliqué que ses fichiers/dossiers n'étaient pas présents pour les utilisateurs de boulogne.

    après plusieurs analyses des journaux d'évènements, les sites AD (domain1, domain2 et domain3) n'étaient en fait plus répliqués et depuis Lyon impossible de contacter les serveurs de boulogne.

    source : ActiveDirectory_DomainService | id : 1865

    source : ActiveDirectory_DomainService | id : 1311

    source : ActiveDirectory_DomainService | id : 1566

    les tests DCDIAG /replications depuis Boulogne :La réplication a généré une erreur (1818) :
    L'appel de procédure distante a été annulé.

    les test DCDIAG /replications depuis Lyon :  La réplication a généré une erreur (1256
     Le système distant n'est pas disponible.  La réplication a généré une erreur (1727) :
    L'appel de procédure distante a échoué et ne s'est pas exécuté.

    j'ai recherché durant 3 jours des solutions eventuelles sur les forums mais rien n'a fonctionné. Les sites AD et liens sont bien configurés, les DNS également ( INFRA en prod depuis 2ans sans problème). Pour les domain2.local et domain3.local, c'était assez urgent, j'ai donc dépromu les serveur de Lyon + réintégré dans les domaines. Pour l'instant ca fonctionne.

    en revanche, pour le domain1.local toujours même problème, et j'aimerai bien comprendre le problème.

    merci pour vos retours :)

    Pierre


    dimanche 4 février 2018 14:20

Réponses

  • Quel config réseau + DNS primaire sur chaque DC ?

    Tu as vérifié la résolution DNS pour chaque DC ? (voir nslookup)

    Lien entre les sites ? Pas de filtrage sur certain port ou protocole ?

    Note :

    Pour la réplication les serveurs utilisent des enregistrement DNS avec id lié au partenaire de réplication. Les enregistrements doivent exister dans la zone de la forêt :

    Vérifie que les enregistrements existent des deux côtés dans les DNS. utilise repadmin pour vérifier la valeur.

    Les DCs n'ont qu'une IP ? A jour dans les DNS ?

    dimanche 4 février 2018 22:11
    Modérateur
  • En effet, il y a un problème, les GUID et les Alias ne correspondent pas. que ce soit sur le serveur de Lyon ou Boulogne.

    en revanche, les nslookup fonctionnent correctement.

    comment faire pour les réinitialiser et les faire correspondre ?

    Bonjour,

    Pour vérifier si l'alias qui correspond au GUID existe vous pouvez verifier la commande nslookup c'est plus simple :

    GUID._msdcs.domain1.local


    Please don't forget to mark the correct answer, to help others who have the same issue. Thameur BOURBITA MCSE | MCSA My Blog : http://bourbitathameur.blogspot.fr/

    lundi 5 février 2018 13:37
    Modérateur
  • La commande ipconfig /registerdns met à jour l'enregistrement A d'un DC. Le redémarrage du service Netlogon mets à jour les enregistrements de service ...

    Voir :

    http://pbarth.fr/node/35

    Tu peux également créer l'enregistrement manuellement dans DNS si cela aide à débloqué.

    L'id d'invocation est généralement identique au GUID sauf par exemple si le contrôleur de domaine à été restauré depuis une sauvegarde avec l'état du système (ce qui est la méthode recommandé ; GUID change pas, ID est réinitialisé). Ce changement permet au DC de reprendre la réplication correctement.


    lundi 5 février 2018 13:55
    Modérateur
  • Bonjour,

    tout d'abord merci à vous pour vos réponses.

    On peut dire que le problème est maintenant résolu, grâce aux actions suivantes:

    - vérification avec la commande repadmin /showrepl, sur les 2 serveurs, que le GUID de l'objet DSA correspondait bien à l'alias du serveur

    --> non : suppression de l'alias manuellement + recréation ( je crois que cela s'est fait automatiquement) ou manuellement grâce à la commande ipconfig /registerdns

    - vérification des évènements dans le journal Directory Service : event ActiveDirectory_DomainService id 1162

    depuis plus d'erreurs.

    Egalement, je ne sais pas si il peut y avoir une conséquence, mais nous avons redémarré notre routeur car les telephones IP étaient bloqués et ne communiquaient pas avec le serveur externe ; leurs requêtes DHCP ne recevaient pas de réponses.

    voila voila.

    bonne journée à tous

    mercredi 7 février 2018 08:45

Toutes les réponses

  • Vous pouvez nous retourner le résultat de la commande REPADMIN /SHOWREPL sur DOMAIN1 ?
    dimanche 4 février 2018 15:32
  • Serveur hôte hyper-v, Activre Directory domain1.local 

    C'est une très mauvaise idée de cumuler le rôle AD DS avec le role HyperV.

    Sinon dcdiag et repadmin sont les outils de base.

    dcdiag /e /q permet de vérifier l'ensemble des DCs.

    et 

    repadmin /showrepl la réplication.


    dimanche 4 février 2018 17:29
    Modérateur
  • Bonsoir et merci pour les retours,

    voici les résultats des commandes:

    Boulogne :

    repadmin /showrepl:

    Repadminÿ: ex‚cution de la commande /SHOWREPL sur le contr“leur de domaine complet localhost

    Default-First-Site-Name\serveur1

    Options DSAÿ: IS_GC

    Options de siteÿ: (none)

    GUID de l'objet DSAÿ: 13d73ca7-ea91-4332-b315-0f60deda99fe

    ID de l'invocation DSAÿ: 13d73ca7-ea91-4332-b315-0f60deda99fe



    === INSTANCES VOISINES ENTRANTES ==================================



    DC=domain1,DC=local

        Lyon\serveur2 via RPC

            GUID de l'objet DSAÿ: 77a324e6-ae8c-42b1-82e9-0b759954a26c

            La derniŠre tentative, le 2018-02-04 19:13:01, a ‚chou‚, r‚sultat 1818 (0x71a):

                L'appel de proc‚dure distante a ‚t‚ annul‚.

            3 ‚checs cons‚cutifs.

            DerniŠre r‚ussite le 2018-02-04 10:08:01.



    CN=Configuration,DC=domain1,DC=local

        Lyon\serveur2 via RPC

            GUID de l'objet DSAÿ: 77a324e6-ae8c-42b1-82e9-0b759954a26c

            La derniŠre tentative, le 2018-02-04 19:13:20, a r‚ussi.



    CN=Schema,CN=Configuration,DC=domain1,DC=local

        Lyon\serveur2 via RPC

            GUID de l'objet DSAÿ: 77a324e6-ae8c-42b1-82e9-0b759954a26c

            La derniŠre tentative, le 2018-02-04 19:13:20, a r‚ussi.



    DC=DomainDnsZones,DC=domain1,DC=local

        Lyon\serveur2 via RPC

            GUID de l'objet DSAÿ: 77a324e6-ae8c-42b1-82e9-0b759954a26c

            La derniŠre tentative, le 2018-02-04 16:18:02, a ‚chou‚, r‚sultat 1818 (0x71a):

                L'appel de proc‚dure distante a ‚t‚ annul‚.

            40 ‚checs cons‚cutifs.

            DerniŠre r‚ussite le 2018-01-30 16:08:03.



    DC=ForestDnsZones,DC=domain1,DC=local

        Lyon\serveur2 via RPC

            GUID de l'objet DSAÿ: 77a324e6-ae8c-42b1-82e9-0b759954a26c

            La derniŠre tentative, le 2018-02-04 16:23:21, a ‚chou‚, r‚sultat 1818 (0x71a):

                L'appel de proc‚dure distante a ‚t‚ annul‚.

            36 ‚checs cons‚cutifs.

            DerniŠre r‚ussite le 2018-01-31 04:13:00.



    Sourceÿ: Lyon\serveur2

    ******* 40 checs cons‚cutifs depuis 2018-02-04 10:08:01

    DerniŠre erreurÿ: 1818 (0x71a):

                L'appel de proc‚dure distante a ‚t‚ annul‚.

    Lyon :

    repadmin /showrepl

    Repadminÿ: ex‚cution de la commande /showrepl sur le contr“leur de domaine complet localhost

    Lyon\serveur2

    Options DSAÿ: IS_GC

    Options de siteÿ: (none)

    GUID de l'objet DSAÿ: 77a324e6-ae8c-42b1-82e9-0b759954a26c

    ID de l'invocation DSAÿ: d0ebbcdb-7691-4f12-978d-dcfe94a2343b



    === INSTANCES VOISINES ENTRANTES ==================================



    DC=domain1,DC=local

        Default-First-Site-Name\serveur1 via RPC

            GUID de l'objet DSAÿ: 13d73ca7-ea91-4332-b315-0f60deda99fe

            La derniŠre tentative, le 2018-02-04 19:13:27, a ‚chou‚, r‚sultat 1727 (0x6bf):

                L'appel de proc‚dure distante a ‚chou‚ et ne s'est pas ex‚cut‚.

            42 ‚checs cons‚cutifs.

            DerniŠre r‚ussite le 2018-01-30 16:14:21.



    CN=Configuration,DC=domain1,DC=local

        Default-First-Site-Name\serveur1 via RPC

            GUID de l'objet DSAÿ: 13d73ca7-ea91-4332-b315-0f60deda99fe

            La derniŠre tentative, le 2018-02-04 19:12:11, a ‚chou‚, r‚sultat 1727 (0x6bf):

                L'appel de proc‚dure distante a ‚chou‚ et ne s'est pas ex‚cut‚.

            42 ‚checs cons‚cutifs.

            DerniŠre r‚ussite le 2018-01-30 16:14:21.



    CN=Schema,CN=Configuration,DC=domain1,DC=local

        Default-First-Site-Name\serveur1 via RPC

            GUID de l'objet DSAÿ: 13d73ca7-ea91-4332-b315-0f60deda99fe

            La derniŠre tentative, le 2018-02-04 19:12:49, a ‚chou‚, r‚sultat 1727 (0x6bf):

                L'appel de proc‚dure distante a ‚chou‚ et ne s'est pas ex‚cut‚.

            42 ‚checs cons‚cutifs.

            DerniŠre r‚ussite le 2018-01-30 16:14:21.



    DC=DomainDnsZones,DC=domain1,DC=local

        Default-First-Site-Name\serveur1 via RPC

            GUID de l'objet DSAÿ: 13d73ca7-ea91-4332-b315-0f60deda99fe

            La derniŠre tentative, le 2018-02-04 19:12:11, a ‚chou‚, r‚sultat 1256 (0x4e8):

                Le systŠme distant n'est pas disponible. Pour obtenir des informations … propos du d‚pannage r‚seau, consulter l'Aide Windows.

            42 ‚checs cons‚cutifs.

            DerniŠre r‚ussite le 2018-01-30 16:14:21.



    DC=ForestDnsZones,DC=domain1,DC=local

        Default-First-Site-Name\serveur1 via RPC

            GUID de l'objet DSAÿ: 13d73ca7-ea91-4332-b315-0f60deda99fe

            La derniŠre tentative, le 2018-02-04 19:12:11, a ‚chou‚, r‚sultat 1256 (0x4e8):

                Le systŠme distant n'est pas disponible. Pour obtenir des informations … propos du d‚pannage r‚seau, consulter l'Aide Windows.

            42 ‚checs cons‚cutifs.

            DerniŠre r‚ussite le 2018-01-30 16:14:22.



    Sourceÿ: Default-First-Site-Name\serveur1

    ******* 42 checs cons‚cutifs depuis 2018-01-30 16:14:22

    DerniŠre erreurÿ: 1727 (0x6bf):

                L'appel de proc‚dure distante a ‚chou‚ et ne s'est pas ex‚cut‚.

    Comme expliqué dans le premier poste, les commandes repadmin et dcdiag je les ai pas mal utilisé pour analyser les problèmes sur mes 2 autres domaines virtualisés mais sans parvenir à totalement résoudre les erreurs.

    Pierre







    dimanche 4 février 2018 18:30
  • Quel config réseau + DNS primaire sur chaque DC ?

    Tu as vérifié la résolution DNS pour chaque DC ? (voir nslookup)

    Lien entre les sites ? Pas de filtrage sur certain port ou protocole ?

    Note :

    Pour la réplication les serveurs utilisent des enregistrement DNS avec id lié au partenaire de réplication. Les enregistrements doivent exister dans la zone de la forêt :

    Vérifie que les enregistrements existent des deux côtés dans les DNS. utilise repadmin pour vérifier la valeur.

    Les DCs n'ont qu'une IP ? A jour dans les DNS ?

    dimanche 4 février 2018 22:11
    Modérateur
  • Comme vous l'indique Philippe, il semble qu'il y a un problème du coté de votre configuration DNS : vous devriez vérifier les configurations clients des 2 DC (ils ne doivent pointer sur rien d'autre que des serveurs DNS hébergeant la zone AD concernée), vérifier les records (nslookup sur le nom de domaine ne devrait retourner que les IP de vos DC), vérifier les enregistrements dans la zone _MSDCS.
    lundi 5 février 2018 12:00
  • En effet, il y a un problème, les GUID et les Alias ne correspondent pas. que ce soit sur le serveur de Lyon ou Boulogne.

    en revanche, les nslookup fonctionnent correctement.

    comment faire pour les réinitialiser et les faire correspondre ?

    lundi 5 février 2018 12:33
  • En effet, il y a un problème, les GUID et les Alias ne correspondent pas. que ce soit sur le serveur de Lyon ou Boulogne.

    en revanche, les nslookup fonctionnent correctement.

    comment faire pour les réinitialiser et les faire correspondre ?

    Bonjour,

    Pour vérifier si l'alias qui correspond au GUID existe vous pouvez verifier la commande nslookup c'est plus simple :

    GUID._msdcs.domain1.local


    Please don't forget to mark the correct answer, to help others who have the same issue. Thameur BOURBITA MCSE | MCSA My Blog : http://bourbitathameur.blogspot.fr/

    lundi 5 février 2018 13:37
    Modérateur
  • Les nslookup GUID me renvoient bien les bonnes IP et les bon noms.

    en revanche, lorsque je fais un repadmin /showrepl, le GUID de l'objet DSA et l'ID de l'invocation de correspondent pas. est ce normal ?

    les serveurs n'ont qu'une IP, leur DNS primaire correspondent à leur adresse IP, et la secondaire à l'autre serveur DNS.

    Pierre

    lundi 5 février 2018 13:48
  • La commande ipconfig /registerdns met à jour l'enregistrement A d'un DC. Le redémarrage du service Netlogon mets à jour les enregistrements de service ...

    Voir :

    http://pbarth.fr/node/35

    Tu peux également créer l'enregistrement manuellement dans DNS si cela aide à débloqué.

    L'id d'invocation est généralement identique au GUID sauf par exemple si le contrôleur de domaine à été restauré depuis une sauvegarde avec l'état du système (ce qui est la méthode recommandé ; GUID change pas, ID est réinitialisé). Ce changement permet au DC de reprendre la réplication correctement.


    lundi 5 février 2018 13:55
    Modérateur
  • d'accord, je vais attendre demain voir si les modifications effectuées ont été bénéfiques.

    merci pour vos retours.

    Pierre

    lundi 5 février 2018 16:20
  • Bonjour,

    tout d'abord merci à vous pour vos réponses.

    On peut dire que le problème est maintenant résolu, grâce aux actions suivantes:

    - vérification avec la commande repadmin /showrepl, sur les 2 serveurs, que le GUID de l'objet DSA correspondait bien à l'alias du serveur

    --> non : suppression de l'alias manuellement + recréation ( je crois que cela s'est fait automatiquement) ou manuellement grâce à la commande ipconfig /registerdns

    - vérification des évènements dans le journal Directory Service : event ActiveDirectory_DomainService id 1162

    depuis plus d'erreurs.

    Egalement, je ne sais pas si il peut y avoir une conséquence, mais nous avons redémarré notre routeur car les telephones IP étaient bloqués et ne communiquaient pas avec le serveur externe ; leurs requêtes DHCP ne recevaient pas de réponses.

    voila voila.

    bonne journée à tous

    mercredi 7 février 2018 08:45