Quelles sont les raisons de l'échec des canaux nommés Windows locaux?

14

J'ai travaillé dur sur celui-ci toute la journée et je suis coincé. Ce matin, nos collègues asiatiques m'ont appelé parce qu'un complément SolidWorks pour notre système de gestion des données produit ne pouvait pas communiquer avec l'application principale locale. Le problème affecte les ordinateurs des utilisateurs finaux dans un domaine Windows. Nous avons utilisé les utilitaires READPIPE et MAKEPIPE de la boîte à outils du serveur SQL pour comprendre que le problème sous-jacent était la fonctionnalité de canal Windows.

  • L'utilitaire MAKEPIPE crée un canal et attend un client. L'utilitaire READPIPE renvoie: "Impossible d'ouvrir le canal. Statut 53." Selon http://support.microsoft.com/kb/110905, cela signifie que le nom du réseau est introuvable. Sur mon ordinateur local, les tuyaux envoient un "bonjour" de READPIPE à MAKEPIPE sans problème.
  • Le processus serveur qui active les canaux nommés est en cours d'exécution.
  • Les paramètres sous HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Lanmanserver \ Parameters semblent corrects. Aucun paramètre de pare-feu de tuyaux.
  • Le problème affecte certains utilisateurs mais pas tous. Nous n'avons apporté aucune modification aux groupes de domaine, à l'exception de certains groupes de partage réseau.
  • Je me suis connecté en tant qu'administrateur et les tuyaux ne fonctionneront toujours pas.

Toute aide est appréciée! Je vous remercie.

windows pipe windows-domain user152700
la source
Les utilisateurs concernés peuvent-ils se connecter à des partages de fichiers ordinaires sur le serveur en question?
Harry Johnston
Il n'y a actuellement aucun problème avec les actions. Ce n'est pas un problème de serveur / client. Les deux processus sont sur le même ordinateur.
user152700
Lorsque vous reproduisez le problème, connecté à un ordinateur affecté en tant qu'administrateur, avec READPIPE et MAKEPIPE, quelles sont les commandes exactes que vous utilisez? (Veuillez modifier votre message pour les inclure plutôt que de les mettre dans un commentaire.)
Harry Johnston
Merci pour votre aide. Ce fut difficile et je vais documenter la solution ici.
user152700

Réponses:

12

Besoin de 1,5 jours pour le comprendre pour chaque cas. Ici pour la documentation.

Symptômes

  • Le glisser-déposer dans les applications ne fonctionne pas.
  • La communication interprocessus, par exemple entre l'application principale et les compléments, ne fonctionne pas.

Causes / antécédents

La communication interprocessus est implémentée pour certaines applications via des canaux nommés Windows (à ne pas confondre avec les canaux de style UNIX). Voir la documentation MSDN: http://msdn.microsoft.com/en-us/library/aa365590.aspx

Il peut y avoir différentes causes pour que les canaux de noms Windows ne fonctionnent pas. Pour vérifier que les tuyaux sont à l'origine du problème, les outils MAKEPIPE et READPIPE peuvent être utilisés. Cet article de la base de connaissances décrit la procédure de test: http://support.microsoft.com/kb/68941 L'explorateur de processus de l'outil Sysinternals peut également être utile pour rechercher les canaux actuellement ouverts. Utilisez l'option "Rechercher -> Rechercher la poignée ou DLL ..." et entrez le modèle "\ Device \ NamedPipe \". Il vous montrera quels processus ont quels tuyaux s'ouvrent. http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Dépanner

Cause 1: l'application est bloquée par le pare-feu Pipes

Windows peut empêcher les applications d'utiliser des canaux nommés. Ce pare-feu n'est normalement pas activé et est configuré via le registre. Voir l'article de support MS ici: http://support.microsoft.com/kb/925890 . Vérifiez que le pare-feu des tuyaux n'est pas activé ou ajoutez Keytech et tous les compléments à la liste des applications autorisées.

Cause 2: le service de partage de fichiers et d'imprimantes n'est pas activé.

Les canaux nommés sont activés par le processus qui contrôle également le partage de fichiers et d'imprimantes. Vérifiez que ce processus s'exécute à l'aide de l'outil Services Windows. Le nom du service apparaît comme «Serveur» dans la liste des services. Le nom du service est LanmanServer et l'EXE est C: \ Windows \ system32 \ svchost.exe -k netsvcs

Cause 3: le pare-feu Windows bloque LanmanServer

Le pare-feu Windows peut bloquer les canaux nommés même lorsqu'ils ne sont utilisés que pour la communication interprocessus sur la même machine. En particulier, les règles de pare-feu de domaine et locales peuvent provoquer un conflit. Deux entrées dans la liste «Programmes autorisés du pare-feu Windows» indiquent un conflit. Dans la plupart des cas, ce problème peut être résolu en utilisant la fenêtre «Vérifier l'état du pare-feu». Si cette fenêtre affiche une option pour définir les règles de pare-feu recommandées, les tuyaux peuvent souvent être débloqués à l'aide de cette option. En combinaison avec les règles de pare-feu de domaine, il est parfois nécessaire de déconnecter d'abord le PC du domaine, puis d'autoriser le service de partage de fichiers et d'imprimantes.

user152700
la source
3
Cause 1) Le pare-feu des canaux affecte uniquement l'accès à distance aux canaux nommés. Notez, cependant, que la connexion à un canal nommé à l'aide de \\ nom_machine \ nom_pipe compte probablement comme un accès distant, même si le nom de la machine est la machine locale.
Harry Johnston
3
Cause 2) De même, le partage de fichiers et d'imprimantes n'est requis que pour l'accès à distance aux canaux nommés. Encore une fois, \\ machinename \ pipename compte probablement comme un accès distant à cet effet.
Harry Johnston
Cause 3) Le pare-feu Windows ne devrait pas être en mesure de bloquer les connexions locales, même si vous utilisez \\ machinename \ pipename. Cependant, si vous êtes dans un domaine et que le pare-feu Windows est mal configuré, vous avez peut-être rencontré des problèmes plus répandus, peut-être liés à l'authentification.
Harry Johnston
@HarryJohnston Quel type d'authentification pourrait-il être bloqué? Comme ServiceHost.Authenticationdécrit ici ?
iCantSeeSharp
Si vous êtes dans un domaine et que votre accès réseau aux contrôleurs de domaine est bloqué par le pare-feu Windows (ou pour une autre raison), vous ne pourrez peut-être pas vous authentifier. Cela ne devrait pas vraiment affecter l'accès au canal local, mais YMMV.
Harry Johnston