By Henning Volkmer on Juni 16, 2026
TL;DR
Ja. Mac- und Linux-Clients können weiterhin über einen Microsoft Windows-Druckserver drucken, sowohl im Windows Ready Print (WRP)- als auch im Windows Protected Print Mode (WPP), solange der Druckserver Warteschlangen über IPP oder IPPS bereitstellt. macOS und Linux nutzen beide CUPS zum Drucken, und CUPS spricht IPP nativ. Einfaches Drucken funktioniert ohne treiberseitige Änderungen. Erweiterte Endverarbeitungsfunktionen sind auf standardmäßige IPP-Attribute beschränkt. Herstellerspezifische Steuerelemente für die Endverarbeitung, die zuvor einen Herstellertreiber auf dem Client erforderten, sind auf diesem Weg nicht verfügbar.
Wie Mac und Linux heute an Windows-Druckserver drucken
Nicht-Windows-Clients, die sich mit einem Microsoft Windows-Druckserver verbinden, hatten schon immer zwei Möglichkeiten: SMB-basiert (die Druckwarteschlange als SMB‑Freigabe einbinden, über SMB übermitteln, der Server übernimmt die Weiterleitung – historisch dominant in gemischten Umgebungen wegen der AD-Authentifizierung und der vertrauten Netzwerkdrucker-UX), und IPP-basiert (direkte Verbindung zur Warteschlange über IPP, in macOS unter „Drucker & Scanner“ als „IPP“ angezeigt und von Linux CUPS wie jede andere Warteschlange behandelt). Beide Wege sind seit Jahren verfügbar. Die Frage für WRP und WPP ist, was sich an beiden ändert.
Was WRP und WPP ändern und was nicht
Eine kurze Unterscheidung ist hier wichtig. Windows Ready Print (WRP) ist Microsofts Bezeichnung für die moderne Druckplattform: IPP-basiert und standardmäßig treiberlos, wobei ältere Treiber von Drittanbietern weiterhin als Fallback verfügbar sind. Windows Protected Print Mode (WPP) ist die strikte Erzwingungsebene, die darauf aufbaut: Wenn WPP aktiviert ist, entfällt der Fallback, ältere Treiber werden vollständig blockiert und nur Mopria‑zertifizierte Drucker funktionieren. Microsoft hat die Bezeichnung WRP im Mai 2026 eingeführt. Die zugrunde liegende Plattform ist dieselbe; der Unterschied besteht darin, ob der ältere Fallback vorhanden ist.
Für Mac‑ und Linux‑Clients ist die Unterscheidung zwischen WRP und WPP weniger relevant als für Windows‑Clients, da die Erzwingung auf der Windows‑Client‑Seite und nicht auf der Server‑Seite stattfindet.
WPP und WRP werden auf Windows‑Clients erzwungen, nicht auf Windows‑Servern. Der Windows‑Druckserver selbst implementiert WPP oder WRP nicht in dem Sinne, dass er Mac‑ und Linux‑Clients steuert; er bietet weiterhin das, was er schon immer hatte (IPP‑Warteschlangen, SMB‑Freigaben, GPO‑gesteuerte Konfiguration, der Spooler‑Dienst). Windows Server 2025 enthält WPP als Funktion, aber die maßgebliche Erzwingung passiert auf der Windows‑Client‑Seite der Verbindung.
Für einen Mac‑ oder Linux‑Client gelten diese Erzwingungen nicht. macOS und Linux haben keinen Windows print spooler mit dem Drittanbieter‑Treibermodell, das WPP abschafft. Sie nutzen CUPS, das von Anfang an auf IPP ausgelegt ist. Die Client‑Seite bleibt also von WRP‑Defaults und der WPP‑Erzwingung unberührt.
Was sich ändert, ist, was der Windows‑Druckserver über seine Warteschlangen anbieten kann. Im Einzelnen:
- IPP‑Warteschlangen bleiben funktionsfähig. Ein Windows‑Druckserver, der IPP‑Warteschlangen hostet, stellt diese weiterhin über IPP/IPPS zur Verfügung. Mac‑ und Linux‑Clients verbinden sich, senden IPP‑formatierte Druckaufträge und der Server leitet sie an die Drucker weiter. Dieser Weg funktioniert sowohl unter WRP als auch unter WPP weiter.
- SMB‑basiertes Drucken auf Windows Server 2025 hat ein bekanntes Problem. Der Zugriff auf SMB‑Druckwarteschlangen für macOS‑Clients weist speziell mit Windows Server 2025 ein dokumentiertes Kompatibilitätsproblem auf – Aufträge gelangen in die Warteschlange und schlagen dann ohne Fehlermeldung fehl, unabhängig von der WPP‑ oder WRP‑Erzwingung. Dies ist kein WPP/WRP‑Problem; es ist ein separates Verhalten von Server 2025, das Microsoft anerkannt, aber noch nicht behoben hat. Linux‑Clients, die CUPS‑basierte SMB‑Verbindungen nutzen, können anders betroffen sein. Wenn deine Umgebung Mac‑Clients über SMB an einen Windows Server 2025‑Druckserver routet, ist IPP der empfohlene Weg, und er funktioniert zuverlässig.
-
Das Herunterladen von Treibern auf Clients über SMB trifft ohnehin nicht auf Nicht‑Windows‑Clients zu. Das ist der WPP‑betroffene Pfad für Windows‑Clients, aber es ist ein Windows‑spezifischer Mechanismus. Mac‑ und Linux‑Clients ziehen auch in einer vor WPP/WRP‑Umgebung keine Windows‑Treiber vom Druckserver. Sie verwenden CUPS‑auflösbare Pfade oder lokal installierte PostScript‑/PCL‑Treiber.
Was mit WRP und WPP verfügbar ist und was eingeschränkt bleibt
Grundlegendes Drucken und Authentifizierung: unbeeinflusst.
Seitenausgabe, Farbe/Schwarzweiß, Duplex, N‑up und andere IPP‑Standardattribute funktionieren wie zuvor. Active‑Directory‑basierte Druckerberechtigungen gelten weiterhin für Mac‑ und Linux‑Clients, solange die Verbindungsmethode den gewählten Authentifizierungsmechanismus unterstützt (Kerberos für AD‑authentifizierte SMB‑Verbindungen, IPP‑AUTH oder Negotiate für IPP‑basierte Verbindungen).
Endverarbeitung: Standard‑IPP verfügbar, herstellerspezifische Optionen eingeschränkt.
IPP definiert ein Standardvokabular für Endverarbeitungsoptionen: acht Standard‑Heftpositionen, zwei Sticharten (edge‑stitch und saddle‑stitch), positionale Lochung, die durch ganzzahlige Offset‑Attribute deklariert wird, zwölf Standard‑Falzarten in IPP Finishings 3.0 und die Auswahl des Ausgabefachs. Wenn die Drucker‑Firmware diese Optionen bereitstellt und der Druckserver die IPP‑Attribute korrekt weiterleitet, können Mac‑ und Linux‑Clients sie genauso anfordern wie der IPP‑Klassentreiber auf Windows. Eingeschränkt sind herstellerspezifische Steuerelemente für die Endverarbeitung, die vom Windows PSA‑Modell abhängen. Mac‑ und Linux‑Clients haben kein PSA‑Äquivalent. Sie sehen die IPP‑Standardattribute und gegebenenfalls das, was der native Mac‑Treiber des Herstellers (sofern lokal installiert) anbietet.
Erweitertes Rendering für Nicht‑Mopria‑Drucker: keine Aufgabe des Windows‑Druckservers.
Häufig wird angenommen, der Pool älterer Treiber auf dem Druckserver könne Aufträge von Nicht‑Windows‑Clients rendern und an Nicht‑Mopria‑Drucker weiterleiten. Das Windows‑Warteschlangen‑/Treibermodell unterstützt dieses Transkodierungs‑Muster nicht: Jede Warteschlange ist mit einem Treiber gekoppelt und erwartet Aufträge im Format dieses Treibers. Für Nicht‑Mopria‑Geräte in gemischten Mac/Linux/Windows‑Umgebungen bleiben praktikable Wege direkte IPP‑Verbindungen von den Clients zu einem IPP‑fähigen Drucker, ein Hardware‑Refresh, wo möglich, oder eine Cloud rendering‑Architektur, die die Transkodierung außerhalb des Windows‑Druckpfads übernimmt.
Was zu tun ist, wenn deine Umgebung von diesem Pfad abhängt
Prüfe, welche Clients sich über welchen Pfad verbinden. Mac‑ und Linux‑Clients, die sich über SMB im Vergleich zu IPP verbinden, machen mit Windows Server 2025 unterschiedliche Erfahrungen – nicht nur bei den Endverarbeitungsoptionen, sondern auch darin, ob Aufträge überhaupt abgeschlossen werden. Eine saubere Bestandsaufnahme ist der erste Schritt.
Stelle Mac‑Clients auf IPP um, bevor du WRP‑ oder WPP‑Einstellungen änderst. Das SMB‑Problem mit Windows Server 2025 ist unabhängig von WPP/WRP, wird aber wahrscheinlich während eines WPP‑Migrationsprojekts sichtbar. Wenn du Mac‑Clients zuerst auf IPP‑Warteschlangen umstellst, eliminierst du diese Variable.
Teste plattformübergreifendes Drucken auf dem WRP‑fähigen Windows‑Server‑Image, bevor du breit ausrollst. Teste insbesondere: die Übermittlung von Druckaufträgen, den Zugriff auf Warteschlangen, die im macOS‑ oder Linux‑Druckdialog angezeigten Endverarbeitungsoptionen und alle herstellerspezifischen Optionen, von denen Workflows abhängen. Der IPP‑Druckpfad sollte ohne Änderungen funktionieren; Überraschungen gibt es bei den Details der Endverarbeitung und beim SMB‑Verhalten.
Dokumentiere den Fallback‑Pfad über IPP‑Attribute für die erweiterte Endverarbeitung. Wo Mac‑ oder Linux‑Clients durch den WRP‑Übergang den Zugriff auf herstellerspezifische Endverarbeitungsoptionen verlieren, decken IPP‑Standardattribute typischerweise die entsprechenden Vorgänge ab. Die Zuordnung herstellerspezifischer Optionen zu den IPP‑Standardäquivalenten ist die Migrationsdokumentation, die sich zu erstellen lohnt.
Wie funktioniert ezeep in einer Windows Ready Print‑Umgebung?
ezeep entfernt den Windows‑Druckserver vollständig aus dem Pfad, sodass die Fragen dieses Beitrags für ezeep‑Umgebungen nicht relevant sind. Das SMB‑zu‑Server‑2025‑Problem, die WPP‑Erzwingung auf Windows‑Clients, die Verfügbarkeit von Endverarbeitungsattributen über eine server‑weitergeleitete Warteschlange – keine dieser Variablen spielt eine Rolle, wenn der Druckserver nicht vorhanden ist.
Mac‑, Linux‑ und Windows‑Clients verbinden sich über ihre jeweils plattformeigenen Wege mit ezeep. Der Cloud rendering‑Pfad liefert jedem unterstützten Betriebssystem die gleiche Erfahrung: Übermittlung von Druckaufträgen, Zugriff auf Warteschlangen, über IPP‑Standardattribute verfügbare Endverarbeitungssteuerungen und Authentifizierung über die Integration von Identitätsanbietern wie Microsoft Entra ID oder Google Workspace.
Unter Windows übernimmt die ezeep Print App die Client‑Seite und läuft bereits heute auf WPP‑fähigen Rechnern. Mac‑ und Linux‑Clients verbinden sich über ihre eigenen plattformeigenen Wege. Plattformübergreifendes Drucken funktioniert, WPP auf Windows‑Clients beeinflusst Mac oder Linux nicht, und das SMB‑Problem von Server 2025 betrifft dann andere.
Sprich mit unseren Expert:innen über deine plattformübergreifende Druckumgebung
Sende uns die Topologie deiner Umgebung: Windows Server‑Version, Warteschlangen, Clients nach Betriebssystem, Workflows mit Endverarbeitungsabhängigkeit. Wir zeigen dir, was sich für jede Client‑Klasse unter WRP und WPP ändert und wo die plattformübergreifenden Lücken liegen. Du willst selbst loslegen? Wir haben eine Checkliste für die WPP‑Bereitschaft , die du dir ansehen solltest.
