Microsoft AZ-140: Resilienza, ripristino e migrazione — Guida allo studio

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

Fa parte della Microsoft Azure Virtual Desktop Specialty AZ-140 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

La pianificazione della resilienza, del ripristino e della migrazione di Azure Virtual Desktop (AVD) si concentra sul mantenimento della produttività degli utenti in caso di guasti a livello di regione, sulla protezione dei dati (profili, immagini, applicazioni), sull’orchestrazione del failover delle dipendenze e sulla fornitura di una transizione prevedibile dai sistemi legacy Remote Desktop Services (RDS). Una progettazione efficace separa il control plane stateless di AVD dai data plane stateful, utilizza l’automazione ripetibile per le ricostruzioni, definisce chiari obiettivi di ripristino per ogni componente e convalida le prestazioni nel mondo reale con l’analisi e la modellazione della capacità.

Architettura Regionale, Accesso Utente e Failover

Control plane e data plane: i servizi di broker, accesso web, diagnostica e gestione di AVD sono resilienti a livello globale. Gli host di sessione, gli host pool, le immagini e lo storage sono specifici per regione e devono essere progettati per il failover.
Strategia per i guasti a livello di regione:
- Creare un host pool in una regione secondaria per ogni gruppo di utenti con la stessa famiglia di dimensioni delle VM e la stessa derivazione delle immagini. Replicare le immagini nella regione secondaria utilizzando Azure Compute Gallery.
- Pubblicare gruppi di applicazioni identici (RemoteApp e/o Desktop) in entrambe le regioni e assegnare gli utenti a entrambi, impostando il pool primario come predefinito e quello secondario come destinazione di DR.
- Mantenere gli host di DR in uno stato di standby a freddo (cold) o a caldo (warm). Per gli host condivisi (pooled), effettuare uno scale-in a zero o spegnerli, e fare affidamento sui piani di scalabilità e sulla funzione Start VM on Connect per minimizzare i costi in condizioni di regime.
Accesso degli utenti durante i guasti:
- Il servizio AVD instrada le richieste di connessione verso gli host di sessione integri. Quando si imposta l’host pool primario in modalità di drain (svuotamento) o se non è disponibile, le nuove connessioni vengono indirizzate al pool secondario se gli utenti vi sono assegnati.
- Informare gli utenti che le sessioni aperte nella regione guasta verranno disconnesse; la riconnessione avverrà nella regione disponibile.
Parità delle immagini e di MSIX app attach:
- Utilizzare Azure Image Builder e Azure Compute Gallery (SIG) con la replica a livello di regione per le immagini.
- Archiviare i pacchetti MSIX app attach in posizioni di storage resilienti e raggiungibili da entrambe le regioni, e replicare il contenuto nella regione secondaria (ad es., replica tra regioni di ANF o replica dello storage account).
Dipendenze di rete e di identità:
- Assicurarsi che il DNS e l’identità (Active Directory o Azure AD DS) siano raggiungibili da entrambe le regioni. Per Azure AD DS, configurare le impostazioni DNS della VNet sugli IP del dominio gestito in ogni VNet regionale che richiede il join al dominio e la risoluzione dei nomi.
- Convalidare il comportamento di RDP Shortpath tra le regioni; effettuare il fallback alla connessione inversa (reverse connect) se il traffico UDP è bloccato.

Esempio per replicare una versione dell’immagine in due regioni:

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

Obiettivi di Ripristino e Ruoli della Protezione Dati

Definire RTO/RPO distinti per ogni componente:

Host pool e host di sessione:
- Condivisi (Pooled): Trattare gli host di sessione come effimeri. RTO in minuti (re-deployment automatizzato), RPO non applicabile (nessuno stato sull’host). Non fare affidamento sui backup delle VM per il ripristino; effettuare un nuovo deployment dall’immagine e usare l’autoscaling.
- Personali: Se lo stato dell’utente risiede sul disco del sistema operativo, proteggerlo con Azure Backup o Azure Site Recovery (ASR). Preferire il trasferimento dello stato utente sui profili FSLogix per semplificare il DR.
Immagini:
- RPO prossimo allo zero per la disponibilità delle immagini utilizzando la replica di Compute Gallery; RTO in minuti per il deployment di nuovi host. Mantenere le pipeline delle golden image versionate e riproducibili.
Profili e cache di Office (FSLogix):
- RPO: da minuti a ore a seconda della pianificazione della replica e del backup; RTO: minuti per il montaggio nella regione secondaria se Cloud Cache è configurato, altrimenti il tempo necessario per ripristinare il volume/la condivisione e reindirizzare le sessioni.
Applicazioni:
- Per le applicazioni incluse nell’immagine, allinearsi con l’RTO/RPO dell’immagine. Per MSIX app attach, allinearsi con la replica dello storage dei pacchetti e il tempo di nuova registrazione.

Azure Backup e ASR:

Azure Backup:
- Eseguire il backup delle condivisioni Azure Files che ospitano i contenitori dei profili FSLogix e ODFC. Utilizzare snapshot frequenti per raggiungere gli obiettivi di RPO; ripristinare singoli VHD/VHDX o un’intera condivisione. Comunicare che gli snapshot sono crash-consistent mentre gli utenti sono connessi; per ripristini di precisione, eseguire una copia/rinomina fuori banda del contenitore di un utente e istruirlo a effettuare nuovamente il login.
- Eseguire il backup dei dischi del sistema operativo dei desktop personali quando necessario. Gli host condivisi (pooled) generalmente non richiedono il backup delle VM.
Azure Site Recovery:
- Utilizzare ASR per i componenti infrastrutturali stateful critici per AVD (ad es., server di gestione, server di licenza se applicabile, server LOB) e per gli host pool personali quando è necessario preservare lo stato della VM.
- Evitare ASR per gli host AVD condivisi (pooled); il re-deployment dall’immagine/piani di scalabilità è più veloce ed economico.

Resilienza dello Storage dei Profili, Cloud Cache, Backup e Ripristino

Opzioni di storage per FSLogix:
- Azure NetApp Files (ANF): IOPS più elevati/latenza più bassa su larga scala; supporta la replica tra regioni per il DR. Ideale per ambienti molto grandi o con alta concorrenza e richieste di I/O dei profili elevate.
- Azure Files Premium: condivisioni di file PaaS basate su SSD con ZRS per la resilienza all’interno della regione; eccellente equilibrio tra prestazioni e amministrazione. Per il DR tra regioni, combinare con Cloud Cache e backup/ripristino a livello di condivisione o progettare condivisioni a doppia regione.
- Storage Spaces Direct (S2D) su IaaS: da utilizzare solo quando il PaaS non è una soluzione praticabile. Richiede un minimo di tre VM senza Cloud Witness per il quorum. L’overhead operativo è superiore rispetto alle alternative PaaS.
Cloud Cache:
- Configurare più provider (ad es., due endpoint Azure Files o ANF in zone/regioni diverse). Durante un’interruzione a livello di regione, FSLogix continua a funzionare con i provider superstiti, con consistenza finale (eventual consistency) per le scritture memorizzate nella cache.
- Configurazione di esempio:

# 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

Pattern di backup e ripristino:
- Implementare snapshot di Azure Backup ogni ora o ogni poche ore per le condivisioni dei profili. In caso di profilo utente corrotto, isolare il VHDX corrente, ripristinare lo snapshot precedente in una posizione alternativa e copiare o ricollegare il contenitore dell’utente.
- Per ANF, utilizzare snapshot e replica tra regioni; ripristinare a livello di volume o singolo file tramite la directory degli snapshot.
Test:
- Includere la convalida del montaggio/collegamento, simulazioni di corruzione e rollback a livello utente nelle esercitazioni di DR.

Failover del traffico, del DNS e delle dipendenze

Dipendenze delle applicazioni:
- Molte app AVD dipendono da API HTTP/S, front-end web o database. Progettarli con bilanciamento del carico globale e distribuzioni regionali in modo che il failover delle dipendenze non blocchi gli utenti in sessioni altrimenti integre.
Azure Front Door e Traffic Manager:
- Utilizzare Azure Front Door per il bilanciamento del carico globale HTTP/S di livello 7, WAF e routing basato sul percorso delle dipendenze delle app utilizzate dagli utenti AVD. Abbinarlo a backend con ridondanza di zona in ogni regione.
- Utilizzare Azure Traffic Manager per il bilanciamento del carico basato su DNS per endpoint non HTTP esposti pubblicamente e che supportano health probe.
DNS privato e risoluzione dei nomi:
- Centralizzare i server d’inoltro condizionali utilizzando Azure DNS Private Resolver per instradare le query tra on-premise, VNet di Azure e domini gestiti. Pubblicare record con TTL basso per gli endpoint che potrebbero richiedere un failover rapido.
- Per gli endpoint di storage che non possono eseguire il failover nativo in modo trasparente, considerare endpoint con doppio nome astratti dietro un DNS interno per passare dalle condivisioni primarie a quelle di DR durante un incidente.
QoS di rete e accesso:
- Dare priorità al traffico AVD in tempo reale (UDP/TCP) attraverso le WAN; regolare la QoS sui router delle filiali per garantire che le classi di traffico AVD abbiano una larghezza di banda sufficiente a ridurre gli errori di connessione e la latenza.
- Convalidare la raggiungibilità di Shortpath e i pinhole del firewall; assicurarsi che la pianificazione della larghezza di banda in uscita corrisponda alla concorrenza e al mix di carichi di lavoro.

Migrazione da RDS, individuazione, densità e capacità

Valutazione di RDS:
- Inventariare Connection Broker, RD Gateway, RD Web, RD Session Host, licenze RD e file server/archivi di profili. Documentare le GPO, la configurazione di FSLogix e i metodi di distribuzione delle applicazioni.
- Mappare i ruoli sui costrutti AVD: pool di host, aree di lavoro, gruppi di app, archiviazione dei profili e brokering gestito da AVD; eliminare la necessità di RD Gateway e Broker in Azure.
Azure Migrate e individuazione:
- Utilizzare l’appliance Azure Migrate per individuare le VM RDS esistenti, le baseline delle prestazioni e le dipendenze. Identificare le relazioni tra app e server per il posizionamento degli host di sessione AVD e la data gravity.
Analisi della densità degli utenti:
- Costruire modelli di densità per carico di lavoro (utenti task/knowledge/power). Derivare le sessioni per VM utilizzando le baseline di CPU ready, pressione della memoria e I/O del profilo. Convalidare con benchmark pilota su SKU di VM candidate (ad es. Dv5/Esv5/Dasv5, abilitate per GPU per la grafica).
- Utilizzare l’Azure Virtual Desktop Experience Estimator per selezionare le regioni con la latenza più bassa tra utente e host.
Modellazione della capacità:
- Convertire la densità in numero di host per pool con un buffer N+1 e un overhead per la manutenzione. Definire le soglie di scale-out e il numero minimo/massimo di host nei piani di scalabilità. Considerare le prenotazioni di capacità per costi prevedibili e core garantiti nelle regioni più trafficate.
- Assicurarsi che le quote di sottoscrizione e regionali (vCPU, core per famiglia, IP, NIC, dischi) vengano aumentate in anticipo; inviare tempestivamente le richieste di aumento delle quote.

Cutover, Coesistenza, Quote e Runbook

Pianificazione del cutover:
- Eseguire una coesistenza parallela: mantenere RDS operativo mentre AVD integra i gruppi pilota. Pubblicare le stesse app in entrambi i sistemi, ma indirizzare gli utenti per coorte.
- Coorti pilota: iniziare con il reparto IT e gli early adopter, espandere a dipartimenti rappresentativi, quindi procedere con un rollout su larga scala. Utilizzare il feedback per ottimizzare le immagini, le impostazioni di FSLogix e la scalabilità.
- Rollback: mantenere i percorsi di accesso a RDS finché i criteri di accettazione non sono soddisfatti. Mantenere i profili utente retrocompatibili o fornire un percorso di ripristino del profilo per ogni coorte.
Prontezza operativa:
- Chiavi di registrazione: durante l’onboarding di VM esistenti nei pool di host, generare una chiave di registrazione e unirle tramite l’agente AVD; automatizzare tramite Azure Image Builder e script di post-provisioning.
- Igiene di workspace e gruppi di app: pubblicare gruppi di app con privilegi minimi (least-privilege); separare Desktop e RemoteApp; mantenere i gruppi di app di DR assegnati ma visivamente meno evidenti, se necessario.
Runbook e automazione:
- Creare runbook di Business Continuity and Disaster Recovery (BCDR) che coprano:
  - Dichiarazione dell’incidente e messa in modalità di drain dei pool primari.
  - Scalabilità dei pool di DR e verifica della parità delle immagini.
  - Commutazione dello storage dei profili tramite Cloud Cache o reindirizzamento DNS.
  - Convalida delle dipendenze critiche delle app tramite Front Door/Traffic Manager.
  - Comunicazione agli utenti e al service desk.
  - Esecuzione del rollback al ripristino della region primaria.
- Implementare i runbook utilizzando Azure Automation o Functions con controlli degli accessi basati sui ruoli (RBAC) e approvazioni delle modifiche.
Costi e prenotazioni:
- Utilizzare Savings Plans e Prenotazioni di capacità per i carichi di lavoro di base stabili; mantenere la capacità di burst in modalità pay-as-you-go con scalabilità automatica. Pianificare lo spegnimento dei pool non di produzione al di fuori dell’orario di lavoro.

Scenario Pratico

Adobe deve garantire che i team creativi e di supporto possano lavorare ininterrottamente durante un’interruzione regionale mentre migrano da una farm RDS on-premise ad Azure Virtual Desktop, con centinaia di terabyte di profili roaming e carichi di lavoro grafici impegnativi.

Individuazione e baseline

Utilizzare Azure Migrate per inventariare gli host RDS, le condivisioni dei profili e le dipendenze LOB, e per catturare i pattern di CPU/memoria/IO per le coorti grafiche e di supporto.
Perché: Le baseline empiriche guidano la definizione di obiettivi accurati di densità utenti e la selezione delle SKU delle VM, minimizzando il sovradimensionamento (overprovisioning).

Progettazione dell’architettura regionale

Creare pool di host primari in West US 2 con SKU NVadsA v5 abilitate per GPU per i creativi e Dv5 per il supporto; distribuire pool secondari in Central US.
Replicare le immagini tramite Azure Compute Gallery; archiviare i pacchetti MSIX in ANF con la replica tra region.
Perché: Garantisce la parità di calcolo e di app tra le region con prestazioni prevedibili.

Rafforzamento di identità e DNS

Configurare il DNS della VNet sugli IP di Azure AD DS a cui si uniranno i session host; distribuire Azure DNS Private Resolver per inoltrare le query tra on-premise e Azure.
Perché: Una risoluzione dei nomi affidabile tra le region abilita il logon e l’accesso alle app durante il failover.

Implementazione di profili resilienti

Utilizzare Azure NetApp Files per FSLogix con snapshot e replica tra region; abilitare FSLogix Cloud Cache puntando ai volumi ANF primari e di DR.
Perché: ANF fornisce gli IOPS e la latenza richiesti dai creativi; Cloud Cache e la replica tra region (CRR) garantiscono la continuità in caso di guasto di una region.

Orchestrazione del failover delle dipendenze

Esporre le API web LOB tramite Azure Front Door e configurare backend distribuiti a livello regionale; utilizzare Traffic Manager per qualsiasi endpoint pubblico non HTTP.
Perché: Mantiene gli endpoint delle applicazioni raggiungibili da entrambe le region AVD senza necessità di riconfigurazione.

Definizione degli obiettivi di ripristino e della protezione

Impostare un RTO di minuti per gli host in pool (ricostruzione), di ore per i desktop personali (se presenti, protetti da Azure Backup/ASR) e un RPO di 15 minuti per i profili tramite snapshot di ANF; eseguire il backup delle condivisioni Azure Files della coorte di supporto, se utilizzate.
Perché: Obiettivi specifici per componente allineano i costi all’impatto sul business.

Pilotaggio e coesistenza

Eseguire l’onboarding di 100 utenti del supporto e 50 creativi su AVD; mantenere RDS pubblicato in parallelo. Convalidare la densità, la stabilità dei profili e le prestazioni delle app. Iterare le policy di scalabilità e le impostazioni di FSLogix.
Perché: I pilotaggi controllati riducono i rischi legati alle scelte di immagine, storage e scalabilità automatica.

Cutover ed esercitazione di DR

Generare chiavi di registrazione AVD per espandere i pool; assegnare i gruppi di app di DR a tutti gli utenti. Eseguire un’esercitazione di DR: mettere in drain il primario, scalare il DR, convalidare la continuità di Cloud Cache ed eseguire il failover delle dipendenze delle app tramite Front Door.
Perché: Dimostra il funzionamento del failover end-to-end, inclusi profili e dipendenze, prima della migrazione completa.

Quote, prenotazioni e automazione

Aumentare preventivamente le quote regionali di vCPU e GPU; acquistare Prenotazioni di capacità per la baseline di GPU e CPU; implementare runbook di Azure Automation per il drain, la scalabilità, la commutazione dello storage e le comunicazioni.
Perché: Garantisce la capacità durante gli incidenti e rimuove i passaggi manuali da eventi stressanti.

Migrazione completa e piano di rollback

Migrare le coorti rimanenti a ondate nell’arco di due settimane; mantenere l’accesso a RDS come percorso di rollback con chiari gate decisionali per ogni ondata.
Perché: Un cutover graduale riduce il rischio e preserva un fallback immediato in caso di problemi imprevisti.

← Monitoraggio · Tutti i domini

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →