In questo precedente articolo abbiamo visto come la configurazione del Resource Bridge, all’interno di un’infrastruttura Azure Stack HCI, abiliti la possibilità di utilizzare una serie di strumenti più proprietari di Microsoft Azure anche in uno scenario on-premises.
Uno dei più interessanti, per chi lavora con scenari di Virtual Desktop Infrastructure (VDI), è sicuramente la possibilità di implementare una farm Azure Virtual Desktop nella propria infrastruttura on-premises.
AVD vi permette di eseguire macchine virtuali in modalità pool o personal, ovvero ad accesso multiplo o dedicato, con sistemi operativi Windows Client o Windows Server, così come pubblicare applicazioni da far usare ai vostri utenti, senza doverle installare localmente su ogni device.
La VDI è una pratica potenzialmente interessante ma dipende molto dallo scenario di uso. Se la mia idea è quella di non investire soldi in device (desktop / notebook), posso pensare di spostare il budget in questa soluzione. I pro sono la centralizzazione, la possibilità di erogare il servizio anche fuori dal proprio territorio, l’ottimizzazione delle risorse ed una semplificazione generale, ma anche un aumento della sicurezza. Il contro è dato dal fatto che fuori dalla propria azienda, gli utenti hanno bisogno di un endpoint per collegarsi (es. un portatile personale o tablet) che non è detto abbiano; inoltre, serve sempre una connessione Internet.
Quindi, interessante ma, indipendentemente dal vendor usato, va valutato con attenzione.
Azure Stack HCI consente di creare un pool basato su Azure Virtual Desktop mantenendo la componente di front-end e gateway in cloud, lasciando on-premises le macchine virtuali, che poi se vogliamo sono quelle che impattano realmente sul billing mensile.
Configurazione
Prima di iniziare la configurazione, è fondamentale aver già implementato il Resource Bridge che attivare la connessione tra il vostro ambiente Azure Stack HCI e Microsoft Azure. Non a caso, appena fatta questa operazione, potrete selezionare il Deploy della farm AVD.
Attualmente il deployment è basato su un template ARM, quindi non c’è un wizard guidato.
Le due figure riportano un esempio di come configurare il pool. Mancano ovviamente i dati del local admin, del dominio a cui fare join e delle credenziali per farlo.
Altri aspetti importanti:
- CPU Count: il numero di processori per ogni VM
- RAM: la quantità di memoria assegnata per ogni VM, che oggi è statica
- VM Number of Instances: il numero di VM da creare per il pool
- VM Name Prefix: il prefisso di come chiamare le VM
Nota: attenzione al prefisso VM, perchè questo valore non deve superare i 10 caratteri, dato che poi il sistema ci attacca un progressivo (es. -0 / -1) oltre al fatto che è usato come nome per la join a dominio.
Ci sono ancora tre valori che vanno parametrizzati e che devono essere recuperati con il loro JSON:
- Virtual Network ID: la rete da usare
- Image ID: l’immagine di Windows da usare
- Custom Location ID: dove posizionare il pool
Per ognuno di questi tre elementi, dovrete cliccare sul loro oggetto e visualizzare lo schema JSON.
Nel mio caso sto utilizzando la versione di Windows 11 Enterprise Multi-Session, che consente di accedere in più sessioni remote.
Dopo circa 20/30 minuti, a seconda della complessità del pool creato, sarete pronti per lavorare sui vostri client. Ricordate che il wizard andrà ad installare anche il componente di Azure Arc per permettere la gestione delle risorsa dal portale Azure.
Pre-Publishing
Prima di pubblicare il pool agli utenti, è bene preparare le singole macchine virtuali per una gestione centralizzata al meglio. Il primo passo è la configurazione di FSLogix, perchè Windows 11 Multi-Session ha al suo interno questo componente a dir poco fondamentale per la gestione in pool delle sessioni. Oltre ad aggiornare l’agent con l’ultima versione, è necessario creare delle GPO per definire un path di rete dove salvare i profili utenti, le eventuali esclusioni e tutto il necessario per un’ottimizazione corretta.
L’ultimo aspetto è quello di assegnare il pool creato ad un gruppo di utenti. Questa operazione la si fa direttamente dalla sezione Azure Virtual Desktop (Application group).
Il gruppo deve esistere sia on-premises che in cloud, quindi sincronizzato tramite Azure AD Connect.
Publish
Non rimane che provare quanto fatto e per farlo è necessario usare il client Remote Desktop scaricabile dal Microsoft Store o dal sito Microsoft, accedendo con delle credenziali valide e che soprattutto siano sincronizzate con Azure AD Connect, tra on-premises e cloud.
I Limiti della Preview
Trattandosi ancora di una soluzione in preview, non conosciamo i prezzi finali di utilizzo. Inoltre, non è possibile fare lo scaling automatico delle VM, non possiamo accendere le VM alla prima connessione utente e altre piccole cose. Il dettaglio lo trovate all’interno di questo articolo – Azure Virtual Desktop for Azure Stack HCI (preview) overview | Microsoft Learn
Conclusioni
Azure Virtual Desktop non è sicuramente una tecnologia nuova, ma la possibilità di utilizzarlo all’interno di Azure Stack HCI apre nuovi scenari di implementazione e di gestione degli ambienti VDI da parte delle aziende, soprattutto per chi vuole sfruttare al meglio il cloud ibrido.