Ende der Wartung von Windows-Druckertreibern — Wie Geschäftsanwendungen Bericht- und Etikettendruck vorbereiten

„Wir haben den PC ausgetauscht, und die Papier- und Fachwahl ist anders, obwohl es derselbe Drucker ist.“ „Die gespeicherten Druckeinstellungen kommen nicht zurück.“ „Der Etikettendrucker ist aus der Liste verschwunden.“ Die Vorbereitung auf das Ende der Druckertreiberwartung bedeutet sicherzustellen, dass solche Änderungen den Betrieb nicht anhalten.

Als Erstes muss klar sein, dass der Plan zum Ende der Treiberwartung und die Aktivierung von Windows protected print mode zwei verschiedene Dinge sind. Vorhandenes Drucken bleibt nicht in dem Moment stehen, in dem die Daten des Plans verstreichen. Andererseits gehen die Einstellungen und Druckziele, von denen die Anwendung abhing, verloren, wenn sich die Art der Treiberauswahl ändert oder Windows protected print mode aktiviert wird.¹²

Dieser Artikel richtet sich an Entwickler, die Windows-Geschäftsanwendungen in WinForms, WPF und Ähnlichem pflegen, und an Administratoren, die Drucker bereitstellen. Er geht was sich ändert, was zu untersuchen ist, was zu reparieren ist und wie zu prüfen ist in dieser Reihenfolge durch. Zur Wahl einer Druck-API oder einer PDF-Ausgabemethode siehe den vorherigen Artikel Drucken und PDF-Ausgabe in Windows-Geschäftsanwendungen.

Die Voraussetzung ist Windows 11 (24H2 oder höher zum Prüfen von WPP), PowerShell 5.1 oder höher (Modul PrintManagement) und C# (.NET 6 oder höher oder .NET Framework 4.x; System.Drawing.Printing / System.Printing). Der Schwierigkeitsgrad ist mittel.

1. Zuerst das Fazit

Statt den gesamten Druckcode pauschal umzuschreiben, prüfen Sie zuerst, ob das Druckziel bestehen bleibt, und reparieren Sie danach die Stellen, die vom Treiber abhängen.

Die Entscheidungsreihenfolge hat drei Stufen.

Zeichnet die Anwendung nur mit PrintDocument oder FixedDocument, ist sie grundsätzlich Gegenstand der Prüfung, nicht der Überarbeitung. Verschwindet die Zielwarteschlange selbst unter WPP und lässt sich nicht neu registrieren, schlägt das Drucken fehl, selbst wenn der Zeichencode in Ordnung ist. Dann ist zuerst ein anderer Pfad nötig.

Wenn Sie mit der Arbeit selbst beginnen wollen, gehen Sie in dieser Reihenfolge vor: Liste in 5.1 aufnehmen → Druckziel mit den Tabellen in Kapitel 4 und 5.1 beurteilen → Abhängigkeiten in 5.2 bis 5.5 prüfen → Pfad in Kapitel 6 wählen → in Kapitel 7 prüfen. Die Kapitel 2 bis 4 erklären den Hintergrund zu den Punkten, an denen die Entscheidung nicht offensichtlich ist.

Im Folgenden wird Windows protected print mode mit WPP abgekürzt. Eine „Warteschlange“ ist ein bei Windows registriertes Druckziel, und der „Spooler“ ist der Mechanismus, der Druckaufträge entgegennimmt und an das Ausgabeziel weitergibt.

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (39 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

2. Was beschlossen wurde — Eine Zeitlinie in drei Stufen

2.1 Was endet, sind Angebot und Aktualisierungen, nicht eine pauschale Abschaltung vorhandener Treiber

Die Primärquelle ist „End of servicing plan for third-party printer drivers on Windows“ auf Microsoft Learn. Der Plan wurde im September 2023 angekündigt und die Daten im Mai 2025 überarbeitet. Zum Zeitpunkt der Abfassung sieht der Plan wie folgt aus.¹

Vorhandene Treiber lassen sich weiterhin über Windows Update und über Installationsprogramme der Hersteller einrichten, und Microsoft sagt, es habe keine Pläne, die Funktionalität von v3/v4-Treibern zu deaktivieren. Mit anderen Worten: Dies ist ein Plan, Angebot und Aktualisierung von Treibern schrittweise einzustellen, kein Plan, die bereits auf PCs im Einsatz installierten Treiber an diesem Tag zu deaktivieren.¹

flowchart TB
    accTitle: Was sich mit dem Ende der Treiberwartung ändert und was nicht
    accDescr: Das Ende der Druckertreiberwartung ändert für sich genommen weder den Einstiegspunkt der Zeichen-API der Anwendung noch die vorhandenen Treiber; erst wenn bei Neuinstallation oder erneuter Erkennung ein anderer Treiber gewählt wird, werden die Papierliste, die proprietären Funktionen und der Warteschlangenname, die der Treiber lieferte, ersetzt, und die durch Aktivierung von Windows protected print mode verursachten Änderungen einschließlich der Entfernung virtueller Drucker sind ein eigener Mechanismus, der in Kapitel 4 behandelt wird
    eos["Ende der Druckertreiberwartung"]
    eos --> keep["Was sich nicht ändert"]
    eos --> cond["Wenn bei Neuinstallation oder erneuter Erkennung ein anderer Treiber gewählt wird"]
    cond --> change["Was ersetzt wird"]
    keep --> api["Einstiegspunkt der Zeichen-API"]
    keep --> drv["Vorhandene Treiber"]
    change --> caps["Papier, Fächer, proprietäre Funktionen"]
    change --> qname["Warteschlangenname"]

Abbildung 1: Das Wartungsende allein ändert nichts; wird ein anderer Treiber gewählt, werden die Informationen und Namen, die der Treiber lieferte, ersetzt. Die durch Aktivierung von WPP verursachten Änderungen einschließlich der Entfernung virtueller Drucker sind ein eigener Mechanismus (Kapitel 4).

2.2 Treiber wechseln vor Ort vor allem in zwei Situationen

Auch wenn der Plan vorhandene Treiber nicht anhält, ändert sich die Umgebung, die die Anwendung sieht, in den folgenden Situationen.

Wenn mehrere Treiberpakete zum selben Gerät passen, weist Windows jedem einen Rang zu und wählt das beste. Die Änderung vom 1. Juli 2026 lässt diese Auswahl den IPP-Klassentreiber bevorzugen. Bei Geräten, für die der IPP-Klassentreiber kein Kandidat ist, kann das Herstellerpaket weiterhin gewählt werden.³¹

flowchart TB
    accTitle: Zwei Wege, auf denen Treiber vor Ort ersetzt werden
    accDescr: Bei Geräten, zu denen der IPP-Klassentreiber passt, wählt die Rangfolge bei PC-Austausch, Neuinstallation des Betriebssystems oder erneuter Druckerkennung den IPP-Klassentreiber und der Treiber wird ersetzt; wenn Windows protected print mode aktiviert wird, werden Drucker auf Treibern Dritter entfernt, der Treiber wird bei Modellen ersetzt, die sich mit Windows Ready Print neu registrieren lassen, und bei Modellen, bei denen das nicht möglich ist, geht das Druckziel verloren
    site["PC vor Ort"]
    site --> r1["PC-Austausch, Neuinstallation des Betriebssystems, erneute Erkennung"]
    site --> r2["Windows protected print mode aktiviert"]
    r1 --> rank["Bevorzugt bei Geräten, zu denen der IPP-Klassentreiber passt"]
    r2 --> del["Drucker auf Treibern Dritter entfernt"]
    rank --> swap["Treiber wird ersetzt"]
    del --> re{"Lässt sich das Gerät mit Ready Print neu registrieren?"}
    re -->|"Ja"| swap
    re -->|"Nein"| lost["Druckziel geht verloren"]

Abbildung 2: Wer den Plan zum Wartungsende und WPP auseinanderhält, kann die Situationen, in denen der Treiber wechselt, von denen trennen, in denen das Druckziel selbst verloren geht.

Wichtig ist hier außerdem, IPP-Unterstützung und Mopria-Zertifizierung nicht als dieselbe Bedingung zu behandeln.

Bei einem Gerät, das IPP ohne Mopria-Zertifizierung unterstützt, kann die Änderung der Rangfolge den Treiber auch dann ersetzen, wenn Sie WPP nicht nutzen. Umgekehrt bestätigt der Treibername „Microsoft IPP Class Driver“ allein nicht, dass der Drucker unter WPP verwendbar ist.¹⁴

flowchart TB
    accTitle: Passung des IPP-Klassentreibers und Mopria-Zertifizierung sind getrennte Bedingungen
    accDescr: Unterstützt der Drucker IPP, kann die Änderung der Rangfolge den IPP-Klassentreiber wählen und den Treiber ersetzen, während die Mopria-Zertifizierung eine eigene Bedingung ist, die entscheidet, ob der Drucker unter Windows protected print mode neu registriert werden kann, wobei bei netzwerkverbundenen Geräten IPP aktiviert und erreichbar sein muss und bei USB-verbundenen Geräten der Modus IPP over USB
    printer["Drucker"]
    printer --> q1{"Unterstützt IPP?"}
    q1 -->|"Ja"| rank["Kann ersetzt werden"]
    q1 -->|"Nein"| keep["Bleibt beim Herstellertreiber"]
    printer --> q2{"Mopria-zertifiziert?"}
    q2 -->|"Nein"| ng["Unter WPP nicht neu registrierbar"]
    q2 -->|"Ja"| q3{"USB-Verbindung?"}
    q3 -->|"Nein"| q5{"IPP aktiviert und erreichbar?"}
    q5 -->|"Ja"| ok["Unter WPP neu registrierbar"]
    q5 -->|"Nein"| ng
    q3 -->|"Ja"| q4{"Modus IPP over USB?"}
    q4 -->|"Ja"| ok
    q4 -->|"Nein"| ng

Abbildung 3: Die Wirkung der Rangfolge entscheidet die IPP-Unterstützung; ob der Drucker unter WPP bestehen bleibt, entscheiden Mopria-Zertifizierung plus aktiviertes und erreichbares IPP (bei USB-Verbindungen der Modus IPP over USB).

2.3 Die Treibersignierung hat Ausnahmen, aber Fortführung ist nicht garantiert

Nach dem 15. Januar 2026 können Treiber, die eine der folgenden Bedingungen erfüllen, eine Signierungsausnahme zur Einzelfallprüfung einreichen.¹

• Für Drucker, die keine Mopria-Zertifizierung erhalten können.
• Pakete, deren höchstes Zielbetriebssystem Windows 10 oder früher ist.
• Native ARM64-Treiber.

Einreichungen sind standardmäßig sowohl für WHQL als auch für Attestation gesperrt und werden zu einer manuellen Prüfung mit beigefügtem Begründungsschreiben. Selbst wenn die Bedingungen zutreffen, ist nicht garantiert, dass der Hersteller einreicht oder Microsoft genehmigt.⁵ Außerdem sind einen signierten Treiber erhalten zu können und ihn in einer Umgebung mit aktiviertem WPP verwenden zu können zwei verschiedene Dinge. Die Vorbereitung für Etiketten- und Bondrucker behandelt Kapitel 6.

flowchart TB
    accTitle: Bedingungen, unter denen die Treibersignierung nach dem 15. Januar 2026 weiterhin zulässig ist
    accDescr: Treibereinreichungen von Herstellern sind standardmäßig gesperrt, und nur solche, die eine von drei Bedingungen erfüllen, Drucker, die keine Mopria-Zertifizierung erhalten können, Pakete, deren höchstes Ziel Windows 10 oder früher ist, und native ARM64-Treiber, können eine Ausnahme zur Einzelfallprüfung einreichen, die zur Genehmigung führen kann, die Signierung aber nicht garantiert
    submit["Treibereinreichung des Herstellers"]
    submit --> block["Standardmäßig gesperrt"]
    block --> c1["Modell, das keine Mopria-Zertifizierung erhalten kann"]
    block --> c2["Windows 10 oder früher als höchstes Ziel"]
    block --> c3["Natives ARM64"]
    c1 --> apply["Ausnahme kann beantragt werden"]
    c2 --> apply
    c3 --> apply
    apply --> review["Einzelfallprüfung"]
    review --> maybe["Kann genehmigt werden (keine Garantie)"]

Abbildung 4: Das Erfüllen der Bedingungen bringt den Treiber nur in die Prüfung; ob er signiert wird, ist nicht garantiert.

3. Wie es funktioniert — Der herkömmliche Treiberpfad und Windows Ready Print

3.1 Was sich ändert, ist der Druckpfad hinter der Zeichen-API

Beim herkömmlichen Windows-Druck gibt die Anwendung GDI- oder XPS-Zeichenbefehle aus, der Spooler nimmt den Auftrag entgegen, und der Druckertreiber wandelt ihn in die Sprache des Druckers (PDL) um und sendet ihn. Sowohl der GDI-Druckpfad als auch der XPS-Druckpfad sitzen auf dieser Struktur.⁶

flowchart TB
    accTitle: Der herkömmliche Treiberpfad
    accDescr: Der als SYSTEM laufende Spooler spult die GDI- oder XPS-Zeichenbefehle der Geschäftsanwendung, und ein v3- oder v4-Treiber eines Dritten wandelt sie in ein proprietäres PDL um und sendet sie an den Drucker, im Spoolerprozess selbst ohne Treiberisolation oder in einem vom Spooler getrennten Prozess unter gemeinsamem oder isoliertem Modus
    app["Geschäftsanwendung (GDI / XPS)"] --> spooler["Spooler (SYSTEM-Rechte)"]
    spooler --> iso{"Treiberisolation"}
    iso -->|"Keine"| inproc["Treiber Dritter im Spoolerprozess"]
    iso -->|"Shared / Isolated"| host["Treiber Dritter in einem eigenen Prozess"]
    inproc --> pdl["Umwandlung in proprietäres PDL"]
    host --> pdl
    pdl --> printer["Drucker"]

Abbildung 5: Auf dem herkömmlichen Pfad unterscheidet sich der Prozess mit der Isolation, aber die Struktur, in der Code Dritter im Druckstapel die Umwandlung in PDL übernimmt, ist dieselbe.

Der Nachfolger ist Windows Ready Print. Das ist der Sammelname für Drucken über IPP (Internet Printing Protocol), Scannen über eSCL und Universal Print, und er braucht keinen Treiber Dritter. Er ist für Mopria-zertifizierte Drucker ausgelegt, und die Unabhängigkeit von der CPU-Architektur ist ein weiterer Vorteil.⁷

Ab Windows 10 21H2 wird der Microsoft IPP Class Driver mitgeliefert, der Mopria-konforme Drucker über Netzwerk und USB bedient.¹ Cloud-Warteschlangen von Universal Print nutzen den mitgelieferten Universal Print Class Driver.⁸

flowchart TB
    accTitle: Der Pfad von Windows Ready Print
    accDescr: Der Spooler nimmt die Zeichenbefehle der Geschäftsanwendung entgegen, und entweder rendert der mitgelieferte Microsoft IPP Class Driver auf dem Client nach PWG Raster oder PDF und sendet es über IPP an einen Mopria-zertifizierten Drucker, oder der mitgelieferte Universal Print Class Driver sendet es über IPP over HTTPS an den Universal-Print-Dienst; Windows protected print mode lässt nur diesen Pfad von Windows Ready Print zu
    app["Geschäftsanwendung (GDI / XPS)"] --> spooler["Spooler"]
    spooler --> ipp["Microsoft IPP Class Driver"]
    ipp --> render["Rendern nach PWG Raster / PDF"]
    render --> printer["Mopria-zertifizierter Drucker (IPP)"]
    spooler --> up["Universal Print Class Driver"]
    up --> cloud["Universal-Print-Dienst (IPP over HTTPS)"]
    wpp["Windows protected print mode"] -.->|"lässt nur den Ready-Print-Pfad zu"| ipp
    wpp -.-> up

Abbildung 6: Auch Windows Ready Print geht durch den Spooler. Was sich ändert, ist, dass Umwandlung und Versand von einem Treiber Dritter auf die mitgelieferten Klassentreiber übergehen.

IPP ist ein HTTP-basiertes Protokoll und identifiziert einen Drucker über einen URI wie ipps://printer.example.com/ipp/print. Die für treiberloses Drucken verwendeten PDL beschränken sich auf wenige Formate auf Grundlage öffentlicher Standards, etwa PWG Raster und PDF, und das fertige Dokument wird auf der Clientseite gerendert.⁹ Bei Universal Print sendet der Spooler den Auftrag über IPP over HTTPS an den Dienst.⁸

Der Einstiegspunkt aus Sicht der Anwendung ändert sich nicht. Eine Anwendung, die mit GDI oder XPS zeichnet, ruft dieselben APIs auf. Was sich ändert, ist der Mechanismus dahinter, der die Liste der Papierformate und Fächer zurückgibt, proprietäre Funktionen bereitstellt und nach PDL umwandelt. Deshalb sind Anwendungen, die von den Informationen abhängen, die ein Treiber zurückgibt, oder von proprietären Einstellungen, stärker betroffen als Anwendungen, die nur zeichnen. Für herstellerspezifische Funktionen prüfen Sie außerdem, ob sie über eine Print Support App (PSA) bereitgestellt werden.¹⁰

3.2 Drucken, Fax und Scannen auf Multifunktionsgeräten getrennt prüfen

Ob ein Gerät zu Windows Ready Print wechseln kann, hängt davon ab, dass das Gerät die Funktion hat und das zugehörige Protokoll umsetzt.¹

Schließen Sie aus der Mopria-Druckunterstützung allein nicht, dass auch Fax und Scannen migrieren können.

flowchart TB
    accTitle: Reihenfolge zur getrennten Prüfung jeder Funktion eines Multifunktionsgeräts
    accDescr: Nehmen Sie die genutzten Funktionen einzeln, prüfen Sie der Reihe nach, dass das Gerät die Funktion hat, dass es das Protokoll in der Tabelle unterstützt und dass es bei USB-Verbindung im Modus IPP over USB ist, und prüfen Sie die übrigen Funktionen getrennt, statt das Druckergebnis für Fax oder Scannen wiederzuverwenden
    start["Eine genutzte Funktion wählen"]
    start --> feature{"Hat das Gerät die Funktion?"}
    feature -->|"Ja"| protocol{"Unterstützt das Protokoll in der Tabelle?"}
    feature -->|"Nein"| unmet["Bedingung für diese Funktion nicht erfüllt"]
    protocol -->|"Ja"| usb{"USB-Verbindung?"}
    protocol -->|"Nein"| unmet
    usb -->|"Ja"| mode{"Modus IPP over USB?"}
    usb -->|"Nein"| checked["Bedingung für diese Funktion geprüft"]
    mode -->|"Ja"| checked
    mode -->|"Nein"| unmet
    checked --> next["Die übrigen Funktionen getrennt prüfen"]
    unmet --> next

Abbildung 7: Prüfen Sie in der Reihenfolge Verfügbarkeit der Funktion, unterstütztes Protokoll und zusätzliche Bedingung je Verbindungsart. Verwenden Sie das Druckergebnis nicht für Fax oder Scannen.

3.3 Der Hintergrund ist die Sicherheit des Druckstapels

Laut der Erklärung auf Microsoft Learn entfielen 9 % der vom MSRC (Microsoft Security Response Center) in den vorangegangenen drei Jahren gezählten Fälle auf druckbezogene Fehler. Der Spooler läuft mit SYSTEM-Rechten, ist für Standardbenutzer breit erreichbar und lädt bei Bedarf Code Dritter. Manche alten Treiber sind mit modernen Mitigations wie CFG und CET unvereinbar, was es erschwert, Mitigations anzuwenden, die erfordern, dass jedes beteiligte Stück Code sie unterstützt.⁹

flowchart TB
    accTitle: Warum Mitigations nicht greifen, solange Treiber Dritter geladen werden
    accDescr: Der als SYSTEM laufende Spooler lädt Code Dritter, und weil alte Treiber mit Mitigations wie CFG und CET unvereinbar sind, können Mitigations, die die Unterstützung jedes Beteiligten erfordern, nicht auf den Spooler angewendet werden, wodurch Schwachstellen leichter ausnutzbar werden
    sys["Spooler läuft als SYSTEM"]
    load["Lädt bei Bedarf Code Dritter"]
    old["Alte Treiber sind mit Mitigations unvereinbar"]
    sys --> risk["Schwachstellen sind leichter ausnutzbar"]
    load --> nomit["Mitigations (CFG / CET / ACG) können nicht angewendet werden"]
    old --> nomit
    nomit --> risk

Abbildung 8: Mitigations greifen erst, wenn jeder Beteiligte sie unterstützt; der Spooler lässt sich daher nicht vollständig schützen, solange die Treiber nicht entfernt sind.

Wo ein Treiber Dritter läuft, hängt von der Einstellung der Druckertreiberisolation ab.¹¹

Ein Treiber, der in seiner INF DriverIsolation=2 erklärt, nutzt standardmäßig den gemeinsamen Prozess, und ein Treiber, der das nicht erklärt, läuft standardmäßig im Spoolerprozess. Administratoren können das in der Druckverwaltungskonsole oder per Gruppenrichtlinie überschreiben. In jedem Modus läuft jedoch weiterhin Code Dritter im Druckstapel.¹¹ WPP ist der Betriebsmodus, der diese Abhängigkeit von Code Dritter entfernt.

flowchart TB
    accTitle: Wie der Prozess entschieden wird, in dem ein Treiber Dritter läuft
    accDescr: Ein Treiber, der in seiner INF DriverIsolation=2 erklärt, läuft standardmäßig in einem gemeinsamen Prozess getrennt vom Spooler, ein Treiber ohne die Erklärung läuft standardmäßig im Spoolerprozess, und Administratoren können das aus der Druckverwaltungskonsole oder per Gruppenrichtlinie auf gemeinsam, im Spoolerprozess oder einen eigenen dedizierten Prozess (isoliert) überschreiben
    inf{"INF erklärt DriverIsolation=2"}
    inf -->|"Ja"| shared["Läuft in einem gemeinsamen eigenen Prozess (Standard)"]
    inf -->|"Nein"| inproc["Läuft im Spoolerprozess (Standard)"]
    admin["Überschrieben durch Administratoreinstellungen oder Richtlinie"] -.-> shared
    admin -.-> inproc
    admin -.-> isolated["Läuft in einem dedizierten eigenen Prozess (isoliert)"]

Abbildung 9: Den Isolationsmodus entscheiden die INF-Erklärung und die Administratoreinstellungen; alte Treiber ohne die Erklärung laufen standardmäßig im Spoolerprozess.

4. Was unter Windows protected print mode verschwindet

4.1 WPP ist ein Betriebsmodus, der „nur Windows Ready Print verwendet“

WPP wurde in Windows 11 24H2 eingeführt. Zum Zeitpunkt der Abfassung ist er standardmäßig deaktiviert, und solange er deaktiviert ist, legt er der Treiberinstallation und den Druckfunktionen keine Beschränkungen auf.¹²¹³ Halten Sie den Weg der Aktivierung und wer ihn wieder ausschalten kann auseinander.

Wenn er über Gruppenrichtlinie aktiviert ist, kann der Benutzer ihn nicht ohne Kontakt zu einem Administrator ausschalten. Der Intune-OMA-URI ist ein weiterer Weg, dieselbe ADMX-gestützte Geräterichtlinie anzuwenden. Gehen Sie davon aus, dass der Benutzer ihn nur dann über den Einstellungsbildschirm ausschalten kann, wenn der Benutzer ihn über den Einstellungsbildschirm aktiviert hat.¹⁴²¹³

flowchart TB
    accTitle: Drei Wege zur Aktivierung von Windows protected print mode
    accDescr: Windows protected print mode kann über die Einstellungen-App, Gruppenrichtlinie oder einen Intune-OMA-URI aktiviert werden; der Benutzer kann ihn in der Einstellungen-App nur ausschalten, wenn der Benutzer ihn dort aktiviert hat, und wenn er über Gruppenrichtlinie oder eine Intune-Richtlinie verteilt wurde, lässt er sich nicht ohne Änderung der Richtlinie durch den Administrator ausschalten
    s["Einstellungen-App (vom Benutzer aktiviert)"] --> wpp["Windows protected print mode aktiviert"]
    g["Gruppenrichtlinie"] --> wpp
    i["Intune (OMA-URI)"] --> wpp
    s -.->|"der Benutzer kann ihn in der Einstellungen-App ausschalten"| off["Ausgeschaltet"]
    g -.->|"der Benutzer kann ihn nicht ausschalten"| adm["Ausschalten erfordert eine Richtlinienänderung durch den Administrator"]
    i -.->|"der Benutzer kann ihn nicht ausschalten"| adm

Abbildung 10: Es gibt drei Aktivierungswege, und der Benutzer kann ihn nur ausschalten, wenn der Benutzer ihn in der Einstellungen-App aktiviert hat.

4.2 Warteschlangen, die bestehen, die verschwinden und die neu registriert werden müssen

Die Wirkung zum Zeitpunkt der Aktivierung hängt nicht nur vom Drucker selbst ab, sondern auch davon, mit welchem Treiber er derzeit registriert ist.²

flowchart TB
    accTitle: Was mit Druckern geschieht, wenn Windows protected print mode aktiviert wird
    accDescr: Bei der Aktivierung werden mit Treibern Dritter installierte Drucker und nicht unterstützte virtuelle Drucker, der XPS Document Writer und der virtuelle Faxdrucker entfernt; Modelle, die Mopria-zertifiziert sind und bei Netzwerkverbindungen IPP aktiviert und erreichbar haben oder bei USB-Verbindungen im Modus IPP over USB sind, können mit Windows Ready Print neu registriert werden, und nicht unterstützte Geräte sind während der Aktivierung nicht verwendbar
    on["WPP aktiviert"]
    on --> third["Drucker auf Treibern Dritter entfernt"]
    on --> soft["Nicht unterstützte virtuelle Drucker entfernt"]
    soft --> xps["XPS Document Writer und Fax ebenfalls entfernt"]
    third --> mopria{"Mopria-zertifiziert?"}
    mopria -->|"Ja"| conn{"Verbindungsart"}
    conn -->|"Netzwerk"| ipp{"IPP aktiviert und erreichbar?"}
    conn -->|"USB"| usb{"Modus IPP over USB?"}
    ipp -->|"Ja"| re["Mit Windows Ready Print neu registrieren"]
    usb -->|"Ja"| re
    ipp -->|"Nein"| no["Während der Aktivierung nicht verwendbar"]
    usb -->|"Nein"| no
    mopria -->|"Nein"| no

Abbildung 11: Eine Warteschlange auf einem Herstellertreiber verschwindet einmal, selbst wenn der Drucker Mopria-zertifiziert ist. Die Bedingungen für die Neu-Registrierung prüfen Sie getrennt.

Solange WPP aktiviert ist, können die entfernten Treiber Dritter nicht verwendet werden. Außerdem bringt das Ausschalten von WPP einen Drucker, der mit Windows Ready Print neu installiert wurde, nicht automatisch auf seinen ursprünglichen Treiber zurück.²¹⁰

Auf Anwendungsseite zu prüfen sind Verarbeitung, die Papierformate, Fächer und proprietäre Funktionen voraussetzt, die ein Herstellertreiber zurückgibt, virtuelle Drucker nach Art einer Port-Monitor-DLL und der XPS Document Writer. XPS-Dateien direkt mit XpsDocument und Ähnlichem zu erzeugen ist etwas anderes als das Drucken in die virtuelle Warteschlange namens XPS Document Writer und ist von dieser Entfernung nicht betroffen.

4.3 Auch Verwaltung und Spooler-Inneres ändern sich

Unter WPP werden Binärdateien Dritter wie Port-Monitor-DLLs nicht mehr geladen. Modul-Lade-APIs wie AddPrintProvidorW können keine neuen Module mehr laden, und nur die für IPP benötigten Microsoft-signierten Binärdateien werden geladen. AddPrintProvidorW ist die historische Schreibweise in winspool.h; die Erklärung auf Microsoft Learn schreibt AddPrintProviderW.⁹

Diese Beschränkung erlaubt XPS-Rendering mit Benutzerrechten statt SYSTEM, und der neue Spooler-Worker-Prozess verwendet ein eingeschränktes Token, dem Rechte wie SeTcbPrivilege entzogen sind. Die Erzeugung von Kindprozessen ist untersagt, und CFG, CET und ACG sind ebenfalls aktiviert.⁹

flowchart TB
    accTitle: Änderungen am Spooler unter Windows protected print mode
    accDescr: Das Nichtladen von Binärdateien Dritter macht es möglich, das Laden von Modulen einzuschränken, XPS mit Benutzerrechten zu rendern, Worker-Prozesse mit einem eingeschränkten Token laufen zu lassen, die Erzeugung von Kindprozessen zu untersagen und CFG, CET und ACG zu aktivieren
    nodrv["Binärdateien Dritter werden nicht geladen"]
    nodrv --> r["Eingeschränktes Laden"]
    nodrv --> l["Verringerte Rechte"]
    nodrv --> m["Mitigations aktiviert"]
    r --> r2["Nur Microsoft-signierte Binärdateien"]
    l --> l2["XPS mit Benutzerrechten, eingeschränktes Token"]
    m --> m2["Keine Kindprozesse, CFG / CET / ACG"]

Abbildung 12: Die Mitigations, die in Abbildung 8 nicht greifen konnten, lassen sich erst aktivieren, wenn Binärdateien Dritter entfernt sind.

Point and Print behält seine IPP-Konfiguration, installiert aber keine Treiber Dritter mehr. Bereitstellungsverfahren, die darauf aufbauen, dass „die Verbindung zum Druckserver den Treiber verteilt“, müssen ebenfalls überdacht werden.⁹

Ob WPP derzeit aktiviert ist, lässt sich ab Windows 11 24H2 mit der WinRT-API Windows.Graphics.Printing.ProtectedPrint.WindowsProtectedPrintInfo.IsProtectedPrintEnabled prüfen.¹⁵ Die Gruppenrichtlinieneinstellung ist der Wert WindowsProtectedPrintGroupPolicyState unter HKLM\Software\Policies\Microsoft\Windows NT\Printers\WPP.¹³

Beachten Sie, dass ein Client mit aktiviertem WPP einen Druckserver mit deaktiviertem WPP nicht aus der Druckverwaltung verwalten kann. Stellen Sie Administratoren einen eigenen Verwaltungsclient mit deaktiviertem WPP bereit.¹⁴

5. Inventur bestehender Anwendungen — Die vier Stellen, die zu prüfen sind

flowchart TB
    accTitle: Die vier Stellen für die Inventur in einer Geschäftsanwendung
    accDescr: Im Druckcode einer Geschäftsanwendung sind die vier Stellen Speichern treiberspezifischer Einstellungen, Abhängigkeiten von Warteschlangennamen (einschließlich solcher in SDKs und Bibliotheken), Abhängigkeiten von virtuellen Druckern, die WPP nicht unterstützt, und RAW-Versand an Warteschlangen, die unter WPP nicht bestehen, Gegenstand der Überarbeitung, und Code, der nur zeichnet, ist Gegenstand der Prüfung
    app["Druckcode der Geschäftsanwendung"]
    app --> deps["Die vier Abhängigkeiten inventarisieren"]
    app --> d0["Nur Zeichnen"]
    deps --> d1["Speichern treiberspezifischer Einstellungen"]
    deps --> d2["Abhängigkeit von Warteschlangennamen"]
    deps --> d3["Abhängigkeit von virtuellen Druckern"]
    deps --> d4["RAW-Versand"]
    d2 -.-> d2n["Einschließlich in SDKs"]
    d3 -.-> d3n["Solche, die WPP nicht unterstützt"]
    d4 -.-> d4n["An Warteschlangen, die nicht bestehen"]
    d1 --> fix["Überarbeiten"]
    d2 --> fix
    d3 --> fix
    d4 --> fix
    d0 --> verify["Prüfen"]

Abbildung 13: Nur die vier Abhängigkeiten sind Gegenstand der Überarbeitung; Code, der nur zeichnet, geht in die Prüfung.

5.1 Zuerst die Treiberliste vor Ort aufnehmen und das Druckziel beurteilen

Ob eine Überarbeitung nötig ist, entscheidet sich, nachdem man sieht, was vor Ort installiert ist. Nehmen Sie die Liste der Warteschlangen und Treiber mit dem PowerShell-Modul PrintManagement auf. Das Auflisten mit Get-Printer und Get-PrinterDriver erfordert keine Administratorrechte, der pnputil-Schritt in der zweiten Hälfte schon.¹⁶¹⁷

# Pro Warteschlange Treibername, Hauptversion (3 = v3, 4 = v4), Hersteller und INF-Dateiname auflisten
Get-Printer |
    Select-Object Name, DriverName, PortName,
        @{ Name = "DriverMajorVersion"; Expression = { (Get-PrinterDriver -Name $_.DriverName).MajorVersion } },
        @{ Name = "Manufacturer"; Expression = { (Get-PrinterDriver -Name $_.DriverName).Manufacturer } },
        @{ Name = "InfName"; Expression = { Split-Path -Leaf (Get-PrinterDriver -Name $_.DriverName).InfPath } } |
    Sort-Object DriverName |
    Format-Table -AutoSize

# Nur Drittanbieter-Treiberpakete auflisten: veröffentlichter Name (oemN.inf), ursprünglicher INF-Name und Anbieter (Administratorrechte erforderlich)
pnputil /enum-drivers /class Printer

MajorVersion unterscheidet v3 von v4.¹⁸ Allerdings sind die Unterscheidung v3/v4 und die Unterscheidung mitgeliefert/Drittanbieter getrennt. Klassifizieren Sie wie folgt.

InfPath von Get-PrinterDriver ist der Pfad zur INF im Treiberspeicher und gibt nicht zwingend den veröffentlichten Namen oemN.inf zurück. Gleichen Sie den veröffentlichten Namen, den ursprünglichen INF-Namen und den Anbieter, die pnputil /enum-drivers zurückgibt, mit dem Dateinamen von InfPath und Manufacturer ab. pnputil /enum-drivers listet nur Drittanbieterpakete; mitgelieferte Pakete erscheinen nicht in der Liste.¹⁹¹⁷

flowchart TB
    accTitle: Verfahren zur Inventur der Drucker vor Ort
    accDescr: Nehmen Sie die Liste der Warteschlangen und Treiber mit PowerShell auf und teilen Sie sie nach DriverName und durch Abgleich von Manufacturer mit der Liste der Drittanbieterpakete von pnputil in Warteschlangen auf dem IPP-Klassentreiber, Universal-Print-Warteschlangen (WPP-kompatibel), Warteschlangen auf anderen mitgelieferten Treibern (XPS und Fax entfernt, Generic / Text Only kann nicht als bestehend angenommen werden, Microsoft Print to PDF steht nicht auf der Entfernungsliste und wird einzeln beurteilt) und Warteschlangen auf Herstellertreibern (Kandidaten für den Wechsel); bei Warteschlangen auf dem IPP-Klassentreiber Mopria-Zertifizierung, bei Netzwerkverbindungen aktiviertes und erreichbares IPP und bei USB-Verbindungen den Modus IPP over USB getrennt bestätigen und dann jede Warteschlange mit den Warteschlangen abgleichen, auf die Einstellungen und Druckcode der Anwendung zeigen
    list["Liste mit Get-Printer / Get-PrinterDriver aufnehmen"]
    list --> cls{"DriverName und Anbieter"}
    cls -->|"IPP Class"| ipp["Warteschlange auf dem IPP-Klassentreiber"]
    cls -->|"Universal Print Class"| up["Universal-Print-Warteschlange"]
    cls -->|"Anderer mitgelieferter"| inbox["Einzeln mit der Tabelle in Kapitel 4 beurteilen"]
    cls -->|"Hersteller"| vendor["Kandidat für den Wechsel"]
    ipp --> mop["Mopria, IPP-Erreichbarkeit, USB prüfen"]
    mop --> match["Mit Einstellungen und Code der Anwendung abgleichen"]
    up --> match
    inbox --> match
    vendor --> match
    match --> judge["Mit der Entscheidungstabelle sortieren"]

Abbildung 14: Liste aufnehmen und nach Namen sortieren braucht keine Administratorrechte; den Anbieter abzugleichen erfordert Administratorrechte für pnputil.

Gleichen Sie diese Liste mit den Warteschlangen ab, auf die Einstellungen, Druckcode und verwendete SDKs der Anwendung verweisen. Wenn Sie für jeden Kundenstandort Treiber, Mopria-Zertifizierung, Verbindungsart, IPP-Erreichbarkeit und USB-Betriebsmodus festhalten, können Sie mit der Tabelle in Kapitel 4 urteilen.

Bleibt das Druckziel unter WPP nicht bestehen und lässt sich nicht neu registrieren, stellen Sie den Ausweichpfad in Kapitel 6 bereit oder entscheiden Sie, WPP nicht zu nutzen, bevor Sie den Code inventarisieren. Kann das Gerät auch ohne WPP von der IPP-Rangfolgeänderung betroffen sein, fahren Sie mit 5.2 fort. Nutzen Sie WPP nicht und hat der Treiberwechsel keine Wirkung, lautet die Entscheidung, auf dem aktuellen Pfad weiterzuarbeiten.

Um den Treibernamen aus der Anwendung zu prüfen, lesen Sie mit WPFs System.Printing PrintQueue.QueueDriver.Name.²⁰

using System.Printing;

// Aus einem Verwaltungstool oder einer Desktop-App den Treibernamen jeder Warteschlange auflisten
using var server = new LocalPrintServer();
foreach (PrintQueue queue in server.GetPrintQueues(
    new[] { EnumeratedPrintQueueTypes.Local, EnumeratedPrintQueueTypes.Connections }))
{
    Console.WriteLine($"{queue.Name}\t{queue.QueueDriver?.Name}\t{queue.QueuePort?.Name}");
}

Allerdings unterstützt der Namensraum System.Printing die Verwendung in einem Windows-Dienst nicht. Wenn Sie aus einem residenten Dienst drucken, legen Sie diese Diagnose ins Verwaltungstool.²¹ Zu den Einschränkungen beim Drucken aus einem Dienst siehe Windows-Dienste erstellen und betreiben und Kapitel 7 des vorherigen Artikels.

5.2 Prüfung 1: Werden treiberspezifische Einstellungen gespeichert und wiederhergestellt?

Am schwersten zu finden sind gespeicherte Druckeinstellungen. Warum sie kaputtgehen, hängt davon ab, wie sie gespeichert werden.

DEVMODE kann nach den öffentlichen Membern private Daten tragen, deren Größe dmDriverExtra angibt. Windows prüft nur den öffentlichen Teil, und beschädigte private Daten können den Treiber im Prozess der Anwendung oder des Spoolers zum Absturz bringen.²²

flowchart TB
    accTitle: Der öffentliche und der private Teil von DEVMODE
    accDescr: Die Struktur DEVMODE trägt nach den öffentlichen Membern treiberdefinierte private Daten, die dmDriverExtra angibt; nur der öffentliche Teil wird von Windows geprüft und der private Teil kann nur von diesem Treiber interpretiert werden, sodass das Speichern im Ganzen seine Bedeutung verliert, wenn der Treiber wechselt
    dm["Struktur DEVMODE"]
    dm --> pub["Öffentlicher Teil (dmSize)"]
    dm --> priv["Privater Teil (dmDriverExtra)"]
    pub --> chk["Von Windows geprüft"]
    priv --> only["Nur von diesem Treiber interpretiert"]
    only --> lost["Verliert die Bedeutung, wenn der Treiber wechselt"]

Abbildung 15: Von einer ganz gespeicherten Einstellung ist der Teil, der kaputtgeht, der private Teil.

Ein PrinterSettings, das seine Einstellungen über SetHdevmode erhalten hat, kopiert diesen privaten Bereich intern.²³ Die .NET-Framework-Version von PrinterSettings hat das Attribut Serializable, und die binäre Serialisierung schließt private Felder standardmäßig ein, sodass das Speichern des ganzen Objekts dieselbe Abhängigkeit mitnimmt.²⁴²⁵

Die .NET-Version von PrinterSettings hat dagegen kein Attribut Serializable, und eine Implementierung, die die öffentlichen Eigenschaften einzeln in einem eigenen Format speichert, speichert weder den nativen DEVMODE-Puffer noch den Bereich dmDriverExtra.²⁴ Worauf in diesem Fall zu achten ist, sind treiberabhängige Werte.

flowchart TB
    accTitle: Das Speichern von DEVMODE und das Speichern verwalteter Werte gehen unterschiedlich kaputt
    accDescr: Eine Implementierung, die den DEVMODE-Puffer ganz speichert, und eine, die ein PrinterSettings nach dem Empfang des privaten Bereichs über SetHdevmode ganz serialisiert, nehmen den privaten Teil mit und verlieren die Bedeutung, wenn der Treiber wechselt; eine Implementierung, die Werte öffentlicher Eigenschaften speichert, nimmt Custom- oder herstellerspezifische Papier- und Fachnummern mit, die Werte gegenüber der Liste des Herstellertreibers sind und unter dem IPP-Klassentreiber nicht dieselbe Bedeutung garantieren; beide werden durch einen Entwurf ersetzt, der nur die Absicht speichert
    a["DEVMODE ganz speichern"]
    a --> a1["Nimmt den privaten Teil mit"]
    s["Nach SetHdevmode ganz speichern"] --> a1
    a1 --> a2["Verliert die Bedeutung, wenn der Treiber wechselt"]
    b["Werte öffentlicher Eigenschaften speichern"]
    b --> b1["Nimmt benutzerdefinierte Papier- und Fachnummern mit"]
    b1 --> b2["Keine Garantie derselben Bedeutung auf dem neuen Treiber"]
    a2 --> c["Beide gehen zum Speichern nur der Absicht über"]
    b2 --> c

Abbildung 16: Das Speichern des ganzen Objekts nach SetHdevmode fällt auf die Seite des privaten Teils; die Fehlerarten unterscheiden sich, aber beide nehmen den Treiberzustand mit.

Steht RawKind für ein Standard-PaperKind oder PaperSourceKind, behält es beim Treiberwechsel seine Bedeutung. Nicht garantiert ist, dass Custom oder herstellerspezifische Nummern auf einem anderen Treiber auf dasselbe Papier oder Fach zeigen. Behandeln Sie Standardwerte nicht pauschal als kaputtgehend.²⁶²⁷

flowchart TB
    accTitle: Welche gespeicherten Papier- und Fachwerte kaputtgehen
    accDescr: Unter den RawKind-Werten behalten diejenigen, die Standardpapierformaten (PaperKind) wie A4 oder Standardpapierquellen (PaperSourceKind) wie Upper und Lower entsprechen, beim Treiberwechsel ihre Bedeutung, während Custom und herstellerspezifische Werte Nummern gegenüber der Liste des Herstellertreibers sind und der IPP-Klassentreiber nicht garantiert, sie als dasselbe Papier oder Fach zu interpretieren
    raw["Gespeicherter RawKind"]
    raw --> std["Standardwerte (PaperKind usw.)"]
    raw --> cus["Custom und herstellerspezifische Werte"]
    std --> keep["Behält die Bedeutung, wenn der Treiber wechselt"]
    cus --> lost["Keine Garantie desselben Papiers oder Fachs"]

Abbildung 17: Was kaputtgeht, sind nicht die Standardwerte, sondern die benutzerdefinierten Werte gegenüber der Liste des Herstellertreibers.

Ein PrintTicket definiert seine öffentlichen Schlüsselwörter ebenfalls im Namensraum psk, kann aber gerätespezifische private Erweiterungen enthalten. Die Regel lautet, dass Elemente Dritter in einen Namensraum gehören, der klar mit diesem Dritten verbunden ist. Erscheint in dem gespeicherten XML ein Hersteller-Namensraum, prüfen Sie ihn als treiberspezifische Einstellung.²⁸²⁹

Abhilfe: Nur die „Absicht“ speichern

Halten Sie die Absicht, also die Wahl von Papierformat, Ausrichtung, Duplex, Kopien und Fach, in einer eigenen Einstellungsdatei mit öffentlichen Schlüsselwörtern. Statt den internen Zustand des Treibers weiterzutragen, gleichen Sie ihn unmittelbar vor dem Druck mit den aktuellen Fähigkeiten ab.

In WPF holen Sie die Fähigkeiten mit PrintQueue.GetPrintCapabilities, drücken die Anforderung als PrintTicket aus und übergeben sie an MergeAndValidatePrintTicket.³⁰ Worauf hier zu achten ist: Eine nicht unterstützte Anforderung erzeugt nicht unbedingt einen Fehler. Der Treiber kann den Konflikt auflösen und ein gültiges Ticket zurückgeben, in der Regel mit einer durch einen Standard oder Ähnliches ersetzten Einstellung.

Ist ValidationResult.ConflictStatus gleich ConflictResolved, vergleichen Sie Duplex und Fach in ValidatedPrintTicket mit der Anforderung, protokollieren Sie den Unterschied und benachrichtigen Sie den Benutzer.³¹

flowchart TB
    accTitle: Ein Entwurf, der nur die Absicht speichert und sie unmittelbar vor dem Druck mit den Fähigkeiten abgleicht
    accDescr: Die Einstellungsdatei hält nur die Absicht für Papier, Ausrichtung, Duplex, Kopien und Fach in öffentlichen Schlüsselwörtern; unmittelbar vor dem Druck die Fähigkeiten des aktuellen Druckers mit GetPrintCapabilities holen, durch MergeAndValidatePrintTicket führen, bei ConflictStatus NoConflict unverändert drucken und bei ConflictResolved die ersetzten Punkte mit der Anforderung vergleichen und in Protokoll und Benachrichtigung geben
    cfg["Einstellungsdatei: nur Absicht (Papier, Ausrichtung, Duplex, Kopien)"]
    cfg --> caps["GetPrintCapabilities unmittelbar vor dem Druck"]
    caps --> merge["MergeAndValidatePrintTicket"]
    merge --> st{"ConflictStatus"}
    st -->|"NoConflict"| print["Drucken"]
    st -->|"ConflictResolved"| tell["Unterschied zur Anforderung protokollieren und benachrichtigen"]

Abbildung 18: Speichern Sie die Absicht der Einstellungen und prüfen Sie sie zur Druckzeit gegen die aktuellen Fähigkeiten. Verwenden Sie eine ersetzte Einstellung nicht still; prüfen Sie den Unterschied.

In WinForms wählen Sie das Papier aus PrinterSettings.PaperSizes erneut nach Kind oder Abmessungen statt nach Namen. Papierquellen aus PaperSources können wiederverwendet werden, wenn sie eindeutige Standardwerte wie Upper oder Lower sind, aber mehrere proprietäre Fächer können zusammengefasst als PaperSourceKind.Custom zurückkommen. Und PaperSource trägt keine Papierabmessungen. Identifizieren Sie ein proprietäres Fach nicht allein über Kind; ordnen Sie es ausdrücklich den aktuellen Fähigkeiten zu oder lassen Sie den Benutzer erneut wählen.²⁷

5.3 Prüfung 2: Gibt es eine Abhängigkeit von Drucker- oder Warteschlangennamen?

Der vorherige Artikel empfahl, den Druckernamen in einer Einstellungsdatei zu halten. Was hier hinzukommt, ist die Voraussetzung, dass nicht garantiert ist, dass nach einem Treiberwechsel oder einer erneuten Erkennung eine Warteschlange mit demselben Namen entsteht. Eine Einstellung, die auf den alten Warteschlangennamen zeigt, verliert so ihr Druckziel.

Die zu prüfenden Stellen sind drei: die Einstellungsdatei, im Code fest verdrahtete Namen und das Innere von SDKs und Berichtsbibliotheken. Auch wenn der eigene Code keinen festen Namen hat, kann ein Hersteller-SDK intern eine bestimmte Warteschlange oder einen Treiber aufrufen. Gleichen Sie die SDK-Dokumentation mit der Liste aus 5.1 ab.

flowchart TB
    accTitle: Drei Stellen, an denen eine Abhängigkeit vom Warteschlangennamen verborgen sein kann
    accDescr: Eine Abhängigkeit vom Warteschlangennamen kann an drei Stellen verborgen sein, einem festen Namen in der Einstellungsdatei, einem im Code fest verdrahteten Namen und der Warteschlange oder dem Treiber, den ein Hersteller-SDK oder eine Berichtsbibliothek intern aufruft; die ersten beiden findet man durch Suche in Code und Einstellungen, die letzte durch die SDK-Dokumentation und die Liste aus 5.1
    dep["Abhängigkeit von Warteschlangennamen"]
    dep --> cfg["Fester Name in der Einstellungsdatei"]
    dep --> code["Im Code fest verdrahteter Name"]
    dep --> sdk["Fest im SDK oder in der Bibliothek"]
    cfg --> grep["Durch Suche in Code und Einstellungen finden"]
    code --> grep
    sdk --> doc["Mit der SDK-Dokumentation und der Liste aus 5.1 bestätigen"]

Abbildung 19: Auch wenn der eigene Code keinen Warteschlangennamen hat, kann eine Abhängigkeit im Inneren eines SDKs oder einer Bibliothek bleiben.

Die Abhilfe besteht darin, beim Start zu prüfen, dass der konfigurierte Name in PrinterSettings.InstalledPrinters existiert, und wenn er nicht gefunden wird, ihn zu protokollieren und den Benutzer zu benachrichtigen. Machen Sie es außerdem möglich, das Druckziel auf dem Einstellungsbildschirm erneut zu wählen.

Fallen Sie nicht still auf den Standarddrucker zurück. Das versteckt einen Beleg, der aus dem Drucker einer anderen Abteilung kommt, als normalen Druck.

flowchart TB
    accTitle: Prüfung des Druckernamens beim Start
    accDescr: Beim Start prüfen, ob der Druckername in der Einstellungsdatei in InstalledPrinters existiert; wenn ja, drucken; wenn nein, protokollieren, den Benutzer benachrichtigen und erneut wählen lassen, und nicht still auf den Standarddrucker zurückfallen
    start["Start: Druckername aus den Einstellungen"]
    start --> exists{"Existiert in InstalledPrinters?"}
    exists -->|"Ja"| print["Auf diese Warteschlange drucken"]
    exists -->|"Nein"| log["Protokollieren und den Benutzer benachrichtigen"]
    log --> pick["Auf dem Einstellungsbildschirm erneut wählen"]
    exists -.->|"das nicht tun"| silent["Still auf den Standarddrucker zurückfallen"]

Abbildung 20: Eine Implementierung, die still auf einen anderen Drucker druckt, wenn das Ziel nicht gefunden wird, erzeugt den Fehler, der am längsten unentdeckt bleibt.

5.4 Prüfung 3: Wird ein virtueller Drucker zur Dateierzeugung verwendet?

Ein Berichtsarchiv, das auf einen PDF-Drucker Dritter druckt und den Ausgabeordner überwacht, oder eine Verarbeitung, die Zwischendateien mit dem XPS Document Writer erzeugt, bleibt stehen, wenn die verwendete Warteschlange von WPP entfernt wird.

Entfernt werden jedoch Softwaredrucker, die WPP nicht unterstützt. Verwechseln Sie nicht unterstützte Produkte etwa nach Art einer Port-Monitor-DLL nicht mit Produkten, die für WPP-Unterstützung aktualisiert wurden, etwa OneNote. Schritt 3 in Kapitel 7 bestätigt, ob die tatsächlich verwendete Warteschlange ein Entfernungsziel ist.²

Wenn Sie ein PDF wollen, ist, wie in Kapitel 5 des vorherigen Artikels erklärt, der Wechsel zu einem Aufbau, der es direkt mit einer PDF-Bibliothek erzeugt, der Entwurf, der am wenigsten von Änderungen im Druckstapel abhängt.

5.5 Prüfung 4: Geht der RAW-Versand durch eine Warteschlange, die WPP entfernt?

RAW-Versand ist das Verfahren, Druckersprachdaten mit OpenPrinter → StartDocPrinter (Datentyp „RAW“) → WritePrinter → EndDocPrinter durch den Spooler zu schieben. Das Dokument muss die Druckeinstellungen vollständig in der Sprache der Hardware beschreiben, und die DEVMODE-Einstellungen werden nicht verwendet.³²³³

Es ist der übliche Ansatz für Etiketten und Belege, aber RAW-Versand ist keine „Direktkommunikation, die den Spooler umgeht“. Auch wenn der Treiber praktisch nur als Durchgang zum Port verwendet wird, geht dieser Durchgang verloren, wenn WPP die Warteschlange entfernt.

flowchart TB
    accTitle: Der Pfad des RAW-Versands und wo WPP ihn entfernt
    accDescr: Die Anwendung schiebt Druckersprachdaten mit OpenPrinter, StartDocPrinter und WritePrinter in den Spooler, und eine Warteschlange, die unter WPP nicht besteht (etwa eine Warteschlange auf einem Herstellertreiber), dient als Durchgang zum Port und weiter zum Drucker, sodass der Durchgang weg ist, wenn WPP diese Warteschlange entfernt
    app["Anwendung: StartDocPrinter (RAW), WritePrinter"]
    app --> spooler["Spooler"]
    spooler --> queue["Warteschlange, die unter WPP nicht besteht (Durchgang)"]
    queue --> port["Port"]
    port --> printer["Etiketten- oder Bondrucker"]
    wpp["WPP aktiviert"] -.->|"Warteschlange verschwindet"| queue

Abbildung 21: RAW-Versand verwendet den Treiber nur als Durchgang, aber der Durchgang selbst verschwindet.

Zu prüfen ist, an welche Kombination aus Warteschlange, Treiber und Port Sie senden. Nicht nur Warteschlangen auf Herstellertreibern, sondern auch mitgelieferte Treiber für physische Drucker außer dem IPP-Klassentreiber, etwa Generic / Text Only, können nicht als bestehend angenommen werden. Alles, was in der Entfernungsliste in Kapitel 7 als verschwindend bestätigt ist, braucht auf dieselbe Weise einen anderen Pfad.¹³

Außerdem sagt Microsoft Learn nicht, dass ein proprietäres PDL RAW an eine Warteschlange auf dem IPP-Klassentreiber gesendet werden kann. Weil es von den PDL abhängt, die die IPP-Implementierung des Druckers annimmt, schließen Sie nicht, dass „der Wechsel zu IPP dieselben RAW-Daten durchlässt“.

6. Ein Ausweg für Etiketten- und Bondrucker

KomuraSoft empfiehlt, für Etiketten und Belege mindestens einen Ausgabepfad zu haben, der nicht vom Spooler abhängt.

Auch wenn ein Drucker unter die Signierungsausnahme in Kapitel 2 fällt, sind die fortgesetzte Lieferung des Herstellertreibers und seine Verwendung unter WPP nicht garantiert.¹ Die Fehlerbehebungsanleitung von Microsoft hält auch einen Fall fest, in dem USB-verbundene Beleg- und Etikettendrucker nach einem Update 2021 aufhörten zu drucken und das Problem durch einen Known Issue Rollback behoben wurde.³⁴ Die Ausgabepfade getrennt zu kennen ist die Vorbereitung.

Für den Entwurf der TCP-Wiederverbindung gilt das Denken in Fallstricke bei seriellen Kommunikationsanwendungen. Zur Wahl einer USB-Methode siehe USB-Geräte aus einer Windows-App ansprechen. IPP ist auf manchen Druckern standardmäßig deaktiviert und muss aktiviert werden.⁴

Der Name „SDK“ allein sagt nicht, ob ein Pfad unabhängig ist. Bestätigen Sie anhand der SDK-Dokumentation und der Liste aus 5.1, ob es mit dem Gerät direkt spricht oder am Ende eine Windows-Warteschlange aufruft.

Wenn eine Windows-Warteschlange verwendet wird, liegt Universal Print auf der WPP-kompatiblen Seite, geht aber ebenfalls durch den Spooler. Eine Warteschlange, die weder der IPP-Klassentreiber noch Universal Print ist, bleibt unter WPP stehen, wenn sie ein Treiber Dritter, XPS oder Fax ist, und eine mitgelieferte Warteschlange, die nicht auf der Entfernungsliste steht, etwa Microsoft Print to PDF, wird einzeln beurteilt. „WPP-kompatibel“ und „spoolerunabhängig“ sind verschiedene Klassifikationen.

flowchart TB
    accTitle: Ablauf zur Entscheidung, ob ein Ausgabepfad vom Spooler abhängt
    accDescr: Sendet der Kandidatenpfad an eine Windows-Druckerwarteschlange, dann hängen eine Warteschlange auf dem IPP-Klassentreiber, deren Drucker Mopria-zertifiziert ist und bei Netzwerkverbindungen IPP aktiviert und erreichbar hat oder bei USB-Verbindungen im Modus IPP over USB ist, und eine Universal-Print-Warteschlange als Teil von Windows Ready Print vom Spooler ab, sind aber WPP-kompatibel; Warteschlangen auf nicht Mopria-zertifizierten Geräten oder Treibern Dritter und laut Tabelle in Kapitel 4 entfernte Warteschlangen wie der XPS Document Writer und Fax können unter WPP stehen bleiben; mitgelieferte Warteschlangen, die nicht auf der Entfernungsliste stehen, etwa Microsoft Print to PDF, werden wie in 5.1 einzeln beurteilt; sendet er nicht an eine Warteschlange, kehrt ein SDK, das intern eine Warteschlange oder einen Treiber aufruft, zur selben Beurteilung zurück, während ein SDK, das das nicht tut, oder ein Pfad, der direkt an das Gerät sendet, ein Ausweg ohne Abhängigkeit vom Spooler ist
    route["Kandidaten-Ausgabepfad"]
    route --> q1{"Sendet an eine Windows-Druckerwarteschlange?"}
    q1 -->|"Ja"| q4{"Warteschlange auf dem IPP-Klassentreiber?"}
    q4 -->|"Ja"| q5{"Mopria-zertifiziert?"}
    q5 -->|"Ja"| q9{"IPP erreichbar? (USB: over USB)"}
    q9 -->|"Ja"| depok["Hängt ab, aber WPP-kompatibel"]
    q9 -->|"Nein"| dep["Hängt ab und kann unter WPP stehen bleiben"]
    q5 -->|"Nein"| dep
    q4 -->|"Nein"| q6{"Universal-Print-Warteschlange?"}
    q6 -->|"Ja"| depok
    q6 -->|"Nein"| q7{"Laut Tabelle in Kapitel 4 entfernt?"}
    q7 -->|"Ja (Treiber Dritter, XPS, Fax)"| dep
    q7 -->|"Nein (Print to PDF usw.)"| indiv["Einzeln beurteilen (5.1)"]
    q1 -->|"Nein"| q2{"Geht über ein Hersteller-SDK?"}
    q2 -->|"Ja"| q3{"Ruft intern eine Warteschlange oder einen Treiber auf?"}
    chk["Prüfen: SDK-Dokumentation und Liste aus 5.1"] -.-> q3
    q3 -->|"Ja"| q4
    q3 -->|"Nein"| indep["Ausweg ohne Abhängigkeit"]
    q2 -->|"Nein"| indep

Abbildung 22: Es kommt darauf an, durch welche Warteschlange der Pfad am Ende geht; abgesehen von einer Warteschlange auf dem IPP-Klassentreiber für ein Mopria-zertifiziertes Gerät und einer Universal-Print-Warteschlange kann alles außer mitgelieferten Warteschlangen, die nicht auf der Entfernungsliste stehen, unter WPP stehen bleiben.

7. Prüfverfahren — Mit und ohne WPP

Bestätigen Sie zuerst den Zweig der Prüfung danach, ob Sie WPP nutzen oder nicht. In beiden Fällen behalten Sie die Ausgabe von vor der Änderung und prüfen mit den Druckzielen, die Sie tatsächlich verwenden.

flowchart TB
    accTitle: Druckprüfverfahren, aufgeteilt danach, ob WPP genutzt wird
    accDescr: Alle Warteschlangen auf einer Prüfmaschine nachbilden und die Ausgabe von vor der Änderung speichern; wenn WPP genutzt wird, aktivieren, die entfernten Warteschlangen aufzeichnen, die Ausgabe nach Neu-Registrierung kompatibler Geräte vergleichen und den Ausweichpfad für inkompatible Geräte prüfen; wenn nicht, physische Geräte, die der IPP-Rangfolgeänderung unterliegen, bei deaktiviertem WPP erneut erkennen und die Ausgabe vergleichen, und für alles andere das Drucken auf den tatsächlichen Warteschlangen bestätigen
    prepare["Alle Warteschlangen nachbilden und aufzeichnen"]
    prepare --> baseline["Die Druckergebnisse von vor der Änderung speichern"]
    baseline --> use{"WPP nutzen?"}
    use -->|"Ja"| enable["Aktivieren und die entfernten Warteschlangen aufzeichnen"]
    enable --> compatible["Kompatible Geräte bei Bedarf neu registrieren"]
    compatible --> compare["Mit denselben Drucken wie zuvor vergleichen"]
    enable --> alternate["Inkompatible Geräte auf dem Ausweichpfad prüfen"]
    use -->|"Nein"| physical{"Physisches Gerät, das der IPP-Rangfolgeänderung unterliegt?"}
    physical -->|"Ja"| redetect["Bei deaktiviertem WPP entfernen und erneut erkennen"]
    redetect --> compare
    physical -->|"Nein"| existing["Drucken auf den tatsächlichen Warteschlangen bestätigen"]
    compare --> finish["Ergebnisse aufzeichnen und die Prüfmaschine wiederherstellen"]
    alternate --> finish
    existing --> finish

Abbildung 23: Die Ausgabe von vor der Änderung ist die gemeinsame Ausgangslage, und nur Umgebungen, die WPP nutzen, aktivieren ihn. Umgebungen, die ihn nicht nutzen, prüfen die IPP-Rangfolgeänderung und das Drucken auf den tatsächlichen Warteschlangen.

7.1 Gemeinsame Vorbereitung: Jedes Druckziel auf einer Prüfmaschine nachbilden, nicht in der Produktion

Verwenden Sie zur Prüfung einen PC mit Windows 11 24H2 oder höher und tun Sie es nicht auf einem Produktions-PC. Für Netzwerkverbindungen reicht eine VM, die dieselben Drucker erreichen kann. Um USB-Neu-Registrierung oder Direktkommunikation zu bewerten, verwenden Sie eine physische Prüfmaschine, sofern die VM nicht dieselbe USB-Schnittstelle durchreichen kann.

Unabhängig davon, ob WPP genutzt wird, bewahren die folgenden Schritte 1 und 2 den Zustand vor der Änderung.

1. Jede Warteschlange nachbilden, die die Anwendung vor Ort nutzt. Installieren Sie nicht nur die physischen Drucker auf Herstellertreibern, sondern auch PDF-virtuelle Drucker Dritter und mitgelieferte Warteschlangen wie Generic / Text Only in derselben Konfiguration. Zeichnen Sie Treibernamen und Versionen mit dem Skript aus 5.1 auf. Die Entfernungsdifferenz kann nur Warteschlangen beurteilen, die auf der Prüfmaschine existieren.
2. Die Druckfunktionen durchlaufen und die Ausgabe speichern. Prüfen Sie die Einstellungsbildschirme für Papier, Fach, Duplex und Kopien, das Drucken jedes Berichts, die PDF-Ausgabe und den Etikettendruck, um eine Ausgangslage für den späteren Vergleich zu schaffen.

flowchart TB
    accTitle: Auf der Prüfmaschine nachzubildende Warteschlangen
    accDescr: Von den Warteschlangen, die die Anwendung laut Inventur in 5.1 nutzt, die physischen Drucker auf Herstellertreibern, die virtuellen Drucker wie PDF Dritter und die Warteschlangen auf mitgelieferten Treibern wie Generic / Text Only alle auf der Prüfmaschine in derselben Konfiguration wie vor Ort nachbilden, wodurch sichtbar wird, dass die Entfernungsliste in Schritt 3 nur Warteschlangen beurteilen kann, die auf der Prüfmaschine existieren
    inv["Inventur 5.1: Warteschlangen, die die Anwendung nutzt"]
    inv --> phys["Physische Drucker (Herstellertreiber)"]
    inv --> virt["Virtuelle Drucker (PDF Dritter usw.)"]
    inv --> inbox["Mitgelieferte Treiber (Generic / Text Only usw.)"]
    phys --> vm["Auf der Prüfmaschine in derselben Konfiguration nachbilden"]
    virt --> vm
    inbox --> vm
    vm --> judge["Bestehen mit der Entfernungsliste in Schritt 3 beurteilen"]
    note["Fehlende Warteschlangen erscheinen nicht in der Entfernungsdifferenz"] -.-> judge

Abbildung 24: Eine auf der Prüfmaschine fehlende Warteschlange erscheint nicht in der Entfernungsdifferenz; bilden Sie deshalb zuerst jede Warteschlange nach, die die Inventur gefunden hat.

7.2 Umgebungen, die WPP nutzen: Aktivieren und prüfen, einschließlich der verschwundenen Druckziele

Nach den Schritten 1 und 2 fahren Sie in der folgenden Reihenfolge fort.

3. WPP aktivieren und die entfernten Warteschlangen aufzeichnen. Die Wahl von „Einrichten“ unter „Windows protected print mode“ in „Drucker und Scanner“ in der Einstellungen-App zeigt die Entfernungsziele in einem Dialog.² Bei Aktivierung über Gruppenrichtlinie erscheint kein Dialog; speichern Sie deshalb das Ergebnis von Get-Printer vor dem Anwenden der Richtlinie und starten Sie die Prüfmaschine nach dem Anwenden neu. Bestätigen Sie die Aktivierung mit IsProtectedPrintEnabled oder dem Einstellungsbildschirm, nehmen Sie die Liste erneut auf und zeichnen Sie die Differenz auf.¹⁴
4. Die entfernten kompatiblen Drucker neu installieren. Installieren Sie sie mit Windows Ready Print neu und bestätigen Sie mit dem Skript aus 5.1, dass der DriverName des physischen Druckers zu Microsoft IPP Class Driver geworden ist.
5. Dieselben Drucke wiederholen und mit dem Zustand vor der Änderung vergleichen. Prüfen Sie die Auswahl auf den Einstellungsbildschirmen, die Wiederherstellung gespeicherter Einstellungen und den Verlust von Druckzielen durch geänderte Warteschlangennamen. Gleichen Sie außerdem Ränder, Schriften und Linien der Ausgabe mit der Ausgabe aus Schritt 2 ab.
6. Inkompatible Geräte über den Ausweichpfad aus Kapitel 6 drucken. Bilden Sie den Zustand nach, in dem „der Drucker nicht in der Liste ist“, und bestätigen Sie, dass die Ausgabe weiterhin funktioniert. Nicht nur der reparierte Code, sondern auch der bereitgestellte Pfad ist Gegenstand der Prüfung.

7.3 Umgebungen, die WPP nicht nutzen: Die Änderung der Treiberauswahl ohne Aktivierung prüfen

In einer Umgebung, in der Sie entschieden haben, WPP nicht zu nutzen, führen Sie die Schritte 3 und 4 nicht aus. Die Aktivierung von WPP entfernt ganze Warteschlangen, wodurch die Wirkung der Rangfolge allein unsichtbar wird.

7.4 Nach der Prüfung wiederherstellen und das Bereitstellungsverfahren vorbereiten

Eine Prüfmaschine, auf der WPP in der lokalen Einstellungen-App aktiviert wurde, lässt sich mit „Ausschalten“ wiederherstellen. Wurde es über Gruppenrichtlinie oder Intune angewendet, ist eine Richtlinienänderung auf Administratorseite erforderlich; bereiten Sie deshalb ein Wiederherstellungsverfahren vor, das zum Aktivierungsweg passt.²¹³

Das Ausschalten von WPP lässt die mit Windows Ready Print neu installierten Drucker, wie sie sind. Inkompatible Drucker werden manuell neu installiert.²¹⁰

Für die Bereitstellung bauen Sie die WPP-Richtlinie und das Verfahren zur Neu-Registrierung der Drucker in den Verteilungsmechanismus ein, der in Von Gruppenrichtlinien zu Intune beschrieben ist. Die Verteilung von Treibern Dritter über Point and Print erfordert seit KB5005652 im Jahr 2021 standardmäßig Administratoranmeldeinformationen,³⁴ und unter WPP findet die Verteilung selbst nicht mehr statt.⁹ In Umgebungen, die WPP nutzen, ersetzen Sie Verfahren, die von der Treiberverteilung abhängen, durch dieses Anwenden der Richtlinie und das Verfahren zur Neu-Registrierung.

flowchart TB
    accTitle: Überarbeitung des Bereitstellungsverfahrens
    accDescr: Das Verfahren, das Treiber Dritter über Point and Print verteilte, entfällt, weil seit 2021 Administratoranmeldeinformationen erforderlich sind und unter WPP die Verteilung selbst nicht mehr stattfindet, und an seiner Stelle werden die WPP-Richtlinie (Gruppenrichtlinie oder OMA-URI) und das Verfahren zur Neu-Registrierung der Drucker in den Verteilungsmechanismus eingebaut
    old["Treiber Dritter über Point and Print verteilen"]
    old --> why1["Seit 2021 Administratoranmeldeinformationen erforderlich"]
    old --> why2["Unter WPP überhaupt keine Verteilung"]
    why1 --> drop["Aus dem Verfahren streichen"]
    why2 --> drop
    drop --> add["WPP-Richtlinie und Verfahren zur Neu-Registrierung einbauen"]

Abbildung 25: Das Verfahren zur Verteilung von Treibern wird durch ein Verfahren zur Verteilung der WPP-Richtlinie und zur Neu-Registrierung der Drucker ersetzt.

8. Zusammenfassung

Die erforderliche Reaktion entscheidet sich in der Reihenfolge „bleibt das Druckziel bestehen?“ → „wovon hängt der Code ab?“ → „unter welchen Bedingungen prüfen wir?“.

Eine Sache zu reparieren ist nicht das Ende. Gehen Sie nach dem Reparieren der Einstellungen weiter zu Warteschlangennamen, virtuellen Druckern und RAW-Versand und bestätigen Sie schließlich die Ausgabe wie in Kapitel 7. Auf Geräten, auf denen die IPP-Rangfolgeänderung auch ohne WPP eintreten kann, brauchen Sie die Inventur der Abhängigkeiten und die Prüfung der erneuten Erkennung bei deaktiviertem WPP.

flowchart TB
    accTitle: Entscheidungsbaum, ob zu reparieren oder nur zu prüfen ist
    accDescr: Zuerst entscheiden, ob die Zielwarteschlange unter WPP besteht (eine Cloud-Warteschlange von Universal Print oder ein von WPP unterstützter virtueller Drucker) oder ob der physische Drucker mit Windows Ready Print neu registriert werden kann; wenn nicht, zwischen dem Bereitstellen eines anderen Pfads und dem Nichtnutzen von WPP wählen; unterstützt das Gerät IPP und kann durch die Rangfolgeänderung ersetzt werden, der Reihe nach Speichern treiberspezifischer Einstellungen, Abhängigkeiten von Warteschlangennamen oder virtuellen Druckern (einschließlich in SDKs und Bibliotheken) und RAW-Versand prüfen und jede zutreffende Stelle reparieren, bevor es weitergeht; schließlich gehen Umgebungen, die WPP nutzen, zur Prüfung mit aktiviertem WPP in Kapitel 7, Umgebungen, die ihn nicht nutzen, senden physische IPP-fähige Geräte zur Prüfung der erneuten Erkennung bei deaktiviertem WPP und Cloud- oder virtuelle Warteschlangen zur Prüfung der tatsächlichen Ausgabe, und wenn WPP nicht genutzt wird und der Wechsel keine Wirkung hat, auf dem aktuellen Pfad weiterarbeiten
    q0{"Bleibt die Warteschlange unter WPP oder lässt sie sich neu registrieren?"}
    q0 -->|"Nein"| alt{"Was zu tun ist"}
    alt -->|"Anderen Pfad bereitstellen"| qi{"Unterstützt IPP und kann ersetzt werden?"}
    alt -->|"WPP nicht nutzen"| qi2{"Unterstützt IPP und kann ersetzt werden?"}
    qi -->|"Ja"| q1{"Werden treiberspezifische Einstellungen gespeichert?"}
    qi -->|"Nein"| verify["Nur prüfen (Kapitel 7)"]
    qi2 -->|"Ja"| q1
    qi2 -->|"Nein"| keep["Auf dem aktuellen Pfad weiterarbeiten"]
    q0 -->|"Ja"| q1
    q1 -->|"Ja"| fix1["Reparieren (5.2)"]
    fix1 --> q2{"Hängt von Warteschlangennamen oder virtuellen Druckern ab?"}
    sdk["Einschließlich Abhängigkeiten in SDKs und Bibliotheken"] -.-> q2
    q1 -->|"Nein"| q2
    q2 -->|"Ja"| fix2["Reparieren (5.3, 5.4)"]
    fix2 --> q3{"Sendet RAW an eine Warteschlange, die unter WPP nicht besteht?"}
    q2 -->|"Nein"| q3
    q3 -->|"Ja"| fix3["Einen Durchgang bereitstellen (Kapitel 6)"]
    fix3 --> vq{"WPP nutzen?"}
    q3 -->|"Nein"| vq
    vq -->|"Ja"| verify
    vq -->|"Nein"| pq{"Physisches IPP-fähiges Gerät?"}
    pq -->|"Ja"| redetect["Prüfung der erneuten Erkennung ohne WPP (7.3)"]
    pq -->|"Nein"| outchk["Ausgabe auf den tatsächlichen Warteschlangen bestätigen"]

Abbildung 26: Entscheiden Sie zuerst, ob die Warteschlange unter WPP besteht; bei Codeabhängigkeiten gehen Sie auch nach dem Reparieren einer Stelle zur nächsten Prüfung weiter und prüfen den reparierten Pfad am Ende. Wird WPP nicht genutzt, prüfen Sie nicht mit der WPP-Aktivierung in Kapitel 7, sondern durch erneute Erkennung physischer IPP-fähiger Geräte bei deaktiviertem WPP und durch tatsächliche Ausgabe auf Cloud- und virtuellen Warteschlangen.

Die Vorbereitungsfrist auf den eigenen Rolloutplan legen, nicht auf Microsofts Daten

Von WPP heißt es, er werde künftig standardmäßig aktiviert, aber ein Datum wird nicht genannt.¹⁰ Legen Sie die Vorbereitungsfrist vor den Zeitpunkt, an dem Sie WPP selbst aktivieren, oder vor den Rollout des Feature-Updates auf Windows 11 24H2 oder höher vor Ort. Der 1. Juli 2027 ist ein Meilenstein auf der Angebotsseite der Treiber, keine Frist für Geschäftsanwendungen.¹

flowchart TB
    accTitle: Wo die Vorbereitungsfrist auf Seiten der Geschäftsanwendung liegt
    accDescr: Jetzt die Liste aufnehmen und inventarisieren, die Pfadänderungen und die Prüfung bis zur eigenen Frist abschließen, also bevor Sie WPP selbst aktivieren oder das Feature-Update 24H2 oder höher ausrollen; der Stopp der Treiberaktualisierungen am 1. Juli 2027 ist ein Meilenstein auf der Angebotsseite, nicht die Vorbereitungsfrist, und das Ziel ist ein Zustand, der von der standardmäßigen Aktivierung von WPP, deren Zeitpunkt unbestimmt ist, unberührt bleibt, wann immer sie kommt
    now["Jetzt: Liste aufnehmen und inventarisieren"]
    now --> prep["Pfadänderungen und Prüfung"]
    prep --> deadline["Frist: bevor Sie WPP selbst aktivieren / bevor Sie das Feature-Update ausrollen"]
    deadline --> fine["Unberührt, wenn WPP standardmäßig aktiviert wird (Zeitpunkt unbestimmt)"]
    ms["1. Juli 2027: Treiberaktualisierungen enden"] -.->|"Meilenstein auf der Angebotsseite, keine Frist"| prep

Abbildung 27: Legen Sie die Frist auf den eigenen Rolloutplan und machen Sie Microsofts Meilensteindaten nicht zu Ihrer Grenze.

Beginnen Sie damit, an jedem Kundenstandort die Liste aufzunehmen und die Abhängigkeiten von Einstellungen, Druckzielen und Ausgabepfaden zu verstehen. Erzeugen Sie PDFs direkt und behalten Sie für Etiketten und Belege einen Pfad, der vom Druckstapel unabhängig ist. Prüfen Sie dann das Drucken unter den tatsächlichen Rolloutbedingungen.

Umgebungen, die bei Windows 10 bleiben, liegen außerhalb des Geltungsbereichs dieses Plans, aber der Support für Windows 10 (22H2) im regulären Kanal endete im Oktober 2025. Enterprise LTSC und IoT Enterprise LTSC haben je Edition andere Enddaten; prüfen Sie den Lebenszyklus. Zu Entscheidungen mit ESU und LTSC siehe Praktische Optionen nach dem Support-Ende von Windows 10, und für Industrie-PCs Welches Windows gehört auf einen Industrie-PC?. Die Vorbereitung auf das Drucken ist erst abgeschlossen, wenn Sie die Prüfung aus Kapitel 7 auf dem Windows 11, auf das Sie wechseln, erneut durchführen.

Verwandte Artikel

• Drucken und PDF-Ausgabe in Windows-Geschäftsanwendungen — System.Drawing.Printing, WPF und Berichtsbibliotheken richtig einsetzen
• Excel-Berichtsausgabe erstellen - COM/Open XML/Vorlagen
• Windows-Dienste erstellen und betreiben — Von der Abgrenzung zur Aufgabenplanung bis zur Umwandlung eines BackgroundService in einen Dienst
• USB-Geräte aus einer Windows-App ansprechen — Die Wahl zwischen virtual COM, HID, WinUSB und Hersteller-SDKs
• Fallstricke bei seriellen Kommunikationsanwendungen — von der Wiederverbindung bis zum Log-Design
• Von Gruppenrichtlinien zu Intune — Ein Leitfaden zur Gerätemanagement-Migration für kleine und mittlere Unternehmen
• Praktische Optionen nach dem Support-Ende von Windows 10 — Eine Entscheidungstabelle für ESU, LTSC und Ersatz

Verwandte Beratungsbereiche

KomuraSoft LLC übernimmt die Inventur der Druckertreiberabhängigkeiten von Geschäftsanwendungen mit Bericht- und Etikettendruck, die Überarbeitung von Druckpfaden (direkte PDF-Erzeugung, direkte Steuerung von Etikettendruckern) und den Entwurf von Prüfplänen, die Windows protected print mode voraussetzen.

• Technische Beratung und Design-Review
• Windows-App-Entwicklung
• Kontakt

Literatur

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Hören die Drucker und Anwendungen, die heute funktionieren, nach Juli 2026 oder Juli 2027 plötzlich auf zu drucken?

Nein. Microsofts Plan ist eine stufenweise Abschaltung auf der Angebotsseite: Neue Treiber Dritter werden nicht mehr in Windows Update veröffentlicht, die Treiberrangfolge bevorzugt den IPP-Klassentreiber, und Aktualisierungen werden nicht mehr angenommen. Der Plan stellt ausdrücklich fest, dass vorhandene Treiber nicht deaktiviert werden, und vorhandene Treiber lassen sich weiterhin über Installationsprogramme der Hersteller einrichten. Gefährlich sind bei Geräten, zu denen der IPP-Klassentreiber passt, der Moment, in dem ein PC ausgetauscht oder das Betriebssystem neu installiert wird und der Treiber automatisch durch den IPP-Klassentreiber ersetzt wird, und der Moment, in dem Windows protected print mode aktiviert wird.

Ist Windows protected print mode standardmäßig aktiviert?

Zum Zeitpunkt der Abfassung (September 2026) ist er standardmäßig deaktiviert und wird über die Einstellungen-App, Gruppenrichtlinie oder Intune aktiviert. Die FAQ von Microsoft sagt jedoch klar, dass er zu einem späteren Zeitpunkt standardmäßig aktiviert wird. Ein Datum wird nicht genannt; die Vorbereitung besteht darin, vorher einen Zustand zu erreichen, in dem die Aktivierung keine Probleme verursacht.

Was geschieht mit Etikettendruckern und Bondruckern?

Drucker, die keine Mopria-Zertifizierung erhalten können, stehen unter den Bedingungen, unter denen die Treibersignierung nach dem 15. Januar 2026 ausnahmsweise weiter zulässig ist. Ein Herstellertreiber kann also vorerst verfügbar bleiben, aber in einer Umgebung mit aktiviertem Windows protected print mode werden Drucker, die Treiber Dritter nutzen, deinstalliert und sind so nicht mehr verwendbar. Ein Hersteller-SDK, das mit dem Gerät direkt über TCP, USB oder seriell spricht, oder ein Pfad, der den Drucker durch direktes Senden seiner Druckersprache ansteuert, trennt Sie von Änderungen am Print Spooler. Ein SDK, das intern eine Windows-Warteschlange oder einen Treiber aufruft, bleibt genauso stehen, wenn der Treiber Dritter verschwindet, und ist deshalb kein Ausweg.

Kann der Druckcode der Anwendung bei PrintDocument bleiben?

Der GDI-Druckpfad und der XPS-Druckpfad bleiben, und Microsoft stellt klar, dass es keine Pläne gibt, die Funktionalität von v3/v4-Treibern zu deaktivieren. Eine Anwendung, die nur mit PrintDocument oder FixedDocument zeichnet, ist etwas zum Prüfen, nicht zum Reparieren. Zu reparieren ist Code, der treiberspezifische Einstellungen speichert und wiederherstellt (den privaten Teil von DEVMODE oder einen privaten Namensraum in einem PrintTicket), Code, der von einem bestimmten Warteschlangennamen oder virtuellen Druckernamen abhängt (einschließlich dessen, was ein Hersteller-SDK oder eine Berichtsbibliothek intern aufruft), und Code, der RAW-Daten über den Spooler an eine Warteschlange sendet, die unter WPP nicht bestehen bleibt (etwa eine Warteschlange auf einem Herstellertreiber). Ist der Zieldrucker selbst ein Modell, das sich mit Windows Ready Print nicht neu registrieren lässt, verschwindet unter Windows protected print mode die ganze Warteschlange, selbst wenn der Code nur zeichnet; dann steht die Bereitstellung eines anderen Pfads zuerst.

Wo soll ich anfangen?

Beginnen Sie damit, an jedem Kundenstandort die Liste der Drucker und Treiber aufzunehmen. Get-Printer und Get-PrinterDriver in PowerShell zeigen ohne Administratorrechte, welche Warteschlange welchen Treiber nutzt (v3 oder v4 oder den IPP-Klassentreiber). Ordnen Sie diese Liste anschließend den Warteschlangen zu, die die Anwendung namentlich nennt, für die sie Einstellungen speichert oder an die sie RAW-Daten sendet, und sortieren Sie sie mit der Entscheidungstabelle in diesem Artikel in „belassen“, „prüfen“ und „Pfad ändern“.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.