Cosa sono gli Azure Arc-enabled servers

Azure Arc estende il control plane di Azure (Azure Resource Manager) a macchine che vivono fuori da Azure: server on-prem, in altri cloud o all’edge. Una volta collegata, la macchina viene “proiettata” in Azure come risorsa ARM di tipo Microsoft.HybridCompute/machines, con un proprio resource ID, tag e assegnazioni RBAC. Da quel momento un Windows Server (2019/2022/2025) fisico o virtuale ospitato nel datacenter locale si gestisce con gli stessi strumenti di una Azure VM: Azure Policy, Azure Monitor, Microsoft Defender for Cloud, Azure Update Manager, Change Tracking e Inventory. Arc NON sposta né virtualizza il carico: la macchina resta dov’è, cambia solo il piano di management. È il cuore dell’hybrid-management richiesto in AZ-800.

Onboarding: agente, interattivo e su larga scala

Il collegamento richiede il Connected Machine agent (azcmagent), diverso dall’Azure VM agent. Include HIMDS (metadata e identity), il guest configuration agent e l’extension manager. L’agente comunica solo in outbound su HTTPS 443 verso gli endpoint Azure/Arc; per reti isolate si usa un proxy, l’Arc gateway o un Azure Arc Private Link Scope, mai aprendo porte inbound.

Per pochi server l’onboarding interattivo (azcmagent connect con login Entra) è sufficiente. Per il server-onboarding di massa si genera dal portale uno script che si autentica con un service principal dedicato, così non serve login umano su ogni macchina. Il principio chiave è il least privilege: il service principal deve avere solo il ruolo Azure Connected Machine Onboarding, non Contributor o Owner. Prima di collegare, registra i resource provider nella subscription (Microsoft.HybridCompute, Microsoft.GuestConfiguration, Microsoft.HybridConnectivity).

Estensioni e managed identity

Dopo l’onboarding il server ottiene una system-assigned managed identity e può ricevere le VM extensions come una Azure VM: Azure Monitor Agent per la telemetria, Custom Script Extension, Key Vault extension, Hybrid Runbook Worker per Automation, l’estensione di Defender for Cloud. Le estensioni sono il meccanismo con cui monitoring, sicurezza e configurazione “scendono” nel server on-prem. La managed identity permette alla macchina di autenticarsi verso risorse Azure (es. leggere segreti da Key Vault) senza credenziali salvate localmente.

Governance con Azure Policy

Poiché l’Arc-enabled server è una risorsa ARM, Azure Policy lo governa come qualsiasi risorsa cloud: si assegnano le policy a management group, subscription o resource group e valgono anche per l’ibrido. Due pattern da distinguere:

  • Policy con effetto DeployIfNotExists (DINE) che installano automaticamente un’estensione mancante (tipico: distribuire Azure Monitor Agent su tutti gli Arc server non conformi).
  • Policy di Guest Configuration (machine configuration) che verificano o applicano impostazioni dentro il sistema operativo (audit di password policy, servizi, applicazioni installate). Richiedono il guest configuration agent — già incluso nell’agente — e la managed identity.

Il risultato è un inventario e una postura di conformità unificati tra cloud e on-prem, valutati nella stessa dashboard di compliance. Per il dettaglio di ruoli e prerequisiti fai sempre riferimento alla documentazione ufficiale Microsoft.

Trappole tipiche d’esame

  • Onboarding di centinaia di server → soluzione: service principal. L’auth interattiva azcmagent connect va bene per pochi nodi; a scala serve uno script con service principal per evitare il login manuale su ogni macchina.
  • Ruolo del service principal → soluzione: Azure Connected Machine Onboarding. È il ruolo a privilegio minimo per collegare; Contributor/Owner sono sovradimensionati e sono risposte trappola.
  • Connettività in rete isolata → soluzione: Private Link Scope / proxy / Arc gateway. L’agente lavora in outbound 443; aprire porte inbound o esporre il server è errato.
  • Applicare la stessa regola a molti server → soluzione: Azure Policy a management group/subscription. Configurare ogni server singolarmente non scala; le policy ereditano lungo la gerarchia.
  • Installare un’estensione sui non conformi → soluzione: policy DeployIfNotExists. Non è Guest Configuration: quest’ultima verifica impostazioni interne all’OS, non installa estensioni.
  • Verificare impostazioni dentro l’OS → soluzione: Guest Configuration + managed identity. Serve l’identità gestita del server; senza di essa l’assegnazione resta non valutata.