Noch 1 Server meiner Infrastruktur läuft mit Windows Server 2016. Das ist mein Server WS-RDS2. Heute ist sein Tag für die Migration auf Windows Server 2019. Er ist ein Remote Desktop Server mit verschiedenen Rollen, die er in einer eigenen Farm anbietet:

• RDCB: Der Server ist ein Remote Desktop Connection Broker. Er weist den anfragenden Benutzern nach der Validierung einen passenden Remote Desktop Session Host zu. Normalerweise ist diese Rolle einzeln installiert.
• RDSH: Dieser Server ist aber zeitgleich auch ein Remote Desktop Session Host. Hier tummeln sich also später auch die Endanwender.
• RDLIC: Zudem ist hier der Lizenzserver für den Remote Desktop Service installiert.
• RDWEB: Das Web-Portal für den Verbindungsaufbau und die RDS-Feeds läuft ebenfalls lokal.
• RDG: Und zuletzt ist er auch ein Remote Desktop Gateway und kann somit die RDP-Verbindungen von extern mit HTTPS tunneln.

Da der Server die Arbeitsrolle RDSH für die Endanwender zusammen mit den Infrastrukturrollen RDCB, RDWEB, RDLIC und RDG ausführt und zudem noch über das Internet erreichbar ist, habe ich verschiedene Schutzmaßnahmen getroffen:

• Diverse Gruppenrichtlinien härten den Windows Server.
• Verschiedenen Sicherheitsgruppen sind für die Verwendung der Services erforderlich:
  • für den Verbindungsaufbau zum RD-Gateway.
  • für die Verwendung der Session Collection im RD-SessionHost.
  • teilweise für die in der Session Collection veröffentlichten Remote Apps.
• Die Einwahl von außen via RDWEB und RD-Gateway ist nur mit einem zweiten Faktor möglich. Hier setze ich den DUO-Authenticator ein.
• Der Applocker im Windows System schränkt alle Komponenten zur Systemsteuerung weitgehend ein.
• Die Veröffentlichung vom RDWEB und RDG findet nach einer Filterung und Analyse meiner PFSense mit dem IPS Snort statt. Hier habe ich den Webzugriffspunkt mit meinem HAPROXY veröffentlicht.
• Das System steht in meinem Client-Netzwerk. Sollte ein Angriff tatsächlich erfolgreich sein, so sind die Verbindungen zu den anderen Servern noch einmal durch die PFSense mit dem IPS Snort zu leiten. Diese filtern und kontrollieren auch den Traffic zwischen dem Client und dem Servernetz.

Der RDSH stellt eine Session Collection mit verschiedenen Remote Apps zur Verfügung Einige davon sind PowerShell-Scriptlösungen. Die Windows PowerShell wurde generell blockiert. Jede Remote App ist daher eine Ausnahme.

Der Server hat mit der Zeit eine gewisse Komplexität bekommen. Dennoch ist es einer der meist genutzten Server meiner Infrastruktur. Daher muss ich den Soll-Zustand und die Migration dorthin genau planen:

• Eine Downtime ist in jedem Fall zu minimieren.
• Der neue Windows Server soll mit Windows Server 2019 ausgeführt werden.
• Das Konzept mit den Remote Apps hat sich bewährt und soll beibehalten bleiben.
• Die Sicherheitsvorkehrungen sollen erhalten bleiben oder verbessert werden.
• Der Servername, die Servicenamen und die Zugriffspunkte sollen beibehalten werden.

Ich könnte einen neuen Windows Server parallel erstellen, fertig konfigurieren und zum Schluss den alten gegen den neuen Server austauschen. Dabei müsste ich aber den Servernamen anpassen. Ich meine, dass ist mit der installierten RD-ConnectionBroker Rolle nicht möglich. Das würde dann aber bedeuten, dass ich den alten Server zuerst deaktivieren muss. Durch die vielen konfigurierten Details ist eine Migration durch einen Neubau nicht einfach und somit zeitaufwendig. Da wird viel Downtime notwendig sein…

Als Alternative könnte ich aber auch eine Aktualisierung auf Windows Server 2019 mit ein paar Nacharbeiten vornehmen. Dabei bleiben die meisten Konfigurationen erhalten. Der Vorgang selber ist auch schnell abgeschlossen.

Bei Microsoft habe ich nur diesen Artikel dazu gefunden: https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/upgrade-to-rds:

Normalerweise bin ich kein Fan von Upgrades. Aber ich möchte der Technik noch eine Chance geben und dabei vielleicht Zeit und Aufwand sparen. Der Server wird also Inplace aktualisiert.

Zuerst starte ich mit meinen PAM-Admin-Script meine T1-Administrationskennung mit den erforderlichen Rechten aus:

Während der Aktualisierung wird der Server nicht immer erreichbar sein. Daher plane ich mal eine Downtime in meinem PRTG-Monitor:

Einige meiner durchgeführten Inplace-Aktualisierungen waren nicht erfolgreich. Daher gehe ich auch hier auf Nummer sicher und erstelle zusätzlich zum normalen und bereits vorhandenen SystemImage-Backup noch einen VM-Snapshot. Mit einer ausgeschalteten VM geht das viel schneller:

Jetzt lege ich noch den Installationsdatenträger als ISO in das virtuelle DVD-Laufwerk ein:

Mehr Vorbereitung ist nicht erforderlich.

Das eigentliche Inplace-Upgrade starte ich über die Setup.exe vom Installationsdatenträger:

Ggf. sind Updates eine Voraussetzung für einen reibungslosen Prozess. Also darf der Server gerne noch einmal prüfen:

Das Zielsystem wird basieren auf meinem Lizenzmodell ein Windows Server 2019 Datacenter. Und für die RDSH-Rolle macht nur der Modus mit der Desktopdarstellung Sinn. Wer will schon als Endanwender auf einem Server Core rauskommen?

An dieser Stelle könnte ich auch eine Neuinstallation vornehmen. Da wäre ich aber mit einer neuen VM viel effizienter gewesen. Zudem will ich ja die vielen Konfigurationen beibehalten. Die Auswahl ist also einfach:

Mit Windows Server 2019 gibt es einige Unterschiede im Remote Desktop Service. Da muss ich ggf. später meine GPO anpassen:

Das wars auch schon mit den Optionen. Es kann losgehen:

Die Aktualisierung läuft und dauert einige Minuten:

Etwa 20 Minuten später ist der Windows Server wieder online und wartet auf meine Anmeldung:

An dieser Stelle beende ich die Maintenance in meinem PRTG-Monitor:

Ein Windows Anmeldebildschirm sagt noch nichts über den Erfolg der Aktualisierung aus. Ich werde also einige Tests durchführen müssen.

Ich beginne ganz pragmatisch und starte auf meinem Client einfach mal eine meiner Remote Apps:

Nach wenigen Sekunden wird mir das grafische Interface angezeigt. Das hat also funktioniert:

Dann prüfe ich die Webseite. Hier hatte ich einige Anpassungen vorgenommen. Diese wurde durch die Aktualisierung wieder überschrieben. Aber die Anmeldemaske wird gezeigt. Ebenso kann ich über das Web-Portal auf meine Remote Apps zugreifen:

Das Web-Portal hat noch eine zweite Aufgabe: Alle Clients laden im Hintergrund die Liste der veröffentlichten Anwendungen für den angemeldeten Benutzer automatisch herunter und integrieren sie in das Startmenü. Auch diese Komponente funktioniert weiter wie bisher gewohnt:

Aus der Endanwender-Perspektive sieht alles gut aus.

Dann sehe ich mich mal auf dem Server als Administrator um. Zuerst kontrolliere ich den Lizenzserver. Bisher hatte er neben nur für Windows Server 2016 die erforderlichen RDS-CALs:

Die Konsole zeigt an, dass nach einer Aktualisierung eine erneute Aktivierung erforderlich ist:

Beim Klicken auf Überprüfen wird mir eine Fehlermeldung angezeigt:

Ich hatte den Server mal in dieser Gruppe stehen… Jetzt hat er gefehlt. Egal, dann nehme ich ihn erneut auf:

Nach einem Neustart kann ich die Aktivierung des RD-Lizenzservers durchführen:

Für meinen Fall gibt es eine eigene Ursache:

Die Aktivierung erfordert einen Internetzugriff und ist schnell erledigt.

Jetzt fehlen mir noch die passenden RDS-CALs für Windows Server 2019. Auf meinem WS-RDS1 hatte ich bereits vor einigen Monaten eine Windows Server 2019 RDS-Farm erstellt. Auch dieser Server wurde damals zum RD-Lizenzserver konfiguriert. Hier sehen wir die 2019er RDS-CALs:

Also habe ich eigentlich 2 RDS-Lizenzserver im Einsatz. Bisher war das zumindest für den Windows Server 2019 erforderlich, denn ein RD-Lizenzserver kann nur RDS-CALs für sein Betriebssystem oder dessen Vorgänger bereitstellen. In der RD-Lizenzierungsdiagnose sehe ich für beide Lizenzserver eine Fehlermeldung:

Das Event im Eventlog auf dem aktualisierten WS-RDS2 ist dabei trügerisch, denn der Admin-Account wurde mit einer der beiden Administrations-CALs vom Level her hochgestuft:

Ich brauche ein Konzept für die Lizenzierung, denn für zwei Lizenzserver habe ich zu wenige Lizenzpakete. Also werde ich einen der beiden Lizenzserver auflösen und den dazugehörigen RDS-Server einfach mit an den verbleibenden RD-LIC binden. Alle Lizenzen werde ich auf diesem Server zusammenführen. Da mein WS-RDS2 eigentlich für Endanwenderzugriffe gedacht ist und der WS-RDS1 später als Administrations-Server dienen soll, ist die Lösung einfach: der aktualisierte Server WS-RDS2 wird der alleinige Lizenzserver. So kann ich den Server WS-RDS1 besser im Netzwerk isolieren.

Zuerst importiere ich die gültigen RDS-CALs vom WS-RDS1 zum WS-RDS2. Das geht in der Konsole auf dem Zielserver:

Bis hier ist der Dialog einfach. Aber nach dem Bestätigen kommt diese Fehlermeldung:

Ich kann mich dunkel an die Ursache erinnern: den Server WS-RDS1 hatte ich im Netzwerk schon einmal testweise isoliert. Er lässt aktuell keine Netzwerkverbindungen vom anderen Server zu… Aber es gibt auch einen anderen Weg für die Übertragung, ohne das sich die beiden Server unterhalten müssen. Auf WS-RDS1 wähle ich die Deaktivierung aus:

Nach der Deaktivierung sind die RDS-CALs wieder frei. Diese kann ich nun in den schon aktivierten Server WS-RDS2 installieren:

Im nächsten Feld gebe ich den Produkt-Key ein:

Und dann kommt die Bestätigung. Hier muss man 2x hinschauen – der Vorgang war NICHT erfolgreich:

Da habe ich mich wohl im Produkt-Key vertan. Ich suche mir den Key neu heraus und gebe ihn in einem neuen Versuch ein – dieses Mal mit Erfolg:

Jetzt verfügt mein aktualisierter WS-RDS2 auch über RDS-CALs für Windows Server 2019:

Im Server Manager passe ich nun den zu verwendenden Lizenzserver an. Hier steht noch der nicht mehr vorhandene WS-RDS1 mit drin. Der kann nun raus:

Ein abschließender Blick in die RD-Lizenzierungsdiagnose auf WS-RDS2 gibt mir grünes Licht:

Aber auch auf WS-RDS1 muss ich diese Anpassung vornehmen. Aktuell verwendet er seinen nun deaktivierten lokalen RD-LIC:

Der fliegt raus. Dafür kommt der RD-LIC vom WS-RDS2 rein:

Auch hier gibt die RD-Lizenzdiagnose grünes Licht. Der Teil der RDS-Infrastruktur funktioniert wieder.

Der aktualisierte Server ist nach der Prozedur mit einem neuen Betriebssystem unterwegs – ist aber nicht Up-to-Date! Denn das Patchlevel hängt natürlich am Alter des verwendeten Installationsdatenträgers. Ein Blick in die Einstellungen zeigt, dass es hier wohl auch noch ein Problem gibt:

Eine spannende Frage lautet: „Hat sich der Server zwischenzeitlich mal beim internen WSUS gemeldet?“. Das hat er. Nur meldet er hier ein Patchlevel von 100%…

Das kann nicht stimmen. Das ISO ist mit dem Stand 2020-11 versehen und mittlerweile ist das Dezember Patch genehmigt. Bevor ich dem Server eine Radikalkur in Sachen Windows Update TroubleShooting antue, versuche ich das Offensichtliche und starte die Update Suche einfach erneut. Dabei beobachte ich den Netzwerk-Traffic im Ressourcen-Monitor:

Die Verbindung wird zu meinem Server WS-CM aufgebaut. Dort ist mein WSUS installiert. Beim aktuellen Versuch scheint der RDS-Server die Updates zu finden:

Nach etlichen Minuten und einem Neustart meldet der Server lokal ein zufriedenstellendes Patchlevel:

Über die Ursache kann spekuliert werden. Ich persönlich tippe auf ungültige Restkonfigurationen der alten Gruppenrichtlinien, mit denen der Windows Update Service nichts anfangen konnte. Erst nach seinem Start wurden die für Windows Server 2019 gültigen Gruppenrichtlinien geladen und erst der nächste Start des Windows Update Service hat dann die Verbindung erfolgreich zum WSUS aufgebaut. Hätte ich einfach noch einige Stunden gewartet, dann wäre das Problem alleine verschwunden.

Ich denke, die Serverfunktionen habe ich bestätigen können. Daher trage ich noch den Produkt-Key ein und aktiviere den Windows Server:

Nachdem der Server zu meiner Zufriedenheit läuft, muss ich zum Abschluss nur noch etwas aufräumen. Im Hyper-V-Manager entferne ich den Prüfpunkt. Das Zusammenführen dauert einen Moment:

Im Systemlaufwerk des RDS-Servers ist natürlich auch noch der bekannte Ordner „Windows.old“ vorhanden, der Speicherplatz belegt. Mit der Datenträgerbereinigung kann ich den Ordner kontrolliert löschen:

Die restlichen Nacharbeiten, wie das Einrichten der Datensicherung, die Integration im Monitoring oder Konfigurationen in der Netzwerk-Firewall entfallen bei dieser Migration. Denn diese Punkte waren bereits vorher konfiguriert und werden in meinem Fall durch die Inplace-Aktualisierung einfach übernommen und weitergeführt. So gesehen spart ein Inplace schon enorm Zeit und Aufwand.

Seit der Aktualisierung sind bis heute einige Wochen vergangen. Bisher funktioniert der Server einwandfrei. Damit habe ich die Entscheidung des Migrations-Szenarios bisher nicht bereut.
Den Artikel gibt es wie gewohnt hier als PDF zum downloaden. Einige meiner PowerShell-Scripte können ganz unten auf der Übersichtsseite gefunden werden.