Was sind die Gründe für das Fehlschlagen lokaler Windows-Named-Pipes?

Ich habe den ganzen Tag hart daran gearbeitet und stecke fest. Heute Morgen haben mich unsere asiatischen Kollegen angerufen, weil ein SolidWorks-Add-In für unser Produktdatenmanagementsystem nicht mit der lokalen Hauptanwendung kommunizieren konnte. Das Problem betrifft Endbenutzercomputer in einer Windows-Domäne. Wir haben die Dienstprogramme READPIPE und MAKEPIPE aus der SQL Server-Toolbox verwendet, um herauszufinden, dass das zugrunde liegende Problem die Windows-Pipe-Funktion war.

Das MAKEPIPE-Util erstellt eine Pipe und wartet auf einen Client. Das READPIPE-Dienstprogramm gibt Folgendes zurück: "Pipe konnte nicht geöffnet werden. Status 53." Laut http://support.microsoft.com/kb/110905 bedeutet dies, dass der Netzwerkname nicht gefunden wurde. Auf meinem lokalen Computer senden die Pipes ohne Probleme ein "Hallo" von READPIPE an MAKEPIPE.
Der Serverprozess, der Named-Pipes aktiviert, wird ausgeführt.
Die Einstellungen unter HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Lanmanserver \ Parameters sehen in Ordnung aus. Keine Pipes-Firewall-Einstellung.
Das Problem betrifft einige Benutzer, aber nicht alle. Wir haben keine Änderungen an den Domänengruppen vorgenommen, mit Ausnahme einiger Netzwerkfreigabegruppen.
Ich habe mich als Administrator angemeldet und trotzdem funktionieren die Pipes nicht.

Jede Hilfe wird geschätzt! Vielen Dank.

windows pipe windows-domain

— user152700
quelle

Können die betroffenen Benutzer eine Verbindung zu normalen Dateifreigaben auf dem betreffenden Server herstellen?

— Harry Johnston

Derzeit gibt es keine Probleme mit Aktien. Dies ist kein Server / Client-Problem. Beide Prozesse befinden sich auf demselben Computer.

— user152700

Wenn Sie das als READPIPE und MAKEPIPE an einem betroffenen Computer als Administrator angemeldete Problem reproduzieren, welche genauen Befehle verwenden Sie? (Bitte bearbeiten Sie Ihren Beitrag, um sie einzuschließen, anstatt sie in einen Kommentar zu setzen.)

— Harry Johnston

Danke für deine Unterstützung. Dies war eine schwierige Frage, und ich werde die Lösung hier dokumentieren.

— user152700

Benötigte 1,5 Tage, um es für jeden Fall herauszufinden. Hier zur Dokumentation.

Symptome

Drag & Drop in Anwendungen funktioniert nicht.
Die Interprozesskommunikation, z. B. zwischen Haupt-App und Add-Ins, funktioniert nicht.

Ursachen / Hintergrund

Die Interprozesskommunikation wird für einige Apps über Windows-Named Pipes implementiert (nicht zu verwechseln mit UNIX-Pipes). Siehe MSDN-Dokumentation: http://msdn.microsoft.com/en-us/library/aa365590.aspx

Es kann verschiedene Ursachen dafür geben, dass die Windows-Namensleitungen nicht funktionieren. Um zu überprüfen, ob die Rohre die Ursache des Problems sind, können die Tools MAKEPIPE und READPIPE verwendet werden. Dieser KB-Artikel beschreibt das Testverfahren: http://support.microsoft.com/kb/68941 Der Sysinternals-Tool-Prozess-Explorer kann auch hilfreich sein, um festzustellen, welche Pipes derzeit geöffnet sind. Verwenden Sie die Option "Suchen -> Handle oder DLL suchen ..." und geben Sie das Muster "\ Device \ NamedPipe \" ein. Es zeigt Ihnen, welche Prozesse welche Rohre offen haben. http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Fehlerbehebung

Ursache 1: Die Anwendung wird von der Pipes-Firewall blockiert

Windows kann Anwendungen daran hindern, Named Pipes zu verwenden. Diese Firewall ist normalerweise nicht aktiviert und wird über die Registrierung konfiguriert. Den MS-Support-Artikel finden Sie hier: http://support.microsoft.com/kb/925890 . Stellen Sie sicher, dass die Pipes-Firewall nicht aktiviert ist, oder fügen Sie Keytech und alle Add-Ins zur Liste der zulässigen Anwendungen hinzu.

Ursache 2: Der Dienst zur gemeinsamen Nutzung von Dateien und Druckern ist nicht aktiviert.

Named Pipes werden durch den Prozess aktiviert, der auch die Datei- und Druckerfreigabe steuert. Überprüfen Sie, ob dieser Prozess mit dem Windows-Diensttool ausgeführt wird. Der Dienstname wird in der Diensteliste als "Server" angezeigt. Der Dienstname lautet LanmanServer und die EXE-Datei lautet C: \ Windows \ system32 \ svchost.exe -k netsvcs

Ursache 3: Die Windows-Firewall blockiert LanmanServer

Die Windows-Firewall kann Named Pipes blockieren, auch wenn sie nur für die Kommunikation zwischen Prozessen auf demselben Computer verwendet werden. Insbesondere Domänen- und lokale Firewallregeln können einen Konflikt verursachen. Zwei Einträge in der Liste "Zulässige Windows-Firewall-Programme" weisen auf einen Konflikt hin. In den meisten Fällen kann dieses Problem mithilfe des Fensters "Firewall-Status überprüfen" behoben werden. Wenn in diesem Fenster eine Option zum Festlegen der empfohlenen Firewall-Regeln angezeigt wird, können die Pipes mit dieser Option häufig entsperrt werden. In Kombination mit Domänen-Firewall-Regeln ist es manchmal erforderlich, den PC zuerst von der Domäne zu trennen und dann den Datei- und Druckerfreigabedienst zuzulassen.

— user152700
quelle

Ursache 1) Die Pipes-Firewall wirkt sich nur auf den Remotezugriff auf Named Pipes aus. Beachten Sie jedoch, dass das Herstellen einer Verbindung zu einer Named Pipe unter Verwendung von \\ Maschinenname \ Pipename wahrscheinlich als Remotezugriff gilt, selbst wenn Maschinenname der lokale Computer ist.

— Harry Johnston

Ursache 2) Ebenso ist die Datei- und Druckerfreigabe nur für den Remotezugriff auf Named Pipes erforderlich. Auch hier zählt \\ Maschinenname \ Pipename wahrscheinlich als Fernzugriff für diesen Zweck.

— Harry Johnston

Ursache 3) Die Windows-Firewall sollte lokale Verbindungen nicht blockieren können, selbst wenn \\ Maschinenname \ Pipename verwendet wird. Wenn Sie sich jedoch in einer Domäne befinden und die Windows-Firewall stark falsch konfiguriert ist, sind möglicherweise häufigere Probleme aufgetreten, die möglicherweise mit der Authentifizierung zusammenhängen.

— Harry Johnston

@HarryJohnston Welche Art der Authentifizierung könnte blockiert werden? Wie hierServiceHost.Authentication beschrieben ?

— iCantSeeSharp

Wenn Sie sich in einer Domäne befinden und Ihr Netzwerkzugriff auf die Domänencontroller von der Windows-Firewall blockiert wird (oder aus einem anderen Grund), können Sie sich möglicherweise nicht authentifizieren. Das sollte den lokalen Pipe-Zugang nicht wirklich beeinflussen, aber YMMV.

— Harry Johnston