Terminalserver und RDS-Farmen im IT-Support

Warum RDS-Farmen im KMU immer noch relevant sind

Auch wenn Azure Virtual Desktop und Cloud-PCs viel Aufmerksamkeit bekommen: Klassische Remote Desktop Services (RDS) mit lokalen oder in Azure gehosteten Session-Hosts sind in Schweizer KMU nach wie vor der Standard, wenn eine ERP-Applikation, eine Fachanwendung mit lokaler Datenbankanbindung oder eine alte Client-Server-Software zentral bereitgestellt werden muss. Der Unterschied zu “einfach mal per RDP draufverbinden” (siehe RDP-Grundlagen) ist die Architektur dahinter: mehrere Rollen, die zusammenspielen, eine Lizenzlogik, die bei Fehlkonfiguration richtig teuer werden kann, und Performance-Fragen, die erst ab 20, 50 oder 200 gleichzeitigen Sessions sichtbar werden.

Dieser Artikel geht davon aus, dass du RDP und Active Directory bereits kennst und dich jetzt mit einer produktiven RDS-Farm auseinandersetzt - Neuaufbau, Übernahme einer bestehenden Umgebung oder Troubleshooting bei Performance-Problemen.

Die RDS-Rollenarchitektur im Detail

Eine vollständige RDS-Bereitstellung besteht aus mehreren Rollen, die auf unterschiedlichen Servern liegen können (oder in kleinen Umgebungen auf einem einzigen Server kombiniert werden):

Für eine minimale, aber produktionsfähige Farm brauchst du mindestens: einen Connection Broker (kann mit Web Access und Licensing kombiniert werden) und zwei Session Hosts für Redundanz. RD Gateway kommt erst dazu, sobald Benutzer von ausserhalb des Firmennetzes zugreifen sollen.

Bereitstellungsarten: Schnellstart vs. Standardbereitstellung

Im Server-Manager-Assistenten für RDS gibt es zwei Wege:

• Schnellstart (“Quick Start”): installiert Broker, Web Access und Session Host auf demselben Server. Nur für Labor/Test geeignet, nicht für Produktion.
• Standardbereitstellung: du wählst jede Rolle einzeln und auf welchem Server sie landet. Das ist der Weg für jede produktive KMU-Umgebung, auch wenn du am Ende nur zwei oder drei Server hast.

# RDS-Standardbereitstellung per PowerShell aufbauen (auf dem künftigen Broker ausführen)
New-RDSessionDeployment -ConnectionBroker "rdcb01.kmu.local" `
  -WebAccessServer "rdcb01.kmu.local" `
  -SessionHost @("rdsh01.kmu.local", "rdsh02.kmu.local")

# RD Gateway nachträglich hinzufügen
Add-RDServer -Server "rdgw01.kmu.local" -Role RDS-GATEWAY -ConnectionBroker "rdcb01.kmu.local"

# Lizenzserver-Rolle hinzufügen
Add-RDServer -Server "rdlic01.kmu.local" -Role RDS-LICENSING -ConnectionBroker "rdcb01.kmu.local"

Session-Host-Lastverteilung: wie neue Verbindungen verteilt werden

Zwei getrennte Mechanismen sorgen dafür, dass Benutzer auf den richtigen Session Host landen:

1. Initiale Verteilung zum Broker: Der Client verbindet sich zuerst zur Farm-Adresse (z. B. per DNS Round Robin auf mehrere Broker-IPs oder über einen Hardware-Load-Balancer/VIP bei HA-Brokern). Der Broker entscheidet dann, welcher Session Host die Sitzung übernimmt.
2. Broker-Entscheidung: Der RD Connection Broker prüft zuerst, ob für den Benutzer bereits eine getrennte (disconnected) Sitzung existiert - falls ja, wird er dorthin zurückgeleitet (Reconnect hat immer Vorrang vor Lastverteilung). Gibt es keine bestehende Sitzung, wählt der Broker den Session Host mit der relativ geringsten Auslastung, gewichtet nach dem konfigurierten “Relative Weight” jedes Hosts.

# Relative Gewichtung eines Session Hosts in der Farm anpassen (Standard = 100)
# Höherer Wert = mehr Sitzungen werden dorthin verteilt, z. B. bei stärkerer Hardware
Set-RDSessionCollectionConfiguration -CollectionName "KMU-Apps" `
  -SessionHost "rdsh02.kmu.local" -RelativeWeight 150

Für Hochverfügbarkeit des Brokers selbst brauchst du eine SQL-Server-Datenbank (kann eine schlanke Express-Instanz sein) als gemeinsamen Sitzungsstatus-Speicher - siehe SQL-Server-Hochverfügbarkeit im KMU. Ohne HA-Broker ist der Broker ein Single Point of Failure: fällt er aus, können sich Benutzer zwar theoretisch weiter direkt mit einem Session Host verbinden, aber neue Lastverteilung und Reconnect-Logik funktionieren nicht mehr sauber.

# Connection Broker in den Hochverfügbarkeitsmodus versetzen
Set-RDConnectionBrokerHighAvailability -ConnectionBroker "rdcb01.kmu.local" `
  -DatabaseConnectionString "DRIVER=SQL Server Native Client 11.0;SERVER=sql01.kmu.local;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDCBDB" `
  -ClientAccessName "rdsfarm.kmu.local"

Profildisks und FSLogix: das Profilproblem lösen

Sobald mehrere Session Hosts im Spiel sind, darf ein Benutzerprofil nicht mehr lokal auf einem einzelnen Server liegen - sonst verliert der Benutzer bei jedem Reconnect auf einen anderen Host seine Einstellungen. Microsoft hat dafür drei Generationen von Lösungen angeboten:

1. Servergespeicherte Profile (Roaming Profiles) - alt, langsam, anfällig für Profilkorruption bei parallelem Zugriff. Nicht mehr empfohlen.
2. User Profile Disks (UPD) - eine VHD-Datei pro Benutzer, eingeführt mit Server 2012. Funktioniert, aber unflexibel (ein Profil pro Collection, kein granulares Whitelisting).
3. FSLogix Profile Container - seit 2021 kostenlos in allen relevanten Windows-Server- und Microsoft-365-Lizenzen enthalten, heute der De-facto-Standard. Siehe auch die vertiefte FSLogix-Profilverwaltung.

FSLogix mountet bei der Anmeldung eine VHDX-Datei aus einem Netzwerkfreigabe-Pfad direkt als Benutzerprofil - für Windows sieht es aus wie ein lokales Profil, liegt aber zentral auf einem Fileserver.

; FSLogix-Kernkonfiguration per GPO (Administrative Vorlagen -> FSLogix -> Profile Containers)
Enabled = 1
VHDLocations = \\fs01.kmu.local\FSLogixProfiles$
VolumeType = VHDX
SizeInMBs = 30000
IsDynamic = 1
DeleteLocalProfileWhenVHDShouldApply = 1
PreventLoginWithFailure = 1
PreventLoginWithTempProfile = 1
FlipFlopProfileDirectoryName = 1

Wichtige Praxispunkte, die in vielen KMU-Umgebungen übersehen werden:

• Dedizierte Freigabe mit korrekten NTFS-Rechten: Benutzer brauchen “Modify” auf ihr eigenes Verzeichnis, aber keinen Zugriff auf fremde Profile. FSLogix erstellt die Unterordner automatisch, die Freigabe selbst muss aber vorbereitet sein - siehe Windows-Server-Freigaben.
• Antivirus-Ausschlüsse zwingend: VHDX-Dateien und die FSLogix-Prozesse (frxdrv.sys, frxccd.sys, frxsvc.exe) müssen von Echtzeit-Scans ausgeschlossen werden, sonst gibt es massive Anmeldeverzögerungen und gelegentliche Profilkorruption.
• Storage-IOPS nicht unterschätzen: Ein Login-Sturm morgens um 8 Uhr, wenn 40 Benutzer gleichzeitig ihre VHDX mounten, erzeugt einen kurzen, heftigen IOPS-Peak auf dem Fileserver. Auf klassischen HDD-basierten NAS-Systemen ist das ein häufiger Grund für “morgens ist RDS langsam, ab 9 Uhr geht’s wieder”.
• Cloud Cache für Multi-Site: Bei zwei Standorten mit RDS-Farmen kann FSLogix Cloud Cache Profile über mehrere Speicherorte gleichzeitig synchron halten - relevant, wenn Benutzer je nach Standort auf unterschiedliche Session-Host-Pools zugreifen.

RemoteApp veröffentlichen statt vollen Desktop

Viele KMU-Szenarien brauchen keinen vollständigen Remote-Desktop, sondern nur eine einzelne Anwendung - zum Beispiel die ERP-Software oder eine Fachapplikation. RemoteApp veröffentlicht ein einzelnes Programm so, dass es für den Benutzer wie eine lokal installierte App aussieht (eigenes Fenster, eigene Taskleisten-Kachel), technisch aber komplett auf dem Session Host läuft.

# Eine RemoteApp-Sammlung anlegen und eine Anwendung veröffentlichen
New-RDSessionCollection -CollectionName "KMU-ERP" `
  -SessionHost @("rdsh01.kmu.local", "rdsh02.kmu.local") `
  -CollectionDescription "ERP-Fachanwendung fuer Sachbearbeitung"

New-RDRemoteApp -Alias erp-client -DisplayName "ERP-Client" `
  -FilePath "C:\Programme\ERPSoftware\erpclient.exe" `
  -CollectionName "KMU-ERP" -ShowInWebAccess 1

# Veröffentlichte RemoteApps einer Sammlung anzeigen
Get-RDRemoteApp -CollectionName "KMU-ERP"

Benutzer erreichen die App entweder über das RD-Web-Access-Portal (https://rdweb.kmu.local/RDWeb), per doppelklickbarer .rdp-Datei, die du zentral per GPO oder Intune verteilst, oder über ein automatisch generiertes MSI-Paket, das den lokalen Icon-Eintrag erzeugt.

Lizenzierung: RDS-CALs richtig verstehen

Die RDS-Lizenzierung ist einer der häufigsten Stolpersteine, weil sie komplett getrennt von der Windows-Server-Lizenzierung läuft. Jeder Benutzer oder jedes Gerät, das sich mit einem RD Session Host verbindet, braucht zusätzlich zur Windows-Server-CAL eine RDS-CAL.

Für die meisten Büro-KMU mit “ein Mitarbeitender, mehrere Geräte” ist Per User CAL die einfachere und meist günstigere Wahl. Bei Produktionsumgebungen mit gemeinsam genutzten Stationen (Lager, Fertigung) kann Per Device günstiger sein.

# Lizenzierungsmodus für die Farm setzen (einmalig, nach Aktivierung des Lizenzservers)
Set-RDLicenseConfiguration -LicenseServer "rdlic01.kmu.local" `
  -Mode PerUser -ConnectionBroker "rdcb01.kmu.local" -Force

# Lizenzserver-Status und ausgegebene CALs prüfen
Get-RDLicenseConfiguration -ConnectionBroker "rdcb01.kmu.local"

Wichtig für die Einkaufsseite: RDS-CALs gibt es nur im Volumenlizenzprogramm (z. B. über einen Microsoft-Partner/CSP), nicht als Einzelplatz-Retail-Lizenz. Wer RDS im Rahmen eines gehosteten Angebots für Dritte betreibt (Managed Service Provider), braucht stattdessen SPLA-Lizenzen (Services Provider License Agreement) mit monatlicher Abrechnung pro genutzter CAL - normale Volumenlizenz-CALs dürfen nicht an Dritte weitervermietet werden.

Performance-Troubleshooting bei vielen Sessions

Ab einer gewissen Benutzerzahl pro Session Host wird “es ist langsam” zur täglichen Ticket-Kategorie. Die Ursache liegt fast immer in einer von vier Ressourcen: CPU, Arbeitsspeicher, Storage-Latenz oder Netzwerk/Grafik.

Systematischer Ablauf

1. Task-Manager auf dem Session Host, Tab “Benutzer”: sofortiger Überblick, welche Sitzung wie viel CPU/RAM frisst - schneller erster Blick, bevor du in Perfmon einsteigst.
2. Get-RDUserSession / qwinsta: Sitzungsübersicht auch remote per PowerShell abrufen.
3. Performance Monitor mit RDS-spezifischen Countern: gezielt nach Engpässen suchen (siehe unten).
4. Event-Viewer, Kanal “Microsoft-Windows-TerminalServices-*”: liefert oft den entscheidenden Hinweis (Lizenzfehler, Profil-Ladefehler, RDP-Protokollabbrüche).
5. Ursache isolieren: einzelner Benutzer/Prozess vs. globales Muster über alle Sitzungen.

# Aktive und getrennte Sitzungen auf einem Session Host auflisten
Get-RDUserSession -CollectionName "KMU-ERP" | Format-Table UserName, HostServer, SessionState

# Sitzung eines Benutzers gezielt abmelden (z. B. bei hängender Session)
Invoke-RDUserLogoff -HostServer "rdsh01.kmu.local" -UnifiedSessionID 7 -Force

# Klassisch per CMD auf dem Host selbst
qwinsta
rwinsta /server:rdsh01 7

Wichtige Performance-Counter für Perfmon (perfmon.exe /res remote nutzbar):

• \User Input Delay per Session(*)\Max Input Delay - der wichtigste Einzelcounter für “fühlt sich langsam an”. Werte über 200ms deuten auf spürbare Verzögerung hin, über 2000ms ist für Benutzer klar wahrnehmbar.
• \Terminal Services\Active Sessions und \...\Inactive Sessions - viele getrennte, aber nicht abgemeldete Sitzungen belegen weiterhin RAM.
• \Memory\Available MBytes - klassischer Speicherengpass, oft durch zu viele parallele Outlook/Teams/Chrome-Instanzen.
• \PhysicalDisk(*)\Avg. Disk sec/Transfer - Storage-Latenz, besonders relevant für FSLogix-Profildisks und Auslagerungsdatei.
• \Processor Information(_Total)\% Processor Time - CPU-Sättigung, oft durch Antivirus-Scans oder ineffiziente Fachapplikationen.

// Falls RDS-Hosts an Log Analytics angebunden sind: Sessions mit hoher Input-Delay finden
Perf
| where ObjectName == "User Input Delay per Session"
| where CounterName == "Max Input Delay"
| where CounterValue > 500
| summarize avg(CounterValue) by Computer, InstanceName, bin(TimeGenerated, 5m)
| order by avg_CounterValue desc

Kapazitätsplanung als Faustformel

Für die Dimensionierung eines neuen Session Hosts gilt grob:

Benötigter RAM = OS-Grundlast (ca. 4-6 GB)
               + (RAM pro Session × Anzahl gleichzeitiger Sessions)

Beispiel Bürobetrieb (Office, Browser, ERP-Client):
  6 GB (OS) + 40 Sessions × 1,5 GB = 66 GB RAM

CPU-seitig gilt als grobe Startlinie 6-10 gleichzeitige “leichte” Office-Benutzer pro physischem Kern, bei rechenintensiveren Anwendungen (CAD, grosse Excel-Modelle) deutlich weniger - hier hilft nur ein Lasttest mit realistischen Fachanwendungen, bevor die Farm live geht.

Entscheidungsbaum: Wann RDS, wann eine Alternative?

Braucht ihr zentral gehostete Windows-Anwendungen für mehrere Benutzer?
│
├─ Nur 1 Anwendung, wenige Benutzer, kein Wachstum absehbar
│   └─ Einzelner Terminalserver ohne Farm-Overhead (kein Broker nötig)
│
├─ Mehrere Anwendungen/Abteilungen, Wachstum absehbar, eigenes Rechenzentrum vorhanden
│   └─ Volle RDS-Farm mit Broker-HA, RD Gateway, FSLogix (dieser Artikel)
│
├─ Bereits stark in Microsoft 365 / Entra ID investiert, will Cloud-first
│   └─ Azure Virtual Desktop (AVD) prüfen - gleiche RDS-Kernkomponenten,
│      aber Broker/Gateway/Lizenzierung durch Azure abgenommen
│
└─ Sehr hohe Anforderungen an Grafik/GPU, Multi-Tenant-Isolation, grosse Farm
    └─ Citrix Virtual Apps and Desktops als Enterprise-Alternative evaluieren
       (höhere Lizenzkosten, aber mehr Features bei Protokoll/Provisioning)

Sicherheit rund um RDS-Farmen

• Network Level Authentication (NLA) immer aktiv lassen - Authentifizierung findet vor dem Sitzungsaufbau statt, reduziert Angriffsfläche gegen ungepatchte RDP-Schwachstellen erheblich.
• RD Gateway mit gültigem, öffentlich vertrauenswürdigem Zertifikat betreiben (kein selbstsigniertes Zertifikat in Produktion) - siehe SSL/TLS-Zertifikate.
• MFA vor dem Gateway über die Azure MFA NPS-Extension oder eine RADIUS-Kette - eine reine Benutzername/Passwort-Anmeldung an einer Farm mit Internetzugriff ist 2026 nicht mehr vertretbar.
• Sitzungs-Timeouts konfigurieren: aktive Leerlauf-Zeit und maximale Verbindungsdauer über GPO begrenzen, damit vergessene, aber noch angemeldete Sitzungen nicht dauerhaft Ressourcen und Angriffsfläche offenhalten.
• Session Hosts wie Server behandeln, nicht wie Clients: konsequentes Patch-Management, siehe WSUS-Patchmanagement, da ein kompromittierter Session Host sofort Zugriff auf alle aktiven Benutzersitzungen bedeutet.

Weiterlernen

• Remote Desktop Services roles - Microsoft Learn
• RDS Standardbereitstellung erstellen - Microsoft Learn
• RD-Sitzungshostfarm horizontal skalieren - Microsoft Learn
• RDS mit CALs lizenzieren - Microsoft Learn
• FSLogix Profile Container konfigurieren - Microsoft Learn
• Performance-Counter zur Diagnose auf RD Session Hosts - Microsoft Learn