# Capstone: die Muster, die sich durch den ganzen Track ziehen > Die wiederkehrenden Fehlermuster einer Sitzungsplattform erkennen, eine Störung unter Zeitdruck einordnen und eine Abwägung zwischen Kosten, Erlebnis und Sicherheit mit ihrem Preis vertreten. Track: [Azure Virtual Desktop](https://physar.tech/learn/rds-avd-operations) Kanonische Fassung: https://physar.tech/learn/rds-avd-operations/rds-avd-expert-capstone Stand: 2026-09-13 Interaktiver Teil: 9 Checks (nur im Browser) ## Capstone: die Muster, die sich durch den ganzen Track ziehen ### Der Arbeitsplatz selbst Eine Sitzungsplattform ist nicht eine Anwendung unter vielen — sie ist der Arbeitsplatz. Fällt sie aus, arbeitet niemand, und es gibt keinen Rückfall auf lokal installierte Programme. Das verändert jede Abwägung in diesem Track: Geschwindigkeit der Wiederherstellung schlägt Eleganz der Lösung, und eine Verschlechterung für alle wiegt schwerer als eine Störung für wenige. Dieses Modul verdichtet die zwölf vorangegangenen zu Mustern. Wer sie erkennt, braucht die Einzelheiten nicht auswendig — er weiß, wo er nachsieht. > **Lernziel:** Du kannst die wiederkehrenden Fehlermuster dieser Plattform benennen, eine Störung unter Zeitdruck der richtigen Ebene zuordnen und eine Abwägung zwischen Kosten, Erlebnis und Sicherheit mit ihrem Preis vertreten. > **Was daraus für die Kommunikation folgt:** Weil es keinen Rückfall gibt, ist bei jeder Störung dieser Plattform die Information an die Betroffenen Teil der Maßnahme und nicht ihre Nachbereitung. Wer nicht weiß, dass seine Sitzung in einem temporären Profil läuft, arbeitet weiter und verliert einen Tag. Wer nicht weiß, dass in zehn Minuten abgemeldet wird, sichert nichts. In einer Umgebung mit lokalen Arbeitsplätzen ist Kommunikation Höflichkeit; hier ist sie eine technische Schutzmaßnahme. ### Muster 1: Was still scheitert Das gefährlichste Verhalten dieser Plattform ist nicht der Fehler, sondern das Ausbleiben eines Fehlers. An mindestens sechs Stellen läuft etwas weiter, obwohl es nicht mehr tut, was es soll. - Ein **temporäres Profil** entsteht, der Nutzer arbeitet einen Tag und verliert alles beim Abmelden — `PreventLoginWithTempProfile` steht auf `0`. - Der **bevorzugte Anwendungsgruppentyp** blendet eine Ressourcenhälfte aus, ohne Meldung und ohne Protokolleintrag. - Nach Ablauf der **Anmeldehäufigkeit** scheitern Feed-Aktualisierung und Diagnose-Upload stillschweigend. - Der **Azure-Monitor-Agent** fehlt auf erneuerten Hosts; die Auswertung zeigt weiterhin Daten, nur von weniger Maschinen. - **Optionale Netzziele**, die nicht freigegeben sind, lassen Hosts still veralten oder Sperrlisten ungeprüft. - Eine **Drosselung ohne Shortpath** ist eine Regel, die dokumentiert ist und nichts tut. > **Die gemeinsame Gegenmaßnahme:** Gegen stilles Scheitern hilft kein Alarm auf Fehler — es gibt keine. Es hilft nur, den **erwarteten Zustand** aktiv zu prüfen: Entsteht ein echter Container? Kommen von allen Hosts Daten? Sind die Ziele erreichbar? Wer nur auf Meldungen wartet, erfährt von diesen sechs Fällen zuletzt. Konkret heißt Zustandsprüfung: Eine Testanmeldung, die prüft, ob ein echter Container unter dem erwarteten Pfad entsteht statt eines temporären Profils. Eine Abfrage, die die Zahl der meldenden Hosts gegen die Zahl der Hosts im Pool hält. Ein Lauf des Agent-URL-Werkzeugs nach jeder Netzänderung. Drei Prüfungen, die zusammen fünf der sechs stillen Fälle abdecken — und alle drei lassen sich als wiederkehrende Aufgabe einrichten, statt auf einen Alarm zu warten, den es nicht gibt. ### Muster 2: Was an zwei Orten steht Mehrfach trägt dieselbe Einstellung zwei Orte, und einer gewinnt. Wer nur einen liest, bestätigt zuverlässig einen Zustand, der nicht gilt. | | | | --- | --- | | **Lastverteilung** | Steht am Host Pool und in jeder Skalierungsphase. Die Phase übersteuert den Pool. | | **Kapazitätsschwelle** | Steht in Ramp-up und Ramp-down. Peak und Off-peak erben sie und lassen sich nicht getrennt setzen. | | **Geräteumleitung** | Steht in den RDP-Eigenschaften des Host Pools und wirkt zusätzlich abhängig vom Session Host. | | **Anwendungssichtbarkeit** | Hängt an Zuweisung, Anwendungsgruppentyp und bevorzugtem Typ des Pools — drei Orte für eine Frage. | > **Die Regel dahinter:** Wo zwei Ebenen dieselbe Einstellung tragen, ist die Anzeige der unterlegenen Ebene irreführend, nicht falsch. Eine Konfigurationsprüfung muss deshalb beide Orte nennen — und im Zweifel entscheidet nicht die Anzeige, sondern die Messung. Ein verwandter Fall sind Werte, die durch eine Standardeinstellung wirken, ohne dass sie jemand gesetzt hat. `MaxSessionLimit` steht bei einem mit `BreadthFirst` angelegten Pool auf `999999` und wird bedeutungslos mitgeführt — bis jemand auf `DepthFirst` umstellt und der Wert plötzlich zählt. `SizeInMBs` trägt ohne Zutun rund 30 GB je Nutzer, und FSLogix legt bei der Installation überhaupt keinen Konfigurationswert an, sodass `Enabled` auf `0` steht. Wer eine Umgebung prüft, muss deshalb nicht nur lesen, was gesetzt ist, sondern auch wissen, was ungesetzt gilt. ### Muster 3: Was eine Erneuerung nicht überlebt In gepoolten Pools sind Hosts Verbrauchsmaterial. Damit wird alles, was auf einer laufenden Maschine entstanden ist, vergänglich — und das trifft mehr als nur Software. - Manuell installierte **Zertifikate**, von Hand gesetzte **Registry-Werte**, nachträglich abgelegte **Dateien**. - Der **Überwachungsagent**, wenn er nicht Teil der Erzeugung ist. - **Berechtigungen**, die an einzelne Computerobjekte statt an eine Gruppe vergeben wurden. - **Lokale Protokolle** und damit die Spur eines Vorfalls — auch wenn die neue Maschine denselben Namen trägt. > **Die drei erlaubten Orte:** Was dauerhaft auf einem Host sein soll, gehört in das **Abbild**, in die **Konfigurationsverwaltung** oder in das **Konfigurationsskript** der Session Host Configuration. Ein vierter Ort existiert nicht — und jede Anpassung, die keinen dieser drei Orte hat, ist eine Anpassung auf Zeit. ### Muster 4: Der Betroffenenkreis als erste Messung | | | | --- | --- | | **Eine Person** | Identität, Zuweisung, ihr Profil — alles vor dem Session Host. | | **Ein Host** | Konfiguration dieser Maschine: Agent, Rechte des Computerkontos, fehlende Werte. | | **Ein Standort** | Netzweg und Laufzeit. Eine Platzierungsfrage, keine Leistungsfrage. | | **Eine Gruppe** | Zuweisung, Anwendungsgruppe, eine Richtlinie mit dieser Zielgruppe. | | **Alle** | Eine gemeinsame Abhängigkeit: Profilspeicher, Verzeichnisdienst, Netz, Dienststörung. | Die Tabelle erklärt, warum die Einzelfallbearbeitung bei gleichzeitigen Meldungen das teuerste Verfahren ist: Sie findet eine gemeinsame Ursache erst, wenn genug Fälle bearbeitet wurden, um das Muster zu sehen — und bis dahin sind Stunden vergangen. **Phase:** Der zweite Schnitt, quer zum Betroffenenkreis: kein Feed, keine Verbindung, keine Anmeldung, träge Sitzung. Kreis und Phase zusammen spannen ein Raster auf, in dem fast jede Meldung genau ein Feld trifft — und jedes Feld hat eine andere Maßnahme. Der Kreis bleibt eine Hypothese. Zwei unabhängige Störungen sehen wie eine gemeinsame aus, und eine gemeinsame Ursache zeigt sich zuerst oft nur bei wenigen — etwa weil nur ein Teil der Belegschaft schon angemeldet ist. Die Messung grenzt ein, wo zuerst gesucht wird; sie beweist nichts. Wer sie als Beweis behandelt, schließt zu früh aus und sucht danach am falschen Ort weiter, mit dem zusätzlichen Nachteil, dass er sich sicher fühlt. ### Muster 5: Was nur einmal entschieden wird Einige Festlegungen binden für die gesamte Lebensdauer einer Umgebung. Sie kosten im Erstellungsdialog je einen Klick und lassen sich danach nur durch Neubau ändern. - **Pooltyp** — persönlich oder gepoolt. Entscheidet zugleich über die Profilstrategie. - **Bevorzugter Anwendungsgruppentyp** — muss bei der Erstellung angegeben werden. - **Managementansatz** — Session Host Configuration oder Standard. - **Identitätsanbindung** der Hosts — und damit, welche Profillösung und welche Verwaltungswerkzeuge überhaupt möglich sind. - **Sitzungsbetriebssystem** — und damit das verfügbare Lizenzmodell. > **Die Aufmerksamkeitsfalle:** Die umkehrbaren Parameter wirken wie Architektur und sind Stellschrauben; die unumkehrbaren wirken wie Details und binden alles. Wer lange über den Lastverteilungsalgorithmus diskutiert und den Pooltyp nebenbei anklickt, verteilt seine Aufmerksamkeit genau falsch herum. Die Gegenprobe lohnt ebenso: Lastverteilungsalgorithmus, Sitzungsgrenze, Kennzeichnung als Validierungsumgebung, Drain-Modus, RDP-Eigenschaften, Skalierungsplan und Diagnoseeinstellungen sind im Betrieb änderbar. Sie dürfen im Entwurf mit einer begründeten Näherung belegt und später aus Messwerten nachgezogen werden. Wer diese Trennung kennt, kann einen Entwurf in der Hälfte der Zeit abschließen — und weiß, welche Werte nach der Inbetriebnahme noch einmal angefasst werden müssen. ### Muster 6: Was ausdrücklich nicht geht Ein Teil der Entwurfsarbeit besteht darin, Kombinationen früh auszuschließen. Die Dokumentation benennt sie klar, und jede einzelne hat schon Projekte spät getroffen. - **FSLogix mit reinen Cloud-Konten** auf Entra-eingebundenen Hosts — es braucht hybride Identitäten. - **App Attach mit Microsoft Entra Domain Services** — nicht unterstützt. - **Nutzungsabhängiger Zugriffspreis für Windows Server** — gibt es nicht. - **Administrator protection auf Session Hosts** — nicht unterstützt, mit Auswirkung auf alle Anmeldungen. - **BitLocker auf der Platte mit FSLogix-Profildaten** — soll nicht verwendet werden. - **Windows Installer deaktivieren** — der Dienst kann dann keine Agent-Aktualisierungen installieren. - **mstsc und RemoteApp and Desktop Connections** als Client — nicht unterstützt. > **Warum diese Liste wertvoll ist:** Jeder dieser Punkte kostet wenig, solange er vor dem Entwurf bekannt ist, und viel, sobald eine Umgebung darauf gebaut wurde. Eine Entwurfsprüfung, die nur fragt, ob etwas funktioniert, übersieht sie — sie muss fragen, ob die gewählte Kombination unterstützt ist. Zwei weitere Grenzen betreffen nicht Kombinationen, sondern Erwartungen. **RemoteApp ist keine Sicherheitsfunktion** — die Veröffentlichung einer einzelnen Anwendung verhindert nicht, dass auf dem Host andere gestartet werden. Und **Azure Virtual Desktop hat keine nativen Funktionen für Notfallszenarien** — Wiederanlauf ist eine Konstruktionsaufgabe aus anderen Azure-Diensten. Beide Sätze stehen so in der Dokumentation, und beide korrigieren eine Annahme, die sonst still in einen Entwurf einzieht. ### Abwägen unter Zeitdruck Im Störungsfall verschieben sich die Gewichte. Was im Entwurf richtig ist, kann unter Druck falsch sein — und umgekehrt. | | | | --- | --- | | **Beweise sichern** | Beim ersten Auftreten nachrangig, beim dritten vorrangig. Wer immer sofort neu startet, klärt nie auf. | | **Betroffenenkreis zuerst** | Fühlt sich wie Untätigkeit an und ist die schnellste Abkürzung — muss aber kommuniziert werden. | | **Teilweise wiederherstellen** | Ein Teil der Belegschaft arbeitet wieder, ein Teil nicht. Fast immer besser als alle warten zu lassen, aber eine bewusste Entscheidung mit Gewinnern und Verlierern. | | **Drain statt Neustart** | Kostet Zeit und rettet laufende Arbeit. Bei vielen Betroffenen die schwerste, meist richtige Wahl. | > **Die Entscheidung, die man vorher trifft:** Unter Druck wird nicht abgewogen, sondern ausgeführt. Deshalb gehören diese Abwägungen in ruhige Zeiten: Ab wann sichern wir Beweise? Wer darf teilweise wiederherstellen? Wie lange darf eine Drain-Phase dauern? Wer das im Vorfall zum ersten Mal entscheidet, entscheidet nach Bauchgefühl und Lautstärke. Ein letzter Punkt zur Reihenfolge: Unter Druck neigt jede Gruppe dazu, mit der Maßnahme zu beginnen, die sie am besten beherrscht. Das Netzteam prüft das Netz, das Windows-Team den Host, das Identitätsteam die Anmeldung — alle gleichzeitig und alle plausibel. Der Betroffenenkreis ist deshalb nicht nur eine Diagnosetechnik, sondern auch ein Koordinationswerkzeug: Er sagt, wer in dieser Störung tatsächlich an der Reihe ist, und erspart drei parallele Untersuchungen, von denen zwei nichts finden können. ### Drei Ziele, die sich widersprechen Kosten, Erlebnis und Sicherheit ziehen in verschiedene Richtungen, und jede Maßnahme dieses Tracks bedient eines auf Kosten der anderen. | | | | --- | --- | | **Höhere Dichte** | Kosten sinken. Erlebnis sinkt für alle. Ein Hostausfall trifft mehr Menschen. | | **Umleitungen sperren** | Sicherheit steigt. Erlebnis sinkt, und ohne Ersatzweg entstehen unkontrollierte Umwege. | | **Persönliche Pools** | Sicherheit und Erlebnis steigen. Kosten steigen deutlich. | | **Aggressives Absenken** | Kosten sinken. Abgebrochene Arbeit am Abend. | | **Zweite Region** | Verfügbarkeit steigt. Kosten und Pflegeaufwand verdoppeln sich. | > **Der einzige Fehler, der wirklich einer ist:** Nicht die Wahl eines Ziels über das andere — dafür gibt es Gründe. Der Fehler ist, eine Maßnahme zu beschließen, ohne ihren Preis zu benennen. Dann erscheint der Gewinn in einer Tabelle und der Preis in Supportanfragen, und niemand verbindet beides. Nützlich ist, die drei Ziele mit unterschiedlichen Zeithorizonten zu betrachten. Kosten wirken monatlich und sind sofort sichtbar. Das Erlebnis wirkt täglich und wird erst über Beschwerden sichtbar, oft mit Wochen Verzögerung und selten als Verweis auf die Maßnahme, die es verursacht hat. Sicherheit wirkt gar nicht sichtbar, bis etwas passiert. Wer die drei nach Sichtbarkeit gewichtet statt nach Wirkung, optimiert zuverlässig die Kosten und bezahlt mit den beiden anderen. ### Ein Teilausfall unter Zeitdruck ### Die Hälfte kann nicht arbeiten Um 08:20 melden sich rund die Hälfte der 300 Nutzer eines Pools mit temporären Profilen an. Die andere Hälfte arbeitet normal. Der Profilspeicher antwortet, ist aber deutlich langsamer als sonst. Ein Wartungsfenster gab es nicht. **Anforderungen** - Die Ursache soll benannt werden, ohne den Betrieb der arbeitsfähigen Hälfte zu gefährden. - Weitere Nutzer sollen nicht in temporäre Profile laufen. **Schritte** - Betroffenenkreis prüfen: Trifft es bestimmte Hosts oder verteilt sich es gleichmäßig? Das entscheidet zwischen Hostkonfiguration und gemeinsamer Abhängigkeit. - Die betroffenen Hosts in den Drain-Modus setzen — so entstehen keine weiteren temporären Profile, und laufende Arbeit bleibt. - Den Profilspeicher messen, nicht nur anpingen: Erreichbarkeit ist nicht Leistung, und eine Sperre ist kein Leistungsproblem. - Prüfen, ob die Anbindung an einer Sperre scheitert oder an einer Zeitüberschreitung — die Retry-Werte geben den Zeitrahmen vor. - Die Betroffenen aktiv informieren, dass ihre Arbeit in dieser Sitzung nicht gesichert wird. Das ist der wichtigste Schritt und wird am häufigsten vergessen. **Merksatz:** Bei einem temporären Profil ist die dringendste Maßnahme keine technische: Solange niemand weiß, dass seine Arbeit verloren geht, arbeitet er weiter. Die Ursache zu finden ist wichtig; die Betroffenen zu warnen ist wichtiger. ### Eine Abwägung mit drei Interessen ### Sparen, härten, erlebbar bleiben Für einen Pool mit 200 Sachbearbeitern liegen drei Forderungen vor: die Kosten sollen um ein Fünftel sinken, eine Prüfung verlangt geschlossene Datenpfade aus der Sitzung, und die Fachbereiche beschweren sich bereits über zähe Vormittage. **Anforderungen** - Alle drei Forderungen sollen adressiert werden. - Jede Maßnahme bekommt ihren Preis genannt. **Schritte** - Kosten zuerst über die **Laufzeit**: Ein Skalierungsplan senkt nachts ab und trifft niemanden. Das ist der einzige Hebel ohne Erlebnisverlust. - Dann die **Lizenzkonstellation** prüfen — sie kann große Beträge enthalten und wirkt gar nicht auf Nutzer. - Die zähen Vormittage über **Mindestanteil** und Ramp-up-Zeit lösen, nicht über mehr Rechenleistung: Kapazität muss vor der Welle da sein. - Die Datenpfade **einzeln** schließen, jeder mit benanntem Ersatz — und `redirectwebauthn` ausnehmen, sonst nimmt man die kennwortlose Anmeldung mit. - Die Dichte zuletzt und nur, wenn das Ziel sonst nicht erreichbar ist — sie trifft alle und verschärft die Vormittagsbeschwerden. **Merksatz:** Die drei Forderungen widersprechen sich weniger, als es aussieht — solange man die Maßnahmen nach ihrer Nebenwirkung ordnet statt nach ihrer Höhe. Erst was niemanden trifft, dann was wenige trifft, zuletzt was alle trifft. ### Was bleibt Wer diesen Track durchgearbeitet hat, kennt eine Menge Einzelheiten — Standardwerte, Portnummern, Grenzwerte, nicht unterstützte Kombinationen. Die Einzelheiten veralten. Die Muster nicht. - **Prüfe den erwarteten Zustand**, nicht die Abwesenheit von Fehlern. - **Lies beide Orte**, wo eine Einstellung zweimal steht. - **Gib jeder dauerhaften Anpassung einen der drei erlaubten Orte.** - **Bestimme den Betroffenenkreis**, bevor du suchst. - **Erkenne die unumkehrbaren Entscheidungen** und gib ihnen die Aufmerksamkeit. - **Benenne den Preis** jeder Maßnahme, auch der richtigen. Diese sechs Sätze sind keine Merkhilfe, sondern eine Prüfliste für den Alltag. Sie lassen sich auf jede Änderung anwenden, die jemand vorschlägt: Prüft irgendetwas, dass die Änderung wirkt? Steht der geänderte Wert noch woanders? Überlebt die Änderung die nächste Hosterneuerung? Betrifft sie eine, viele oder alle Personen? Ist sie später noch korrigierbar? Und was kostet sie auf der anderen Seite? Sechs Fragen, die zusammen weniger Zeit brauchen als eine einzige Fehlentscheidung. > **Der Satz, der den Track zusammenhält:** Diese Plattform ist der Arbeitsplatz selbst. Jede Entscheidung, die hier getroffen wird, wirkt unmittelbar auf die Fähigkeit von Menschen, ihre Arbeit zu tun — und fast keine davon meldet sich, wenn sie falsch war. Deshalb wird hier gemessen statt angenommen, und deshalb steht neben jeder Empfehlung ihr Preis. ## Quellen - learn.microsoft.com/en-us/azure/virtual-desktop/terminology — https://learn.microsoft.com/en-us/azure/virtual-desktop/terminology - learn.microsoft.com/en-us/azure/virtual-desktop/prerequisites — https://learn.microsoft.com/en-us/azure/virtual-desktop/prerequisites - learn.microsoft.com/en-us/fslogix/reference-configuration-settings — https://learn.microsoft.com/en-us/fslogix/reference-configuration-settings - learn.microsoft.com/en-us/azure/virtual-desktop/security-guide — https://learn.microsoft.com/en-us/azure/virtual-desktop/security-guide - learn.microsoft.com/en-us/azure/virtual-desktop/licensing — https://learn.microsoft.com/en-us/azure/virtual-desktop/licensing - learn.microsoft.com/en-us/azure/virtual-desktop/session-host-update — https://learn.microsoft.com/en-us/azure/virtual-desktop/session-host-update - learn.microsoft.com/en-us/azure/virtual-deskto…-assign-scaling-plan — https://learn.microsoft.com/en-us/azure/virtual-desktop/autoscale-create-assign-scaling-plan - learn.microsoft.com/en-us/azure/virtual-deskto…-pool-load-balancing — https://learn.microsoft.com/en-us/azure/virtual-desktop/host-pool-load-balancing - learn.microsoft.com/en-us/azure/virtual-desktop/app-attach-overview — https://learn.microsoft.com/en-us/azure/virtual-desktop/app-attach-overview - learn.microsoft.com/en-us/azure/virtual-desktop/insights — https://learn.microsoft.com/en-us/azure/virtual-desktop/insights