Dal portale agli oggetti in gioco

Il primo deployment conviene farlo dal portale, non perché sia il modo corretto di andare in produzione, ma perché obbliga a vedere gli oggetti che compongono l’ambiente: l’host pool (pooled o personal), i session host che ci vivono dentro, l’application group di tipo desktop o RemoteApp collegato all’host pool, il workspace che raccoglie gli application group e li pubblica, e le assegnazioni degli utenti — che si fanno sull’application group, non sull’host pool. Il wizard del portale in realtà compone e sottomette un template ARM: è la stessa cosa che si farà a mano dopo, con meno controllo. Serve a imparare il modello dati, non a governarlo.

Imperativo e dichiarativo: il criterio è la ripetibilità

Azure PowerShell (modulo Az.DesktopVirtualization) e Azure CLI (extension desktopvirtualization) sono strumenti imperativi: descrivono azioni. Sono la scelta giusta per le operazioni puntuali e per l’ordinaria amministrazione — mettere in drain un host, leggere le sessioni attive, disconnettere un utente, rigenerare un token, ciclare su un elenco di host per una manutenzione. Sono anche il collante nelle pipeline, per i passaggi che dipendono da uno stato runtime.

Template ARM e file Bicep sono dichiarativi: descrivono lo stato finale desiderato e lo riapplicano in modo idempotente. Bicep ha la stessa semantica di ARM con sintassi più leggera, moduli riusabili e un’anteprima delle modifiche prima dell’applicazione; ARM in JSON resta quando si eredita materiale esistente o quando un tool lo richiede. La scelta non è di gusto: se una cosa va rifatta identica — un host pool per region, un ambiente di test gemello, la ricostruzione dopo un disastro, la crescita periodica del pool — sta in un template versionato. Se è un’azione una tantum su oggetti già esistenti, sta in uno script. La combinazione tipica è template per la topologia, script per il post-deploy.

Registration token, agent e nascita di un session host

Aggiungere un session host è composto da due metà distinte. Da un lato la VM: immagine, rete, dominio o join a Microsoft Entra ID. Dall’altro la registrazione nell’host pool, che è un fatto del servizio, non della VM. Il ponte fra le due è il registration token, generato a livello di host pool con una scadenza definita al momento della creazione: l’agent installato sull’host lo consuma per registrarsi, dopodiché la relazione host–host pool è stabilita e il token non serve più. Un token scaduto è la causa più banale di un host che non compare nell’host pool o resta non disponibile, e la risposta è rigenerarlo, non ricreare la VM. Nei template il token entra come parametro sensibile, quindi ogni espansione del pool richiede di produrne uno valido prima di lanciare il deployment.

Drain mode e le impostazioni che si regolano dopo

Il drain mode impedisce nuove sessioni su un session host senza toccare quelle in corso: l’host smette di ricevere utenti dal load balancing e si svuota da solo, man mano che le sessioni terminano. È lo strumento con cui si sostituisce un host in un pool pooled — nuova versione dell’immagine nell’Azure Compute Gallery, nuovi host registrati, drain sui vecchi, comunicazione agli utenti, rimozione — anziché applicare patch manuali host per host.

Le impostazioni dell’host pool si toccano dopo il deployment e in buona parte valgono solo sui pooled: algoritmo di bilanciamento breadth-first o depth-first, limite di sessioni per host (che è ciò che rende sensato il depth-first), custom RDP properties, assegnazione di uno scaling plan, Start VM on Connect. Su un host pool personal non esiste bilanciamento né limite di sessioni: c’è solo il tipo di assegnazione, automatica o diretta. Il validation environment marca un host pool come destinatario anticipato degli aggiornamenti del servizio: si applica a un pool separato con utenti pilota, per intercettare le regressioni prima della produzione.

Trappole tipiche d’esame

  • Espandere un host pool creato settimane prima → rigenerare il registration token: quello usato al primo deployment è scaduto; l’agent non registra e l’host non compare. Non è un problema di immagine né di rete.
  • Aggiornare l’immagine di un host pool pooled senza disconnettere gli utenti → drain mode e sostituzione degli host: si mettono in drain i vecchi, si attende lo svuotamento, si rimuovono. Il drain non espelle le sessioni attive, e il patching manuale host per host non è la risposta attesa.
  • Ricreare lo stesso ambiente in più region o subscription → template ARM o Bicep in pipeline: uno script PowerShell one-off non è ripetibile né verificabile. Viceversa, “svuota questi tre host stanotte” è imperativo, non dichiarativo.
  • Ridurre il limite di sessioni su un host pool personal → non esiste: personal significa un session host per utente, senza bilanciamento e senza max session limit. Se lo scenario chiede quel controllo, l’host pool deve essere pooled.
  • Provare in anticipo gli aggiornamenti del servizio → validation environment su un host pool dedicato: mai attivarlo sul pool di produzione, che è esattamente l’ambiente da proteggere.
  • Gli utenti non vedono il desktop dopo un deployment riuscito → assegnazione all’application group: gli utenti si assegnano al gruppo, e il gruppo deve essere pubblicato in un workspace. L’host pool non è un oggetto a cui si assegnano persone.