waagerecht 10 Geschrieben 13. Juli 2004 Melden Teilen Geschrieben 13. Juli 2004 Hallo Habe folgendes Problem Zwei Standorte über eine Standleitung verbunden und an einem Ende ein WTS 2K und am anderen Ende einen Client Das Problem ist folgendes: Nach kurzer inaktivität wird die Verbindung getrennt obwohl am WTS Verbindung trennen auf nie eingestellt ist. Muss vielleicht noch was geändert werden Michael Zitieren Link zu diesem Kommentar
=BT=Viper 11 Geschrieben 13. Juli 2004 Melden Teilen Geschrieben 13. Juli 2004 Läuft eure Standleitung nicht so doll? Wie habt ihr die Standleitung realisiert? Mit VPN Tunnel oder mit einer echten Standleitung der Telekom? Hast du mal einen ping -t auf den Server gemacht und geschaut ob Packete verloren gehen? Zitieren Link zu diesem Kommentar
waagerecht 10 Geschrieben 14. Juli 2004 Autor Melden Teilen Geschrieben 14. Juli 2004 Die Standleitung ist über Telekom fest Verbindung mit einem Bintec Router und über Octupus Telefonanlage und dauerhaft geschaltet. Das Netzwerk auf der Seite des wo auf der Terminal Client steht läuft wunderbar nur der Terminal Client trennt nach kurzer Zeit die Verbindung Woran könnte das liegen???? Zitieren Link zu diesem Kommentar
hochfrequenzG5 10 Geschrieben 14. Juli 2004 Melden Teilen Geschrieben 14. Juli 2004 Klarer Fall -> KEEP ALIVE per GP aktivieren Hi, das Problem hatte ich auch bei Win 2003 Server und ist wiedermal auf eine schlechte default Einstellung von MS zurückzuführen. Geh in Ausführen > gpedit.msc > Gruppenrichtlinien Editor öffnet sich. Richtlinien > Computer > Admin Vorlagen > windows Komponenten > Terminaldienste > rechts Keep Alive aktivieren und das Intervall auf minütlich stellen. Daneben findest du auch eine Erklärung. Danach hatte ich keine Abbrüche der TS Clients mehr. Die TS Verbindung verbraucht im idle Zustand so wenig Bandbreite, dass nach einiger Zeit die Router/Switches den Connection port killen, weil sie denken die Verbindung würde nicht mehr bestehen. Mit keep alive sendet der Server jede Minute einen "Herzschlag" und die Clients bestätigen diesen. Arbeiten deine TS Clients im Vollbild Modus? Hast du es zufällig geschafft die gelbe Verbindungsleiste dauerhaft auszublenden? Trotz displayconnectionbar:i:0 kommt sie bei mir im Vollbild immer wieder. Gruß Björn Zitieren Link zu diesem Kommentar
waagerecht 10 Geschrieben 14. Juli 2004 Autor Melden Teilen Geschrieben 14. Juli 2004 Danke für die Antwort Werde es gleich morgen mal ausprobieren Gruß Michael Zitieren Link zu diesem Kommentar
=BT=Viper 11 Geschrieben 15. Juli 2004 Melden Teilen Geschrieben 15. Juli 2004 Das mit der GPO in 2003 wusst ich net...aber gut :) Die gelbe Verbindungsleiste oben? Die geht doch normal weg wenn man auf die Reisszwecke links klickt? Oder tuts das nicht? Zitieren Link zu diesem Kommentar
tneub 10 Geschrieben 15. Juli 2004 Melden Teilen Geschrieben 15. Juli 2004 Gibt es den Punkt keep alive auch bei Windows 2000? Zitieren Link zu diesem Kommentar
waagerecht 10 Geschrieben 15. Juli 2004 Autor Melden Teilen Geschrieben 15. Juli 2004 Wie kann ich bei Windows 2000 Keep Alive einstellen?? Geht es auch am Client?? Gruß Michael Zitieren Link zu diesem Kommentar
hochfrequenzG5 10 Geschrieben 15. Juli 2004 Melden Teilen Geschrieben 15. Juli 2004 Mensch ich will nicht das die Mitarbeiter immer auf die Nadel klicken müssen. Ich möchte, dass die gelbe Leiste im Vollbild NIEMALS erscheint. Sie soll immer automatisch ausgeblendet sein. Einstellungen im Client haben keine Wirkung, auch nicht ein editieren des RDP Files bei der Zeile "displayconnectionbar:i:0". Die Leiste kommt bei jeder Session immer wieder, jedes mal zumindest unter Win 2000 Pro. Zitieren Link zu diesem Kommentar
grizzly999 11 Geschrieben 15. Juli 2004 Melden Teilen Geschrieben 15. Juli 2004 Wer hat in diesem Thread eigentlich das Problem, Hochfrequent oder waagrecht? Bitte mache zu deinem Problem einen eigenen Thread auf, sonst kommt hier nur Verwirrung auf. Ist auch hier beschrieben: http://www.mcseboard.de/rules.php?s=#nr7 Die Überschrift passt nämlich auch nicht dazu, und überhaupt :rolleyes: grizzly999 Zitieren Link zu diesem Kommentar
hochfrequenzG5 10 Geschrieben 15. Juli 2004 Melden Teilen Geschrieben 15. Juli 2004 Hat Win 2000 TS in der gpedit.msc kein Keep Alive ? Wenn dem so sein sollte müßt ihr es halt billig per Registry reinflicken. How to make your intermittent or flaky terminal services connection a little more stable In this article, I'll quickly discuss how using a few registry hacks, you can stabilize your terminal services network connection and reduce the number of disconnected sessions you get from weak WAN connections. These tweaks will also serve to prevent disconnects from occurring when network devices kill off sockets that are idle too long. Prerequisites: •A running terminal server that needs to have its connection stabilized •A registry editor, like regedit.exe Section 1: Indicators: Many WAN connections can vary in quality and latency, and often times these two characteristics will manifest themselves in disconnected terminal services sessions. By doing two relatively easy registry hacks, you can reduce these disconnects and improve the overall experience of your users. Section 2: Keep Alives: In the registry at HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server, create or edit the DWORD value of KeepAliveEnable and set it to 1. This will turn Keep Alives on. This will serve to stabilize the connection by sending 'heartbeat' packets to the client every so often. This will cause an idle connection to be probed every so often just to be sure that the connection is still alive and that the client is still listening on the other side. This will also help prevent disconnects by preventing network devices from killing off sockets that it assumes to be idle. Because terminal services is such a low bandwidth protocol, when a user is idle, no network activity will occur. Some network devices will interpret a connection that is in the idle state for an extended period of time to be a dead connection, and thus will terminate the socket. However, when the user comes out of the idle state, the terminal services client can no longer contact the terminal server because the socket is dead. By turning on Keep Alives, the connection will not appear idle, and therefore the network device will not attempt to terminate the socket. For more information about Keep Alives, check out this link. Two other registry entries to look at are at HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveInterval and HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime. Both are DWORD entries. These two registry entries typically do not need to be changed, but I've included them here for completeness. KeepAliveInterval determines the interval separating keep alive retransmissions until a response is received. If a response is received, the delay until the next keep alive transmission is again controlled by the value of KeepAliveTime. The connection will be aborted after the number of retransmissions specified by TcpMaxDataRetransmissions (which will be discussed in the next section) have gone unanswered. KeepAliveInterval is set by default to be 1000, which is one second. KeepAliveTime controls how often TCP attempts to verify that an idle connection is still intact by sending a keep alive packet. If the remote system is still reachable and functioning, it will acknowledge the keep alive transmission. KeepAliveTime is set by default to be 7,200,000, which is 2 hours. For more information about KeepAliveInterval and KeepAliveTime, check out this link. Section 3: TcpMaxDataRetransmissions: In the registry at HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters, create or edit the DWORD value of TcpMaxDataRetransmissions. By default it is set to 5, but I would recommend doubling that value, to 10. The value of TcpMaxDataRetransmissions is the number of times TCP retransmits an unacknowledged data segment on an existing connection. TCP retransmits data segments until they are acknowledged or until this value expires. Basically, when a client doesn't respond to a packet from the terminal server, the server will attempt to retransmit the packet up to TcpMaxDataRetransmissions number of times. By increasing this value, you are giving the client more time to respond to the server, which will help improve flaky connections or connections with high latency or higher than normal packet loss. For more information about TcpMaxDataRetransmissions, check out this link. If you have numerous servers you need to migrate this out to, you can hack this registry entry, export the changes to a .reg file, then silently import it (regedit.exe /q) onto your all your servers. Zitieren Link zu diesem Kommentar
grizzly999 11 Geschrieben 15. Juli 2004 Melden Teilen Geschrieben 15. Juli 2004 Eine Bitte: bei solchen Quotes immer die Quelle, wenn geht mit Link, angeben, damit wir nicht mit irgendwelchen Urherberrechtssachen in Kollision kommen. Danke ;) grizzly999 Zitieren Link zu diesem Kommentar
hochfrequenzG5 10 Geschrieben 15. Juli 2004 Melden Teilen Geschrieben 15. Juli 2004 Sorry tut mir leid habe leider den Link dazu nicht mehr. Hatte den Text zum Glück noch in einer alten Mail drin. Zitieren Link zu diesem Kommentar
Nigatol 10 Geschrieben 3. Dezember 2004 Melden Teilen Geschrieben 3. Dezember 2004 Schade, dass waagerecht nicht mehr gepostet hat, ob es bei ihm funktioniert hat. Hab nämlich das gleiche Problem. Aber Schweigen bedeutuet ja normalerweise, dass es funktioniert hat. Zitieren Link zu diesem Kommentar
EVIL 10 Geschrieben 8. März 2005 Melden Teilen Geschrieben 8. März 2005 Quelle: http://www.prcontrol.com/kb/index.php?page=index_v2&id=52&c=4 (hab nämlich die Info auch gerade benötigt) Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.