142090
26.12.2019
10886
8
0
Anmeldefehler wandert durch RDP Farm
Moin Jungs,
wir haben hier einen Pool aus 3 (virtualisierten) Terminalservern (Win2012) und haufenweise Igel ThinClients (Igel Universal Desktop Client in unterschiedlichen Versionen). Läuft eigentlich auch alles recht performant und zuverlässig, bis auf einen Standort. Die User melden, daß sie stundenlang versuchen sich anzumelden (RDP), immer wieder die Meldung "Server unreachable" kassieren bis Sie dann irgendwann anmelden können.
Also spiegel ich mir einen der Clients und probier rum: Wenn ich mit rdppool... verbinden möchte dauert es geraume Zeit und mal komm ich durch mal nicht. Wenn ich stattdessen versuche mich direkt per IP mit den einzelnen Terminalservern zu verbinden passiert folgendes: Auf einen der Server komme ich sofort und direkt rauf, bei zweien erscheint nach etwas Wartezeit wieder "Server unreachable". Leider wandert das, scheinbar kann man sich nur auf dem Server anmelden, der einem eh vom gateway zugewiesen würde.
Ich tippe mal die Fehlermeldung vom Screenshot ab:
...[9240:9242]Error[freerdp.core.transport] BIO-should_retry returned a system error 32: Broken pipe
...[9240:9242]Error[freerdp.core.nego] Protocol Security Negotiation Failure
...[9240:9242]Error[freerdp.core]freerdp_set_last_error
ERRCONNECT_SCURITY_NEGO_CONNECT_FAILED [0x2000C]
Das liest sich ja irgendwie so, als wenn der Terminalserver zu scharf gestellt ist. Dann würden aber die anderen Uraltclients nicht reinkommen. Ich habe auch Hinweise gefunden, daß eine bestimmte Version von freerdp Probleme mit der Anmeldung auf Win2012 hat. Aber ich kann mich ja auf einem der Server anmelden (je nach Tageszeit wechselnd). Scheint also ein Gateway Problem zu sein, das nur bei einigen Clients auftritt, auf denen UDC 10.0x.xx läuft.
Kommt das jemandem bekannt vor?
wir haben hier einen Pool aus 3 (virtualisierten) Terminalservern (Win2012) und haufenweise Igel ThinClients (Igel Universal Desktop Client in unterschiedlichen Versionen). Läuft eigentlich auch alles recht performant und zuverlässig, bis auf einen Standort. Die User melden, daß sie stundenlang versuchen sich anzumelden (RDP), immer wieder die Meldung "Server unreachable" kassieren bis Sie dann irgendwann anmelden können.
Also spiegel ich mir einen der Clients und probier rum: Wenn ich mit rdppool... verbinden möchte dauert es geraume Zeit und mal komm ich durch mal nicht. Wenn ich stattdessen versuche mich direkt per IP mit den einzelnen Terminalservern zu verbinden passiert folgendes: Auf einen der Server komme ich sofort und direkt rauf, bei zweien erscheint nach etwas Wartezeit wieder "Server unreachable". Leider wandert das, scheinbar kann man sich nur auf dem Server anmelden, der einem eh vom gateway zugewiesen würde.
Ich tippe mal die Fehlermeldung vom Screenshot ab:
...[9240:9242]Error[freerdp.core.transport] BIO-should_retry returned a system error 32: Broken pipe
...[9240:9242]Error[freerdp.core.nego] Protocol Security Negotiation Failure
...[9240:9242]Error[freerdp.core]freerdp_set_last_error
ERRCONNECT_SCURITY_NEGO_CONNECT_FAILED [0x2000C]
Das liest sich ja irgendwie so, als wenn der Terminalserver zu scharf gestellt ist. Dann würden aber die anderen Uraltclients nicht reinkommen. Ich habe auch Hinweise gefunden, daß eine bestimmte Version von freerdp Probleme mit der Anmeldung auf Win2012 hat. Aber ich kann mich ja auf einem der Server anmelden (je nach Tageszeit wechselnd). Scheint also ein Gateway Problem zu sein, das nur bei einigen Clients auftritt, auf denen UDC 10.0x.xx läuft.
Kommt das jemandem bekannt vor?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 529845
Url: https://administrator.de/forum/anmeldefehler-wandert-durch-rdp-farm-529845.html
Ausgedruckt am: 15.04.2025 um 15:04 Uhr
8 Kommentare
Neuester Kommentar
Moin,
Prbier einmal die Parameter auf, ob du damit das Problem eingrenzen kannst. Es kann sicherlich nicht schaden auf den Thinclients das neuste OS zu installieren.
Ansonsten wird es mit einem Support Ticket bei IGEL wahrscheinlich sowieso nichts.
Gruß,
Dani
Kommt das jemandem bekannt vor?
Es gibt bzw. gab ein [https://github.com/FreeRDP/FreeRDP/issues/2862 Issue auf GitHub dazu bei FreeRDP.Prbier einmal die Parameter auf, ob du damit das Problem eingrenzen kannst. Es kann sicherlich nicht schaden auf den Thinclients das neuste OS zu installieren.
Ansonsten wird es mit einem Support Ticket bei IGEL wahrscheinlich sowieso nichts. Gruß,
Dani
also es gibt hier wohl zwei potentielel Fehlerquellen
1.) die Clients von dem problematischen Standort können den Session broker nicht erreichen (ansonsten hätte man ja keine Farm sondern drei einzelnstehende Termianlserver), dann kommt keine Session zustande.
2.) Streß mit falschen Richtlinien bezüglich der Oracle CredSSP (ein Verfahren zur Paßwortübertragung bei RDP Sitzungen), die Igel Clients nicht beherrschen. Man muß die dazugehörige GPO dann auf Serverseite einstellen...
1.) die Clients von dem problematischen Standort können den Session broker nicht erreichen (ansonsten hätte man ja keine Farm sondern drei einzelnstehende Termianlserver), dann kommt keine Session zustande.
2.) Streß mit falschen Richtlinien bezüglich der Oracle CredSSP (ein Verfahren zur Paßwortübertragung bei RDP Sitzungen), die Igel Clients nicht beherrschen. Man muß die dazugehörige GPO dann auf Serverseite einstellen...
Hallo,
versuch mal "/sec:rdp" in den freerdp-Call einzubauen. Wenn er das automatisch wählt haut das oft nicht hin. Hatte das auch mal, zwar nicht in ner Farm aber ähnlicher Fehler.
Grüße
bloody
versuch mal "/sec:rdp" in den freerdp-Call einzubauen. Wenn er das automatisch wählt haut das oft nicht hin. Hatte das auch mal, zwar nicht in ner Farm aber ähnlicher Fehler.
Grüße
bloody
Erst einmal Vielen Dank für die Tips zur freerdp. Dahin hatte mich Google auch schon geführt. Nur nutze ich die Oberfläche der Igel, die wiederrum Einstellungen zentral per Management Konsole verpasst bekommen. Manuell die FreeRDP Syntax zu ändern ist da so nicht vorgesehen.
Zitat von @GrueneSosseMitSpeck:
also es gibt hier wohl zwei potentielel Fehlerquellen
1.) die Clients von dem problematischen Standort können den Session broker nicht erreichen (ansonsten hätte man ja keine Farm sondern drei einzelnstehende Termianlserver), dann kommt keine Session zustande.
2.) Streß mit falschen Richtlinien bezüglich der Oracle CredSSP (ein Verfahren zur Paßwortübertragung bei RDP Sitzungen), die Igel Clients nicht beherrschen. Man muß die dazugehörige GPO dann auf Serverseite einstellen...
also es gibt hier wohl zwei potentielel Fehlerquellen
1.) die Clients von dem problematischen Standort können den Session broker nicht erreichen (ansonsten hätte man ja keine Farm sondern drei einzelnstehende Termianlserver), dann kommt keine Session zustande.
2.) Streß mit falschen Richtlinien bezüglich der Oracle CredSSP (ein Verfahren zur Paßwortübertragung bei RDP Sitzungen), die Igel Clients nicht beherrschen. Man muß die dazugehörige GPO dann auf Serverseite einstellen...
Danke, da kommen wird der Sache wohl näher. Ich hab mittlerweile festgestellt, daß das Problem nicht nur an einem Standort besteht sondern auf allen Clients die UDC 10 fahren, nicht aber auf älteren oder neueren Maschinen. Wenn ich von einer Maschine versuche die Farm anzupingen wird in 90% aller Fälle auf eben die 2 Server aufgelöst die eben nicht reagieren und nur ab und zu auf den Server auf dem die Anmeldung möglich ist. Unterscheidungsmerklmal ist also entweder die Version UDC 10 oder das Konfigurationsprofil für die UDC10 Clients.
Jetzt stecke ich in dem Thema aber nicht so tief drin und springe hier als Aushilfe ein. Außerdem bin ich langsam etwas lange auf den Beinen und mir raucht der Kopf.
In der Management Konsole kann ich so spontan weder andere Einstellungen für die 10er als für die 11er finden, noch den Bereich Oracle CreddSSP...
Es gibt da aber doch sicher eine Option für? Sonst mal Igel-Hersteller anschreiben oder gibts da ein Forum?
Kenne das vom Namen her, habs aber selber noch nicht benutzt.
Kenne das vom Namen her, habs aber selber noch nicht benutzt.
Zitat von @bloodstix:
Es gibt da aber doch sicher eine Option für? Sonst mal Igel-Hersteller anschreiben oder gibts da ein Forum?
Kenne das vom Namen her, habs aber selber noch nicht benutzt.
Es gibt da aber doch sicher eine Option für? Sonst mal Igel-Hersteller anschreiben oder gibts da ein Forum?
Kenne das vom Namen her, habs aber selber noch nicht benutzt.
Für den Support muss man wohl erst von nem Vertriebler freigeschaltet werden, da warte ich noch auf Antwort und das Forum ist so ne komische Slack Community zum networken und lifestylen....... Ich arbeite dran.
Der Ansatz mit dem Session broker erscheint mir der viel versprechenste zu sein, aber auch da muss ich mir mal angucken wie das hier überhaupt läuft. Auch hier sind die Leute die das aufgebaut haben nicht zu erreichen.
Da das Problem aber schon länger besteht, werde ich mir aber die Freiheit nehmen und mich mal kurz ablegen, dann kann ich auch wieder klar denken.
War alles etwas konfus und langwierig hier....
Ursache ist das Gateway/der Session Broker bzw. die angehängte Datenbank. Wir werden demnächst die Terminalserver mal komplett neu verdrahten. Der Fehler wurde also nicht durch die Konfiguration der Igel sondern der des Servers verursacht. Vielen Dank noch einmal für Eure Unterstützung und Tips!!
Abschließend möchte ich noch anmerken, daß ich mit dem Produkt Igel in Kombination Igel UMS echt zufrieden bin, der Support aber höflich ausgedrückt zum Kotzen ist.
Ursache ist das Gateway/der Session Broker bzw. die angehängte Datenbank. Wir werden demnächst die Terminalserver mal komplett neu verdrahten. Der Fehler wurde also nicht durch die Konfiguration der Igel sondern der des Servers verursacht. Vielen Dank noch einmal für Eure Unterstützung und Tips!!
Abschließend möchte ich noch anmerken, daß ich mit dem Produkt Igel in Kombination Igel UMS echt zufrieden bin, der Support aber höflich ausgedrückt zum Kotzen ist.
