Drucken in AVD, Citrix und RDS: Wie es funktioniert und warum es scheitert
By Brock McKenna on September 30, 2026

Drucken in einem virtuellen Desktop überbrückt eine Lücke: Die Sitzung von Nutzenden läuft auf einem Server in einem Rechenzentrum, während der Drucker in einem anderen Teil des Netzwerks steht — meist direkt neben den Nutzenden. Etwas muss den Druckauftrag über diese Grenze transportieren und das Dokument in Daten umwandeln, die der Drucker versteht.
Es gibt drei Möglichkeiten, und jede verlagert die Schwierigkeit an eine andere Stelle. Wenn du weißt, welchen Ansatz du einsetzt, erklärt das die meisten Druckfehler, die du bisher hattest.
Auf dem Papier klingt jeder Ansatz unkompliziert. In der Praxis macht jeder einen anderen Kompromiss.
Wie funktioniert das Drucken auf virtuellen Desktops?
1. Printer Redirection in AVD, Citrix und RDS
Die Printer Redirection bildet die auf dem lokalen Gerät installierten Drucker in der virtuellen Sitzung ab. Nutzende verbinden sich, ihre lokalen Drucker erscheinen in der Druckerliste der Sitzung, und Druckaufträge aus der Sitzung werden über den Remote-Display-Kanal (RDP & HTML5 für AVD, RDP für RDS und ICA für Citrix) zurück an den Client geleitet, der sie an den Drucker sendet.
Das ist die Standardeinstellung: Sie erfordert keine zusätzliche Infrastruktur, bringt aber drei vorhersehbare Fehler mit sich.
Treiberkonflikt. Der Sitzungs-Host benötigt einen Treiber für den umgeleiteten Drucker, andernfalls nutzt er einen generischen. Ist der Treiber nicht im Image enthalten, erscheint der Drucker entweder gar nicht oder mit falschen Funktionen. Deshalb sammeln sich in Golden Images Druckertreiber an, und das Entfernen eines Treibers führt fast immer zu Problemen.
Druckernamen ändern sich. In gepoolten Multi-Session-Umgebungen erhalten umgeleitete Druckernamen häufig sitzungsspezifische Suffixe. Anwendungen, die auf einen festen Druckernamen konfiguriert sind (branchenspezifische ERPs sind ein klassisches Beispiel), finden diesen Namen nicht. Die Anwendung liefert keine hilfreiche Fehlermeldung – sie druckt einfach nicht.
Der Druckauftrag durchläuft die Sitzungsgrenze zweimal. Das Dokument gelangt in die Sitzung, wird dort gerendert, und die gerenderte Ausgabe wird an den Client zurückgesendet. Gerenderte Druckdaten sind deutlich größer als das Quelldokument, sodass dadurch Sitzungsbandbreite verbraucht wird, die eigentlich für Pixel vorgesehen war.
Der nächste Ansatz geht einen anderen Teil des Problems an: die Anzahl der Treiber in der Sitzung.
2. Universelle Druckertreiber in virtuellen Desktop-Umgebungen
Ein universeller Druckertreiber installiert einen einzigen Treiber in der Sitzung, der alle Drucker abdeckt. Er rendert Druckaufträge in ein Zwischenformat, das dann am Client oder auf einem Druckserver konvertiert wird.
Das beseitigt das Image-Aufblähen. Ein Treiber, nicht vierzig. Das Bandbreitenproblem löst es jedoch nicht, denn der gerenderte Druckauftrag überschreitet weiterhin die Sitzungsgrenze und kann je nach Implementierung die Bandbreite sogar stärker belasten.
Zudem gibt es eine Grenze bei den Möglichkeiten: Ein universeller Treiber bietet nur eine gemeinsame Untermenge an Features. Papierfachwahl, Heften, Lochen und Abrechnungscodes funktionieren dann nicht mehr — und zwar gerade für diejenigen Nutzenden, die darauf angewiesen sind: etwa das Finanzteam, das auf Briefpapier aus Fach 3 druckt, oder die Rechtsabteilung, die bestimmtes Papier benötigt.
Wenn weder Weiterleitung noch ein universeller Treiber eine attraktive Option sind, gibt es eine direktere Möglichkeit: den Session-Host direkt mit dem Drucker kommunizieren zu lassen.
3. Direktes IP‑Drucken aus einer virtuellen Desktop‑Sitzung
Der Session-Host druckt über IP direkt auf einen Netzwerkdrucker, ohne Weiterleitung und ohne Beteiligung des Clients.

Sauber in einer Ein-Standort-Bereitstellung, bei der sich Session-Hosts und Drucker im selben Netzwerk befinden. Anderswo wird das zunehmend unwahrscheinlich. Wenn dein Azure Virtual Desktop‑Hostpool in Westeuropa läuft und dein Drucker in einer Niederlassung in Manchester steht, bedeutet „direktes IP“, dass eine Route von einem Azure‑Subnetz zu einem Drucker‑VLAN über ein Site‑to‑Site‑VPN nötig ist — und der Druckauftrag eine malerische Reise durch dein Netzwerk macht, um ein Gerät zu erreichen, das nur etwa neun Meter von der Person entfernt ist, die den Druck ausgelöst hat.
Es bedeutet außerdem, dass Drucker einzeln von den Session-Hosts erreichbar sein müssen — ein Netzwerkzugriffsmodell, zu dem die meisten Sicherheitsteams eine klare Meinung haben.
Die drei VDI‑Druckmodelle im Überblick
Warum gibt es in AVD, Citrix und RDS Probleme beim Drucken?
Weil alle drei den Treiber in der Sitzung belassen — und die Sitzung ist der denkbar schlechteste Ort dafür.
Der Sitzungs-Host ist eine gemeinsam genutzte, gepoolte und häufig neu erstellte Maschine, auf der ein Spooler läuft, der Code von Treibern von Drittanbietern lädt. Jeder Treiber im Image ist ein Kompatibilitätsrisiko für das nächste Windows‑Update. Jeder Treiberkonflikt legt das Drucken für alle Nutzer:innen auf diesem Host lahm, nicht nur für eine einzelne Person. Und das Golden Image, das dein Team für schnelle Startzeiten bewusst schlank gehalten hat, trägt dennoch eine Druckertreiberbibliothek mit sich, die einzig deshalb vorhanden ist, weil der Drucker woanders steht.
Hinzu kommt die Sicherheitsdimension. Der Spooler in der Sitzung hat die gleichen Eigenschaften wie jeder andere Spooler: Er läuft als SYSTEM, akzeptiert RPC und lädt Code von Drittanbietern. Microsoft schreibt 9 % der an das MSRC gemeldeten Windows‑Sicherheitsprobleme dem Druck‑Stack zu. Das auf einem Host mit mehreren Sitzungen und Dutzenden von Nutzer:innen zu betreiben, ist keine Verbesserung gegenüber dem Betrieb auf einem Druckserver.
Das wirft eine andere Frage auf: Anstatt zu versuchen, das Drucken innerhalb der Sitzung besser handhabbar zu machen – was, wenn das Rendering die Sitzung vollständig verlässt?
Was ändert sich, wenn das VDI-Print-Rendering außerhalb der Sitzung erfolgt?
Wenn der Auftrag außerhalb der Sitzung gerendert wird, wird keines der drei Modelle benötigt, da das Problem, das sie lösen sollen, gar nicht erst auftritt.
Genau diesen architektonischen Wandel vollzieht ezeep.
Mit ezeep verlässt der Druckauftrag die Sitzung als Dokument. Er wird mittels Cloud rendering unter Verwendung einer Bibliothek von über 6.000 Herstellertreibern gerendert. Die gerenderte Ausgabe wird dann über eine ausschließlich ausgehende Verbindung an den ezeep Hub am physischen Standort des Druckers geliefert und dort gedruckt. Sie reist nie zurück über den RDP- oder ICA-Kanal.
Das hat konkrete Folgen:
- Keine Druckertreiber im Golden Image. Das Image wird kleiner und bietet keine Angriffsfläche mehr für Treiberkompatibilität.
- Kein Druckdatenverkehr auf dem Sitzungskanal. Die für das Nutzererlebnis vorgesehene Bandbreite steht dem Nutzererlebnis zur Verfügung.
- Keine Druckerzuordnung bei der Anmeldung. Drucker werden per Identität über Entra ID oder Google Workspace zugewiesen. Nutzende sehen ihre Drucker, weil diese an ihre Identität gebunden sind.
- Kein sitzungsseitiger Print spooler, der Treiber-Code von Drittanbietern ausführt. Das bedeutet auch, dass es für den Windows Protected Print-Modus nichts zu blockieren gibt, da WPP auf Sitzungshosts von Windows Server 2025 und Windows 11 24H2 eintrifft.
ezeep unterstützt Azure Virtual Desktop, Windows 365, Citrix, Parallels und Omnissa Horizon. Die DMK Group, Deutschlands größte Molkereigenossenschaft, betreibt ezeep in einer Azure Virtual Desktop-Umgebung mit mehr als 4.000 Nutzenden.
Und das ist kein neues Problem, auf das ezeep erst kürzlich gestoßen ist.
Die ThinPrint-Herkunft ist hier entscheidend. ezeep basiert auf ThinPrint-Technologie, die seit den 1990er-Jahren in Terminal-Services- und Citrix-Umgebungen beim Drucken eingesetzt wird. Der Ansatz ist das Ergebnis jahrzehntelanger Beobachtung, wie genau dieses Szenario scheitert.
Die Geschichte führt zurück zu derselben Grenze, mit der wir angefangen haben: Nutzende befinden sich an einem Ort, die Sitzung an einem anderen und der Drucker wieder an einem dritten. Die Frage ist einfach: An welcher Stelle willst du diese Komplexität bewältigen?
Häufig gestellte Fragen
Wie funktioniert das Drucken in einem virtuellen Desktop?
Die Sitzung von Nutzenden läuft auf einem Remote-Host, während sich der Drucker in einem anderen Netzwerk befindet, sodass der Druckauftrag diese Grenze überqueren muss. Es gibt drei Modelle: Druckerumleitung (lokale Drucker werden in die Sitzung eingebunden), ein universeller Druckertreiber (ein Treiber in der Sitzung bedient alle Drucker) und sitzungsbasiertes direktes IP‑Drucken (der Host druckt direkt auf einen Netzwerkdrucker).
Warum fällt das Drucken in Citrix und AVD immer wieder aus?
Weil Druckertreiber‑Code innerhalb der Sitzung ausgeführt werden muss. Treiber im Golden Image stehen oft in Konflikt miteinander und mit Windows‑Updates, umgeleitete Druckernamen ändern sich in gepoolten Sitzungen und führen bei Anwendungen mit hartcodierten Namen zu Fehlern, und gerenderte Druckaufträge verbrauchen auf dem Rückweg zum Client Bandbreite der Sitzung.
Was ist Druckerumleitung?
Die Druckerumleitung bindet die auf lokalen Geräten von Nutzenden installierten Drucker in die virtuelle Sitzung ein, sodass sie in der Druckerliste der Sitzung erscheinen. Druckaufträge aus der Sitzung laufen über den Remote‑Display‑Kanal zurück zum Client, der sie an den Drucker sendet. Dafür muss auf dem Sitzungs‑Host ein geeigneter Treiber vorhanden sein.
Warum ändern sich die Druckernamen in einer gepoolten AVD‑Sitzung?
Die native RDP‑Druckerumleitung hängt umgeleiteten Druckern häufig sitzungsspezifische Bezeichner an, damit sie bei gleichzeitigen Sitzungen auf demselben Host eindeutig bleiben. Anwendungen, die auf einen festen Druckernamen konfiguriert sind, finden den Drucker dann nicht — ein häufiger und schwer zu diagnostizierender Fehler bei Geschäftsanwendungen.
Benötige ich Druckertreiber in meinem VDI‑Golden Image?
Nur wenn das Druckmodell Treiber‑Code innerhalb der Sitzung erfordert. Das trifft auf Druckerumleitung und universelle Druckertreiber zu. Eine auf Cloud rendering basierende Architektur benötigt dies nicht: Druckaufträge werden außerhalb der Sitzung gerendert und über einen lokalen Connector direkt an den Drucker gesendet, sodass das Image keinerlei Druckertreiber enthält.
- September 2026 (10)
- August 2026 (9)
- Juli 2026 (9)
- Juni 2026 (12)
- Mai 2026 (3)
- April 2026 (3)
- März 2026 (3)
- Februar 2026 (2)
- Januar 2026 (2)
- Dezember 2025 (1)
- November 2025 (4)
- Oktober 2025 (4)
- September 2025 (2)
- August 2025 (4)
- Juli 2025 (1)
- Juni 2025 (2)
- Mai 2025 (3)
- April 2025 (5)
- März 2025 (4)
- Februar 2025 (3)
- Januar 2025 (2)
- Dezember 2024 (2)
- November 2024 (3)
- Oktober 2024 (4)
- September 2024 (2)
- August 2024 (2)
- Juli 2024 (4)
- Mai 2024 (4)
- Februar 2024 (4)
- Januar 2024 (1)
- Dezember 2023 (1)
- November 2023 (1)
- Oktober 2023 (3)
- September 2023 (2)
- August 2023 (1)
- Juli 2023 (2)
- Juni 2023 (1)
- Mai 2023 (1)
- April 2023 (3)
- März 2023 (7)
- Februar 2023 (4)
- Dezember 2022 (2)
- November 2022 (2)
- Oktober 2022 (4)
- September 2022 (6)
- August 2022 (1)
- Juli 2022 (4)
- Juni 2022 (4)
- Mai 2022 (1)
- April 2022 (5)
- März 2022 (3)
- Februar 2022 (3)
- Oktober 2021 (1)
- Juli 2021 (4)
- Juni 2021 (4)
- Mai 2021 (1)
- April 2021 (2)
- März 2021 (1)
- Februar 2021 (1)
- Dezember 2020 (1)
- November 2020 (1)
- Oktober 2020 (2)
- September 2020 (1)
- August 2020 (1)
- Juli 2020 (1)
- Juni 2020 (1)
- Mai 2020 (1)
- April 2020 (2)
- März 2020 (2)
- Februar 2020 (1)
- August 2019 (2)
- Mai 2019 (1)