Microsoft AZ-140: Resilienz, Wiederherstellung und Migration — Lernleitfaden

By Laurynas Brazys · 12 August 2026 · #microsoft #az-140 #certification #exam-prep #study-guide

Teil des Microsoft Azure Virtual Desktop Specialty AZ-140 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Die Planung von Resilienz, Wiederherstellung und Migration für Azure Virtual Desktop (AVD) konzentriert sich auf die Aufrechterhaltung der Benutzerproduktivität bei regionalen Ausfällen, den Schutz von Daten (Profile, Images, Anwendungen), die Orchestrierung des Failovers von Abhängigkeiten und die Bereitstellung eines vorhersagbaren Übergangs von älteren Remote Desktop Services (RDS). Effektive Designs trennen die zustandslose AVD-Steuerungsebene von den zustandsbehafteten Datenebenen, verwenden wiederholbare Automatisierung für Neuinstallationen, definieren klare Wiederherstellungsziele für jede Komponente und validieren die Leistung in der Praxis durch Discovery und Kapazitätsmodellierung.

Regionale Architektur, Benutzerzugriff und Failover

Steuerungs- und Datenebenen: Die Broker-, Web-Access-, Diagnose- und Verwaltungsdienste von AVD sind global resilient. Sitzungshosts, Hostpools, Images und Speicher sind regionalspezifisch und müssen für ein Failover ausgelegt sein.
Strategie für regionale Ausfälle:
- Erstellen Sie einen Hostpool in einer sekundären Region pro Benutzerkohorte mit der gleichen VM-Größenfamilie und Image-Abstammung. Replizieren Sie Images mit der Azure Compute Gallery in die sekundäre Region.
- Veröffentlichen Sie identische Anwendungsgruppen (RemoteApp und/oder Desktop) in beiden Regionen und weisen Sie Benutzer beiden zu, wobei der primäre Pool als Standard und der sekundäre als DR-Ziel festgelegt wird.
- Halten Sie DR-Hosts in einem Cold- oder Warm-Standby-Status. Bei gepoolten Hosts skalieren Sie auf null herunter oder schalten Sie sie aus und verlassen Sie sich dann auf Skalierungspläne und „Start VM on Connect“, um die Kosten im Normalbetrieb zu minimieren.
Benutzerzugriff bei Ausfällen:
- Der AVD-Dienst leitet Verbindungsanfragen an fehlerfreie Sitzungshosts weiter. Wenn Sie den primären Hostpool in den Drain-Modus versetzen oder er nicht verfügbar ist, werden neue Verbindungen an den sekundären Pool vermittelt, sofern die Benutzer dort Zuweisungen haben.
- Informieren Sie die Benutzer darüber, dass offene Sitzungen in der ausgefallenen Region getrennt werden; eine erneute Verbindung wird mit der verfügbaren Region hergestellt.
Parität von Images und MSIX App Attach:
- Verwenden Sie Azure Image Builder und Azure Compute Gallery (SIG) mit regionaler Replikation für Images.
- Speichern Sie MSIX App Attach-Pakete an resilienten Speicherorten, die in beiden Regionen erreichbar sind, und replizieren Sie den Inhalt in die sekundäre Region (z. B. ANF Cross-Region Replication oder Replikation von Speicherkonten).
Netzwerk- und Identitätsabhängigkeiten:
- Stellen Sie sicher, dass DNS und Identität (Active Directory oder Azure AD DS) von beiden Regionen aus erreichbar sind. Konfigurieren Sie für Azure AD DS die VNet-DNS-Einstellungen auf die IPs der verwalteten Domäne in jedem regionalen VNet, das einen Domänenbeitritt und eine Namensauflösung erfordert.
- Validieren Sie das RDP Shortpath-Verhalten über Regionen hinweg; greifen Sie auf Reverse Connect zurück, wenn UDP behindert wird.

Beispiel für die Replikation einer Image-Version in zwei Regionen:

az sig image-version create \
  --resource-group rg-avd-images \
  --gallery-name sig-avd \
  --gallery-image-definition win11-ms \
  --gallery-image-version 1.0.3 \
  --target-regions eastus=1 westus=1

Wiederherstellungsziele und Rollen der Datensicherung

Definieren Sie unterschiedliche RTO/RPO pro Komponente:

Hostpools und Sitzungshosts:
- Gepoolt: Behandeln Sie Sitzungshosts als ephemer (kurzlebig). RTO beträgt Minuten (automatisierte Neuverteilung), RPO ist N/A (kein Host-Zustand). Verlassen Sie sich zur Wiederherstellung nicht auf VM-Backups; stellen Sie aus einem Image neu bereit und nutzen Sie Autoscaling.
- Persönlich: Wenn der Benutzerzustand auf der Betriebssystemfestplatte liegt, schützen Sie ihn mit Azure Backup oder Azure Site Recovery (ASR). Bevorzugen Sie die Auslagerung des Benutzerzustands in FSLogix-Profile, um die Notfallwiederherstellung (DR) zu vereinfachen.
Images:
- RPO nahe Null für die Image-Verfügbarkeit durch Compute Gallery-Replikation; RTO von Minuten für die Bereitstellung neuer Hosts. Halten Sie Golden-Image-Pipelines versioniert und reproduzierbar.
Profile und Office-Caches (FSLogix):
- RPO: Minuten bis Stunden, abhängig von Replikations- und Backup-Zeitplänen; RTO: Minuten für das Mounten in der sekundären Region, wenn Cloud Cache konfiguriert ist, andernfalls die Zeit, die für die Wiederherstellung des Volumes/der Freigabe und die Neuzuweisung der Sitzungen benötigt wird.
Anwendungen:
- Bei Anwendungen im Image richten Sie sich nach dem RTO/RPO des Images. Bei MSIX App Attach richten Sie sich nach der Replikation des Paketspeichers und der Zeit für die Neuregistrierung.

Azure Backup und ASR:

Azure Backup:
- Sichern Sie Azure Files-Freigaben, die FSLogix-Profil- und ODFC-Container hosten. Verwenden Sie häufige Snapshots, um RPO-Ziele zu erreichen; stellen Sie einzelne VHD/VHDX oder eine vollständige Freigabe wieder her.
- Kommunizieren Sie, dass Snapshots absturzkonsistent sind, während Benutzer angemeldet sind; für präzise Wiederherstellungen führen Sie ein Out-of-Band-Kopieren/Umbenennen des Containers eines Benutzers durch und weisen Sie den Benutzer an, sich erneut anzumelden.
- Sichern Sie bei Bedarf die Betriebssystemfestplatten von persönlichen Desktops. Gepoolte Hosts erfordern im Allgemeinen keine VM-Backups.
Azure Site Recovery:
- Verwenden Sie ASR für zustandsbehaftete Infrastrukturkomponenten, die für AVD kritisch sind (z. B. Verwaltungsserver, Lizenzserver falls zutreffend, LOB-Server) und für persönliche Hostpools, wenn die Beibehaltung des VM-Zustands erforderlich ist.
- Vermeiden Sie ASR für gepoolte AVD-Hosts; eine Neuverteilung aus Image-/Skalierungsplänen ist schneller und kostengünstiger.

Resilienz des Profilspeichers, Cloud Cache, Backup und Wiederherstellung

Speicheroptionen für FSLogix:
- Azure NetApp Files (ANF): Höchste IOPS/niedrigste Latenz bei Skalierung; unterstützt Cross-Region Replication für DR. Ideal für sehr große Umgebungen oder hohe Gleichzeitigkeit und hohe IO-Anforderungen an Profile.
- Azure Files Premium: SSD-gestützte PaaS-Dateifreigaben mit ZRS für Resilienz innerhalb einer Region; ausgezeichnete Balance zwischen Leistung und Verwaltung. Für regionenübergreifendes DR kombinieren Sie es mit Cloud Cache und Backup/Restore auf Freigabeebene oder entwerfen Sie Freigaben in zwei Regionen.
- Storage Spaces Direct (S2D) auf IaaS: Nur verwenden, wenn PaaS nicht realisierbar ist. Erfordert ein Minimum von drei VMs ohne Cloud Witness für das Quorum. Der Betriebsaufwand ist höher als bei PaaS-Alternativen.
Cloud Cache:
- Konfigurieren Sie mehrere Anbieter (z. B. zwei Azure Files- oder ANF-Endpunkte in verschiedenen Zonen/Regionen). Während eines regionalen Ausfalls arbeitet FSLogix mit den überlebenden Anbietern weiter, mit Eventual Consistency für zwischengespeicherte Schreibvorgänge.
- Beispielkonfiguration:

# PowerShell on session host
New-Item -Path HKLM:\SOFTWARE\FSLogix\Profiles -Force | Out-Null
New-ItemProperty HKLM:\SOFTWARE\FSLogix\Profiles -Name Enabled -Type DWord -Value 1 | Out-Null
New-ItemProperty HKLM:\SOFTWARE\FSLogix\Profiles -Name CCDLocations -Type String `
  -Value "type=smb,connectionString=\\files-pri.file.core.windows.net\profiles;type=smb,connectionString=\\files-dr.file.core.windows.net\profiles" | Out-Null
New-ItemProperty HKLM:\SOFTWARE\FSLogix\Profiles -Name DeleteLocalProfileWhenVHDShouldApply -Type DWord -Value 1 | Out-Null

Backup- und Wiederherstellungsmuster:
- Implementieren Sie stündliche oder alle paar Stunden stattfindende Azure Backup-Snapshots für Profilfreigaben. Bei einem beschädigten Benutzerprofil isolieren Sie die aktuelle VHDX, stellen den vorherigen Snapshot an einem alternativen Ort wieder her und kopieren oder hängen den Container des Benutzers neu an.
- Für ANF verwenden Sie Snapshots und Cross-Region Replication; stellen Sie auf Volume-Ebene oder einzelne Dateien über das Snapshot-Verzeichnis wieder her.
Tests:
- Beziehen Sie Validierungen für das Mounten/Anhängen, Korruptionssimulationen und Rollbacks auf Benutzerebene in DR-Übungen ein.

Datenverkehr, DNS und Failover von Abhängigkeiten

Anwendungsabhängigkeiten:
- Viele AVD-Anwendungen sind von HTTP/S-APIs, Web-Frontends oder Datenbanken abhängig. Architektieren Sie diese mit globalem Load Balancing und regionalen Bereitstellungen, damit ein Failover von Abhängigkeiten Benutzer nicht in ansonsten fehlerfreien Sitzungen blockiert.
Azure Front Door und Traffic Manager:
- Verwenden Sie Azure Front Door für globales HTTP/S Layer-7 Load Balancing, WAF und pfadbasiertes Routing von Anwendungsabhängigkeiten, die von AVD-Benutzern verwendet werden. Kombinieren Sie dies mit zonenredundanten Backends in jeder Region.
- Verwenden Sie Azure Traffic Manager für DNS-basiertes Load Balancing für Nicht-HTTP-Endpunkte, die öffentlich zugänglich sind und Health Probes unterstützen.
Privates DNS und Namensauflösung:
- Zentralisieren Sie bedingte Weiterleitungen (conditional forwarders) mit Azure DNS Private Resolver, um Abfragen zwischen lokalen Umgebungen (on-premises), Azure VNets und verwalteten Domänen zu routen. Veröffentlichen Sie Einträge mit niedriger TTL für Endpunkte, die ein schnelles Failover erfordern könnten.
- Für Speicherendpunkte, die kein nahtloses natives Failover unterstützen, ziehen Sie Endpunkte mit doppelten Namen in Betracht, die hinter internem DNS abstrahiert sind, um während eines Vorfalls zwischen primären und DR-Freigaben (shares) zu wechseln.
Netzwerk-QoS und Zugriff:
- Priorisieren Sie den Echtzeit-AVD-Datenverkehr (UDP/TCP) über WANs; passen Sie QoS auf Routern in Zweigstellen an, um sicherzustellen, dass AVD-Datenverkehrsklassen über ausreichende Bandbreite verfügen, um Verbindungsfehler und Latenz zu reduzieren.
- Validieren Sie die Erreichbarkeit von Shortpath und Firewall-Pinholes; stellen Sie sicher, dass die Planung der ausgehenden Bandbreite (egress bandwidth) der Gleichzeitigkeit und dem Workload-Mix entspricht.

Migration von RDS, Discovery, Dichte und Kapazität

RDS-Bewertung:
- Inventarisieren Sie Connection Brokers, RD Gateways, RD Web, RD Session Hosts, RD Licensing und Dateiserver/Profilspeicher. Dokumentieren Sie GPOs, die FSLogix-Konfiguration und die Methoden zur Anwendungsbereitstellung.
- Ordnen Sie Rollen den AVD-Konstrukten zu: Hostpools, Workspaces, App-Gruppen, Profilspeicher und AVD-verwaltetes Brokering; eliminieren Sie die Notwendigkeit für RD Gateway und Broker in Azure.
Azure Migrate und Discovery:
- Verwenden Sie die Azure Migrate Appliance, um bestehende RDS-VMs, Leistungs-Baselines und Abhängigkeiten zu ermitteln (discover).
- Identifizieren Sie App-zu-Server-Beziehungen für die Platzierung von AVD-Sitzungshosts und die Data Gravity.
Analyse der Benutzerdichte:
- Erstellen Sie Dichtemodelle pro Workload (Task-/Knowledge-/Power-User). Leiten Sie die Anzahl der Sitzungen pro VM (sessions-per-VM) anhand von CPU Ready, Memory Pressure und Profil-IO-Baselines ab.
- Validieren Sie dies mit Pilot-Benchmarks auf Kandidaten-VM-SKUs (z. B. Dv5/Esv5/Dasv5, GPU-fähig für Grafik).
- Verwenden Sie den Azure Virtual Desktop Experience Estimator, um Regionen mit der niedrigsten Latenz vom Benutzer zum Host auszuwählen.
Kapazitätsmodellierung:
- Wandeln Sie die Dichte in die Anzahl der Hosts pro Pool um, einschließlich eines N+1-Puffers und Wartungs-Overheads.
- Definieren Sie Schwellenwerte für das Scale-Out sowie die minimale/maximale Anzahl von Hosts in Skalierungsplänen. Ziehen Sie Kapazitätsreservierungen für vorhersagbare Kosten und garantierte Cores in stark ausgelasteten Regionen in Betracht.
- Stellen Sie sicher, dass die Abonnement- und regionalen Kontingente (vCPU, Cores pro Familie, IPs, NICs, Disks) im Voraus erhöht werden; reichen Sie Anträge auf Kontingenterhöhung frühzeitig ein.

Umstellung, Koexistenz, Kontingente und Runbooks

Umstellungsplanung:
- Parallele Koexistenz betreiben: RDS in Betrieb halten, während AVD Pilotbenutzer aufnimmt. Dieselben Apps in beiden Systemen veröffentlichen, aber die Benutzer nach Kohorten steuern.
- Pilot-Kohorten: Mit der IT und Early Adopters beginnen, auf repräsentative Abteilungen ausweiten, dann breiter Rollout. Feedback nutzen, um Images, FSLogix-Einstellungen und die Skalierung anzupassen.
- Rollback: RDS-Zugriffspfade beibehalten, bis die Akzeptanzkriterien erfüllt sind. Benutzerprofile abwärtskompatibel halten oder einen Pfad zum Zurücksetzen der Profile pro Kohorte bereitstellen.
Betriebsbereitschaft:
- Registrierungsschlüssel: Beim Onboarding bestehender VMs in Host-Pools einen Registrierungsschlüssel generieren und über den AVD-Agenten beitreten; dies über Azure Image Builder und Post-Provisioning-Skripte automatisieren.
- Hygiene bei Workspaces und App-Gruppen: App-Gruppen mit den geringsten Rechten (Least Privilege) veröffentlichen; Desktop und RemoteApp trennen; DR-App-Gruppen zugewiesen lassen, aber bei Bedarf visuell unauffällig gestalten.
Runbooks und Automatisierung:
- Business Continuity und Disaster Recovery (BCDR) Runbooks erstellen, die Folgendes abdecken:
  - Ausrufen eines Incidents und Versetzen der primären Pools in den Drain-Modus.
  - Skalieren der DR-Pools und Überprüfen der Image-Parität.
  - Umschalten des Profilspeichers über Cloud Cache oder DNS-Neuausrichtung.
  - Validieren kritischer App-Abhängigkeiten über Front Door/Traffic Manager.
  - Kommunikation mit Benutzern und dem Service Desk.
  - Rollback, wenn die primäre Region wiederhergestellt ist.
- Runbooks mit Azure Automation oder Functions implementieren, unter Verwendung von rollenbasierter Zugriffskontrolle und Genehmigungen für Änderungen.
Kosten und Reservierungen:
- Savings Plans und Capacity Reservations für stabile Basis-Workloads verwenden; Burst-Kapazitäten auf Pay-as-you-go-Basis mit Autoscaling belassen. Nicht-Produktions-Pools so planen, dass sie außerhalb der Geschäftszeiten heruntergefahren werden.

Praktisches Problemszenario

Adobe muss sicherstellen, dass Kreativ- und Support-Teams während eines regionalen Ausfalls kontinuierlich arbeiten können, während sie von einer On-Premises-RDS-Farm zu Azure Virtual Desktop migrieren. Dabei gibt es Hunderte von Terabytes an Roaming-Profilen und anspruchsvolle Grafik-Workloads.

Ermittlung und Baseline-Erstellung

Azure Migrate verwenden, um RDS-Hosts, Profil-Freigaben und LOB-Abhängigkeiten zu inventarisieren und CPU-/Speicher-/IO-Muster für die Grafik- und Support-Kohorten zu erfassen.
Warum: Empirische Baselines ermöglichen genaue Ziele für die Benutzerdichte und die Auswahl der VM-SKU, wodurch eine Überprovisionierung minimiert wird.

Entwurf der regionalen Architektur

Primäre Host-Pools in West US 2 mit GPU-fähigen NVadsA v5 für Kreative und Dv5 für den Support erstellen; sekundäre Pools in Central US bereitstellen.
Images über die Azure Compute Gallery replizieren; MSIX-Pakete in ANF mit cross-region replication speichern.
Warum: Stellt Rechen- und App-Parität über Regionen hinweg mit vorhersagbarer Leistung sicher.

Identität und DNS härten

VNet-DNS auf die Azure AD DS-IPs konfigurieren, mit denen sich die Sitzungshosts in die Domäne einbinden; Azure DNS Private Resolver bereitstellen, um Abfragen zwischen On-Premises und Azure weiterzuleiten.
Warum: Eine zuverlässige Namensauflösung über Regionen hinweg ermöglicht die Anmeldung und den App-Zugriff während eines Failovers.

Implementierung robuster Profile

Azure NetApp Files für FSLogix mit Snapshots und cross-region replication verwenden; FSLogix Cloud Cache aktivieren, der auf die primären und DR-ANF-Volumes verweist.
Warum: ANF liefert die von Kreativen benötigten IOPS/Latenz; Cloud Cache und CRR gewährleisten die Kontinuität bei einem Ausfall einer Region.

Failover von Abhängigkeiten orchestrieren

LOB-Web-APIs mit Azure Front Door versehen und regional bereitgestellte Backends konfigurieren; Traffic Manager für alle nicht-HTTP-basierten öffentlichen Endpunkte verwenden.
Warum: Hält Anwendungsendpunkte von jeder AVD-Region aus ohne Neukonfiguration erreichbar.

Wiederherstellungsziele und Schutzmaßnahmen festlegen

RTO in Minuten für gepoolte Hosts (Neuaufbau), in Stunden für persönliche Desktops (falls vorhanden, geschützt durch Azure Backup/ASR) und ein RPO von 15 Minuten für Profile über ANF-Snapshots festlegen; Azure Files-Freigaben der Support-Kohorte sichern, falls verwendet.
Warum: Komponentenspezifische Ziele richten die Kosten am geschäftlichen Einfluss aus.

Pilotbetrieb und Koexistenz

100 Support-Benutzer und 50 Kreative auf AVD onboarden; RDS parallel veröffentlicht lassen. Dichte, Profilstabilität und App-Leistung validieren. Skalierungsrichtlinien und FSLogix-Einstellungen iterativ anpassen.
Warum: Kontrollierte Pilotprojekte reduzieren das Risiko bei der Auswahl von Images, Speicher und Autoscaling.

Umstellung und DR-Übung

AVD-Registrierungsschlüssel generieren, um Pools zu erweitern; allen Benutzern DR-App-Gruppen zuweisen. Eine DR-Übung durchführen: primären Pool in den Drain-Modus versetzen, DR-Pool skalieren, die Kontinuität von Cloud Cache validieren und ein Failover der App-Abhängigkeiten über Front Door durchführen.
Warum: Beweist das End-to-End-Failover, einschließlich Profilen und Abhängigkeiten, vor der vollständigen Migration.

Kontingente, Reservierungen und Automatisierung

Regionale vCPU- und GPU-Kontingente vorab erhöhen; Capacity Reservations für die Basislast von GPU und CPU erwerben; Azure Automation Runbooks für Drain, Skalierung, Speicherumschaltung und Kommunikation implementieren.
Warum: Garantiert Kapazität während Incidents und eliminiert manuelle Schritte in stressigen Situationen.

Vollständige Migration und Rollback-Plan

Verbleibende Kohorten in Wellen über zwei Wochen migrieren; RDS-Zugriff als Rollback-Pfad mit klaren Entscheidungspunkten pro Welle beibehalten.
Warum: Eine schrittweise Umstellung reduziert das Risiko und bewahrt einen sofortigen Fallback, falls unerwartete Probleme auftreten.

← Überwachung · Alle Domänen

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →