Scegliere la base e decidere cosa ci va dentro

Il primo bivio è tra un’immagine di marketplace e una golden image personalizzata. Le immagini di marketplace per Azure Virtual Desktop, incluse le varianti multi-session con Microsoft 365 Apps preinstallate, sono mantenute da Microsoft: la scelta corretta quando le applicazioni si distribuiscono a runtime e vuoi ridurre il lavoro operativo. La custom image si giustifica quando esistono componenti che devono essere presenti prima del primo logon, o quando l’installazione a caldo sarebbe troppo lenta o fragile.

Dentro l’immagine metti ciò che è comune a tutti gli utenti e stabile nel tempo: applicazioni condivise e pesanti da installare, agenti di gestione, sicurezza e monitoraggio, ottimizzazioni per il multi-session, il client FSLogix, il Remote Desktop WebRTC Redirector Service per l’ottimizzazione di Microsoft Teams, i language pack. Microsoft 365 Apps installate in immagine su multi-session richiedono la shared computer activation.

Fuori dall’immagine resta tutto ciò che cambia più in fretta dell’immagine stessa o riguarda un sottoinsieme di utenti: le applicazioni di reparto, che vanno bene per App attach o per un application group RemoteApp; le impostazioni e le policy, che si applicano con Intune o Group Policy; i dati utente, che vivono nel FSLogix profile container; segreti, credenziali e domain join, che appartengono al deployment e non all’immagine.

Costruire: manuale contro Azure VM Image Builder

La strada manuale parte da una VM, installa e configura, poi generalizza il sistema prima della cattura. È veloce la prima volta e ingestibile dalla terza: nessuna tracciabilità, risultati diversi a ogni giro, dipendenza da chi l’ha costruita.

Azure VM Image Builder risolve il problema descrivendo la personalizzazione come codice, in un custom image template: una source (immagine di marketplace, managed image o versione già in gallery), una sequenza di customization, e uno o più target di distribuzione. Il template è versionabile in un repository e richiamabile da una pipeline, quindi la stessa immagine si ricostruisce identica su una base aggiornata. È il criterio che l’esame premia: ripetibilità e auditabilità, non velocità del singolo build.

L’Azure Compute Gallery è il contenitore di distribuzione. La gerarchia è gallery, image definition e image version: la definition fissa le caratteristiche strutturali, tra cui generazione di VM, security type e stato del sistema operativo (generalized o specialized), che devono combaciare con la configurazione dei session host da creare. Le version sono i rilasci successivi della stessa immagine.

La gallery replica le version verso più region, e dove supportato anche verso zone diverse: la replica va tenuta nella region dell’host pool, altrimenti il deployment è lento o fallisce. Il numero di repliche conta quando crei molti session host in parallelo. Nel creare gli host puoi puntare a una version specifica, per determinismo e rollback prevedibile, oppure a “latest”, per prendere automaticamente l’ultima al prossimo provisioning.

Ciclo di vita e strategia di aggiornamento

Su un host pool pooled i session host sono usa e getta: non li aggiorni, li sostituisci. Il flusso corretto è costruire una nuova image version, provisionare nuovi session host da quella version, mettere i vecchi in drain mode perché non accettino nuove sessioni, attendere che si svuotino, e infine rimuoverli. Il drain mode è ciò che rende l’operazione trasparente per chi sta lavorando. Sui pool personal la logica si rovescia: l’host è dedicato e conserva stato dell’utente, quindi si aggiorna in place con gli strumenti di patching, non si ricicla.

Trappole tipiche d’esame

  • Aggiornare le applicazioni su un host pool pooled senza disturbare gli utenti → nuova image version, nuovi host, drain mode sui vecchi: applicare patch host per host è la risposta sbagliata anche quando sembra la più rapida.
  • Nuova version pubblicata con riferimento “latest” e i session host esistenti restano invariati → “latest” agisce solo al provisioning: pubblicare non aggiorna nulla di già creato.
  • Applicazione usata solo da un reparto → App attach o application group RemoteApp, non l’immagine: metterla in immagine obbliga a ricostruire tutto a ogni suo aggiornamento.
  • Build ripetibile, versionata e integrabile in pipeline → Azure VM Image Builder con custom image template: snapshot manuali e cattura a mano non danno ripetibilità.
  • Deployment di molti host lento o fallito in una region → repliche della image version nella region (e zona) di destinazione: la gallery non serve i deployment da una region remota in modo efficiente.
  • Host pool personal da aggiornare → patching in place, non sostituzione: ricreare gli host distrugge lo stato locale che l’assegnazione dedicata presuppone.