Weitergeleitete Drucker über RDP verlangsamen Anwendung
Hallo,
ich habe ein seltsames Problem: Über eine VPN Verbindung (SSL über eine UTM 9) und anschließender RDP Verbindung auf einen Terminalserver (sowohl 2008 R2 als auch 2016) ist eine bestimmte Anwendung (AP Comfort von Datev falls einem das was sagt) beim Öffnen eines sehr umfangreichen Dokuments (ca. 500 Seiten mit diversen Querverweisen und Links auf weitere Dokumente) das auf einem angebundenen Netzlaufwerk liegt, extrem langsam. So langsam, dass das Öffnen bis zu 10 Minuten dauert.
Sobald ich aber bei der RDP Verbindung die Druckerweiterleitung der lokal per USB angebundenen Drucker deaktiviere, schrumpft die Wartezeit beim Öffnen des gleichen Dokuments auf ca. 30 Sekunden.
Problem ist nur, dass die lokal angebundenen Drucker auf jeden Fall über die RDP-Verbindung verfügbar sein sollen.
Meine Fragen wären:
Hat jemand ähnliche Erfahrungen mit der Druckerumleitung über RDP bei bestimmten Anwendungen gemacht?
Wie kann man die lokalen Drucker in einem solchen Fall ohne Geschwindigkeitseinbuße einbinden?
Alle anderen Anwendung und die Druckerumleitung an sich funktionieren bei allen Anwendern übrigens ohne Probleme.
Vielen Dank!
ich habe ein seltsames Problem: Über eine VPN Verbindung (SSL über eine UTM 9) und anschließender RDP Verbindung auf einen Terminalserver (sowohl 2008 R2 als auch 2016) ist eine bestimmte Anwendung (AP Comfort von Datev falls einem das was sagt) beim Öffnen eines sehr umfangreichen Dokuments (ca. 500 Seiten mit diversen Querverweisen und Links auf weitere Dokumente) das auf einem angebundenen Netzlaufwerk liegt, extrem langsam. So langsam, dass das Öffnen bis zu 10 Minuten dauert.
Sobald ich aber bei der RDP Verbindung die Druckerweiterleitung der lokal per USB angebundenen Drucker deaktiviere, schrumpft die Wartezeit beim Öffnen des gleichen Dokuments auf ca. 30 Sekunden.
Problem ist nur, dass die lokal angebundenen Drucker auf jeden Fall über die RDP-Verbindung verfügbar sein sollen.
Meine Fragen wären:
Hat jemand ähnliche Erfahrungen mit der Druckerumleitung über RDP bei bestimmten Anwendungen gemacht?
Wie kann man die lokalen Drucker in einem solchen Fall ohne Geschwindigkeitseinbuße einbinden?
Alle anderen Anwendung und die Druckerumleitung an sich funktionieren bei allen Anwendern übrigens ohne Probleme.
Vielen Dank!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 365599
Url: https://administrator.de/contentid/365599
Ausgedruckt am: 26.11.2024 um 06:11 Uhr
5 Kommentare
Neuester Kommentar
Hallo,
Nein, da bei uns generell keine lokalen Drucker in die Sitzung mitgenommen werden. Auch nicht bei Heimarbeit, Externen MA etc.
Wurde uns vor Ewigkeiten, als Siemens noch aktiv in der der PC/Server-Sparte Support leistete, empfohlen da das heftige Einbrueche in der Performance haben koennte. Scheint sich nicht geaendert zu haben. Selbiges gilt auch fuer USB, CD/DVD, was immer.
Wie gut ist den Deine Leitung?
BFF
Hat jemand ähnliche Erfahrungen mit der Druckerumleitung über RDP bei bestimmten Anwendungen gemacht?
Nein, da bei uns generell keine lokalen Drucker in die Sitzung mitgenommen werden. Auch nicht bei Heimarbeit, Externen MA etc.
Wurde uns vor Ewigkeiten, als Siemens noch aktiv in der der PC/Server-Sparte Support leistete, empfohlen da das heftige Einbrueche in der Performance haben koennte. Scheint sich nicht geaendert zu haben. Selbiges gilt auch fuer USB, CD/DVD, was immer.
Wie gut ist den Deine Leitung?
BFF
Hallo,
viele Anwendungen, z.B. auch Word, nutzen den aktuellen Standarddrucker um das Dokument zu rendern.
Vermutlich schickt die Anwendung in diesem Fall das ganze Dokumente in Rohform zum lokalen PC und zurück. Je nach Umfang dauert das einfach.
Abhilfe können hier 2 Dinge schaffen:
- Software besser programmieren (wird bei Datev schwierig)
- Einen anderen Drucker als Standard einstellen bevor man die Software startet. Das kann z.B. ein lokaler PDF-Drucker sein.
Stefan
viele Anwendungen, z.B. auch Word, nutzen den aktuellen Standarddrucker um das Dokument zu rendern.
Vermutlich schickt die Anwendung in diesem Fall das ganze Dokumente in Rohform zum lokalen PC und zurück. Je nach Umfang dauert das einfach.
Abhilfe können hier 2 Dinge schaffen:
- Software besser programmieren (wird bei Datev schwierig)
- Einen anderen Drucker als Standard einstellen bevor man die Software startet. Das kann z.B. ein lokaler PDF-Drucker sein.
Stefan
Hallo,
per rdp-Client durchgeschleifte Drucker rendern Dokumente bereits auf der Serverseite, d.h. der auf der Serverseite benutzte Druckertreiber bereitet die Druckdaten schon geräteabhängig auf. Aus den GDI-Anweisungen im Spoolfile wird schon der vom Clientdrucker direkt zu verarbeitende Datenstrom erzeugt. Dieser Renderprozess erzeugt, je nach Zieldrucker, ein mehrfaches an Datenvolumen gegenüber dem eigentlichen Spoolfile. Extrem wird es, wenn der Clientdrucker z.B. direkt Postscript verarbeiten möchte.
Da ich seit über 15 Jahren Terminalserver betreue sind mir diese Probleme hinreichend bekannt.
Lange Zeit habe ich nach Lösungen gesucht und habe verschieden Software von Drittanbietern getestet, die das Druckverfahren aufbrechen. Mögliche Lösungen sind Thinprint, Tricerat.Screwdrivers oder Slimprinter.
Letztendlich bin ich vor rund 10 Jahren bei Slimprinter geblieben (einfache Installation und Verwaltung, gutes Preis-Leistungsverhältnis, unaufdringliches Marketing und kostenloser Service).
Durch den Einsatz kommen noch weitere Verbesserungen hinzu, wie etwa konstante Druckernamen (ohne umgeleitet in xxx etc.) und eine zusätzliche Kompression der zu übertragenden Druckdaten.
Die Software kann ohne Anmeldung von Slimprinter.de heruntergeladen werden und läuft ohne Lizenzschlüssel für 20 Tage als uneingeschränkte Version.
Ich denke ein Test kann nicht schaden.
Gruß Crazy
per rdp-Client durchgeschleifte Drucker rendern Dokumente bereits auf der Serverseite, d.h. der auf der Serverseite benutzte Druckertreiber bereitet die Druckdaten schon geräteabhängig auf. Aus den GDI-Anweisungen im Spoolfile wird schon der vom Clientdrucker direkt zu verarbeitende Datenstrom erzeugt. Dieser Renderprozess erzeugt, je nach Zieldrucker, ein mehrfaches an Datenvolumen gegenüber dem eigentlichen Spoolfile. Extrem wird es, wenn der Clientdrucker z.B. direkt Postscript verarbeiten möchte.
Da ich seit über 15 Jahren Terminalserver betreue sind mir diese Probleme hinreichend bekannt.
Lange Zeit habe ich nach Lösungen gesucht und habe verschieden Software von Drittanbietern getestet, die das Druckverfahren aufbrechen. Mögliche Lösungen sind Thinprint, Tricerat.Screwdrivers oder Slimprinter.
Letztendlich bin ich vor rund 10 Jahren bei Slimprinter geblieben (einfache Installation und Verwaltung, gutes Preis-Leistungsverhältnis, unaufdringliches Marketing und kostenloser Service).
Durch den Einsatz kommen noch weitere Verbesserungen hinzu, wie etwa konstante Druckernamen (ohne umgeleitet in xxx etc.) und eine zusätzliche Kompression der zu übertragenden Druckdaten.
Die Software kann ohne Anmeldung von Slimprinter.de heruntergeladen werden und läuft ohne Lizenzschlüssel für 20 Tage als uneingeschränkte Version.
Ich denke ein Test kann nicht schaden.
Gruß Crazy