5 importanti prerequisiti per il deployment Windows Virtual Desktop (WVD)
Cosa fare per iniziare ad approcciare alla tecnologia
Una domanda che si pongono molti MSP che approcciano Windows Virtual Desktop (WVD) è: “Cosa devo fare per iniziare?”
In questo articolo, andiamo a vedere i prerequisiti di Windows Virtual Desktop, utili per approcciare la tecnologia.
L’assunto fondamentale da cui partire per affrontare questo articolo è che implementerete Windows Virtual Desktop utilizzando Windows 10 Enterprise multi-session desktop OS e non Windows Server 2019 con RDS (in realtà è anch’esso supportato tecnicamente).
Per iniziare, dovete avere a disposizione i seguenti elementi:
1. Sottoscrizione a Windows 10 Enterprise per ogni utente WVD;
2. Tenant Azure Active Directory (AAD);
3. Deployment di Active Directory Domain Services (AD DS);
4. Sottoscrizione Azure;
5. File Server.
1. Sottoscrizione a Windows 10 Enterprise
WVD Management Service e Windows 10 desktop OS sono licenziati tramite una sottoscrizione a Windows 10 Enterprise.
I seguenti piani di licensing lo comprendono:
– Microsoft 365 – E3/E5/A3/A5/Business
– Windows (via CSP) – E3/E5/A3/A5
Tenete presente che le versioni Windows 10 Professional, OEM o e le altre versioni senza sottoscrizione Windows non sono autorizzate ad utilizzare WVD.
Potete acquistare una sottoscrizione ai prodotti elencati attraverso i canali: CSP, EA, MCA ecc.
La stessa licenza autorizza l’utente a cui è assegnata a connettersi a molteplici desktop WVD sia che si tratti di Windows 10 Enterprise multi-session, single-session e addirittura Windows 7.
2. Tenant Azure Active Directory (AAD)
Per distribuire e gestire WVD in qualità di amministratore ed assegnare gli utenti a desktop ed applicazioni dovete avere un tenant Azure AD.
AAD è il servizio di directory del cloud di Microsoft. Rappresenta l’oggetto di più alto livello di gerarchia quando si parla di Microsoft Cloud services (O365, D365 ed Azure).
Tutte le identità sono legate ad un tenant AAD che è generalmente associato ad un unico domain name: tenant.onmicrosoft.com. È anche un oggetto legato ai concetti di “Directory” o “Account”.
Se state già utilizzando Office 365, per definizione, avete un tenant Azure AD ed è il tenant di cui avete bisogno per implementare WVD.
Quando vi registrate su Office 365, viene creato un tenant AAD. Dovete avere un account Global Administrator che abbia accesso al tenant AAD.
Il tenant AAD è gratuito: rappresenta la directory di utenti, gruppi, contatti e altri servizi.
I membri di un tenant AAD possono essere pagati. Ad esempio, ad un utente all’interno di AAD potrebbe essere assegnata una licenza Office 365 e quella licenza va pagata.
Vi sono anche degli add-on a pagamento per AAD. Ad esempio, le Azure Active Directory Premium (P1 e P2) sono licenze per utente che estendono le funzionalità di AAD con feature avanzate quali la multi-factor authentication (MFA) ed il conditional access (CA).
La buona notizia è che, per quanto riguarda il WVD, la questione è semplice: il vostro tenant Office 365 è un tenant Azure AD nella maggior parte degli scenari poichè è lì che gli oggetti verranno assegnati ai desktops reside.
3. Deployment di Active Directory Domain Services
Mentre Azure AD è un contenitore di oggetti dell’utente, l’attuale session host di WVD – la virtual machine che esegue Windows 10 Enterprise multi-session – deve essere collegato ad una foresta Active Directory Domain Services (AD DS).
Chiariamo le singole tecnologie per non creare confusione:
– Active Directory Domain Services (AD DS) – spesso chiamato “Active Directory”
a) Ruolo di Active Directory su una macchina tradizionale Windows Server che viene gestita con strumenti quali Active Directory Users e Computer, Sites e Services, Domains eTrusts.
b) Contiene utenti, gruppi, contatti e oggetti computer.
c) Windows desktop e server tradizionali collegati a AD DS.
d) Utenti e Gruppi possono essere sincronizzati con Azure AD utilizzando ADConnect.
– Azure Active Directory (AAD) – servizio di Microsoft Cloud Directory
a) Nonostante il nome ricordi l’Active Directory, si tratta di un servizio diverso ospitato da Microsoft e rappresenta l’oggetto di massimo livello all’interno del cloud Microsoft (O365, D365 ed Azure).
b) Contiene utenti, gruppi e oggetti relativi ai contatti.
c) I computer Windows 10 possono collegarsi a AAD mentre le macchine con vecchi sistemi operativi non possono.
d) Può essere sincronizzato con un AD DS attraverso lo strumento ADConnect: potete usare le medesime username e password.
– Azure Active Directory Domain Services (AAD DS)
a) Si tratta di un AD DS Microsoft ospitato su Azure.
b) La maggior parte delle funzionalità corrispondono ad un tradizionale AD DS on premises con alcune limitazioni dovute alla mancanza di un accesso amministrativo all’attuale domain controller.
c) Si sincronizza con AAD (che è sincronizzato con un AD DS on-premises) e permette alle VM in esecuzione su Azure di effettuare il join indipendentemente dal tipo di sistema operativo Windows (Windows 10/8/7 o Server 2008/2012/2016/2019).
Perchè tutti questi dettagli? WVD richiede che la sessione che ospita le VM (desktop VMs) sia collegata sia ad AD DS che ad AAD DS.
Questo significa che dovete avere un deployment di Active Directory accessibile alla sessione WVD che ospita le VM. Non è possibile usare soltanto l’AAD per un deployment WVD.
Punto fondamentale: con WVD avete bisogno sia di AAD (che contiene oggetti dell’utente) che di AD DS (che contiene oggetti del computer) e AD DS dev’essere sincronizzato con AAD via ADConnect per la migliore user experience.
4. Sottoscrizione Azure
Ora che avete sistemato la questione licensing e directory, il prossimo step è trovare il punto in cui creare ed eseguire la vostra sessione WVD che ospita le VM che servirà Windows 10 Enterprise multi-session OS quale desktop per i vostri utenti.
Per farlo, avete bisogno di una sottoscrizione Azure.
La sottoscrizione Azure può essere acquistata attraverso diversi canali: CSP, EA, MCA ecc.
Si troverà all’interno del tenant Azure AD di cui abbiamo parlato qui sopra.
La sottoscrizione conterrà i seguenti elementi:
– WVD Management Service;
– Il tenant WVD sarà registrato ed aggiunto alla sottoscrizione Azure;
– All’interno del tenant WVD creerete l’Host Pools;
– All’interno dell’Host Pools avrete le session host – Windows 10 VMs;
– Durante la Public Preview, il WVD Management Service è disponibile solo nella regione East US 2. Una volta che la WVD sarà in versione general availability, il servizio sarà esteto anche ad altre regioni;
– VM Windows 10 ed infrastruttura;
– Le session host sono VM su cui è installato Windows 10 Enterprise multi-session;
– Ogni VM avrà un OS e dei data disk. Questi dischi possono utilizzare qualsiasi disco gestito in Azure (Standard HDD, Standard SSD, Premium SSD);
– Ci saranno un Virtual Network e subnet con le VM collegate alle subnet;
– Vi saranno costi di connettività internet e trasferimento di banda;
– Non avrete bisogno di aprire alcuna porta network per il traffico inbound come vi serviva per RDS. WVD utilizza un agente installato su ogni session host VM che sfrutta la tecnologia di Reverse Connect per stabilire la connettività senza aprire alcuna porta inbound;
– Le session host possono essere eseguite in qualsiasi regione Azure. Poichè i desktop user di WVD vengono originati dapprima dal WVD Management Service e poi ottenuti dalla VM che esegue il desktop, è importante mantenere la VM ed il Management Services il più vicino possibile – preferibilmente nella stessa regione Azure.
5. File Server
Una delle nuove ed interessanti funzionalità di WVD è la tecnologia di profile management proveniente da FSLogix.
I profili Windows degli utenti desktop WVD sono racchiusi in file VHD ed archiviati su un file server indipendente della Windows 10 session host VM.
In questo modo, se un utente è assegnato ad un pooled desktop (non persistente), il profilo (inclusa la cache Windows Search) può seguire l’utente, indipendentemente dal virtual desktop della VM a cui si loggano.
Per poter sfruttare questa nuova funzionalità, dev’esserci un file server accessibile alla VM session host in cui archiviare questi profile disks.
La cosa migliore, sarebbe avere il file server ed il desktop VM nella stessa regione Azure: in questo modo la connettività sarà più veloce e gli utenti finali avranno migliori performance. Eventualmente, è possibile anche usare Azure Files invece di un file server ma, per ora, è raccomandato l’utilizzo di Windows file server VM.
In conclusione, tenere in considerazione questi 5 prerequisiti prima di addentrarvi nel deployment, vi farà risparmiare un bel po’ di tempo e permetterà che il deployment fili liscio. Permetterà inoltre una corretta infrastruttura, directory e licensing di modo che siate sicuri che i vostri utenti apprezzino le performance, l’usabilità e la flessibilità dei loro nuovi virtual desktop in Azure.
Se avete intrapreso le azioni necessarie rispetto a questi pre-requisiti, allora siete pronti per iniziare.
Le informazioni presenti a questo post, sono prese dall’articolo: 5 Windows Virtual Desktop (WVD) Prerequisites.
