• Cloud, Guide, Sistemi Operativi
• 3 Marzo 2021

Windows Virtual Desktop è un servizio completo di virtualizzazione di desktop e applicazioni che viene eseguito nel cloud. È possibile connettersi da qualsiasi dispositivo tramite un’applicazione nativa oppure tramite il client Web HTML5 di Windows Virtual Desktop.

Sicuramente negli ultimi mesi questo tipo di soluzione ha avvantaggiato parecchio il lavoro remoto sicuro e molte aziende lo stanno utilizzando per ospitare macchine Windows 10, usando le licenze esistenti per ridurre i costi con un’infrastruttura VDI (Virtual Desktop Infrastructure) moderna basata sul cloud e pagando solo per le risorse usate. Grazie alla multisessione di Windows 10, è possibile eseguire facilmente più sessioni interattive simultanee degli utenti con la stessa distribuzione, per incrementare l’efficienza dei costi, e l’offerta di Microsoft 365 completa l’approccio al Modern Desktop: sicuro, flessibile ed efficiente.

Avevo già avuto modo di parlare della soluzione quasi due anni fa nell’articolo Windows Virtual Desktop – Il Desktop As A Service di Microsoft – ICT Power, in tempi non sospetti e quando era ancora in preview. La soluzione è ormai matura ed è già utilizzata da moltissime aziende.

È anche vero che tantissime aziende utilizzano i Remote Desktop Services, ma molte si stanno avvicinando alla soluzione Windows Virtual Desktop per ottimizzare efficienza e costi di gestione.

Io oggi voglio proporvi proprio questo tipo di migrazione, cioè il passaggio dall’on-premises al cloud delle soluzioni Remote Desktop Services (RDS).

Figura 1: Architettura di Windows Virtual Desktop

L’approccio alla migrazione di Remote Desktop Services (RDS) verso Azure Windows Virtual Desktop potrebbe essere di due tipi:

1. GreenField: In Informatica si riferisce all’approccio tale per cui è preferibile creare una soluzione parallela a quella già esistente, completamente nuova;
2. BrownField: È invece riferito alla creazione del nuovo sistema in coesistenza con quello già esistente e ne possa permettere successivamente la migrazione.

Se volete dare un’occhiata alla soluzione GreenField potete confrontare la mia guida Configurare i Remote Desktop Services in Azure Windows Virtual Desktop.

In questa guida mi occuperò della soluzione BrownField, evidenziando la possibilità di migrare le macchine RD Session Host esistenti direttamente nell’infrastruttura di Windows Virtual Desktop.

È infatti possibile utilizzare Azure Migrate, di cui avevo già trattato nella guida Migrazione delle macchine virtuali VMware verso Microsoft Azure con l’utilizzo di Azure Migrate – ICT Power, per migrare anche l’infrastruttura VDI o RDS.

Figura 2: Utilizzo di Azure Migrate per la migrazione dell’infrastruttura VDI o RDS

Architettura proposta

La soluzione proposta è quella di portare tutte le VM o le macchine fisiche in Azure, compresi i Domain Controller. In alternativa si potrebbe anche pensare ad una soluzione ibrida in cui parte del workload rimane ancora on-premises, come ad esempio i domain controller, e grazie ad una connessione VPN Site-To-Site con Azure oppure con ExpressRoute la nostra rete aziendale diventa un tutt’uno con il Cloud. Alla fine è come se considerassimo il Cloud una nostra sede remota.

Figura 3: Architettura proposta: Migrazione del workload RDS su Azure

Processo di migrazione

Il processo di migrazione si articola in diverse fasi:

1. Verifica di tutti i prerequisiti necessari per poter migrare l’ambiente esistente. In particolar modo è necessario avere:
   1. Una sottoscrizione di Azure con un credito sufficiente (necessario per ospitare le risorse).
   2. Assicurarsi che la rete virtuale in Azure (VNET) sia configurata in modo tale che le nuove macchine virtuali possano contattare il controller  di dominio o i servizi di dominio di Azure AD (Azure AD Domain Services).
   3. Assicurarsi che tutte le risorse di Azure si trovino nella stessa regione di Azure.
   4. Verificare che i servizi di dominio, Active Directory o Azure Active Directory Domain Services, siano sincronizzati con Azure Active Directory (Azure AD). Verificare che il servizio del dominio sia accessibile dalla sottoscrizione di Azure e dalla rete virtuale da connettere in cui verrà distribuito Windows Virtual Desktop.
   5. Avere uno storage account dove poter replicare le VM.
2. Configurare un progetto di migrazione con Azure Migrate.
3. Valutare l’ambiente RDS corrente.
4. Effettuare un assessment per capire quante risorse utilizza l’infrastruttura RDS e come viene utilizzata dagli utenti.
5. Replicare le macchine RDS locali in Azure.
6. Testare che la replica sia avvenuta in maniera corretta.
7. Completare la migrazione.

Figura 4: Processo di migrazione di un’infrastruttura VDI/RDS a Windows Virtual Desktop

Figura 5: Checklist per la migrazione a Windows Virtual Desktop

Gestione degli utenti

Uno dei prerequisiti più importanti è che i servizi di dominio, Active Directory o Azure Active Directory Domain Services, siano sincronizzati con Azure Active Directory (Azure AD). Nel mio caso ho sincronizzato la mia Active Directory locale con Azure Active Directory (Azure AD) utilizzando il tool Azure AD Connect.

Figura 6: Sincronizzazione della Active Directory locale con Azure AD utilizzando il tool Azure AD Connect

Figura 7: Utenti sincronizzati con Azure AD

Creazione di un nuovo progetto di Azure Migrate

Azure Migrate è un tool gratuito che permette di individuare le risorse nel datacenter, effettuare l’analisi dell’idoneità delle macchine per la migrazione verso il Azure, stima dei costi e visualizzazione delle dipendenze delle app, nel caso in cui abbiate delle applicazioni multi-tier. Gli strumenti a disposizione permettono di velocizzare il trasferimento rapido in modalità lift-and-shift e hanno l’obiettivo di farvi risparmiare, suggerendovi le dimensioni ottimali per le vostre risorse cloud.

Dal portale di Azure cercate la funzionalità Azure Migrate e, come si può vedere dalle figure sotto, noterete che è disponibile il nodo VDI,  che è l’opzione per la valutazione e la migrazione dei server RDS oppure delle macchine Windows Client.

Figura 8: Scheda Overview di Azure Migrate

Figura 9: Opzione VDI in Azure Migrate

Cliccate su Create project e inserite le informazioni richieste, facendo attenzione a scegliere di voler tenere i dati di progetto in Europa. Impostate la sottoscrizione, il gruppo di risorse, il nome del progetto e la geografia per i dati del progetto di migrazione. Qui verranno messi solo i vostri dati di progetto; successivamente potrete decidere dove mettere le macchine da replicare e da migrare.

Figura 10: Creazione del progetto di migrazione

Microsoft si avvale della collaborazione del partner Lakeside per effettuare un assessment completo dell’infrastruttura esistente on-premises. Durante il processo di assessment vengono collezionate molte informazioni relative al vostro ambiente, che vi potranno aiutare successivamente a scegliere le risorse (e quindi gestire i costi) della vostra infrastruttura di Windows Virtual Desktop. Vi invito a dare un’occhiata alla sessione di Ignite Accelerate your RDS and VDI migration to Windows Virtual Desktop dove è stata presentata la soluzione, per avere un’idea delle potenzialità del prodotto.

Figura 11: Lakeside assessment integration

Se volete utilizzare Lakeside Assessment Tool è necessario prima registrarsi. Nelle schermate sotto sono mostrati tutti i passaggi, che non necessitano di spiegazioni.

Figura 12: Registrazione del Lakeside Assessment Tool con Azure Migrate

Figura 13: Creazione di una nuova utenza in Lakeside

Figura 14: Autenticazione con le proprie credenziali di Azure AD

Figura 15: Richiesta di autorizzazione da parte di Lakeside ad utilizzare la vostra utenza di Azure AD

Figura 16: Conferma dell’utenza scelta

Figura 17: Completamento informazioni di registrazione a Lakeside

Al termine del processo di registrazione vi apparirà un messaggio che vi avviserà che la vostra richiesta di integrazione è stata presa in carico e che un amministratore di Lakeside dovrà approvarla.

Figura 18: Un amministratore di Lakeside dovrà approvare la vostra richiesta

Se la registrazione sarà stata accettata vi basterà collegarvi al tool direttamente da Azure Migrate, potrete creare un nuovo tenant e iniziare a valutare l’ambiente RDS locale. Scaricando il client sarà possibile iniziare a distribuirlo nella propria infrastruttura ed iniziare a collezionare i dati.

Figura 19: Dashboard di Lakeside Assessment tool – Credits: Microsoft

Una volta acquisita una quantità di dati adeguata, esaminate i dati per determinare il percorso di migrazione migliore. I dati raccolti sono:

• Numero di utenti
• Applicazioni utilizzate dagli utenti.
• Consumo di risorse per utente.
• Media di utilizzo delle risorse da persona utente.
• Dati sulle prestazioni del server RDS.
• Report utenti simultanei.
• Principali pacchetti software in uso.

Nel mio ambiente di test non ho effettuato nessun assessment, ma il risultato finale, dopo aver utilizzato il tool SysTrack di Lakeside sarà simile a quello mostrato nella figura sotto:

Figura 20: Report di Systrack di Lakeside – Credits: Microsoft

Migrazione degli RD Session Host esistenti

Come già detto prima, in questa guida mi occuperò di affrontare lo scenario BrownField e di riutilizzare gli RD Session Host disponibili in azienda perpoter creare un template con cui creare la mia soluzione di Windows Virtual Desktop. Per iniziare la migrazione delle macchine (lift-and-shift), da Azure Migrate, nel nodo VDI, cliccate su Discover e iniziate la procedura per trovare le macchine on-premises da migrare. Il wizard vi guiderà con la richiesta del tipo di virtualizzazione utilizzate in casa e della Region di destinazione delle VM. Io ho utilizzato delle macchine ospitate in Hyper-V.

Figura 21: Inizio del Discover delle VM presenti on-premises

Figura 22: Scelta del tipo di virtualizzatore utilizzato on-premises

NOTA: La procedura mostrata di seguito è valida se utilizzate Hyper-V on-premises. Nel caso utilizziate VMware, abbiate macchine fisiche o dobbiate migrare da AWS o GCP la procedura sarà diversa.

A questo punto verrà creato una Azure Recovery Services Vault all’interno del quale verranno replicate le vostre VM. Scaricate il client di Azure Site Recovery e della chiave per la sua successiva attivazione.

Figura 23: Download del client di replica di Azure Site Recovery

Terminato il download del client, provvedete alla sua installazione, come mostrato nelle figure sotto:

Figura 24: Azure Site Recovery Setup Provider per Hyper-V

Figura 25: Cartella di installazione di Azure Site Recovery Setup Provider per Hyper-V

A questo punto del wizard dovete utilizzare il file con le chiavi di accesso al vostro Azure Site Recovery Vault, che avete scaricato precedentemente dal portale di Azure Migrate.

Figura 26: Inserimento delle credenziali per l’accesso ad Azure Site Recovery Vault

Figura 27: Installazione del Azure Site Recovery Setup Provider per Hyper-V completata

Il passaggio successivo consiste nel terminare la procedura di aggiunta del vostro server on-premises. Cliccate su Finalize registration e attendete qualche minuto per il completamento della procedura.

Figura 28: Finalizzazione della procedura di registrazione dei server on-premises

Figura 29: La procedura di finalizzazione richiede qualche minuto

Figura 30: Finalizzazione della procedura di registrazione dei server on-premises completata

Nel giro di qualche minuto verrà effettuato il Discover dell’infrastruttura on-premises e sarete pronti per migrare le vostre VM.

NOTA: Assicuratevi di aver già creato una VNET ed uno Storage Account dove mettere la replica delle VM. Il wizard di replica, infatti, non vi permetterà di crearli al momento. Le due risorse devono essere già esistenti.

Cliccate sul pulsante Replicate per iniziare la procedura di replica delle VM.

Figura 31: Inizio della procedura di replica delle VM

Figura 32: Scelta del tipo di virtualizzatore utilizzato on-premises

Nella schermata successiva decidete quali VM volete portare nel Cloud. L’obiettivo di questa guida è quello di poter riutilizzare l’RD Session Host che abbiamo on-premises come macchina di partenza per la creazione dei Session Host da utilizzare per il nostro pool di Windows Virtual Desktop. Quindi mi basta selezionare solo UN RD Session Host.

NOTA: Scegliete quali macchine portare in cloud secondo le vostre necessità. Se avete una connessione VPN Site-To-Site oppure una ExpressRoute con Azure potete lasciare ancora parte delle macchine on-premises. Se volete migrare completamente la vostra infrastruttura allora potete decidere di portare i domain controller, i file server, ecc.

Figura 33: Scelta delle VM da replicare in Azure

Figura 34: Inserimento delle informazioni relative alla sottoscrizione, al resource group, alla VNET e allo storage account dove mettere le VM

Decidete quale dimensione deve avere la VM oppure lasciate decidere ad Azure Migrate, secondo le informazioni che avrà raccolto. Scegliete anche il tipo di sistema operativo che è installato nella VM.

Figura 35: Scelta della dimensione delle VM

Figura 36: Scelta dei dischi da replicare

Figura 37: Schermata di riepilogo ed avvio della replica delle VM

Figura 38: Stato di avanzamento della replica delle VM

Al termine della replica della VM (ci sono volute alcune ore) ho cliccato su Test migration per assicurarmi che la migrazione sia andata a buon fine. Ho scelto a quale virtual network collegare la macchina virtuale, in modo tale da potermici poi successivamente connettere e verificare che tutto funzionasse in maniera corretta.

Figura 39: Inizio del test di migrazione della VM

NOTA: la virtual network a cui collegare la VM deve essere già esistente. Vi consiglio di utilizzare una virtual network non collegata alla rete di produzione perché altrimenti vi ritroverete due host con lo stesso nome nella rete. Sarebbe anche il caso di avere nella rete di test un domain controller da poter utilizzare per le autenticazioni.

Figura 40: Scelta della virtual network a cui collegare la VM, per effettuare i test.

Figura 41: Avvio della VM per poter effettuare il test di migrazione

Noterete a questo punto che è stata creata una nuova macchina virtuale a cui vi potrete collegare per effettuare tutte le prove di funzionamento, come mostrato nella figura sotto:

Figura 42: VM di test creata

Collegatevi quindi la macchina virtuale ed effettuate tutte le prove che ritenete necessarie.

Figura 43: Collegamento alla VM per il test di migrazione

Terminati tutti i test potete quindi ritornare nel pannello di Azure Migrate e utilizzare il tasto Clean up test migration per completare la procedura di test e per distruggere la macchina di testa che era stata creata.

Figura 44: Completamento del test di migrazione e pulizia delle risorse di test create

Figura 45: Conferma della pulizia delle risorse di test

Migrazione della VM

Terminati tutti i test sarà possibile migrare la macchina virtuale utilizzando il tasto Migrate. Partirà una procedura che vi guiderà nell’operazione di lift-and-shift e di accensione della macchina in Azure. Come si può vedere dalle figure sotto l’operazione è molto semplice e non necessita di spiegazioni.

Figura 46: Migrazione della VM per l’accensione nel Cloud

Figura 47: Conferma della migrazione

Figura 48: Avvio della migrazione

L’operazione di accensione della macchina in Azure (Planned failover) dura veramente pochissimi minuti.

Figura 49: L’operazione di planned failover viene completata in pochissimi minuti

A questo punto è possibile interrompere la replica e completare la migrazione. Verrà fermata la macchina on-premises e verrà anche interrotta la replica con la macchina accesa in Azure. Dal pannello di Azure Migrate fate clic su Stop replication.

Figura 50: interruzione della replica tra la VM on-premises e quella migrata in Azure

Figura 51: Conferma dell’interruzione della replica

Figura 52: L’operazione dura qualche minuto

Adesso la vostra macchina è stata completamente migrata in Azure, ma sarà ancora capace di parlare con l’infrastruttura on-premises grazie al collegamento tra la virtual network e la vostra azienda, realizzato con una VPN Site-to-Site oppure con ExpressRoute.

Figura 53: La VM è operativa ed è perfettamente funzionante

Cattura dell’immagine della VM da utilizzare come template per la creazione dei Session Host di Windows Virtual Desktop

Scopo di questa guida è quello di poter utilizzare uno degli RD Session Host come immagine di partenza per la creazione del nostro pool di Windows Virtual Desktop. Prima di utilizzare il session host migrato è necessario però generalizzare l’immagine con il tool sysprep e successivamente spegnerla, in modo tale che possa essere catturata e riutilizzata come immagine. Collegatevi quindi alla macchina accesa in Azure e lanciate il tool Sysprep.exe con l’opzione di Shutdown.

Figura 54: Utilizzo del tool Sysprep per la generalizzazione dell’immagine

Nel giro di pochi istanti la macchina verrà generalizzata e spenta, pronta per poter essere trasformata in una Immagine.

Cliccate sul tasto Capture per trasformare la vostra macchina virtuale migrata in un’immagine da poter successivamente riutilizzare.

Figura 55: Cattura dell’immagine della VM

Inserite le informazioni richieste nel wizard, scegliete in quale Resource Group mettere l’immagine e decidete se condividerla all’interno di una Shared Image Gallery oppure utilizzarla come immagine gestita. Ho già avuto modo di trattare l’argomento delle Shared Image Gallery nella guida Creazione di una Shared Image Gallery in Microsoft Azure – ICT Power

Figura 56: Cattura della VM e creazione dell’immagine

Al termine della cattura della creazione della nuova immagine la VM di partenza verrà cancellata, come si può vedere nelle notifiche mostrate nella figura sotto:

Figura 57: Cattura dell’immagine completata

Figura 58: L’immagine è presente nel Resource Group scelto

Creazione di un Windows Virtual Desktop Host Pool

Siamo quindi finalmente pronti per poter creare il nostro pool di macchine virtuali a cui poi gli utenti potranno connettersi. Dal portale di Azure cerchiamo la voce Windows Virtual Desktop e clicchiamo sul pulsante Create a host pool.

Figura 59: creazione di un Windows Virtual Desktop Host pool

Nella scheda Basic inserite tutte le informazioni richieste e scegliete il tipo di host pool da creare. Poiché noi vogliamo creare un pool di Session Host scegliete come tipo Pooled e decidete il numero massimo di sessioni che potrà accettare. È possibile definire anche il metodo di bilanciamento del carico sui vari Session Host ed è possibile scegliete tra due modalità:

• Breadth-first: questa modalità (che è quella impostata di default) esegue prima una query sugli host e seleziona quindi il Session Host con il minor numero di sessioni;
• Depth-first: i nuovi utenti vengono assegnati al primo host disponibile una volta che quello precedente ha superato il numero massimo di sessioni;

Figura 60: Configurazioni di base per il Windows Virtual Desktop Host Pool

Nella scheda Virtual Machines scegliete il prefisso che verrà assegnato alle VM che verranno create e l’immagine da utilizzare. Ovviamente utilizzate l’immagine che avete generato dal vostro Session Host migrato, come mostrato nella figura sotto. In Number of VMs specificare il numero di macchine virtuali (al massimo 400) che si vuole creare per il pool di host.

Figura 61: Scelta dell’immagine da utilizzare per la creazione dei Session Host

Scegliete a quale virtual network connettere l’host pool, assicurandovi che la rete virtuale possa connettersi al domain controller, poiché sarà necessario joinare le macchine virtuali al dominio aziendale. I server DNS della rete virtuale selezionata devono essere quindi configurati per l’uso degli indirizzi IP dei controller di dominio.

Se volete permettere l’accesso da Internet potete dare un IP pubblico alle VM. Vi consiglio di selezionare No, perché un IP privato è più sicuro. Gli utenti, infatti, si potranno collegare anche da Internet attraverso il client di Windows Virtual Desktop anche se non assegnare un indirizzo IP pubblico alle macchine che compongono l’Host Pool.

Specificate il dominio della vostra infrastruttura a cui devono essere aggiunte le VM che saranno create e inserite le credenziali corrette per effettuare il join.

Figura 62: Completamento delle informazioni richieste per la creazione dell’Host Pool

Nella schermata Workspace è possibile registrare un gruppo di applicazioni che saranno poi utilizzate dai nostri utenti. Scegliere quindi se volete creare una nuova area di lavoro o selezionare un’area di lavoro esistente.

Figura 63: Creazione del Workspace

Figura 64: Verifica delle informazioni inserite

Dopo aver fatto clic su Create verrà lanciato il processo di distribuzione, che creerà:

• Un nuovo pool di host.
• Un gruppo di app desktop.
• Un’area di lavoro, se si è scelto di crearla.
• Se si sceglie di registrare il gruppo di app desktop, la registrazione verrà completata.
• Le macchine virtuali, che verranno aggiunte al dominio e registrate con il nuovo pool di host.
• Un collegamento di download per un template di Azure Resource Manager in base alla configurazione che avete scelto.

Figura 65: Creazione del nuovo Windows Virtual Desktop Host Pool

Nella schermata sotto è possibile verificare tutte le risorse di Azure che sono state create:

Figura 66: Risorse di Azure che sono state create

Connessione a Windows Virtual Desktop

Prima che i vostri utenti possano connettersi a Windows Virtual Desktop è necessario assegnare gli utenti al Desktop Application Group (DAG) che è stato creato attraverso l’HostPool wizard. Il nome è in genere <HostPoolname>-DAG. Selezionate il Desktop Application Group dal pannello di Azure e nel nodo Assignment procedete ad aggiungere gli utenti , o meglio ancora i gruppi, che potranno accedere alle applicazioni offerta dal Windows Virtual Desktop Host Pool.

Figura 67: Aggiunta di utenti e gruppi che potranno acceder al Desktop Application Group

Figura 68. Utenti aggiunti al Desktop Application Group

Connessione al Windows Virtual Desktop Host Pool

Per poter accedere a Windows Virtual Desktop è possibile utilizzare il client web HTML 5 disponibile all’indirizzo https://rdweb.wvd.microsoft.com/arm/webclient oppure è possibile utilizzare i client Windows dedicati, che potete trovare alla pagina Connettersi a desktop virtuale Windows 10 o 7-Azure | Microsoft Docs. Potete installare il client per l’utente corrente, nel qual caso non sono richiesti diritti di amministratore, oppure l’amministratore può installare e configurare il client in modo che tutti gli utenti del dispositivo possano accedervi. Dopo l’installazione, il client può essere avviato dal menu Start cercando Desktop remoto.

Nel mio caso ho utilizzato il client web e dopo l’autenticazione mi sono collegato al WorkSpace che avevo creato durante il wizard. L’unica applicazione disponibile è quella che permette di collegarsi alla sessione desktop remota. In alternativa potete pubblicare le applicazioni e utilizzare le RemoteApp.

Figura 69: Connessione a Windows Virtual Desktop effettuata

Inserite le credenziali per poter accedere al desktop remoto e sarete pronti per cominciare a lavorare!

Figura 70: Inserimento delle credenziali per poter accedere al desktop remoto

Figura 71: Richiesta di consentire l’accesso alle stampanti locali e ai dischi del dispositivo da cui si sta effettuando la connessione

Quando la connessione verrà instaurata, potrete lavorare col vostro Desktop remoto e potrete accedere a tutte le risorse, anche a quelle on-premises grazie alle connessioni VPN Site-To-Site oppure grazie ad ExpressRoute. Nella figura sotto l’utente ha l’accesso al file server aziendale.

Figura 72: Connessione effettuata ed utilizzo delle risorse di rete aziendali

Conclusioni

Windows Virtual Desktop consente di lavorare in maniera remota e sicura e permette di sfruttare la scalabilità del Cloud per semplificare la distribuzione e la gestione dell’infrastruttura. La migrazione delle risorse esistenti on-premises è molto semplificata grazie ad Azure Migrate e la migrazione dell’infrastruttura esistente può essere effettuata con pochi passaggi ed in brevissimo tempo.