By Brock McKenna on setembro 30, 2026
A impressão em um desktop virtual funciona ao fazer a ponte entre duas coisas: a sessão do usuário é executada em um servidor em um datacenter, e a impressora está em outra rede, geralmente ao lado do usuário. Algo precisa transportar o trabalho de impressão através dessa fronteira, e algo precisa saber como transformar o documento em dados que a impressora consiga entender.
Existem três maneiras de fazer isso, e cada uma resolve o problema transferindo a dificuldade para outro lugar. Entender qual delas você está usando explica a maioria das falhas de impressão que você já teve.
Na teoria, cada abordagem parece simples. Na prática, cada uma faz um trade-off diferente.
Como funciona a impressão em desktop virtual?
1. Redirecionamento de impressora no AVD, Citrix e RDS
O redirecionamento de impressora mapeia as impressoras instaladas no dispositivo local do usuário para dentro da sessão virtual. O usuário se conecta, suas impressoras locais aparecem na lista de impressoras da sessão, e os trabalhos de impressão gerados dentro da sessão retornam pelo canal de exibição remota (RDP & HTML5 para AVD, RDP para RDS e ICA para Citrix) até o cliente, que então os envia para a impressora.
É o padrão, não exige infraestrutura adicional e introduz três falhas previsíveis.
Incompatibilidade de driver. O host da sessão precisa de um driver para a impressora redirecionada, ou então usa um genérico. Se o driver não estiver na imagem, a impressora ou não aparece ou aparece com os recursos errados. É por isso que as imagens mestre acumulam drivers de impressão, e por que remover uma delas sempre quebra alguma coisa.
Nomes de impressora mudam. Em ambientes pool de várias sessões, os nomes das impressoras redirecionadas costumam receber sufixos específicos da sessão. Qualquer aplicativo configurado para imprimir em um nome de impressora fixo (ERPs de linha de negócios são o caso clássico) não consegue encontrá‑lo. O aplicativo não exibe um erro útil. Ele simplesmente não imprime.
O trabalho de impressão cruza a fronteira da sessão duas vezes. O documento entra na sessão, é renderizado lá, e o resultado renderizado volta para o cliente. Os dados de impressão renderizados são muito maiores que o documento original, portanto isso consome a largura de banda da sessão que foi orçada para pixels.
A próxima abordagem trata de outra parte do problema: o número de drivers na sessão.
2. Drivers de impressão universais em ambientes de desktop virtual
Um driver de impressão universal instala um único driver na sessão que atende todas as impressoras, renderizando os trabalhos de impressão para um formato intermediário que é então convertido no cliente ou em um servidor de impressão.
Isso resolve o inchaço das imagens. Um driver, não quarenta. Não resolve a largura de banda, porque o trabalho de impressão já renderizado ainda atravessa o limite da sessão e, dependendo da implementação, pode até piorar o consumo de banda.
Também impõe um teto de capacidades. Um driver universal expõe um subconjunto comum de funcionalidades. Seleção de bandeja, grampeamento, furação e códigos de contabilidade são recursos que deixam de funcionar — e deixam de funcionar justamente para quem mais precisa deles: a equipe financeira que imprime em papel timbrado da bandeja 3, a equipe jurídica que precisa de um papel específico, etc.
Se nem o redirecionamento nem um driver universal forem opções atraentes, existe uma alternativa mais direta: permitir que o host da sessão se comunique diretamente com a impressora.
3. Impressão IP direta de uma sessão de desktop virtual
O host da sessão imprime diretamente em uma impressora de rede via IP, sem redirecionamento e sem envolvimento do cliente.
Funciona bem em implantações em um único local, onde os hosts da sessão e as impressoras estão na mesma rede — mas torna‑se cada vez mais inviável em outros cenários. Se o seu pool de hosts do Azure Virtual Desktop estiver na Europa Ocidental e a sua impressora estiver em uma filial em Manchester, "IP direto" significa uma rota de uma sub‑rede do Azure para uma VLAN de impressora através de uma VPN site‑to‑site, e o trabalho de impressão faz um percurso pela sua rede até chegar a um dispositivo que está a poucos metros da pessoa que imprimiu.
Também significa que as impressoras precisam ser acessíveis individualmente a partir dos hosts da sessão, o que é um modelo de acesso à rede sobre o qual a maioria das equipes de segurança tem opiniões.
Os três modelos de impressão VDI em resumo
Por que a impressão falha no AVD, Citrix e RDS?
Porque os três mantêm o driver dentro da sessão, e a sessão é o pior lugar para ele.
O host da sessão é uma máquina compartilhada, agrupada e frequentemente reconstruída, que executa um print spooler que carrega código de drivers de terceiros. Cada driver na imagem é um risco de compatibilidade com a próxima atualização do Windows. Cada conflito de driver interrompe a impressão para todos os usuários naquele host, não apenas para uma pessoa. E a imagem golden, que sua equipe minimizou cuidadosamente para otimizar o desempenho de inicialização, carrega uma biblioteca de drivers de impressão que existe unicamente porque a impressora está em outro lugar.
Além disso, há a dimensão da segurança. O print spooler do lado da sessão tem as mesmas propriedades que qualquer outro spooler: ele é executado como SYSTEM, aceita RPC e carrega código de terceiros. A Microsoft atribui 9% dos problemas de segurança do Windows relatados ao MSRC à pilha de impressão. Executá-lo em um host multissessão com dezenas de usuários não é uma melhoria em relação a executá-lo em um servidor de impressão.
Isso aponta para uma pergunta diferente. Em vez de tentar tornar a impressão dentro da sessão mais gerenciável, e se a renderização saísse completamente da sessão?
O que muda quando a renderização de impressão em VDI sai da sessão?
Se o trabalho de impressão for renderizado fora da sessão, nenhum dos três modelos é necessário, pois o problema que eles existem para resolver deixa de ocorrer.
Essa é a mudança arquitetônica promovida pela ezeep.
Com ezeep, o trabalho de impressão sai da sessão como um documento. Ele passa por Cloud rendering usando uma biblioteca com mais de 6.000 drivers de fabricantes. A saída renderizada é então entregue ao ezeep Hub no local físico da impressora, por uma conexão apenas de saída, e impressa. Ele nunca retorna pelo canal RDP ou ICA.
As consequências são específicas:
- Sem drivers de impressão na imagem mestre. A imagem fica menor e deixa de ser uma superfície de compatibilidade de drivers.
- Sem tráfego de impressão no canal de sessão. A largura de banda reservada para a experiência do usuário passa a ser usada pela própria experiência.
- Sem Mapeamento de Impressoras no logon. As impressoras são atribuídas por identidade via Entra ID ou Google Workspace. O usuário vê suas impressoras com base em sua identidade.
- Sem print spooler do lado da sessão com código de driver de terceiros. O que também significa que não há nada para o modo Windows Protected Print bloquear, já que o WPP chega aos hosts de sessão do Windows Server 2025 e do Windows 11 24H2.
A plataforma ezeep suporta Azure Virtual Desktop, Windows 365, Citrix, Parallels e Omnissa Horizon. O DMK Group, a maior cooperativa de laticínios da Alemanha, o utiliza em um ambiente Azure Virtual Desktop com mais de 4.000 usuários.
E esse não é um problema novo para o ezeep.
A linhagem ThinPrint importa aqui. ezeep é construído sobre a tecnologia ThinPrint, que trabalha com impressão em ambientes Terminal Services e Citrix desde a década de 1990. A abordagem reflete anos observando essa falha específica.
A história volta ao mesmo limite com que começamos: o usuário está em um lugar, a sessão em outro e a impressora em um terceiro. A questão é simplesmente onde você decide lidar com a complexidade.
