Die Verwaltung eines Windows Server 2016 als Terminal-Server (oft auch als Remote Desktop Services – RDS Host bezeichnet) kann eine Herausforderung sein. Alles läuft reibungslos, bis plötzlich Benutzer keine Verbindung mehr herstellen können, Fehlermeldungen über abgelaufene Grace Periods auftauchen oder schlicht die Dienste versagen, weil die „Aktivierung” nicht stimmt. Diese hartnäckigen Probleme mit der Aktivierungs-ID oder genauer gesagt, mit der Lizenzierung von Remote Desktop Services, können IT-Administratoren und Systemingenieuren den letzten Nerv rauben. Aber keine Sorge, Sie sind nicht allein! In diesem umfassenden Leitfaden tauchen wir tief in die Materie ein und zeigen Ihnen, wie Sie diese lästigen Probleme nicht nur erkennen, sondern auch dauerhaft lösen können.
Oftmals führt der Begriff „Aktivierungs-ID” zu Verwirrung. Während die Server-Betriebssystem-Aktivierung ein separater Prozess ist, beziehen sich die meisten Probleme, die Benutzer in diesem Kontext erleben, auf die Lizenzierung der Remote Desktop Services (RDS CALs). Wenn der RDS-Sitzungshost keine gültige Lizenz für einen Benutzer oder ein Gerät finden kann, greift er auf eine Kulanzperiode (Grace Period) zurück. Läuft diese ab, können keine neuen Verbindungen mehr aufgebaut werden, und bestehende Verbindungen werden möglicherweise getrennt. Unser Ziel ist es, diese zugrundeliegenden Lizenzierungsprobleme zu identifizieren und zu beheben.
Was ist der Kern des Problems? Die RDS-Lizenzierung verstehen
Bevor wir uns in die Fehlersuche stürzen, ist es entscheidend, die Grundlagen der RDS-Lizenzierung auf Server 2016 zu verstehen. Ein RDS-Deployment besteht in der Regel aus mehreren Rollen:
- RD-Sitzungshost (RD Session Host): Dies ist der Server, auf dem die Benutzeranwendungen ausgeführt werden und zu dem sich die Benutzer verbinden.
- RD-Lizenzserver (RD Licensing Server): Dieser Server ist für die Verwaltung und Ausgabe von RDS-Clientzugriffslizenzen (CALs) verantwortlich. Ohne einen korrekt konfigurierten Lizenzserver können Benutzer nach Ablauf der Kulanzperiode keine Verbindung herstellen.
- RD-Verbindungsbroker (RD Connection Broker): Dieser verteilt Benutzeranfragen auf mehrere RD-Sitzungshosts und verwaltet bestehende Sitzungen.
- Weitere Rollen wie RD-Web Access und RD-Gateway können ebenfalls Teil des Deployments sein.
Die RDS CALs müssen auf dem RD-Lizenzserver installiert und aktiviert werden. Der RD-Sitzungshost wiederum muss so konfiguriert sein, dass er weiß, wo er den Lizenzserver findet, und in welchem Lizenzierungsmodus er arbeitet (pro Benutzer oder pro Gerät).
Symptome hartnäckiger Aktivierungs-ID-Probleme
Die Anzeichen für Lizenzierungs- oder „Aktivierungs-ID”-Probleme sind vielfältig und oft frustrierend:
- Benutzer können sich nicht mit dem Terminal-Server verbinden.
- Beim Versuch der Verbindung erscheint eine Fehlermeldung wie „Die Remote Desktop Lizenzierungs-Kulanzperiode ist abgelaufen…” (The remote desktop licensing grace period has expired…).
- Im Ereignisprotokoll des RD-Sitzungshosts finden sich Warnungen oder Fehler bezüglich der Lizenzierung (z.B. Event ID 1127, 4105, 4106, 20202).
- Der Lizenzierungsstatus wird in den RDS-Deployment-Eigenschaften als rot oder fehlerhaft angezeigt.
- Benutzer, die bereits verbunden sind, werden möglicherweise nach einer bestimmten Zeit getrennt.
Die Standard-Checks: Bevor Sie tief graben
Bevor wir zu den fortgeschrittenen Techniken übergehen, sollten Sie die grundlegenden Konfigurationen überprüfen. Oft liegt der Fehler in einer einfachen Fehleinstellung:
- Prüfung der Lizenzserver-Konfiguration auf dem RD-Sitzungshost:
- Öffnen Sie den Server-Manager auf dem RD-Sitzungshost.
- Navigieren Sie zu „Remotedesktopdienste” -> „Übersicht” -> „Bereitstellungsübersicht”.
- Klicken Sie auf „Aufgaben” -> „Bereitstellungseigenschaften bearbeiten”.
- Wählen Sie im linken Bereich „RD-Lizenzierung”.
- Stellen Sie sicher, dass der korrekte Lizenzierungsmodus (pro Benutzer oder pro Gerät) ausgewählt ist und dass der RD-Lizenzserver korrekt angegeben ist. Fügen Sie ihn ggf. manuell hinzu. Es ist wichtig, dass der hier eingetragene Server der tatsächliche Lizenzserver in Ihrem Netzwerk ist und über die entsprechenden RDS CALs verfügt.
Tipp: Oftmals hilft es, den Lizenzierungsmodus zu wechseln (z.B. von Pro Benutzer auf Pro Gerät und zurück) und den Lizenzserver neu einzutragen, um die Einstellungen zu aktualisieren.
- Überprüfung der CALs auf dem Lizenzserver:
- Öffnen Sie den Remotedesktoplizenzierungs-Manager (rdlicensing.msc) auf dem RD-Lizenzserver.
- Stellen Sie sicher, dass der Lizenzserver aktiviert ist und die erforderlichen RDS CALs installiert und verfügbar sind. Überprüfen Sie das Gültigkeitsdatum der Lizenzen.
- Netzwerk und DNS-Auflösung:
- Kann der RD-Sitzungshost den Lizenzserver über seinen Hostnamen erreichen? Testen Sie dies mit
pingundnslookup. - Gibt es Firewall-Regeln, die die Kommunikation zwischen dem RD-Sitzungshost und dem Lizenzserver blockieren? Die Kommunikation erfolgt typischerweise über Port 135 (RPC) und dynamische RPC-Ports.
- Kann der RD-Sitzungshost den Lizenzserver über seinen Hostnamen erreichen? Testen Sie dies mit
- Datum und Uhrzeit:
- Eine falsche Systemzeit auf einem der Server (insbesondere dem Lizenzserver oder dem Sitzungshost) kann zu Lizenzierungsproblemen führen. Stellen Sie sicher, dass die Zeit über NTP synchronisiert wird.
Tiefere Fehlersuche: Wenn die Basics nicht helfen
Wenn die einfachen Checks keine Lösung bringen, müssen wir tiefer graben. Hier kommen oft hartnäckige Probleme zum Vorschein, die besondere Aufmerksamkeit erfordern.
1. Registry-Hacks: Die Gnadenfrist zurücksetzen (Vorsicht geboten!)
Ein häufiges Problem ist das Ablaufen der Grace Period, selbst wenn die Lizenzen korrekt erscheinen. Microsoft sieht vor, dass Sie die Grace Period durch korrekt installierte Lizenzen beenden. Manchmal jedoch hängt sich das System auf. Eine temporäre „Lösung” (eher ein Workaround) ist das Zurücksetzen der Kulanzperiode über die Registry. Dies behebt NICHT das zugrunde liegende Lizenzierungsproblem, sondern verschafft Ihnen lediglich Zeit.
- Öffnen Sie den Registrierungs-Editor (
regedit) auf dem RD-Sitzungshost. - Navigieren Sie zu:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerRCMGracePeriod. - WICHTIG: Erstellen Sie vor Änderungen ein Backup dieses Schlüssels! Exportieren Sie ihn.
- Suchen Sie den Wert
L$00409(oder einen ähnlichen benannten Binärwert, der oft schwer zu identifizieren ist, da er als Hexadezimalwert gespeichert ist und nicht direkt lesbar ist). Dieser Wert enthält das Ablaufdatum der Grace Period. - Löschen Sie diesen Binärwert (nicht den Schlüssel
GracePeriodselbst!). - Starten Sie den RD-Sitzungshost neu.
Nach dem Neustart sollte die Grace Period für 120 Tage neu starten. Nutzen Sie diese Zeit unbedingt, um das eigentliche Lizenzierungsproblem zu beheben! Wenn der Binärwert nicht existiert, könnte das Problem woanders liegen.
2. Analyse der Ereignisprotokolle
Die Ereignisanzeige ist Ihr bester Freund bei der Fehlersuche. Konzentrieren Sie sich auf die folgenden Protokolle auf dem RD-Sitzungshost und dem RD-Lizenzserver:
- RD-Sitzungshost (Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> TerminalServices-Licensing / TerminalServices-SessionBroker):
- Event ID 1127: Zeigt an, dass der RD-Sitzungshost keine Lizenz für einen Benutzer finden konnte und die Grace Period nutzt.
- Event ID 4105/4106: Probleme bei der Verbindung zum Lizenzserver oder beim Abrufen einer Lizenz.
- Event ID 20202: Fehler bei der Lizenzserver-Erkennung.
- RD-Lizenzserver (Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> TerminalServices-Licensing):
- Überprüfen Sie, ob der Lizenzserver ordnungsgemäß funktioniert, Lizenzen ausgibt und ob es Fehler bei der Kommunikation mit anderen Servern gibt.
3. Den Lizenzserver neu registrieren/konfigurieren
Manchmal verliert der RD-Sitzungshost die Verbindung oder die korrekte Referenz zum Lizenzserver. Auch wenn im Server-Manager alles korrekt aussieht, können interne Fehler bestehen:
- Verwenden Sie das PowerShell-Cmdlet:
Set-RDSessionHost -SessionHost <RDSH_Hostname> -LicenseServer <LicenseServer_Hostname> -LicenseMode PerUser(oderPerDevice). - Prüfen Sie auch über die lokale Gruppenrichtlinie des RD-Sitzungshosts:
gpedit.msc-> „Computerkonfiguration” -> „Administrative Vorlagen” -> „Windows-Komponenten” -> „Remotedesktopdienste” -> „Remotedesktop-Sitzungshost” -> „Lizenzierung”. Stellen Sie sicher, dass die Einstellungen hier korrekt sind oder nicht mit globalen GPOs kollidieren.
4. Gruppenrichtlinien (GPOs) prüfen
GPOs können die lokalen Einstellungen überschreiben und sind eine häufige Ursache für Lizenzierungsprobleme. Überprüfen Sie auf Domain-Ebene, ob GPOs existieren, die die Lizenzierungseinstellungen für Ihre RD-Sitzungshosts festlegen:
- Verwenden Sie
gpresult /rauf dem RD-Sitzungshost, um alle angewendeten GPOs zu sehen. - Nutzen Sie den Gruppenrichtlinienverwaltungs-Editor, um die spezifischen Einstellungen unter „Computerkonfiguration” -> „Richtlinien” -> „Administrative Vorlagen” -> „Windows-Komponenten” -> „Remotedesktopdienste” -> „Remotedesktop-Sitzungshost” -> „Lizenzierung” zu prüfen.
Stellen Sie sicher, dass hier der korrekte Lizenzserver und der passende Lizenzierungsmodus konfiguriert sind. Im Zweifelsfall kann es helfen, die GPO-Einstellungen zu deaktivieren oder zu entfernen, um zu sehen, ob das Problem behoben wird, und sie dann sauber neu zu konfigurieren.
5. WMI-Probleme
Manchmal können Beschädigungen im WMI (Windows Management Instrumentation) Repository die korrekte Funktion von RDS-Diensten und deren Lizenzierung beeinträchtigen. Dies ist seltener, aber ein hartnäckiges Problem.
- Überprüfen Sie die Integrität des WMI-Repositorys mit
winmgmt /verifyrepositoryin einer Admin-CMD. - Sollte es beschädigt sein, kann ein Neuaufbau des Repositorys erforderlich sein. Achtung: Dies ist ein gravierender Schritt und sollte nur als letzter Ausweg mit einem vorherigen System-Backup in Betracht gezogen werden! Anleitungen dazu finden Sie in der Microsoft-Dokumentation.
6. Firewall-Einstellungen und Netzwerkports
Auch wenn bereits erwähnt, ist dies oft eine Falle: Stellen Sie sicher, dass auf allen involvierten Servern (RD-Sitzungshost, RD-Lizenzserver, Domänencontroller) die notwendigen Ports geöffnet sind.
- Port 135 (TCP): Für RPC Endpoint Mapper.
- Dynamische RPC-Ports (1024-65535 TCP): Für die eigentliche RPC-Kommunikation. Sie können auch einen spezifischen Portbereich für RPC konfigurieren, um die Firewall-Regeln zu vereinfachen, aber dies ist komplexer.
- Stellen Sie sicher, dass der Netzwerkprofil auf dem Server korrekt ist (Domänennetzwerk, nicht Öffentlich).
Tools und Befehle für die Fehlersuche
Hier sind einige nützliche Befehle und Tools, die Ihnen bei der Fehlersuche helfen können:
rdlicensing.msc: Der Remotedesktoplizenzierungs-Manager.gpresult /r: Zeigt die auf den Server angewendeten Gruppenrichtlinien.dcdiag: Prüft die Gesundheit des Domänencontrollers, wichtig für die Authentifizierung und Lizenzserver-Registrierung.nltest /dsgetdc:<DomainName>: Überprüft, ob der Server einen Domänencontroller finden kann.Get-RDSessionHostundSet-RDSessionHost(PowerShell): Zum Abrufen und Setzen von RDS-Host-Eigenschaften.Get-RDLicenseConfiguration(PowerShell): Zeigt die Lizenzierungskonfiguration.Test-NetConnection -ComputerName <LicenseServer> -Port 135(PowerShell): Überprüft die Konnektivität zum Lizenzserver auf Port 135.
Prävention ist der beste Schutz
Nachdem Sie die hartnäckigen Probleme geknackt haben, ist es wichtig, zukünftige Vorkommnisse zu vermeiden:
- Regelmäßige Überprüfung: Planen Sie regelmäßige Checks der RDS-Lizenzierung auf allen Servern ein.
- Dokumentation: Dokumentieren Sie Ihre RDS-Bereitstellung, einschließlich Lizenzserver, Lizenzmodus und CAL-Informationen.
- Überwachung: Implementieren Sie eine Überwachung für kritische Ereignis-IDs (siehe oben) im Zusammenhang mit der RDS-Lizenzierung.
- CAL-Verwaltung: Stellen Sie sicher, dass Sie immer genügend RDS CALs haben und diese rechtzeitig erneuern.
- Testumgebung: Testen Sie wichtige Änderungen in einer Testumgebung, bevor Sie sie in der Produktion implementieren.
Fazit
Probleme mit der „Aktivierungs-ID” auf Server 2016 als Terminal-Server sind fast immer Probleme mit der korrekten Erkennung und Anwendung von Remote Desktop Services CALs. Von der grundlegenden Konfiguration über das Debugging von Netzwerkproblemen bis hin zu tiefen Registry-Eingriffen – der Weg zur Lösung kann steinig sein. Doch mit den hier vorgestellten Schritten und einem systematischen Ansatz können Sie diese hartnäckigen Herausforderungen meistern. Denken Sie daran: Geduld, eine methodische Fehlersuche und ein gutes Verständnis der RDS-Lizenzierungsarchitektur sind Ihre besten Verbündeten. Indem Sie die Ursache beheben und nicht nur die Symptome unterdrücken, stellen Sie sicher, dass Ihr Terminal-Server reibungslos und zuverlässig läuft.