By Henning Volkmer on giugno 15, 2026
In sintesi
Sì. I client Mac e Linux possono continuare a stampare tramite un server di stampa Microsoft sia con Windows Ready Print (WRP) sia con Windows Protected Print Mode (WPP), a condizione che il server di stampa esponga le code su IPP o IPPS. macOS e Linux usano entrambi CUPS per la stampa e CUPS parla nativamente IPP. La stampa di base funziona senza modifiche lato driver. Le funzionalità di finitura avanzate sono limitate agli attributi standard IPP. Le opzioni di finitura specifiche del fornitore, che in precedenza richiedevano un driver del produttore sul client, non sono disponibili tramite questo percorso.
Come stampano oggi i client Mac e Linux su server di stampa Windows
I client non Windows che si connettono a un server di stampa Microsoft hanno sempre avuto due percorsi: Basato su SMB (montare la coda di stampa come condivisione SMB, inviare tramite SMB, con il server che gestisce l'inoltro — storicamente predominante in ambienti misti per via dell'autenticazione AD e dell'esperienza utente familiare delle stampanti di rete), e Basato su IPP (connettersi direttamente alla coda tramite IPP, mostrata in macOS in «Stampanti e scanner» come "IPP" e trattata da CUPS su Linux come una qualsiasi altra coda). Entrambi sono disponibili da anni. La domanda per WRP e WPP è cosa cambia per ciascuno dei due.
Cosa cambia e cosa non cambia con WRP e WPP
Qui è importante fare una breve distinzione. Windows Ready Print (WRP) è il nome che Microsoft ha dato alla piattaforma di stampa moderna: basata su IPP e senza driver per impostazione predefinita, con i driver di terze parti legacy ancora disponibili come fallback. Windows Protected Print Mode (WPP) è lo strato di applicazione rigorosa costruito su di essa: quando WPP è abilitato, il fallback scompare, i driver legacy vengono bloccati completamente e funzionano solo le stampanti certificate Mopria. Microsoft ha introdotto il nome WRP a maggio 2026. La piattaforma sottostante è la stessa; ciò che cambia è la presenza o meno del fallback legacy.
Per i client Mac e Linux, la distinzione tra WRP e WPP conta meno rispetto ai client Windows, perché l'applicazione delle regole avviene sul client Windows, non sul server.
WPP e WRP vengono applicati sui client Windows, non sui server Windows. Il server di stampa Windows in sé non implementa WPP o WRP nel senso di controllare i client Mac e Linux; continua a offrire ciò che ha sempre offerto (code IPP, condivisioni SMB, configurazione tramite GPO, il servizio spooler). Windows Server 2025 include WPP come funzionalità, ma l'applicazione significativa avviene sul lato client Windows della connessione.
Per un client Mac o Linux, nessuna di queste regole si applica. macOS e Linux non hanno lo spooler di stampa Windows con il modello di driver di terze parti che WPP blocca. Hanno CUPS, strutturato attorno a IPP fin dall'inizio. Quindi il lato client non è interessato né dalle impostazioni predefinite di WRP né dall'applicazione di WPP.
Ciò che cambia riguarda invece ciò che il server di stampa Windows può offrire tramite le sue code. In particolare:
- Le code IPP rimangono funzionanti. Un server di stampa Windows che ospita code IPP continua a esporle via IPP/IPPS. I client Mac e Linux si connettono, inviano processi di stampa in formato IPP e il server li inoltra alle stampanti. Questo percorso resta operativo sia con WRP sia con WPP.
- La stampa basata su SMB su Windows Server 2025 presenta un problema noto. L'accesso alle code di stampa SMB per i client macOS ha un problema di compatibilità documentato specifico per Windows Server 2025: i processi di stampa vengono accodati ma falliscono silenziosamente, indipendentemente dall'applicazione di WPP o WRP. Non si tratta di un problema di WPP/WRP, ma di un comportamento distinto di Server 2025 che Microsoft ha riconosciuto ma non ancora risolto. I client Linux che usano connessioni SMB tramite CUPS possono risentirne in modo diverso. Se il vostro ambiente instrada i client Mac tramite SMB verso un server di stampa Windows Server 2025, IPP è il percorso consigliato e funziona correttamente.
-
Il download dei driver ai client tramite SMB non si applica comunque ai client non Windows. Questo è il percorso interessato da WPP per i client Windows, ma è un meccanismo specifico di Windows. I client Mac e Linux non scaricano i driver Windows dal server di stampa nemmeno in un ambiente pre-WPP/WRP. Usano percorsi risolvibili da CUPS o driver PostScript/PCL che installano localmente.
Cosa è disponibile e cosa è limitato con WRP e WPP
Stampa di base e autenticazione: non cambiano.
L'output di pagina, colore/bianco e nero, fronte/retro, N‑up e altri attributi standard IPP funzionano come prima. Le autorizzazioni della stampante basate su Active Directory continuano ad applicarsi ai client Mac e Linux, purché il metodo di connessione supporti il meccanismo di autenticazione scelto (Kerberos per le connessioni SMB autenticate con AD, IPP‑AUTH o Negotiate per le connessioni basate su IPP).
Finitura: standard IPP disponibili, opzioni vendor‑specific limitate.
IPP definisce un vocabolario standard per le opzioni di finitura: otto posizioni di pinzatura standard, due tipi di cucitura (edge-stitch e saddle-stitch), foratura posizionale dichiarata tramite attributi con offset intero, dodici tipi di piegatura standard in IPP Finishings 3.0 e selezione del vassoio di uscita. Se il firmware della stampante espone queste opzioni e il server di stampa inoltra correttamente gli attributi IPP, i client Mac e Linux possono richiederle allo stesso modo del driver di classe IPP su Windows. Ciò che è limitato sono le opzioni di finitura specifiche del fornitore che dipendono dal modello Windows PSA. I client Mac e Linux non hanno un equivalente PSA: vedono gli attributi standard IPP e, se presente, qualsiasi opzione esposta dal driver Mac del fornitore installato localmente.
Rendering avanzato per stampanti non Mopria: non è un ruolo del server di stampa Windows.
È comune pensare che il pool di driver legacy del server di stampa possa eseguire il rendering di processi provenienti da client non Windows e inoltrarli a stampanti non Mopria. Il modello di coda/driver di stampa di Windows non supporta questo schema di transcodifica: ogni coda è associata a un solo driver e si aspetta processi nel formato di quel driver. Per dispositivi non Mopria in ambienti misti Mac/Linux/Windows, i percorsi funzionanti sono connessioni IPP dirette da ciascun client a una stampante compatibile con IPP, il rinnovo dell'hardware ove possibile, oppure un'architettura con rendering cloud che gestisca la transcodifica al di fuori del percorso di stampa Windows.
Cosa fare se il vostro ambiente dipende da questo percorso
Verificate quali client si connettono e tramite quale percorso. I client Mac e Linux che si connettono tramite SMB anziché IPP a Windows Server 2025 vivono un'esperienza diversa — non solo sulle opzioni di finitura, ma anche sulla probabilità che i processi di stampa vengano effettivamente completati. Conoscere la suddivisione è il primo passo.
Spostate i client Mac su IPP prima di toccare le impostazioni di WRP o WPP. Il problema SMB con Windows Server 2025 è indipendente da WPP/WRP, ma è probabile che emerga durante un progetto di migrazione a WPP. Portare prima i client Mac su code IPP elimina questa variabile.
Testate la stampa cross‑platform sull'immagine del server Windows abilitata per WRP prima della distribuzione estesa. Testate in particolare: l'invio dei processi di stampa, l'accesso alla coda, le opzioni di finitura esposte nel pannello di stampa di macOS o Linux e qualsiasi opzione specifica del fornitore da cui dipendono i flussi di lavoro. Il percorso IPP dovrebbe funzionare senza modifiche; le sorprese si nascondono nei dettagli della finitura e nel comportamento SMB.
Documentate il percorso di fallback basato su attributi IPP per la finitura avanzata. Dove i client Mac o Linux perdono l'accesso alle opzioni di finitura vendor‑specific nella transizione a WRP, gli attributi standard IPP coprono in genere le operazioni equivalenti. Mappare le opzioni specifiche del fornitore agli equivalenti standard IPP è la documentazione di migrazione che vale la pena produrre una volta per tutte.
Come funziona ezeep in un ambiente Windows Ready Print?
ezeep elimina completamente il server di stampa Windows dal percorso, quindi le questioni descritte in questo articolo non si applicano agli ambienti ezeep. Il problema SMB con Server 2025, l'applicazione di WPP sui client Windows, la disponibilità degli attributi di finitura tramite una coda inoltrata dal server: niente di tutto questo è una variabile quando il server di stampa non c'è.
I client Mac, Linux e Windows si connettono a ezeep attraverso i loro percorsi nativi di piattaforma. Il percorso con rendering cloud offre la stessa esperienza a ogni sistema operativo supportato: invio dei processi di stampa, accesso alle code, opzioni di finitura disponibili tramite attributi standard IPP e autenticazione tramite integrazione dell'identity provider con Microsoft Entra ID o Google Workspace.
Su Windows, l'ezeep Print App gestisce il lato client e funziona già oggi sulle macchine abilitate per WPP. I client Mac e Linux si connettono tramite i loro percorsi nativi di piattaforma. La stampa multipiattaforma funziona, WPP sui client Windows non influisce su Mac o Linux e il problema SMB con Server 2025 diventa un problema di altri.
Parlate con un esperto del vostro ambiente di stampa multipiattaforma
Inviateci la topologia del vostro ambiente: versione di Windows Server, code, client per sistema operativo, flussi di lavoro che dipendono dalle opzioni di finitura. Definiremo cosa cambia per ogni classe di client con WRP e WPP e dove si trovano le lacune nella compatibilità multipiattaforma. Volete iniziare da soli? Abbiamo una checklist di preparazione a WPP che vi consigliamo di consultare.
