none
AD gros problèmes de réplication avec un site distant RRS feed

 > 

  • Question

  • Question
    Connectez-vous pour voter
    2
    Connectez-vous pour voter

    Bonjour à tous,


    Je viens d'arriver chez un client pour revoir l’infrastructure AD et lors de mes vérifications je vois qu'il y a de gros problèmes de réplication avec un site distant. La situation est assez désespérante :


    Environnement :

    • 1 forêt  / 1 domaine
    • une dizaine de sites distants (donc autant de sites AD dans sites et services AD)
    • Une quinzaine de DC répartis sur les différents sites
    • niveau dc/forêt : 2008R2
    • Les sites sont interconnectés avec un réseau mpls opérateur


    Problèmes :

    • La première chose que j'ai remarqué est la non application des GPO sur ce site distant.


    • En faisant un repadmin /showreplsum depuis les sites qui fonctionnent bien, on voit tous les serveurs de ce site distant qui pose soucis avec des erreurs et le commentaire : 1818 L'appel de procédure distant a échoué.
    • Depuis le site qui fonctionne mal, c'est l'inverse, on voit tous les serveurs des autres sites avec : 1818 L'appel de procédure distant a échoué. On a aussi du (1256) Le système distant n'est pas disponible.


    • en faisant les tests DNS du DCdiag depuis les sites qui fonctionnent bien j'ai les erreurs suivantes :
    •  Test connectivity qui échoue sur les serveurs distants posant problème : Active Directory RPC Services Check [serveurdistant] DsBindWithSpnEx() a ‚chou‚ avec l'erreur 1726, chec de l'appel de proc‚dure distante..
    •  TEST: Basic (Basc)
                        Erreurÿ: Pas de connexion DS RPC
                        Error: No WMI connectivity
                        [Error details: 0x80010002 (Type: HRESULT - Facility: RPC, Description: L'appel a ‚t‚ annul‚ par le filtre de messages.) - Connection to WMI server failed]
                        Aucun enregistrement d'h“te (A ou AAAA) n'a ‚t‚ trouv‚ pour
                        ce contr“leur de domaine

    ou  pour ce même test (Basc) : [Error details: 1726 (Type: Win32 - Description: chec de l'appel de proc‚dure distante.)]

    • en faisant les tests DNS du DCdiag depuis le site qui pose problème on a les mêmes erreurs mais du coup forcément pour tous les serveurs des autres sites, sauf un ou deux.


    tentatives de résolution

    Au départ le client m'a annoncé avoir fait des modification sur les registres des serveurs AD sur le site posant problème. Donc en pensant que ces serveurs aient des dysfonctionnement système, j'ai monté un nouveau serveur AD tout neuf

    => Pas de changement...

    Je me suis donc dit que c'était un problème firewall puisque tout le site est concerné.

    => En regardant dans l'outil du firewall, aucun paquet n'est bloqué, et tout est ouvert entre les DCs...

    En me renseignant sur l'erreur 1818, j'ai essayé sur mon nouveau serveur sur le site posant problème de créer cette DWORD : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\RPC Replication Timeout (mins) et de mettre 45min.

    http://social.technet.microsoft.com/wiki/contents/articles/11795.troubleshooting-ad-replication-error-1818-the-remote-procedure-call-was-cancelled.aspx

    => Rien ne change

    Du coup je me dis que l'AD/DNS devait être bien pourri sur les serveurs qui était présent sur ce site posant problème et que le nouveau serveur a récupérer des mauvaises infos...


    Dernière chose : Je remarque que le client a lui même créé les connexions entre les DCs dans sites et services Active Directory. tous les serveurs répliquent à tous les serveurs. Est ce bien bon ?

    De plus le diagnostique est horrible car le repadmin /replsum met bien 1 ou 2h à se terminer... Ce sur tous les serveurs AD.

    HELP please ;) Pouvez vous me guider pour la suite du diagnostique ?

    Merci d'avance
    jeudi 6 août 2015 07:48
    |

Réponses

  • Question
    Connectez-vous pour voter
    2
    Connectez-vous pour voter

    Tu peux créer des liens de site différents. Cela permet de tenir compte des capacité de chaque connexion et d'ajuster une notion de "cout" afin de privilégié certain lien et de ne pas saturer les liens les plus faibles. 

    Il est recommandé d'utiliser un autre DC comme DNS primaire plutôt que lui même. C'est d'autant plus vrai si tu as un autre DC sur le même site. Sur les anciennes versions il pouvait y avoir des problèmes liés au fait que le DC s'interroge en premier.

    Pour le site en question tu as essayé de rajouter un lien manuellement ? D'après ce que j'ai compris il n'est pas isolé. D'autres lien de réplication fonctionne ?

    • Proposé comme réponse Emile Supiot mercredi 19 août 2015 09:50
    • Marqué comme réponse Emile Supiot lundi 24 août 2015 09:49
    mardi 11 août 2015 16:00
    |
    Modérateur
  • Question
    Connectez-vous pour voter
    2
    Connectez-vous pour voter

    Bonjour mr Barth,

    J'ai pris des vacances d'où le temps de réponse.

    Du coup pour les quelques petites erreurs restantes cela venait de la solution Firewall Checkpoint. Je n'avais pas vu les paquets droppés dans un premier temps.

    En réanalysant en profondeur, le checkpoint bloquait tous les paquets RPC sortant d'un site en particulier avec la mention "TCP packet out of state". EN expliquant que le premier paquet d'une session TCP n'était pas un SYN... En fait le checkpoint n'aime pas trop les allocations dynamiques de ports TCP...

    Résolution : utilisation dans la règle d'ouverture de ports entre les DC du service ALL_DCE_RPC prévu depuis les nouvelle versions à cet effet. Cela ne suffisait pas, un technicien checkpoint niveau 3 à modifier en ligne de commande le fichier de définition du service DCE_RPC sur le checkpoint. Puis après compilation tout fonctionne. Problème checkpoint donc.

    Voilà en espérant que cela serve pour d'autres.

    Bonne journée,

    • Marqué comme réponse shinobitom jeudi 27 août 2015 12:43
    jeudi 27 août 2015 12:43
    |

Toutes les réponses

  • Question
    Connectez-vous pour voter
    1
    Connectez-vous pour voter

    Bonjour,

    Sagit-il de Windows Server 2008 ou bien 2012 ?

    Cordialement

    Emile

    Votez! Appel à la contribution TechNet Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.


    vendredi 7 août 2015 07:45
    |
  • Question
    Connectez-vous pour voter
    2
    Connectez-vous pour voter

    Bonjour,

    C'est du 2012 pour 80% des DC (c'est pour ça que j'ai placé le sujet ici) et 20% en 2008r2.

    Mais le niveau fonctionnel des controleurs et DC est en 2008r2.

    DU coup au bout d'une semaine de galère une solution a pu être trouvé grâce à deux autres tickets créés sur ce site :

    https://social.technet.microsoft.com/Forums/fr-FR/312a1a60-d4b6-4d4d-bfc2-eb03cfeec322/ad-les-serveurs-dpromu-restent-dans-la-console-site-et-service?forum=windowsserver8fr
    https://social.technet.microsoft.com/Forums/fr-FR/529327e6-c56b-419b-aafa-c9345b6e2610/ad-revoir-la-topologie-de-rplication?forum=windowsserver8fr

    Par contre je ne comprends pas entre 3 sites différents (entre eux uniquement) j'ai encore l'erreur de réplication 58 dans le repadmin /replsum... Alors que la communication avec les autres sites est niquelle.

    D'après AD replication status tool, toutes les partitions sont bien syncrhonisées sur les DC en question donc j'imagine que la réplication s'est faite comme il faut par les liens de secours. Mais bon j'aimerai bien faire disparaitre l'erreur... C'est la dernière sur les 20 que j'avais.

    Merci d'avance !

    lundi 10 août 2015 14:30
    |
  • Question
    Connectez-vous pour voter
    2
    Connectez-vous pour voter

    Tu as vérifié la conf IP de ses DC ? Quuel DNS primaire et secondaire ? Quel partenaire de réplication ? tester la résolution de nom dns des partenaires ?

    Sinon crée un utilisateur sur un autre site, tu veras très vite le résultat.

    Si tu as des liens de réplications qui ne fonctionne pas supprime les et recrée des autres, pour éviter qu'une partie soit isolée. Attention quand tu crée un lien de site tu le crée sur un DC et il doit être en mesure de répliquer l'info ) son  partenaire (sinon erreur contexte de nommage ... ). Le lien peut mettre un certain temps à apparaître sur le partenaire ) cause de la latence de réplication inter site.

    Tu peux aussi essayer d'utiliser le vérificateur de cohérence de la topologie de réplication

    lundi 10 août 2015 22:03
    |
    Modérateur
  • Question
    Connectez-vous pour voter
    1
    Connectez-vous pour voter

    Merci pour ta réponse.


    Oui j'ai tout vérifié niveau carte réseau sur tous les DCs. Tout est valide.

    J'ai même fait un coup de dnslint /ad /s localhost sur tous les serveurs et tous arrivent à résoudre tous les GUID.

    Par contre la question que je me posais à ce niveau c'est que j'ai laissé le DNS local en primaire. Par exemple sur le DC 192.168.0.10, le DNS primaire est 192.168.0.10. Il me semble qu'il faut le mettre en secondaire non ? Quel est le risque ?


    Oui le vérificateur de cohérence a été utilisé. Pour un DC qui a le souci, le repadmin /kcc tourne encore depuis 3 jours alors que ça prend 10min max pour les serveurs sur lesquels ça fonctionne bien.

    Même problème en passant par sites et services en faisant "vérifier la topologie" à partir de l'ISTG.


    Et oui j'ai supprimé et recréé ces liens. Même soucis. Je vais avoir de temps en temps lors du repadmin /showrepl :

    ******* Avertissement : une erreur a empêché le vérificateur de cohérence de données d'ajouter ce lien de réplica.


    Et toujours cette erreur 58 malgré tout ça !


    Concernant les liens de sites je n'en ai pas créé. En fait tout est toujours dans le lien de site par défaut "DEFAULTIPSITELINK". Vaut il mieux utiliser des liens de sites différents ? Par exemple :

    • un lien de site qui relie les sites A au B
    • un autre lien de site qui relie les sites A au C
    • un autre lien de site qui relie les sites B au C
    • ...


    En fait actuellement tous sites peuvent communiquer par "DEFAULTIPSITELINK". Après je gère les liaisons entre les sites par les connexions dans la partie NTDS Settings des serveurs. Peut être n'est ce pas la bonne pratique ?


    Pour ce qui est du test de création d'un utilisateur, ça marche il se réplique car ça passe par d'autres liens.

    Donc en soit c'est pas très grave on est plus dans la même situation dans laquelle j'avais créé ce ticket (grâce à toi d'ailleurs, merci !). Mais bon maintenant j'aimerais vraiment mettre au propre et supprimer toutes les petites erreurs restantes.


    Merci d'avance


    mardi 11 août 2015 14:53
    |
  • Question
    Connectez-vous pour voter
    2
    Connectez-vous pour voter

    Tu peux créer des liens de site différents. Cela permet de tenir compte des capacité de chaque connexion et d'ajuster une notion de "cout" afin de privilégié certain lien et de ne pas saturer les liens les plus faibles. 

    Il est recommandé d'utiliser un autre DC comme DNS primaire plutôt que lui même. C'est d'autant plus vrai si tu as un autre DC sur le même site. Sur les anciennes versions il pouvait y avoir des problèmes liés au fait que le DC s'interroge en premier.

    Pour le site en question tu as essayé de rajouter un lien manuellement ? D'après ce que j'ai compris il n'est pas isolé. D'autres lien de réplication fonctionne ?

    • Proposé comme réponse Emile Supiot mercredi 19 août 2015 09:50
    • Marqué comme réponse Emile Supiot lundi 24 août 2015 09:49
    mardi 11 août 2015 16:00
    |
    Modérateur
  • Question
    Connectez-vous pour voter
    2
    Connectez-vous pour voter

    Bonjour mr Barth,

    J'ai pris des vacances d'où le temps de réponse.

    Du coup pour les quelques petites erreurs restantes cela venait de la solution Firewall Checkpoint. Je n'avais pas vu les paquets droppés dans un premier temps.

    En réanalysant en profondeur, le checkpoint bloquait tous les paquets RPC sortant d'un site en particulier avec la mention "TCP packet out of state". EN expliquant que le premier paquet d'une session TCP n'était pas un SYN... En fait le checkpoint n'aime pas trop les allocations dynamiques de ports TCP...

    Résolution : utilisation dans la règle d'ouverture de ports entre les DC du service ALL_DCE_RPC prévu depuis les nouvelle versions à cet effet. Cela ne suffisait pas, un technicien checkpoint niveau 3 à modifier en ligne de commande le fichier de définition du service DCE_RPC sur le checkpoint. Puis après compilation tout fonctionne. Problème checkpoint donc.

    Voilà en espérant que cela serve pour d'autres.

    Bonne journée,

    • Marqué comme réponse shinobitom jeudi 27 août 2015 12:43
    jeudi 27 août 2015 12:43
    |
  • Question
    Connectez-vous pour voter
    1
    Connectez-vous pour voter

    Bonjour,

    Merci beaucoup de votre retour pour la communauté !

    Cordialement,

    Emile

    Votez! Appel à la contribution TechNet Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    jeudi 27 août 2015 13:01
    |