• Cloud, Guide
• 11 Novembre 2026

Quante volte vi hanno chiesto un desktop remoto e la prima cosa a cui avete pensato è stato il firewall, non il desktop?

Azure Virtual Desktop Hybrid prova a togliervi proprio quel pensiero. Il control plane resta in Azure, con broker e gateway gestiti da Microsoft, mentre i session host restano a casa vostra, sulle macchine che avete già. Niente gateway RDS da installare, niente broker da tenere in vita, nessuna porta da esporre verso Internet: sono i session host a uscire verso Azure, non il contrario.

Anche la configurazione è piuttosto sobria: pochi pezzi da mettere in fila (Azure Arc per portare la macchina sotto la gestione di Azure, un host pool e l’estensione che li collega) e il gioco è fatto.

In questa guida vi mostro come ho fatto io, partendo da una semplice Virtual Machine Windows su VMware, fino al desktop che si apre da Windows App.

Se vi serve un ripasso su come si tira su AVD o su cosa sia Azure Arc, trovate tutto qui: Introduzione ad Azure Virtual Desktop e Azure Arc: non è un agente, è un modo diverso di gestire i server

Tappa 1 – Portare la VM sotto Azure Arc

La vostra VM può vivere dove vuole: nella sala macchine, in un datacenter in colocation, su un cluster VMware che nessuno tocca da anni. Ad Azure, però, serve poterla “vedere”, e il modo per farlo si chiama Azure Arc. È lui che trasforma una macchina qualsiasi in una risorsa Azure, e senza questo passaggio non si va da nessuna parte: l’estensione AVD Hybrid, più avanti, si installa proprio su una risorsa Arc.

Prima di partire

Per questo articolo ho usato una VM Windows su VMware, con Entra ID join. Prima di scegliere la vostra, date un’occhiata a cosa è supportato:

La macchina deve poi poter parlare con Azure. L’agent Arc usa solo connessioni in uscita sulla porta 443 (TCP) e, se avete un firewall che filtra per nome, questi sono gli endpoint da consentire:

• login.microsoftonline.com e *.login.microsoft.com (autenticazione Entra);
• management.azure.com (creazione della risorsa Arc, serve solo quando collegate o scollegate il server);
• *.his.arc.azure.com (metadati e identità ibrida);
• *.guestconfiguration.azure.com (gestione delle estensioni);
• guestnotificationservice.azure.com e *.guestnotificationservice.azure.com, più azgn*.servicebus.windows.net oppure *.servicebus.windows.net (notifiche);
• pas.windows.net (Entra ID);
• download.microsoft.com (solo per scaricare l’agent, ma serve anche per gli aggiornamenti automatici).

La lista completa, comprese le varianti per i service tag e per gli scenari particolari, la trovate nella documentazione ufficiale

Generare lo script di onboarding

Il modo più rapido è farsi generare lo script direttamente dal portale:

1. Nel portale Azure aprite Azure Arc, poi Infrastructure > Machines.
2. Selezionate Onboard existing machines
3. Impostate subscription, resource group, region e sistema operativo Windows.

Figura 1: Onboard existing machines on Azure ARC

Figura 2: Onboarding existing machines with Azure ARC – deployment

Poi arriva la scelta del metodo di connettività: public endpoint, private endpoint oppure proxy. Dipende dall’architettura di rete di casa vostra. Io ho scelto il public endpoint senza proxy: è la strada più breve, e per un lab o per un ambiente con uscita su Internet diretta va benissimo.

Sulla stessa schermata trovate l’opzione per l’aggiornamento automatico dell’agent. L’ho abilitata: è un agent in meno da ricordarsi di aggiornare. Se le policy aziendali lo vietano, ovviamente lo gestite a mano.

Figura 3: Onboarding existing machines with Azure ARC – deployment

Infine, nella scheda Download and run script, scaricate lo script PowerShell.

Figura 4: Onboard existing machines with Azure ARC – Script

Eseguire lo script sulla VM

Copiate lo script sulla macchina, aprite Windows PowerShell come amministratore ed eseguitelo. Durante il processo vi verrà chiesta l’autenticazione interattiva verso Azure.

Se la execution policy blocca lo script, applicate solo l’eccezione prevista dalle policy interne e ripristinate la configurazione quando avete finito. A me non è capitato, ma è il tipo di cosa che salta fuori nel momento meno opportuno.

Figura 5: Onboard existing machines with Azure ARC – Run script

Controllare che sia andata a buon fine

Tornate nel portale, in Azure Arc > Infrastructure > Machines, aprite la vostra macchina e verificate che lo Status sia Connected.

Figura 6: Azure ARC Virtual Machine onboarded

Se lo stato non diventa Connected, i soliti sospetti sono firewall, proxy e TLS inspection che impediscono di raggiungere gli endpoint Arc. Partite da lì e, se serve, date un’occhiata alla guida ufficiale sui problemi di onboarding.

La VM adesso è un server Azure Arc-enabled, ma da sola non fa nulla di utile: le serve qualcosa a cui collegarsi. Ci pensiamo nella prossima tappa.

Tappa 2 – Preparare il terreno lato Azure

La VM è visibile ad Azure, ma non sa ancora dove andare a lavorare. Ora ci occupiamo del lato cloud: host pool, application group e workspace.

Prima di partire

Tre cose da avere a posto prima di iniziare:

• il provider Microsoft.DesktopVirtualization registrato nella subscription;
• il ruolo Desktop Virtualization Contributor per poter gestire l’host pool;
• i session host che riescono a raggiungere gli URL richiesti da AVD. Sono tutte connessioni in uscita, quindi niente porte da aprire verso l’interno. Tra i principali ci sono *.wvd.microsoft.com (traffico di servizio), login.microsoftonline.com (autenticazione) e *.prod.warm.ingest.monitor.core.windows.net (traffico dell’agent). Come per Arc, la lista completa è nella documentazione ufficiale, che descrive anche l’Agent URL Tool per verificare l’accesso dalla macchina.

Creare l’host pool

L’host pool è un host pool standard, con due regole particolari che valgono solo per l’Hybrid: non aggiungere VM dal wizard (le vostre stanno già altrove) e non usare Session Host Configuration, che in questo scenario non è supportata.

Io ho scelto un personal pool, per dare ai miei utenti una VDI dedicata. Lo faccio per semplicità, ma nulla vi vieta di ragionare diversamente se il vostro scenario è un altro.

Figura 7: Host pool deployment – 1

Figura 8: Host pool deployment – 2

Figura 9: Host pool deployment – 3

La managed identity: da non saltare

Questo è il passaggio che si dimentica più facilmente, quindi ve lo metto in evidenza. Durante la creazione dell’host pool, nella scheda Identity, assegnate una managed identity. Poi date a quella identity il ruolo Reader sul resource group che contiene i server Azure Arc-enabled.

Figura 10: Host pool deployment – 4

Perché serve? Perché l’host pool deve poter leggere le risorse Arc per sapere cosa c’è lì dentro. La documentazione avverte che, senza il ruolo Reader, una release futura potrebbe impedire ai session host di diventare disponibili: meglio non scoprirlo a servizio avviato.

Per assegnare il ruolo, dal portale:

1. Aprite il resource group che contiene i vostri server Arc, poi Access control (IAM).
2. Selezionate Add role assignment e scegliete il ruolo Reader.
3. In Assign access to selezionate Managed identity, poi Select members.
4. Scegliete la subscription e, nel menu delle managed identity, Host pool.
5. Selezionate l’identity del vostro host pool e confermate con Review + assign.

Figura 11: Add Role assignment -1

Figura 12: Add Role assignment – 2

Figura 13: Add Role assignment – 3

In alternativa potete testare la modalità di assegnazione del ruolo direttamente dall’ host pool

Figura 14: AVD Managed Identity

Figura 15: AVD Managed Identity role assignment

Workspace e application group

Per il workspace ne ho creato uno nuovo (come visto in Figura 9). Riutilizzare un workspace esistente ha senso solo se è coerente con gli application group che già contiene: altrimenti finite per avere un contenitore in cui convivono cose che non c’entrano nulla tra loro.

Come application group ho usato un Desktop application group, che pubblica il desktop completo. Se invece preferite pubblicare singole applicazioni, lo strumento è il RemoteApp application group.

Una volta creato l’application group, associatelo al workspace. Anche questo passaggio si salta senza accorgersene: se il workspace non “contiene” l’application group, gli utenti non vedranno nulla da Windows App.

Figura 16: AVD Application Group

Il lato Azure è pronto. Manca solo l’host: nella prossima tappa lo mettiamo dove deve stare.

Tappa 3 – Registrare il session host

Eccoci al punto in cui la VM smette di essere “un server Arc qualsiasi” e diventa un session host a tutti gli effetti. Vi mostro due strade: quella ufficiale, e quella che ha funzionato a me quando la prima ha deciso di prendersi una pausa.

Strada 1: l’estensione ufficiale

È il percorso previsto da Microsoft: si installa l’estensione Azure Virtual Desktop Hybrid sulla macchina Arc-enabled, e lei si occupa di distribuire i componenti AVD e di registrare l’host nel pool.

1. Aprite Azure Arc > Infrastructure > Machines e selezionate la VM.
2. Entrate in Settings > Extensions e scegliete Add.
3. Selezionate Azure Virtual Desktop Hybrid.

   

Figura 17: ARC Machine AVD Extension

1. Indicate subscription, resource group e host pool di destinazione.

   

Figura 18: ARC Machine AVD Extension configuration

1. Confermate con Review + Create e poi Create.
2. Attendete che Microsoft.AzureVirtualDesktop.CloudDeviceExtension mostri lo stato Succeeded.

A questo punto aprite l’host pool e controllate la scheda Session hosts: la macchina dovrebbe comparire nell’elenco. Microsoft segnala che possono servire fino a 15 minuti dopo il Succeeded perché l’host diventi Available.

Per chi usa Windows Server: l’estensione abilita anche il ruolo Remote Desktop Session Host, e questo può causare un riavvio. Per evitare sorprese, installate il ruolo RDSH in anticipo e pianificate una finestra di manutenzione. Sul Windows Client, come nel mio caso, non serve.

Quando l’estensione non collabora

Ad oggi, novembre 2026, l’estensione si installa ma non registra correttamente l’host nel pool selezionato. Io l’ho vissuta così: il portale dava lo stato Succeeded, ho aspettato oltre un’ora e l’host è rimasto in Not registered. A quel punto ho smesso di aspettare e ho cominciato a sospettare.

Figura 19: AVD Session Host not registered

Se vi capita la stessa cosa, non serve disperare: la registrazione a mano funziona e richiede pochi minuti.

Strada 2: la registrazione manuale

Ripartire puliti. Per avere una situazione più ordinata, io ho disinstallato dalla macchina entrambi gli agent installati dall’estensione, bootloader e RD Agent. Voi avete la possibilità di rimuovere solo l’RD Agent, se preferite.

Generare il token. Prima di cominciare, generate dall’host pool il token di registrazione (la funzione Registration key). Vi servirà durante l’installazione dell’RD Agent.

Figura 20: AVD Host Pool Registration Key

Nota di sicurezza: il token di registrazione dell’host pool è un segreto temporaneo. Generatelo con la durata minima necessaria, non inseritelo in documentazione o screenshot (parlo bene e pratico male) e revocatelo o rigeneratelo dopo l’uso.

Installare gli agent. L’ordine conta: prima il bootloader, poi l’RD Agent.

• Bootloader: download Microsoft
• RD Agent: download Microsoft

Durante l’installazione dell’RD Agent vi verrà chiesta la chiave di collegamento all’host pool: è il token che avete appena generato. Nessuno dei due installer richiede un riavvio.

Figura 21: AVD RD Agent configuration

Controllare che l’host sia Available

Tornate nell’host pool, in Session hosts: lo stato deve diventare Available. Nel mio caso ci ha messo meno di cinque minuti, che dopo l’ora di attesa con l’estensione mi è sembrato un tempo straordinario.

Figura 22: AVD Session Host Available

Il mio consiglio

Sulla prima VM provate con l’estensione ufficiale: è la strada prevista, e magari quando leggerete questo articolo Microsoft avrà già sistemato tutto. Se l’host non si registra, passate alla configurazione manuale. Per le VM successive usate semplicemente la strada che avete visto funzionare.

L’host è pronto. Adesso tocca ai vostri utenti.

Tappa 4 – Pubblicare e testare

Finalmente l’ultimo kilometro: Azure è pronto, l’host è registrato e disponibile, ora si tratta di far entrare gli utenti. Il Desktop application group lo abbiamo già creato e associato al workspace nella Tappa 2, quindi qui restano solo le assegnazioni e il test.

Assegnare gli utenti all’application group

Aprite l’application group, entrate in Assignments e aggiungete un gruppo Microsoft Entra ID. Meglio un gruppo che i singoli utenti: il giorno in cui qualcuno arriva o se ne va, modificate un gruppo e non venti assegnazioni. (per scopi di test io ho assegnato solo il mio utente in maniera puntuale, ma vi prego, utilizzate i gruppi)

Figura 23: Assing Users and Groups to Applicaiton Group

Il ruolo che si dimentica: Virtual Machine Login

Se i vostri session host sono in Entra ID join, come nel mio caso, c’è un passaggio che non si vede subito e che vi può far perdere un po’ di tempo: gli utenti devono avere un ruolo di login sulla macchina.

La scelta dipende da a chi state dando la macchina:

• a un utente senza ruoli amministrativi date Virtual Machine User Login;
• a un amministratore date Virtual Machine Administrator Login.

Il consiglio è di validare caso per caso, e di non dare l’Administrator Login “a tutti per stare tranquilli”: il risultato sarebbe un parco utenti con diritti da amministratore locale dentro il vostro datacenter (degno di un film di Dario Argento).

Il ruolo si può assegnare sulla singola VM Arc, sul resource group o sulla subscription. Microsoft consiglia di farlo a livello di resource group, allo stesso gruppo usato per l’application group, così vale per tutti i server del pool.

Figura 24: Assign Virtual Machine User/Administrator Login

E se lo dimenticate? La sessione parte, ma il login fallisce con un errore sul nome utente o sulla password, che è fuorviante perché la password è giusta.

Personal pool: chi finisce su quale macchina

Visto che ho scelto un personal pool, l’assegnazione dell’utente alla sua VM è automatica: alla prima connessione, l’utente viene associato a un session host libero. Si vede nella scheda Session hosts, dove accanto alla macchina compare l’utente assegnato. Se preferite decidere voi chi va su quale macchina, esiste anche l’assegnazione diretta.

Accedere da Windows App

Sul client Windows, aprite Windows App, accedete con l’utente assegnato e sottoscrivete il workspace. Il desktop compare tra le risorse disponibili: avviatelo.

Figura 25: Windows App

Il test finale

Io ho verificato il login e l’apertura della sessione, e tutto è filato liscio. Dopo la Tappa 3, devo ammettere che mi sono quasi insospettito.

Figura 26: AVD Session Desktop

Ora che tutto funziona, resta una sola domanda: il conto?

Costi e licensing

Il conto, dunque. La prima notizia è che per AVD Hybrid il conto ha due voci. La seconda notizia è che nessuna delle due riguarda il vostro hypervisor.

Prima voce: le licenze degli utenti

Per accedere a un session host Hybrid, ogni utente deve avere una licenza Microsoft idonea. Se state usando Windows 11 Enterprise, come nel mio caso, vanno bene:

• Microsoft 365 E3/E5, A3/A5, F3 o Business Premium;
• Windows 11 Enterprise E3/E5 o A3/A5;
• Windows 11 VDA per utente.

Se invece usate Windows Server come session host, vi servono una RDS CAL con Software Assurance attiva, una RDS User Subscription License o una RDS SAL, più la licenza del sistema operativo Server.

Per molte aziende questa è la parte meno dolorosa, perché queste licenze spesso ci sono già. Ed è anche l’ultima buona notizia di questa sezione.

Seconda voce: il service fee

Il “service fee” di AVD Hybrid è il canone per la gestione e l’orchestrazione del servizio, e viene calcolato per utente nominale al mese: nel documento Microsoft sul pricing dell’Hybrid la cifra indicata è di 10 dollari per utente al mese. Sembrerebbe, ma qui chiedete conferma al vostro referente Microsoft, che il billing avvenga tramite la sottoscrizione Azure al momento. (Reference Pricing Azure Virtual Desktop)

Figura 27: AVD Hybrid Pricing

Per orientarsi: Azure, Azure Local e Hybrid

Se state confrontando le opzioni, ecco come si compone il conto nei tre scenari. Le licenze utente sono sempre la stessa voce; a cambiare è tutto il resto:

Tre modi diversi di contare le stesse persone. Quale conviene dipende da quanti utenti avete e da quante macchine servono per servirli, e qui il foglio di calcolo è più onesto di qualsiasi slide.

Una piccola invettiva (lo ammetto, è un parere)

Non lo dico per partito preso: AVD Hybrid ha vantaggi veri. Il control plane gestito, l’assenza di gateway e broker da mantenere e nessuna porta da esporre verso Internet sono comodità che non si trovano ovunque.

Però a quei soldi, a mio parere, il confronto diventa inevitabile. Soluzioni di terze parti come Horizon e Parallels hanno costi paragonabili, a seconda di licenze e contratti, e in più portano un monitoring migliore e un supporto più semplice, due aspetti su cui AVD è sempre rimasto un po’ indietro, a scapito di un’infrastruttura bellissima.

Una possibile soluzione e integrazione potrebbe essere attraverso strumenti di 3e parti come Nerdio o Hydra che aiutano a sorpassare i limiti di AVD evidenziati prima, ma anche qui con dei delta economici.

Chiusura – Cosa AVD Hybrid (ancora) non fa

Il percorso è finito: avete una VM on-premises che è un server Arc, un session host registrato e un desktop che si apre da Windows App. Prima di chiudere, però, è giusto sapere cosa AVD Hybrid non fa, per evitare di scoprirlo a servizio avviato.

Non gestisce le vostre macchine. AVD Hybrid non fa provisioning né power management delle macchine locali. Di conseguenza non sono supportati:

• Autoscale;
• Start VM on Connect;
• Session Host Configuration.

Accensione, spegnimento e capacità restano affari vostri: vanno gestiti con gli strumenti dell’hypervisor, con degli script o con soluzioni di terze parti. Insomma, il pulsante di accensione è sempre in mano a voi.

Non supporta tutto il catalogo Windows. Windows 11 Enterprise multi-session non è supportato: si lavora con Windows 11 Enterprise single-session e con Windows Server. I dispositivi fisici sono ammessi solo se headless e dedicati.

Detto questo, il progetto fa quello che promette: porta AVD dove sono già i vostri server, senza gateway da gestire e senza porte da esporre.

Buon deploy!

Enea