Hosterneuerung: ersetzen statt nachpflegen

Jegliche Anpassungen — Dateien, Registry-Schlüssel oder Zertifikate —, die manuell auf Session Hosts hinzugefügt wurden, sind nach einer Erneuerung nicht mehr vorhanden. Und einzeln erneuern lässt sich kein Host. Wer das erst hinterher liest, hat gerade das Zertifikat verloren, das die Fachanwendung braucht. Dieses Modul behandelt die Hosterneuerung als das, was sie ist: ein Ersetzen von Maschinen. Warum die erste Maschine allein vorausgeht und was das für die verbleibende Kapazität bedeutet, warum Computerobjekte im Active Directory absichtlich stehen bleiben und die neue Maschine sie erbt, warum Autoscale vorher abgeschaltet gehört, und welche zwei Fallen keinen Fehler erzeugen, sondern Stille — eine davon kostet die halbe Überwachung.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-12

Hosts sind Verbrauchsmaterial

In einem gepoolten Host Pool ist ein Session Host kein Server, den man über Jahre pflegt, sondern eine Instanz eines Abbilds. Die Dokumentation sagt das für gepoolte Pools ausdrücklich: Sie werden aktualisiert, indem Hosts aus aktualisierten Abbildern neu bereitgestellt werden, statt Aktualisierungen einzeln auf jede laufende Maschine zu verteilen.

Der Unterschied ist nicht theoretisch. Wer zwanzig Hosts einzeln patcht, hat nach einem Jahr zwanzig verschiedene Zustände und kein Dokument, das beschreibt, worauf eine Nutzerin gerade arbeitet. Wer sie ersetzt, hat genau so viele Zustände wie Abbildversionen — und kann jeden davon benennen.

LernzielDu kannst eine Hosterneuerung so planen, dass laufende Sitzungen nicht abgeschnitten werden, vorhersagen welche Anpassungen sie nicht überleben, und benennen, welche Nebenwirkungen sie in Verzeichnis und Überwachung hinterlässt.

Zustandsdrift — Das Auseinanderlaufen von Maschinen, die einmal gleich waren. Sie entsteht durch einzeln installierte Aktualisierungen, manuelle Eingriffe und fehlgeschlagene Verteilungen — und sie ist der Grund, warum ein Fehler auf drei von zwanzig Hosts auftritt und auf den übrigen nicht.

VoraussetzungErsetzen funktioniert nur, wenn kein Nutzerzustand auf dem Host liegt. Profile, Daten und Einstellungen gehören in den Profilcontainer — sonst löscht jede Erneuerung Arbeit.

Woher das Abbild kommt

Für Session Hosts kommen drei Quellen in Frage, und die Wahl bestimmt, wie gut sich Versionen später auseinanderhalten lassen.

Azure Marketplace: Von Microsoft bereitgestellte Betriebssystemabbilder. Einfach, aber ohne eigene Anwendungen.
Azure Compute Gallery: Eigene Abbilder mit Versionen und Replikation. Der Ort für ein Abbild, das mehr trägt als das nackte Betriebssystem.
Managed Image: Ein einzelnes, eigenes Abbild ohne Versionsverwaltung.

Warum Versionen den Unterschied machenEin Abbild, das bei jeder Änderung überschrieben wird, kennt nur einen Stand: den aktuellen. Meldet ein Fachbereich nach einer Aktualisierung, dass eine Anwendung nicht mehr startet, gibt es dann nichts, worauf man zurückgehen könnte — und keine Möglichkeit zu sagen, was sich überhaupt geändert hat. Versionierte Abbilder in einer Compute Gallery machen den Rückweg zu einem Auswahlfeld statt zu einem Wiederaufbau.

Zwei dokumentierte Einschränkungen gehören in die Planung: Ein Compute-Gallery-Abbild in einem anderen Abonnement als der Host Pool wird derzeit nicht unterstützt, und bei Abbildern mit hinterlegtem Kaufplan bleibt dieser Plan nach einer Erneuerung nicht erhalten.

Was bei einer Erneuerung tatsächlich passiert

Benachrichtigung an angemeldete Nutzer→Wartezeit, dann Abmeldung der Verbliebenen→Drain-Modus, Entfernen aus dem Pool→Neue Hosts aus dem neuen Abbild erzeugen→Aufnahme in den Pool, Drain aus→Alte VMs löschen

Ersetzen, nicht aktualisieren

Das ist der dokumentierte Ablauf der Session Host Update-Funktion, die für Host Pools mit dem Managementansatz *Session Host Configuration* zur Verfügung steht. Sie hebt die vorhandenen Maschinen auf oder löscht sie und erzeugt neue mit der aktualisierten Konfiguration.

Änderbar sind dabei nicht nur das Abbild, sondern auch VM-Größe, Plattentyp, Sicherheitstyp, Domänenbeitritt, Intune-Registrierung, lokale Administratoranmeldedaten und ein eigenes Konfigurationsskript.
Erhalten bleiben Verfügbarkeitskonfiguration, Netzkonfiguration und Standort der Hosts.
Die Größe der Betriebssystemplatte lässt sich während einer Erneuerung nicht ändern — der Dienst übernimmt die Größe aus dem Gallery-Abbild.
Je Host Pool läuft oder wartet immer nur eine Erneuerung. Mehrere Pools gleichzeitig sind möglich.

Die erste Maschine geht allein

Hier steckt der Teil des Verfahrens, den man kennen muss, um eine Erneuerung zeitlich zu planen — und der zugleich der beste Schutz vor einem fehlerhaften Abbild ist.

Die Batchgröße legt fest, wie viele Hosts gleichzeitig erneuert werden; sie ist damit zugleich die Höchstzahl gleichzeitig nicht verfügbarer Hosts. Zu Beginn wird jedoch genau ein Host erneuert — die *initial* —, um zu prüfen, ob der gesamte Vorgang von Anfang bis Ende gelingt, bevor der Rest folgt.

Zehn Hosts, Batchgröße drei

Szenario

Ein Pool mit zehn Session Hosts soll auf eine neue Abbildversion gehoben werden. Als Batchgröße sind drei eingetragen. Gefragt ist, wie viele Hosts währenddessen mindestens zur Verfügung stehen.

Anforderungen

Die Rechnung muss den Sonderfall des ersten Hosts berücksichtigen.
Das Ergebnis dient der Frage, ob die Erneuerung im laufenden Betrieb vertretbar ist.

Schritte

Zuerst wird ein einzelner Host erneuert — die *initial*. Währenddessen sind neun Hosts verfügbar.
Ist sie erfolgreich, folgen die verbleibenden neun Hosts in drei Batches zu je drei.
Während eines Batches sind drei Hosts nicht verfügbar, also sieben nutzbar.
Nach Abschluss der *initial* stehen damit dauerhaft mindestens sieben Hosts zur Verfügung.

Merksatz: Die Batchgröße ist eine Aussage über die verbleibende Kapazität, nicht über die Geschwindigkeit. Wer sie erhöht, verkürzt die Erneuerung und senkt zugleich die Reserve, die während der Erneuerung trägt — und große Batches erzeugen laut Dokumentation gelegentlich Registrierungsfehler des Agenten, die einen erneuten Anlauf nötig machen.

Fortschritt, der stillstehtDie Fortschrittsanzeige bewegt sich erst, wenn ein Host fertig ist. Bei zehn Hosts steht sie deshalb während der gesamten Erneuerung der ersten Maschine auf 0,00 % und springt dann auf 10 %. Das ist kein Hänger, sondern die Auflösung der Anzeige — wer daraufhin abbricht, bricht einen laufenden Vorgang ab.

Was mit angemeldeten Nutzern geschieht

Eine Erneuerung schneidet Sitzungen nicht ohne Vorwarnung ab, aber sie beendet sie. Der Ablauf ist dokumentiert und vom Administrator parametriert.

Angemeldete Nutzer erhalten eine vom Administrator festgelegte Benachrichtigung, die sie zum Ab- und Wiederanmelden auffordert.
Nach einer ebenfalls festgelegten Wartezeit werden verbliebene Nutzer abgemeldet.
Wer sich sofort wieder anmeldet, landet auf einem anderen Host des Pools und kann weiterarbeiten.
Neue Verbindungen werden bevorzugt auf bereits erneuerte Hosts gelenkt.

Die Ausnahme zu BeginnAm Anfang einer Erneuerung gibt es noch keine erneuerten Hosts. Nutzer, die gerade zum Abmelden aufgefordert wurden und sich sofort wieder anmelden, landen deshalb möglicherweise auf einem Host, der als Nächstes an der Reihe ist — und werden ein zweites Mal aufgefordert. Die Dokumentation nennt das ausdrücklich. Für die Ankündigung an die Belegschaft heißt das: Der Hinweis, man müsse sich einmal ab- und wieder anmelden, ist zu Beginn schlicht nicht wahr.

Weil währenddessen weniger Hosts zur Verfügung stehen, gehört eine Erneuerung in ein Zeitfenster, das zur Arbeitsrealität passt. Der vorhandene Energiezustand und der Drain-Modus der Hosts werden respektiert — ein Pool, dessen Hosts zum Kostensparen vollständig abgeschaltet sind, lässt sich ebenfalls erneuern.

Was eine Erneuerung nicht überlebt

Dieser Abschnitt ist der teuerste des Moduls, wenn man ihn überspringt. Die Dokumentation formuliert ihn in einem Satz: Jegliche Anpassungen — Dateien, Registry-Schlüssel oder Zertifikate, die manuell auf Session Hosts hinzugefügt wurden — sind nach Abschluss der Erneuerung nicht mehr vorhanden.

Und es gibt keinen Ausweg über den Einzelfall: Hosts eines Pools lassen sich nicht einzeln erneuern. Wer eine Anpassung dauerhaft braucht, hat genau drei dokumentierte Orte dafür.

Im Abbild: Die Anpassung wandert in die nächste Abbildversion. Der sauberste Weg, mit dem längsten Vorlauf.
Konfigurationsverwaltung: Intune oder Gruppenrichtlinien setzen die Anpassung nach jeder Bereitstellung erneut.
Konfigurationsskript: Ein eigenes PowerShell-Skript, das Teil der Session Host Configuration ist und bei jeder Erzeugung läuft.

Kurzcheck

Ein Kollege hat auf allen Hosts ein Zertifikat für eine Fachanwendung manuell im Maschinenspeicher installiert. Was ist nach der nächsten Erneuerung damit?

Es ist weg — manuelle Anpassungen überstehen die Erneuerung nicht.
Es bleibt erhalten, weil das Computerobjekt im Verzeichnis bestehen bleibt.
Es bleibt erhalten, solange die Betriebssystemplatte nicht verändert wird.
Es wird beim Erneuern automatisch auf die neuen Hosts übertragen.

Treffer. Richtig. Die neuen Maschinen entstehen aus dem Abbild. Das Zertifikat gehört in das Abbild, in die Konfigurationsverwaltung oder in das Konfigurationsskript.

Die Nebenwirkung im Verzeichnis

Eine Erneuerung hinterlässt Spuren dort, wo man sie nicht sucht: im Active Directory. Das Verhalten ist gewollt und hat eine nützliche Folge — und eine, die man kennen muss.

Die Computerkonten domänengebundener Session Hosts werden bei der Entfernung nicht gelöscht. Für einen Moment stehen damit verwaiste Computerobjekte im Verzeichnis. Die neue Maschine tritt der Domäne unter dem ursprünglichen Hostnamen bei und erbt das verwaiste Objekt: Damit entsteht ihre Vertrauensstellung — und die der alten Maschine wird gebrochen.

Warum das gut istWeil das Computerobjekt erhalten bleibt, greifen bestehende Gruppenrichtlinien unverändert weiter — auch solche, die über Computer- oder Gruppenobjekte gefiltert werden. Eine Erneuerung wirft die Richtlinienzuordnung also nicht um. Wird im Zuge der Erneuerung die OU-Mitgliedschaft geändert, gilt das nicht mehr: Dann gehört geprüft, ob die bisherigen Richtlinien überhaupt noch greifen.

Wird die Domäne gewechselt, bleiben die verwaisten Objekte in der alten Domäne zurück und müssen dort entfernt werden. Der Namensmechanismus der Azure-Ressourcen ist davon getrennt: VM, Betriebssystemplatte und Netzwerkkarte entstehen im Format SessionHostName-DateTime — aus VM1-0 wird etwa VM1-0-2023-04-15T17-16-07. Der Hostname des Betriebssystems ändert sich dabei nicht, und genau deshalb funktioniert das Erben des Computerobjekts.

Zwei Dinge, die vorher abgeschaltet gehören

Autoscale ausschaltenDie Dokumentation ist hier unmissverständlich: Wer Autoscale nutzt, deaktiviert es vor dem Start einer Erneuerung und lässt es bis zu deren Abschluss deaktiviert. Ist ein Skalierungsplan während der Erneuerung aktiv, kann diese mit einem Laufzeitfehler scheitern. Zwei Mechanismen, die denselben Hostbestand erzeugen und entfernen, geraten unweigerlich in Konflikt.

Der zweite Punkt ist keine Einstellung, sondern eine Rechnung: Während der Erneuerung existieren alte und neue Maschinen gleichzeitig. Das Abonnement braucht in diesem Moment Kontingent für beide. Wer knapp an seinen Grenzen arbeitet, erhöht das Kontingent vorher — oder die Erneuerung bleibt mittendrin stehen.

Wenn es doch schiefgehtEine gescheiterte Erneuerung lässt sich anhalten, fortsetzen, abbrechen oder erneut versuchen. Solange sie nicht abgebrochen ist, lässt sich der Host Pool allerdings nicht löschen — ein hängender Vorgang blockiert also auch den radikalen Ausweg.

Was still kaputtgeht

Zwei dokumentierte Fallen erzeugen keinen Fehler, sondern Stille. Beide fallen erst auf, wenn jemand etwas sucht, das nicht mehr da ist.

Überwachung: Der Azure-Monitor-Agent wird auf erneuerten Session Hosts nicht automatisch installiert. Wer Azure Virtual Desktop Insights nutzt, verliert die erneuerten Hosts aus der Auswertung — ohne Fehlermeldung. Abhilfe: automatische Installation über Azure Policy oder manuelles Nachtragen.
Abbilder aus laufenden Hosts: Wird ein Abbild von einem bestehenden Session Host erzeugt und anschließend als Quelle verwendet, muss vorher der Ordner C:\packages\plugin gelöscht werden. Andernfalls verhindert er, dass die DSC-Erweiterung läuft, die die neuen Maschinen dem Host Pool beitreten lässt.

Das Muster hinter beidenBeide Fälle entstehen aus derselben Annahme: dass eine neue Maschine ist wie die alte. Sie ist es nicht — sie ist eine Instanz des Abbilds plus dessen, was die Automation nachträglich anbringt. Alles, was am alten Host außerhalb dieses Weges entstanden ist, fehlt. Das gilt für Agenten genauso wie für Zertifikate, und es gilt für Reste im Abbild genauso wie für Fehlendes auf der Maschine.

Ohne Automatik: dieselbe Logik von Hand

Im Managementansatz *Standard* gibt es keine Session-Host-Update-Funktion. Der Ablauf bleibt derselbe, nur führt ihn niemand von selbst aus — und die einzelnen Schritte haben benennbare Werkzeuge.

Der Drain-Modus ist der Kern: Ein Host im Drain-Modus nimmt keine neuen Sitzungen an, neue Verbindungen gehen an den nächsten verfügbaren Host, und bestehende Verbindungen bleiben aktiv, bis der Nutzer sich abmeldet oder ein Administrator die Sitzung beendet. Gesetzt wird er über den Parameter AllowNewSession des Befehls Update-AzWvdSessionHost:

AllowNewSession = $False sperrt den Host für neue Sitzungen, $True gibt ihn wieder frei.
Der Befehl gilt je Host — bei zwanzig Hosts läuft er zwanzigmal, üblicherweise aus einer Schleife.
Nötig ist ein Konto mit der Rolle Desktop Virtualization Session Host Operator.
Ein Administrator erreicht den Host weiterhin direkt per Remotedesktop, ohne über den Azure-Virtual-Desktop-Dienst zu gehen — Wartung ist also auch im Drain-Modus möglich.

Eine Minute GeduldDie Dokumentation weist ausdrücklich darauf hin: Wer das Portal unmittelbar nach dem Umschalten aktualisiert, sieht den Drain-Status möglicherweise noch nicht synchron. Vor dem Aktualisieren mindestens 60 Sekunden warten. Wer das nicht weiß, schaltet zweimal — und hebt dabei versehentlich wieder auf.

Der Rest ist Handarbeit in fester Reihenfolge: Drain setzen, warten bis die Sitzungen enden, Host aus dem Pool entfernen, neuen Host aus der aktuellen Abbildversion erzeugen, aufnehmen, Drain aufheben. Genau diese Reihenfolge nimmt einem die Session-Host-Update-Funktion ab — samt der Vorsichtsmaßnahme, zuerst nur eine einzelne Maschine zu erneuern.

Abbildversionen als Rückweg

Weil eine Erneuerung Maschinen ersetzt, ist der Rückweg ebenfalls eine Erneuerung — auf die vorige Abbildversion. Das funktioniert nur, wenn diese Version noch existiert.

Abbilder werden versioniert abgelegt, nicht überschrieben. Eine Version, die es nicht mehr gibt, ist kein Rückweg.
Die aufzubewahrende Zahl von Versionen folgt der Frage, wie spät ein Fehler typischerweise auffällt — nicht einer runden Zahl.
Der Rückweg kostet dieselbe Zeit wie der Hinweg: dieselben Batches, dieselben Abmeldungen, dieselbe reduzierte Kapazität.
Was Nutzer in der Zwischenzeit erzeugt haben, bleibt erhalten — es liegt im Profilcontainer und nicht auf dem Host.
Der Rückweg gehört geprobt, bevor er gebraucht wird: Eine Abbildversion, die sich noch nie als Quelle einer Erneuerung bewährt hat, ist eine Vermutung und kein Rückfall.
Wer den Rückweg antritt, sollte den Grund festhalten — sonst wird dieselbe fehlerhafte Version beim nächsten Anlauf erneut freigegeben.

Der ehrliche Preis des ModellsErsetzen statt Nachpflegen macht Zustände benennbar und den Rückweg planbar. Bezahlt wird es mit Vorlauf: Jede noch so kleine Änderung braucht eine neue Abbildversion und einen vollständigen Erneuerungslauf. Wer einen Hotfix in zwei Stunden ausrollen muss, ist mit diesem Modell langsamer als mit einer Verteilung auf die laufenden Maschinen — und muss diesen Fall über Konfigurationsverwaltung abdecken statt über das Abbild.

Vor der ersten Erneuerung eines Produktivpools

Testpool anlegen, der dem Zielpool entspricht→Erneuerung dort vollständig durchlaufen lassen→Anwendungen und Hotfixes im Ergebnis prüfen→Autoscale deaktivieren, Kontingent prüfen→Zeitfenster nach verbleibender Kapazität wählen

Erst der Testpool, dann die Produktion

Die Dokumentation empfiehlt diesen Testlauf ausdrücklich — und nennt einen Grund, der leicht überlesen wird: Geprüft wird nicht nur der Vorgang selbst, sondern auch, wie die Umgebung darauf reagiert, dass eine neue Maschine mit demselben Namen wie die vorherige auftaucht. Überwachung, Bestandsverwaltung und Sicherheitswerkzeuge reagieren darauf unterschiedlich, und manche melden es als Vorfall.

Grenzen, die vorher feststehen solltenSession Host Update steht nur in der globalen Azure-Cloud zur Verfügung — nicht in Azure für US-Behörden und nicht in Azure, betrieben von 21Vianet. Und es setzt einen Host Pool mit dem Managementansatz *Session Host Configuration* voraus. Wer im Standardansatz arbeitet, baut dieselbe Logik in eigenen Pipelines nach: Drain, leerlaufen lassen, ersetzen, aufnehmen — der Ablauf bleibt derselbe, nur führt ihn niemand von selbst aus.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität6 Primärquellen · zuletzt geprüft: 2026-09-12