Windows Admin Center: la console unificata

Windows Admin Center (WAC) è una console browser-based che centralizza la gestione di server standalone, failover cluster e cluster iperconvergenti (S2D), oltre ai client Windows, senza aprire decine di snap-in MMC separati. Si distribuisce in due modalità principali: desktop mode su Windows 10/11 per un uso locale da postazione singola, e gateway mode su un Windows Server, dove diventa un servizio raggiungibile via HTTPS da più amministratori contemporaneamente. In ambiente ibrido puoi anche usare Windows Admin Center nel portale Azure per amministrare le VM Azure e i server Azure Arc-enabled direttamente dal browser.

Il gateway è il cuore dell’architettura: si connette ai nodi gestiti tramite PowerShell remoting e WMI, quindi ogni server target deve avere WinRM attivo e raggiungibile. L’autenticazione al gateway può appoggiarsi a Microsoft Entra ID con controllo RBAC (gateway administrators e gateway users) oppure ai gruppi locali della macchina gateway. WAC integra inoltre gli Azure hybrid services — Azure Backup, Azure Site Recovery, Azure Monitor, Azure File Sync e la gestione degli update — diventando il punto d’ingresso naturale verso Azure per i server on-premises.

Amministrazione remota: WinRM e TrustedHosts

L’amministrazione remota di Windows Server si basa su WinRM, l’implementazione Microsoft del protocollo WS-Management, che veicola PowerShell remoting e alimenta sia WAC sia Server Manager. WinRM ascolta su HTTP (porta 5985) e HTTPS (porta 5986); su Windows Server è di norma già abilitato, altrimenti si attiva con Enable-PSRemoting.

Il punto critico d’esame è l’autenticazione. In un dominio, Kerberos gestisce l’autenticazione mutua in modo trasparente e non serve configurazione aggiuntiva. Quando invece il target è in workgroup o in una foresta non trusted, Kerberos non è disponibile e si ricade su NTLM: in quel caso bisogna aggiungere il nome dell’host alla lista TrustedHosts del client con Set-Item WSMan:\localhost\Client\TrustedHosts. TrustedHosts si configura sul client che avvia la connessione, non sul server di destinazione. Per lo scenario double-hop — rilanciare le credenziali verso un terzo server — servono invece CredSSP o la delega Kerberos vincolata.

Gestione degli update: da Update Management ad Azure Update Manager

La gestione degli aggiornamenti in ambiente ibrido è passata da Update Management di Azure Automation al più recente Azure Update Manager. La versione legacy si appoggiava a un Automation account e a un workspace Log Analytics con l’agente installato sui server, ed è ormai deprecata a favore del nuovo servizio.

Azure Update Manager è il servizio nativo che la sostituisce: non richiede né Automation account né Log Analytics workspace e opera direttamente sulle risorse. Per portare sotto governance un server on-premises o in un altro cloud la chiave è Azure Arc: con il Connected Machine agent il server diventa Arc-enabled ed è trattato come risorsa Azure, con assessment periodico e patching pianificato. La pianificazione avviene tramite maintenance configurations (finestre di manutenzione), che definiscono quando e quali classi di update installare, sia per Windows sia per Linux.

Azure Automation resta rilevante nel programma AZ-800 per le altre sue funzioni: runbook di process automation (PowerShell/Python), Hybrid Runbook Worker per eseguire runbook sui server on-premises, State Configuration (DSC) e Change Tracking and Inventory. Non confondere queste capacità con l’update management, che ora vive in un servizio dedicato. Per i dettagli operativi e le date di transizione fai sempre riferimento alla documentazione ufficiale, ricordando che l’esame AZ-800 sarà ritirato il 30 settembre 2026 (passing score 700/1000).

Trappole tipiche d’esame

  • Gestire via WinRM un server in workgroup → soluzione: aggiungi l’host alla lista TrustedHosts del client; fuori dominio manca Kerberos e la sola Enable-PSRemoting non abilita l’autenticazione NTLM cross-machine.
  • “Senza Automation account né Log Analytics workspace” → soluzione: lo scenario punta ad Azure Update Manager; se la traccia cita workspace e Automation account si riferisce invece all’Update Management legacy, ormai deprecato.
  • Portare un server on-premises sotto Azure Update Manager → soluzione: onboarda la macchina con Azure Arc (Connected Machine agent); senza Arc il server non è una risorsa Azure e Update Manager non può gestirlo.
  • Console unica per più amministratori e più server → soluzione: installa WAC in gateway mode su Windows Server; la desktop mode su Windows 10/11 serve solo per l’uso locale da singola postazione.
  • Da una sessione remota accedere a una share su un terzo server → soluzione: è il classico double-hop, che richiede CredSSP o la delega Kerberos vincolata; TrustedHosts non risolve il problema.
  • Installare gli update solo in finestre pianificate → soluzione: usa le maintenance configurations di Azure Update Manager; l’assessment periodico da solo rileva la compliance ma non installa nulla.