L’application group è l’oggetto che si pubblica

In Azure Virtual Desktop l’host pool è l’insieme dei session host, ma non è ciò che l’utente riceve. L’oggetto pubblicato è l’application group, che appartiene a un solo host pool ed esiste in due tipi: desktop, che consegna la scrivania completa del session host, e RemoteApp, che espone le singole applicazioni in finestre proprie, come se fossero installate sul dispositivo locale. Gli application group vengono poi raccolti in un workspace, ed è il workspace che il client Windows App presenta all’utente come elenco di risorse.

Il punto che l’esame verifica quasi sempre è l’assegnazione: utenti e gruppi si assegnano all’application group, non all’host pool. Chi ha diritti sull’host pool o sulla subscription non per questo vede una risorsa pubblicata; e una risorsa pubblicata in un application group non associato a un workspace resta comunque invisibile nel client.

Un host pool pooled ospita un solo desktop application group, ma più RemoteApp application group. È lo strumento con cui si servono popolazioni diverse dagli stessi session host: stessa infrastruttura, stessa immagine, gruppi di pubblicazione distinti con assegnazioni distinte. Su un host pool personal la pubblicazione naturale è il desktop, perché l’utente ha una VM dedicata e non c’è bilanciamento di carico da sfruttare.

Desktop o RemoteApp: criteri di scelta

Il desktop application group si sceglie quando l’utente lavora interamente nell’ambiente remoto, ha bisogno della shell completa, di molte applicazioni e di un contesto stabile, o quando i dati non devono uscire dall’ambiente gestito. RemoteApp si sceglie quando il dispositivo dell’utente è già gestito e serve solo portare una o poche applicazioni legacy o pesanti: l’attrito percepito è minore e la superficie esposta è ridotta, perché non si consegna la shell.

Il trade-off da tenere presente è che RemoteApp non è “più leggero” lato server: sul session host resta comunque una sessione completa, con lo stesso profilo e lo stesso consumo di risorse. Il risparmio è nell’esperienza e nella superficie, non nel dimensionamento.

Come l’applicazione arriva sul session host

Tre strade, con costi diversi nel tempo. Dentro l’immagine: semplice e prevedibile, ma ogni aggiornamento applicativo diventa una nuova versione di immagine in Azure Compute Gallery e una sostituzione dei session host con drain mode. Va bene per il set di applicazioni comune e stabile. Installazione a posteriori con Intune, Configuration Manager o script di configurazione: disaccoppia l’applicazione dal ciclo dell’immagine, ma introduce deriva fra gli host, che su un host pool pooled significa esperienza incoerente a seconda di dove atterra la sessione.

App attach monta il pacchetto applicativo dinamicamente a runtime da una share condivisa, senza installarlo sull’host: l’applicazione diventa un oggetto gestito a parte, aggiornabile senza toccare l’immagine, e assegnabile a popolazioni diverse sullo stesso host pool. Ha sostituito la vecchia impostazione MSIX app attach. Il prezzo è complessità: servono pacchetti in formato adatto, una share raggiungibile dai session host con i permessi corretti e una gestione delle versioni. Si sceglie quando le popolazioni hanno esigenze applicative divergenti o quando il ciclo di rilascio dell’applicazione è più rapido di quello dell’immagine.

I tre casi speciali che l’esame verifica

Microsoft 365 Apps su un session host multi-session richiede la shared computer activation: senza di essa l’attivazione fallisce o chiede credenziali a ogni sessione, perché il modello per-device non regge più utenti concorrenti sulla stessa macchina.

OneDrive va installato per-machine e configurato per la sottoscrizione silenziosa dell’account; i dati devono vivere nel FSLogix profile container, altrimenti su un host pool pooled la sincronizzazione riparte a ogni accesso su un host diverso. Files On-Demand limita la crescita del container.

Microsoft Teams si ottimizza con il Remote Desktop WebRTC Redirector Service installato sui session host, abbinato a un client supportato: l’elaborazione audio e video viene spostata sul dispositivo dell’utente invece che sul session host. Senza redirection il media viene renderizzato lato host e il traffico compie un percorso in più, con CPU sprecata e qualità peggiore.

Trappole tipiche d’esame

  • L’utente ha permessi sull’host pool ma non vede risorse nel client → assegnalo all’application group: l’RBAC sull’host pool o sulla subscription non pubblica nulla; verifica anche che l’application group sia registrato in un workspace.
  • Due reparti con set di applicazioni diversi sugli stessi host → più RemoteApp application group sullo stesso host pool: non servono due host pool né due immagini, bastano gruppi di pubblicazione con assegnazioni distinte.
  • L’applicazione si aggiorna spesso e non si vuole ricostruire l’immagine → App attach: monta il pacchetto a runtime e disaccoppia il ciclo dell’applicazione da quello dell’immagine, che altrimenti richiede sostituzione degli host in drain mode.
  • Microsoft 365 Apps chiede attivazione a ogni sessione su multi-session → shared computer activation: è un requisito di licensing del modello multi-utente, non si risolve con reinstallazioni o attivazione per-device.
  • I file OneDrive si risincronizzano da zero a ogni accesso su host pool pooled → profilo in FSLogix profile container e installazione per-machine: con profilo locale l’utente atterra ogni volta su un host diverso e riparte da capo.
  • Chiamate Teams con qualità scadente e CPU alta sui session host → Remote Desktop WebRTC Redirector Service: aumentare le dimensioni della VM tratta il sintomo; la redirection sposta l’elaborazione media sul client.