TS-Sitzung optimieren: Drucken über RDP an einem anderen Standort (VPN)
HI @ all,
ich nutze die Chance und veröffentliche meine erste Frage...
Und zwar stellt sich die Situation wie folgt dar:
Kunde hat 3 Standorte (Stadt A, Stadt B, Stadt C). Alle Standorte verfügen über SDSL 4mbit und haben Standortverbindungen über VPN.
Die Server stehen in der Stadt B
Alle Drucker die vor Ort irgendwo stehen, sind auf die Terminalserver direkt eingebunden.
Nun stellt sich folgendes Problem dar;
User aus Stadt A, druckt in der Terminalsitzung ein Dokument aus, was 96 Seiten hat und 100mb groß ist. Dadurch blockiert er den Drucker und Druckaufträge gehen schleppent raus.
Desweiteren leidet die VPN Verbindung zur Stadt B, so mein empfinden.
Gibt es die Möglichkeit dies zu optimieren.
Die erste Möglichkeit wäre ja, die Drucker über RDP durchzuschleifen (Printer Redirection), doch da denke ich, würde ich das gleiche Problem haben wie jetzt und es können mehr Probleme auftreten (Wird nicht richtig durchgeschliffen etc.)
Vielen Dank für eure Tipps.
Christian Giuranna
ich nutze die Chance und veröffentliche meine erste Frage...
Und zwar stellt sich die Situation wie folgt dar:
Kunde hat 3 Standorte (Stadt A, Stadt B, Stadt C). Alle Standorte verfügen über SDSL 4mbit und haben Standortverbindungen über VPN.
Die Server stehen in der Stadt B
Alle Drucker die vor Ort irgendwo stehen, sind auf die Terminalserver direkt eingebunden.
Nun stellt sich folgendes Problem dar;
User aus Stadt A, druckt in der Terminalsitzung ein Dokument aus, was 96 Seiten hat und 100mb groß ist. Dadurch blockiert er den Drucker und Druckaufträge gehen schleppent raus.
Desweiteren leidet die VPN Verbindung zur Stadt B, so mein empfinden.
Gibt es die Möglichkeit dies zu optimieren.
Die erste Möglichkeit wäre ja, die Drucker über RDP durchzuschleifen (Printer Redirection), doch da denke ich, würde ich das gleiche Problem haben wie jetzt und es können mehr Probleme auftreten (Wird nicht richtig durchgeschliffen etc.)
Vielen Dank für eure Tipps.
Christian Giuranna
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 263618
Url: https://administrator.de/contentid/263618
Ausgedruckt am: 25.11.2024 um 11:11 Uhr
12 Kommentare
Neuester Kommentar
Zitat von @Bigitalian:
HI @ all,
ich nutze die Chance und veröffentliche meine erste Frage...
Und zwar stellt sich die Situation wie folgt dar:
Kunde hat 3 Standorte (Stadt A, Stadt B, Stadt C). Alle Standorte verfügen über SDSL 4mbit und haben
Standortverbindungen über VPN.
Die Server stehen in der Stadt B
Alle Drucker die vor Ort irgendwo stehen, sind auf die Terminalserver direkt eingebunden.
Nun stellt sich folgendes Problem dar;
User aus Stadt A, druckt in der Terminalsitzung ein Dokument aus, was 96 Seiten hat und 100mb groß ist. Dadurch blockiert er
den Drucker und Druckaufträge gehen schleppent raus.
Desweiteren leidet die VPN Verbindung zur Stadt B, so mein empfinden.
das ist kein empfinden, sondern ist so....HI @ all,
ich nutze die Chance und veröffentliche meine erste Frage...
Und zwar stellt sich die Situation wie folgt dar:
Kunde hat 3 Standorte (Stadt A, Stadt B, Stadt C). Alle Standorte verfügen über SDSL 4mbit und haben
Standortverbindungen über VPN.
Die Server stehen in der Stadt B
Alle Drucker die vor Ort irgendwo stehen, sind auf die Terminalserver direkt eingebunden.
Nun stellt sich folgendes Problem dar;
User aus Stadt A, druckt in der Terminalsitzung ein Dokument aus, was 96 Seiten hat und 100mb groß ist. Dadurch blockiert er
den Drucker und Druckaufträge gehen schleppent raus.
Desweiteren leidet die VPN Verbindung zur Stadt B, so mein empfinden.
Gibt es die Möglichkeit dies zu optimieren.
Die erste Möglichkeit wäre ja, die Drucker über RDP durchzuschleifen (Printer Redirection), doch da denke ich,
würde ich das gleiche Problem haben wie jetzt und es können mehr Probleme auftreten (Wird nicht richtig durchgeschliffen
etc.)
evtl. auf citrix xenapp umsteigen, braucht weniger bandbreite... wird aber mit einem QoS flüssiger laufen...
und für die druckjobs braucht es eben etwas gedult
Vielen Dank für eure Tipps.
Christian Giuranna
lgV
Hi,
wieviele Sitzungen pro Standort?
ThinPrint könnte ne Lösung sein.
Oder sowas wie der Citrix Branch Repeater, oder WANscaler oder NetScaler oder wie auch immer das Teil bei denen jetzt aktuell heißt.
E.
wieviele Sitzungen pro Standort?
ThinPrint könnte ne Lösung sein.
Oder sowas wie der Citrix Branch Repeater, oder WANscaler oder NetScaler oder wie auch immer das Teil bei denen jetzt aktuell heißt.
E.
Hallo Christian,
wenn ich es recht sehe steht für Dich das größte Problem in der Belastung des VPN durch die großen Druckdateien, die über das VPN gedrückt werden.
Um dies zu reduzieren sollte man folgendes in Betracht ziehen:
1.für die direkt auf dem TS installierten Drucker wird jeder Druckjob auf dem TS gerendert und die Renderdaten dann über das VPN zum Zieldrucker geleitet, d.h. Port 3389 für rdp ist da nicht mehr involviert. Die Datenmenge der Druckrohdaten (also die GDI-Befehle, die die druckende Anwendung in das Spoolfile auf dem Server schreibt) sind wesentlich kleiner als das gerendete (also für den Zieldrucker aufbereitete) Datenmaterial. Dies wird dann noch unkomprimiert außerhalb des rdp über den VPN-Tunnel übertragen! Das kostet natürlich Bandbreite.
2.Bei der Verteilung der Drucker auf mehrere Außenstellen macht es keinen Sinn diese auf dem TS zu installieren, da kaum eine Außenstelle auf einem entfernten Drucker einen Ausdruck starten wird.
Ergo, es ist ein Verfahren nötig, dass die Druckrohdaten vom TS auf die lokalen Maschinen der Außenstellen überträgt (möglichst komprimiert im rdp-Channel), dort rendert und auf den lokal installierten Drucker ausgibt. Für das WAN bedeutet dies weniger zu transportierende Daten, die noch via rdp komprimiert werden, für den TS weitaus weniger Last, da kein Druckjob gerendert werden muß.
Nun könnte man zunächst mal Easyprint aktivieren, aber das geht auch nicht mit allen Druckern und ist besonders unter Office recht unperformant. Ohne Easyprint nur 'normales' rdp-Printermapping zu verwenden, wird bei eingen Druckemodellen (einige OKI, HP...) ebenfalls zu Problemen führen oder u.U. den Serverspooler crashen.
Da ich selbst einen Kunden mit 10 Außenstellen quer durch Deutschland betreue, kann ich die Problematik voll nachempfinden und habe schon zu Server2000-Zeiten nach Lösungen gesucht, manches probiert und wieder verworfen. Im Ergebnis kann ich sagen: Es gibt für die Windowsserver nur wenige brauchbare Lösungen.
Da sind
1. Thinprint: relativ teuer(Wartung), Testmöglichkeit nur nach Anmeldung und anschließendem Marketing
2. Tricerat Screwdrivers: auch teuer, Testdownload nur mit Anmeldung, 'Marketingterror'
3. Slimprinter: einmalige Anschaffungskosten bei kostenlosem Support und kostenlosen Updates, frei downloadbar (20 Tage Testzeitraum)
Allen Produkten ist gemeinsam, dass Sie eine Serverkomponente und auf den Clientmaschinen einen Client benötigen, nur das GDI-File (nochmal zusätzlich komprimiert) vom TS zum Client übertragen und auf dem Client rendern. sowie an die Userzahl skalierbar sind.
Seit vielen Jahren verwende ich mit Erfolg Slimprinter auf etlichen Terminalservern und konnte ohne finanziellen Aufwand die Weiterentwicklung des Produktes nutzen.
Gruß Crazy
wenn ich es recht sehe steht für Dich das größte Problem in der Belastung des VPN durch die großen Druckdateien, die über das VPN gedrückt werden.
Um dies zu reduzieren sollte man folgendes in Betracht ziehen:
1.für die direkt auf dem TS installierten Drucker wird jeder Druckjob auf dem TS gerendert und die Renderdaten dann über das VPN zum Zieldrucker geleitet, d.h. Port 3389 für rdp ist da nicht mehr involviert. Die Datenmenge der Druckrohdaten (also die GDI-Befehle, die die druckende Anwendung in das Spoolfile auf dem Server schreibt) sind wesentlich kleiner als das gerendete (also für den Zieldrucker aufbereitete) Datenmaterial. Dies wird dann noch unkomprimiert außerhalb des rdp über den VPN-Tunnel übertragen! Das kostet natürlich Bandbreite.
2.Bei der Verteilung der Drucker auf mehrere Außenstellen macht es keinen Sinn diese auf dem TS zu installieren, da kaum eine Außenstelle auf einem entfernten Drucker einen Ausdruck starten wird.
Ergo, es ist ein Verfahren nötig, dass die Druckrohdaten vom TS auf die lokalen Maschinen der Außenstellen überträgt (möglichst komprimiert im rdp-Channel), dort rendert und auf den lokal installierten Drucker ausgibt. Für das WAN bedeutet dies weniger zu transportierende Daten, die noch via rdp komprimiert werden, für den TS weitaus weniger Last, da kein Druckjob gerendert werden muß.
Nun könnte man zunächst mal Easyprint aktivieren, aber das geht auch nicht mit allen Druckern und ist besonders unter Office recht unperformant. Ohne Easyprint nur 'normales' rdp-Printermapping zu verwenden, wird bei eingen Druckemodellen (einige OKI, HP...) ebenfalls zu Problemen führen oder u.U. den Serverspooler crashen.
Da ich selbst einen Kunden mit 10 Außenstellen quer durch Deutschland betreue, kann ich die Problematik voll nachempfinden und habe schon zu Server2000-Zeiten nach Lösungen gesucht, manches probiert und wieder verworfen. Im Ergebnis kann ich sagen: Es gibt für die Windowsserver nur wenige brauchbare Lösungen.
Da sind
1. Thinprint: relativ teuer(Wartung), Testmöglichkeit nur nach Anmeldung und anschließendem Marketing
2. Tricerat Screwdrivers: auch teuer, Testdownload nur mit Anmeldung, 'Marketingterror'
3. Slimprinter: einmalige Anschaffungskosten bei kostenlosem Support und kostenlosen Updates, frei downloadbar (20 Tage Testzeitraum)
Allen Produkten ist gemeinsam, dass Sie eine Serverkomponente und auf den Clientmaschinen einen Client benötigen, nur das GDI-File (nochmal zusätzlich komprimiert) vom TS zum Client übertragen und auf dem Client rendern. sowie an die Userzahl skalierbar sind.
Seit vielen Jahren verwende ich mit Erfolg Slimprinter auf etlichen Terminalservern und konnte ohne finanziellen Aufwand die Weiterentwicklung des Produktes nutzen.
Gruß Crazy
Noch ein Nachtrag:
das Durchschleifen der Drucker per rdp hat auch den Nachteil, dass in Abhängigkeit der Anmeldereihenfolge dem Druckernamen ein Zusatz wie '(in Sitzung nnn)' angefügt wird (sich also bei nahezu jeder Anmeldung ändert).
Manche Software hat aber ihre eigene Druckerverwaltung, die einen konstanten Druckernamen verlangt!
Slimprinter umgeht dieses Problem durch Bildung des Druckernamens aus Maschinenname + Druckername.
Crazy
das Durchschleifen der Drucker per rdp hat auch den Nachteil, dass in Abhängigkeit der Anmeldereihenfolge dem Druckernamen ein Zusatz wie '(in Sitzung nnn)' angefügt wird (sich also bei nahezu jeder Anmeldung ändert).
Manche Software hat aber ihre eigene Druckerverwaltung, die einen konstanten Druckernamen verlangt!
Slimprinter umgeht dieses Problem durch Bildung des Druckernamens aus Maschinenname + Druckername.
Crazy
Es sind nicht nur mehr Einstellmöglichkeiten vorhanden, auch das Druckprinzip ist anders als bei Printerrediction.
Zur Theorie des Druckvorgangs:
Die druckende Anwendung schreibt den zu druckenden Inhalt als GDI-Anweisungen in das Spoolfile. Diese Anweisungen sind nicht abhängig vom Druckgerät. Erst der Druckertreiber rendert diese GDI-Anweisungen auf ein Format, das der gewählte Zieldrucker verarbeiten kann (sprich die gerenderten Daten werden an den Anschluß des Druckers gesendet.
Bei Printerrediction läuft das komplett auf dem Terminalserver ab(deshalb ist der Originaltreiber auch auf dem Server nötig. Bei easyprint wird eine Zwischenstufe in Form eines XPS-Dokuments verwendet.).
Es wird eine größere Datenmenge via rdp übertragen.
Slimprinter, thinprint oder tricerat gehen dabei den Weg, das nicht auf dem Server gerendert wird, sondern das GDI-Spoolfile zum Clienten übertragen wird, was schonmal generell weniger Daten sind und die werden noch vor dem Versand zum Client komprimiert. Printerrediction hingegen nutzt nur die weniger effizente Kompression von des rdp-protokolls.
Da auf dem Server nicht gerendert wird, reicht ein universeller Treiber (bei Slimprinter 2) aus, der nur die Schablone für mögliche Papierformate, Auflösungen und Geräteeigenschaften wie z.B. Schächte zur Verfügung stellen muß.
Somit ist das Gesamtverfahren bzgl. der Performance weitaus effektiver.
Die Lizenzierung von Slimprinter ist eigentlich ganz einfach:
1. Für den Terminalserver sind 5 konkurrirende User intergriert. Werden mehr User benötigt, können User-AddOns erworben werden.
Kokurrierende User bedeutet gleichzeitige User, d.h. die Userlizenzen sind nicht an Benutzernamen oder Maschinennamen gebunden. Es wird nur die Useranzahl gezählt. Sind z.B. 5 User möglich wird eine 6. Anmeldung bei 5 angemeldeten Usern abgewiesen. Meldet sich einer der bereits angemeldeten User ab, kann wieder ein neuer hinzu. Gezählt werden dabei nur User mit clientseitig aktiviertem Slimprinter.
2. Soll Slimprinter nur auf einem PC (und nicht auf einem Terminalserver) installiert werden, um auf diesem PC per rdp zuzugreifen und drucken zu können, gibt es eine 1-User Lizenz (99,-€ glaube ich).
Entschieden wird dies bei der Installation der Serverkomponente und dem vorhandenen Betriebssystem.
Für mehr Einzelheiten würde ich den Hersteller kontaktieren.
Crazy
Zur Theorie des Druckvorgangs:
Die druckende Anwendung schreibt den zu druckenden Inhalt als GDI-Anweisungen in das Spoolfile. Diese Anweisungen sind nicht abhängig vom Druckgerät. Erst der Druckertreiber rendert diese GDI-Anweisungen auf ein Format, das der gewählte Zieldrucker verarbeiten kann (sprich die gerenderten Daten werden an den Anschluß des Druckers gesendet.
Bei Printerrediction läuft das komplett auf dem Terminalserver ab(deshalb ist der Originaltreiber auch auf dem Server nötig. Bei easyprint wird eine Zwischenstufe in Form eines XPS-Dokuments verwendet.).
Es wird eine größere Datenmenge via rdp übertragen.
Slimprinter, thinprint oder tricerat gehen dabei den Weg, das nicht auf dem Server gerendert wird, sondern das GDI-Spoolfile zum Clienten übertragen wird, was schonmal generell weniger Daten sind und die werden noch vor dem Versand zum Client komprimiert. Printerrediction hingegen nutzt nur die weniger effizente Kompression von des rdp-protokolls.
Da auf dem Server nicht gerendert wird, reicht ein universeller Treiber (bei Slimprinter 2) aus, der nur die Schablone für mögliche Papierformate, Auflösungen und Geräteeigenschaften wie z.B. Schächte zur Verfügung stellen muß.
Somit ist das Gesamtverfahren bzgl. der Performance weitaus effektiver.
Die Lizenzierung von Slimprinter ist eigentlich ganz einfach:
1. Für den Terminalserver sind 5 konkurrirende User intergriert. Werden mehr User benötigt, können User-AddOns erworben werden.
Kokurrierende User bedeutet gleichzeitige User, d.h. die Userlizenzen sind nicht an Benutzernamen oder Maschinennamen gebunden. Es wird nur die Useranzahl gezählt. Sind z.B. 5 User möglich wird eine 6. Anmeldung bei 5 angemeldeten Usern abgewiesen. Meldet sich einer der bereits angemeldeten User ab, kann wieder ein neuer hinzu. Gezählt werden dabei nur User mit clientseitig aktiviertem Slimprinter.
2. Soll Slimprinter nur auf einem PC (und nicht auf einem Terminalserver) installiert werden, um auf diesem PC per rdp zuzugreifen und drucken zu können, gibt es eine 1-User Lizenz (99,-€ glaube ich).
Entschieden wird dies bei der Installation der Serverkomponente und dem vorhandenen Betriebssystem.
Für mehr Einzelheiten würde ich den Hersteller kontaktieren.
Crazy
Hallo Christian,
noch ein Nachtrag:
Slimprinter greift nicht störend in das Drucksystem von Windows ein. Dies bedeutet, dass Slimprinter zu Testzwecken auch in ein laufendes produktives System installiert werden kann und von einem einzelnen Client getestet werden kann ohne die anderen Sitzungen zu stören.
Es ist auch möglich zu Vergleichszwecken sowohl Slimprinter und das rdp printermapping parallel zu betreiben. Hierbei ist ggfs. die Wartezeit der Clientintialisierung zu erhöhen. Dann werden die Slimprinterdrucker erst nach dem Erstellen der rdp-Drucker erzeugt und Slimprinter bestimmt den Standarddrucker.
Gruß Crazy
noch ein Nachtrag:
Slimprinter greift nicht störend in das Drucksystem von Windows ein. Dies bedeutet, dass Slimprinter zu Testzwecken auch in ein laufendes produktives System installiert werden kann und von einem einzelnen Client getestet werden kann ohne die anderen Sitzungen zu stören.
Es ist auch möglich zu Vergleichszwecken sowohl Slimprinter und das rdp printermapping parallel zu betreiben. Hierbei ist ggfs. die Wartezeit der Clientintialisierung zu erhöhen. Dann werden die Slimprinterdrucker erst nach dem Erstellen der rdp-Drucker erzeugt und Slimprinter bestimmt den Standarddrucker.
Gruß Crazy