Remote Desktop Services (RDS) ist die Windows-Server-Technologie, mit der mehrere Benutzer gleichzeitig Desktops oder Applikationen auf einem zentralen Server nutzen, der klassische Terminalserver für KMU. Ohne aktivierten Lizenzserver enden Verbindungen nach 120 Tagen. Diese Anleitung zeigt Installation, Lizenzserver-Aktivierung und CAL-Wahl.

Voraussetzungen

Windows Server 2022 oder 2025 (Standard oder Datacenter) auf allen RDS-Servern
RDS Client Access Licenses (CALs), Per-User oder Per-Device, passend zur Windows-Server-Version des Session Hosts
Für RD Gateway: öffentlich vertrauenswürdiges SSL-Zertifikat (.pfx), CN = externer FQDN
Für HA Connection Broker: SQL Server (oder Azure SQL) für die Sitzungsdatenbank
Session Host mit mindestens 2 CPU-Kernen und 4 GB RAM, dazu RAM und CPU je gleichzeitiger Sitzung nach Anwendungslast; vor dem Produktivbetrieb mit echten Benutzern und Programmen testen
Internetzugang des Lizenzservers (TCP/443) zur Online-Aktivierung, alternativ https://activate.microsoft.com
Alle beteiligten Server lösen sich gegenseitig per Hostname auf (DNS oder HOSTS-Datei)
Konto mit Domain-Admin-Rechten (Domain) oder lokales Administratorkonto (Workgroup)

Schritt 1: RDS-Rollen verstehen und planen

Legen Sie fest, welche der fünf RDS-Rollen Sie brauchen:

Rolle	Aufgabe	Pflicht?
RD Session Host (RDSH)	Führt Benutzersitzungen aus; die eigentliche „Arbeitsmaschine“	Ja
RD Licensing (RDL)	Verwaltet und verteilt RDS-CALs	Ja
RD Connection Broker (RDCB)	Verteilt Sitzungen, ermöglicht Reconnect und Load Balancing	Nur bei mehreren Session Hosts
RD Web Access (RDWA)	Browser-Portal für RemoteApp und Desktop-Verbindungen	Nein
RD Gateway (RDG)	Sicherer Internetzugang über HTTPS/TCP 443	Nein (empfohlen für Remote-Zugriff)

Für 5–15 Benutzer reicht ein einzelner Server mit RDSH + RDL. Den Connection Broker brauchen Sie erst bei mehreren Session Hosts.

Verifizieren: Sie haben schriftlich festgelegt, welche Rollen auf welchem Server laufen, und alle Server lösen sich gegenseitig per Hostname auf (Resolve-DnsName bzw. ping mit Hostnamen).

Schritt 2: Per-User oder Per-Device-CAL wählen

Das Lizenzierungsmodell lässt sich nachträglich nur mit Aufwand ändern:

Kriterium	Per-User-CAL	Per-Device-CAL
Bindung	An Benutzer-Account (beliebig viele Geräte)	An Gerät (beliebig viele Benutzer)
Active Directory nötig?	Ja (Pflicht)	Nein (auch Workgroup)
Schichtbetrieb empfohlen?	Nein	Ja
Widerrufbar?	Nein	Ja (bis 20 % der CALs)
Reassignment	Erst nach 90 Tagen	Temporäre CAL: 90 Tage; permanente CAL: alle 52–89 Tage erneuert
Overuse-Schutz	Kein technischer Stopp – Compliance-Risiko!	Technisch begrenzt durch CAL-Anzahl

Faustregel: 10 Mitarbeiter teilen sich 4 PCs im Schichtbetrieb → 4 Per-Device-CALs. 10 Mitarbeiter mit festem Arbeitsplatz und Active Directory → 10 Per-User-CALs.

Verifizieren: Das gewählte Lizenzmodell passt zu den gekauften CALs: Auf dem Lizenzbeleg steht dieselbe Variante (Per-User oder Per-Device) und dieselbe Windows-Server-Version wie beim Session Host.

Schritt 3: RDS-Rollen installieren

Im Domain-Szenario nutzen Sie den Server Manager Wizard „Remote Desktop Services-Installation“, damit der Connection Broker alle Rollen kennt. Im Workgroup-Betrieb oder für minimale Deployments verwenden Sie PowerShell.

Vollständiges Domain-Deployment per PowerShell

# RD Session Host, Connection Broker und Web Access auf je einem Server deployen
New-RDSessionDeployment `
    -ConnectionBroker 'rdcb.domain.local' `
    -WebAccessServer 'rdweb.domain.local' `
    -SessionHost 'rdsh.domain.local'

Minimales Deployment (Workgroup oder All-in-One)

# RD Session Host installieren
Install-WindowsFeature RDS-RD-Server -IncludeManagementTools

# RDS Licensing-Rolle installieren
Install-WindowsFeature RDS-Licensing -IncludeAllSubFeature -IncludeManagementTools

# Installierte RDS-Features prüfen
Get-WindowsFeature -Name RDS* | Where-Object { $_.Installed -eq $true }

Wichtig: Im Server Manager immer „Remote Desktop Services-Installation“ → „Standardbereitstellung“ wählen, nie die rollenbasierte Installation: Sonst erfährt der Connection Broker nichts von den Rollen, das Deployment bleibt unvollständig.

Verifizieren: Get-WindowsFeature -Name RDS* zeigt RDS-RD-Server und RDS-Licensing als installiert. Im Domain-Szenario listet Get-RDServer -ConnectionBroker 'rdcb.domain.local' alle Server mit ihren Rollen.

Schritt 4: Lizenzserver aktivieren

Aktivieren Sie den Lizenzserver sofort nach der Installation: Remote Desktop Licensing Manager (licmgr.exe) öffnen, Rechtsklick auf den Server, „Server aktivieren“. Die Online-Aktivierung läuft über TCP/443 zum Microsoft Clearinghouse; ohne Internetzugang über https://activate.microsoft.com oder per Telefon.

Danach installieren Sie die CAL-Pakete: Rechtsklick auf den aktivierten Server → „Lizenzen installieren“ → Produktschlüssel eingeben.

Verifizieren: Im Licensing Manager steht beim Server der Aktivierungsstatus „Aktiviert“, und unter dem Server erscheinen die installierten CAL-Pakete mit der erwarteten Anzahl.

Schritt 5: Lizenzserver am Session Host konfigurieren

Die automatische Lizenzserver-Erkennung ist seit Windows Server 2008 R2 unzuverlässig. Geben Sie den Lizenzserver explizit an.

Mit Connection Broker (Domain-Deployment)

# Per Device
Set-RDLicenseConfiguration `
    -LicenseServer @('rds-lic01.domain.local') `
    -Mode PerDevice `
    -ConnectionBroker 'rdcb.domain.local'

# Per User
Set-RDLicenseConfiguration `
    -LicenseServer @('rds-lic01.domain.local') `
    -Mode PerUser `
    -ConnectionBroker 'rdcb.domain.local'

Ohne Connection Broker per WMI (Workgroup / All-in-One)

$obj = Get-WmiObject -Namespace 'Root/CIMV2/TerminalServices' Win32_TerminalServiceSetting

# Modus setzen: 2 = Per Device, 4 = Per User
$obj.ChangeMode(2)

# Lizenzserver eintragen
$obj.SetSpecifiedLicenseServerList('LIC-SERVER-NAME')

# Konfiguration prüfen
$obj.GetSpecifiedLicenseServerList()

Alternativ per Registry

# Lizenzierungstyp: 2 = Per Device, 4 = Per User
$RDSCALMode = 2
$RDSlicServer = 'rds-lic01'

New-Item 'HKLM:\SYSTEM\CurrentControlSet\Services\TermService\Parameters\LicenseServers' -Force

New-ItemProperty `
    'HKLM:\SYSTEM\CurrentControlSet\Services\TermService\Parameters\LicenseServers' `
    -Name SpecifiedLicenseServers `
    -Value $RDSlicServer `
    -PropertyType 'MultiString' `
    -Force

Set-ItemProperty `
    'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Licensing Core' `
    -Name 'LicensingMode' `
    -Value $RDSCALMode

Per GPO (empfohlen für mehrere Session Hosts)

Öffnen Sie gpmc.msc und navigieren Sie zu Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Licensing. Aktivieren Sie „Use the specified Remote Desktop license servers“ und „Set the Remote Desktop licensing mode“.

Verifizieren: $obj.GetSpecifiedLicenseServerList() bzw. Get-RDLicenseConfiguration -ConnectionBroker 'rdcb.domain.local' zeigt den eingetragenen Lizenzserver und den richtigen Modus. Der RD Licensing Diagnoser (lsdiag.msc) meldet keine Fehler.

Schritt 6: Benutzer einrichten und Session Collection erstellen

# Benutzer zur Remote Desktop Users-Gruppe hinzufügen (lokal / Workgroup)
Add-LocalGroupMember -Group 'Remote Desktop Users' -Member 'USERNAME'

# Session Collection erstellen (Domain mit Connection Broker)
New-RDSessionCollection `
    -CollectionName 'KMU-Desktop' `
    -SessionHost 'rdsh.domain.local' `
    -ConnectionBroker 'rdcb.domain.local'

# Benutzergruppen der Collection hinzufügen
Set-RDSessionCollectionConfiguration `
    -CollectionName 'KMU-Desktop' `
    -UserGroup 'DOMAIN\Domain Users' `
    -ConnectionBroker 'rdcb.domain.local'

Benutzer erhalten keine lokalen Administratorrechte auf dem Session Host.

Verifizieren: Ein Testbenutzer ohne Adminrechte meldet sich per mstsc am Session Host an und erhält einen Desktop. Im Domain-Szenario listet Get-RDSessionCollection -ConnectionBroker 'rdcb.domain.local' die Collection „KMU-Desktop“.

Schritt 7: RD Gateway einrichten (optional, für Internet-Zugriff)

Das RD Gateway ermöglicht RDP-Zugriff aus dem Internet über TCP/443 (HTTPS) und UDP/3391. Das SSL-Zertifikat muss öffentlich vertrauenswürdig sein, sein CN dem externen FQDN entsprechen.

# SSL-Zertifikate für RDS-Rollen zuweisen
$PfxPassword = ConvertTo-SecureString -String 'PfxPasswort' -AsPlainText -Force

Set-RDCertificate -Role RDGateway `
    -ImportPath 'C:\Certs\gateway.pfx' `
    -Password $PfxPassword `
    -ConnectionBroker 'rdcb.domain.local'

Set-RDCertificate -Role RDWebAccess `
    -ImportPath 'C:\Certs\rdweb.pfx' `
    -Password $PfxPassword `
    -ConnectionBroker 'rdcb.domain.local'

Set-RDCertificate -Role RDRedirector `
    -ImportPath 'C:\Certs\rdcb.pfx' `
    -Password $PfxPassword `
    -ConnectionBroker 'rdcb.domain.local'

Set-RDCertificate -Role RDPublishing `
    -ImportPath 'C:\Certs\rdcb.pfx' `
    -Password $PfxPassword `
    -ConnectionBroker 'rdcb.domain.local'

In KMU können RD Web Access und RD Gateway auf derselben VM laufen. Im RD Gateway Manager konfigurieren Sie danach CAP (Connection Authorization Policy) und RAP (Resource Authorization Policy).

Verifizieren: Ein externer Client verbindet sich über das Gateway (in mstsc unter Erweitert eingetragen) ohne Zertifikatswarnung. Get-RDCertificate -ConnectionBroker 'rdcb.domain.local' zeigt für alle Rollen den Status „Trusted“.

Schritt 8: Workgroup-Betrieb (ohne Active Directory)

Ohne Active Directory gilt:

Nur Per-Device-CALs: Per-User-CAL-Tracking setzt voraus, dass der Lizenzserver das AD-Attribut msTSManagingLS schreiben kann.
Die grafischen RDS-Verwaltungstools im Server Manager fehlen; Konfiguration nur per PowerShell, WMI oder lokaler GPO.
Session Host und Lizenzserver müssen sich per Name oder IP erreichen; ohne DNS beide Hostnamen in die HOSTS-Datei eintragen.
Auf beiden Servern müssen identische lokale Administratorkonten existieren.

Zwischen Session Host und Lizenzserver müssen offen sein: TCP/135 (RPC), UDP/137–138 (NetBIOS), TCP/139, TCP/445 (SMB) und TCP/49152–65535 (RPC dynamisch).

Mit Active Directory wechseln Sie auf Per-User-CALs und steuern RDS-Einstellungen per Gruppenrichtlinien.

Verifizieren: Test-NetConnection LIC-SERVER-NAME -Port 135 und -Port 445 vom Session Host liefern TcpTestSucceeded : True; der Lizenzserver ist per Name erreichbar.

Schritt 9: Karenzzeit prüfen und Lizenzstatus überwachen

# Verbleibende Karenzzeit (Grace Period) prüfen
(Invoke-CimMethod -InputObject (Get-CimInstance -Namespace root/CIMV2/TerminalServices `
    -ClassName Win32_TerminalServiceSetting) -MethodName GetGracePeriodDays).DaysLeft

# Installierte CAL-Pakete anzeigen
Get-WmiObject Win32_TSLicenseKeyPack | `
    Select-Object KeyPackId, ProductVersion, TypeAndModel, AvailableLicenses, IssuedLicenses | `
    Format-Table

# Per-Device-CAL widerrufen (bis 20 % der CALs widerrufbar)
$RevokedPCName = 'CLIENT-PC-NAME'
$licensepacks = Get-WmiObject win32_tslicensekeypack | `
    Where-Object { ($_.keypacktype -ne 0) -and ($_.keypacktype -ne 4) -and ($_.keypacktype -ne 6) }
$TSLicensesAssigned = Get-WmiObject win32_tsissuedlicense | `
    Where-Object { $_.licensestatus -eq 2 }
$RevokePC = $TSLicensesAssigned | Where-Object { $_.sIssuedToComputer -eq $RevokedPCName }
$RevokePC.Revoke()

Der RD Licensing Diagnoser (lsdiag.msc) zeigt Fehler und Warnungen zum Lizenzstatus. wmic ist ab Windows Server 2025 nur noch optionales Feature (Feature on Demand), daher nutzt der Befehl oben PowerShell.

Verifizieren: Get-WmiObject Win32_TSLicenseKeyPack zeigt bei IssuedLicenses ausgestellte CALs, und lsdiag.msc meldet einen aktivierten, erreichbaren Lizenzserver ohne Warnungen.

Troubleshooting / Typische Fehler

„The remote session was disconnected because there are no Remote Desktop client access licenses available for this computer.“ – Die 120-Tage-Grace-Period ist abgelaufen. Lizenzserver aktivieren, CALs installieren, mit lsdiag.msc Erreichbarkeit prüfen.
Lizenzserver ausgewählt, aber Verbindungen scheitern trotzdem nach Grace Period – Der Lizenzserver ist nicht explizit per GPO, WMI oder Registry eingetragen (Schritt 5). Prüfen mit $obj.GetSpecifiedLicenseServerList().
„The Remote Desktop license server is not activated“ in lsdiag.msc – Aktivierung über licmgr.exe nachholen (TCP/443 oder Telefon).
Per-User-CALs funktionieren nicht (Workgroup) – Ohne AD kann der Lizenzserver msTSManagingLS nicht setzen. Nur Per-Device-CALs funktionieren; einen Workaround gibt es nicht.
CALs werden ausgestellt, aber Session Host akzeptiert sie nicht – Das Computerkonto des Lizenzservers fehlt in der AD-Gruppe „Terminal Server License Servers“ (Builtin-Container). Hinzufügen und RDSH neu starten.
Windows Server 2025 Session Host, 2022-CALs werden abgelehnt – 2022-CALs gelten nicht auf einem 2025-Session-Host. Windows Server 2025 RDS CALs beschaffen und den Lizenzserver auf mindestens Windows Server 2025 aktualisieren.
Zertifikatswarnung beim RD Gateway – CN des Zertifikats passt nicht zum externen FQDN. Zertifikat mit korrektem CN ausstellen und per Set-RDCertificate zuweisen.
RDS-Deployment-Wizard fehlt im Server Manager (Workgroup) – Im Workgroup-Betrieb nicht verfügbar; PowerShell oder lokale Gruppenrichtlinie nutzen.

Häufige Fragen

Brauche ich für jeden Remote-Desktop-Nutzer eine RDS-CAL, auch wenn nur 2 gleichzeitig verbunden sind?

Ja. RDS-CALs sind keine Concurrent-Use-Lizenzen: 10 Benutzer, die nacheinander arbeiten, brauchen 10 Per-User-CALs, auch wenn nie mehr als 2 gleichzeitig verbunden sind. Ausnahme: 2 gleichzeitige Administrator-RDP-Verbindungen für Verwaltungszwecke sind kostenfrei (kein RDS-Feature).

Welche CAL-Variante ist besser für Schichtbetrieb?

Per-Device-CALs: 20 Mitarbeiter an 8 PCs brauchen 8 statt 20 CALs, etwa in Produktion, Pflege oder Gastronomie.

Funktioniert RDS auch ohne Active Directory (Workgroup)?

Ja, mit den Einschränkungen aus Schritt 8. Ab etwa 5 Benutzern lohnt sich eine Active-Directory-Domäne.

Muss ich neue CALs kaufen, wenn ich von Windows Server 2022 auf 2025 migriere?

Ja, siehe Troubleshooting: 2022-CALs gelten nicht auf einem 2025 Session Host, und der Lizenzserver muss mindestens Windows Server 2025 sein. Umgekehrt decken 2025-CALs auch ältere Session Hosts (2016, 2019, 2022) ab.

Was passiert, wenn der Lizenzserver nicht mehr erreichbar ist?

Neue RDP-Verbindungen werden mangels CALs abgelehnt. Bestehende Sitzungen bleiben je nach Konfiguration aktiv, nach dem Trennen aber nicht neu aufbaubar. Für geschäftskritische Server Hochverfügbarkeit einplanen.

Kann ich RDS auf einem Domain Controller betreiben?

Technisch möglich, von Microsoft aber nicht empfohlen; nötig sind etwa Druckerweiterleitungs-Berechtigungen per cacls.exe PRINTERS /e /g users:C. In Produktion aus Sicherheitsgründen nie einen Domain Controller als RDSH einsetzen.

Wie erkenne ich, ob Per-User-CALs still überschritten werden?

Technisch gar nicht: Bei Per-User-Lizenzierung gibt das System auch bei Überschreitung CALs aus (Overuse-Pool); der Verstoß fällt erst im Audit auf. Vergleichen Sie regelmäßig die im RD Licensing Manager ausgestellten CALs mit Ihrer Benutzerzahl.

Fazit

Entscheidend sind: Lizenzserver sofort aktivieren und explizit am Session Host eintragen, CAL-Variante passend wählen (Workgroup oder Schichtbetrieb = Per-Device, Domain mit festen Arbeitsplätzen = Per-User) und beim Upgrade auf Windows Server 2025 neue CALs und Lizenzserver einplanen. Mit PowerShell richten Sie den Stack ein und überwachen ihn; DHCP und DNS ergänzen das Server-Fundament.

Weiterführende Anleitungen und Quellen

Quellen: Microsoft Learn: Remote Desktop Services roles · Microsoft Learn: License RDS with Client Access Licenses (CALs) · Microsoft Learn: Deploy your Remote Desktop environment · Microsoft Learn: Install RDS role service without Connection Broker · Microsoft Learn: Activate the RDS license server · Windows OS Hub: Install and Activate RDS Licensing Role and CALs