Czy komputery macOS i Linux nadal mogą drukować przez Microsoft Print server w ramach WPP?

W skrócie

Tak. Klienci macOS i Linux mogą nadal drukować przez Microsoft Print Server zarówno w trybie Windows Ready Print (WRP), jak i Windows Protected Print Mode (WPP), o ile serwer udostępnia kolejki przez IPP lub IPPS. macOS i Linux korzystają z CUPS do drukowania, a CUPS natywnie obsługuje IPP. Podstawowe drukowanie działa bez konieczności wprowadzania zmian po stronie Print driver. Zaawansowane funkcje wykańczania są ograniczone do standardowych atrybutów IPP. Opcje wykańczania specyficzne dla producenta, które wcześniej wymagały producentowego Print driver na kliencie, nie są dostępne tą ścieżką.

Jak macOS i Linux drukują dziś na Windows Print Server

Klienci niebędący systemem Windows łączący się z Microsoft Print Server zawsze mieli do dyspozycji dwie ścieżki: Oparta na SMB (montowanie kolejki wydruku jako udział SMB, przesyłanie przez SMB, serwer obsługuje przekazywanie – historycznie dominująca metoda w środowiskach mieszanych ze względu na uwierzytelnianie AD i znajomy interfejs drukarki sieciowej), oraz Oparta na IPP (bezpośrednie połączenie z kolejką przez IPP, widoczne w macOS w sekcji „Drukarki i skanery” jako „IPP” i traktowane przez CUPS w Linux jak każda inna kolejka). Obie metody są dostępne od lat. Pytanie w kontekście WRP i WPP brzmi: co się zmienia dla każdej z nich.

Co zmieniają WRP i WPP, a czego nie

Tu istotne jest szybkie rozróżnienie. Windows Ready Print (WRP) to nazwa Microsoftu dla nowoczesnej platformy drukowania: domyślnie opartej na IPP i driverless printing, z możliwością użycia starszych Print driver jako opcji awaryjnej. Windows Protected Print Mode (WPP) to ścisła warstwa egzekwowania zasad zbudowana na jej bazie: po włączeniu WPP opcja awaryjna znika, starsze Print driver są całkowicie blokowane, a działają jedynie drukarki z certyfikatem Mopria. Microsoft wprowadził nazwę WRP w maju 2026 roku. Platforma bazowa pozostaje ta sama; różnica polega na tym, czy istnieje legacy fallback.

Dla klientów macOS i Linux rozróżnienie między WRP a WPP ma mniejsze znaczenie niż dla klientów Windows, ponieważ egzekwowanie odbywa się po stronie klienta Windows, a nie po stronie serwera.

WPP i WRP są egzekwowane na klientach Windows, nie na Windows Server. Sam Windows Print Server nie implementuje WPP ani WRP w sensie kontroli klientów macOS i Linux; dalej udostępnia to, co zawsze (kolejki IPP, udziały SMB, konfigurację opartą na GPO, usługę Print spooler). Windows Server 2025 zawiera WPP jako funkcję, ale znaczące egzekwowanie dzieje się po stronie klienta Windows.

Dla klienta macOS lub Linux żadne z tych zasad nie ma zastosowania. macOS i Linux nie mają Windowsowego modelu Print spooler z modelem Print driver, który WPP zamyka. Mają CUPS, zbudowany wokół IPP od początku. Strona klienta pozostaje więc nienaruszona ani przez domyślne ustawienia WRP, ani przez egzekwowanie WPP.

Zmienia się to, co Windows Print Server może zaoferować poprzez swoje kolejki. W szczególności:

• Kolejki IPP pozostają funkcjonalne. Windows Print Server hostujący kolejki IPP nadal udostępnia je przez IPP/IPPS. Klienci macOS i Linux łączą się, wysyłają zadania drukowania w formacie IPP, a serwer przekazuje je do drukarek. Ta ścieżka działa zarówno w trybie WRP, jak i WPP.
• Drukowanie oparte na SMB do Windows Server 2025 ma znany problem. Dostęp do kolejek wydruku przez SMB dla klientów macOS ma udokumentowany problem ze zgodnością, specyficzny dla Windows Server 2025 – zadania trafiają do kolejki i kończą się niepowodzeniem bez komunikatu, niezależnie od egzekwowania WPP czy WRP. To nie jest problem WPP/WRP; to odrębne zachowanie Server 2025, które Microsoft potwierdził, ale jeszcze nie rozwiązał. Klienci Linux używający połączeń SMB za pośrednictwem CUPS mogą być dotknięci w inny sposób. Jeśli Wasze środowisko kieruje klientów macOS przez SMB do Windows Server 2025, zalecaną i bezproblemową ścieżką jest IPP.

• Pobieranie Print driver do klientów przez SMB i tak nie dotyczy klientów innych niż Windows. To jest ścieżka dotknięta przez WPP dla klientów Windows, ale jest to mechanizm specyficzny dla Windows. Klienci macOS i Linux nie pobierają Windows Print driver z Print Server nawet w środowisku sprzed WPP/WRP. Używają ścieżek rozpoznawanych przez CUPS albo lokalnie instalowanych sterowników PostScript/PCL.

Co jest dostępne, a co ograniczone w przypadku WRP i WPP

Podstawowe drukowanie i uwierzytelnianie: bez zmian.

Wyjście strony, kolor/czarno-biały, dupleks, N-up i inne standardowe atrybuty IPP działają jak wcześniej. Uprawnienia do drukarek oparte na Active Directory nadal obowiązują wobec klientów macOS i Linux, o ile metoda połączenia obsługuje wybrany mechanizm uwierzytelniania (Kerberos dla uwierzytelnianych przez AD połączeń SMB, IPP-AUTH lub Negotiate dla połączeń opartych na IPP).

Wykańczanie: dostępne standardowe opcje IPP, ograniczone opcje producenta.

IPP definiuje standardowy słownik opcji wykańczania: osiem standardowych pozycji zszywania, dwa typy stitch (edge-stitch i saddle-stitch), pozycjonowanie dziurkowania deklarowane przez atrybuty z przesunięciem liczbowym, dwanaście standardowych typów składania w IPP Finishings 3.0 oraz wybór tacy wyjściowej. Jeśli firmware drukarki udostępnia te opcje, a serwer poprawnie przekazuje atrybuty IPP, klienci macOS i Linux mogą ich żądać tak samo, jak robi to sterownik klasy IPP w Windows. Ograniczeniem są opcje wykańczania specyficzne dla producenta zależne od modelu Windows PSA. Klienci macOS i Linux nie mają odpowiednika PSA — widzą tylko to, co opisują standardowe atrybuty IPP, plus to, co udostępnia producentowy sterownik dla macOS (jeśli jest zainstalowany lokalnie).

Zaawansowane renderowanie dla drukarek bez certyfikatu Mopria: to nie jest rola Windows Print Server.

Częstym założeniem jest, że pula legacy Print driver na serwerze wydruku może renderować zadania od klientów nie-Windows i przekazać je do drukarek bez certyfikatu Mopria. Model kolejki/Print driver w Windows nie obsługuje takiego wzorca transkodowania: każda kolejka powiązana jest z jednym Print driver i oczekuje zadań w formacie tego Print driver. Dla urządzeń bez Mopria w mieszanych środowiskach macOS/Linux/Windows działające ścieżki to: bezpośrednie połączenia IPP z każdego klienta do drukarki obsługującej IPP, wymiana sprzętu tam, gdzie możliwe, lub architektura Cloud rendering, która obsługuje transkodowanie poza ścieżką drukowania Windows.

Co zrobić, jeśli Wasze środowisko zależy od tej ścieżki

Audyt: którzy klienci łączą się którą ścieżką. Klienci macOS i Linux łączący się przez SMB w porównaniu z IPP doświadczają innego zachowania wobec Windows Server 2025 – nie tylko w zakresie opcji wykańczania, ale też tego, czy zadania w ogóle są realizowane. Poznanie tego rozkładu to pierwszy krok.

Przenieście klientów macOS na IPP przed zmianą ustawień WRP lub WPP. Problem SMB w Windows Server 2025 jest niezależny od WPP/WRP, ale prawdopodobnie ujawni się podczas projektu migracji do WPP. Przeniesienie klientów macOS na kolejki IPP najpierw eliminuje tę zmienną.

Przetestujcie drukowanie wieloplatformowe na obrazie serwera Windows z włączonym WRP przed szerokim wdrożeniem. Konkretnie przetestujcie: przesyłanie zadań drukowania, dostęp do kolejki, opcje wykańczania widoczne w oknie dialogowym drukowania w macOS lub Linux oraz wszelkie opcje producenta, od których zależą przepływy pracy. Ścieżka IPP powinna działać bez zmian; niespodzianki zwykle kryją się w szczegółach wykańczania i w zachowaniu SMB.

Udokumentujcie awaryjną ścieżkę opartą na atrybutach IPP dla zaawansowanego wykańczania. Gdy klienci macOS lub Linux tracą dostęp do opcji wykańczania producenta w wyniku przejścia na WRP, standardowe atrybuty IPP zwykle pokrywają równoważne operacje. Zmapowanie opcji producenta na standardowe odpowiedniki IPP to dokumentacja migracyjna, którą warto przygotować raz.

Jak ezeep działa w środowisku Windows Ready Print?

ezeep usuwa Windows Print Server całkowicie ze ścieżki drukowania, więc pytania z tego wpisu nie dotyczą środowisk ezeep. Problem SMB do Server 2025, egzekwowanie WPP na klientach Windows, dostępność atrybutów wykańczania przez kolejkę przekazywaną przez serwer — żadna z tych zmiennych nie ma znaczenia, gdy nie ma serwera wydruku.

Klienci macOS, Linux i Windows łączą się z ezeep przez natywne dla platformy ścieżki. Cloud rendering dostarcza takie samo doświadczenie na każdym obsługiwanym systemie: przesyłanie zadań drukowania, dostęp do kolejki, opcje wykańczania dostępne przez standardowe atrybuty IPP oraz uwierzytelnianie przez integrację z dostawcą tożsamości jak Microsoft Entra ID lub Google Workspace.

W Windows stronę klienta obsługuje ezeep Print App i działa dziś na maszynach z włączonym WPP. Klienci macOS i Linux łączą się przez swoje natywne ścieżki. Drukowanie wieloplatformowe działa, WPP na klientach Windows nie wpływa na macOS ani Linux, a problem SMB w Server 2025 staje się czyimś innym problemem.

Skontaktujcie się z ekspertem w sprawie Waszego wieloplatformowego środowiska druku

Prześlijcie nam topologię Waszego środowiska: wersję Windows Server, kolejki, klientów według systemu operacyjnego, przepływy zależne od wykańczania. Określimy, co zmieni się dla każdej klasy klientów w ramach WRP i WPP oraz gdzie występują luki w obsłudze wieloplatformowej. Chcecie zacząć sami? Mamy dla Was listę kontrolną gotowości na WPP , którą warto sprawdzić.

Pracujecie w środowisku z różnymi systemami operacyjnymi?

Określmy ścieżkę druku dla całego środowiska.

Skontaktujcie się z ekspertem