• Cloud, Guide, Sistemi Operativi
• 23 Maggio 2026

Azure Local è la soluzione Microsoft pensata per portare le funzionalità di Azure direttamente nei vostri ambienti locali, nei datacenter aziendali, nelle sedi periferiche o negli scenari edge in cui avete bisogno di eseguire workload vicino agli utenti, ai dati o ai sistemi produttivi. In pratica vi permette di avere un’infrastruttura cloud-connected, gestita e governata tramite Azure Arc, ma eseguita su hardware locale o in ambienti controllati dall’organizzazione.

Rispetto a un’infrastruttura tradizionale, Azure Local introduce un modello più moderno di gestione: potete distribuire macchine virtuali, servizi, workload containerizzati e scenari ibridi mantenendo un punto di controllo centralizzato dal portale Azure. Questo approccio è particolarmente utile quando dovete rispettare requisiti di latenza, sovranità del dato, compliance o continuità operativa, senza rinunciare agli strumenti di governance e automazione tipici del cloud.

Per testare Azure Local senza dover predisporre subito hardware fisico dedicato, Microsoft mette a disposizione Jumpstart LocalBox, un ambiente sandbox che automatizza la creazione di una istanza Azure Local a due nodi utilizzando la nested virtualization su una macchina virtuale Azure con Hyper-V. In questo modo potete provare le funzionalità principali della piattaforma, verificarne il comportamento e prendere confidenza con la gestione dal portale Azure in tempi molto più rapidi.

In questa guida vedremo quindi come utilizzare Jumpstart LocalBox per realizzare un laboratorio Azure Local, analizzando i passaggi principali della distribuzione e le verifiche da effettuare al termine del deployment. L’obiettivo non è sostituire una progettazione di produzione, ma fornirvi un ambiente pratico con cui iniziare a comprendere architettura, componenti e modalità operative di Azure Local.

Figura 1: Architettura di Jumpstart LocalBox utilizzata per distribuire un ambiente di test Azure Local in Azure

Istanza Azure Local a due nodi

LocalBox crea automaticamente un’istanza Azure Local a due nodi, utilizzando la nested virtualization con Hyper-V eseguito all’interno di una macchina virtuale Azure.

In questo scenario la VM Azure diventa l’host Hyper-V principale del laboratorio. Al suo interno vengono create tre macchine virtuali: AzLHOST1 e AzLHOST2, che rappresentano i due nodi Azure Local, e AzLMGMT, usata come macchina di gestione.

La macchina AzLMGMT ospita a sua volta altre due VM: un domain controller Active Directory e un server Routing and Remote Access, utilizzato come router virtuale. Questo vi permette di avere un ambiente completo e isolato, già predisposto con i servizi di base necessari per testare Azure Local senza dover configurare manualmente tutta l’infrastruttura.

Figura 2: Architettura di nested virtualization utilizzata da LocalBox per creare l’ambiente Azure Local a due nodi con VM di gestione, domain controller e router virtuale

Distribuzione dell’infrastruttura LocalBox con Azure Bicep

La distribuzione di LocalBox viene eseguita tramite Azure Bicep, che automatizza la creazione delle risorse necessarie all’interno della vostra sottoscrizione Azure.

Per distribuire LocalBox useremo Azure Cloud Shell, così non dovete installare strumenti aggiuntivi sulla vostra macchina. Cloud Shell include già Azure CLI, PowerShell e i moduli necessari per interagire con la sottoscrizione Azure.

Prima di avviare il deployment, dovete registrare i Resource Provider richiesti. È un passaggio fondamentale, perché Azure Local, Azure Arc, Kubernetes, Key Vault, Monitor e gli altri servizi utilizzati da LocalBox devono essere abilitati nella sottoscrizione.

Per eseguire questa operazione dovete usare un account con ruolo Owner o Contributor sulla sottoscrizione. In alternativa, chiedete all’amministratore Azure di effettuare la registrazione per voi.

Aprite quindi Azure Cloud Shell dal portale Azure, scegliete PowerShell ed eseguite i seguenti comandi:

Figura 3: Registrazione dei Resource Provider richiesti per Jumpstart LocalBox tramite Azure Cloud Shell

Clonazione del repository Azure Arc Jumpstart

Dopo aver registrato i Resource Provider, è necessario scaricare in Azure Cloud Shell il repository GitHub di Azure Arc Jumpstart. È da questo repository che utilizzerete i file per distribuire Jumpstart LocalBox, inclusi i template Bicep e gli script di configurazione.

Da Azure Cloud Shell, eseguite il comando:

Al termine del download, Cloud Shell crea una nuova cartella chiamata azure_arc nella home dell’utente.

Figura 4: Clonazione del repository Azure Arc Jumpstart in Azure Cloud Shell

Verificare la versione di Azure CLI

Prima di procedere con la distribuzione di LocalBox, verificate che in Azure Cloud Shell sia disponibile una versione aggiornata di Azure CLI. La guida richiede almeno la versione 2.65.0, quindi è importante controllare questo requisito prima di lanciare i template di deployment.

Da Azure Cloud Shell eseguite:

Nel mio caso Cloud Shell restituisce Azure CLI 2.86.0, quindi il requisito è soddisfatto e possiamo continuare con la preparazione dell’ambiente. Se nella vostra sottoscrizione Cloud Shell mostra una versione precedente, riavviate la sessione o aggiornate l’ambiente prima di proseguire.

Figura 5: Verifica della versione di Azure CLI in Azure Cloud Shell prima della distribuzione di Jumpstart LocalBox

Verificare la sottoscrizione e le quote vCPU

Prima di distribuire LocalBox è importante verificare due aspetti: la sottoscrizione Azure attiva e la disponibilità di quote vCPU nella region scelta.

Per prima cosa controllate che Azure CLI stia usando la sottoscrizione corretta:

Se la sottoscrizione non è quella desiderata, impostate quella corretta prima di proseguire.

LocalBox può essere distribuito in una region che disponga di capacità sufficiente per la SKU scelta. Con i parametri predefiniti viene usata una VM della famiglia Standard E32s v5/v6, quindi dovete verificare di avere almeno 32 vCPU disponibili nella region di destinazione. Al momento, per LocalBox, potete usare australiaeast, southcentralus, eastus, westeurope, southeastasia, canadacentral, japaneast, centralindia.

Io ho scelto la region West Europe e ho controllato le quote con il comando:

Figura 6: Verifica delle quote vCPU disponibili nella region scelta prima della distribuzione di Jumpstart LocalBox

Aggiornare Bicep e recuperare l’ID del Resource Provider

Prima di avviare il deployment del template, aggiornate Azure Bicep alla versione più recente disponibile in Azure Cloud Shell. Questo passaggio evita errori di compilazione o incompatibilità con i file Bicep usati da Jumpstart LocalBox.

Eseguite il comando:

Terminato l’aggiornamento, dovete recuperare l’object ID del service principal associato al Microsoft.AzureStackHCI Resource Provider. Questo valore verrà utilizzato nei passaggi successivi della distribuzione, quindi segnatevelo.

Eseguite:

Nell’output JSON individuate il campo id. Copiatelo e conservatelo, perché servirà durante la configurazione dei parametri del deployment.

Figura 7: Aggiornamento di Azure Bicep e recupero dell’object ID del Microsoft.AzureStackHCI Resource Provider da Azure Cloud Shell

Modificare il file dei parametri Bicep

Prima di avviare il deployment dovete modificare il file main.bicepparam, che contiene i parametri utilizzati dal template Bicep per creare l’ambiente Jumpstart LocalBox.

Il file si trova nel percorso:

azure_arc/azure_jumpstart_localbox/bicep/main.bicepparam

Io ho aperto il file con Visual Studio Code for the Web, avviato direttamente da Azure Cloud Shell tramite il pulsante Open in VS Code for the Web. È il metodo più comodo, perché vi permette di modificare i parametri senza scaricare nulla localmente.

Nel file dovete valorizzare almeno i parametri principali, tra cui tenantId, spnProviderId, windowsAdminUsername, windowsAdminPassword, location, azureLocalInstanceLocation, rdpPort e la dimensione della VM con vmSize.

Il valore spnProviderId deve corrispondere all’id del Microsoft.AzureStackHCI Resource Provider recuperato nel passaggio precedente. Nel mio laboratorio ho impostato sia location sia azureLocalInstanceLocation su westeurope, così le risorse Azure e l’istanza Azure Local vengono create nella stessa region.

Ricordatevi anche di sostituire la password di esempio con una password robusta e conforme ai requisiti di complessità.

Nota: evitate di usare il simbolo $ nel parametro windowsAdminPassword. La presenza di questo carattere può causare il fallimento del LogonScript durante la configurazione automatica dell’ambiente LocalBox. Usate quindi una password complessa, ma senza il simbolo $.

Figura 8: Modifica del file main.bicepparam con VS Code for the Web per configurare i parametri di distribuzione di Jumpstart LocalBox

Personalizzare gli script di LocalBox

Nel file main.bicepparam trovate alcuni parametri che controllano il comportamento del deployment di Jumpstart LocalBox. Tra questi, due sono particolarmente importanti se volete personalizzare gli script o le configurazioni usate durante la distribuzione:

param githubAccount = ‘microsoft’
param githubBranch = ‘main’

Per impostazione predefinita, githubAccount punta all’account GitHub microsoft e githubBranch al branch main. Questo significa che, durante il deployment, LocalBox scarica script, configurazioni e automazioni dal repository ufficiale Microsoft:

https://github.com/microsoft/azure_arc

Se volete modificare qualche parametro interno degli script, ad esempio configurazioni avanzate, comportamento del post-deployment o impostazioni come il provisioning del Network Controller, non dovete modificare direttamente il repository Microsoft. La scelta corretta è fare un fork del repository nel vostro account GitHub e modificare lì i file necessari.

Dopo aver creato il fork, aggiornate il parametro githubAccount nel file main.bicepparam, facendolo puntare al vostro account GitHub. Ad esempio:

param githubAccount = ‘nicferr’
param githubBranch = ‘main’

In questo modo il deployment userà il vostro repository come sorgente degli script e delle configurazioni. È una possibilità molto utile quando volete testare personalizzazioni di LocalBox senza alterare il codice originale e mantenendo comunque lo stesso processo di distribuzione.

Nota: questa impostazione è utile anche se avete modificato file presenti nel percorso azure_jumpstart_localbox, come gli script PowerShell di configurazione o i file usati durante il post-deployment. Il template continuerà a distribuire LocalBox, ma recupererà gli artefatti dal vostro fork invece che dal repository ufficiale Microsoft.

Creare il Resource Group e distribuire il template Bicep

Dopo aver configurato il file main.bicepparam, spostatevi nella cartella che contiene i file Bicep di Jumpstart LocalBox:

Create quindi un nuovo Resource Group nella region scelta per il laboratorio. Io ho usato West Europe e ho chiamato il gruppo AzureLocalBox:

A questo punto potete avviare la distribuzione del template Bicep usando il file dei parametri modificato in precedenza:

Da questo momento Azure inizia a creare l’infrastruttura necessaria a LocalBox. Il processo richiede tempo, perché vengono distribuite la VM principale, la rete, le configurazioni Hyper-V annidate e i componenti necessari per preparare l’ambiente Azure Local.

Figura 9: Creazione del Resource Group AzureLocalBox e avvio della distribuzione del template Bicep di Jumpstart LocalBox da Azure Cloud Shell

Al termine del deployment iniziale, che nel mio caso è durato circa 12 minuti, potete aprire il Resource Group creato per LocalBox e verificare che le risorse siano state distribuite correttamente.

All’interno sono presenti le risorse di base generate dal template Bicep, tra cui la VM LocalBox-Client, i dischi dati, il disco del sistema operativo, la scheda di rete, l’indirizzo IP pubblico, il Network Security Group, la rete virtuale, il workspace Log Analytics e lo storage account.

Notate anche il tag DeploymentProgress, che indica lo stato della configurazione. In questa fase il valore mostra Downloading nested VMs VHD files, quindi l’automazione post-deployment ha iniziato a scaricare i dischi VHD necessari per creare le macchine virtuali annidate dell’ambiente LocalBox.

Questa verifica è utile perché vi permette di controllare subito che il deployment sia andato a buon fine e che la VM LocalBox-Client sia disponibile. Da questa macchina continuerete i passaggi successivi per completare la configurazione dell’istanza Azure Local.

Figura 10: Verifica delle risorse create nel Resource Group AzureLocalBox dopo il deployment iniziale di Jumpstart LocalBox

Connessione alla VM LocalBox-Client

Completato il deployment iniziale, dovete collegarvi in RDP alla macchina virtuale LocalBox-Client. Prima di farlo, create un’eccezione nel Network Security Group associato alla VM, consentendo l’accesso alla porta RDP solo dal vostro indirizzo IP pubblico. È una buona pratica evitare regole troppo permissive, soprattutto su ambienti esposti in Azure.

Una volta stabilita la connessione, accedete con le credenziali amministrative configurate nel file main.bicepparam. Al primo logon viene avviato automaticamente uno script PowerShell: è la fase di automazione post-deployment che completa la preparazione dell’ambiente LocalBox.

Lo script installa e configura i componenti necessari, tra cui Azure CLI, VS Code, Azure Data Studio e gli strumenti richiesti per proseguire con la distribuzione dell’istanza Azure Local.

Figura 11: Primo accesso RDP alla VM LocalBox-Client e avvio automatico dello script PowerShell di post-deployment

Terminata l’installazione dei software prerequisiti, lo script di post-deployment prosegue automaticamente con la preparazione dell’ambiente Azure Local.

In questa fase viene configurato l’host LocalBox-Client come ambiente di virtualizzazione. Lo script abilita PowerShell Remoting, verifica la connettività Internet, crea gli switch virtuali interni e configura il NAT Switch che verrà utilizzato dalle macchine virtuali annidate.

Subito dopo inizia la copia dei file VHDX necessari per creare le VM del laboratorio. In particolare, viene preparato il disco della macchina di gestione e dei nodi che formeranno il cluster Azure Local.

Questa fase è delicata e richiede tempo. Non dovete chiudere la sessione RDP, la finestra PowerShell o riavviare la macchina. Lasciate completare lo script: sarà lui a proseguire con la creazione dei componenti necessari.

NOTA: Questa fase può richiedere circa 5 ore; se sono disponibili aggiornamenti per Azure Local, considerate anche un’ora aggiuntiva.

Figura 12: Avvio della fase di creazione del cluster Azure Local

Durante l’esecuzione dello script di post-deployment viene avviata la creazione delle macchine virtuali che compongono il laboratorio LocalBox.

Aprendo Hyper-V Manager sulla VM LocalBox-Client potete vedere le tre VM create automaticamente: AzLHOST1, AzLHOST2 e AzLMGMT. Le prime due rappresentano i nodi dell’istanza Azure Local, mentre AzLMGMT viene utilizzata come macchina di gestione dell’ambiente.

In questa fase lo script prepara i dischi VHDX, installa le funzionalità necessarie e avvia le VM. Subito dopo passa alla configurazione della rete e dello storage, elementi indispensabili per creare correttamente il cluster Azure Local.

Verificate che le tre macchine risultino nello stato Running. Questo conferma che la nested virtualization è attiva e che l’ambiente LocalBox sta proseguendo correttamente con la costruzione del cluster.

Figura 13: Creazione e avvio delle macchine virtuali annidate AzLHOST1, AzLHOST2 e AzLMGMT all’interno della VM LocalBox-Client

Dopo l’avvio dello script sulla VM LocalBox-Client, potete seguire l’avanzamento della distribuzione anche dal portale Azure. È sufficiente aprire il Resource Group che avete creato e selezionare la voce Deployments.

Da questa schermata potete controllare lo stato dei singoli deployment eseguiti dal processo di automazione. Alcune attività risultano già completate con stato Succeeded, mentre altre possono essere ancora in esecuzione con stato Deploying.

Non intervenite sui deployment in corso e non rilanciate manualmente le operazioni. Lasciate completare lo script: l’automazione gestisce l’intera sequenza di configurazione.

Figura 14: Monitoraggio dal portale Azure dei deployment avviati dallo script di configurazione di Jumpstart LocalBox

Dopo circa 5 ore, lo script di post-deployment termina la configurazione dell’ambiente Jumpstart LocalBox. Al completamento, la finestra PowerShell si chiude automaticamente.

Questo indica che la fase automatica è stata completata e che l’infrastruttura del laboratorio è pronta per le verifiche successive. Da questo momento potete iniziare a controllare lo stato delle VM annidate, verificare la presenza dell’istanza Azure Local nel portale Azure e proseguire con la gestione delle risorse tramite Azure Arc.

Vi consiglio di aprire la cartella Logs se volete controllare il dettaglio delle operazioni eseguite o analizzare eventuali errori comparsi durante la configurazione.

Figura 15: Completamento del deployment di Jumpstart LocalBox dopo l’esecuzione dello script di post-deployment sulla VM LocalBox-Client

Completato lo script di post-deployment, tornate nel Resource Group usato per LocalBox e aggiornate la pagina. A questo punto non vedrete più soltanto le risorse iniziali, ma anche i componenti creati durante la configurazione automatica dell’ambiente Azure Local.

Nel Resource Group AzureLocalBox sono ora presenti, oltre alla VM LocalBox-Client, anche i nodi AzLHOST1 e AzLHOST2 registrati come Machine – Azure Arc, la Custom Location, l’istanza Azure Local, l’Arc Resource Bridge, la rete logica Azure Local Logical network e gli Azure Local Storage path.

I tag del Resource Group confermano lo stato finale della procedura: DeploymentProgress: Completed e DeploymentStatus: Tests succeeded. Questo è un controllo importante, perché vi permette di verificare che la distribuzione sia terminata correttamente e che le risorse ibride siano visibili e gestibili dal portale Azure.

Figura 16: Risorse create nel Resource Group AzureLocalBox dopo il completamento della distribuzione di Jumpstart LocalBox e la registrazione dell’ambiente Azure Local

Utilizzo delll’ambiente LocalBox

Dopo il completamento del deployment potete iniziare a esplorare l’ambiente LocalBox. È importante capire come sono organizzate le macchine virtuali, perché l’intero laboratorio simula un’infrastruttura Azure Local a due nodi.

All’interno di AzLMGMT vengono eseguite due ulteriori VM: JumpstartDC, che svolge il ruolo di domain controller, e VM-Router, utilizzata come Remote Access Server e router virtuale. Questa struttura vi consente di avere un ambiente completo, con dominio Active Directory, rete interna e nodi Azure Local, senza dover predisporre hardware fisico.

Per accedere alla VM LocalBox-Client usate le credenziali locali definite nel file main.bicepparam. Per molte attività successive, ad esempio l’accesso ai nodi AzLHOST1 e AzLHOST2, dovrete invece usare l’account di dominio [email protected].

La password è la stessa configurata durante il deployment per l’account amministrativo locale.

Vi riporto, per comodità lo stesso schema che ho messo all’inizio della guida:

Figura 17: Architettura di nested virtualization di Jumpstart LocalBox con host principale, nodi Azure Local, macchina di gestione, domain controller e router virtuale

Per comprendere meglio l’ambiente appena distribuito, aprite Hyper-V Manager dalla VM LocalBox-Client. Qui potete vedere le tre macchine virtuali principali create dal deployment: AzLHOST1, AzLHOST2 e AzLMGMT.

La VM AzLMGMT è a sua volta un host Hyper-V annidato. Collegandovi alla sua console potete verificare la presenza delle due VM interne: jumpstartdc, che svolge il ruolo di domain controller, e vm-router, utilizzata come router virtuale e Remote Access Server.

Figura 18: Verifica delle VM annidate jumpstartdc e vm-router all’interno della macchina AzLMGMT tramite Hyper-V Manager

Verificare gli aggiornamenti di Azure Local

Dopo il deployment è consigliabile controllare se sono disponibili aggiornamenti per l’istanza Azure Local. LocalBox viene aggiornato regolarmente, ma il team di prodotto può pubblicare nuove versioni con correzioni di sicurezza e miglioramenti funzionali anche dopo il rilascio dell’immagine usata dal laboratorio.

Dal portale Azure aprite la risorsa Azure Local che si chiama localboxcluster, quindi spostatevi in Operations > Updates. In questa sezione potete verificare lo stato degli aggiornamenti, la versione installata e l’eventuale presenza di update disponibili.

Nel mio caso lo stato risulta Up to date, la readiness è Healthy e la connessione ad Azure è Connected. Questo conferma che l’istanza Azure Local è correttamente registrata, raggiungibile dal portale e già aggiornata alla versione disponibile.

Se durante la configurazione avete impostato il parametro autoUpgradeClusterResource su true, l’aggiornamento automatico dell’istanza Azure Local dovrebbe essere già stato eseguito al termine del deployment.

Figura 19: Verifica dello stato degli aggiornamenti dell’istanza Azure Local localboxcluster dal portale Azure

Gestire le macchine virtuali dal portale Azure

Una volta completato il deployment di LocalBox, potete iniziare a usare una delle funzionalità più interessanti di Azure Local: la gestione delle macchine virtuali direttamente dal portale Azure.

Azure Local permette infatti di creare, modificare, eliminare e amministrare VM Windows e Linux eseguite sull’infrastruttura locale, ma gestite tramite gli strumenti Azure. Questo modello usa Azure Arc per proiettare nel portale risorse locali come VM, dischi, interfacce di rete, immagini e logical network. In questo modo potete lavorare con un’esperienza molto simile a quella delle VM Azure, pur eseguendo i workload sull’ambiente Azure Local.

Nel laboratorio LocalBox i componenti necessari sono già stati predisposti dal deployment: trovate l’Arc Resource Bridge, la Custom Location, la rete logica e gli storage path. Questi elementi permettono al portale Azure di sapere dove distribuire le nuove VM e come collegarle alle risorse locali. La documentazione Jumpstart dedica una sezione specifica al provisioning delle VM in LocalBox https://jumpstart.azure.com/azure_jumpstart_localbox/RB .

Figura 20: Sezione Virtual machines dell’istanza Azure Local localboxcluster pronta per la creazione di una nuova VM dal portale Azure

Preparare le immagini delle VM

Prima di creare una macchina virtuale su Azure Local, dovete rendere disponibile almeno una VM image. Senza un’immagine di riferimento, il portale non ha un sistema operativo da utilizzare per il provisioning della nuova VM.

Dalla risorsa localboxcluster, aprite Resources > VM images e selezionate Add VM Image. Il portale vi permette di aggiungere un’immagine in tre modi: da Azure Marketplace, da uno Storage Account Azure oppure da una condivisione locale.

Per un primo test con LocalBox, l’opzione più semplice è partire da Azure Marketplace, così potete scaricare un’immagine già pronta e usarla per distribuire le VM nell’ambiente Azure Local.

Una volta aggiunta l’immagine, questa comparirà nell’elenco delle VM images e potrà essere selezionata durante la creazione della macchina virtuale.

Figura 21: Aggiunta di una VM image all’istanza Azure Local localboxcluster prima della creazione di nuove macchine virtuali

Seguite il breve wizard e scegliete una delle immagini disponibili Windows e Linux. Nel mio laboratorio ho scelto di aggiungere l’immagine Windows Server 2025 Datacenter: Azure Edition.

Il processo è durato 3 ore. Durante questo processo l’immagine viene scaricata e salvata nel cluster storage di Azure Local, all’interno dello storage path configurato dal deployment. Questo passaggio è necessario perché le nuove VM verranno create usando il file VHD disponibile localmente nel cluster.

Al termine, lo stato dell’immagine deve risultare Available. Solo a quel punto potete utilizzarla per creare nuove macchine virtuali dal portale Azure.

Figura 22: Immagine Windows Server 2025 Datacenter Azure Edition disponibile nel portale Azure e scaricata come file VHD nel cluster storage di Azure Local

Creare la Logical Network

Per permettere alle vostre VM di connettersi alle rete dovete creare una Logical Network associata alla Custom Location di LocalBox. Questa rete verrà usata dalle macchine virtuali Azure Local per collegarsi all’ambiente di laboratorio.

Dal portale Azure aprite la risorsa localboxcluster, quindi selezionate Resources > Logical networks. Se l’elenco è vuoto, scegliete Create logical network.

La Logical Network è un prerequisito per aggiungere una network interface alla VM. Senza questa configurazione, durante il wizard di creazione della macchina virtuale vedrete il messaggio No Networks available in this Custom Location e non potrete proseguire correttamente con la parte di networking.

Figura 23: Creazione di una Logical Network nell’istanza Azure Local localboxcluster per consentire il collegamento di rete delle nuove VM

Procedete quindi con la creazione della Logical Network, inserendo i dati richiesti per identificare la rete che verrà usata dalle VM Azure Local.

Nella scheda Basics selezionate la Subscription e il Resource Group in cui si trova l’ambiente LocalBox.

Assegnate poi un nome alla rete logica e selezionate il Virtual switch name disponibile nell’ambiente Azure Local. In LocalBox viene esposto lo switch ConvergedSwitch(compute_management), che verrà usato per collegare le VM alla rete configurata dal laboratorio.

La Region e la Custom location vengono valorizzate automaticamente in base all’istanza Azure Local selezionata.

Dopo aver compilato questi campi, proseguite con Next.

Creare la Logical Network senza NSG

Durante la creazione della Logical Network potete notare che il campo Network security group non è selezionabile. Il portale mostra il messaggio che indica che non è possibile aggiungere Network Security Group perché il Software Defined Networking non è abilitato da Azure Arc oppure il Network Controller non è configurato nel cluster.

Nel mio laboratorio ho quindi proseguito senza associare un NSG alla rete logica. È un comportamento atteso: il deployment standard di LocalBox non crea il Network Controller, quindi non espone le funzionalità SDN necessarie per gestire gli NSG sulle VM Azure Local.

La Logical Network può comunque essere creata e usata dalle VM, ma senza regole NSG applicate dal piano di controllo SDN. Per il laboratorio è sufficiente, perché l’obiettivo è verificare la creazione della rete, l’assegnazione IP e la connettività delle VM.

Per abilitare la creazione degli NSG sarebbe necessario distribuire anche il Network Controller. Nel repository GitHub di LocalBox il parametro da modificare si trova nel file azure_jumpstart_localbox/artifacts/PowerShell/LocalBox-Config.psd1

All’interno della sezione dedicata al provisioning SDN trovate il parametro ProvisionNC = $false

Per predisporre il deployment del Network Controller il valore dovrebbe essere impostato a ProvisionNC = $true

Solo dopo l’abilitazione del Network Controller potrete usare le funzionalità SDN e associare Network Security Group alle risorse di rete delle VM Azure Local.

Figura 24: Configurazione dei dati di base della Logical Network da associare alla Custom Location dell’ambiente Azure Local

Nella scheda Network Configuration definite lo spazio di indirizzamento che verrà usato dalle VM collegate alla Logical Network.

Potete scegliere tra assegnazione DHCP o Static. Nel mio laboratorio ho scelto Static, così Azure Local assegnerà gli indirizzi IP alle VM usando il pool configurato nel portale.

L’obiettivo è permettere alle VM create su Azure Local di comunicare correttamente con l’ambiente di laboratorio e di poter uscire verso Internet.

Ho configurato la subnet 192.168.200.0/24 perché questa rete è indicata nella documentazione di LocalBox come subnet associata alla VLAN 200 e pensata per l’uso con le VM Arc-enabled create nel laboratorio.

Il Default Gateway 192.168.200.1 permette alle VM di usare il percorso di rete previsto da LocalBox per raggiungere l’esterno. Il DNS Server 192.168.1.254 punta invece al domain controller creato durante il deployment. Questa scelta è importante perché consente alle VM non solo di risolvere i nomi, ma anche di utilizzare i servizi Active Directory del dominio jumpstart.local.

In questo modo se durante la creazione della VM abilitate il domain join, la macchina potrà usare il domain controller del laboratorio per entrare nel dominio creato da LocalBox. È una configurazione più completa rispetto a una rete isolata, perché vi permette di testare scenari più vicini a quelli reali: VM connesse alla rete, risoluzione DNS interna, accesso a Internet e integrazione con Active Directory.

Figura 25: Configurazione dell’indirizzamento IP statico della Logical Network usata dalle VM Azure Local

Se la validazione è superata selezionate Create. Al termine della creazione la Logical Network sarà disponibile e potrà essere selezionata durante la creazione della network interface della risorse Azure Local.

Figura 26: Revisione e creazione della Logical Network

Al termine della creazione tornate nella sezione Resources > Logical networks dell’istanza localboxcluster e aggiornate la pagina.

Figura 27: Logical Network Production creata correttamente e disponibile nell’istanza Azure Local localboxcluster

Creare una nuova VM usando l’immagine scaricata

Dopo aver aggiunto l’immagine Windows Server 2025 Datacenter: Azure Edition, potete procedere con la creazione della nuova macchina virtuale su Azure Local.

Dalla risorsa localboxcluster aprite Resources > Virtual machines e selezionate Create VM. Nel wizard di creazione compilate i campi richiesti, indicando il nome della macchina virtuale, il tipo di macchina virtuale e il profilo di sicurezza.

Nel campo Image selezionate l’immagine precedentemente scaricata da Azure Marketplace e resa disponibile nel cluster storage. Questo è il passaggio che collega la nuova VM al file VHD preparato nella fase precedente.

Completate poi la configurazione delle risorse hardware, specificando il numero di vCPU, la quantità di memoria e le credenziali dell’account amministratore locale. Potete lasciare lo storage path su selezione automatica, così sarà Azure Local a scegliere il percorso più adatto tra quelli disponibili.

Se volete che la VM effettui il domain join, provvedete ad inserire le informazioni richieste. Vi ricordo che il dominio creato si chiama jumpstart.local.

Proseguite con Next.

Figura 28: Creazione di una nuova VM Azure Local dal portale Azure utilizzando l’immagine Server2025 scaricata da Azure Marketplace

Per impostazione predefinita la macchina virtuale viene creata solo con il disco del sistema operativo, derivato dall’immagine selezionata nel passaggio precedente.

Nella scheda Disks potete aggiungere uno o più data disk, creando nuovi dischi oppure collegando dischi già esistenti. Nel nostro test non è necessario aggiungere dischi aggiuntivi, quindi potete lasciare la configurazione predefinita e proseguire con Next.

Figura 29: Configurazione dei dischi della nuova VM Azure Local, con possibilità di aggiungere data disk

Nella scheda Networking selezionate Add network interface e compilate i campi richiesti.

Assegnate un nome alla scheda di rete e selezionate la Logical Network nel campo Network. Poiché la Logical Network è stata configurata con indirizzamento statico, il tipo IPv4 risulta Static. Lasciando Allocation Method su Automatic, Azure Local assegnerà automaticamente alla VM un indirizzo IP libero dal pool configurato. Altrimenti potete assegnare voi un indirizzo scelto dal pool che abbiamo indicato prima al momento della creazione della Logical Network.

Anche in questa schermata il Network Security Group non può essere selezionato. È lo stesso comportamento visto durante la creazione della Logical Network: nel deployment LocalBox utilizzato non è stato distribuito il Network Controller, quindi le funzionalità SDN per la gestione degli NSG non sono disponibili.

Per questo motivo ho lasciato Network security group impostato su None e ho proseguito con Add.

Figura 30: Aggiunta della network interface Prod-1 alla VM Azure Local usando la Logical Network Production

Controllate con attenzione i valori prima di procedere, in particolare immagine, dimensionamento, storage path, credenziali amministrative e network interface. Se tutto è corretto, selezionate Create per avviare il provisioning della VM.

A questo punto Azure invia la richiesta all’ambiente Azure Local tramite Azure Arc e Arc Resource Bridge. La VM verrà quindi creata sul cluster locale, ma sarà visibile e gestibile dal portale Azure.

Figura 31: Revisione finale e avvio della creazione della VM NicVM01 su Azure Local dal portale Azure

Dopo aver avviato la creazione della VM, attendete il completamento del provisioning. Nel mio laboratorio la creazione della macchina NicVM01 ha richiesto circa 30 minuti.

Figura 32: Completamento del deployment della VM NicVM01 e delle risorse associate su Azure Local.

Al termine, aprendo la risorsa dal portale Azure, la VM risulta in stato Running ed è visibile come Machine – Azure Arc (Azure Local). Questo conferma che la macchina virtuale è stata creata sull’istanza Azure Local, ma è gestibile direttamente dal portale Azure tramite Azure Arc.

Nel riepilogo potete verificare i parametri principali: sistema operativo Windows, immagine Server2025, 4 CPU core, 8192 MB di memoria e una scheda di rete associata alla rete Production, con indirizzo IP assegnato automaticamente dal pool configurato nella Logical Network.

Da questa schermata potete anche eseguire le operazioni principali sulla VM, come Start, Stop, Restart, Pause, Save ed eliminazione della risorsa.

Figura 33: VM NicVM01 creata correttamente su Azure Local e gestibile dal portale Azure tramite Azure Arc

Connettersi alla VM con SSH

Per poter gestire e collegarvi alla VM potete utilizzare Settings > Connect della VM NicVM01. Il portale mostra la modalità Connect with SSH, che permette di aprire una sessione verso la macchina usando Azure Arc.

Nel nostro caso abbiamo creato una VM Windows con un account locale, quindi selezionate Password come tipo di autenticazione e inserite il nome utente configurato durante la creazione della VM.

A questo punto potete usare il pulsante Connect in browser per avviare la connessione direttamente dal portale Azure. In alternativa, il portale genera automaticamente il comando Azure CLI da usare da un client SSH, Azure Cloud Shell o PowerShell.

Durante il primo tentativo di connessione viene mostrato un messaggio relativo alla porta 22: la porta non è ancora consentita per le connessioni SSH alla risorsa. Azure chiede quindi se volete aggiornare la configurazione del servizio per abilitare le connessioni sulla porta 22. Rispondete y.

Subito dopo viene visualizzato il fingerprint della chiave del server. Anche questo è normale alla prima connessione: confermate con yes per aggiungere la VM all’elenco degli host conosciuti. A questo punto viene richiesta la password dell’utente locale, che è la stessa password impostata nel wizard di creazione della VM.

Inserite la password configurata durante la creazione della VM. Se la rete, il guest management e la configurazione Arc sono corretti, la sessione SSH verrà aperta direttamente verso la VM NicVM01.

Questa modalità è molto comoda perché vi permette di connettervi alla macchina senza esporre direttamente un indirizzo IP pubblico della VM. La connessione passa attraverso Azure Arc e sfrutta la configurazione gestita dal portale Azure.

Figura 34: Connessione alla VM NicVM01 tramite Azure Arc SSH da Azure Cloud Shell con autenticazione tramite password locale

Verificare la configurazione IP della VM

Dopo aver effettuato l’accesso alla VM NicVM01 tramite Azure Arc SSH, potete verificare che la configurazione di rete sia stata applicata correttamente.

Dalla sessione aperta in Cloud Shell, eseguite ipconfig /all

L’output mostra che la VM ha ricevuto un indirizzo IP dalla Logical Network Production configurata in precedenza. Nel mio caso l’indirizzo assegnato è 192.168.200.50, con subnet mask 255.255.255.0 e default gateway 192.168.200.1.

È importante notare anche il DNS configurato: 192.168.1.254. Questo indirizzo punta al domain controller creato da LocalBox e consente alla VM di risolvere i nomi del dominio jumpstart.local. Questa configurazione è utile anche se volete successivamente effettuare il join della VM al dominio del laboratorio.

La verifica conferma quindi che la VM è collegata alla rete corretta, ha ricevuto un IP dal pool configurato e può usare il gateway previsto per la navigazione verso Internet.

Figura 35: Verifica della configurazione IP della VM NicVM01 con indirizzo assegnato dalla Logical Network Production e DNS del domain controller LocalBox

Verificare la connettività Internet della VM

Dopo aver verificato la configurazione IP, potete controllare che la VM sia effettivamente in grado di uscire verso Internet.

Dalla sessione SSH aperta verso NicVM01, eseguite un semplice test di connettività, ad esempio ping www.ictpower.it

Nel mio laboratorio la VM risolve correttamente il nome DNS e riceve risposta dall’indirizzo pubblico del sito. Il test termina con 0% packet loss, confermando che la rete Production è configurata correttamente, che il gateway 192.168.200.1 permette l’uscita verso Internet e che il DNS indicato nella Logical Network funziona.

Questo passaggio è importante perché valida tutta la configurazione fatta in precedenza: Logical Network, pool IP, gateway, DNS e connettività della VM creata su Azure Local.

Figura 36: Verifica della connettività Internet della VM NicVM01 tramite ping verso un sito pubblico

Collegarsi alla VM Windows in RDP over SSH

Dalla pagina Connect della VM NicVM01, il portale vi propone il comando az ssh arc. Per aprire una sessione Remote Desktop dovete aggiungere il parametro –rdp.

Il comando diventa quindi:

Eseguite il comando da una macchina Windows con Azure CLI installata, oppure da un ambiente che supporti l’apertura del client RDP. Alla richiesta delle credenziali, inserite la password dell’utente locale creato durante il provisioning della VM.

Questa modalità crea un tunnel sicuro tramite Azure Arc e poi apre la connessione RDP verso la VM. È utile perché non richiede di esporre direttamente la porta 3389 o un IP pubblico della macchina.

Dopo l’autenticazione dell’utente locale, viene avviata automaticamente la connessione Remote Desktop. La finestra di sicurezza di Windows vi chiede le credenziali per collegarvi a localhost, perché il tunnel RDP viene aperto localmente dal comando az ssh arc.

Quando inserite l’utente, usate l’account locale della VM in uno di questi formati: .\username oppure Computrname\username. Ovviamente se la macchina è joinata al dominio potete utilizzare la notazione Domain\username.

Inserite poi la password configurata durante la creazione della VM.

Figura 37: Avvio della connessione Remote Desktop tramite Azure Arc SSH e richiesta delle credenziali locali della VM Windows

Figura 38: Conferma del certificato RDP della VM NicVM01 durante la connessione Remote Desktop tramite Azure Arc SSH

Figura 39: Accesso RDP alla VM Windows NicVM01 tramite Azure Arc SSH e verifica delle informazioni di sistema da Server Manager

NOTA: Avete già letto la mia guida Connessione Remote Desktop (RDP) ai Windows Server 2025 gestiti con Azure Arc utilizzando SSH – ICT Power?

Conclusioni

Jumpstart LocalBox è un ottimo punto di partenza per provare Azure Local senza dover predisporre subito hardware fisico dedicato. In poche ore avete a disposizione un laboratorio completo, con cluster a due nodi, Azure Arc, Resource Bridge, Custom Location, storage, networking e gestione delle VM dal portale Azure.

L’aspetto più interessante è che potete vedere concretamente come Azure Local estende il modello operativo di Azure verso l’infrastruttura locale. Le VM vengono eseguite nel cluster, ma vengono create, controllate e monitorate dal portale Azure, con un’esperienza molto simile a quella delle risorse cloud native.

Naturalmente LocalBox resta un ambiente di test e valutazione. Non sostituisce un progetto di produzione, ma vi permette di prendere confidenza con architettura, deployment, aggiornamenti, immagini, reti logiche e provisioning delle VM prima di affrontare una distribuzione reale.

Al termine della prova ricordatevi di eliminare le risorse non più necessarie, così da evitare costi inutili nella sottoscrizione Azure.

Maggiori informazioni sono disponibili alla pagina https://jumpstart.azure.com/azure_jumpstart_localbox/deployment_az