Host Pools: Entscheidungen, die man nur einmal trifft

Breadth-first verteilt Sitzungen nicht gleichmäßig. Der Algorithmus wählt zufällig aus der Hälfte der Hosts mit den wenigsten Sitzungen — bei neun Hosts mit 11 bis 19 Sitzungen kann die nächste Anmeldung auf dem Host mit 15 landen, obwohl einer mit 11 frei steht. Wer aus dem Namen eine Gleichverteilung ableitet, plant Kapazität auf einer Annahme, die das Produkt nie gemacht hat. Dieses Modul behandelt die Entscheidungen, die ein Host Pool verlangt: persönlich oder gepoolt, welcher Algorithmus zu Kosten oder Erlebnis passt, warum die Sitzungsgrenze bei Breadth-first auf 999999 steht und beim Umstellen stehen bleibt, warum sie unter gleichzeitiger Last sogar überschritten werden darf — und welche drei Eigenschaften sich nach der Erstellung nie wieder ändern lassen.

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

Der Pooltyp entscheidet, wie alles andere funktioniert

Ein Host Pool ist die Sammlung der virtuellen Maschinen, auf denen Sitzungen laufen. Die Wahl seines Typs klingt nach einer Detailfrage im Erstellungsdialog. Tatsächlich legt sie fest, wo Nutzerdaten liegen, wie aktualisiert wird, wie skaliert wird und ob ein Nutzer morgen auf derselben Maschine landet wie heute.

Ein Teil dieser Entscheidungen lässt sich später ändern — die Lastverteilung etwa jederzeit. Andere sind an die Erstellung gebunden. Dieses Modul trennt beides und benennt die Stellen, an denen dokumentiertes Verhalten von der Erwartung abweicht.

LernzielDu kannst zwischen persönlichem und gepooltem Host Pool anhand der Arbeitslast entscheiden, einen Lastverteilungsalgorithmus samt Sitzungsgrenze begründet wählen und benennen, welche Eigenschaften bei der Erstellung festgelegt werden.

Zwei Pooltypen, zwei Betriebsmodelle

Persönlicher Host Pool — Jeder Session Host ist einem einzelnen Nutzer zugewiesen. Das liefert dedizierte Desktops und trennt Daten sauber — die maximale Sitzungszahl je Host ist eins.

Gepoolter Host Pool — Sitzungen werden auf beliebige Hosts des Pools verteilt; mehrere Nutzer arbeiten gleichzeitig auf einer Maschine. Das senkt Kosten und erhöht die Auslastung.

Lastverteilung: Persönlich: immer zum zugewiesenen Host. Gepoolt: nach Sitzungszahl, per BreadthFirst oder DepthFirst.
Sitzungsgrenze: Persönlich: eins. Gepoolt: der Wert MaxSessionLimit des Host Pools.
Zuweisung: Persönlich: direkt oder automatisch beim ersten verfügbaren Host. Gepoolt: keine Hostzuweisung — nach Ab- und Neuanmeldung kann ein anderer Host zuständig sein.
Aktualisierung: Persönlich: Windows Update, Configuration Manager oder andere Verteilwerkzeuge. Gepoolt: Hosts werden aus aktualisierten Abbildern neu bereitgestellt statt klassisch aktualisiert.
Nutzerdaten: Persönlich: dürfen auf der Betriebssystemplatte liegen. Gepoolt: gehören in ein FSLogix-Profil, weil der Host wechselt.

Die Kopplung, die man übersiehtPooltyp und Profilstrategie sind nicht zwei Entscheidungen, sondern eine. Wer gepoolt fährt und den Nutzerzustand lokal lässt, liefert bei jeder Anmeldung einen anderen Rechner aus — mit anderen Einstellungen, anderen Dateien, anderem Outlook-Zustand. Das Modul profile-storage behandelt die Umsetzung; hier zählt nur, dass die Entscheidung hier fällt.

Zuweisung im persönlichen Pool

Persönliche Pools kennen zwei Zuweisungsarten. Bei der direkten Zuweisung bestimmt die Administration, wer auf welchem Host landet. Bei der automatischen Zuweisung wird ein Nutzer beim ersten Verbinden dem nächsten freien Host zugeordnet und bleibt dann dort.

Ist ein Nutzer noch keinem Host zugewiesen, wird seine Sitzung auf den nächsten verfügbaren Host im Pool verteilt — danach gilt die feste Bindung. Der Parameter LoadBalancerType kennt für persönliche Pools die Werte Persistent und MultiplePersistent; die beiden gepoolten Algorithmen sind hier ohne Bedeutung.

Was die feste Bindung kostetEin persönlicher Pool ist betrieblich bequem — Nutzer dürfen ihren Rechner behalten, Software lässt sich einzeln installieren. Der Preis ist, dass jede Maschine ein eigener Zustand wird: Nach einem Jahr hat man so viele verschiedene Installationsstände wie Hosts, und kein Abbild beschreibt mehr, worauf jemand arbeitet.

Lastverteilung: zwei Algorithmen mit gegensätzlichem Ziel

Hosts abfragen, die neue Verbindungen annehmen→Kandidaten nach Algorithmus einschränken→Host auswählen→Sitzung dort starten

Nur gepoolte Pools

Breadth-first verteilt neue Sitzungen möglichst gleichmäßig über die Hosts und optimiert damit die Leistung je Sitzung: Arbeitsspeicher, Prozessor und Platte sind weniger umkämpft. Eine Sitzungsgrenze muss dafür nicht gesetzt werden.

Depth-first füllt einen Host bis zur Sitzungsgrenze, bevor der nächste an die Reihe kommt. Das ist die Wahl für kostenbewusste Umgebungen: Wer Hosts dicht packt, kann bei sinkender Last mehr Maschinen abschalten. Eine Sitzungsgrenze ist hier Pflicht.

Gemeinsam: Hat ein Nutzer bereits eine aktive oder getrennte Sitzung im Pool, führt die Lastverteilung ihn dorthin zurück.
Gemeinsam: Ein Host im Drain-Modus wird für Nutzer ohne bestehende Sitzung nicht in Betracht gezogen.
Gemeinsam: Wird die Sitzungsgrenze gesenkt, während Sitzungen laufen, bleiben die bestehenden unberührt.

Die Ausnahme, die Wartungsfenster zerstörtDer Drain-Modus hält nur neue Nutzer fern. Wer im Pool bereits eine aktive oder getrennte Sitzung hat, wird laut Dokumentation weiterhin auf genau diesen Host geführt — auch bei aktiviertem Drain-Modus. Ein Host leert sich deshalb erst, wenn die bestehenden Sitzungen enden, nicht wenn der Schalter umgelegt wird.

Breadth-first verteilt nicht gleichmäßig

Hier liegt der Befund, der die meisten Kapazitätsrechnungen still verfälscht. Breadth-first wählt nicht den Host mit den wenigsten Sitzungen. Der Algorithmus fragt zunächst die Hosts ab, die neue Verbindungen annehmen, und wählt dann zufällig einen aus der Hälfte mit den wenigsten Sitzungen.

Neun Hosts, eine neue Sitzung

Szenario

Ein gepoolter Host Pool mit neun Session Hosts trägt aktuell 11, 12, 13, 14, 15, 16, 17, 18 und 19 Sitzungen. Die Lastverteilung steht auf Breadth-first. Ein Nutzer meldet sich neu an.

Anforderungen

Es soll vorhergesagt werden, auf welchem Host die Sitzung landet.
Die Vorhersage muss zum dokumentierten Verhalten passen, nicht zur Bezeichnung des Algorithmus.

Schritte

Die Hosts, die neue Verbindungen annehmen, bilden die Kandidatenmenge — hier alle neun.
Der Algorithmus bildet die Hälfte mit den wenigsten Sitzungen: die Hosts mit 11, 12, 13, 14 und 15 Sitzungen.
Aus diesen fünf wird zufällig einer gewählt.
Die neue Sitzung kann also auf dem Host mit 15 Sitzungen landen, obwohl einer mit 11 frei wäre.

Merksatz: Die Dokumentation sagt es selbst: Durch die Zufallsauswahl sind Sitzungen unter Umständen nicht gleichmäßig über alle Hosts verteilt. Wer aus dem Namen des Algorithmus eine exakte Gleichverteilung ableitet, plant Kapazität auf einer Annahme, die das Produkt nie gemacht hat.

Depth-first ist umgekehrt genau bestimmt: Er fragt die Hosts ab, die neue Verbindungen annehmen und ihre Sitzungsgrenze noch nicht erreicht haben, und wählt darunter den mit den meisten Sitzungen. Bei Gleichstand gewinnt der erste Treffer der Abfrage.

Kurzcheck

Ein Pool mit Breadth-first zeigt dauerhaft eine Spreizung von etwa 30 Prozent zwischen dem am wenigsten und dem am stärksten belasteten Host. Wie bewertest du das?

Erwartbar — die Zufallsauswahl aus der unteren Hälfte erzeugt genau solche Spreizungen.
Ein Defekt der Lastverteilung — Breadth-first muss gleichmäßig verteilen.
Ein Zeichen dafür, dass die Sitzungsgrenze zu niedrig steht.
Ein Hinweis auf Hosts im Drain-Modus.

Treffer. Richtig. Das ist dokumentiertes Verhalten und kein Defekt. Erst eine Schieflage, die einzelne Hosts an ihre Ressourcengrenze bringt, ist ein Befund.

Die Sitzungsgrenze und ihr Standardwert

MaxSessionLimit begrenzt bei Depth-first, wie viele Sitzungen ein Host aufnimmt. Der Standardwert ist der Grund, warum diese Einstellung so oft übersehen wird.

999999Wird ein Host Pool mit Breadth-first angelegt, steht die Sitzungsgrenze laut Dokumentation auf 999999 — zugleich der höchstmögliche Wert. Wer später auf Depth-first umstellt und diesen Wert stehen lässt, hat nominell Depth-first konfiguriert und praktisch einen einzigen Host, der alle Sitzungen aufnimmt, bis er an seiner Ressourcengrenze zusammenbricht.

Die Umstellung des Algorithmus ist jederzeit möglich — die Sitzungsgrenze wandert dabei nicht automatisch mit.
Haben alle Hosts ihre Grenze erreicht, hilft nur, die Grenze anzuheben oder weitere Hosts aufzunehmen.
Der passende Wert wird gemessen, nicht geraten: Azure Virtual Desktop Insights zeigt Sitzungszahl und Leistung je Host.

Die Grenze ist keine harte SchrankeDie Dokumentation hält ausdrücklich fest: Bei hoher gleichzeitiger Verbindungslast, wenn sich viele Nutzer zur selben Zeit anmelden, kann die Zahl der auf einem Host erzeugten Sitzungen die Sitzungsgrenze überschreiten. Wer die Grenze als Garantie in eine Kapazitätszusage schreibt, verspricht etwas, das das Produkt nicht zusichert — und der Morgenpeak ist genau der Moment, in dem es auffällt.

Ausstehende Sitzung — Ein Platzhalter, der einem Nutzer den Platz auf dem gewählten Host reserviert, während seine Anmeldung läuft. Weil dieser Vorgang je nach Profil zwischen 30 Sekunden und fünf Minuten dauert, verhindert der Platzhalter, dass ein schnellerer Nutzer den Platz wegnimmt.

Drei Sitzungszustände — und was sie belegen

Kapazität wird in Sitzungen gerechnet, und Sitzungen gibt es in drei Zuständen. Die Unterscheidung ist keine Feinheit: Zwei der drei belegen einen Platz, ohne dass jemand sichtbar arbeitet.

Aktiv: Der Nutzer ist angemeldet und mit seinem Desktop oder seiner Anwendung verbunden.
Getrennt: Eine inaktive Sitzung, von der sich der Nutzer noch nicht abgemeldet hat — etwa weil er das Fenster geschlossen hat. Beim Wiederverbinden landet er in dieser Sitzung, und sie wird wieder aktiv.
Ausstehend: Ein Platzhalter, der den Platz auf dem gewählten Host reserviert, solange die Anmeldung läuft.

Die getrennte Sitzung ist der betrieblich unangenehmste der drei Zustände. Sie verbraucht weiterhin Arbeitsspeicher und Prozessorzeit auf ihrem Host, sie zählt gegen die Sitzungsgrenze, und sie bindet den Nutzer an genau diesen Host — auch dann, wenn der Host in den Drain-Modus versetzt wurde. Eine Umgebung ohne Grenzwerte für getrennte Sitzungen sammelt sie über Wochen an.

Warum es die ausstehende Sitzung gibtDie Anmeldung an einen Session Host dauert laut Dokumentation je nach Nutzerprofil zwischen 30 Sekunden und fünf Minuten. Ohne Platzhalter könnte in dieser Zeit ein zweiter, schnellerer Nutzer denselben Platz einnehmen — und der erste flöge aus seiner gerade entstehenden Sitzung. Der Platzhalter kostet Kapazität, die noch niemand nutzt; das ist der Preis dafür, dass niemand mitten in der Anmeldung verdrängt wird.

Für die Kapazitätsplanung heißt das: Die Zahl der verbundenen Nutzer ist nicht die Zahl der belegten Plätze. Wer nur aktive Sitzungen zählt, unterschätzt die Belegung systematisch — und zwar am stärksten am Nachmittag, wenn sich getrennte Sitzungen des Vormittags angesammelt haben.

Fest bei der Erstellung, später änderbar

Die teuerste Eigenschaft einer Entwurfsentscheidung ist nicht ihr Inhalt, sondern ihre Umkehrbarkeit. Bei Host Pools verläuft die Trennlinie nicht dort, wo man sie vermutet.

Pooltyp: Bei der Erstellung festgelegt. Ein Wechsel zwischen persönlich und gepoolt bedeutet einen neuen Pool.
Bevorzugter Anwendungsgruppentyp: Muss laut Dokumentation bei der Erstellung angegeben werden.
Managementansatz: Wird bei der Erstellung gewählt und bestimmt, wer den Lebenszyklus der Hosts führt.
Lastverteilungsalgorithmus: Jederzeit umstellbar — je Pool ist immer genau einer aktiv.
Sitzungsgrenze: Jederzeit änderbar. Eine Senkung wirkt nur auf neue Sitzungen, bestehende bleiben unberührt.
Validierungsumgebung: Als Eigenschaft des Pools setzbar und wieder entfernbar.

Die praktische FolgeDie drei unumkehrbaren Entscheidungen kosten im Erstellungsdialog je einen Klick und binden danach die gesamte Betriebsführung. Die drei umkehrbaren wirken wie Architektur, sind aber Stellschrauben, die man im laufenden Betrieb nachziehen darf. Wer die Aufmerksamkeit umgekehrt verteilt — lange über den Algorithmus diskutiert und den Pooltyp nebenbei anklickt — diskutiert das Falsche.

Kurzcheck

Ein bestehender gepoolter Pool soll künftig jedem Nutzer einen festen Rechner geben. Was ist der Weg?

Ein neuer Host Pool vom Typ persönlich; der bestehende wird abgelöst.
Den Lastverteilungsalgorithmus auf Persistent stellen.
Die Sitzungsgrenze auf eins setzen.
Jedem Nutzer eine eigene Anwendungsgruppe zuweisen.

Treffer. Richtig. Der Pooltyp wird bei der Erstellung festgelegt und lässt sich nicht umschalten. Die Ablösung braucht einen Übergang samt Profilumzug.

Zwei Managementansätze

Neben dem Pooltyp gibt es eine zweite, oft übersehene Weichenstellung: Wer kümmert sich um den Lebenszyklus der Session Hosts?

Session Host Configuration: Azure Virtual Desktop verwaltet den Lebenszyklus der Hosts im Pool mit nativen Funktionen — Erstellen, Aktualisieren, Skalieren.
Standard: Erstellen, Aktualisieren und Skalieren der Hosts bleiben in der eigenen Hand, typischerweise über eigene Pipelines.

Prüfen, bevor man wähltWer bereits eigene Pipelines für Abbilder und Hostbereitstellung betreibt, muss vor der Wahl von Session Host Configuration klären, ob diese Pipelines daneben noch sinnvoll sind — zwei Instanzen, die denselben Hostbestand verwalten, geraten in Konflikt. Zu beachten ist außerdem: Die Region West US 3 wird für automatisierte Host Pools mit Session Host Configuration nicht unterstützt.

Die Validierungsumgebung

Ein Host Pool kann als Validierungsumgebung markiert werden. Dienstaktualisierungen erreichen ihn, bevor sie auf die übrigen Pools ausgerollt werden. Ohne eine solche Umgebung bemerkt man fehlerhafte Änderungen erst, wenn sie die Produktion treffen.

Die Validierungsumgebung soll den Produktivpools so ähnlich wie möglich sein — anderes Abbild, andere Anwendungen, andere Aussage.
Nutzer sollen sich dort so häufig verbinden wie in der Produktion. Ein Pool, den niemand benutzt, bemerkt nichts.
Wer seine Host Pools automatisiert testet, bezieht die Validierungsumgebung in die Tests ein.

Der ehrliche PreisEine Validierungsumgebung kostet Hosts, Lizenzen und Pflege — und sie braucht echte Nutzer mit echter Arbeit, sonst ist sie ein leeres Versprechen. Genau daran scheitern die meisten: Der Pool existiert, aber niemand arbeitet darin, und der erste Hinweis auf eine fehlerhafte Dienstaktualisierung kommt trotzdem aus der Produktion.

Was als Session Host nicht in Frage kommt

Einige Entwurfsideen scheitern nicht an der Betriebsführung, sondern daran, dass sie nicht unterstützt sind. Die Liste ist kurz und lohnt sich, bevor eine Architektur gezeichnet wird.

32-Bit-Betriebssysteme.
N-, KN-, LTSC- und weitere nicht gelistete Windows-Editionen.
Ultra Disks als Typ der Betriebssystemplatte.
Ephemere Betriebssystemplatten für Azure-VMs.
Virtual Machine Scale Sets.
Azure-VMs auf Arm64-Basis.

Die Überraschung in der ListeVirtual Machine Scale Sets sind das naheliegende Azure-Muster für gleichartige, austauschbare Maschinen — und genau dafür sind Session Hosts nicht vorgesehen. Wer aus anderen Azure-Projekten kommt, plant das Muster ein und merkt erst bei der Bereitstellung, dass es hier nicht trägt. Die Skalierung übernimmt stattdessen der Autoscale-Mechanismus des Host Pools.

Eine geografische Trennung gehört ebenfalls in den Entwurf: Host Pools, Workspaces und Anwendungsgruppen lassen sich nur in bestimmten Azure-Regionen anlegen — dort liegen die Metadaten. Die Session Hosts selbst dürfen in beliebigen Regionen stehen, also nahe bei den Nutzern.

Die Entwurfsentscheidung in Reihenfolge

Braucht die Arbeitslast einen festen Rechner je Person?→Wohin gehört der Nutzerzustand?→Kosten oder Erlebnis — welcher Algorithmus?→Sitzungsgrenze aus Messung ableiten→Managementansatz zur vorhandenen Automation wählen

Erst die Arbeitslast, dann die Technik

Die Reihenfolge ist nicht beliebig. Wer mit dem Algorithmus beginnt, entscheidet über Kostenoptimierung, bevor feststeht, ob überhaupt mehrere Nutzer auf einen Host dürfen. Und wer die Sitzungsgrenze setzt, bevor er gemessen hat, hat eine Zahl gewählt, die nichts bedeutet.

Was jede Wahl kostetGepoolt spart Geld und verlangt dafür eine funktionierende Profillösung samt Storage-Betrieb. Persönlich ist einfach und erzeugt dafür so viele Zustände wie Maschinen. Depth-first senkt die Rechnung und setzt mehr Nutzer demselben Hostausfall aus. Breadth-first schützt das Erlebnis und lässt Maschinen laufen, die halb leer sind. Keine dieser Entscheidungen ist kostenlos — wer eine davon ohne ihren Preis verkauft, schreibt Werbung.

Jetzt anwenden

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

Zum Modul →

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