Zum Hauptinhalt springen
S-EDV news
← Alle Anleitungen
📘 Anleitung Windows Server 04.06.2026 · 11 min Lesezeit

Remote Desktop Services einrichten und lizenzieren: Terminalserver für KMU

Schritt für Schritt RDS auf Windows Server 2022/2025 aufsetzen: Rollen installieren, Lizenzserver aktivieren, Per-User vs. Per-Device-CALs richtig wählen – inklusive Workgroup-Betrieb und der 120-Tage-Karenzzeit-Falle.

Serverraum mit leuchtendem Rack und holografischer Verbindungsübersicht für Remote Desktop Services

Remote Desktop Services (RDS) ist die Windows-Server-Technologie, mit der mehrere Benutzer gleichzeitig auf einen zentralen Server zugreifen und dort Desktops oder Applikationen nutzen können – der klassische Terminalserver für KMU. Wer RDS falsch aufsetzt oder die Lizenzierung vernachlässigt, landet nach 120 Tagen vor verschlossenen Türen. Diese Anleitung zeigt dir, wie du RDS korrekt installierst, den Lizenzserver aktivierst, die richtige CAL-Variante wählst und typische Fallen von Anfang an vermeidest.

Voraussetzungen

  • Windows Server 2022 oder 2025 (Standard oder Datacenter) auf allen Servern, auf denen RDS-Rollen laufen sollen
  • RDS Client Access Licenses (CALs) in der passenden Version (Per-User oder Per-Device), abgestimmt auf die Windows-Server-Version des Session Hosts
  • Für RD Gateway: öffentlich vertrauenswürdiges SSL-Zertifikat (.pfx) mit dem externen FQDN als Common Name
  • Für HA Connection Broker: SQL Server-Instanz (oder Azure SQL) für die Sitzungsdatenbank
  • Mindestens 2 CPU-Kerne und 4 GB RAM pro gleichzeitiger Benutzersitzung – je nach Applikationslast mehr
  • Internetzugang auf dem Lizenzserver (TCP/443) für Online-Aktivierung, alternativ https://activate.microsoft.com
  • Alle beteiligten Server müssen sich gegenseitig per Hostname auflösen können (DNS oder HOSTS-Datei)
  • Administratorkonto mit Domain-Admin-Rechten (Domain-Szenario) oder lokales Administratorkonto (Workgroup)

Schritt 1: RDS-Rollen verstehen und planen

Bevor du mit der Installation beginnst, solltest du wissen, welche der fünf RDS-Rollen du brauchst:

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

Für ein typisches KMU-Kleinstdeployment mit 5–15 Benutzern reicht ein einzelner Server mit RDSH + RDL. Den Connection Broker brauchst du erst, wenn du mehrere Session Hosts betreibst.

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

Die Wahl des Lizenzierungsmodells ist eine der wichtigsten Entscheidungen – und lässt sich nachträglich nur mit Aufwand ändern. Die folgende Tabelle hilft bei der Entscheidung:

KriteriumPer-User-CALPer-Device-CAL
BindungAn Benutzer-Account (beliebig viele Geräte)An Gerät (beliebig viele Benutzer)
Active Directory nötig?Ja (Pflicht)Nein (auch Workgroup)
Schichtbetrieb empfohlen?NeinJa
Widerrufbar?NeinJa (bis 20 % der CALs)
ReassignmentErst nach 90 TagenTemporäre CAL: 90 Tage; permanente CAL: alle 52–89 Tage erneuert
Overuse-SchutzKein 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 je einem festen Arbeitsplatz und Active Directory → 10 Per-User-CALs.

Schritt 3: RDS-Rollen installieren

Im Domain-Szenario empfiehlt sich der Server Manager Wizard über „Remote Desktop Services-Installation". Damit kennt der Connection Broker alle Rollen von Anfang an. Im Workgroup-Betrieb oder für minimale Deployments verwendest du PowerShell direkt.

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: Wähle im Server Manager immer „Remote Desktop Services-Installation" → „Standardbereitstellung", nie die rollenbasierte Installation. Letztere installiert die Rollen technisch, aber der Connection Broker erfährt nichts davon – das Deployment ist dann unvollständig.

Schritt 4: Lizenzserver aktivieren

Den Lizenzserver sofort nach der Installation aktivieren – nicht erst wenn die Karenzzeit abläuft. Öffne den Remote Desktop Licensing Manager (licmgr.exe), klicke mit der rechten Maustaste auf den Server und wähle „Server aktivieren". Online-Aktivierung erfolgt automatisch über TCP/443 zum Microsoft Clearinghouse. Ohne Internetzugang nutze https://activate.microsoft.com (Webbrowser-Methode) oder die Telefonaktivierung.

Nach der Serveraktivierung installierst du die CAL-Pakete ebenfalls im Licensing Manager: Rechtsklick auf den aktivierten Server → „Lizenzen installieren" → Produktschlüssel eingeben.

Schritt 5: Lizenzserver am Session Host konfigurieren

Ab Windows Server 2008 R2 funktioniert die automatische Lizenzserver-Erkennung nicht mehr zuverlässig. Du musst den Lizenzserver explizit angeben.

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)

Öffne die Group Policy Management Console (gpmc.msc) und navigiere zu: Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Licensing. Aktiviere dort „Use the specified Remote Desktop license servers" und „Set the Remote Desktop licensing mode".

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 dürfen keine lokalen Administratorrechte auf dem Session Host haben – reguläre Sitzungen gehören in Non-Admin-Konten. Das Administrator-Konto ist ausschließlich für Verwaltungsaufgaben reserviert.

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

Das RD Gateway ermöglicht sicheren RDP-Zugriff aus dem Internet über TCP/443 (HTTPS) und UDP/3391. Du benötigst ein öffentlich vertrauenswürdiges SSL-Zertifikat, dessen CN dem externen FQDN entspricht.

# 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'

Für KMU lässt sich RD Web Access zusammen mit RD Gateway auf derselben VM betreiben – das spart Lizenz- und Betriebskosten. Im RD Gateway Manager konfigurierst du anschließend CAP (Connection Authorization Policy) und RAP (Resource Authorization Policy).

Schritt 8: Workgroup-Betrieb (ohne Active Directory)

Ohne Active Directory gelten besondere Einschränkungen, die du kennen musst:

  • Ausschließlich Per-Device-CALs werden unterstützt – Per-User-CAL-Tracking setzt voraus, dass der Lizenzserver das AD-Attribut msTSManagingLS schreiben kann.
  • Die grafischen RDS-Verwaltungstools im Server Manager stehen nicht zur Verfügung – Konfiguration nur per PowerShell, WMI oder lokaler GPO.
  • Session Host und Lizenzserver müssen sich gegenseitig per Name oder IP erreichen; trag beide Hostnamen in die HOSTS-Datei ein, falls kein DNS vorhanden ist.
  • Auf beiden Servern müssen identische lokale Administratorkonten existieren, damit die Lizenzserver-Kommunikation funktioniert.

Für die Kommunikation zwischen Session Host und Lizenzserver müssen diese Ports offen sein: TCP/135 (RPC), UDP/137–138 (NetBIOS), TCP/139, TCP/445 (SMB) und TCP/49152–65535 (RPC dynamisch).

Wenn du Active Directory bereits betreibst oder einrichten möchtest, wechsle auf Per-User-CALs – das vereinfacht die Benutzerverwaltung erheblich und gibt dir volle Kontrolle über Gruppenrichtlinien für RDS-Einstellungen.

Schritt 9: Karenzzeit prüfen und Lizenzstatus überwachen

# Verbleibende Karenzzeit (Grace Period) prüfen
wmic /namespace:\\root\CIMV2\TerminalServices PATH Win32_TerminalServiceSetting `
    WHERE (__CLASS !='') CALL GetGracePeriodDays

# 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()

Öffne zusätzlich den RD Licensing Diagnoser (lsdiag.msc) – er zeigt Fehler und Warnungen zum Lizenzierungsstatus direkt an und ist das wichtigste Diagnosetool bei Verbindungsproblemen.

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. Sofort Lizenzserver aktivieren und CALs installieren. Prüfe mit lsdiag.msc, ob der Lizenzserver erreichbar und aktiviert ist.
  • Lizenzserver ausgewählt, aber Verbindungen scheitern trotzdem nach Grace Period – Auto-Discovery ist deaktiviert, der Lizenzserver wurde nicht explizit per GPO, WMI oder Registry eingetragen. Prüfe mit $obj.GetSpecifiedLicenseServerList(), ob der Server wirklich eingetragen ist.
  • „The Remote Desktop license server is not activated" in lsdiag.msc – Lizenzserver ist installiert, aber nicht aktiviert. Aktivierung über licmgr.exe durchführen; erfordert TCP/443-Zugang oder Telefonaktivierung.
  • Per-User-CALs funktionieren nicht (Workgroup) – In einer Workgroup kann der Lizenzserver das AD-Attribut msTSManagingLS nicht setzen. Wechsel zwingend auf Per-Device-CALs; es gibt keine Workaround-Option.
  • CALs werden ausgestellt, aber Session Host akzeptiert sie nicht – Das Computerkonto des Lizenzservers fehlt in der AD-Gruppe „Terminal Server License Servers" (im Builtin-Container). Mitgliedschaft hinzufügen und RDSH neu starten.
  • Windows Server 2025 Session Host, 2022-CALs werden abgelehnt – 2022-CALs sind auf einem 2025-Session-Host ungültig. Neue Windows Server 2025 RDS CALs kaufen und den Lizenzserver auf mindestens Windows Server 2025 aktualisieren.
  • Zertifikatswarnung beim RD Gateway – CN des SSL-Zertifikats stimmt nicht mit dem externen FQDN überein. Neues Zertifikat mit korrektem CN ausstellen und über Set-RDCertificate zuweisen.
  • RDS-Deployment-Wizard fehlt im Server Manager (Workgroup) – Im Workgroup-Betrieb nicht verfügbar. Alle Konfigurationen per PowerShell oder lokaler Gruppenrichtlinie vornehmen.

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, sondern Named-User- (Per-User) oder Named-Device-Lizenzen (Per-Device). Bei 10 Benutzern, die nacheinander den Server nutzen, werden 10 Per-User-CALs benötigt – auch wenn nie mehr als 2 gleichzeitig verbunden sind. Ausnahme: Windows Server bietet immer 2 gleichzeitige Administrator-RDP-Verbindungen kostenfrei für Verwaltungszwecke (kein RDS-Feature).

Welche CAL-Variante ist besser für Schichtbetrieb?

Per-Device-CALs. Wenn 20 Mitarbeiter sich 8 PCs teilen, reichen 8 Per-Device-CALs statt 20 Per-User-CALs. Die CAL wird dem Gerät zugewiesen – perfekt für Schichtmodelle in Produktion, Pflege oder Gastronomie.

Funktioniert RDS auch ohne Active Directory (Workgroup)?

Ja, mit erheblichen Einschränkungen: Nur Per-Device-CALs werden unterstützt, die grafischen Server-Manager-RDS-Tools fehlen, und auf Session Host sowie Lizenzserver müssen identische lokale Administratorkonten existieren. Für mehr als 5 Benutzer lohnt sich der Aufbau einer Active-Directory-Domäne.

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

Ja. Windows Server 2022 CALs sind auf einem 2025 Session Host ungültig. Du musst Windows Server 2025 RDS CALs erwerben und außerdem den Lizenzserver auf mindestens Windows Server 2025 aktualisieren – ein 2022-Lizenzserver kann keine 2025-CALs ausstellen. Umgekehrt gilt: 2025-CALs decken auch ältere Session Hosts (2016, 2019, 2022) ab.

Was passiert, wenn der Lizenzserver nicht mehr erreichbar ist?

Neue RDP-Verbindungen werden abgelehnt mit der Meldung, dass keine CALs verfügbar sind. Bestehende Sitzungen können je nach Konfiguration aktiv bleiben, lassen sich nach dem Trennen aber nicht neu aufbauen. Plane daher Hochverfügbarkeit ein, wenn der Server geschäftskritisch ist.

Kann ich RDS auf einem Domain Controller betreiben?

Technisch möglich, aber von Microsoft nicht empfohlen. Bei dieser Konfiguration müssen zusätzliche Schritte ausgeführt werden, zum Beispiel Druckerweiterleitungs-Berechtigungen per cacls.exe PRINTERS /e /g users:C. Aus Sicherheitsgründen sollte ein Domain Controller niemals als RDSH in der Produktion eingesetzt werden.

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

Bei Per-User-Lizenzierung gibt es keinen technischen Stopp. Das System gibt CALs auch bei Überschreitung aus (Overuse-Pool) – ein Compliance-Verstoß, der erst beim Lizenz-Audit auffällt. Prüfe regelmäßig im RD Licensing Manager, wie viele CALs ausgestellt wurden, und vergleiche das mit der Anzahl deiner Benutzer.

Fazit

RDS ist für KMU eine bewährte und kostengünstige Lösung für zentralisierten Mehrbenutzer-Fernzugriff – vorausgesetzt, Lizenzierung und Konfiguration stimmen von Anfang an. Die wichtigsten Punkte: Den Lizenzserver sofort nach der Rolleninstallation aktivieren, ihn explizit am Session Host eintragen (Auto-Discovery ist nicht zuverlässig), die CAL-Variante sorgfältig wählen (Workgroup = Per-Device, Schichtbetrieb = Per-Device, Domain + feste Arbeitsplätze = Per-User), und beim Upgrade auf Windows Server 2025 rechtzeitig neue CALs und einen neuen Lizenzserver einplanen. Mit PowerShell lässt sich der gesamte Stack zuverlässig einrichten und überwachen – DHCP und DNS auf Windows Server runden das Server-Fundament ab.

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