Funktionieren Etikettendrucker unter Windows Protected Print noch? ZPL, EPL und die Mopria-Frage

Warum industrieller Etikettendruck einer der härtesten Fälle im WPP-Umfeld ist – und wie Sie Ihre Druckpfade prüfen

Funktionieren Zebra-Etikettendrucker unter Windows Protected Print noch?

Als Gerät ja. Über den Windows-Druckpfad in der Regel nicht. Der Grund liegt in einer Bedingung, die Microsoft ausdrücklich formuliert: „Windows protected print mode builds on the existing IPP print stack where only Mopria certified printers are supported, and disables the ability to load third-party drivers.“

Aus dieser einen Aussage folgen zwei getrennte Konsequenzen, die in der Diskussion regelmäßig vermischt werden.

Erstens der Treiber. Der ZDesigner-Treiber von Zebra, der Honeywell-Treiber, der cab- oder SATO-Treiber sind aus Sicht von Windows Drittanbieter-Treiber. Bei Aktivierung von WPP werden sie deinstalliert und aus dem Treiberspeicher entfernt. HP beschreibt die Wirkung in seinem technischen WPP-Whitepaper unmissverständlich: „All v3 and v4 third party print drivers are prevented from installing onto Windows.“

Zweitens die Neuinstallation. Sie ist der eigentlich harte Teil, und Microsoft ist hier eindeutig: „Non-compatible printers are uninstalled and will be not able to be reinstalled while Windows protected print mode is enabled.“ Ein Etikettendrucker, den Windows nicht als kompatibel erkennt, lässt sich unter aktivem WPP nicht wieder einrichten – auch nicht mit einem anderen Treiber.

Eine Präzisierung, die für die weitere Argumentation wichtig ist: Microsoft spricht in der FAQ durchgehend von „non-compatible printers“, nicht von „nicht zertifizierten“ Geräten. Ein Abgleich gegen eine Zertifikatsliste ist nirgends dokumentiert. Maßgeblich ist die technische Kompatibilität mit dem IPP-Inbox-Treiber; die Mopria-Zertifizierung ist Microsofts Aussage darüber, welche Geräte diese Kompatibilität erfüllen. HP formuliert den funktionalen Zusammenhang so: „Failure to enable IPP Printing at the device will result in Windows seeing the device as a non-Mopria compliant device.“

Damit ist die Frage „Funktioniert mein Zebra-Drucker noch?“ falsch gestellt. Der Drucker funktioniert unverändert. Was entfällt, ist der Weg, auf dem Windows ihn erreicht.

Was passiert mit ZPL- und EPL-Druck unter WPP?

Der Datenstrom bleibt gültig, der Transportweg über Windows entfällt. Microsoft beschreibt den Formatumfang des treiberlosen Pfads präzise: „Driverless printing supports a limited number of PDLs based on public standards such as PWG Raster and PDF.“

ZPL und EPL sind keine öffentlichen Standard-PDLs. Sie sind herstellereigene Druckersprachen, und sie sind mehr als ein Seitenformat: Ein ZPL-Datenstrom enthält Koordinatenanweisungen, Feldpositionen, Schriftreferenzen und – entscheidend – Barcode-Befehle, die der Drucker selbst in Modulbreiten umsetzt. Dasselbe gilt für die verwandten Sprachen des Segments:

Die letzten drei Zeilen zeigen die Anforderung, an der es im Etikettensegment hängt: Für einen monochromen Drucker ist PWG Raster das einzige zwingend zu unterstützende Format. Ein Gerät, das ausschließlich ZPL versteht, erfüllt das nicht.

Für die Praxis heißt das: Wo eine Anwendung, ein WMS oder SAP den ZPL-Strom selbst erzeugt und über eine Windows-Warteschlange schickt, war der Windows-Treiber nie für das Rendering verantwortlich – er war nur der Durchgang. Genau dieser Durchgang ist der Teil, den WPP schließt.

Sind Etikettendrucker Mopria-zertifiziert?

Nein, und die Aussage lässt sich präziser belegen als über Zertifizierungslisten. Kein Spezialanbieter für industriellen Etikettendruck ist Mitglied der Mopria Alliance. Der Zugang zum Zertifizierungsverfahren ist nach der Mitglieder-Leistungsübersicht der Alliance an eine Mitgliedschaft ab Adopter-Ebene gebunden. In der öffentlichen Liste zertifizierter Produkte ist Zebra nicht als Hersteller auswählbar.

Stand der Mitgliederliste: 13. August 2026.

Gegen Alarmismus: Die Mitgliedschaft ist keine technische Sperre, sondern ein Marktsignal. Ein Beitritt steht jedem Hersteller offen, und die Tabelle kann sich ändern.

Gegen Aufschieben: Ein Beitritt allein reicht nicht. Die Mopria-Zertifizierung setzt IPP-Everywhere-Konformität voraus, und dort ist PWG Raster verpflichtend. Für einen Drucker, der bisher ausschließlich herstellereigene Sprachen interpretiert, ist das keine Formalie, sondern eine zusätzliche Rendering-Kette in der Firmware – also Entwicklungsarbeit, die diese Geräteklasse bisher nicht braucht. Wer seine Planung darauf stützt, dass die Bestandsflotte künftig zertifiziert wird, plant auf eine Absicht, die bis heute (Stand 13. August 2026) kein Hersteller dieses Segments öffentlich erklärt hat. Zwischen einer solchen Erklärung und einer zertifizierten Bestandsflotte liegen zudem Firmware- und Gerätelebenszyklen – im Etikettendruck typischerweise deutlich länger als im Bürodruck.

Der verbreitete Irrtum: Mein Etikettendrucker spricht IPP – ist er damit WPP-kompatibel?

Zebra-Link-OS-Drucker unterstützen IPP. Es gibt ein dokumentiertes Gerätesetting ip.ipp.mode mit den Werten ipp/ipps und ipps. Für in der EMEA-Region nach dem 1. August 2025 gekaufte Drucker ist ipps der Standardwert – ein Datum, das mit dem Wirksamwerden der Cybersecurity-Anforderungen der EU-Funkanlagenrichtlinie zusammenfällt und deshalb kein Indiz für den Reifegrad der IPP-Implementierung ist. Festzuhalten bleibt: IPP ist in diesem Segment kein Fremdwort.

Trotzdem folgt daraus keine WPP-Kompatibilität, weil unter WPP drei Bedingungen gleichzeitig erfüllt sein müssen:

Der Merksatz für die Flottenprüfung lautet deshalb: IPP-Fähigkeit ist eine Eigenschaft des Transportwegs. WPP-Kompatibilität ist eine Eigenschaft des gesamten Pfads, einschließlich Format und Attributen. Wer nur das Datenblatt auf „IPP“ prüft, kommt zu einem zu optimistischen Ergebnis.

Was ist mit dem RAW-Pfad über eine Generic-/Text-Only-Warteschlange?

Das ist die wichtigste Frage dieses Artikels für Bestandsumgebungen, weil dieser Pfad in Lager, Versand und Fertigung verbreitet ist – und weil er den Anschein von Unbetroffenheit hat.

Das Muster: Die Anwendung erzeugt den ZPL-Strom selbst. Auf dem Windows-System liegt eine Warteschlange mit dem Microsoft-Treiber „Generic / Text Only“ auf einem Standard-TCP/IP-Port, meist Port 9100. Windows rendert nichts, sondern schiebt die Bytes durch. Ein Herstellertreiber ist nicht im Spiel. Die naheliegende Schlussfolgerung – „uns trifft WPP nicht“ – ist mit Vorsicht zu behandeln, und zwar aus drei Richtungen.

Erstens die Warteschlangenerstellung. Unter aktivem WPP ändert sich der Weg, auf dem eine Warteschlange überhaupt entsteht. In einem Microsoft-Q&A-Thread zu genau dieser Frage schlägt der klassische Aufruf mit Port- und Treiberangabe fehl; funktionsfähig ist allein die Variante über die IPP-Adresse:

Bemerkenswert ist daran, dass im gescheiterten Aufruf gar kein Drittanbieter-Treiber vorkam, sondern der IPP-Klassentreiber selbst: Nicht der Treiber war das Hindernis, sondern der Weg über Port- und Treiberangabe. Für die RAW-Variante mit „Generic / Text Only“ auf einem Standard-TCP/IP-Port liegt kein entsprechender Bericht vor – die Übertragung auf diesen Fall ist eine Ableitung, kein Befund. Anzumerken ist außerdem, dass es sich um einen Community-Thread handelt: Die Beiträge stammen nicht von erkennbar gekennzeichneten Microsoft-Mitarbeitern, und die Aussage, dass die Hardware Mopria-konform und eingeschaltet sein muss, ist eine Community-Einschätzung, keine Produktdokumentation.

Zweitens der Portmonitor. Microsoft benennt den Portmonitor ausdrücklich als Teil der Angriffsfläche, die WPP schließen soll: „A common attack on Windows would abuse the fact that a printer port monitor can be a Dynamic Link Library (DLL), and attackers would abuse this to load malicious code.“ Die daraus angekündigte Durchsetzung ist die entscheidende Formulierung: „We’ll also enforce a restriction that ensures that only Microsoft Signed binaries required for IPP are loaded.“ Ein RAW-Portmonitor ist für IPP nicht erforderlich. Microsoft fasst den Effekt allgemein zusammen: „In Windows protected print mode, many legacy configurations are no longer valid.“

Drittens der Treiber selbst. „Generic / Text Only“ ist ein Microsoft-Treiber, aber ein v3-Treiber im klassischen Treibermodell – nicht der IPP-Inbox-Treiber. Microsoft formuliert die Deinstallation konsequent für Drittanbieter-Treiber; die Richtlinienbeschreibung stellt darauf ab, dass nur „a subset of inbox Windows print drivers“ zugelassen bleibt. Ob „Generic / Text Only“ zu dieser Teilmenge gehört, ist nicht dokumentiert. Das ist offen und gehört auf die Testliste.

Was hier belegt ist und was nicht – klar getrennt: Belegt ist, dass WPP das Laden von Binaries auf das für IPP Erforderliche beschränken soll, dass Portmonitore ein benanntes Ziel sind, dass Legacy-Konfigurationen ihre Gültigkeit verlieren und dass nicht kompatible Drucker unter aktivem WPP nicht neu installierbar sind. Nicht dokumentiert ist das Schicksal einer bereits bestehenden Generic-/Text-Only-Warteschlange auf einem Standard-TCP/IP-Port nach der WPP-Aktivierung. Genau das ist deshalb ein Pflicht-Testpunkt – er steht unten im Prüfprotokoll, und wer diesen Pfad produktiv nutzt, sollte ihn messen statt ihn anzunehmen.

Unberührt von all dem bleibt ein Pfad: Erzeugt die Anwendung den ZPL-Strom und sendet ihn selbst per TCP-Socket an Port 9100 oder per LPD an das Gerät, ohne Windows-Warteschlange, spielt das Treibermodell keine Rolle. Dieser Weg ist tragfähig – aber er ist pro Anwendung zu prüfen, nicht über die Windows-Druckverwaltung administrierbar und liefert weder zentrale Umleitung noch Statusrückmeldung noch Protokollierung. Er löst einzelne Prozesse, nicht die Flotte.

Zebra PDF Direct – ist das der Ausweg?

Zebra bietet mit PDF Direct eine Geräteemulation, die PDF-Dateien direkt auf dem Drucker verarbeitet, statt sie in der Anwendung nach ZPL zu konvertieren. Nach Zebras eigener Ankündigung ist die Funktion mit Wirkung zum 31. August 2020 ab Link-OS 6.3 kostenlos enthalten – vorher war sie eine kostenpflichtige Option. Sie gilt für die dort gelisteten Modellserien, nicht für die gesamte Flotte. Damit ist Bedingung 2 aus der Tabelle oben – das Gerät versteht ein Standardformat – für einen Teil der Geräte erfüllbar.

Was damit nicht gelöst ist:

Die Kompatibilitätsfrage bleibt offen. PDF Direct macht ein Gerät nicht Mopria-zertifiziert und sagt nichts darüber, ob das Gerät die vom IPP-Inbox-Treiber erwarteten Attribute veröffentlicht. Bedingung 3 ist unverändert die Grenze.

Die Barcode-Erzeugung wechselt die Zuständigkeit. Das ist der fachlich folgenreichste Punkt. Ein ZPL-Barcode-Befehl beschreibt dem Drucker den Code symbolisch; das Gerät setzt ihn in Modulbreiten um, die zur Druckauflösung passen – bei 203 dpi in ganzen Punkten. Kommt der Barcode dagegen als Grafik in einem PDF oder als Raster an, entscheidet die Rendering-Kette über die Modulbreiten, und Rundungen zwischen Rendering- und Druckauflösung werden möglich. Ob das im konkreten Fall die Bewertung nach ISO/IEC 15416 (lineare Symbole) bzw. ISO/IEC 15415 (2D-Symbole) beeinflusst, lässt sich nicht ableiten – es lässt sich nur mit einem Verifier messen. Bei GS1-pflichtigen oder kundenseitig gradingpflichtigen Etiketten ist diese Messung Teil der Abnahme, nicht eine optionale Zusatzprüfung.

Die Layoutkontrolle wird indirekt. Zebra selbst weist darauf hin, dass generische PDF-Renderer die Etikettenqualität „significantly reduce“ und die Laufzeit erhöhen. Genau deshalb liegt die Emulation im Gerät. Für eine Bestandsumgebung heißt das aber: Die Etikettenerzeugung muss auf PDF umgestellt werden – ein Eingriff in die Anwendung, nicht eine Konfigurationsänderung.

PDF Direct ist damit ein ernstzunehmender Baustein für neue Etikettenprozesse und kein Migrationspfad für eine gewachsene ZPL-Landschaft.

Reicht Universal Print für den Etikettendruck?

Für den Bürodruck an kompatiblen Geräten ist Universal Print eine belastbare Antwort auf den Wegfall des Windows-Druckservers. Für Etikettendruck ist es das derzeit nicht, und Microsoft dokumentiert das selbst mit ungewöhnlicher Deutlichkeit:

• „Label printing is currently limited to printing PDF documents.“ Ein RAW- oder ZPL-Pfad ist nicht vorgesehen.
• „However, since the industry standards for label printing are still a work in progress, full-featured support for label printing is not yet possible in Universal Print.“
• „Scaling is not supported.“ Der Skalierungswert bleibt unabhängig von den Vorgaben des Clients immer None.
• „When printing to a label printer from a Windows application, the print preview will not show the correct size and scale the label printer will produce.“

Dazu kommt eine Voraussetzung, die den Kreis unfreiwillig schließt. Der dokumentierte Etikettenpfad setzt den Universal Print Connector voraus: „Verify that label printers are installed on a PC running Universal Print connector 1.92.8740 or later.“ Der Connector läuft auf einem Windows-System, und die Drucker müssen dort installiert sein – „the connector can connect printers installed on that machine to Universal Print.“

Damit steht am Anfang des Microsoft-eigenen Etikettenpfads genau das, was WPP entfernt: eine Windows-Druckerwarteschlange für ein nicht kompatibles Gerät. Wer WPP auf dem Connector-Host aktiviert, prüft diesen Zusammenhang besser vorher als nachher.

Welche Etiketten-Druckpfade sind betroffen? Die Klassifizierung

Die Betroffenheit ergibt sich nicht aus dem Gerät und nicht aus dem Hersteller, sondern aus zwei Fragen: Wo entsteht der Datenstrom, und läuft er über eine Windows-Warteschlange?

Drei Zeilen dieser Tabelle verdienen eine Anmerkung.

Zeile 5 ist der Fall, der am häufigsten falsch eingeschätzt wird. Ein nativer SAP-Etiketten-Gerätetyp – etwa aus der LZEB-Familie für ZPL II oder LB_CAB für cab-JScript – erzeugt den fertigen Datenstrom im SAP-Spool. Kein Windows-Treiber rendert hier etwas. Trotzdem ist der Pfad betroffen, wenn die Übergabe über einen Windows-Host mit Druckerwarteschlange erfolgt: Nicht das Rendering ist das Problem, sondern die Warteschlange, die es für ein nicht kompatibles Gerät unter aktivem WPP nicht mehr gibt. Die Unterscheidung zwischen Gerätetyp und Kopplungsart ist deshalb keine Formalie – sie entscheidet den Fall.

Zur Konsistenz mit unserem Beitrag Betrifft Windows Protected Print den SAP-Druck?: Dort ist diese Konstellation als „nicht betroffen, mit Einschränkung bei der Warteschlange“ bewertet, weil die Datenstromerzeugung treiberfrei bleibt. Für Etikettendrucker greift genau diese Einschränkung, weil das Gerät nicht kompatibel ist. Die Bewertungen widersprechen sich nicht – sie betrachten unterschiedliche Glieder derselben Kette. Für die Praxis ist die Warteschlange das entscheidende Glied.

Zeile 7 gilt nicht transitiv. Die Kopplungsart E entkoppelt nur den Abschnitt zwischen SAP-Spool und Output-Management-System. Sie ist allein kein Nachweis der WPP-Unabhängigkeit, sondern verlagert die Frage eine Ebene weiter: Entscheidend ist, wie das OMS anschließend ausgibt.

Zeile 10 gilt nicht pauschal. Ob eine Ausgabeschicht treiberfrei ausgibt, ist eine Frage der Konfiguration, nicht der Produktkategorie. Gibt sie über Windows-Druckerwarteschlangen aus, gilt für diesen Abschnitt dieselbe Prüfregel wie für jeden anderen Windows-Host. Das gilt für jedes Produkt dieser Kategorie, auch für unser eigenes.

Wie prüfe ich unsere Etiketten-Druckpfade? Prüfvorgehen in sechs Schritten

Das Vorgehen kommt ohne Werkzeuganschaffung aus. Es beginnt bewusst nicht mit der Geräteliste – Etikettendruck ist selten sauber inventarisiert, und eine Geräteliste beantwortet die entscheidende Frage nicht.

1. Etikettenprozesse erfassen, nicht Drucker. Welche Prozesse erzeugen Etiketten? Typisch: Wareneingang, Einlagerung, Kommissionierung, Versand und Speditionslabel, Fertigungsaufträge und Chargenkennzeichnung, Qualitätsprüfung und Probenlabels, Instandhaltung, Asset- und Regalkennzeichnung. Pro Prozess wird notiert, welches System das Etikett anstößt.

2. Pro Prozess die erzeugende Instanz bestimmen. Erzeugt SAP den Datenstrom über einen Gerätetyp? Eine Etikettensoftware über einen Herstellertreiber? Ein WMS oder MES über eigene ZPL-Templates? Eine Fachanwendung an der Linie? Das ist die Frage, die Zeile 1 von Zeile 2 in der Klassifizierung trennt.

3. Den Transportweg bis zum Gerät nachzeichnen. Für jeden Pfad: über welchen Host, über welche Warteschlange, über welchen Port, mit welchem Treiber. Bei SAP zusätzlich Gerätetyp und Kopplungsart aus Transaktion SPAD erfassen – beides, nicht eines von beiden. Bei Kopplungsart U ist zusätzlich festzuhalten, ob das Ziel das Gerät selbst oder ein Windows-Host ist; die Kopplungsart allein entscheidet den Fall nicht.

4. Windows-Systeme im Datenpfad inventarisieren. Packplatz-PCs, Etikettenserver, SAPSprint-Hosts, Universal-Print-Connector-Hosts, Citrix-VDAs, Linien-PCs. Erfasst werden Betriebssystemversion, installierte Etikettentreiber, Portkonfiguration und WPP-Status. Diese Liste ist gleichzeitig die Liste der Systeme, auf denen eine WPP-Aktivierung Wirkung zeigt.

5. Geräteseitig prüfen, was tatsächlich angeboten wird. Pro Modell und Firmwarestand: Ist IPP aktiv, welche Adresse, welche Dokumentformate werden veröffentlicht, ist PDF Direct verfügbar? Die Attributabfrage per ipptool -tv ipp://<gerät>/ipp/print get-printer-attributes.test zeigt in document-format-supported, was das Gerät annimmt. Parallel gegen die Mopria-Liste zertifizierter Produkte abgleichen – Datenblatt und Zertifizierungsstatus sind nicht dasselbe.

6. Gegen Prozesskritikalität priorisieren. Nicht „welches Gerät ist betroffen“, sondern „welcher Prozess steht still und wie lange hält er das aus“. Ein Regallabel-Drucker und ein Versandlabel-Drucker erscheinen in der Geräteliste gleichwertig. Steht der zweite, steht der Warenausgang.

Testprotokoll für den WPP-Pilotversuch

Diese Punkte gehören auf ein Testsystem, bevor WPP in einer Umgebung mit Etikettendruck aktiviert wird. Alle sind mit Bordmitteln prüfbar; die Spalte „Aus Dokumentation ableitbar“ zeigt, wo die Antwort schon vorliegt und wo tatsächlich gemessen werden muss.

Welche Fristen gelten – und was gilt bereits heute?

Beides gilt gleichzeitig. Es gibt keinen Ausfalltermin – und es gibt eine Richtung, deren Endpunkt keine Drittanbieter-Treiber mehr kennt.

Was ein Gerätetausch löst – und was nicht

Zwei weitere Punkte gehören in dieselbe Rechnung. Etikettendrucker haben in Lager- und Fertigungsumgebungen deutlich längere Nutzungszyklen als Bürogeräte; eine Flotte, die zehn Jahre läuft, folgt keinem dreijährigen Refresh-Rhythmus. Und ein Teil der verlorenen Funktion war ohnehin nie eine Eigenschaft des Druckers, sondern eine des Treibers oder der Warteschlange: zentrale Umleitung bei Gerätestörung, Statusrückmeldung an den Prozess, Protokollierung für die Chargenrückverfolgung.

Die belastbare Reihenfolge ist deshalb: erst Prozesse und Datenströme klassifizieren, dann entscheiden, welcher Teil ein Hardwarethema ist und welcher ein Architekturthema. Die zweite Kategorie wird durch keinen Beschaffungsvorgang kleiner.

Die Frage hinter der Frage: Wo entsteht der Etikettendatenstrom?

Legt man die Klassifizierungstabelle neben das Prüfvorgehen, zeigt sich ein Muster. Die betroffenen Pfade haben nichts miteinander zu tun außer einem Merkmal: Sie führen über eine Windows-Druckerwarteschlange für ein Gerät, das Windows nicht als kompatibel erkennt. Die nicht betroffenen Pfade haben ebenfalls nur ein gemeinsames Merkmal: Der druckfertige Datenstrom entsteht anderswo und erreicht das Gerät direkt.

Betroffen ist damit keine Gerätekategorie und kein Hersteller, sondern eine Zuständigkeit – die Annahme, dass ein Windows-System der Ort ist, an dem aus einem Etikettenauftrag ein gerätefertiger Datenstrom wird.

Die Leitfrage für die eigene Planung lautet deshalb nicht „sind unsere Etikettendrucker WPP-fähig?“, sondern: Wo entsteht der Etikettendatenstrom – in einer Komponente, deren Treibermodell andere bestimmen, oder in einer Ausgabeschicht, die das Unternehmen selbst kontrolliert? Wer diese Frage für den Etikettendruck beantwortet, hat sie für den Plotter, das CAD-Blatt und das SAP-Formular mitbeantwortet.

Häufige Fragen

Fällt der Etikettendruck an einem festen Datum aus?

Nein. WPP ist heute optional und standardmäßig deaktiviert. Microsoft hat die standardmäßige Aktivierung für einen „future date“ angekündigt, ohne ein Datum zu nennen, und am 25. Februar 2026 klargestellt, dass die Unterstützung für Legacy-Treiber nicht beendet ist. Fixiert ist ein anderer Termin: Ab dem 1. Juli 2027 sind Updates für Drittanbieter-Treiber auf sicherheitsrelevante Fixes beschränkt.

Wir haben WPP nicht aktiviert. Sind wir sicher?

Für den Bestand zunächst ja. Zu beachten ist aber die zweite, weichere Stufe: Seit dem 1. Juli 2026 bevorzugt Windows bei neu hinzugefügten Druckern den IPP-Inbox-Treiber. Dass bestehende Installationen davon unberührt bleiben, folgt aus der Wirkungsweise einer Rangfolgeänderung, ist aber nicht ausdrücklich dokumentiert – im Zweifel prüfen.

Können wir WPP auf den Etiketten-Arbeitsplätzen einfach deaktiviert lassen?

Ja, per Group Policy oder Intune, und als Übergangsmaßnahme ist das sinnvoll. Als Zielzustand trägt es nicht: Die Treiber-Rangfolge greift auch ohne WPP, ab Juli 2027 gibt es nur noch Sicherheitsfixes, und die standardmäßige Aktivierung ist angekündigt. Eine Ausnahme sollte dokumentiert werden – mit Begründung und Überprüfungstermin.

Unsere Anwendung erzeugt ZPL selbst. Dann sind wir doch nicht betroffen?

Nur wenn die Anwendung den Strom auch selbst zum Gerät bringt. Läuft er über eine Windows-Warteschlange, ist der Pfad betroffen – nicht wegen des Renderings, sondern wegen der Warteschlange. Das ist Zeile 2 der Klassifizierungstabelle und der häufigste Fehlschluss zu diesem Thema.

Betrifft das auch Bondrucker, Kassendrucker und Kennzeichnungssysteme?

Nach derselben Logik ja: ESC/POS, Star- und Bixolon-Befehlssätze sind keine öffentlichen Standard-PDLs. Dass ein Hersteller Mopria-Mitglied ist – Epson etwa, als Urheber von ESC/POS – sagt dabei nichts über die Zertifizierung seiner Bon- und Kassendrucker. Zu prüfen ist immer das Modell, nicht der Hersteller.

Was ist mit mobilen Etikettendruckern am Handheld?

Der Druck von Android- oder iOS-Handhelds läuft nicht über den Windows-Druckstack und ist von WPP nicht berührt. Betroffen sind die Pfade, in denen ein Windows-System zwischen Anwendung und Gerät steht.

Wo finde ich die SAP-Seite dieses Themas?

Die Betroffenheit von SAP-Druckpfaden hängt von der Kombination aus Gerätetyp und Kopplungsart ab. Der Beitrag Betrifft Windows Protected Print den SAP-Druck? enthält die vollständige Betroffenheitsmatrix, die SAPSprint-Analyse und ein Prüfvorgehen über Transaktion SPAD.

Einordnung

Die Fragen, die Windows Protected Print im Etikettendruck aufwirft – wo der Datenstrom entsteht, wie ein gerätespezifisches Format sein Gerät erreicht, wie eine Ausgabe bei Gerätestörung umgeleitet und protokolliert wird –, sind die Fragen des Output Managements. Ob ein konkreter Ausgabeweg betroffen ist, entscheidet dabei nicht die Produktkategorie, sondern die eingesetzte Kopplung. Das gilt für jede Plattform, auch für unsere – und es ist der Grund, warum am Anfang eine Bestandsaufnahme steht und nicht eine Produktauswahl.

Quellen

Microsoft Learn: Overview of Windows protected print mode

Microsoft Learn: Windows protected print mode FAQ

Microsoft Learn: More information on Windows protected print mode for enterprises and developers

Microsoft Learn: Windows Ready Print

Microsoft Learn: End of Servicing Plan for Third-Party Printer Drivers on Windows

Microsoft Learn: Printers Policy CSP – ConfigureWindowsProtectedPrint

Microsoft Learn: Universal Print limited support for label printing

Microsoft Learn: Universal Print connector overview

Microsoft Q&A: Add a local IPP printer queue programmatically or with PowerShell when Windows protected print mode is enabled – Community-Thread, keine Produktdokumentation und kein Microsoft-Statement

HP: Windows Protected Print – Technical Whitepaper

Mopria Alliance: Member Companies

Mopria Alliance: Member Benefits

Mopria Alliance: Certified Products

PWG: IPP Everywhere – Übersicht und Formatanforderungen

PWG 5100.14: IPP Everywhere v1.1

PWG 5100.20: IPP Everywhere Printer Self-Certification Manual v1.1

Zebra Technologies: ip.ipp.mode – SGD-Befehlsreferenz

Zebra Technologies: IPP/IPPS Configuration Guide for Link-OS Printers (P1140936-01EN)

Zebra Developer Portal: Printers Include Free PDF Direct with Link-OS 6.3

Zebra Technologies: PDF Direct – Virtual Device Support

Zebra Technologies: Solution Guide – Zebra Printers and SAP Smart Forms.  

Zebra Technologies: Device Type Used to Print to a Zebra Printer from SAP Smart Forms

SAP KBA 2135619: Background graphic is not printed to Zebra printer

cab Produkttechnik: FAQ – SAP-Anbindung über Gerätetyp LB_CAB und Kopplungsart U

ISO/IEC 15416: Bar code print quality test specification – Linear symbols

ISO/IEC 15415: Bar code print quality test specification – Two-dimensional symbols

WindowsPro: Windows Protected Print Mode (WPP) konfigurieren

CUPS: ipptool Manual

Microsoft-Statement vom 25. Februar 2026 zu Legacy-Druckertreibern, veröffentlicht bei Windows Central

Zu diesem Blog-Artikel

Dieser Beitrag beschreibt öffentlich dokumentiertes Verhalten von Microsoft Windows, des IPP-Standards und der Etikettendruck-Architektur. Aussagen zur Betroffenheit einzelner Druckpfade sind Ableitungen aus dieser Dokumentation und ersetzen keine Prüfung der konkreten Systemlandschaft. Wo eine Aussage nicht dokumentiert ist, ist sie im Text als Ableitung oder als Testpunkt gekennzeichnet. Der Beitrag enthält keine Kompatibilitätszusage für einzelne Produkte, Produktversionen oder Gerätemodelle. Die Angaben zur Mopria-Mitgliedschaft beziehen sich auf den Stand vom 13. August 2026.