Drucken an Server 2012 R2 über RDP zu langsam
Hallo zusammen!
Hoffentlich kann mir hier jemand helfen.
Wir haben folgendes Szenario:
Ein Hotel mit zwei Standorten (Hotel und Privathaus), die über zwei Lancoms per VPN Tunnel verbunden sind. Beim Privathaus steht der Server, auf den jeweils vom Hotel als auch vom Privathaus per RDP zugegriffen wird. Auf dem Server befindet sich eine Software, die eben von beiden Standorten erreichbar sein muss.
Alle Client-PCs haben Windows 7 Pro SP1 x64. Im Hotelstandort gibt es zwei Arbeitsplätze mit insgesamt 4 Druckern. Jeder Arbeitsplatz hat zwei Drucker.
Im Zuge des Umstiegs von Server 2003 auf 2012 R2 wurde die Art der Druckerweiterleitung geändert; bisher wurden die per RDP mitgenommen und haben wunderbar funktioniert.
Mit 2012 R2 hat das nicht mehr ohne Probleme funktioniert, weshalb wir dazu umgestiegen sind, alle Drucker im Netzwerk freizugeben und lokal auf dem Server im Privathaus zu installieren. Im Zuge dessen mussten wir die Firewalls deaktivieren, da trotz Firewallfreigaben die Kommunikation nicht übers Netzwerk möglich war.
Beim zweiten Arbeitsplatz hat das mit der RDP-Mitnahme der Drucker seltsamerweise aber wiederum funktioniert. Deshalb wurde hier nichts geändert.
Wir haben nun das generelle Problem, dass das Drucken in den anderen Standort über RDP zu lange dauert. Die Wartezeit pro Druck beträgt gute 15 Sekunden, das ist zu lange. Auch wenn der Laserdrucker aufgewärmt ist, dauert der Druckvorgang so lange.
Testweise haben wir uns von unserem Standort mit der Mitnahme eines unseren Druckers dort per RDP eingeloggt und das Drucken auf unserem Drucker hat mitsamt Aufwärmen dann auch 20 Sekunden gedauert. Wenn man vor Ort auf einen der im Netzwerk freigegebenen Druckern per USB Anschluss druckt, druckt der Drucker ganz normall schnell.
Und solange der Druck in Arbeit ist, ist ein Arbeiten mit der Software, aus der gedruckt wird, nicht möglich (sie wartet softwarebedingt auf die Fertigstellung des Drucks).
Ich habe schon versucht, clientseitig die bidirektionale Druckerunterstützung zu deaktivieren, ohne Erfolg.
Ich habe in den Gruppenrichtlinien festgelegt, dass zuerst der EasyPrint Treiber versucht werden soll, ohne Erfolg.
Ich weiß inzwischen auch nicht mehr weiter. Es muss sich zwischen Server 2003 und 2012 R2 irgendetwas grundlegendes geändert haben, denn sonst hätte das ja von Anfang an funktionieren müssen.
Ich habe noch gelesen, dass man dem Server den identischen Treiber bereitstellen lassen muss, aber ist das in 2012 R2 noch gültig? Die Anleitung von MS verweist dazu auf Server 2008 oder sogar ganz auf 2003er Server.
Kann mir jemand helfen? Was wäre der beste Weg, um sozusagen von Grundauf alles neu zu konfigurieren *from scratch*, sozusagen; Sowohl vom Sever als auch von den Client-PCs alle Treiber entfernen und neu aufspielen?
Danke erstmal für eure Hilfe!
MfG
Max Gembe
Hoffentlich kann mir hier jemand helfen.
Wir haben folgendes Szenario:
Ein Hotel mit zwei Standorten (Hotel und Privathaus), die über zwei Lancoms per VPN Tunnel verbunden sind. Beim Privathaus steht der Server, auf den jeweils vom Hotel als auch vom Privathaus per RDP zugegriffen wird. Auf dem Server befindet sich eine Software, die eben von beiden Standorten erreichbar sein muss.
Alle Client-PCs haben Windows 7 Pro SP1 x64. Im Hotelstandort gibt es zwei Arbeitsplätze mit insgesamt 4 Druckern. Jeder Arbeitsplatz hat zwei Drucker.
Im Zuge des Umstiegs von Server 2003 auf 2012 R2 wurde die Art der Druckerweiterleitung geändert; bisher wurden die per RDP mitgenommen und haben wunderbar funktioniert.
Mit 2012 R2 hat das nicht mehr ohne Probleme funktioniert, weshalb wir dazu umgestiegen sind, alle Drucker im Netzwerk freizugeben und lokal auf dem Server im Privathaus zu installieren. Im Zuge dessen mussten wir die Firewalls deaktivieren, da trotz Firewallfreigaben die Kommunikation nicht übers Netzwerk möglich war.
Beim zweiten Arbeitsplatz hat das mit der RDP-Mitnahme der Drucker seltsamerweise aber wiederum funktioniert. Deshalb wurde hier nichts geändert.
Wir haben nun das generelle Problem, dass das Drucken in den anderen Standort über RDP zu lange dauert. Die Wartezeit pro Druck beträgt gute 15 Sekunden, das ist zu lange. Auch wenn der Laserdrucker aufgewärmt ist, dauert der Druckvorgang so lange.
Testweise haben wir uns von unserem Standort mit der Mitnahme eines unseren Druckers dort per RDP eingeloggt und das Drucken auf unserem Drucker hat mitsamt Aufwärmen dann auch 20 Sekunden gedauert. Wenn man vor Ort auf einen der im Netzwerk freigegebenen Druckern per USB Anschluss druckt, druckt der Drucker ganz normall schnell.
Und solange der Druck in Arbeit ist, ist ein Arbeiten mit der Software, aus der gedruckt wird, nicht möglich (sie wartet softwarebedingt auf die Fertigstellung des Drucks).
Ich habe schon versucht, clientseitig die bidirektionale Druckerunterstützung zu deaktivieren, ohne Erfolg.
Ich habe in den Gruppenrichtlinien festgelegt, dass zuerst der EasyPrint Treiber versucht werden soll, ohne Erfolg.
Ich weiß inzwischen auch nicht mehr weiter. Es muss sich zwischen Server 2003 und 2012 R2 irgendetwas grundlegendes geändert haben, denn sonst hätte das ja von Anfang an funktionieren müssen.
Ich habe noch gelesen, dass man dem Server den identischen Treiber bereitstellen lassen muss, aber ist das in 2012 R2 noch gültig? Die Anleitung von MS verweist dazu auf Server 2008 oder sogar ganz auf 2003er Server.
Kann mir jemand helfen? Was wäre der beste Weg, um sozusagen von Grundauf alles neu zu konfigurieren *from scratch*, sozusagen; Sowohl vom Sever als auch von den Client-PCs alle Treiber entfernen und neu aufspielen?
Danke erstmal für eure Hilfe!
MfG
Max Gembe
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 276052
Url: https://administrator.de/contentid/276052
Ausgedruckt am: 22.11.2024 um 19:11 Uhr
8 Kommentare
Neuester Kommentar
Moin,
LG, Thomas
Im Zuge dessen mussten wir die Firewalls deaktivieren, da trotz Firewallfreigaben die Kommunikation nicht übers Netzwerk möglich war.
was hat Drucken im VPN mit der firewall zu tun? Jetzt läuft da in beiden Netzen keine mehr ?Kann mir jemand helfen?
Ganz sicher --> ruf doch einfach ein Systemhaus an, damit sich da ein Fachkundiger das Dilemma mal vor Ort anschaut ...LG, Thomas
Moin.
Was habt ihr denn überhaupt für eine WAN-Leitung ? 15 s. ist eigentlich noch vertretbar wenn es hier um eine durchschnittliche DSL-Leitung geht, je nachdem wie groß euer Upstream und wie groß die Dokumente sind die gedruckt werden.
Gruß jodel32
Wir mussten die Firewalls an den Client-PCs deaktivieren, da wir sonst nicht von den anderen PCs im VPN Netz auf den dort freigegebenen Drucker zugreifen konnten.
Muss man eben nicht komplett, das ist Humbug, denn es reicht wenn man die Datei- und Druckerfreigabe auf dem Client der den Drucker freigibt in der erweiterten Firewall auch aus anderen Subnetzen zulässt ! Denn per default ist das nur aus dem eigenen Subnetz erlaubt. Standardfehler den viele machen wenn sie mit VPNs und anderen Subnetzen arbeiten.Was habt ihr denn überhaupt für eine WAN-Leitung ? 15 s. ist eigentlich noch vertretbar wenn es hier um eine durchschnittliche DSL-Leitung geht, je nachdem wie groß euer Upstream und wie groß die Dokumente sind die gedruckt werden.
Mit 2012 R2 hat das nicht mehr ohne Probleme funktioniert, weshalb wir dazu umgestiegen sind,
Was waren das denn für Probleme ?Gruß jodel32
Hallo Max,
leider hast Du keine Angaben zu den Druckermodellen und auch zur Art der Software gemacht.
Prinzipiell kann man aber festhalten, das die Druckeranbindung über VPN im gegensatz zu mitgenommenen
rdp-Druckern immer langsamer sein wird. Was das Nachteiligste an beiden Geschichten ist: Es werden immer die gerenderten Druckerdaten übertragen.
Easyprint bremst dann noch mehr, weil zunächst serverseitig ein XPS-File erzeugt wird, zum client übertragen wird und dort in den Devicecontext des Zieldruckers ausgegeben wir (also XPS-->GDI-->rendern für den Zieldrucker). Zugleich funktioniert Easyprint nicht mit allen Druckermodellen. Für Easyprint ist also serverseitig kein installierter Druckertreiber in gleicher Version wie auf dem Client erforderlich. Verzichtet man auf Easyprint ist natürlich ein gleicher Treiber auf dem Server erforderlich (egal ob 2008 oder 2012).
Da ich einige Kunden mit Terminalservern betreue, wo Außenstellen zum Teil recht schmalbandig angebunden sind, hatte ich natürlich auch manchen Trouble und habe nach Auswegen gesucht und spezielle Software für das Drucken auf Terminalservern getestet. Da waren z.B. Tricerat, Thinprint und Slimprinter. Allen ist eins gemeinsam: Sie versenden die serverseitig generierten GDI-Anweisungen komprimiert über einen virtuellen Kanal des rdp und rendern diese Daten erst auf dem Client für den Zieldrucker. D.h. es ist nur eine funktionierende rdp-Verbindung nötig (die natürlich auch im VPN gekapselt sein kann) und es gibt keine Firewallprobleme mit der Datei- und Druckerfreigabe.
Slimprinter hat sich für mich inzwischen als 'die Lösung' herauskristallisert (einmalige Kosten, keine Wartungsgebüren, kostenloser lebenslanger Service und Updates, beste Nachbildung der Clientdrucker in der rdp-Sitzung z.B. Papiere, Schächte etc.)
Die downloadbare Version (www.slimprinter.de) geht 20 Tage für 5 User als Vollversion und kann ohne jede Registrierung gezogen werden. Ein Test lohnt immer!
Crazy
leider hast Du keine Angaben zu den Druckermodellen und auch zur Art der Software gemacht.
Prinzipiell kann man aber festhalten, das die Druckeranbindung über VPN im gegensatz zu mitgenommenen
rdp-Druckern immer langsamer sein wird. Was das Nachteiligste an beiden Geschichten ist: Es werden immer die gerenderten Druckerdaten übertragen.
Easyprint bremst dann noch mehr, weil zunächst serverseitig ein XPS-File erzeugt wird, zum client übertragen wird und dort in den Devicecontext des Zieldruckers ausgegeben wir (also XPS-->GDI-->rendern für den Zieldrucker). Zugleich funktioniert Easyprint nicht mit allen Druckermodellen. Für Easyprint ist also serverseitig kein installierter Druckertreiber in gleicher Version wie auf dem Client erforderlich. Verzichtet man auf Easyprint ist natürlich ein gleicher Treiber auf dem Server erforderlich (egal ob 2008 oder 2012).
Da ich einige Kunden mit Terminalservern betreue, wo Außenstellen zum Teil recht schmalbandig angebunden sind, hatte ich natürlich auch manchen Trouble und habe nach Auswegen gesucht und spezielle Software für das Drucken auf Terminalservern getestet. Da waren z.B. Tricerat, Thinprint und Slimprinter. Allen ist eins gemeinsam: Sie versenden die serverseitig generierten GDI-Anweisungen komprimiert über einen virtuellen Kanal des rdp und rendern diese Daten erst auf dem Client für den Zieldrucker. D.h. es ist nur eine funktionierende rdp-Verbindung nötig (die natürlich auch im VPN gekapselt sein kann) und es gibt keine Firewallprobleme mit der Datei- und Druckerfreigabe.
Slimprinter hat sich für mich inzwischen als 'die Lösung' herauskristallisert (einmalige Kosten, keine Wartungsgebüren, kostenloser lebenslanger Service und Updates, beste Nachbildung der Clientdrucker in der rdp-Sitzung z.B. Papiere, Schächte etc.)
Die downloadbare Version (www.slimprinter.de) geht 20 Tage für 5 User als Vollversion und kann ohne jede Registrierung gezogen werden. Ein Test lohnt immer!
Crazy
Hallo Max!
Wir haben eine ähnliche Aufstellung, nur eben mit mehreren Standorten.
Wir arbeiten auch auf Terminal Servern (2003 und 2012R2)
Wir haben das Problem vor kurzem gelöst!
Tsprint funktioniert super und ist sein Geld Wert gewesen.
Es installiert am TerminalServer einen Virtuellen lokalen drucker.
Die Software schickt den Druckauftrag lokal weg und das wegschicken des Druckauftrages dauert somit nur 1 bis 2 Sekunden.
Im Hintergrund läuft auf dem Client PC nun die TSPrint Client Software welche den Druckauftrag annimmt und an den Drucker weiterleitet.
Das ganze kann man sogar soweit einrichten, dass man dem Virtuellen Drucker den Originaltreiber des richtigen Druckers zuweisen kann. Dann hat man auch 100% Kompabilität erreicht.
Infos und Trial:
http://www.terminalworks.com/remote-desktop-printing
MfG
Matthias
Wir haben eine ähnliche Aufstellung, nur eben mit mehreren Standorten.
Wir arbeiten auch auf Terminal Servern (2003 und 2012R2)
Wir haben das Problem vor kurzem gelöst!
Tsprint funktioniert super und ist sein Geld Wert gewesen.
Es installiert am TerminalServer einen Virtuellen lokalen drucker.
Die Software schickt den Druckauftrag lokal weg und das wegschicken des Druckauftrages dauert somit nur 1 bis 2 Sekunden.
Im Hintergrund läuft auf dem Client PC nun die TSPrint Client Software welche den Druckauftrag annimmt und an den Drucker weiterleitet.
Das ganze kann man sogar soweit einrichten, dass man dem Virtuellen Drucker den Originaltreiber des richtigen Druckers zuweisen kann. Dann hat man auch 100% Kompabilität erreicht.
Infos und Trial:
http://www.terminalworks.com/remote-desktop-printing
MfG
Matthias
@Matthias
TSPrint von Terminalworks ist mir ebenfalls bekannt. Allerdings genügt das Programm nur geringen Anforderungen, da die Clientdrucker nicht ebenbürtig auf dem TS abgebildet werden. Es wird nur der Standarddrucker des Clienten verfügbar gemacht. Weitere Drucker sind zwar bei Verwendung des Druckers TSPrinter im Dialog auswählbar, aber es kann nicht von druckenden Programm etwas zugewiesen werden, also unhandlich. Somit zwar PnP aber reicht das in der Praxis?
TSPrint berücksichtigt nicht die vorhanden Auflösungen und Papierformate eines Clientdruckers.
Spezielle Drucker wie Bon-Drucker oder Drucker mit Spezialfunktionen (Lochen, Heften etc.) werden absolut nicht unterstützt, da bei Bedarf nur umständlich ein Originaltreiber verwendet werden kann.
Support ist nur in Englisch bei entsprechendem Versatz der Zeitzonen möglich. Slimprinter ist ein deutsches Produkt mit deutschen oder englischem Support, auch das wäre zu überlegen.
Für mich also fraglich, ob das das Geld wert ist.
@max
Wenn die alten Drucker lokal funktionieren werden sie auch mit Slimprinter funktionieren. Der Übergang von x86 zu x64 und umgekehrt spielt keine Rolle. Da du mehrere Drucker vom Client bedienen willst (mußt) spielt TSPrint für dich nicht mit der richtigen Musik.
Gruß Crazy
TSPrint von Terminalworks ist mir ebenfalls bekannt. Allerdings genügt das Programm nur geringen Anforderungen, da die Clientdrucker nicht ebenbürtig auf dem TS abgebildet werden. Es wird nur der Standarddrucker des Clienten verfügbar gemacht. Weitere Drucker sind zwar bei Verwendung des Druckers TSPrinter im Dialog auswählbar, aber es kann nicht von druckenden Programm etwas zugewiesen werden, also unhandlich. Somit zwar PnP aber reicht das in der Praxis?
TSPrint berücksichtigt nicht die vorhanden Auflösungen und Papierformate eines Clientdruckers.
Spezielle Drucker wie Bon-Drucker oder Drucker mit Spezialfunktionen (Lochen, Heften etc.) werden absolut nicht unterstützt, da bei Bedarf nur umständlich ein Originaltreiber verwendet werden kann.
Support ist nur in Englisch bei entsprechendem Versatz der Zeitzonen möglich. Slimprinter ist ein deutsches Produkt mit deutschen oder englischem Support, auch das wäre zu überlegen.
Für mich also fraglich, ob das das Geld wert ist.
@max
Wenn die alten Drucker lokal funktionieren werden sie auch mit Slimprinter funktionieren. Der Übergang von x86 zu x64 und umgekehrt spielt keine Rolle. Da du mehrere Drucker vom Client bedienen willst (mußt) spielt TSPrint für dich nicht mit der richtigen Musik.
Gruß Crazy