127132
20.06.2018
2031
18
0
Druckprobleme bei Thin Clients und Netzwerkdruckern
Morgen zusammen!
Bei uns werden in den Außenstellen HP t520 Thin Clients an drei W2k16 Terminalserver mittels RDP eingesetzt.
Die Außenstellen sind mit LTE, VDSL25 oder VDSL50 angebunden.
Die Server sind aktuell noch an einer 5 MBit CompanyConnect, die demnächst eine 10 MBit DeutschlandLAN Connect ersetzen wird.
Insgesamt läuft das alles rund. Das ERP wird per Terminalamulation angesprochen. Drucke daraus funktionieren auch tadellos und die Aufträge werden auch zügig gestartete.
Probleme machen im Grunde die Druckaufträge, aus allen anderen Anwendungen. Sprich Office-Geschichten. Gearbeitet wird mit LibreOffice. Aber auch das Ausdrucken aus Outlook 2016 (das ist als Standalone auf dem Terminalserver installiert) ist nicht das, was man als angenehm bezeichnet.
Oftmals kommt nach dem Klick auf den Druck-Button in der Anwendung das geniale "Keine Rückmeldung". Das liegt, so wie ich das sehe, daran, dass der Druckjob eben zuerst von der Außenstelle an den Druckserver in der Zentrale und dann wieder zurück an den Drucker in der Außenstelle gesendet wird.
In der Hälfte der Zeit läuft das auch wie geschnitten Brot. In der andern Hälfte brauchts für einen Druck einer DIN A4 Seite schon mal eine Minute, bis der Drucker endlich anfängt.
An welchen Stellschrauben kann ich da rumtüdeln, damit das nicht nur die halbe Zeit gut funktioniert? Ich bin momentan der Meinung, dass der Flaschenhals wohl die 5 MBit-Leitung ist.
Mehr als die dann kommenden 10 MBit sind aber nicht drin.
Im Netz bin ich auf ThinPrint gestoßen. Kann das was?
Oder gibts da andere Möglichkeiten die Situation zu verbessern?
Bei uns werden in den Außenstellen HP t520 Thin Clients an drei W2k16 Terminalserver mittels RDP eingesetzt.
Die Außenstellen sind mit LTE, VDSL25 oder VDSL50 angebunden.
Die Server sind aktuell noch an einer 5 MBit CompanyConnect, die demnächst eine 10 MBit DeutschlandLAN Connect ersetzen wird.
Insgesamt läuft das alles rund. Das ERP wird per Terminalamulation angesprochen. Drucke daraus funktionieren auch tadellos und die Aufträge werden auch zügig gestartete.
Probleme machen im Grunde die Druckaufträge, aus allen anderen Anwendungen. Sprich Office-Geschichten. Gearbeitet wird mit LibreOffice. Aber auch das Ausdrucken aus Outlook 2016 (das ist als Standalone auf dem Terminalserver installiert) ist nicht das, was man als angenehm bezeichnet.
Oftmals kommt nach dem Klick auf den Druck-Button in der Anwendung das geniale "Keine Rückmeldung". Das liegt, so wie ich das sehe, daran, dass der Druckjob eben zuerst von der Außenstelle an den Druckserver in der Zentrale und dann wieder zurück an den Drucker in der Außenstelle gesendet wird.
In der Hälfte der Zeit läuft das auch wie geschnitten Brot. In der andern Hälfte brauchts für einen Druck einer DIN A4 Seite schon mal eine Minute, bis der Drucker endlich anfängt.
An welchen Stellschrauben kann ich da rumtüdeln, damit das nicht nur die halbe Zeit gut funktioniert? Ich bin momentan der Meinung, dass der Flaschenhals wohl die 5 MBit-Leitung ist.
Mehr als die dann kommenden 10 MBit sind aber nicht drin.
Im Netz bin ich auf ThinPrint gestoßen. Kann das was?
Oder gibts da andere Möglichkeiten die Situation zu verbessern?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 377580
Url: https://administrator.de/forum/druckprobleme-bei-thin-clients-und-netzwerkdruckern-377580.html
Ausgedruckt am: 16.04.2025 um 12:04 Uhr
18 Kommentare
Neuester Kommentar
Hi,
wenn Ihr Office in 32bit verwendet, bleibt der Spooldienst für das Drucken in 32bit hängen!
Das Programm heist "spl64wow.exe" im Taskmanager, einfach, mal killen und dann geht es sofort weiter.
Man muß regestry settings setzen. Leider hab ich die gerad nicht zur Hand!
Gruß
Holli
wenn Ihr Office in 32bit verwendet, bleibt der Spooldienst für das Drucken in 32bit hängen!
Das Programm heist "spl64wow.exe" im Taskmanager, einfach, mal killen und dann geht es sofort weiter.
Man muß regestry settings setzen. Leider hab ich die gerad nicht zur Hand!
Gruß
Holli
Schon mal Danke dafür. Jedoch sind LibreOffice und Outlook jeweils in der 64-Bit-Version installiert.
Hi,
was ist mit dem Prozess "spl64wow.exe!" im Taskmanager?
Gruß
Holli
was ist mit dem Prozess "spl64wow.exe!" im Taskmanager?
Gruß
Holli
Nö, da ist kein solcher Prozess zu finden.
Ich hab jetzt auch was drucken lassen und natürlich funktionierts jetzt wieder einwandfrei.
Ich habe aber gerade in der Registry den Eintrag HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print gefunden.
Dort kann mann SplWOW64TimeOutSeconds anlegen, der überprüft ob der Prozess entladen werden muss.
Bin mir da aber nicht sicher, welche Einstellung man für den Timeout setzen soll. Und auch ob das dann tatsächlich die Lösung ist.
Ich hab jetzt auch was drucken lassen und natürlich funktionierts jetzt wieder einwandfrei.
Ich habe aber gerade in der Registry den Eintrag HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print gefunden.
Dort kann mann SplWOW64TimeOutSeconds anlegen, der überprüft ob der Prozess entladen werden muss.
Bin mir da aber nicht sicher, welche Einstellung man für den Timeout setzen soll. Und auch ob das dann tatsächlich die Lösung ist.
Guten Morgen holli.zimmi,
standen vor dem gleichen Problem. Mit ThinPrint konnte ich gute Erfahrungen machen wobei wir es wieder gelassen haben, es hat auch so geklappt allerdings mit einer 10er Leitung. Nimm dir mal deinen Printserver vor, am besten du ziehst den um per Export Import dann wirst du sehen (in meinem Fall war es so) das viele Einstellungen Treiber etc. nicht exportiert werden können wg. defekt etc. Schau dir auch die Firewallrules im VPN an, hier kann man einiges an Traffic sparen wenn man lange genug analysiert
Wenns dann noch nix ist dann musst du halt wirklich auf Thinprint ausweichen.
PS: auch die Treiber machen hier viel Unterschied
Gruß user217
standen vor dem gleichen Problem. Mit ThinPrint konnte ich gute Erfahrungen machen wobei wir es wieder gelassen haben, es hat auch so geklappt allerdings mit einer 10er Leitung. Nimm dir mal deinen Printserver vor, am besten du ziehst den um per Export Import dann wirst du sehen (in meinem Fall war es so) das viele Einstellungen Treiber etc. nicht exportiert werden können wg. defekt etc. Schau dir auch die Firewallrules im VPN an, hier kann man einiges an Traffic sparen wenn man lange genug analysiert
Wenns dann noch nix ist dann musst du halt wirklich auf Thinprint ausweichen.PS: auch die Treiber machen hier viel Unterschied
Gruß user217
Hm....danke schon mal für den Einblick in ThinPrint.
Der Druckerserver ist auf dem DC und wurde vor Kurzem (also unter 12 Monate) neu installiert. Da sollte eigentlich nix querliegen. Aber genau diese eigentlich-Fälle können das Problem sein. Ich schau mal.
Es sind halt die Original-Kyocera-Treiber.
Den Lancom muss ich mir da auch mal anschauen, was man da noch machen kann. Danke für die Tipps.
Zum ThinPrint....was genau ist das nun eigentlich? Ist das ein eigener Printserver oder wie läuft das?
Der Druckerserver ist auf dem DC und wurde vor Kurzem (also unter 12 Monate) neu installiert. Da sollte eigentlich nix querliegen. Aber genau diese eigentlich-Fälle können das Problem sein. Ich schau mal.
Es sind halt die Original-Kyocera-Treiber.
Den Lancom muss ich mir da auch mal anschauen, was man da noch machen kann. Danke für die Tipps.
Zum ThinPrint....was genau ist das nun eigentlich? Ist das ein eigener Printserver oder wie läuft das?
So wie ich das verstanden habe ist das mehr oder weniger nur ein Treiber der den Druckjob komprimiert..
Schau mal am printserver ins ereignisprotokoll unter Microsoft/print (muss erst aktiviert werden) und gib das zeug per csv nach Excel aus und sortiere mal nach jobgröße dann wirst du sehen das manche 2-seitigen pdfs oft 100-300 MB Jobs produzieren. Evtl. kann man damit schon sehr viel erreichen.
Mit QOS am Lancom würde ich mich dann später spielen, denke das bringt wohl nicht so mega viel
PS: die Kyocera Classic Universaldriver PCL 1.42.1601.0 funktionieren mit 2100er Druckern relativ stabil auf einem 2012er Server.
Schau mal am printserver ins ereignisprotokoll unter Microsoft/print (muss erst aktiviert werden) und gib das zeug per csv nach Excel aus und sortiere mal nach jobgröße dann wirst du sehen das manche 2-seitigen pdfs oft 100-300 MB Jobs produzieren. Evtl. kann man damit schon sehr viel erreichen.
Mit QOS am Lancom würde ich mich dann später spielen, denke das bringt wohl nicht so mega viel
PS: die Kyocera Classic Universaldriver PCL 1.42.1601.0 funktionieren mit 2100er Druckern relativ stabil auf einem 2012er Server.
Super!
Danke für die Tipps.
Ich werd da mal rumpfuschen.
Danke für die Tipps.
Ich werd da mal rumpfuschen.
Moin,
auch wenn du nur Orginal-Treiber des Herstellers verwendest ist es manchmal schon ein großer Unterschied ob es "normale" oder z.B. PCL6-Treiber sind. Das hat bei uns (mit Samsung-Druckern) einen Teilerfolg bei der selben Problematik gebracht.
Henning
auch wenn du nur Orginal-Treiber des Herstellers verwendest ist es manchmal schon ein großer Unterschied ob es "normale" oder z.B. PCL6-Treiber sind. Das hat bei uns (mit Samsung-Druckern) einen Teilerfolg bei der selben Problematik gebracht.
Henning
Hi,
wenn es mal geht und mal "nicht" (nur mit Kunstpause) dann würde ich als erstes mal den Druckjob verfolgen. Also
Das verschafft mir dann schon mal ein Bild davon, wo tatsächlich die Kunstpause entsteht.
Wenn ich zum Schluss komme, dass es zuletzt am Druckgerät liegen könnte, dann würde ich z.B. mal den Energiesparmodus für eine Weile deaktivieren. Wenn es dann immer noch auftritt, dann hat es nichts mit dem Aufwachen zu tun, wenn doch, dann hätte man schon mal einen konkret Verdächtigen.
ThinPrint kann eine gute Sache sein. Das müsste man erstmal testen und Aufwand, Kosten und Nutzen gegeneinander abwägen. Es ist ja nicht ganz billig. In keinen Fall würde ich jetzt aus purem AktionismusThinprint einführen wollen ...
Edit: Und auch nicht an den Treibern rumpfummeln.
Wie sind die Druckgeräte überhaupt angeschlossen? Am ThinClient über USB oder direkt am LAN/WLAN?
E.
wenn es mal geht und mal "nicht" (nur mit Kunstpause) dann würde ich als erstes mal den Druckjob verfolgen. Also
- wann drucke ich, (Klick, Enter)
- wann landet der Druckjob in der Warteschlange auf dem Printserver,
- wann wird dieser von dort an den Drucker gesendet,
- wann sagt die Warteschlange "ich habe gedruckt",
- wann fängt das Druckgerät an zu melden "empfange Daten" und
- wann beginnt das Druckgerät, tatsächlich zu drucken
Das verschafft mir dann schon mal ein Bild davon, wo tatsächlich die Kunstpause entsteht.
Wenn ich zum Schluss komme, dass es zuletzt am Druckgerät liegen könnte, dann würde ich z.B. mal den Energiesparmodus für eine Weile deaktivieren. Wenn es dann immer noch auftritt, dann hat es nichts mit dem Aufwachen zu tun, wenn doch, dann hätte man schon mal einen konkret Verdächtigen.
ThinPrint kann eine gute Sache sein. Das müsste man erstmal testen und Aufwand, Kosten und Nutzen gegeneinander abwägen. Es ist ja nicht ganz billig. In keinen Fall würde ich jetzt aus purem AktionismusThinprint einführen wollen ...
Edit: Und auch nicht an den Treibern rumpfummeln.
Wie sind die Druckgeräte überhaupt angeschlossen? Am ThinClient über USB oder direkt am LAN/WLAN?
E.
1
Von solchen Konstrukten würde ich absehen. Der MS-Support wird da schnell komisch, wenn du ihn mal brauchen wolltest. Printserver lieber einzeln oder zusammen mit Fileserver. DC wenn möglich immer AD/DNS/DHCP auf einer Maschine und mehr nicht, ggf. noch TermServ-Lizenz-Server aber das wars dann auch.
DC wenn möglich immer AD/DNS/DHCP
Das wäre dann genauso falsch. DHCP-Admin muss nicht gleich AD-Admin sein, und umgekehrt.
Was hat das mit dem Admin zu tun?
Es geht darum welche Rollen der Server übernimmt wegen automatischen Richtlinien usw. und AD geht nicht ohne DNS und das sollte auch ein MS-DNS sein und kein Bind oder Router-DNS.
Es geht darum welche Rollen der Server übernimmt wegen automatischen Richtlinien usw. und AD geht nicht ohne DNS und das sollte auch ein MS-DNS sein und kein Bind oder Router-DNS.
DNS - ja schön. Ich schrieb aber von DHCP.
Zitat von @emeriks:
Hi,
wenn es mal geht und mal "nicht" (nur mit Kunstpause) dann würde ich als erstes mal den Druckjob verfolgen. Also
Das verschafft mir dann schon mal ein Bild davon, wo tatsächlich die Kunstpause entsteht.
Wenn ich zum Schluss komme, dass es zuletzt am Druckgerät liegen könnte, dann würde ich z.B. mal den Energiesparmodus für eine Weile deaktivieren. Wenn es dann immer noch auftritt, dann hat es nichts mit dem Aufwachen zu tun, wenn doch, dann hätte man schon mal einen konkret Verdächtigen.
Hi,
wenn es mal geht und mal "nicht" (nur mit Kunstpause) dann würde ich als erstes mal den Druckjob verfolgen. Also
- wann drucke ich, (Klick, Enter)
- wann landet der Druckjob in der Warteschlange auf dem Printserver,
- wann wird dieser von dort an den Drucker gesendet,
- wann sagt die Warteschlange "ich habe gedruckt",
- wann fängt das Druckgerät an zu melden "empfange Daten" und
- wann beginnt das Druckgerät, tatsächlich zu drucken
Das verschafft mir dann schon mal ein Bild davon, wo tatsächlich die Kunstpause entsteht.
Wenn ich zum Schluss komme, dass es zuletzt am Druckgerät liegen könnte, dann würde ich z.B. mal den Energiesparmodus für eine Weile deaktivieren. Wenn es dann immer noch auftritt, dann hat es nichts mit dem Aufwachen zu tun, wenn doch, dann hätte man schon mal einen konkret Verdächtigen.
Ja, da muss ich mal genau nachverfolgen. Energiesparmodus könnte da ein Kandidat sein.
ThinPrint kann eine gute Sache sein. Das müsste man erstmal testen und Aufwand, Kosten und Nutzen gegeneinander abwägen. Es ist ja nicht ganz billig. In keinen Fall würde ich jetzt aus purem AktionismusThinprint einführen wollen ...
Edit: Und auch nicht an den Treibern rumpfummeln.
Wie sind die Druckgeräte überhaupt angeschlossen? Am ThinClient über USB oder direkt am LAN/WLAN?
Die sind alle per LAN angeschlossen. Ich dachte kurz mal dran, die testweise per USB dranzuhängen, hab das aber wieder sofort verworfen, da ich ja mehrere User für einen Drucker hab und nicht immer nur je ThinClient einen Drucker. Außerdem würde es da meiner Meinung nach noch mehr Probleme geben.Und zum Rest:
Installiert sind die PCL6-Treiber. Ich werd hier wohl mal die Universal-PCL-Dinger testen.
Der Printserver ist auf dem DC nebst DNS und DHCP. Würde ich jetzt nicht wirklich von vornherein als problematisch ansehen.
Der Printserver ist auf dem DC nebst DNS und DHCP. Würde ich jetzt nicht wirklich von vornherein als problematisch ansehen.
Rein technisch nicht. Das geht so.Zitat von @user217:
PS: die Kyocera Classic Universaldriver PCL 1.42.1601.0 funktionieren mit 2100er Druckern relativ stabil auf einem 2012er Server.
PS: die Kyocera Classic Universaldriver PCL 1.42.1601.0 funktionieren mit 2100er Druckern relativ stabil auf einem 2012er Server.
Ich habe jetzt nochmal die Universaltreiber (3.10.1225) von der Kyocera-Homepage runtergeladen und installiert und den Drucker dann ersetzen lassen.
Es scheint gut zu funktionieren.
Ich bin vorsichtig optimistisch.
Da es noch immer problemlos läuft (bis jetzt) stell ich dann schon mal auf gelöst.
Danke nochmal an alle!
Danke nochmal an alle!
