none
Connection broker inaccessible lors de l'ajout d'une deuxième carte réseau RRS feed

  • Question

  • Bonjour,

    Sur un serveur 2016 virtualisé, membre d'un domaine, j'ai un RDS qui tourne depuis des mois sans soucis.

    Pour des besoins d'accès a un vlan de backup, je lui ajoute une carte réseau.

    Lorsque cette nouvelle interface réseau est désactivée, je peux via le serveur manger accéder au RDS et ses configs, et les clients peuvent se connecter.

    LOrsque j'active cette interface, je n'arrive plus a accéder au RDS service dans le serveur manager (j'ai un  "connection to connection broker ..." sans réponse) et les cleints réseaux n'ont plus accè a a leur sessions terminales.

    Une idée ???


    mardi 3 septembre 2019 03:45

Toutes les réponses

  • Bonjour,

    Je pense que lors de l'activation de la 2nde carte réseau, le nom DNS du serveur est publié dans le DNS de l'Active Directory et que les machines tentent du coup de joindre le serveur via l'IP de la seconde carte réseau.

    Dans les propriétés de la 2nde carte, TCP/IP v4, Avancé, Onglet DNS, modifiez le suffixe DNS de la connexion pour un nom de domaine dédié au backup (ex: backup.monlan.intra).

    Comme cela, la carte ne s'enregistrera plus dans le DNS.

    Pour vérifier le problème, activez la carte réseau, et allez sur le DNS à partir d'un contrôleur de domaine : vous devriez voir apparaître la "mauvaise" IP !


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    http://snsv.consulting

    Blog : http://sylvaincoudeville.fr

    mardi 3 septembre 2019 06:12
  • Bonjour, 

    Vous pouvez forcer l'utilisatation de la prémier interface on modifiant l'ordre:

    https://www.windowscentral.com/how-change-priority-order-network-adapters-windows-10


    Vote or mark as answer if you think useful

    mardi 3 septembre 2019 10:12
  • Déjà merci pour cette piste ... La config de ma deuxième carte n'a ni gateway, ni DNS. par acquis de conscience j'ai quand même essayer votre solution mais cela ne change rien.

    Dès que j'active la deuxième carte dans le serveur manager j'ai toujours "Connecting to connexion broker ...."

    Si vous avez une autre piste.

    fr

    mardi 3 septembre 2019 16:02
  • Merci aussi de votre réponse, c'est sur le serveur 2016 que j'ai le soucis. J'ai quand même tenté de prioritiser les cartes, même message et même résultat.

    fr

    mardi 3 septembre 2019 16:03
  • Bonjour,

    Avez-vous configuré votre RDCB pour un mode High Available ? Si oui, vérifiez que vous avez toujours accès à la base de données lorsque la 2nde carte est activée.

    Pouvez-vous nous confirmer que le plan d'adressage de la 2nde carte est bien différent de celui de la première?

    Enfin, que disent les journaux du serveur RDS, et plus spécifiquement le journal "TerminalServices-SessionBroker" lorsque la 2nde carte est activée?


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    http://snsv.consulting

    Blog : http://sylvaincoudeville.fr

    mercredi 4 septembre 2019 06:28
  • Merci,

    rien n'est configuré pour le high availability, et la seconde carte a bien un adressge différent de la carte principale (la principale sur le réseau 192.168.2.0 et la carte additionnelle sur le 192.168.3.0, celle ci n'ayant ni gateway ni dns)

    Je regardes dans les journaux

    merci

    mercredi 4 septembre 2019 08:41
  • Dans les journaux rien de transcendant quand je mets l'interface en ligne.

    Dans un journal j'ai de temps en temps : Current async message was dropped by async dispatcher, because there is a new message which will override the current one.

    Mais la ligne qui suit montre : Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational

    Mais ce message n'est pas lié au moment ou j'active la deuxième interface.

    merci

    mercredi 4 septembre 2019 19:52
  • Dans les journaux rien de transcendant quand je mets l'interface en ligne.

    Dans un journal j'ai de temps en temps : Current async message was dropped by async dispatcher, because there is a new message which will override the current one.

    Mais la ligne qui suit montre : Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational

    Mais ce message n'est pas lié au moment ou j'active la deuxième interface.

    merci

    Et au moment d'une connexion RDS? Aucun message ?

    Pouvez-vous vérifier que du côté du client, la résolution de noms de votre broker ne change pas d'IP?


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    http://snsv.consulting

    Blog : http://sylvaincoudeville.fr

    jeudi 5 septembre 2019 06:04
  • Bonjour,

    dans les logs aucuns messages d’erreur ou d'avertissement. Coté client je suis certains que c'est bon, on attaque le RDPB via l'IP, qui est l'IP de la première carte réseau installée a l'origine.

    J'ai u peu difficile de faire des essais en pleine journée, car je coupe alors les connexions des users en prod. Je ne peux donc le faire que tôt le matin ou le soir.

    En tout cas c'est bien reproduisible, il suffit que je mette UP la deuxième carte pour ne plus avoir accès au manger du connexion broker et pour que les clients ne sachent plus se connecter.

    Merci de votre patience

    jeudi 5 septembre 2019 08:45
  • Dans le fonctionnement d'un Broker, le client se connecte au Broker, qui envoie un signal de redirection au client, basé sur le FQDN.

    Du coup, le client ne doit surtout pas être mis de côté dans le Troubleshooting.

    Pour le prochain set de test, il faudrait faire ceci :

    • Depuis le poste client : ping IP du Broker. nslookup FQDN et ping FQDN du point de terminaison (fqdn du RDS)
    • Depuis le serveur Broker/RDS : ipconfig /all, route print, nslookup FQDN, ping FQDN

    Dans tous les cas, c'est l'IP de la carte #1 qui doit répondre : si ce n'est pas le cas, il faut vérifier la résolution de noms.


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    http://snsv.consulting

    Blog : http://sylvaincoudeville.fr

    jeudi 5 septembre 2019 09:15
  • Bonjour, 

    Vous etez sur une plateforme Hyper-V ou Vmaware peut-etre il faut installer/mettre à jours les outils d'integrations.


    Vote or mark as answer if you think useful

    jeudi 5 septembre 2019 12:10
  • Rebonjour,

    J'avance un peu. Le ping répondais par une ipV6(::1), pourtant le protocole ipv6 est désactivé sur les deux cartes.

    Sur le serveur ou sont installé le broker, le host session, j'ai priorisé l'ipv4 avec les commandes :

    netsh interface ipv6 set prefix ::/96 60 3
    netsh interface ipv6 set prefix ::ffff:0:0/96 55 4

    Maintenant en local sur le serveur RDS, le ping sur l'ip4, le ping sur le FQDN et Nslookup répondent correctement.

    Les clients arrivent a se connecter en utilisant l'IP ou le nom et se connectent sur leur session.

    Par contre en local sur le serveur, il me reste le soucis suivant :

    Lorsque je démarre le server manager et navigue vers remote desktop service / overview dans le pannel de droite j'ai toujours : "Connecting to the RD connection server Broker ...", handicapant si je veux gérer les sessions etc ....

    Dans les events j'ai ceci ..

    User xx\xx will be logged on to the local redirector machine (assuming TS farm scenario) sending local ip address to the client in the redirection packet

    Ma question là .. Il y a un seul rds et un seul session host sur la même machine, la "redirection" est-elle normale

    Autre log

    RD connection broker succesfuly processed the connection request for user xx\xx. Redirection info : target name = data01

    Le nom de la cible est cohérent et resolvable

    Autre piste pour laquelle je n'ai pas d'explication je n'ai pas de loadbalancing configurer et je retrouve dans un log d'il y a 3 jours l'event suivant ...

    Connectiviy to the database was restored.All deployement services.... are running and the deployement is operational.

    Est-ce que la deuxième carte ne s'est pas inscrite dans cette base et est-ce possible que le manager n'arrive pas a se connecter a cause de cela ???

    jeudi 5 septembre 2019 16:00
  • Le server est virtualisé sur proxmox ... Quels sont ces outils d'intégrations ?

    merci

    jeudi 5 septembre 2019 16:01
  • Bonjour,

    Alors plusieurs points :

    • Pourquoi avoir installé le Broker si vous n'avez qu'un seul serveur RDS ?
      Le Broker est là pour faire de la répartition dans le cadre d'une ferme RDS.
      Si vous ne comptez pas ajouter de RDS au sein de la même collection, je vous suggère de retirer le Broker, ce qui simplifiera et allégera la configuration
    • Désactiver IPv6 n'est pas une bonne idée, car même si vous ne l'utilisez pas sur votre réseau, certains services Windows l'utilisent (vous l'avez d'ailleurs appris à vos dépends)
    • Pour éviter que Windows ne retourne ::1 quand vous le pinguez lui-même, dans le fichiers hosts, ajoutez une entrée "127.0.0.1    fqdn-du-serveur"
      Comme cela un ping sur le fqdn retournera 127.0.0.1 et non ::1
    • Réactivez IPv6

    Après cela, je pense que tout rentrera dans l'ordre, y compris le fonctionnement de ServerManager


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    http://snsv.consulting

    Blog : http://sylvaincoudeville.fr

    vendredi 6 septembre 2019 06:19
  • Re bonjour,

    Le broker parce qu'il est prévu d'ajouter un autre serveur d'ici un mois ou deux, donc cela me semble assez normal d'avoir essayé de prévoir l'infra en ce sens.

    Pour l'ipv6 je comprends l'argument qui est souvent discuté, mais sur un autre serveur similaire lors du setup du RDS l'installation du broker bloquait avec comme message que le remote powershell n'était pas disponible (alors qu'il l'était) et plusieurs post expliquaient une erreur semblable résolue en désactivant ipv6 (https://serverfault.com/questions/834014/disabling-ipv6-to-allow-rds-installation-whats-the-real-solution). Je reste convaincu que l'on contourne le problème en le désactivant.

    Le système fonctionne mais j'en suis toujours au point de départ lorsque j'active la deuxième carte :(

    merci en tout cas et si d'autres idées viennent ....

    dimanche 8 septembre 2019 05:52
  • Lorsque je démarre le server manager et navigue vers remote desktop service / overview dans le pannel de droite j'ai toujours : "Connecting to the RD connection server Broker ...", handicapant si je veux gérer les sessions etc ....

    Dans les events j'ai ceci ..

    Est-ce que vous avez le même problème si vous essayez de gérer depuis un autre serveur ?

    User xx\xx will be logged on to the local redirector machine (assuming TS farm scenario) sending local ip address to the client in the redirection packet

    Ma question là .. Il y a un seul rds et un seul session host sur la même machine, la "redirection" est-elle normale

    Oui, le broker redirige, c'est son job. Et il le fait qu'il y ait 1 seul ou plusieurs serveurs dans la ferme.

    Autre log

    RD connection broker succesfuly processed the connection request for user xx\xx. Redirection info : target name = data01

    Le nom de la cible est cohérent et resolvable

    Hum... "data01" : est-ce normal qu'il n'y ait pas le suffixe avec le nom de domaine ?
    Même si vous réussissez à résoudre "data01" depuis une machine, cela ne signifie pas forcément que le broker est en mesure de le faire, ou bien qu'il résolve convenablement ce nom.

    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    http://snsv.consulting

    Blog : http://sylvaincoudeville.fr

    lundi 9 septembre 2019 06:32
  • Bonjour,

    Je ne comprends pas l'intérêt de la seconde carte réseau.

    S'il y a besoin d’accès à un vlan de backup, on fait du routage. Avoir 2 carte réseau sur un serveur RDS c'est pas une conf standard et ne fait probablement pas partie des recommandation de MS donc je vous le déconseille.


    Merci de marquer comme reponses les interventions qui vous ont ete utile.


    • Modifié matteu31400 dimanche 15 septembre 2019 14:23
    dimanche 15 septembre 2019 14:17
  • Bonjour et merci.

    Effectivement le choix du routage pourrait être fait.

    Avoir un réseau dédicacé permet d'avoir aussi une bande passante dédicacée a plus haut débit vers un stockage, sur un réseau totalement isolé du monde extérieur ...

    merci

    mercredi 18 septembre 2019 06:37
  • Pour avancer, voici ce que j'ai constaté et ce qui semble avoir résolu mon soucis.

    En démarrant ma deuxième carte réseau (pas de gateway ni DNS configuré pour cette carte) j'ai remarqué que quand elle se connecte elle m'affiche "identifying ..." puis prends le non du réseau de la première carte. Alors qu'elle n'a rien dans sa config DNS. Dans ce cadre, le broker n'est plus accessible.

    Si je renseigne une valeur ip de DNS qui n'existe pas dans le réseau de backup, que je configure un suffixe DNS pour ce réseau, différent de celui utilisé sur la carte principale, tout revient dans l'ordre. Le server manger se connecte au broker ....

    Pour moi cela fonctionne ainsi.

    Merci a tous

    mercredi 18 septembre 2019 06:47
  • Pour avancer, voici ce que j'ai constaté et ce qui semble avoir résolu mon soucis.

    En démarrant ma deuxième carte réseau (pas de gateway ni DNS configuré pour cette carte) j'ai remarqué que quand elle se connecte elle m'affiche "identifying ..." puis prends le non du réseau de la première carte. Alors qu'elle n'a rien dans sa config DNS. Dans ce cadre, le broker n'est plus accessible.

    Si je renseigne une valeur ip de DNS qui n'existe pas dans le réseau de backup, que je configure un suffixe DNS pour ce réseau, différent de celui utilisé sur la carte principale, tout revient dans l'ordre. Le server manger se connecte au broker ....

    Pour moi cela fonctionne ainsi.

    Merci a tous

    On en revient à un problème de résolution de noms interne sur le serveur.

    Comme je l'avais suggéré, mettez un suffixe DNS différent sur la seconde carte (backup.monlan.intra) pour que Windows ne l'utilise pas pour une résolution de nom du FQDN principal.


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    WWW : http://snsv.consulting | Blog : http://sylvaincoudeville.fr

    "Aléatoire" et "Mystérieux" sont des qualificatifs inventés par l'Homme pour éviter de dire qu'il n'a pas trouvé la root cause du problème...

    mercredi 18 septembre 2019 06:54