By Brock McKenna on września 30, 2026
Drukowanie na pulpicie wirtualnym polega na przekroczeniu pewnej granicy: sesja użytkownika działa na serwerze w centrum danych, a drukarka jest podłączona do sieci gdzie indziej, zwykle obok użytkownika. Coś musi przenieść zadanie drukowania przez tę granicę i musi też umieć przekształcić dokument w dane zrozumiałe dla drukarki.
Istnieją trzy sposoby rozwiązania tego problemu, a każdy z nich przerzuca trudność w inne miejsce. Zrozumienie, którego podejścia używacie, wyjaśnia większość problemów z drukowaniem, które napotykaliście.
Na papierze każde podejście wygląda prosto. W praktyce każde z nich wiąże się jednak z innym kompromisem.
Jak działa drukowanie na pulpicie wirtualnym?
1. Przekierowanie drukarek w AVD, Citrix i RDS
Przekierowanie drukarek polega na mapowaniu drukarek zainstalowanych na lokalnym urządzeniu użytkownika do sesji wirtualnej. Po nawiązaniu połączenia lokalne drukarki użytkownika pojawiają się na liście drukarek w sesji, a zadania drukowania zainicjowane w sesji są przesyłane z powrotem przez kanał zdalnego wyświetlania (RDP i HTML5 dla AVD, RDP dla RDS oraz ICA dla Citrix) do klienta, który następnie wysyła je do drukarki.
To rozwiązanie domyślne — nie wymaga dodatkowej infrastruktury — i generuje trzy przewidywalne rodzaje awarii.
Niezgodność sterowników. Host sesji potrzebuje sterownika dla przekierowanej drukarki; w przeciwnym razie użyje sterownika uniwersalnego. Jeśli sterownik nie znajduje się w obrazie, drukarka albo w ogóle się nie pojawi, albo pojawi się z nieprawidłowymi możliwościami. Dlatego obrazy wzorcowe gromadzą sterowniki drukarek, a usunięcie któregoś z nich zwykle powoduje problemy.
Nazwy drukarek się zmieniają. W środowiskach z pulą wielu sesji nazwy przekierowanych drukarek często zyskują sufiksy specyficzne dla danej sesji. Aplikacja skonfigurowana do drukowania na drukarce o stałej nazwie (klasyczny przykład to system ERP) nie odnajdzie takiej drukarki. Aplikacja nie zwraca użytecznego komunikatu o błędzie — po prostu nie drukuje.
Zadanie dwukrotnie przekracza granicę sesji. Dokument trafia do sesji, jest tam renderowany, a wyrenderowane dane wydruku wracają do klienta. Wyrenderowane dane są zwykle znacznie większe niż dokument źródłowy, więc zużywają przepustowość sesji, która była przeznaczona na przesyłanie pikseli.
Następne podejście rozwiązuje inny aspekt tego problemu: liczbę sterowników obecnych w sesji.
2. Uniwersalne sterowniki wydruku w środowiskach wirtualnych pulpitów
Uniwersalny sterownik wydruku instaluje w sesji jeden sterownik, który obsługuje wszystkie drukarki, renderując zadania drukowania do formatu pośredniego, który jest następnie konwertowany na urządzeniu klienckim lub na print server.
Rozwiązuje to problem nadmiernego rozmiaru obrazu. Jeden sterownik zamiast czterdziestu. Nie rozwiązuje jednak problemu z przepustowością — wyrenderowane zadanie nadal przekracza granicę sesji i, w zależności od implementacji, może nawet zwiększyć wykorzystanie pasma.
Wprowadza też ograniczenie możliwości. Uniwersalny sterownik udostępnia wspólny podzbiór funkcji. Wybór tacy, zszywanie, dziurkowanie i kody rozliczeniowe to funkcje, które przestają działać — i to dla użytkowników, którym zależy na nich najbardziej: działu finansów drukującego na papierze firmowym z tacy nr 3, działu prawnego potrzebującego konkretnego papieru itd.
Jeśli ani przekierowanie, ani uniwersalny sterownik nie są atrakcyjną opcją, pozostaje bardziej bezpośrednie rozwiązanie: pozwolić hostowi sesji komunikować się bezpośrednio z drukarką.
3. Bezpośrednie drukowanie przez IP z sesji wirtualnego pulpitu
Host sesji drukuje bezpośrednio na drukarce sieciowej przez IP — bez przekierowywania i bez udziału klienta.
Proste i czyste we wdrożeniu w jednej lokalizacji, gdzie hosty sesji i drukarki są w tej samej sieci. W innych przypadkach staje się to coraz mniej prawdopodobne. Jeśli pula hostów AVD działa w regionie West Europe, a drukarka stoi w oddziale w Manchesterze, „bezpośrednie IP” oznacza trasę z podsieci Azure do VLAN‑u drukarek przez site‑to‑site VPN, a zadanie drukowania pokonuje długą drogę przez waszą sieć, żeby dotrzeć do urządzenia znajdującego się około 9 metrów od osoby, która je wysłała.
To też oznacza, że drukarki muszą być indywidualnie osiągalne z hostów sesji — model dostępu do sieci, który wywołuje zastrzeżenia większości zespołów ds. bezpieczeństwa.
Trzy modele drukowania w VDI w pigułce
Dlaczego drukowanie w środowiskach AVD, Citrix i RDS sprawia problemy?
Ponieważ we wszystkich trzech przypadkach sterownik pozostaje w sesji — a to najgorsze możliwe miejsce.
Host sesji to współdzielona, często przebudowywana maszyna z puli zasobów, na której działa bufor wydruku ładujący kod sterowników firm trzecich. Każdy sterownik w obrazie stanowi ryzyko niekompatybilności z kolejną aktualizacją systemu Windows. Każdy konflikt sterowników przerywa drukowanie wszystkim użytkownikom na danym hoście, a nie pojedynczej osobie. Obraz wzorcowy, który wasz zespół starannie zminimalizował, by przyspieszyć uruchamianie, nadal zawiera bibliotekę sterowników druku istniejącą wyłącznie dlatego, że drukarka jest gdzie indziej.
Jest też wymiar bezpieczeństwa. Bufor wydruku po stronie sesji ma te same właściwości co każdy inny bufor: działa z uprawnieniami SYSTEM, akceptuje wywołania RPC i ładuje kod firm trzecich. Microsoft przypisuje 9% zgłoszonych do MSRC problemów z bezpieczeństwem systemu Windows stosowi drukowania. Uruchamianie go na hoście obsługującym wiele sesji z dziesiątkami użytkowników nie poprawia sytuacji w porównaniu z uruchamianiem go na print server.
Pojawia się więc inne pytanie. Zamiast próbować usprawnić drukowanie w obrębie sesji — co gdyby renderowanie odbywało się całkowicie poza nią?
Co się zmienia, gdy renderowanie wydruku VDI odbywa się poza sesją?
Jeśli zadanie drukowania jest renderowane poza sesją, żaden z trzech modeli nie jest potrzebny — problem, który miały rozwiązać, po prostu nie występuje.
Na tym polega zmiana architektury, którą wprowadza ezeep.
Dzięki ezeep zadanie opuszcza sesję jako dokument. Jest ono wykonywane jako Cloud rendering, w oparciu o bibliotekę ponad 6 000 sterowników producentów. Wynik renderowania jest następnie dostarczany do ezeep Hub w fizycznej lokalizacji drukarki przez połączenie wyłącznie wychodzące i tam drukowany. Nigdy nie wraca przez kanał RDP ani ICA.
Konsekwencje są następujące:
- Brak sterowników drukarek w obrazie wzorcowym. Obraz jest mniejszy i przestaje być miejscem problemów ze zgodnością sterowników.
- Brak ruchu drukowania w kanale sesji. Przepustowość zarezerwowana dla doświadczenia użytkownika jest faktycznie wykorzystywana na jego obsługę.
- Brak mapowania drukarek przy logowaniu. Drukarki są przypisywane według tożsamości przez Entra ID lub Google Workspace. Użytkownik widzi swoje drukarki dzięki temu, kim jest.
- Brak bufora wydruku po stronie sesji, zawierającego kod sterowników firm trzecich. To także oznacza, że tryb Windows Protected Print nie będzie miał czego blokować, gdy WPP pojawi się na hostach sesji Windows Server 2025 i Windows 11 24H2.
ezeep obsługuje Azure Virtual Desktop, Windows 365, Citrix, Parallels i Omnissa Horizon. DMK Group, największa niemiecka spółdzielnia mleczarska, korzysta z ezeep w środowisku Azure Virtual Desktop dla ponad 4 000 użytkowników.
To nie jest nowy problem, z którym ezeep zetknął się dopiero niedawno.
Dziedzictwo ThinPrint ma tu znaczenie. ezeep bazuje na technologii ThinPrint, która od lat 90. zajmuje się drukowaniem w środowiskach Terminal Services i Citrix. Podejście to jest efektem wieloletnich obserwacji tego, jak ten konkretny układ zawodzi.
Wszystko sprowadza się do tej samej granicy, od której zaczęliśmy: użytkownik jest w jednym miejscu, sesja w drugim, a drukarka jeszcze w innym. Pytanie brzmi, gdzie zdecydujecie się obsłużyć tę złożoność.
