Fehlersuche: erst der Betroffenenkreis, dann die Daten

Zwölf Meldungen in einer Stunde sind selten zwölf Ursachen — und die Einzelfallbearbeitung ist der teuerste Weg zu einer gemeinsamen. Dieses Modul verbindet die Methode mit den Daten: wie der Betroffenenkreis den Suchraum halbiert, warum ein Neustart hilft und zugleich die Spur vernichtet, welche Diagnosetabellen an welchem Objekt eingeschaltet werden — und warum zwei völlig verschiedene Dinge in diesem Umfeld Workspace heißen. Dazu der blinde Fleck, der sich nicht meldet: Der Azure-Monitor-Agent wird auf erneuerten Session Hosts nicht automatisch installiert, und die Auswertung zeigt danach weiterhin Daten, nur eben von weniger Hosts.

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

Sechs Schichten, ein Satz

Eine Sitzungsplattform hat viele Schichten, die dieselben Symptome erzeugen: Client, Netzweg, Vermittlung, Session Host, Profil und Anwendung. Nutzer melden sie alle mit demselben Satz — es geht nicht.

Die erste Frage ist deshalb nie, was kaputt ist, sondern wen genau es trifft. Der Betroffenenkreis ist die billigste Messung, die es gibt, und er schneidet den Suchraum schneller zusammen als jedes Protokoll.

LernzielDu kannst einen Betroffenenkreis bestimmen und daraus die wahrscheinliche Schicht ableiten, Beweise sichern, bevor ein Neustart sie vernichtet, und benennen, welche Datenquelle welche Frage beantwortet.

Wen trifft es?→Welche Schicht?→Beweise sichern→Hypothese prüfen→Maßnahme

Kreis vor Ursache

Betroffenenkreis — Die Menge der Personen, Standorte oder Maschinen, bei denen ein Symptom auftritt — und ebenso wichtig die Menge derer, bei denen es nicht auftritt. Erst beide zusammen grenzen ein: Was alle trifft, sitzt in einer gemeinsamen Abhängigkeit; was einen trifft, sitzt in dem, was diesen einen von den anderen unterscheidet.

Was der Betroffenenkreis verrät

Eine Person: Identität, Zuweisung oder ihr Profil. Fast nie die Plattform — sonst träfe es mehr.
Ein Standort: Netzweg, Laufzeit oder eine standortbezogene Richtlinie.
Ein Host: Konfiguration dieser Maschine: Agent, Rechte des Computerkontos, fehlende Werte im Abbild.
Eine Nutzergruppe: Zuweisung, Anwendungsgruppe oder eine Richtlinie, die auf diese Gruppe zielt.
Alle gleichzeitig: Eine gemeinsame Abhängigkeit: Profilspeicher, Verzeichnisdienst, Netzweg, Dienststörung.

Die Frage, die den Kreis bestimmtSie lautet nicht, ob es bei jemand anderem auch nicht gehe, sondern: seit wann, von wo, mit welchem Client, und geht es bei einer Kollegin am Nebentisch. Vier Rückfragen, die zusammen mehr wert sind als eine Stunde in Protokollen — vorausgesetzt, jemand stellt sie, bevor er mit dem Suchen anfängt.

Der Kreis ist eine Hypothese, kein Beweis. Zwei unabhängige Störungen sehen wie eine aus, und eine gemeinsame Ursache kann sich zuerst nur bei wenigen zeigen. Er grenzt ein, wo man zuerst hinsieht — er ersetzt das Hinsehen nicht.

Die Schichten trennen

Der zweite Schnitt geht quer zum ersten: In welcher Phase bricht es ab? Die Plattform trennt drei Authentifizierungsphasen, und die Symptome unterscheiden sich deutlich genug, um sie mit einer Rückfrage auseinanderzuhalten.

Kein Feed, keine Ressourcen — der Vorgang endet vor dem Session Host. Zuweisung, bevorzugter Anwendungsgruppentyp, Conditional Access.
Feed da, Verbindung scheitert — Gateway, Netzweg oder eine Richtlinie, die erst beim Verbinden greift.
Verbindung steht, Windows-Anmeldung scheitert — Einbindungsart, Anmelderecht, Profilzugriff.
Desktop läuft, Anwendung fragt — Umleitung, Kerberos-Sichtverbindung, Grenzen externer Identitäten.
Alles läuft, fühlt sich zäh an — Laufzeit und Transport, nicht Rechenleistung.

Warum die Kombination trägtBetroffenenkreis und Phase spannen ein Raster auf. Eine Person, die keinen Feed bekommt, ist ein Zuweisungsfall. Alle Personen eines Hosts ohne Profil sind ein Konfigurationsfall dieser Maschine. Ein Standort mit zäher Bedienung ist ein Platzierungsfall. Drei Felder, drei völlig verschiedene Maßnahmen — und alle drei wurden mit demselben Satz gemeldet.

Praktisch lässt sich die Phase mit drei Rückfragen bestimmen, die jeder Meldende beantworten kann: Ist die Ressource in der Liste erschienen? Kam ein Anmeldefenster? War der Desktop kurz sichtbar? Wer diese drei Antworten hat, weiß, in welchem Drittel der Kette er suchen muss — und braucht dafür weder Zugriff auf Protokolle noch technisches Vorwissen beim Gegenüber.

Beweise sichern, bevor sie verschwinden

Ein Neustart hilft oft und vernichtet dabei die Spur. Das ist kein Grund, ihn zu unterlassen — es ist ein Grund, vorher zu sammeln. Der Konflikt zwischen Wiederherstellung und Aufklärung ist echt, und er wird durch Reihenfolge aufgelöst, nicht durch Verzicht.

Zeitpunkt und Person festhalten — ohne beides lässt sich später nichts korrelieren.
Ereignisprotokolle des Hosts sichern, solange sie den Vorfall noch enthalten.
Fehlercode oder Korrelations-ID aus der Meldung des Clients notieren.
Zustand des Hosts dokumentieren: Sitzungszahl, Drain-Modus, Agentzustand.
Erst dann neu starten — und den Neustart selbst als Zeitstempel festhalten.

Der Host im Drain-Modus als KompromissWenn ein Host sich auffällig verhält, aber noch Sitzungen trägt, ist der Drain-Modus der Weg zwischen beiden Zielen: keine neuen Nutzer mehr darauf, bestehende arbeiten weiter, und die Maschine bleibt für die Untersuchung erhalten. Wer sie stattdessen sofort neu startet, hat den Betrieb wiederhergestellt und die Ursache verloren — bis sie wiederkommt.

Für die Sicherung am Host selbst sind zwei Quellen besonders ergiebig: die Ereignisprotokolle unter *Windows-Protokolle* und *Anwendung* — dort meldet sich unter anderem die Quelle WVD-Agent — sowie die Protokolle der Profillösung. Beide sind lokal und verschwinden mit der Maschine: Wird ein Host im Zuge einer Erneuerung ersetzt, ist die Spur endgültig fort, auch wenn dieselbe Maschine hinterher wieder denselben Namen trägt.

Zwei Ebenen von Daten

Für die Aufklärung gibt es zwei getrennte Datenquellen, und sie beantworten verschiedene Fragen. Wer sie verwechselt, sucht die Anmeldedauer im Dienstprotokoll und den Verbindungsfehler im Leistungsindikator.

Diagnose der Plattformobjekte: Was der Dienst über Verbindungen, Fehler, Feed und Hostregistrierung weiß. Wird an den Objekten Host Pool und Workspace eingeschaltet.
Telemetrie der Session Hosts: Leistungsindikatoren und Windows-Ereignisprotokolle der Maschinen. Kommt über den Azure-Monitor-Agenten und eine Datensammlungsregel.

Zusammengeführt werden beide in einem Log-Analytics-Arbeitsbereich. Sie müssen nicht derselbe sein — der Arbeitsbereich für die Hostdaten darf ein anderer sein als der für die Diagnosedaten.

Die Trennung ist auch eine Zuständigkeitsfrage. Die Diagnose der Plattformobjekte schaltet man an Host Pool und AVD-Workspace ein — das ist eine Aufgabe in Azure. Die Telemetrie der Hosts verlangt einen Agenten im Betriebssystem, eine Datensammlungsregel und eine verwaltete Identität — das ist eine Aufgabe am Abbild und an der Bereitstellung. In Organisationen mit getrennten Teams fällt deshalb regelmäßig eine der beiden Ebenen zwischen die Stühle, und niemand bemerkt es, solange keine Störung aufzuklären ist.

Der Begriff, der zwei Dinge meint

Workspace ist nicht gleich WorkspaceIn diesem Umfeld heißen zwei völlig verschiedene Objekte gleich: der Azure-Virtual-Desktop-Workspace, der Anwendungsgruppen bündelt und in dem Nutzer ihre Ressourcen sehen — und der Log-Analytics-Arbeitsbereich, in dem Protokolldaten landen. Die Dokumentation stellt an mehreren Stellen ausdrücklich klar, welcher gemeint ist. Wer das überliest, schaltet Diagnose am falschen Objekt ein und wundert sich über leere Tabellen.

Die Unterscheidung ist keine Sprachpedanterie: Beide Objekte tragen Diagnoseeinstellungen, und die verfügbaren Tabellen unterscheiden sich. Wer die Verbindungsdaten sucht, findet sie am Host Pool — am AVD-Workspace gibt es sie gar nicht.

Dieselbe Sorgfalt lohnt bei einem zweiten Begriffspaar. Der Host Pool trägt die Diagnose über Verbindungen und Hostregistrierung; die Session Hosts tragen ihre eigene Telemetrie über den Agenten. Wer am Host Pool sucht, findet, was der Dienst gesehen hat — wer am Host sucht, findet, was das Betriebssystem gesehen hat. Beide Sichten auf denselben Vorfall können sich unterscheiden, und genau diese Differenz ist oft der eigentliche Befund: Meldet der Dienst eine erfolgreiche Verbindung und das Betriebssystem eine abgebrochene Anmeldung, liegt die Ursache dazwischen.

Welche Tabellen wo eingeschaltet werden

Am Host Pool: Management Activities, Feed, Connections, Errors, Checkpoints, HostRegistration, AgentHealthStatus.
Am AVD-Workspace: Management Activities, Feed, Errors, Checkpoints.

Connections beantwortet, wer wann von wo eine Verbindung aufgebaut hat.
Errors liefert die Fehlerbilder samt Code zu diesen Vorgängen.
Checkpoints zeigt den Fortschritt innerhalb eines Verbindungsaufbaus — hier wird sichtbar, in welcher Phase es hakt.
HostRegistration beantwortet, ob ein Session Host sich überhaupt angemeldet hat.
AgentHealthStatus zeigt, ob der Agent auf dem Host gesund ist.
Feed beantwortet, was ein Nutzer als Ressourcen geliefert bekam.

Rückwirkend gibt es nichtsDiagnoseeinstellungen sammeln ab dem Moment, in dem sie eingeschaltet werden. Eine Störung von gestern lässt sich mit einer heute aktivierten Tabelle nicht aufklären. Deshalb gehören sie zur Inbetriebnahme und nicht zur ersten Störung — das ist die häufigste und teuerste Auslassung in diesem Feld.

Die Zuordnung erklärt auch, warum eine Frage manchmal unbeantwortbar ist. Wer wissen will, ob ein Nutzer die richtige Ressourcenliste bekam, braucht Feed. Wer wissen will, ob der Verbindungsaufbau in der Gateway-Phase oder erst bei der Hostanmeldung abbrach, braucht Checkpoints — mit Errors allein sieht man den Fehler, nicht die Stelle. Und wer fragt, ob ein Host überhaupt betriebsbereit war, findet die Antwort in HostRegistration und AgentHealthStatus, nicht in den Verbindungsdaten.

Daten von den Hosts holen

Leistungsindikatoren und Ereignisprotokolle der Session Hosts kommen nicht von selbst. Dafür braucht es drei Dinge, die zusammengehören.

Eine Datensammlungsregel, die festlegt, welche Leistungsindikatoren und welche Ereignisprotokolle gesammelt werden.
Eine Zuordnung dieser Regel zu den Session Hosts.
Den Azure-Monitor-Agenten auf jedem Host des Pools, samt der benötigten verwalteten Identität.

Die Grenze der automatischen VerteilungDie automatisierte Bereitstellung über das Konfigurations-Arbeitsbuch ist auf 1.000 Session Hosts oder weniger begrenzt. Für größere Pools empfiehlt die Dokumentation, den Agenten schon beim Erzeugen eines Hosts über eine Vorlage zu installieren — was ohnehin die tragfähigere Variante ist, weil sie jede neue Maschine erfasst.

Für die Auswertung selbst braucht es Leserechte an zwei Stellen: Desktop Virtualization Reader auf der Ressourcengruppe oder dem Abonnement mit Host Pools und Session Hosts, dazu Log Analytics Reader auf dem Arbeitsbereich. Lesezugriff erlaubt dabei nur das Ansehen — für die Verwaltung der Ressourcen braucht es andere Rechte.

Ob die Kette vollständig ist, beantwortet das Konfigurations-Arbeitsbuch selbst. Es prüft Diagnoseeinstellungen, Datensammlungsregel, Agentverteilung, Leistungsindikatoren und Ereignisprotokolle und meldet fehlende Teile im Klartext — etwa, dass einige Hosts des Pools keine Daten an den gewählten Arbeitsbereich senden. Diese Prüfung ist der schnellste Weg, eine Telemetrielücke zu finden, und sie gehört nach jeder größeren Änderung wiederholt, nicht nur beim Aufbau.

Der blinde Fleck nach einer Erneuerung

Hier trifft die Fehlersuche auf den Abbildlebenszyklus, und das Ergebnis ist eine Lücke, die sich nicht meldet.

Der Agent überlebt keine ErneuerungDer Azure-Monitor-Agent wird auf erneuerten Session Hosts nicht automatisch installiert. Wer Hosts aus aktualisierten Abbildern neu bereitstellt — also genau das, was für gepoolte Pools empfohlen ist —, verliert die erneuerten Maschinen aus der Auswertung. Ohne Fehlermeldung, ohne Warnung: Die Auswertung zeigt weiterhin Daten, nur eben von weniger Hosts.

Abhilfe ist eine Richtlinie, die den Agenten auf jeder neuen Maschine erzwingt — oder die Installation im Abbild beziehungsweise über die Bereitstellungsvorlage.
Manuelles Nachtragen hält bis zur nächsten Erneuerung und ist deshalb keine Lösung, sondern eine Wiederholung.
Das Konfigurations-Arbeitsbuch meldet den Zustand: Es weist darauf hin, wenn nicht alle Hosts des Pools Daten senden.
Die Prüfung gehört in die Abnahme jeder Erneuerung, nicht in die nächste Störung.

Das Muster ist allgemeiner als dieser eine Fall: Jede Beobachtungsfähigkeit, die auf einem Agenten im Betriebssystem beruht, ist an den Lebenszyklus der Maschine gebunden. Wer Maschinen als Verbrauchsmaterial behandelt — und das ist für gepoolte Pools die empfohlene Betriebsweise —, muss den Agenten zum Bestandteil der Erzeugung machen. Sonst wächst der blinde Fleck mit jedem Erneuerungslauf, und die Auswertung wird nicht falsch, sondern unvollständig. Das ist die gefährlichere Variante, weil sie plausibel aussieht.

Wo die eigene Zuständigkeit endet

Bei einer Störung laufen Befunde zusammen, die nicht alle in die eigene Verantwortung fallen. Die Grenze sauber zu ziehen beschleunigt die Aufklärung — und verhindert, dass man an einer Komponente sucht, die man gar nicht steuert.

Eigene Sache: Session Hosts und ihr Betriebssystem, Identität und Verzeichnisdienste, Anwendungen, Profilspeicher, Netzsteuerung, Konfiguration der Bereitstellung.
Anbietersache: Virtualisierungs-Steuerungsebene mit Broker und Gateway, Web-Zugang, Diagnosedienst, physische Infrastruktur.

Was die Grenze praktisch bedeutetMeldet der Dienst eine Störung der Steuerungsebene, ist kein Befund am eigenen Host zu erwarten — und umgekehrt lässt sich eine Störung, die nur die eigenen Hosts betrifft, nicht an den Anbieter abgeben. Ein Dienstzustandsalarm für Azure Virtual Desktop beantwortet diese Frage in Sekunden und gehört deshalb eingerichtet, bevor man ihn braucht.

Für die Abgrenzung im laufenden Betrieb hilft eine einfache Probe: Lässt sich der Befund auf einem einzelnen Host reproduzieren, den man selbst anfassen kann, liegt er fast immer in der eigenen Zuständigkeit. Betrifft er gleichzeitig Hosts in mehreren Pools und mehreren Regionen, ohne dass eine gemeinsame eigene Komponente dazwischenliegt, lohnt der Blick auf den Dienstzustand, bevor weiter gesucht wird.

Die Diagnose als Ablauf

Zwölf Meldungen in einer Stunde

Szenario

Innerhalb einer Stunde gehen zwölf Meldungen über Verbindungsabbrüche ein. Der Support beginnt, für jeden Fall einzeln Client, Netzverbindung und Endgerät zu prüfen. Nach zwei Stunden ist keine Ursache gefunden und die Zahl der Meldungen gestiegen.

Anforderungen

Das Vorgehen soll geändert werden, bevor weitere Zeit in Einzelfälle fließt.
Das Ergebnis soll sagen, ob eine gemeinsame Ursache vorliegt.

Schritte

Die zwölf Meldungen nebeneinanderlegen und den gemeinsamen Nenner suchen: Standort, Nutzergruppe, Host, Zeitpunkt.
In der Tabelle der Verbindungen prüfen, ob die Abbrüche auf bestimmte Hosts oder auf einen Zeitraum fallen.
Die Fehlertabelle nach dem gemeinsamen Fehlercode durchsehen.
Bei Treffern auf wenige Hosts: diese in den Drain-Modus setzen und ihren Zustand sichern.
Erst danach die verbleibenden Einzelfälle einzeln betrachten.

Merksatz: Zwölf Einzelfälle sind selten zwölf Ursachen. Die Einzelfallbearbeitung ist der teuerste Weg zu einer gemeinsamen Ursache — sie findet sie erst, wenn genug Fälle bearbeitet wurden, um das Muster zu sehen.

Der Preis dieser ReihenfolgeWer den Kreis zuerst bestimmt, lässt die zwölf Meldenden zunächst warten. Das fühlt sich falsch an und ist es nicht: Die Einzelbearbeitung hätte sie ebenfalls warten lassen, nur länger und ohne Ergebnis. Kommunizieren muss man es trotzdem — sonst sieht es nach Untätigkeit aus.

Was Telemetrie kostet

Für Log Analytics fallen übliche Speichergebühren an; empfohlen wird, mit nutzungsabhängiger Abrechnung zu beginnen und mit wachsender Bereitstellung anzupassen.
Ein eigener Arbeitsbereich für die Session Hosts stellt sicher, dass nur deren Indikatoren und Ereignisse gesammelt werden — alles andere lässt sich abschalten, um Kosten zu sparen.
Mehr gesammelte Ereignisprotokolle bedeuten mehr Daten und höhere Kosten, aber nicht zwangsläufig bessere Diagnose.
Alarme sind eine eigene, optionale Funktion und werden getrennt eingerichtet.

Die ehrliche AbwägungTelemetrie ist die einzige Investition dieses Moduls, die sich nur im Störungsfall auszahlt — und dann vollständig. Zu wenig davon heißt, bei jeder Störung von vorn anzufangen; zu viel heißt, für Daten zu zahlen, die niemand ansieht. Der Mittelweg entsteht nicht aus einer Zahl, sondern aus der Frage, welche Störung man beim letzten Mal nicht aufklären konnte — und welche Tabelle dafür gefehlt hat.

Eine letzte Bemerkung zur Auswahl: Mehr Ereignisprotokolle bedeuten nicht bessere Diagnose. Was eine Störung aufklärt, ist selten die Menge, sondern die Passung — eine einzige fehlende Tabelle kann eine Aufklärung unmöglich machen, während zwanzig überflüssige Protokolle nur Kosten erzeugen. Die pragmatische Vorgehensweise ist deshalb, mit dem dokumentierten Satz an Indikatoren und Protokollen zu starten und ihn nur dann zu erweitern, wenn eine konkrete, nicht aufgeklärte Störung zeigt, welche Angabe gefehlt hat.

Jetzt anwenden

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

Zum Modul →

Quellen & Aktualität7 Primärquellen · zuletzt geprüft: 2026-09-13