6
Von Lokal-Win7 in RDP-Sitzung durchgeschleifter Netzwerkdrucker wird nach ca. 5-6 Stunden als Offline angezeigt
Hallo zusammen,
erstmal ein paar Informationen zur Umgebung:
- Windows Server 2008 R2 Terminalserver
- Benutzer arbeiten von Win7 Clients von einem externen Standort über VPN-Tunnel per RDP-Sitzung auf dem Terminalserver
- Netzwerkdrucker (steht vort Ort am externen Standort) wurde lokal auf den Win7 Clients über die IP-Adresse angelegt und wird dann in die RDP-Sitzung durchgeschleift
- Dies wird so gemacht, weil hier größere Druckjobs durchgeführt werden und diese somit durch das "Umleiten" in die RDP Sitzung komprimiert werden, vorher gab es immer Abbrüche der Druckjobs
- Drucker ist ein Kyocera TASKalfa 3510i KX
Nun zum Problem:
Die Benutzer melden sich morgens am Terminalserver an und können in der RDP-Sitzung ganz normal auf den Drucker drucken.
Sie haben nun berichtet, dass der Drucker bisher immer ab 12-13 Uhr plötzlich in der RDP-Sitzung als "Offline" angezeigt wird und kein Druckjob mehr drauf geschickt werden kann.
Obwohl zur gleichen Zeit der Drucker im lokalen Win7 weiterhin als Online angezeigt wird.
Nach dem Abmelden der RDP-Sitzung und wieder anmelden ist der Drucker dann auch hier wieder verfügbar.
Ist kein akutes Problem.
Wäre aber interessant, ob es hierzu eine Lösung gibt. Evtl. ist hier ein timeout aktiv? Habe bisher dazu leider nichts in der Ereignisanzeige des Terminalservers gefunden.
Viele Grüße
Manuel
erstmal ein paar Informationen zur Umgebung:
- Windows Server 2008 R2 Terminalserver
- Benutzer arbeiten von Win7 Clients von einem externen Standort über VPN-Tunnel per RDP-Sitzung auf dem Terminalserver
- Netzwerkdrucker (steht vort Ort am externen Standort) wurde lokal auf den Win7 Clients über die IP-Adresse angelegt und wird dann in die RDP-Sitzung durchgeschleift
- Dies wird so gemacht, weil hier größere Druckjobs durchgeführt werden und diese somit durch das "Umleiten" in die RDP Sitzung komprimiert werden, vorher gab es immer Abbrüche der Druckjobs
- Drucker ist ein Kyocera TASKalfa 3510i KX
Nun zum Problem:
Die Benutzer melden sich morgens am Terminalserver an und können in der RDP-Sitzung ganz normal auf den Drucker drucken.
Sie haben nun berichtet, dass der Drucker bisher immer ab 12-13 Uhr plötzlich in der RDP-Sitzung als "Offline" angezeigt wird und kein Druckjob mehr drauf geschickt werden kann.
Obwohl zur gleichen Zeit der Drucker im lokalen Win7 weiterhin als Online angezeigt wird.
Nach dem Abmelden der RDP-Sitzung und wieder anmelden ist der Drucker dann auch hier wieder verfügbar.
Ist kein akutes Problem.
Wäre aber interessant, ob es hierzu eine Lösung gibt. Evtl. ist hier ein timeout aktiv? Habe bisher dazu leider nichts in der Ereignisanzeige des Terminalservers gefunden.
Viele Grüße
Manuel
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 329516
Url: https://administrator.de/contentid/329516
Ausgedruckt am: 22.11.2024 um 19:11 Uhr
6 Kommentare
Neuester Kommentar
Hallo,
Und wird durch vile Clients zunichte gemacht
Gruß,
Peter
Zitat von @Manuel-IT:
- Benutzer arbeiten von Win7 Clients von einem externen Standort über VPN-Tunnel per RDP-Sitzung
Standort zu Standort VPN oder Client zu Standort VPN?- Benutzer arbeiten von Win7 Clients von einem externen Standort über VPN-Tunnel per RDP-Sitzung
- Netzwerkdrucker (steht vort Ort am externen Standort) wurde lokal auf den Win7 Clients über die IP-Adresse angelegt und wird dann in die RDP-Sitzung durchgeschleift
Warum nicht den Drucker per IP am TS bekannt gemacht und dort direkt nutzen? Jeder Cleint schleift so seinen eigenen Drucker mit durch.- Dies wird so gemacht, weil hier größere Druckjobs durchgeführt werden und diese somit durch das "Umleiten" in die RDP Sitzung
komprimiert werden,Und wird durch vile Clients zunichte gemacht
vorher gab es immer Abbrüche der Druckjobs>
Und jetzt nicht mehr? Täglich ab 12 - 13 Uhr ...Sie haben nun berichtet, dass der Drucker bisher immer ab 12-13 Uhr
Was passiert dann? Router neustart? Externe IP wird erneuert? Ein Modem wählt sich neu ein? Provider zwangstrennung alle 24 Stunden greift? Mal ein dauerping gemacht und geschaut ob die prozesse und sessions gleich bleiben wenn da was ab 12 - 13 Uhr deine RDP Sitzungen lahmlegt?Obwohl zur gleichen Zeit der Drucker im lokalen Win7 weiterhin als Online angezeigt wird.
Du vergleichst Äpfel mit Stacheldraht. Wieso sollte dein Lokales LAN gestört sein wenn deine RDP Sitzungen per VPN wegfliegen? Was haben die miteinander zu tun?Nach dem Abmelden der RDP-Sitzung und wieder anmelden ist der Drucker dann auch hier wieder verfügbar.
Oh Wunder? Wirklich? Gruß,
Peter
Guten Morgen Peter,
erstmal vielen Dank für die schnelle Antwort.
Standort zu Standort VPN mit Watchguard Firewalls auf beiden Seiten
Die Drucker waren vorher am TS bekannt und wurden dort direkt genutzt, allerdings sind hier die größeren Druckjobs immer abgebrochen unabhängig von der Uhrzeit. Dies wurde ausgiebig getestet und konnte auch durch einen externen IT-Dienstleister nicht behoben werden. Dieses Problem konnten wir eben mit dem Anlegen der Drucker direkt auf den 2 Clients dort am externen Standort beheben. Die Druckjobs brechen jetzt nicht mehr ab. Sind bisher immer sauber durchgelaufen laut den Mitarbeitern dort.
Was dort um die Uhrzeit 12-13 Uhr passiert werde ich nochmal genau prüfen und dann berichten.
Das war auch kein Vergleich, sondern eine Feststellung, dass es am Drucker selbst nicht liegen kann
Grüße
Manuel
erstmal vielen Dank für die schnelle Antwort.
Standort zu Standort VPN mit Watchguard Firewalls auf beiden Seiten
Die Drucker waren vorher am TS bekannt und wurden dort direkt genutzt, allerdings sind hier die größeren Druckjobs immer abgebrochen unabhängig von der Uhrzeit. Dies wurde ausgiebig getestet und konnte auch durch einen externen IT-Dienstleister nicht behoben werden. Dieses Problem konnten wir eben mit dem Anlegen der Drucker direkt auf den 2 Clients dort am externen Standort beheben. Die Druckjobs brechen jetzt nicht mehr ab. Sind bisher immer sauber durchgelaufen laut den Mitarbeitern dort.
Was dort um die Uhrzeit 12-13 Uhr passiert werde ich nochmal genau prüfen und dann berichten.
Das war auch kein Vergleich, sondern eine Feststellung, dass es am Drucker selbst nicht liegen kann
Grüße
Manuel
Guten Morgen Manuel,
die lokalen Drucker durchzuschleifen ist für eine WAN-Anbindung der Aussenstelle sicher erstmal der richtige Ansatz.
Wenn der Drucker der Aussenstelle über das VPN zum Terminalserver hin verbunden ist, wird die zu übertragende Datenmenge weitaus grösser, da dann der Druckjob auf dem Terminalserver gerendert wird, also die für den Zieldrucker aufbereiteten Daten übertragen werden müssen. Hier gilt: je grösser die Auflösung um so grösser die Datenmenge!
Benutzt der User hingegen einen gemappten Drucker wird das geräteunabhängige Spoolfile zum lokalen Spooler transportiert und erst dort gerendert.
Dabei kommt noch die Kompression des rdp-Protokolls ins Spiel (die aber nicht sonderlich gut ist) und reduziert zusätzlich die Datenmenge, die über das WAN geht.
Mit zusätzlicher Software für das rdp-Drucken kann diese Datenmenge weiter komprimiert werden.
Da ich schon seit vielen Jahren Kunden mit Terminalservern betreue habe ich in dieser Richtung nach Optimierungen gesucht. Getestet habe ich Thin-print, Tricerat Screwdriver und Slimprinter.
Letztendlich bind ich bei Slimprinter hängen geblieben. Da existiert wohl das beste Preis/Leistungsverhältnis. Auch andere Problem wie konstante Druckernamen (kein umgeleitet von xxx, mache Software kann mit den wechselnden Druckernamen nicht umgehen) und die Verwaltung vom Clienten selbst (anderer Standarddrucker, Schachtsteuerung etc.) sind von Vorteil. Auch die Möglichkeit der 'privaten Drucker' (User sieht nur seine(n) Drucker) sollte noch erwähnt sein.
Da die Software für 20 Tage ohne Einschränkungen für 5 User läuft steht da einem Test nichts im Wege.
Gruß Crazy
die lokalen Drucker durchzuschleifen ist für eine WAN-Anbindung der Aussenstelle sicher erstmal der richtige Ansatz.
Wenn der Drucker der Aussenstelle über das VPN zum Terminalserver hin verbunden ist, wird die zu übertragende Datenmenge weitaus grösser, da dann der Druckjob auf dem Terminalserver gerendert wird, also die für den Zieldrucker aufbereiteten Daten übertragen werden müssen. Hier gilt: je grösser die Auflösung um so grösser die Datenmenge!
Benutzt der User hingegen einen gemappten Drucker wird das geräteunabhängige Spoolfile zum lokalen Spooler transportiert und erst dort gerendert.
Dabei kommt noch die Kompression des rdp-Protokolls ins Spiel (die aber nicht sonderlich gut ist) und reduziert zusätzlich die Datenmenge, die über das WAN geht.
Mit zusätzlicher Software für das rdp-Drucken kann diese Datenmenge weiter komprimiert werden.
Da ich schon seit vielen Jahren Kunden mit Terminalservern betreue habe ich in dieser Richtung nach Optimierungen gesucht. Getestet habe ich Thin-print, Tricerat Screwdriver und Slimprinter.
Letztendlich bind ich bei Slimprinter hängen geblieben. Da existiert wohl das beste Preis/Leistungsverhältnis. Auch andere Problem wie konstante Druckernamen (kein umgeleitet von xxx, mache Software kann mit den wechselnden Druckernamen nicht umgehen) und die Verwaltung vom Clienten selbst (anderer Standarddrucker, Schachtsteuerung etc.) sind von Vorteil. Auch die Möglichkeit der 'privaten Drucker' (User sieht nur seine(n) Drucker) sollte noch erwähnt sein.
Da die Software für 20 Tage ohne Einschränkungen für 5 User läuft steht da einem Test nichts im Wege.
Gruß Crazy
Hallo Crazy,
vielen Dank für den Hinweis!
Das werde ich mir anschauen.
Aktuell suche ich aber noch nach einer schlankeren Lösung bzw. Erklärung für das Verhalten.
Denn das Drucken an sich klappt ja einwandfrei.
Ich freue mich auf weitere Ideen und Hinweise.
Grüße
Manuel
vielen Dank für den Hinweis!
Das werde ich mir anschauen.
Aktuell suche ich aber noch nach einer schlankeren Lösung bzw. Erklärung für das Verhalten.
Denn das Drucken an sich klappt ja einwandfrei.
Ich freue mich auf weitere Ideen und Hinweise.
Grüße
Manuel
Hallo Manuel,
evtl. haben sich zu viele inaktive TS-Ports angesammelt.
Das ist auch in folgendem Link beschrieben.
Vielleicht hilft das ja?
Gruß Crazy
evtl. haben sich zu viele inaktive TS-Ports angesammelt.
Das ist auch in folgendem Link beschrieben.
Vielleicht hilft das ja?
Gruß Crazy
Danke für den weiteren Hinweis.
Habe die inaktiven TS-Ports nun mal entfernt.
Dauerping auf den Drucker vom Terminalserver aus ergab: Sent 8810, Received: 8796, Lost: 14
Die 14 verlorenen Pakete sind vereinzelt und zeitlich auseinander. Hier lässt sich keine größere Unterbrechung feststellen.
Problem trat auch heute wieder nach der Rückfrage beim Mitarbeiter auf.
Habe die inaktiven TS-Ports nun mal entfernt.
Dauerping auf den Drucker vom Terminalserver aus ergab: Sent 8810, Received: 8796, Lost: 14
Die 14 verlorenen Pakete sind vereinzelt und zeitlich auseinander. Hier lässt sich keine größere Unterbrechung feststellen.
Problem trat auch heute wieder nach der Rückfrage beim Mitarbeiter auf.
