Zebra Etikettendrucker in einer Remote Desktop Farm nutzen

Druckermapping in Remote Desktop Terminalserver-Umgebungen waren schon immer ein Problem. Es hat sich zwar seit Windows Server 2012 mit dem easyPrint Treiber einiges gebessert, aber Sonderdrucker wie z.B. Zebra Etikettendrucker, die via “Generic / Text only” Treiber angesprochen werden, machen hier leider noch das ein oder andere Problem.

Der Zebra Etikettendrucker benötigt zum Drucken von ZPL Kommandos den Generic Treiber.

Die ZPL Befehle werden hier mit 1:1 an den Drucker übergeben. Es gibt zwar auch die Möglichkeit einen Imagetreiber wie z.b. den von Seagull zu verwenden, aber wenn wir eine Applikation haben, die ZPL Codes verwendet, führt leider kein Weg am Generic Treiber vorbei.

Am “Generic / Text Only” gibt es eigentlich nicht viel einzustellen. In den meisten Fällen reicht es, den Drucker via USB oder Netzwerk mit dem Client zu verbinden und los zudrucken.

Es kann jedoch aber auch sein, dass die Code-Page, eine sogenannte Übersetzungstabelle, eine Änderung benötigt.

Die Code Page Einstellung im Treiber steht Standardmäßig auf “US (ANSI) (1252)”.

Diese Einstellung macht aber vor allem beim Drucken von Umlauten und Sonderzeichen am Zebra Etikettendrucker Probleme, vor allem wenn es sich um deutschsprachige Systeme handelt.

Die Lösung ist hier natürlich am Client die CodePage Einstellung auf “Multilingual – Latin 1 (850) zu stellen. Somit werden die ZPL Codes korrekt in die jeweilige Landessprache konvertiert und der Barcode-Ausdruck inkl. Sonderzeichen passt nach dieser Umstellung auch wieder.

Zebra Etikettendrucker – lokal und remote

Das ganze funktioniert am Client wunderbar, nicht jedoch, wenn der Drucker dann auf einem Remote Server gemappt wird.

Hier macht als Erstes das easyPrint Probleme, denn dies tauscht den CodePage Treiber einfach durch einen Image-Treiber aus und versucht somit die ZPL Kommandos als Image am Drucker zu drucken.

Als Ergebnis bekommen wir beim Drucken am Zebra Etikettendrucke lauter schöne ZPL Kommandos auf dem Ausdruck zu sehen. Nicht gerade das, was wir uns wünschen.

Da der “Generic / Text Only” Treiber den meisten Windows Betriebssystemen beiliegt, kann hier das EasyPrint deaktiviert werden.

Als ersten Schritt erstellen wir eine GPO, die auf den Remotedesktop Hosts das EasyPrint erst als zweite Wahl auswählt.

Hier wird im ersten Step versucht den lokalen Druckertreiber, wenn er am Remotedesktop Host vorhanden ist, zu verwenden. Schlägt dies fehl, wird auf den EasyPrint Treiber gewechselt.

Nach erneutem Verbinden auf den RD Host sieht man nun im Drucker, dass der “Generic / Text Only” Treiber auch in der Remote Sitzung verwendet wird. So weit, so gut.

Money: Die 7 einfachen Schritte zur finanziellen Freiheit

(868)

32,54 € (von 25. Dezember 2024 08:51 GMT +01:00 - Mehr InformationenProduct prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on [relevant Amazon Site(s), as applicable] at the time of purchase will apply to the purchase of this product.)

Beim Ausdruck erkennt man aber auch hier, dass irgendetwas noch nicht passt.
Der Ausdruck ist auf den ersten Blick richtig, alle Barcodes und Angaben sind auf dem Etikett. Jedoch bei genauerer Betrachtung sieht man, dass alle Umlaute und Sonderzeichen wieder falsch übersetzt wurden.

Wenn wir nun am RemoteDesktop-Host in die Zebra Etikettendrucker Druckereigenschaften schauen, sehen wir, dass die CodePage wieder auf den Defaultwert “US (ANSI) (1252)” steht.

Obwohl also am lokalen Client die richtige multilingual Code Page eingestellt wurde, wird dies beim Mapping auf dem RD Host nicht übernommen.

Auch ein Anpassen der CodePage innerhalb der RD Sitzung ging nicht. Man konnte zwar den Wert ändern, aber sobald man das Menü schloss und erneut öffnete war der Default Wert wieder da.

Eine Lösung des Problems konnte also nur sein, den Default Wert des Treibers auf “Multilingual” zu setzen. Dies ist so einfach, aber nicht machbar.

Eine Analyse der Registry als auch der geänderten Dateien beim Umstellen der CodePage ergab, dass der Defaultwert scheinbar direkt im Treiber fest hinterlegt wurde. Es gibt also kein Default Registry Eintrag, den man hierfür einfach ändern könnte.

So war es leider auch.
Dennoch gibt es hierzu eine Lösung.

Ein eigener Treiber

Microsoft hat im WDK Driver Sample Paket den SourceCode vom Treiber veröffentlicht.

Das Paket gibt es hier:
Windows driver code samples

Nach dem Ändern der Default Werte im Quellcode und neu Kompilieren der DLL Dateien war der Default Wert nun auf Multilingual gestellt.

Nach dem Installieren des umprogrammierten Treibers klappte auch das Etikett Drucken über eine Remote Session ohne Probleme.

Es ist wichtig zu beachten, dass beim Erstellen eines eigenen Treibers einige Vorsichtsmaßnahmen getroffen werden müssen, um sicherzustellen, dass der Treiber ordnungsgemäß funktioniert und keine Probleme mit anderen Komponenten des Systems verursacht. Es ist empfehlenswert, den Treiber in einer Testumgebung zu installieren und zu testen, bevor er in einer produktiven Umgebung verwendet wird.

Es ist auch wichtig, die Dokumentation und Anweisungen des WDK Driver Sample Pakets sorgfältig zu lesen, um sicherzustellen, dass der Quellcode korrekt geändert und kompiliert wird. Insbesondere sollte man darauf achten, dass die Änderungen an den Default Werten nicht zu unerwarteten Problemen führen.

Noch eine Information:
So wie es aussieht, hat Microsoft die Website geändert. Man findet den Quellcode aber noch im WDK Paket für Server 2012 unter folgendem Link:
https://code.msdn.microsoft.com/windowsapps/Windows-Driver-Kit-WDK-80-e3161626/view/SourceCode

Dies ist die mir einzige bekannte Lösung um ZPL basierte Drucker ordentlich mit deutschen ERP Lösungen zu nutzen.