Azure Arc, Update Manager e Automation per i server ibridi

Azure Arc è il punto in cui AZ-802 smette di chiedere «che cos’è» e comincia a chiedere «con quale proprietà». Che un server on-premises registrato in Arc diventi una risorsa Microsoft.HybridCompute/machines è dato per scontato: quello che l’esame misura è se sai quale ruolo serve per l’onboarding di massa, quale valore di assignmentType corregge la deriva di configurazione, perché una schedule di patching funziona sui server Arc e non sulle VM Azure della stessa sottoscrizione, e dove gira davvero il codice di un runbook.

Onboarding di massa: l’agente, il service principal, la GPO

L’agente si chiama Azure Connected Machine agent e la sua interfaccia da riga di comando è azcmagent. Prima di collegare qualsiasi macchina vanno registrati i resource provider Microsoft.HybridCompute, Microsoft.GuestConfiguration, Microsoft.HybridConnectivity e — se ci sono istanze SQL Server — Microsoft.AzureArcData.

Per centinaia di macchine il login interattivo non è un’opzione: si crea un service principal di Microsoft Entra ID e gli si assegna il ruolo Azure Connected Machine Onboarding, limitato alla landing zone di destinazione. Il segreto generato dura un anno e va rigenerato alla scadenza. Punto che l’esame ama: il service principal serve solo durante l’onboarding, non viene usato per nient’altro dopo.

Su un parco già joinato a un dominio AD DS la strada nativa è la Group Policy. Serve una share remota raggiungibile dai domain controller e dalle macchine (computer di dominio con permesso Change), dove si copiano il pacchetto MSI dell’agente e i file del progetto ArcEnabledServersGroupPolicy: EnableAzureArc.ps1, DeployGPO.ps1 e AzureArcDeployment.psm1. Si esegue DeployGPO.ps1 sul domain controller, passando FQDN del dominio, share, client ID e secret del service principal, sottoscrizione, resource group, region e tenant. Nasce una GPO chiamata [MSFT] Azure Arc Servers (datetime), che si collega alla OU desiderata e contiene una scheduled task. A onboarding verificato la GPO va disabilitata, altrimenti la task si ripresenta a ogni riavvio o refresh delle policy.

Una volta collegata, la macchina riceve una managed identity assegnata dal sistema. Un’applicazione locale ottiene un token dall’endpoint IMDS su http://localhost:40342, scoprendolo dalle variabili d’ambiente IDENTITY_ENDPOINT e IMDS_ENDPOINT. La risposta iniziale è una sfida: il client deve leggere un file di challenge token e ripresentarlo come header Authorization: Basic. Per leggerlo, su Windows l’account deve appartenere agli Administrators locali oppure al gruppo Hybrid Agent Extension Applications; su Linux al gruppo himds. È questo il modo per far leggere a un servizio locale un certificato da Azure Key Vault senza mettere password, secret o certificati client sul disco.

Estensioni VM su macchine non-Azure

Il Connected Machine agent porta su una macchina non-Azure lo stesso modello di estensioni delle VM Azure: Azure Monitor Agent, Azure Key Vault (KeyVaultForWindows), Custom Script Extension, WindowsOsUpdateExtension, HybridWorkerForWindows, Windows Admin Center, Microsoft Defender for Endpoint. Il ruolo che le distribuisce è Azure Connected Machine Resource Administrator, che però include anche la cancellazione della risorsa: valutalo prima di darlo.

Attenzione a una assenza: l’estensione Desired State Configuration non è più disponibile per i server Arc. La via documentata è la migrazione a machine configuration, o in subordine la Custom Script Extension.

Le estensioni nascono con l’aggiornamento automatico attivo. In un change freeze la mossa corretta non è disinstallare l’estensione né disconnettere l’agente — la macchina deve restare connessa e continuare a mandare dati — ma disattivare l’auto-upgrade su quella singola estensione:

Update-AzConnectedMachineExtension -ResourceGroup RG -MachineName SRV01 `
  -Name AzureMonitorWindowsAgent -EnableAutomaticUpgrade:$false

L’equivalente CLI è az connectedmachine extension update --enable-auto-upgrade false. Utile sapere i tempi: un aggiornamento automatico ordinario può impiegare fino a otto settimane a raggiungere tutte le macchine, mentre le versioni che chiudono vulnerabilità critiche viaggiano su un canale accelerato di tre settimane.

Device configuration = Azure Machine Configuration

«Device configuration by using Azure Arc» significa Azure Machine Configuration, cioè l’ex Azure Policy guest configuration. Automation State Configuration (DSC) è il legacy da cui si migra, non la risposta. Sulle VM Azure servono l’estensione di machine configuration e una managed identity di sistema; sui server Arc l’estensione non serve, perché il motore è già dentro il Connected Machine agent (per i pacchetti che applicano configurazioni serve agent 1.10.0 o superiore).

Le definizioni che intervengono dentro la macchina usano l’effetto DeployIfNotExists e creano una guest assignment il cui comportamento dipende da assignmentType (proprietà case sensitive):

Da qui la risposta al caso classico: se gli amministratori locali cambiano a mano un’impostazione e l’assegnazione resta NonCompliant, la correzione continua non si ottiene con una remediation task una tantum ma portando assignmentType ad ApplyAndAutoCorrect. E siccome i risultati per singola impostazione finiscono nella compliance di Azure Policy, l’audit dell’intero parco — Azure e Arc insieme — si legge nella stessa dashboard. L’agente cerca assegnazioni nuove ogni 5 minuti e rivaluta quelle attive ogni 15 minuti; la spunta Create a remediation task serve a coprire le macchine già esistenti al momento dell’assegnazione.

Azure Update Manager

Il servizio corrente è Azure Update Manager, non Azure Update Management di Automation (che era basato su Log Analytics). Non richiede workspace: si appoggia alle estensioni WindowsOsUpdateExtension / LinuxOsUpdateExtension. La valutazione periodica gira ogni 24 ore e si attiva o disattiva dalle Update settings.

La patching pianificata si esprime con una maintenance configuration di scope Guest (Azure VM, Arc-enabled VMs/servers), con finestra massima di 3 ore e 55 minuti. Le macchine si legano staticamente oppure con un dynamic scope, cioè un filtro su sottoscrizione, resource group, location, tipo di risorsa, tipo di OS e tag. La proprietà che l’esame sfrutta: i criteri vengono valutati all’ora di esecuzione, non alla creazione. Se stacchi il tag patchRing = ring1 da una macchina, quella macchina esce dalla schedule al run successivo senza toccare la configurazione.

L’asimmetria più insidiosa riguarda i prerequisiti. Per una VM Azure la patch orchestration deve essere Customer Managed Schedules (sotto il cofano: Patch mode = Azure-orchestrated più BypassPlatformSafetyChecksOnUserSchedule = TRUE). Per un server Arc questo prerequisito non esiste: basta l’associazione alla schedule. È esattamente il motivo per cui una stessa configurazione può patchare 30 server Arc e saltare 20 VM Azure.

Dettaglio di finestra: servono 20 minuti residui per un service pack, 15 per gli altri update, 10 per avviare un riavvio.

Runbook di Azure Automation sui server ibridi

Un runbook di Azure Automation gira per default in una sandbox cloud. Per eseguirlo sulla macchina, serve un Hybrid Runbook Worker. La sola piattaforma supportata è quella extension-based (V2): la versione agent-based, legata al Log Analytics agent, è ritirata dal 31 agosto 2024 e dal 1° aprile 2025 i suoi job vengono fermati.

Il flusso su un server già Arc-enabled è: creare un Hybrid Worker Group (New-AzAutomationHybridRunbookWorkerGroup), poi installare sulla macchina l’estensione HybridWorkerForWindows del publisher Microsoft.Azure.Automation.HybridWorker con New-AzConnectedMachineExtension, passando nei settings l’AutomationAccountURL dell’Automation account. Serve la managed identity di sistema sulla macchina: se manca, viene abilitata durante l’aggiunta.

All’avvio si sceglie Run on → Hybrid Worker nel portale, oppure Start-AzAutomationRunbook -RunOn "NomeGruppo". Si indica il gruppo, mai il singolo worker: i worker fanno polling ogni 30 secondi e prendono i job a chi arriva primo. I job girano sotto l’account System locale, salvo configurare le Hybrid Worker credentials sul gruppo. Se la macchina si riavvia il job riparte da capo, e dopo tre riavvii viene sospeso.

Trappole tipiche d’esame

• Update Manager ≠ Update Management. Se una risposta nomina un Log Analytics workspace, un Automation account o Azure Update Management per installare le patch, è la soluzione ritirata. Update Manager lavora con estensioni e maintenance configuration.
• Il prerequisito di patch orchestration vale solo per le VM Azure. Quando una schedule patcha i server Arc e ignora le VM Azure della stessa sottoscrizione e region, la causa non è la finestra né il dynamic scope: è la patch orchestration da portare a Customer Managed Schedules.
• Il dynamic scope si risolve al momento dell’esecuzione. L’elenco di macchine visto quando hai creato o modificato l’ambito non è quello che verrà patchato: aggiungere o togliere il tag basta a cambiare l’associazione.
• ApplyAndMonitor applica e poi lascia derivare. Contro le modifiche manuali ripetute degli amministratori locali serve ApplyAndAutoCorrect; la remediation task è un intervento una tantum sulle macchine già non conformi, non una guardia continua.
• Device configuration significa Machine Configuration. Non State Configuration, non l’estensione DSC (che sui server Arc non esiste più), e sui server Arc non va installata alcuna estensione aggiuntiva.
• Congelare una versione di estensione si fa con -EnableAutomaticUpgrade:$false, non disinstallando l’estensione e non disconnettendo l’agente: la macchina deve restare connessa e continuare a inviare dati.
• Il service principal serve solo a collegare la macchina. A runtime l’autenticazione verso Azure — Key Vault compreso — passa dalla managed identity di sistema via IMDS, e l’accesso al challenge token dipende dall’appartenenza ad Administrators o a Hybrid Agent Extension Applications.