Drucken in AVD, Citrix und RDS: Wie es funktioniert und warum es scheitert

By Brock McKenna on September 30, 2026

<span id="hs_cos_wrapper_name" class="hs_cos_wrapper hs_cos_wrapper_meta_field hs_cos_wrapper_type_text" style="" data-hs-cos-general-type="meta_field" data-hs-cos-type="text" >Drucken in AVD, Citrix und RDS: Wie es funktioniert und warum es scheitert</span>

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.

vdi-printing-direct-ip

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

 

Druckmodell
Wie der Druckauftrag zum Drucker gelangt
Welche Probleme es löst
Wichtigster Kompromiss
Druckerumleitung
Lokale Drucker werden in der virtuellen Sitzung abgebildet; der Druckauftrag läuft zurück an den Client
Erfordert keine zusätzliche Infrastruktur
Treiberkonflikte, wechselnde Druckernamen und Sitzungsbandbreite
Universeller Druckertreiber
Ein Treiber in der Sitzung erzeugt ein Zwischenformat, das auf dem Client oder dem Druckserver konvertiert wird
Reduziert die Anzahl der Treiber im Image
Der Druckdatenverkehr überschreitet weiterhin die Sitzungsgrenze und einige Drucker-Features sind möglicherweise nicht verfügbar
Direktes IP-Drucken
Der Sitzungs-Host druckt direkt über IP auf den Netzwerkdrucker
Entfernt die Umleitung und die Einbindung des Clients
Sitzungs-Hosts müssen Zugriff auf die Drucker im Netzwerk haben

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?

chrome-extension-print
Bereit für VDI-Druck in der Cloud?
Teste ezeep noch heute.
Kostenlos Testen

 

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.

Back to top