none
Druckproblem mit per RDP umgeleiteten Druckern unter Server 2012 RRS feed

  • Frage

  • Hallo,

    wir haben mehrere Server 2012 Terminalserver. Beim Kunden sind auf dem Client lokal oder auch per Netzwerk Drucker installiert (Windows XP, Windows 7, Windows 8). Die Drucker des Clients werden per RDP in die RDP Session reinverbunden. Sobald ich TS Easy Print aktiviert habe klappt auch der Ausdruck problemlos.

    Wenn ich jedoch Easy Print ausschalte, also über die konventionellen Druckertreiber drucken will klappt das nicht. Der Drucker wird in die RDP Sitzung reinverbunden und dort auch mit dem korrekten Treiber angezeigt. Wenn ich jedoch etwas ausdrucke kommt die Meldung "Fehler - wird gedruckt" in der Auftragswarteschlange und es kommt nichts am Drucker raus. Es wird nicht mal an die lokale Warteschlange des PCs übermittelt. 

    Auf Clients und Server ist die gleiche Version der Druckertreiber installiert. Das Ganze betrifft Server 2012 als TS egal mit welchem Clientbetriebssystem. Wir haben es mit Kyocera, Utax und Samsung Druckertreibern getestet - überall das gleiche Problem. Auch in unserer Testumgebung konnten wir das Problem nachstellen.

    Bevor die Frage auftaucht warum wir nicht einfach Easy Print verwenden - weil die Druckdatenströme dort größer sind und in Filialen mit schwacher Anbindung der Druck sehr lange dauert. Mit konventionellen Treibern ist das nicht so.

    Hat jemand einen Tip?

    Gruß Christoph

    Dienstag, 28. Mai 2013 13:44

Antworten

  • Hatten einen Call bei MS offen. Lösung ist nicht die KX Treiber zu verwenden sondern die KPDL. Mit diesen Treibern funktionierts jetzt bei uns. Allerdings haben diese Treiber eine etwas abgespeckte Oberfläche im Vergleich zu den KX Treibern. Aber die gehn wenigstens. 

    Was ich allerdings nicht verstehe: Auch der KX Treiber ist 2012 zertifiziert und wird sogar über den Windows Update Catalog von MS zum Download angeboten...obwohl er nicht richtig funktioniert.

    Gruß Christoph

    Freitag, 12. Juli 2013 08:27

Alle Antworten

  • Hallo Christoph,

    besteht das Problem weiterhin? Wenn ja, um eine mögliche Lösung zu Deiner Frage zu finden, müssen wir einen privaten Kommunikationskanal mit Dir
    erstellen. Dieser nutzt auch um zusätzliche Informationen zu sammeln.

    Kannst Du bitte eine e-Mail an dieser
    E-Mail-Adresse mit Deinem Namen, Deiner e-Mail-Adresse und Telefonnummer senden, damit wir Dich erreichen zu können?

    Danke und Grüße,
    Alex



    Alex Pitulice, MICROSOFT 
    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip„IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.


    Donnerstag, 30. Mai 2013 09:54
    Moderator
  • Problem besteht noch, habe wie gewünscht eine E-Mail an die angegebene Adresse geschrieben.

    Danke, Gruß Christoph

    Sonntag, 2. Juni 2013 19:45
  • Ab Windows 8/Windows Server 2012 hat sich das zugrundeliegenden Drucker-Architektur geändert.

    Wurde dem Rechnung getragen und auf dem Windows Server 2012 Servern auch zertifizierte und für Windows Server 2012 freigegebene Druckertreiber installiert?

    S.a.:

    http://msdn.microsoft.com/en-us/library/windows/hardware/hh706306(v=vs.85).aspx und http://msdn.microsoft.com/en-us/library/windows/hardware/hh852373

    --

    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net

    Montag, 3. Juni 2013 07:37
  • Ja wir haben den aktuellsten Kyocera bzw. Utax Treiber installiert. Diese sind laut Hersteller für Server 2012 freigegeben.
    Montag, 3. Juni 2013 08:00
  • Wir haben exakt das gleiche Problem. Gibt es dazu schon eine Lösung?
    Freitag, 12. Juli 2013 08:20
  • Hatten einen Call bei MS offen. Lösung ist nicht die KX Treiber zu verwenden sondern die KPDL. Mit diesen Treibern funktionierts jetzt bei uns. Allerdings haben diese Treiber eine etwas abgespeckte Oberfläche im Vergleich zu den KX Treibern. Aber die gehn wenigstens. 

    Was ich allerdings nicht verstehe: Auch der KX Treiber ist 2012 zertifiziert und wird sogar über den Windows Update Catalog von MS zum Download angeboten...obwohl er nicht richtig funktioniert.

    Gruß Christoph

    Freitag, 12. Juli 2013 08:27
  • Hallo,

    ich weiß das ist schon alt aber ich habe aktuell auch schon länger das Problem.

    Windows Server 2012 R2 auf dem sich die User über REMOTE Desktop anmelden.

    Der lokale Netzwerkdrucker wird in die Sitzung mit durchgeschleift.

    Wenn der User vom Server dann ausdruckt ist das Dokument in der Druckwarteschlange ruckzug vom Server zum Client gewandert. Auf dem Client dauert es aber dann 20  Seiten ausdrucken mehr als 35 Minuten.

    Auf den Clients(WIN10PRO) ist der der Kyocera FS-1370 DN mit dem original KX Treiber der Microsoft signiert ist installiert. 

    Der Versuch mit dem XPS Treiber scheitert und es funktioniert gar nix. Der Versuch KPDL funktioniert auch nicht da werden von 20 Seiten nur 6 gedruckt.

    Komisch ist wenn ich mir das Dokument auf dem Server in Druckwarteschlange anschaue ist das Dokument nur paar Kilobyte oder höchstens 1,5 MB groß. Wenn ich mir es in der Druckwarteschlange auf dem Clint dann anschaue hat das gleiche Dokument utopisch mehr Größe irgendetwas zwischen 16 MB und 35 MB.

    Ist echt nervig auf das Dokument so lange zu warten.

    Hat jemand eine Lösung. Außer Drucker tauschen. 50 Drucker deswegen tauschen ist keine Lösung. Früher ging es ja auch reibungslos. Testhalber habe ich auch schon mal den Arbeitsspeicher auf dem Drucker aufgerüstet aber bringt auch nix.

    Vielen Dank

    Montag, 8. Juli 2019 14:38
  • Wenn der Datenstrom so anwächst deutet das auf z.T. inkompatible Treiber hin.
    Hier wird dann u.U. der Ausdruck per Windows-GDI bereits als Bitmap gerendert und dann zum Drucker geschickt.
    Dann benötigt dieser natürlichsehr viel Speicher um diese Bitmaps zu drucken.

    Was ich nicht verstehe ist, warum der originale Druckertrieber des Herstellers nicht funktioniert.
    Ich habe z.B. den Epson-Workplace lokal als Netzdrucker mit den Epson-Treibern und kann per RDP-Umleitung vom Server ganz normal und zügig drucken (Win 10 1903).

    Montag, 8. Juli 2019 16:14
  • Haben Client und Server den gleichen Treiber installiert und ist per GPO der Remote Easy Print deaktiviert?

    Admin Templates -> Windows Components -> Remote Desktop Services -> RD Session Host -> Printer Redirection -> Use Remote Desktop Easy Print printer driver first -> disabled.

    Alternativ mal mit dem HP Laserjet 4 Treiber versuchen:
    Client to Server Print Driver Mapping: https://www.brianmadden.com/feature/How-Terminal-Server-for-Windows-Server-2003-Printing-Works


    Dienstag, 9. Juli 2019 10:42
  • Moin,

    Fragen dazu:

    1. Sind die Drucker auf den Clients direkt per TCP/IP angebunden oder ist ein Printserver dazwischen?
    2. Falls Letzteres: Habt ihr versucht, den Printserver direkt vom TS anzusteuern? Sofern er da netzwerktechnisch rankommt...
    3. Was passiert, wenn man das gleiche Dokument (sofern Programme dazu installiert sind) direkt vom Client druckt?
    4. Gibt es bei diesem Verhalten einen Unterschied zwischen Office-Dokumenten und PDFs?

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Dienstag, 9. Juli 2019 11:36
  • Auf den Servern sind die Druckertreiber nicht hinterlegt. Auf dem Server nutzen wir den REMOTE EASY PRINT. Würde auch ehrlich gesagt ungern auf diese Möglichkeit verzichten.

    Ich habe es auch schon wenn immer die Gelegenheit war mit anderen Druckermodellen(bzw. Herstellern) zu probieren. Da läuft es flüssig und zügig.

    Die Drucker sind per TCP/IP an den Clients angebunden.

    Gleiches Dokument direkt am Client läuft zügig.

    Zwischen Office und PDF leider kein Unterschied.

    Habe auch mittlerweile 2 KYOCERA Ecosys P2135DN im Einsatz. noch nicht mal Treiber getauscht auf Client und es läuft wesentlich flüssiger. Da stockt er noch nicht mal zwischen den Seiten. Druckt hintereinander weg. Diese Gerät hat ja doppelt so viel RAM wie der 1370. Also beim 1370 den RAM aufgerüstet auf das Maximum. Null Änderung.

    Die Dokumente sind in der Schriftart Calibri. (Ist leider vom QM vorgegeben) Früher hatten die Dokumente eine Linotype Schriftart Namens LT Ergo. Calibri ist doch eine Standartschriftart sollte dann doch eigentlich besser sein. Kann mir nicht vorstellen das das so gravierende Auswirkungen haben sollte.

    Mittwoch, 10. Juli 2019 07:28
  • Calibri ist ein Softfont (Opentype).
    Wenn es da u.U. eine Inkompatibilität gibt, wird eine Schrift als Bitmap gerendert was das Datenvolumen erklärt.
    Kannst du mal eine andere Standarschrift, z.B. Arial oder Times New Roman, probieren und das Verhalten prüfen?

    Ggf. noch mal die installierten Schriften, Client und Server abgleichen.

    Mittwoch, 10. Juli 2019 13:50
  • Hallo,

    so ich hatte nun noch mal die Gelegenheit zum testen. Das Thema beschäftigt mich schon eine geraume Zeit. Da aber auch noch andere Sachen angelegen haben Ihr wisst schon was ich meine. Die Vermutung mit der Schriftart hatte ich schon mal so im Gefühl.

    Der Test hat folgendes ergeben.

    Ein Worddokument 6 Seiten DIN A4 ist die Basis.

    Schriftart Calibri  ist das Dokument in der Druckwarteschlange auf dem Server 457 kB groß auf dem Client in   der Druckwarteschlange auf dem Client ist es dann 18,4 MB groß und dauert vom Start des Druckvorganges bis es fertig gedruckt ist 7 Minuten

    Schriftart Arial Server 508 kB  Client 7,16 MB  Druckzeit  1,3 Minuten

    Schriftart Time New Roman  Server 583 kB   Client 10,9 MB  Druckzeit  2,58 Minuten

    Und zu guter letzt die angesprochene Schriftart

    Schriftart LT ERGO  Server  5,81 MB  Client  6,64 MB      Druckzeit  52 Sekunden

    Die Schriftarten sind alle auf dem Server und auch auf den Client installiert. Calibri, Arial, TimeNewRoman ja mit der Windows Installation. LT Ergo Separat auf den Clients und den Servern.

    Wie schon geschrieben ging meine Tendenz schon in die Richtung Schriftart. Aber das dies so grass ist und solche Auswirkungen hat hätte ich nicht gedacht, vor allem weil Calibri ja eigentlich eine Standartschriftart ist die mit Windows mitgeliefert wird.

    Gibt es vielleicht irgendwie eine Möglichkeit das es doch mit Calibri flüssiger wird.

    Von der LT ergo hat man sich getrennt weil diese nicht ExCELfähig war und Calibri kommt dem am nächsten.

    Donnerstag, 11. Juli 2019 14:54
  • LT Ergo scheint in soweit spezial zu sein, dass diese Schrift grundsätzlich als Bitmap bereits vom Server an den Drucker geht.
    True-/Opentype sind generell Softfonts und je nach Type eben mehr oder weniger komplex.
    Jedes Zeichen wird dann als eine Reihe von Zeichnenanweisungen, Linien, Formen, Vielecke, Kurven usw.
    Nun muss jeder Druckertreiber über seine Eigenschaften dem Windows mitteilen, was er an direkten GDI-Funktionien unterstützt. Windows wählt dann die Druckersteteuerung aus oder, was eben nicht unterstützt wird, wird als Bitmap gerendert.
    Und da kann man sich eben ausrechnen, das bei einer Druckerleistung von 600DPI im 4-Farbmodus 600x600x32-Bit je Zollquadrat gesendet werden müssen.
    Der Drucker benötigt daher dann auch viel Speicher um die Seite intern dann aufzubauen was wiederum auch Rechenzeit bedeutet.

    Daher ist es manchmal auch besser, mal zu prüfen welche Schriftarten durch den Drucker bereits integriert sind.
    Dann wird der Ausdruck plötzlich erheblich schneller.
    Auch sollte man in Erfahrung bringen, ob der Drucker True-/Opentypefonts native unterstützt.
    In diesem Fall sendet Windows den Font an den Drucker und dann halt nur noch Text und Stilanweisungen.

    So schafft ihr ja kaum die 20 Seiten/Minute oder mehr, die so ein Drucker ja inzwischen leisten kann.
    Denn auch 52 Sekunden für 6 Seiten finde ich da schon sehr langsam.

    Donnerstag, 11. Juli 2019 15:33
  • Hallo bfuerchau,

    Danke erst mal für das Schnelle Feedback.

    Das ist leider wahr das wir von dem Punkt 20 Seiten/Minute meilenweit entfernt sind. Die 52 Sekunden sind schon Welten.

    Was ich aber nicht verstehe das im Drucker die Schriftart Calibri als Scalable drauf ist. Habe mir die Schriftartenliste mit den auf dem Drucker vorhandenen Schriften ausgedruckt. Calibri auch Standard Fett Kursiv.

    Times New Roman ist auch drauf Standard fett kursiv.

    Arial lediglich fett

    LT Ergo logischerweise nicht.

    Sollte ich einfach mal das Dokument testhalber mit den installierten Schriftarten die es laut Fontliste vom Drucker gibt ausprobieren und die Zeit stoppen? Zumindest die es auch im Windows gibt.

    Ob der Drucker  True-/Opentypefonts native unterstützt werde ich mal heute Abend recherchieren.

    Donnerstag, 11. Juli 2019 16:21
  • Hallo,

    ich habe heute mal noch was anderes probiert.

    Im Druckertreiber hab ich Text und Bild auf nur Schwarz/Weiß bei den beiden punkten gesetzt. Ist ja auch kein Farbdrucker.

    Gleiches Dokument wie schon beschrieben 6 DIN A4 Seiten in Calibri

    Druckwarteschlange Server   568 kB

    Druckwarteschlange Client    1,89 MB sofort rasselt aber den ganz fix auf 5,68 MB 

    Druckjob  vom Klick auf Drucken bist Drucker beginnt 20 Sekunden, das komplette Dokument fertig in 36 Sekunden. Wahnsinn zu vorher 7 Minuten.

    Das scheint aber definitiv echt nur mit Kyocera so ein Problem zu sein.

    Ich habe es gerade mal von zu Hause aus ausprobiert wo ich leider nur eine nicht mal 2 Mbit DSL Leitung habe. Und da hab ich folgende Geräte stehen.

    Brother MFC 7360

    Druckwarteschlange Server 400 KB

    Druckwarteschlange Client Druck als Bild im Treiber 400 kB         Fertig gedruckt in 56 Sekunden

    Druckwarteschlange Client Druck als Text im Treiber 480 kB        Fertig gedruckt in 41 Sekunden

    Und dann mal zum Test HP Color LaserJet CP5225

    Druckwarteschlange Server  457 kB

    Druckwarteschlange Client  11,4 MB  Fertig gedruckt in 1,20 Minuten

    Das es auf Farbdrucker länger dauert ist miir schon klar. Aber selbst die 1,20 sind ja welten zu 7 Minuten bei VDSL50. Der Server wo es herkommt hat ein SDSL25. Die Bandbreite spielt schon auch mit rein in die Sache,

    Aber ist schon krass. Ob meine Variante nun die GOLD Variante ist mal dahingestellt. Wenn jemand noch andere Vorschläge und Ideen hat bin ich offen dafür.

    Freitag, 12. Juli 2019 20:12
  • Die Druckerhersteller machen es sich da inzwischen ganz schön einfach,  da die sog. Windows GDI (Graphical Device Interface) eben alles im Endeffekt in Bitmaps rastern kann wenn der Drucker selber eben die Grafikanweisungen wie Bezier-Kurven u.ä. nicht native unterstützen.
    Da hatte ich mich schon zu Zeiten des Nadeldruckers, ca. 90er Jahre, gewundert, was da plötzlich so alles gedruckt werden konnte.

    Das ist eben der Unterschied zu den Grafikkarten, die sich ja geradezu bemühen alle möglichen Standards von GDI, GDI+, OpenGL und DirectX native zu unterstützen um optimale Performance herauszuholen.
    Die Bildschirmdarstellungen werden schon bei Office2016, WPF u.s.w., immer komplexer, so dass auch hier RDP z.T. nicht mehr mit den benötigten Bandbreiten zurechtkommt.
    Ich muss z.B. für Office2016 über RDP auf 2-MBit und Highcolor (16-Bit) reduzieren um noch einiger maßen zügig arbeiten zu können.

    Was die Druckerleistungen angeht, so sind die Angaben von X Seiten/Minute i.d.R. für den Copy-Modus angegeben. D.h., wenn die Seite nach 1 Minute gerendert ist, kann sie danach in 1 Miunte 20 Mal gedruckt werden.

    Wie oben bereits mitgeteilt:
    Das Volumen der Daten berechnet sich aus DPI (Dots per Inch) und dem Farbmodus.
    RGB = 24 Bit, ARGB = 32Bit, CMYK = 32-Bit, Graustufen (Schwarzweiß) = 8 Bit.
    Anzumerken ist noch, dass ein Dot ein Farbpunkt ist und nicht ein logisches Pixel.
    Also ein 600DPI 4-Farbdrucker kann eben mit 75 Pixeln Bilder drucken.

    Die Seitenaufbereitung bei dir scheint aber ebenso grundsätzlich länger zu dauern als deine DSL-Rate.
    Zum Rechnen:

    2 Megabit / Sekunde ca. 250KB / Sekunde, macht in 1 Minute ca. 15MB.
    Die Frage ist also, wie und wann du gemessen hast.

    Samstag, 13. Juli 2019 09:54
  • Ich habe gestoppt vom Klick auf den Button Drucken im Word auf dem REMOTE Server wo ich angemeldet bin. Bis zu dem Zeitpunkt wo er fertig ist mit drucken.

    Auf dem Server ist der Druckjob auch ruckzuck weg und hat auch eine realistische Größe. Auf dem Client in der Druckwarteschlange steigt dann die Größe von dem Dokument.

    Der Vergleich  6 Seiten in 7 Minuten zu 6 Seiten in 36 Sekunden sind ja schon Welten.

    Was mich so stutzen lässt warum wachsen die Druckjobs die vom Server kommen und dort nur paar kB groß sind, wenn Sie dann auf dem Client sind so massiv in der Größe anwachsen. 

     
    Sonntag, 14. Juli 2019 17:51
  • Wie ich bereits versucht habe zu erklären.
    Auf dem Server wird im Prinzp, ggf. auch tatsächlich) eine WMF-Datei (Windows-Meta-File) erstellt:
    https://de.wikipedia.org/wiki/Windows_Metafile

    Diese WMF ist nichts weiter als eine Aufzeichnung der Windows-GDI-Befehle zur Darstellung von grafischem Output.
    Der Empfangsjob im Client hat nun nichts weiter zu tun, als eben diese WMF abzuspielen und gibt dabei den Device-Context des Druckers an, der GDI-Befehle via Treiber ausführt.
    Nun liegt es am Treiber, was er daraus dann tatsächlich macht, da hat Windows selber dann keinen Einfluss drauf.

    Was dann beim Drucker native ankommt, kann man z.B. durch eine Umleitung in eine Datei (Anschlusseinstellung des Druckers) analysieren.

    Bei PCL5/6 wird u.U. ein Font in den Drucker geladen, da auch True/Opentype-Fonts nur als eine Reihe von GDI-Funktionen vorliegen und daher abspielbar sind.
    https://www.pclviewer.com/de/resources/font_selection.html
    Dies reduziert das Datenvolumen erheblich und beschleunigt u.U. auch die Seitenaufbereitung im Drucker.

    Bei Kyocera besteht anscheined diese Funktion nicht, so dass die Schrift eben gerastert werden muss.
    Dies lässt sich z.B. durch die Dateianalyse (ist halt etwas mühsam) feststellen.

    Bei Kyocera gibt es einen TrueType-Fontdownloader:
    https://www.kyoceradocumentsolutions.de/index/serviceworld/downloadcenter.false.utility.KMC3225._.EN.html
    Für OpenType scheint es da nichts vergleichbares zu geben.

    Montag, 15. Juli 2019 07:38
  • Danke erst mal für die Hinweise. Ich habe jetzt 2 Standorte erst mal auf den Druckern die Schriftart über den TrueType-Fontdownloader draufgepackt. Dann habe ich den Drucker auf KPDL gestellt und den aktuelsten KX- Treiber von Kyocera installiert. Nach einigen Testen und spielen im Treiber läuft es erst mal relativ flüssig. Das lasse ich erst mal so laufen bei en 2 Standorten bevor ich das beim Rest mache.

    Die zwei Standorte sind auch angehalten Feedbacks zu liefern. 

    Donnerstag, 22. August 2019 15:56