In-place Upgrade für einen RDS – Terminalserver: Was Sie bei den RDS-CALs beachten müssen

Die Welt der Remote Desktop Services (RDS) ist komplex, und ein *In-place Upgrade* eines bestehenden RDS-Terminalservers kann sich wie ein Minenfeld anfühlen, insbesondere wenn es um die korrekte Handhabung von Client Access Licenses (CALs) geht. Viele Administratoren sind von der vermeintlichen Einfachheit eines In-place Upgrades verführt: Es verspricht, die bestehende Konfiguration zu erhalten und den Aufwand eines Neuaufbaus zu vermeiden. Doch gerade bei RDS-Umgebungen lauern hier Fallstricke, die ohne sorgfältige Planung zu Compliance-Problemen, unerwarteten Kosten oder gar einem Ausfall des Dienstes führen können.

In diesem umfassenden Artikel beleuchten wir, was ein In-place Upgrade für einen RDS-Server bedeutet, welche spezifischen Herausforderungen es mit sich bringt und vor allem, wie Sie die **RDS-CALs** korrekt handhaben, um rechtliche und technische Schwierigkeiten zu vermeiden. Unser Ziel ist es, Ihnen einen detaillierten Leitfaden an die Hand zu geben, der Sie sicher durch diesen Prozess führt.

### Was ist ein In-place Upgrade für einen RDS-Terminalserver?

Ein **In-place Upgrade** (auch als Direkt-Upgrade bezeichnet) ist der Prozess, bei dem das Betriebssystem eines Servers auf eine neuere Version aktualisiert wird, ohne den Server neu zu installieren. Nehmen wir an, Sie betreiben einen **Windows Server 2016** als RDS-Sitzungshost (Terminalserver) und möchten ihn auf **Windows Server 2019** oder **Windows Server 2022** aktualisieren. Anstatt eine neue VM oder einen neuen physischen Server mit der neuen Betriebssystemversion aufzusetzen und alle Anwendungen, Daten und Konfigurationen zu migrieren, führen Sie das Upgrade direkt auf dem bestehenden System durch.

**Vorteile (auf den ersten Blick):**
* **Weniger Neuinstallationen:** Bestehende Anwendungen und Daten sollen erhalten bleiben.
* **Geringerer Migrationsaufwand:** Es entfällt die Notwendigkeit, Profile oder Anwendungsdaten manuell zu verschieben.
* **Kürzere Downtime (vermeintlich):** Der Server soll nur für die Dauer des Upgrade-Prozesses offline sein.

**Nachteile und Risiken (die oft übersehen werden):**
* **Rückstände alter Konfigurationen:** Das System kann durch alte Treiber, Registry-Einträge oder Dienste destabilisiert werden.
* **Inkompatibilitäten:** Nicht alle Anwendungen oder Treiber sind mit der neueren Serverversion kompatibel und können nach dem Upgrade Probleme verursachen.
* **Fehleranfälligkeit:** Der Upgrade-Prozess selbst kann fehlschlagen und den Server in einem unbrauchbaren Zustand hinterlassen.
* **Komplexität bei RDS:** Speziell bei RDS-Rollen wie dem Sitzungshost, dem Lizenzserver oder dem Broker können Versionsinkompatibilitäten gravierende Auswirkungen haben.
* **Der wichtigste Punkt: RDS-CALs.** Hier liegt die größte Stolperfalle.

Gerade der letzte Punkt, die **RDS-CALs**, ist der entscheidende Faktor, der ein In-place Upgrade eines RDS-Servers zu einer potenziell teuren und riskanten Angelegenheit macht.

### Die Grundlagen von RDS-CALs: Warum sie so wichtig sind

**RDS-CALs** (Remote Desktop Services Client Access Licenses) sind Lizenzen, die benötigt werden, damit Benutzer oder Geräte auf die Funktionalität eines **RDS-Sitzungshosts** zugreifen können. Anders ausgedrückt: Ohne die passenden CALs können sich Ihre Benutzer nicht mit dem Terminalserver verbinden und dessen Ressourcen nutzen.

Es gibt zwei Haupttypen von RDS-CALs:
1. **RDS Per User CALs:** Lizenzieren einen bestimmten Benutzer, der sich von beliebig vielen Geräten mit dem RDS-Sitzungshost verbinden kann. Dies ist oft die flexiblere und beliebtere Wahl in Umgebungen, in denen Benutzer mehrere Geräte nutzen oder in Schichten arbeiten.
2. **RDS Per Device CALs:** Lizenzieren ein bestimmtes Gerät, von dem aus sich beliebig viele Benutzer mit dem RDS-Sitzungshost verbinden können. Diese Option ist sinnvoll, wenn beispielsweise mehrere Benutzer einen gemeinsamen Arbeitsplatzrechner nutzen (z.B. in Callcentern oder Produktionsstätten).

Der **RDS-Lizenzserver** (RD Licensing Server) ist die zentrale Komponente in Ihrer RDS-Infrastruktur, die diese CALs verwaltet, ausgibt und überwacht. Er stellt sicher, dass jede Verbindung ordnungsgemäß lizenziert ist. Ohne einen funktionierenden und korrekt konfigurierten Lizenzserver kann ein RDS-Sitzungshost nur für eine begrenzte Zeit (oft 120 Tage) im sogenannten „Gnadenzeitraum” (Grace Period) betrieben werden, bevor er den Dienst verweigert.

### Die goldene Regel der RDS-CAL-Kompatibilität

Dies ist der absolut wichtigste Punkt, den Sie verstehen müssen:

**RDS-CALs sind versionsspezifisch.**

Das bedeutet: Eine **RDS-CAL** muss für dieselbe Version oder eine neuere Version des Windows Server-Betriebssystems ausgestellt sein, auf dem der **RDS-Sitzungshost** läuft.

* Wenn Ihr RDS-Sitzungshost auf **Windows Server 2016** läuft, benötigen Sie **Windows Server 2016 RDS-CALs** (oder neuere, die aber für diese Version nicht relevant sind).
* Wenn Ihr RDS-Sitzungshost auf **Windows Server 2019** läuft, benötigen Sie **Windows Server 2019 RDS-CALs** (oder neuere, z.B. 2022). **Windows Server 2016 RDS-CALs funktionieren NICHT!**
* Wenn Ihr RDS-Sitzungshost auf **Windows Server 2022** läuft, benötigen Sie **Windows Server 2022 RDS-CALs**. **Windows Server 2019 oder 2016 RDS-CALs funktionieren NICHT!**

Diese Regel ist unumstößlich und wird vom **RDS-Lizenzserver** rigoros durchgesetzt.

### In-place Upgrade des RDS-Sitzungshosts: Die CAL-Herausforderung

Stellen Sie sich vor, Sie haben einen **Windows Server 2016 RDS-Sitzungshost** mit entsprechend vielen **Windows Server 2016 RDS Per User CALs**, die auf einem **Windows Server 2016 RDS-Lizenzserver** installiert sind. Sie entscheiden sich für ein In-place Upgrade des **Sitzungshosts** auf **Windows Server 2019**.

Was passiert?
1. Nach dem erfolgreichen Upgrade läuft Ihr RDS-Sitzungshost nun auf **Windows Server 2019**.
2. Die Benutzer versuchen, sich zu verbinden.
3. Der RDS-Sitzungshost fordert vom **RDS-Lizenzserver** **Windows Server 2019 RDS-CALs** an.
4. Der **RDS-Lizenzserver** (der noch auf Windows Server 2016 läuft und nur 2016er CALs installiert hat) kann **KEINE Windows Server 2019 RDS-CALs** ausstellen.
5. Ergebnis: Nach Ablauf der 120-tägigen Gnadenfrist können sich Ihre Benutzer nicht mehr mit dem RDS-Sitzungshost verbinden.

**Der RDS-Lizenzserver selbst hat ebenfalls eine Versionskompatibilität:**
Ein **RDS-Lizenzserver** kann CALs für *seine eigene Version oder frühere Versionen* von RDS-Sitzungshosts ausstellen. Er kann **KEINE CALs für neuere Versionen** ausstellen, als die Version, auf der er selbst läuft.

* Ein **Windows Server 2019 RDS-Lizenzserver** kann **2016er und 2019er CALs** hosten und ausstellen.
* Ein **Windows Server 2016 RDS-Lizenzserver** kann **NUR 2016er CALs** hosten und ausstellen. Er kann KEINE 2019er CALs ausstellen.

Das bedeutet, ein In-place Upgrade Ihres RDS-Sitzungshosts von 2016 auf 2019 erfordert nicht nur den Kauf neuer **Windows Server 2019 RDS-CALs**, sondern auch, dass Ihr **RDS-Lizenzserver** *mindestens* auf **Windows Server 2019** läuft, um diese neuen CALs überhaupt hosten und verwalten zu können.

### Die Rolle von Software Assurance (SA)

**Software Assurance (SA)** ist ein Microsoft-Programm, das zusätzliche Vorteile bietet, darunter das Recht auf Upgrades auf neuere Softwareversionen, technische Unterstützung und flexible Lizenzierungsoptionen.

Wenn Ihre **RDS-CALs** unter **Software Assurance** gekauft wurden und die SA-Abdeckung zum Zeitpunkt des Upgrades aktiv ist, haben Sie in der Regel das Recht, die entsprechenden CALs für die neue Serverversion ohne zusätzliche Kosten zu nutzen. Das ist ein großer Vorteil! Sie müssen dann lediglich die neuen CALs auf Ihrem Lizenzserver (der natürlich die passende Version haben muss) aktivieren.

**Wichtiger Hinweis:** Wenn Ihre **RDS-CALs** *ohne Software Assurance* erworben wurden, sind sie an die spezifische Version gebunden, für die sie ursprünglich gekauft wurden. Ein Upgrade des RDS-Sitzungshosts würde dann den Kauf völlig neuer **RDS-CALs** für die neue Serverversion erforderlich machen. Dies ist oft der größte Kostentreiber bei einem Upgrade ohne vorherige Planung.

### Praktische Schritte und Best Practices vor dem In-place Upgrade

Um Stolpersteine zu vermeiden, ist eine sorgfältige Planung unerlässlich:

1. **Bestandsaufnahme Ihrer aktuellen RDS-Infrastruktur:**
* **RDS-Rollen:** Welche Server hosten welche RDS-Rollen (Sitzungshost, Broker, Gateway, Web Access, Lizenzserver)? Notieren Sie die **Betriebssystemversion** jedes Servers.
* **CAL-Typen und -Mengen:** Wie viele **RDS Per User CALs** und **RDS Per Device CALs** sind auf welchem Lizenzserver installiert? Notieren Sie deren **Version** (z.B. 2016).
* **Lizenzserver-Details:** Auf welchem Server läuft Ihr **RDS-Lizenzserver**? Welche **OS-Version** hat dieser Server? Welche CALs sind dort aktiviert?
* **Software Assurance:** Überprüfen Sie, ob Ihre aktuellen **RDS-CALs** durch Software Assurance abgedeckt sind und wann diese ausläuft. Dies ist entscheidend für Ihre Budgetplanung.

2. **Definieren Sie Ihr Upgrade-Ziel:**
* Auf welche **Windows Server-Version** möchten Sie den **RDS-Sitzungshost** upgraden (z.B. 2019, 2022)?
* Müssen auch andere RDS-Rollen-Server (insbesondere der Lizenzserver) aktualisiert werden?

3. **Bewertung der CAL-Kompatibilität und des Bedarfs:**
* Vergleichen Sie die aktuelle CAL-Version mit der Ziel-OS-Version des Sitzungshosts.
* Wenn Sie von Server 2016 auf Server 2019/2022 upgraden, und Ihre CALs keine SA haben, müssen Sie **NEUE RDS-CALs** für die Zielversion kaufen. Planen Sie dies im Budget ein!
* Wenn Ihre CALs SA haben, haben Sie das Recht, die neuen CALs zu nutzen. Informieren Sie sich, wie Sie diese im Volumenlizenzcenter (VLSC) herunterladen und auf Ihrem Lizenzserver installieren können.

4. **Planung des Lizenzserver-Upgrades/-Austauschs:**
* Wenn Ihr aktueller **RDS-Lizenzserver** eine ältere Version ist als die Ziel-CALs (z.B. 2016er Lizenzserver für 2019er CALs), müssen Sie ihn ebenfalls upgraden oder einen neuen Lizenzserver mit der neueren OS-Version aufsetzen.
* **Best Practice:** Erwägen Sie, einen neuen, separaten Server für den **RDS-Lizenzserver** aufzusetzen, der die neue Betriebssystemversion hat. Migrieren Sie dann die CALs (falls gleicher Typ und Version) oder installieren Sie die neuen CALs dort.

5. **Backup, Backup, Backup:** Erstellen Sie vor JEDEM In-place Upgrade ein vollständiges Backup des Servers. Im Falle eines Fehlers ist dies Ihre Rettung.

### Der Upgrade-Prozess und die CAL-Implementierung

1. **Upgrade des RDS-Lizenzservers (falls nötig):**
* Wenn Ihr Lizenzserver auf einer älteren OS-Version ist und die neuen CALs hosten soll, führen Sie zuerst das In-place Upgrade dieses Servers durch oder migrieren Sie die Lizenzrolle auf einen neuen, bereits aktualisierten Server.
* **Aktivieren Sie die neuen CALs** auf dem aktualisierten Lizenzserver. Stellen Sie sicher, dass genügend CALs für alle Ihre Benutzer/Geräte vorhanden sind.

2. **Upgrade des RDS-Sitzungshosts:**
* Führen Sie das In-place Upgrade des **RDS-Sitzungshosts** auf die gewünschte Windows Server-Version durch.
* Nach dem Upgrade stellen Sie sicher, dass der Sitzungshost den korrekten, aktualisierten Lizenzserver konfiguriert hat. Dies können Sie in den **Remote Desktop Services Collection Properties** im Server Manager oder über Gruppenrichtlinien (GPO) einstellen.

3. **Überprüfung und Validierung:**
* Nach dem Upgrade melden Sie sich als Administrator an und überprüfen Sie das **Ereignisprotokoll** auf Lizenzfehler (Event ID 1128, 1130, 1131).
* Verwenden Sie den **RD Licensing Diagnoser** (ausführbar über `lsdiag.msc`), um sicherzustellen, dass der Lizenzserver korrekt konfiguriert ist und die CALs korrekt ausgestellt werden.
* Testen Sie Anmeldungen von verschiedenen Benutzern, um sicherzustellen, dass sie eine Lizenz erhalten und sich erfolgreich verbinden können.
* Überprüfen Sie die Funktionalität aller installierten Anwendungen.

### Warum ein Clean Install oft die bessere Wahl ist

Obwohl dieser Artikel sich auf das In-place Upgrade konzentriert, muss betont werden, dass Microsoft für RDS-Rollen in der Regel einen **Clean Install** (Neuinstallation) empfiehlt, insbesondere für den Sitzungshost und den Lizenzserver.

**Vorteile eines Clean Installs:**
* **Sauberes System:** Keine Altlasten oder inkompatible Treiber.
* **Bessere Performance:** Optimiert für die neue Betriebssystemversion.
* **Weniger Fehleranfälligkeit:** Der Upgrade-Pfad ist oft komplexer und fehleranfälliger.
* **Bessere Trennung der Infrastruktur:** Ermöglicht eine schrittweise Migration und Tests.
* **CAL-Migration:** Wenn Sie einen neuen Lizenzserver aufsetzen, können Sie vorhandene CALs (sofern versionskompatibel) von einem alten Lizenzserver migrieren. Bei einem Upgrade auf eine neue OS-Version benötigen Sie jedoch ohnehin neue CALs (es sei denn, SA ist aktiv).

Eine gängige Strategie ist der Aufbau einer **parallelen RDS-Farm** mit den neuen Serverversionen und der neuen CAL-Infrastruktur. Dann migrieren Sie Benutzer schrittweise oder planen einen Umschalttermin. Dies bietet die größte Sicherheit und minimiert das Risiko von Ausfallzeiten.

### Fazit

Ein **In-place Upgrade** eines RDS-Terminalservers mag auf den ersten Blick verlockend erscheinen, birgt jedoch erhebliche Komplexität und Risiken, insbesondere im Zusammenhang mit **RDS-CALs**. Die strikte Versionsabhängigkeit der CALs vom **RDS-Sitzungshost** und die Notwendigkeit, dass der **RDS-Lizenzserver** die entsprechende oder eine neuere Version besitzt, sind kritische Punkte, die oft übersehen werden.

Eine gründliche Bestandsaufnahme, eine sorgfältige Planung der Lizenzierungsstrategie (inklusive der Berücksichtigung von **Software Assurance**) und das Verständnis der Kompatibilitätsregeln sind absolut entscheidend für den Erfolg. Ohne die korrekte Handhabung Ihrer **RDS-CALs** riskieren Sie nicht nur einen Systemausfall, sondern auch schwerwiegende Compliance-Verletzungen. In vielen Fällen ist eine Neuinstallation oder der Aufbau einer parallelen Umgebung zwar aufwändiger, bietet aber langfristig mehr Stabilität und Sicherheit für Ihre **RDS-Infrastruktur**. Investieren Sie Zeit in die Planung – es zahlt sich aus.