By Henning Volkmer on Junho 15, 2026
TL;DR
Sim. Clientes macOS e Linux podem continuar a imprimir através de um Microsoft Print Server tanto no Windows Ready Print (WRP) quanto no Windows Protected Print Mode (WPP), desde que o servidor de impressão exponha as filas por IPP ou IPPS. macOS e Linux usam o CUPS para impressão, e o CUPS fala IPP nativamente. A impressão básica funciona sem alterações no lado do driver. Recursos de acabamento avançados ficam limitados aos atributos padrão do IPP. Controles de acabamento específicos do fornecedor, que antes exigiam um driver do fabricante no cliente, não estão disponíveis por essa via.
Como macOS e Linux imprimem em servidores de impressão Windows hoje
Clientes não-Windows que se conectam a um Microsoft Print Server sempre tiveram dois caminhos: Baseado em SMB (montar a fila de impressão como um compartilhamento SMB, enviar via SMB, e o servidor faz o encaminhamento — historicamente dominante em ambientes mistos por sua autenticação AD e pela experiência familiar com impressoras de rede), e Baseado em IPP (conectar-se diretamente à fila por IPP, exibida em Impressoras e Scanners do macOS como "IPP" e tratada pelo CUPS do Linux como qualquer outra fila). Ambos estão disponíveis há anos. A questão com WRP e WPP é o que muda em cada um.
O que WRP e WPP mudam, e o que não mudam
Uma distinção rápida importa aqui. Windows Ready Print (WRP) é o nome da Microsoft para a plataforma de impressão moderna: baseada em IPP e sem driver por padrão, com drivers legados de terceiros ainda disponíveis como alternativa. Windows Protected Print Mode (WPP) é a camada de aplicação rigorosa construída sobre ela: quando o WPP é ativado, a alternativa desaparece, os drivers legados são totalmente bloqueados e só impressoras certificadas pela Mopria funcionam. A Microsoft introduziu o nome WRP em maio de 2026. A plataforma subjacente é a mesma; o que difere é se a alternativa legada existe.
Para macOS e Linux, a distinção entre WRP e WPP importa menos do que para clientes Windows, porque a aplicação acontece no lado do cliente Windows, não no lado do servidor.
WPP e WRP são aplicados nos clientes Windows, não nos Windows Servers. O próprio servidor de impressão do Windows não implementa WPP ou WRP no sentido de controlar clientes macOS e Linux; o que ele implementa é o que sempre implementou (filas IPP, compartilhamentos SMB, configuração por GPO, o serviço de spooler). O Windows Server 2025 inclui o WPP como uma funcionalidade, mas a aplicação relevante ocorre no lado do cliente Windows da conexão.
Para um cliente macOS ou Linux, nada dessa aplicação se aplica. macOS e Linux não têm um print spooler do Windows com o modelo de driver de terceiros que o WPP encerra. Eles têm o CUPS, que foi estruturado em torno do IPP desde o início. Portanto, o lado do cliente não é afetado nem pelos padrões WRP nem pela aplicação do WPP.
O que muda é o que o servidor de impressão do Windows pode oferecer por meio de suas filas. Especificamente:
- As filas IPP continuam funcionais. Um servidor de impressão Windows que hospeda filas IPP segue expondo-as por IPP/IPPS. Clientes macOS e Linux se conectam, enviam trabalhos de impressão no formato IPP e o servidor os encaminha para as impressoras. Esse caminho permanece funcional tanto com WRP quanto com WPP.
- A impressão baseada em SMB para o Windows Server 2025 tem um problema conhecido. O acesso à fila de impressão via SMB para clientes macOS tem um problema de compatibilidade documentado especificamente com o Windows Server 2025 — os trabalhos entram na fila e falham silenciosamente, independentemente da aplicação do WPP ou WRP. Isso não é um problema do WPP/WRP; é um comportamento separado do Server 2025 que a Microsoft reconheceu, mas ainda não resolveu. Clientes Linux usando conexões SMB via CUPS podem ser afetados de forma diferente. Se seu ambiente direciona clientes macOS por SMB para um servidor de impressão Windows Server 2025, o IPP é o caminho recomendado e funciona sem problemas.
-
O download de drivers para clientes via SMB não se aplica a clientes não-Windows de qualquer forma. Esse é o caminho afetado pelo WPP para clientes Windows, mas é um mecanismo específico do Windows. Clientes macOS e Linux não puxam drivers do Windows do servidor de impressão, mesmo em um ambiente pré-WPP/WRP. Eles usam caminhos que o CUPS resolve ou drivers PostScript/PCL que instalam localmente.
O que está disponível e o que é limitado com WRP e WPP
Impressão básica e autenticação: não afetadas.
Saída de página, colorido/preto e branco, duplex, N-up e outros atributos padrão do IPP funcionam como antes. Permissões de impressora baseadas no Active Directory continuam a se aplicar a clientes macOS e Linux, desde que o método de conexão suporte o mecanismo de autenticação escolhido (Kerberos para conexões SMB autenticadas por AD, IPP-AUTH ou Negotiate para conexões baseadas em IPP).
Acabamento: padrão IPP disponível; controles específicos do fornecedor são limitados.
O IPP define um vocabulário padrão para opções de acabamento: oito posições de grampeamento padrão, dois tipos de costura (costura na borda e costura a cavalo), perfuração posicional declarada por atributos de deslocamento inteiro, doze tipos de dobra padrão no IPP Finishings 3.0 e seleção da bandeja de saída. Se o firmware da impressora expuser esses atributos e o servidor de impressão encaminhar corretamente os atributos IPP, clientes macOS e Linux podem solicitá-los da mesma forma que o driver de classe IPP faz no Windows. O que fica limitado são os controles de acabamento específicos do fornecedor que dependem do modelo PSA do Windows. Clientes macOS e Linux não têm um equivalente ao PSA. Eles veem os atributos padrão do IPP descritos e, além disso, o que o driver do fornecedor para macOS (se instalado localmente) expuser.
Renderização avançada para impressoras não-Mopria: não é função do servidor de impressão Windows.
Uma suposição comum é que o conjunto de drivers legados do servidor de impressão pode renderizar trabalhos de clientes não-Windows e encaminhá-los para impressoras não-Mopria. O modelo de fila/driver do Windows não suporta esse padrão de transcodificação: cada fila pareia com um driver e espera trabalhos no formato desse driver. Para dispositivos não-Mopria em ambientes mistos macOS/Linux/Windows, as opções práticas são conexões IPP diretas de cada cliente para uma impressora compatível com IPP, atualização de hardware quando possível, ou uma arquitetura com cloud rendering que realiza a transcodificação fora do caminho de impressão do Windows.
O que fazer se seu ambiente depende desse caminho
Audite quais clientes se conectam por qual caminho. Clientes macOS e Linux que se conectam por SMB versus IPP têm experiências diferentes com o Windows Server 2025 — não só em relação aos controles de acabamento, mas também quanto à conclusão dos trabalhos. Conhecer essa divisão é o primeiro passo.
Mova os clientes macOS para IPP antes de mexer nas configurações de WRP ou WPP. O problema do SMB com o Windows Server 2025 é independente do WPP/WRP, mas tende a aparecer durante projetos de migração para o WPP. Colocar os clientes macOS em filas IPP primeiro elimina essa variável.
Teste a impressão multiplataforma na imagem do servidor Windows com WRP ativado antes da implantação em larga escala. Teste especificamente: envio de trabalho de impressão, acesso à fila, opções de acabamento expostas na caixa de diálogo de impressão do macOS ou Linux e quaisquer opções específicas do fornecedor das quais os fluxos de trabalho dependem. O caminho de impressão IPP deve funcionar sem alterações; os detalhes de acabamento e o comportamento SMB são onde surgem surpresas.
Documente o caminho de fallback por atributos IPP para acabamento avançado. Onde clientes macOS ou Linux perdem acesso a controles de acabamento específicos do fornecedor durante a transição para WRP, os atributos padrão do IPP geralmente cobrem as operações equivalentes. Mapear as opções específicas do fornecedor para os equivalentes padrão do IPP é a documentação de migração que vale a pena produzir.
Como o ezeep funciona em um ambiente Windows Ready Print?
ezeep remove completamente o servidor de impressão Windows do caminho, o que significa que as questões deste post não se aplicam a ambientes ezeep. O problema SMB do Server 2025, a aplicação do WPP em clientes Windows, a disponibilidade de atributos de acabamento por meio de uma fila encaminhada pelo servidor — nenhuma dessas variáveis existe quando o servidor de impressão não está lá.
Clientes macOS, Linux e Windows se conectam ao ezeep por seus próprios caminhos nativos de plataforma. O caminho com cloud rendering entrega a mesma experiência para todos os sistemas operacionais suportados: envio de trabalho de impressão, acesso à fila, controles de acabamento disponíveis via atributos padrão IPP e autenticação por integração com provedores de identidade como Microsoft Entra ID ou Google Workspace.
No Windows, o ezeep Print App cuida do lado cliente e já roda em máquinas com WPP ativado. Clientes macOS e Linux se conectam por seus próprios caminhos nativos de plataforma. A impressão multiplataforma funciona, o WPP em clientes Windows não afeta macOS ou Linux, e o problema SMB do Server 2025 é problema de outra parte.
Fale com um especialista sobre seu ambiente de impressão multiplataforma
Envie-nos a topologia do seu ambiente: versão do Windows Server, filas, clientes por sistema operacional, fluxos de trabalho dependentes de acabamento. Vamos mapear o que muda para cada classe de cliente sob o WRP e WPP e onde estão as lacunas multiplataforma. Quer começar por conta própria? Temos um checklist de prontidão para o WPP que você vai querer conferir.
