Remote Desktop Multi Session: Simultane einrichten

Müssen Sie mehrere Benutzer gleichzeitig unterstützen, mehrere GUI‑Sitzungen auf einem Server betreiben oder Technikern erlauben, unabhängig zum gleichen Host zu verbinden? "Remote desktop multi session" ist der Punkt, an dem man auf OS‑Beschränkungen, Lizenzprobleme und Netzwerkkomplexität stößt. Dieser Leitfaden erklärt, was Multi‑Session tatsächlich bedeutet, Plattform‑Tradeoffs und konkrete Einrichtungsschritte, damit Sie gleichzeitige Sitzungen zuverlässig und sicher betreiben können.

Was „multi‑session“ tatsächlich bedeutet

Mit „Multi‑Session“ werden zwei verschiedene Dinge bezeichnet. Wählen Sie vor der Auslegung einer Lösung die Variante, die Sie benötigen.

Mehrere gleichzeitige Verbindungen zur gleichen Desktop‑Sitzung (geteilte Anzeige) — mehrere Administratoren oder Helfer verbinden sich gleichzeitig, um denselben angemeldeten Desktop anzusehen/zu steuern. Tools: TeamViewer, AnyDesk, Tenvo und klassische VNC‑Varianten. Nützlich für Co‑Support und Demonstrationen.
Mehrere unabhängige GUI‑Sitzungen auf einer Maschine (separate Benutzersitzungen) — verschiedene Benutzer erhalten jeweils eigene Desktop‑Sitzungen auf demselben Host (ähnlich wie mehrere RDP‑Sitzungen auf einem Windows Server). Das erfordert Server‑OS‑Unterstützung oder einen Session‑Manager, der Benutzersitzungen erstellt und diesen unterschiedliche virtuelle Displays zuordnet.

Architektur‑ und Lizenzentscheidungen folgen daraus, welche Variante Sie wählen. Geteilte Konsolensitzungen sind einfach; unabhängige Sitzungen erfordern Serverrollen oder Linux‑Session‑Daemonen.

Plattformunterschiede und praktische Schritte

So verhalten sich die drei großen Betriebssystemfamilien und so richten Sie dort gleichzeitige Sitzungen ein.

Windows (Desktop vs. Server)

Windows‑Desktop‑SKUs (Windows 10/11 Pro) sind dafür ausgelegt, jeweils eine interaktive Konsolen‑Sitzung zu bieten. Mehrere Personen können mit Drittanbieter‑Tools auf diese Konsole zugreifen, aber unabhängige Benutzer‑Desktops erhalten Sie nicht ohne Wechsel zu Windows Server und Remote Desktop Services (RDS).

Windows Server (2016/2019/2022) unterstützt mehrere unabhängige Sitzungen über die Remote Desktop Services‑Rolle. Wichtige Komponenten sind:

RD Session Host (hostet Benutzersitzungen).
RD Connection Broker (weist Benutzer Sitzungen zu und unterstützt Wiederverbindung sowie Load‑Balancing).
RD Web Access / RD Gateway (sicherer Fernzugriff über HTTPS).
RDS‑Lizenzierung: Sie benötigen RDS CALs (pro Benutzer oder pro Gerät) — Microsoft verlangt korrekte Lizenzierung für den produktiven Mehrfach‑Sitzungsbetrieb.

Grobe Schritte, um mehrere unabhängige Sitzungen auf Windows Server einzurichten:

Installieren Sie Windows Server 2019 oder 2022 (diese Versionen werden aktuell empfohlen).
Fügen Sie die Remote Desktop Services‑Rolle und die erforderlichen Rollendienste hinzu (Session Host, Connection Broker, Licensing).
Konfigurieren Sie den Lizenzierungsmodus und installieren Sie Ihre RDS CALs im RD Licensing Manager.
Optional: Fügen Sie einen RD Gateway hinzu, um RDP (TCP/3389) nicht offen ins Internet stellen zu müssen, und aktivieren Sie NLA (Network Level Authentication).
Nutzen Sie DNS oder einen Load Balancer vor mehreren RD Session Host‑Servern und registrieren Sie den Connection Broker für Session‑Persistenz.

Wann Sie Windows RDS verwenden sollten: Sie benötigen Profilpersistenz, Anwendungsisolation und saubere Benutzertrennung. Wenn Sie nur möchten, dass ein Supporttechniker die Konsole eines Benutzers ansieht/steuert, ist ein Remote‑Support‑Tool einfacher und benötigt keine RDS‑Lizenzierung.

Linux: mehrere unabhängige Sitzungen sind unkompliziert

Linux‑Desktops sind flexibel. Sie können mehrere X.org‑ oder Wayland‑Sitzungen betreiben und jede per RDP (xrdp) oder VNC bereitstellen. Das macht unabhängige Sitzungen kostengünstig und einfach skalierbar.

Beispiel: Ubuntu 22.04 LTS + xrdp + TigerVNC. Diese Konfiguration gibt jedem Benutzer eine eigene Sitzung auf separaten Display‑Nummern. Praktische Befehle:

sudo apt update
sudo apt install -y xrdp tigervnc-standalone-server
sudo systemctl enable --now xrdp
# create users
sudo adduser alice
sudo adduser bob
# open firewall for RDP (or tunnel via SSH / VPN instead)
sudo ufw allow 3389/tcp

xrdp ordnet neue Anmeldungen standardmäßig neuen Sitzungen zu. Wenn Sie lieber pro‑Display VNC‑Ports verwenden, nutzt VNC TCP‑Ports 5900 + Display‑Nummer (Display :1 → 5901). Für Internetzugriff sollten Sie einen Reverse‑Proxy, Apache Guacamole oder ein VPN vor die Hosts setzen, anstatt 3389/5900 direkt freizugeben.

Linux erleichtert auch die Automatisierung des Spawnens von Sitzungen, die Verwendung von LDAP/AD für die Benutzerauthentifizierung und das Ablegen von Home‑Verzeichnissen auf einem NFS/SMB‑Share, wenn Sie zustandslose Hosts hinter einem Load Balancer benötigen.

macOS: eingeschränkte unabhängige GUI‑Sitzungen

macOS ist primär ein Ein‑Konsolen‑OS. Sie können schnellen Benutzerwechsel und mehrere Beobachter per Screen Sharing oder Apple Remote Desktop nutzen, aber macOS bietet in der Regel keine mehreren unabhängigen GUI‑Sitzungen wie Windows Server oder Linux (ohne aufwändige Hacks und nicht unterstützte Serverprodukte).

Wenn Sie viele unabhängige GUI‑Sitzungen benötigen, sind Linux oder Windows Server bessere Wahl. Wenn der Anwendungsfall Remote‑Support oder geteiltes Bildschirmsehen auf einem Mac ist, decken Tools wie Tenvo, TeamViewer oder VNC diesen Bedarf ab.

Session‑Broker, Load‑Balancing und Skalierung

Ein paar gleichzeitige Sitzungen zu betreiben ist eine Sache; Hunderte erfordern Architektur: Session‑Broker, Load‑Balancing und zentralisierte Benutzerverzeichnisse.

Connection Broker / Session‑Manager — Windows verwendet den RD Connection Broker, um Benutzer zu leiten und Sitzungsstatus zu erhalten. Für Linux können Sie Apache Guacamole als Web‑Gateway oder eigene Broker (LB + Sticky‑Sessions) einsetzen, um Benutzer auf Hosts zu verteilen.
Load‑Balancing — verwenden Sie DNS + Load Balancer oder Hardware‑NLB. Stellen Sie sicher, dass der Broker Session‑Wiederverbindung/Sticky‑Mapping unterstützt.
Profil‑Speicherung — für wechselnde Benutzer (Roaming) speichern Sie Profile auf einem zentralen Dateiserver (SMB/NFS) oder verwenden Roaming‑Profile, damit Sitzungen unabhängig vom Host konsistent sind.
Sicherheit — setzen Sie RD Gateway, VPN oder Web‑Gateways vor die RDP/VNC‑Endpunkte; stellen Sie 3389/5900 nicht direkt ins Internet, es sei denn, Sie haben entsprechende Schutzmaßnahmen.

Für Windows‑RDS‑Farmen sind RD Connection Broker und RD Licensing Server in großem Maßstab obligatorisch; für Linux‑Fleets ist die Zentralisierung der Authentifizierung mit LDAP/AD und der Einsatz eines Gateways wie Apache Guacamole oder eines VPN übliche Praxis.

Praktisches Linux‑Beispiel: xrdp für mehrere unabhängige Sitzungen

Hier ein knapper Konfigurationsablauf, der für kleine Teams gut funktioniert, die separate Sitzungen auf einem Linux‑Server (Beispiel Ubuntu 22.04) wünschen.

Installieren Sie die Pakete (siehe Befehle weiter oben).
Konfigurieren Sie xrdp so, dass das Xorg‑Backend verwendet wird. Bearbeiten Sie /etc/xrdp/xrdp.ini, um sicherzustellen, dass neue Sitzungen wie erforderlich gestartet werden (Standard ist für die meisten Installationen ausreichend).
Legen Sie separate Benutzerkonten mit adduser an und setzen Sie Passwörter.
Verwenden Sie SSH‑Tunnels oder ein VPN für den Fernzugriff, statt 3389 freizugeben. Beispiel: SSH‑Tunnel vom Administrator‑Arbeitsplatz:

ssh -L 33890:localhost:3389 youruser@remote-host.example.com

Richten Sie dann Ihren RDP‑Client auf localhost:33890. Das erlaubt mehreren Admins, verschiedene Tunnel zu erstellen und zu verbinden, ohne Firewallregeln zu ändern. Für Unternehmen ersetzen Sie SSH‑Tunneling durch ein zentral verwaltetes VPN oder ein Gateway wie Apache Guacamole.

Wann Tenvo einsetzen (und wie es passt)

Tenvo ist ein Open‑Source‑Remote‑Desktop‑Tool, das standardmäßig über einen verwalteten Relay läuft. Für Support‑ und Multi‑Operator‑Workflows ist das der relevante Teil: Sie installieren einen Client auf jedem Endpunkt statt RDP‑ oder VNC‑Ports zu öffnen, und das Relay übernimmt die Arbeit, Maschinen hinter NAT zu erreichen. Der Code ist AGPL‑3.0, daher bleibt es möglich, das Relay selbst zu betreiben — es ist einfach nicht der Weg, den die meisten Teams brauchen.

Verwenden Sie Tenvo, wenn:

Sie müssen viele verschiedene Endpunkte aus der Ferne unterstützen, ohne auf jedem Gerät RDP‑Ports zu öffnen.
Sie möchten, dass ein verwaltetes Relay die NAT‑Traversal für Sie übernimmt, statt Routerregeln oder Tunnel pro Standort zu pflegen (siehe unseren Guide zu remote desktop without port forwarding). Ein eigenes Relay zu betreiben ist ebenfalls möglich, es lohnt sich aber nur, wenn eine Anforderung dies verlangt.
IHR Bedarf ist Co‑Support oder gemeinsamer Zugriff auf denselben Desktop, statt unabhängiger OS‑Level‑Sitzungen pro Nutzer.

Wenn Sie vollständig unabhängige Benutzersitzungen (je Nutzer ein eigener Desktop) unter Windows benötigen, ist RDS auf Windows Server der korrekte Ansatz; Tenvo ersetzt nicht die RDS‑Lizenzanforderungen. Das Relay im eigenen LAN zu betreiben ergibt Sinn, wenn eine Anforderung dies vorschreibt — Formulierungen in Compliance‑Vorgaben zu Infrastruktur Dritter, isolierten Netzwerken oder Datenresidenzregeln, die eine Rechtsordnung nennen; unser Self-hosted remote desktop: the honest 2026 guide beschreibt diese Installation und die laufenden Kosten. Fehlt eine solche Anforderung, ist das verwaltete Relay die günstigere Option.

Holen Sie sich den Client von der Downloads-Seite und verbinden Sie sich über das verwaltete Relay — kein eigener Server nötig. Free ist $0, Lite $2.99/Monat und Pro $7.99/Monat auf der Preise; wenn Sie dies in einem Support‑Team ausrollen, siehe die Business‑Pläne.

Sicherheits‑ und Lizenz‑Checkliste

Bevor Sie Multi‑Session‑Zugriff ausrollen, arbeiten Sie diese Checkliste ab:

Ist die Sitzung ein geteilter Konsolen‑Sitzungstyp oder unabhängige Sitzungen? Wählen Sie die korrekte Architektur.
Für Windows Server Multi‑Session: Stellen Sie sicher, dass Sie RDS CALs besitzen und die RD Licensing‑Rolle installiert ist.
Blockieren Sie die direkte Exposition von RDP/VNC‑Ports; verwenden Sie RD Gateway, VPN, SSH‑Tunnels oder ein Remote‑Access‑Gateway wie das Relay von Tenvo.
Aktivieren Sie NLA auf RDP‑Hosts und erzwingen Sie nach Möglichkeit starke Passwörter / MFA.
Protokollieren und überwachen Sie Sitzungsaktivitäten — führen Sie Audit‑Trails darüber, wer wann verbunden war.
Nutzen Sie ein zentrales Identitätsverzeichnis (AD/LDAP), damit Zugriffe zentral entzogen werden können.

Für eine detailliertere Betrachtung der Sicherheits‑Tradeoffs siehe unseren Artikel zu Remote‑Desktop‑Sicherheit, der Härtung von RDP und die Konfiguration von Gateways und MFA behandelt.

Fehlerbehebungstipps

Verbindungen schlagen fehl? Prüfen Sie, ob der Session‑Broker oder das Gateway erreichbar ist und DNS korrekt aufgelöst wird.
Benutzer können nicht zu ihren Sitzungen zurückkehren? Prüfen Sie unter Windows die Gesundheit des RD Connection Broker und stellen Sie sicher, dass die RD Session Host‑Server dort registriert sind. Unter Linux prüfen Sie die xrdp‑Logs unter /var/log/xrdp-sesman.log.
Leistungsprobleme bei vielen Sitzungen? Überwachen Sie CPU, RAM und Festplatten‑I/O; fügen Sie weitere Session‑Hosts hinzu und verwenden Sie einen Load Balancer oder horizontale Skalierung.
Firewall‑ und NAT‑Probleme? Verwenden Sie SSH‑Tunnels oder das Relay von Tenvo, um komplexe Port‑Änderungen zu vermeiden.

Fazit — das richtige Werkzeug wählen

Wenn Ihr Ziel Co‑Support oder mehrere Personen ist, die am selben Desktop arbeiten, dann ist das die Aufgabe eines Remote‑Support‑Tools und nicht einer Serverrolle — und bei Tenvo läuft das über das verwaltete Relay, sodass im Netzwerk des Endgeräts nichts geöffnet werden muss. Wie sich das gegenüber den proprietären Optionen verhält, stellen wir in unseren Vergleichen mit TeamViewer und AnyDesk dar. Wenn Sie pro Nutzer separate, unabhängige Desktops benötigen, planen Sie mit Windows Server RDS oder einer Linux‑Multi‑Session‑Bereitstellung (xrdp/TigerVNC oder ein Web‑Gateway wie Guacamole).

Es gibt kein Patentrezept: Windows RDS ist die richtige Enterprise‑Wahl für das Hosten von Benutzerdesktops und die Bereitstellung von Anwendungen, und Linux ist der günstigste Weg zu unabhängigen Sitzungen wenn Sie die Hosts bereits betreiben und warten. Rechnen Sie die Gesamtbilanz, bevor Sie es billig nennen — Bereitschaftsdienste, Patchen, Schlüsselverwaltung, Zertifikatserneuerung, eine Region ohne Failover. Um Endpunkte über NAT zu erreichen, ohne pro Standort Netzwerkarbeit zu leisten, ist ein verwaltetes Relay für $2.99–$7.99 pro Monat in der Regel die kürzere Rechnung; siehe Preise.

Bereit, es auszuprobieren? Tenvo herunterladen und testen Sie den Multi‑Operator‑Workflow über das verwaltete Relay — das ist die Voreinstellung, und für die meisten Teams ist die Sache damit erledigt; die Stufen sind auf Preise aufgeführt. Wenn eine Compliance‑Vorgabe, ein isoliertes Netzwerk oder eine Residenzregel verlangt, dass das Relay Ihnen gehört, behandelt unser Self-hosted remote desktop: the honest 2026 guide die Installation und die laufenden Kosten.