locked
mstsc.exe qui se connecte en TCP port 80 vers cds18.par9.msecn.net/94.245.70.23 RRS feed

  • Discussion générale

  • Bonjour,

    nous avons une infra RDS en place et avons mis en place des bureau RDP complets à nos utilisateurs accessibles depuis des postes de travail XP SP3 ou encore des XPe / WYSE.

    Nous avons installé sur les poste la dernière version du client RDP (6.1.7600) et activé le SSO avec CredSSP.

    Jusque là tout marche bien, sauf que certains utilisateurs, au démarrage de la connexion RDP, la phase de négociation de sécurité est anormalement longue (~20/30s).

    Après avoir analysé le pb, il s'avère qu'une connexion est tentée depuis le process mstsc.exe vers des serveurs Microsofts: cds18.par9.msecn.net/94.245.70.23

    Comme les postes n'ont pas d'accès direct à Internet (mais via proxy) un timeout arrive et la connexion s'établie.

    Je souhaiterain empêcher une fois pour toute cet effet de bord du mstsc.exe et surtout comprendre pourquoi il tente une telle connexion chez Microsoft???

    Merci à tous pour votre aide, ce pb est extrêmement pénalisant (semble nous générer des coupures de session par la suite).

      Yann

    jeudi 14 octobre 2010 17:42

Toutes les réponses

  • Bonjour Yann,

    Je vous propose de visite ce lien : Troubleshooting General Remote Desktop Error Messages

    Cordialement

     


    Anouar KETAT
    My Blog: Directory Services
    Knowledge is only power if it's shared
    vendredi 15 octobre 2010 07:57
  • Merci pour le lien mais que c'est pauvre en informations!

    Exemple de solution à un message d'erreur:

    "Solution:  Try connecting to the remote computer again. If you receive the same message, contact the server administrator. "

    Nous sommes des professionnels de l'informatique et avons besoin de réponses CONCRETES de Microsoft, un simple essayez de vous reconnecter ou contactez votre admin système n'est pas suffisant sur le technet!

    C'est une réponse qu'on ferait à un utilisateur lambda, NOUS attendons plus, le technet n'est pas destiné à nos utilisateurs finaux!

    Bref je sèche toujours...

    vendredi 15 octobre 2010 09:38
  • Bonjour,

    il est possible qu'il cherche a valider l'authenticité d'un certificat


    www.alexwinner.com
    vendredi 15 octobre 2010 11:36
  • Effectivement c'est une piste que j'ai tenté d'éllucider mais en vain...

    Les accès à Internet s'effectuent aléatoirement entre les serveurs MSECN et AKAMAI.

    Peut-être aussi une tentative de MAJ (Windows Update?) le process source est souvent mstsc.exe mais parfois lsass.exe

    vendredi 15 octobre 2010 13:10
  • Bonjour,

    Merci de nous tenir au courant avec la résolution de votre problème.

    Cordialement


    Anouar KETAT
    My Blog: Directory Services
    Knowledge is only power if it's shared
    vendredi 22 octobre 2010 10:47
  • Bonjour,

     

    Je suis admin sys et réseau pour mon établissement public.

    Ici pas de SSO, de clients légers ou autre... Un domaine AD, des PC en XP SP3, et un proxy ISAServer avec authentification.

    On force les différents navigateurs en parc à se connecter à internet via ce proxy, les accès directs sont filtrés par notre parefeu d'entrée. Nous utilisons un script de configuration automatique pour l'emploi du proxy, cette configuration est déployée sur les PC via GPO (pas encore de DHCP chez nous).

    Malgré ces points, je constate également des tentatives de connexions de nombreux PC de mon parc vers des machines du domaine msecn.net via le port 80, sans passer par le proxy du système.

    Je crois avoir établi une corrélation entre ces postes et la présence au démarrage de ces postes/à l'ouverture de session de msnmgr.exe (le client MSN installé par défaut sur chaque windows). Je n'ai pas pu confirmer ça à 100%, mais cela me semble une piste sérieuse.

    Je n'ai pas non plus insisté sur ce point, mais il semblerait que les sessions soient légèrement plus lentes à s'ouvrir sur ces postes que sur les postes n'ayant pas ce client au démarrage.

    J'ai beaucoup de mal à comprendre pourquoi ces connexions directes alors qu'un proxy est déclaré au niveau du navigateur IE. Peut être est-ce que l'utilisation d'un script de configuration automatique n'est pas adaptée pour msnmgr, peut être est-ce que le lancement de msnmgr intervient trop tôt par rapport à la configuration via GPO des navigateurs lors de l'ouverture de session...

    Bref, si quelqu'un a de l'info sur le sujet, je suis preneur.

    Merci d'avance.

     

    Julien

     

    vendredi 3 décembre 2010 14:45