Wiederanlauf: die Plattform bringt dafür nichts mit

Azure Virtual Desktop hat keine nativen Funktionen für Notfallszenarien. Was es gibt, sind andere Azure-Dienste, die man selbst zusammensetzt — der Wiederanlauf ist eine Konstruktionsaufgabe, keine Einstellung. Und die Liste dessen, was dabei in der eigenen Hand bleibt, ist kurz genug, um sie auswendig zu kennen: Session Hosts, Profilverwaltung, Anwendungen, Nutzerdaten, Identitäten. Ein Plan, der nur Maschinen in eine zweite Region bringt, deckt ein Fünftel ab. Dieses Modul behandelt, was ein tragfähiger Plan enthält: warum Metadaten- und Hostregion getrennt zu betrachten sind, warum Cloud Cache beim Ausfall aller Anbieter schlimmer ist als gar kein Cloud Cache, warum Identität die stillste Abhängigkeit ist — und warum der Weg zurück der am häufigsten fehlende Teil ist.

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

Der Satz, der die Erwartung korrigiert

Ein verwalteter Dienst weckt eine Erwartung: Wenn eine Region ausfällt, kümmert sich der Anbieter. Für Azure Virtual Desktop ist diese Erwartung falsch, und die Dokumentation sagt es in einem Satz.

Keine eigenen FunktionenAzure Virtual Desktop hat keine nativen Funktionen für die Bewältigung von Notfallszenarien. Was es gibt, sind andere Azure-Dienste, die man je nach Anforderung selbst zusammensetzt — Verfügbarkeitszonen, Azure Site Recovery, Redundanzoptionen für Dateifreigaben. Der Wiederanlauf ist eine Konstruktionsaufgabe, keine Einstellung.

Was Microsoft trägt, ist die Steuerungsebene: Broker, Gateway, Diagnose, Web-Zugang. Was darunter liegt und was ein Mensch zum Arbeiten braucht, bleibt vollständig in der eigenen Verantwortung.

LernzielDu kannst benennen, welche Komponenten im Notfall selbst wiederhergestellt werden müssen, ein aktiv-passives gegen ein aktiv-aktives Muster abwägen und die Fallen erkennen, die Profile über Regionen hinweg mit sich bringen.

Die fünf Komponenten, die du wiederherstellst

Die Dokumentation listet ausdrücklich auf, was kunden- oder partnerseitig verwaltet wird. Die Liste ist kurz und vollständig genug, um sie auswendig zu kennen.

Session Hosts — die virtuellen Maschinen selbst.
Profilverwaltung, üblicherweise mit FSLogix.
Anwendungen — ob im Abbild, angehängt oder veröffentlicht.
Nutzerdaten — alles, was außerhalb des Profils liegt.
Identitäten der Nutzer.

Die Probe aufs ExempelEin Notfallplan, der nur die Session Hosts in einer zweiten Region vorsieht, deckt genau ein Fünftel ab. Stehen dort keine Profile, keine Anwendungen, keine Daten und keine erreichbaren Verzeichnisdienste, meldet sich zwar jemand an — und findet eine leere Maschine vor.

Drei Begriffe, die nicht dasselbe meinen

Hochverfügbarkeit: Verteilte Infrastruktur, damit kleinere, örtlich begrenzte Störungen nicht die gesamte Bereitstellung unterbrechen. Gut entworfen macht sie einen vollständigen Wiederanlauf oft überflüssig.
Geschäftsfortführung: Wie eine Organisation während einer Störung jeder Größe weiterarbeiten kann.
Wiederanlauf: Der Vorgang, nach einem vollständigen Ausfall zurück in den Betrieb zu kommen.

Die Begriffe werden in Projekten regelmäßig vermischt, und daraus entstehen Pläne, die eine Frage beantworten und für eine andere bezahlt werden. Hochverfügbarkeit kostet dauerhaft und wirkt gegen den kleinen Fall; ein Wiederanlaufplan kostet wenig und greift erst im großen Fall — dafür langsam.

Fehlertoleranz — Eine doppelte Konfiguration oder ein doppeltes System in einer anderen Azure-Region, das während einer Störung die Aufgabe der Hauptkonfiguration übernimmt. Sie verringert die Auswirkung einer örtlich begrenzten Störung — und sie existiert nur, wenn jemand sie gebaut hat.

Warum die Unterscheidung Geld spartDie meisten Störungen sind klein und örtlich begrenzt. Wer dafür Hochverfügbarkeit innerhalb einer Region baut — Verfügbarkeitszonen, mehrere Hosts, ein redundanter Profilspeicher —, deckt den überwiegenden Teil der Fälle ab und braucht den teuren Wiederanlauf nur für den seltenen großen Fall. Umgekehrt hilft eine aufwendige zweite Region nicht gegen einen einzelnen ausgefallenen Host, und genau der kommt häufiger vor.

Die Bausteine, die Azure dafür anbietet

Verfügbarkeitszonen verteilen Maschinen innerhalb einer Region auf getrennte Standorte.
Verfügbarkeitsgruppen verteilen sie innerhalb eines Rechenzentrums auf getrennte Fehlerdomänen.
Azure Site Recovery repliziert Maschinen in eine zweite Region und führt Umschaltung und Rückkehr.
Redundanzoptionen für Dateifreigaben bestimmen, wie oft und wo Profile und Daten liegen.
Session Hosts über mehrere Regionen verteilen die geografische Lage weiter und verringern die Auswirkung einer Regionsstörung.

Die Kostenseite gehört dazuDie Dokumentation formuliert es zurückhaltend und eindeutig: Alle diese Funktionen bieten ein gewisses Maß an Schutz, und man sollte sie sorgfältig zusammen mit ihren Kostenfolgen abwägen. Keine davon ist umsonst, und mehrere zugleich addieren sich.

Für die Session Hosts selbst kommt ein weiterer Baustein hinzu, der oft übersehen wird: Der Drain-Modus ist das Werkzeug, mit dem eine Region kontrolliert geräumt wird. Über Update-AzWvdSessionHost mit AllowNewSession lassen sich die Hosts der primären Region für neue Sitzungen sperren, ohne laufende Arbeit abzuschneiden. Eine Umschaltung, die stattdessen Maschinen abschaltet, beendet Sitzungen mitten in der Arbeit — und genau das will man im Notfall vermeiden, weil die betroffenen Menschen ohnehin schon unter Druck stehen.

Zwei Regionen, die nichts miteinander zu tun haben

Eine Unterscheidung erspart viel Verwirrung: Host Pools, Workspaces und Anwendungsgruppen lassen sich nur in bestimmten Azure-Regionen anlegen — dort liegen ihre Metadaten. Die Session Hosts selbst dürfen in beliebigen Regionen stehen.

Für die Notfallplanung heißt das: Die Region der Metadaten und die Region der Rechenleistung sind getrennt zu betrachten. Ein Plan, der nur Maschinen in eine zweite Region bringt, verlässt den Geltungsbereich der Metadaten nicht — und ein Plan, der für die Metadaten vorsorgen will, braucht dafür eigene Objekte.

Was das praktisch bedeutetEin aktiv-passives Muster besteht deshalb aus mehr als abgeschalteten Maschinen: Es braucht in der zweiten Region Host Pool, Anwendungsgruppen und Workspace als eigene Objekte, dazu Zuweisungen, Profile und erreichbare Verzeichnisdienste. Diese Objekte entstehen nicht im Ernstfall — sie müssen vorher existieren.

Aktiv-passiv oder aktiv-aktiv

Aktiv-passiv: Die zweite Region steht bereit und wird im Ernstfall aktiviert. Günstiger, langsamer, und der Zustand der passiven Seite muss regelmäßig geprüft werden.
Aktiv-aktiv: Beide Regionen tragen im Normalbetrieb Nutzer. Teurer, schneller im Ernstfall — und mit einer Profilfrage, die gelöst sein muss.

Die Wahl folgt der vereinbarten Wiederanlaufzeit. Wer in Minuten wieder arbeiten muss, kommt an einer aktiven zweiten Seite kaum vorbei; wer Stunden hat, kann mit einer passiven auskommen — vorausgesetzt, sie wird regelmäßig erprobt.

Die unangenehme Eigenschaft des passiven MustersEine passive Region wird nur im Ernstfall gebraucht und genau dann zum ersten Mal benutzt. Was dort veraltet ist — ein altes Abbild, eine fehlende Anwendungsversion, ein abgelaufenes Zertifikat, eine nicht nachgezogene Zuweisung —, fällt in dem Moment auf, in dem niemand Zeit dafür hat. Ein passives Muster ohne regelmäßigen Testlauf ist eine Vermutung.

Profile über Regionen: der heikelste Teil

Session Hosts lassen sich duplizieren, Anwendungen lassen sich duplizieren. Der Nutzerzustand nicht — er ist genau einmal vorhanden und muss in beiden Regionen erreichbar und konsistent sein.

Cloud Cache ist der dokumentierte Weg dafür: Der Container läuft lokal auf der Maschine und wird an mehrere entfernte Anbieter abgeglichen, die in verschiedenen Regionen liegen dürfen. Gelesen wird von genau einem Anbieter, geschrieben an alle.

Die Warnung, die den Entwurf prägtKann Cloud Cache Daten von keinem der Anbieter mehr holen, führt das laut Dokumentation zu einer hängenden Sitzung oder schlimmer zu einem Systemabsturz. Redundanz schützt hier also gegen den Ausfall einzelner Anbieter — der gleichzeitige Ausfall aller ist schlimmer als der Verzicht auf Cloud Cache. Für einen Regionsausfall, der genau einen Anbieter trifft, ist das die richtige Wahl; für eine Netztrennung, die alle unerreichbar macht, ist es ein zusätzliches Risiko.

Technisch unterscheidet sich das von der gewohnten Konfiguration an einer Stelle: Statt VHDLocations trägt der Host dann CCDLocations mit den Anbietern in der Reihenfolge ihrer Nähe. Der lokale Zwischenspeicher liegt unter C:\ProgramData\FSLogix\Cache, und das Abmelden verzögert sich, bis alle Anbieter denselben Stand haben — gesteuert über HealthyProvidersRequiredForUnregister und CcdUnregisterTimeout. Wer für den Notfall auf Cloud Cache umstellt, ändert damit das Abmeldeverhalten aller Nutzer im Normalbetrieb.

Für den gleichzeitigen Zugriff aus zwei Umgebungen ist ProfileType der Schalter: 0 steht für normales Verhalten ohne gleichzeitigen Zugriff, 1 und 2 legen eine Maschine auf die schreibende beziehungsweise lesende Rolle fest, 3 versucht die schreibende und fällt auf die lesende zurück. Die Dokumentation verlangt dabei, dass alle beteiligten Sitzungen einen zusammenpassenden Wert tragen, und warnt ausdrücklich davor, 0 mit einem anderen Wert zu mischen. Unabhängig davon unterstützt OneDrive unter keinen Umständen mehrere gleichzeitige Verbindungen auf dasselbe Profil.

Kurzcheck

Zwei regionale Pools sind für den Notfallbetrieb vorbereitet. Nutzer könnten gleichzeitig beide öffnen, während ihre Profile regionsübergreifend abgeglichen werden. Welche Schutzregel ist erforderlich?

Gleichzeitige Anmeldungen desselben Nutzers in beiden Regionen verhindern.
Die Abgleichhäufigkeit erhöhen, damit beide Stände zusammenlaufen.
In der zweiten Region eigene Profile anlegen lassen.
Die zweite Region nur lesend betreiben.

Treffer. Richtig. Ein Profilcontainer verträgt keinen unkontrollierten gleichzeitigen Schreibzugriff aus zwei Umgebungen — die Zuweisung muss zu jedem Zeitpunkt eindeutig auf eine Region zeigen.

Identität ist die stillste Abhängigkeit

Von den fünf kundenseitigen Komponenten ist die Identität diejenige, die in Notfallplänen am häufigsten fehlt — weil sie im Normalbetrieb nie auffällt.

Eine Sitzung kommt erst zustande, wenn mehrere unabhängige Anmeldungen gelingen: am Dienst, am Session Host und am Profilspeicher.
Hosts, die einer Active-Directory-Domäne angehören, brauchen in der zweiten Region erreichbare Domänencontroller.
Smartcard- und Windows-Hello-Anmeldung am Host setzt Kerberos voraus und damit Netzsicht auf ein Key Distribution Center — auch in der Ausweichregion.
Hybride Identitäten setzen eine funktionierende Synchronisierung voraus; fällt sie aus, altern beide Verzeichnisse auseinander.

Der Test, der es aufdecktEin Testlauf, bei dem nur die Maschinen der Ausweichregion gestartet und von einem Administratorkonto geprüft werden, beweist wenig. Aussagekräftig wird er erst, wenn ein regulärer Nutzer sich mit seinem gewohnten Verfahren anmeldet, sein Profil vorfindet und eine Fachanwendung öffnet. Alles andere prüft die Infrastruktur und nicht den Arbeitsplatz.

Ein Sonderfall verdient Erwähnung, weil er im Notfall besonders bitter ist: Wer bei der Anmeldung am Session Host auf Single Sign-on setzt, hängt an zwei Microsoft-Entra-Anwendungen und den Conditional-Access-Richtlinien darauf. Sind diese Richtlinien an Standorte oder an Gerätekonformität gebunden, greifen sie im Notfall anders — Menschen arbeiten dann von anderen Orten und gelegentlich von anderen Geräten. Eine Richtlinie, die den Normalbetrieb sauber absichert, kann so zur Sperre für genau die Situation werden, für die der Plan gedacht war. Notfallpläne gehören deshalb auch gegen die eigenen Zugriffsrichtlinien geprüft, nicht nur gegen die Infrastruktur.

Anwendungen und Daten

Die Anwendungen folgen dem Lieferweg, für den man sich entschieden hat — und jeder Weg hat im Notfall eine eigene Anforderung.

Im Abbild: Die Abbildversion muss in der zweiten Region verfügbar sein. Eine Compute Gallery repliziert dafür, ein einzelnes verwaltetes Abbild nicht.
Dynamisch angehängt: Die Anwendungsfreigabe muss in der zweiten Region erreichbar sein — der Pfad ebenso wie der Inhalt.
Nutzerdaten: Alles außerhalb des Profils braucht einen eigenen Replikationsweg. Dateidienste, Datenbanken und Fachverfahren haben eigene Verfahren.

Ein Namensproblem mit LösungWeil die Anwendungsfreigabe unter demselben Pfad erreichbar sein sollte, empfiehlt die Dokumentation für den Notfallplan ausdrücklich, den Freigabepfad im Ausweichstandort zugänglich zu machen — etwa über einen gemeinsamen Namensraum, der auf verschiedene Freigaben zeigt. Andernfalls müsste im Ernstfall die Konfiguration jedes Pakets geändert werden.

Bei dynamisch angehängten Anwendungen kommt eine zweite Bedingung hinzu: Die Rechte auf der Anwendungsfreigabe gelten dem Computerkonto des Session Hosts. Neue Maschinen in der Ausweichregion bringen neue Computerobjekte mit, und die haben die Berechtigung nicht automatisch. Wer die Rechte an einzelne Computerobjekte vergeben hat statt an eine Gruppe, stellt im Ernstfall fest, dass die Hosts zwar starten und niemand seine Anwendungen bekommt.

Was ein Plan enthalten muss

Wiederanlaufzeit und Datenverlusttoleranz je Pool festlegen→Alle fünf kundenseitigen Komponenten zuordnen→Muster wählen: aktiv-passiv oder aktiv-aktiv→Kapazität in der Ausweichregion sichern→Umschaltung, Kommunikation und Rückkehr beschreiben→Regelmäßig üben und das Ergebnis festhalten

Zusage zuerst, Technik danach

Die Reihenfolge ist nicht beliebig. Wiederanlaufzeit und zulässiger Datenverlust sind geschäftliche Zusagen; sie bestimmen, welches Muster überhaupt in Frage kommt. Wer mit der Technik beginnt, baut eine Lösung und erfährt später, ob sie zur Zusage passt.

Die Kapazitätsfrage im ErnstfallEine Ausweichregion nützt nur, wenn dort im Ernstfall auch Maschinen verfügbar sind. Wer auf Abruf plant, konkurriert im Regionsausfall mit allen anderen, die dasselbe geplant haben. Wer Kapazität reserviert, zahlt dafür dauerhaft. Diese Entscheidung gehört in den Plan und nicht in den Ernstfall.

Zur Zusage gehören zwei Zahlen, die getrennt verhandelt werden: die Wiederanlaufzeit — wie lange es dauern darf, bis wieder gearbeitet wird — und die Datenverlusttoleranz — wie viel Arbeit verloren gehen darf. Beide sind geschäftliche Größen, keine technischen, und beide unterscheiden sich zwischen Nutzergruppen: Ein Callcenter, das ohne Plattform gar nicht arbeiten kann, hat andere Zahlen als eine Abteilung, die zur Not zwei Tage mit lokalen Mitteln überbrückt. Ein einziges Zahlenpaar für die gesamte Plattform ist deshalb fast immer zu teuer oder zu schwach.

Rückkehr ist ein eigener Vorgang

Der am häufigsten fehlende Teil eines Notfallplans ist der Weg zurück. Umgeschaltet wird unter Druck und mit Aufmerksamkeit; zurückgekehrt wird Wochen später, wenn niemand mehr hinsieht.

Während des Notbetriebs entstehen Daten und Profiländerungen in der Ausweichregion — sie müssen mit zurück.
Die primäre Region kann inzwischen veraltet sein: alte Abbildversion, alte Anwendungspakete, alte Zuweisungen.
Die Rückkehr braucht ein eigenes Zeitfenster mit Abmeldungen, genau wie die Umschaltung.
Ohne festgehaltenen Zeitpunkt der Umschaltung lässt sich hinterher nicht sagen, welcher Stand der richtige ist.

Warum das im Plan stehen mussEine Umschaltung ohne geplante Rückkehr führt dazu, dass die Ausweichregion stillschweigend zur neuen primären wird — mit einer Konfiguration, die als Übergangslösung gebaut wurde, und ohne Ausweichregion dahinter. Das ist der häufigste Weg, wie eine Organisation nach einem überstandenen Notfall schlechter dasteht als davor.

Praktisch hilft eine einfache Regel: Die Rückkehr wird wie eine geplante Wartung behandelt und nicht wie das Ende einer Störung. Sie bekommt ein Zeitfenster, eine Ankündigung, einen Drain-Modus in der Ausweichregion und eine Abnahme durch echte Nutzer. Wer sie stattdessen als stillen Schwenk über Nacht durchführt, erzeugt genau die Datenlage, die hinterher niemand mehr auflösen kann.

Was Wiederanlauf kostet

Aktiv-aktiv: Schnellster Wiederanlauf — und doppelte laufende Kosten, doppelte Pflege, dazu die Profilfrage im Normalbetrieb.
Aktiv-passiv mit Reservierung: Kapazität ist im Ernstfall sicher — und wird dauerhaft bezahlt, ohne im Normalbetrieb zu nutzen.
Aktiv-passiv auf Abruf: Günstig — und im Regionsausfall konkurriert man mit allen anderen um dieselben Maschinen.
Cloud Cache über Regionen: Profile überleben den Ausfall eines Anbieters — und jeder Host trägt dauerhaft mehr Platten- und Netzlast.
Regelmäßige Übungen: Der einzige Weg zu einem belastbaren Plan — und jede Übung kostet Arbeitszeit und stört den Betrieb.

Keine dieser Zeilen ist kostenlos, und keine ist verzichtbar, wenn eine Zusage existiert. Der einzige echte Fehler wäre, eine Zusage zu geben und keine der Zeilen zu bezahlen — dann existiert der Plan auf Papier und im Ernstfall nicht.

Der Satz für die LeitungsrundeHochverfügbarkeit ersetzt keine erprobte Wiederanlaufstrategie. Verteilte Maschinen innerhalb einer Region schützen gegen den Ausfall eines Standorts und nicht gegen den Ausfall der Region — und sie sagen nichts darüber, ob Profile, Anwendungen, Daten und Identitäten anderswo verfügbar sind.

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-13