Netzwerkdrucker Terminalserver Umgebung langsam
Der Druck über einen im Terminalserver eingebundenen Netzwerkdrucker ist sehr langsam, sobald er jedoch vom lokalen Rechner weitergeleitet wird ist er gewohnt schnell.
Hallo,
ich habe ein kleines Problem mit unserem Terminalserver. Standort A ist über S-DSL mit einem anderen Standort B verbunden. Auf Standort A wird eine Anwendung ausgeführt, aus dieser die User von Standort B drucken müssen.
Natürlich möchten die User von Standort B auf die gewohnten Drucker zugreifen, also binde ich im Terminalserver den Drucker erneut ein. Allerdings ist der Druck unheimlich langsam. Leite ich allerdings die Drucker über die RDP Verbindung weiter, geht alles gewohnt schnell.
Hat jemand eine Idee woran das liegen kann? Die Umgebung ist Windows Server 2003 auf den Servern und XP auf den Clients.
Laut dem vorherigen Admin lief das ganze jedoch schon einmal über eine Einbindung der Drucker auf dem Terminalserver.
Die Druckaufträge haben nur eine geringe Größe.
Gruß
hanswurst
Hallo,
ich habe ein kleines Problem mit unserem Terminalserver. Standort A ist über S-DSL mit einem anderen Standort B verbunden. Auf Standort A wird eine Anwendung ausgeführt, aus dieser die User von Standort B drucken müssen.
Natürlich möchten die User von Standort B auf die gewohnten Drucker zugreifen, also binde ich im Terminalserver den Drucker erneut ein. Allerdings ist der Druck unheimlich langsam. Leite ich allerdings die Drucker über die RDP Verbindung weiter, geht alles gewohnt schnell.
Hat jemand eine Idee woran das liegen kann? Die Umgebung ist Windows Server 2003 auf den Servern und XP auf den Clients.
Laut dem vorherigen Admin lief das ganze jedoch schon einmal über eine Einbindung der Drucker auf dem Terminalserver.
Die Druckaufträge haben nur eine geringe Größe.
Gruß
hanswurst
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 176044
Url: https://administrator.de/forum/netzwerkdrucker-terminalserver-umgebung-langsam-176044.html
Ausgedruckt am: 22.12.2024 um 19:12 Uhr
4 Kommentare
Neuester Kommentar
Moin,
Ist ja eher die Frage was der Druckertreiber daraus macht. Wenn der Drucker z.B. keine Rastereinheit hat, erstellt der Druckertreiber eine recht große Bitmap.
Das fällt im lokalen Netzwerk nicht auf, im WAN aber schon.
Die Einbindung durch RDP vereinheitlicht und verschlankt diesen Vorgang. Nicht immer zum besseren.
Was spricht also bei Dir dagegen drucken durch RDP zu nutzen?
Alternativ könntest Du andere Druckertreiber oder Druckereinstellungen probieren.
Stefan
Ist ja eher die Frage was der Druckertreiber daraus macht. Wenn der Drucker z.B. keine Rastereinheit hat, erstellt der Druckertreiber eine recht große Bitmap.
Das fällt im lokalen Netzwerk nicht auf, im WAN aber schon.
Die Einbindung durch RDP vereinheitlicht und verschlankt diesen Vorgang. Nicht immer zum besseren.
Was spricht also bei Dir dagegen drucken durch RDP zu nutzen?
Alternativ könntest Du andere Druckertreiber oder Druckereinstellungen probieren.
Stefan
Ich würde es auch für wahrscheinlich halten, daß der auf dem Terminalserver (nicht über RDP) eingerichtete Druckertreiber Roh-Daten, also Bitmaps an den Drucker schickt. Ich glaube, das ist nicht unüblich.
Der per RDP eingebundene Drucker wird dann wohl erst auf dem Remodedesktop rastern (obwohl er ja für die Sitzung auf dem Terminalserver ebenso als Druckertreiber auf dem Terminalserver installiert wird). (Genau weiß ich's nicht.)
Alternativ könnte es noch ein Netzwerk-Problem sein mit dem "Anschluß"/"Anschluß-Typ": Vielleicht bekommt der Terminalserver nur schlecht Kontakt über den manuell von Dir am Terminalserver eingerichteten "Anschluß" in's Netzwerk-B (IP-Adresse/Freigabe), also Namensauflösung. Während der RDP-Druckerdreiber ja quasi vom Terminalserver aus durch den RDP-Tunnel den Remote-PC ohne Eingriffe zuverlässig erreichen/auflösen kann, und dann über Remote-PCs direkte/zuverlässige LAN-Verbindung zum Drucker geht.
Du könntest auch mal am Terminalserver mit "type Textdatei.txt > \\<Drucker-IP-Standort-B>\" experimentieren.
Gruß,
Harald
Der per RDP eingebundene Drucker wird dann wohl erst auf dem Remodedesktop rastern (obwohl er ja für die Sitzung auf dem Terminalserver ebenso als Druckertreiber auf dem Terminalserver installiert wird). (Genau weiß ich's nicht.)
Alternativ könnte es noch ein Netzwerk-Problem sein mit dem "Anschluß"/"Anschluß-Typ": Vielleicht bekommt der Terminalserver nur schlecht Kontakt über den manuell von Dir am Terminalserver eingerichteten "Anschluß" in's Netzwerk-B (IP-Adresse/Freigabe), also Namensauflösung. Während der RDP-Druckerdreiber ja quasi vom Terminalserver aus durch den RDP-Tunnel den Remote-PC ohne Eingriffe zuverlässig erreichen/auflösen kann, und dann über Remote-PCs direkte/zuverlässige LAN-Verbindung zum Drucker geht.
Du könntest auch mal am Terminalserver mit "type Textdatei.txt > \\<Drucker-IP-Standort-B>\" experimentieren.
Gruß,
Harald
Hallo Hans,
ich gebe dem Vorredner völlig recht, es ist mmer eine Frage was der Druckertreiber an Output erzeugt.
Ich glaube dein Problem kann aber z.B. mit Slimprinter gelöst werden. Da können beliebige Clientdrucker ausgewählt werden!
Auch der Datentransfer wird flotter gehen, da nicht der Output des Druckertreibers sondern nur die GDI-Befehle in komprimierter Form übertragen werden.
Die Anzeige der Druckerdialoge sind ebenfalls sehr schnell, da keine RPC-Aufrufe erfolgen.
Last but not least spielt die Architektur 32/64bit keine Rolle.
Als für 3 Netzwerke mit TS verantwortlicher Admin und weltweit verstreuten Remoteclients benutze ich Slimprinter seit mehreren Jahren mit großer Zufriedenheit.
Gruß Softprogger
ich gebe dem Vorredner völlig recht, es ist mmer eine Frage was der Druckertreiber an Output erzeugt.
Ich glaube dein Problem kann aber z.B. mit Slimprinter gelöst werden. Da können beliebige Clientdrucker ausgewählt werden!
Auch der Datentransfer wird flotter gehen, da nicht der Output des Druckertreibers sondern nur die GDI-Befehle in komprimierter Form übertragen werden.
Die Anzeige der Druckerdialoge sind ebenfalls sehr schnell, da keine RPC-Aufrufe erfolgen.
Last but not least spielt die Architektur 32/64bit keine Rolle.
Als für 3 Netzwerke mit TS verantwortlicher Admin und weltweit verstreuten Remoteclients benutze ich Slimprinter seit mehreren Jahren mit großer Zufriedenheit.
Gruß Softprogger