Aggiornare a Windows 11 22H2 con Intune ed Endpoint Manager

Windows 11 22H2 con Intune: quando l’upgrade va trattato come change controllato

Passare a Windows 11 22H2 con Intune non è un semplice “aggiorna e spera”. Se gestisci un parco macchine aziendale, il punto non è solo distribuire la feature update: devi capire quali dispositivi sono davvero pronti, quali dipendono da applicazioni legacy e quali policy potrebbero trasformare un upgrade banale in una giornata di ticket. Il modo corretto è trattarlo come un change controllato, con osservabilità prima della spinta e rollback definito prima ancora del primo pilota.

Il vantaggio di Intune è che puoi governare il rollout in modo graduale, combinando requisiti di compatibilità, anelli di distribuzione e reporting centralizzato. Il rischio, però, è pensare che la console risolva da sola problemi di firmware, cifratura, driver o spazio disco. Non lo fa. Ti serve una base pulita: inventario affidabile, criteri coerenti e una sequenza di verifica che parta dal dispositivo, non dalla policy.

Prima di creare la policy: stato atteso e stato osservato

Stato atteso: i device destinati a Windows 11 22H2 risultano compatibili, ricevono la feature update da Intune, completano il download senza errori e si riavviano entro la finestra prevista. Stato osservato: spesso trovi endpoint bloccati per requisiti mancanti, policy in conflitto, spazio insufficiente o download fermo a metà senza un errore evidente lato utente.

La differenza operativa sta nel fatto che la compatibilità non va dedotta a occhio. Va misurata. Prima di spingere il rollout conviene verificare: versione attuale del sistema, stato di BitLocker, presenza di TPM 2.0, Secure Boot, spazio libero su disco e salute generale dell’Enrollment. Se uno di questi elementi è ambiguo, il problema non è “Intune non funziona”: il problema è che stai chiedendo a una macchina non pronta di fare un salto di release.

Prerequisiti tecnici che vale la pena validare davvero

Per ridurre i falsi positivi, conviene separare i requisiti in tre gruppi: hardware, management e applicazioni. Sul lato hardware, Windows 11 richiede una base più rigorosa di Windows 10: TPM, Secure Boot, CPU supportata e firmware allineato. Sul lato management, devi essere sicuro che il dispositivo sia correttamente registrato in Intune e che riceva policy e profili senza errori di sincronizzazione. Sul lato applicazioni, devi sapere se esistono software con driver, agent o componenti che hanno storicamente sofferto i feature update.

Un controllo utile è partire dal report di compatibilità e da un campione reale di endpoint. Se hai Microsoft Endpoint Analytics disponibile, l’analisi di readiness ti dà una fotografia molto più onesta di una checklist compilata a mano. Se non hai quel livello di telemetria, il minimo sindacale è incrociare inventario hardware, versione OS e stato di cifratura con i log del client. Meglio ancora se lo fai prima di creare il ring di produzione, non dopo il primo blocco di utenti.

Per una verifica rapida lato macchina, i controlli utili sono questi:

systeminfo | findstr /B /C:"OS Name" /C:"OS Version"
manage-bde -status
msinfo32

Il punto non è automatizzare tutto con uno script alla cieca, ma avere un riferimento verificabile. Se `manage-bde -status` mostra BitLocker attivo e protetto, `msinfo32` conferma Secure Boot e il sistema risulta allineato alla build prevista, hai già ridotto parecchio il rischio di upgrade fallito per cause banali.

Come impostare il rollout in Intune senza trasformarlo in un salto nel buio

La strategia più pulita è usare Windows Update for Business con feature update policy o update ring, a seconda di come hai già strutturato il tenant. Se stai introducendo Windows 11 22H2 come change controllato, ha senso dedicare un gruppo pilota ristretto, un ring di validazione e solo dopo un ring più ampio. Non mischiare i dispositivi critici con quelli di test: sembra ovvio, ma è il punto in cui molte migrazioni iniziano male.

In Intune il percorso tipico è definire il target di distribuzione, associare la policy e monitorare lo stato di installazione. Se la tua organizzazione usa gruppi dinamici, verifica che la logica di membership non includa macchine non pronte. Un errore frequente è mettere in produzione una regola basata solo su modello o versione attuale del sistema, senza tenere conto della compatibilità reale. Il risultato è un gruppo “corretto” sulla carta e disastroso nella pratica.

Un criterio prudente è questo: prima pilota su un gruppo piccolo e rappresentativo, poi estensione per ondate. Nel pilota devono esserci almeno un laptop standard, una macchina con periferiche particolari, un device che usa VPN e uno che vive fuori sede. Se il rollout regge su quel campione, hai una base più solida per allargare. Se invece si rompe subito, hai risparmiato un danno più grande.

Sequenza operativa consigliata: dal tenant al dispositivo

La sequenza corretta non è “crea policy e distribuisci”. È: verifica stato, prepara gruppi, testa su pilota, osserva, poi allarghi. In pratica:

1. Verifica che i dispositivi target siano già in una baseline accettabile di patch e che non abbiano errori aperti di enrollment o compliance.
2. Crea o aggiorna il gruppo di destinazione con un numero limitato di endpoint reali, non solo device di laboratorio.
3. Assegna la feature update policy per Windows 11 22H2 e controlla la propagazione lato client.
4. Monitora installazione, download, riavvio e post-upgrade per almeno un ciclo operativo completo.
5. Solo se gli indicatori restano stabili, espandi l’assegnazione al ring successivo.

Il valore di questa sequenza è che ti consente di distinguere un problema di distribuzione da un problema di compatibilità. Se il client non riceve la policy, stai guardando un tema di management. Se riceve la policy ma non parte il download, spesso il problema è nel servizio Windows Update, nella connettività o nello spazio libero. Se il download parte e poi fallisce, il colpevole può essere un driver, una prerogativa di sicurezza o una condizione di sistema non prevista.

Cosa controllare sul client quando l’upgrade non parte

Quando un endpoint resta fermo, conviene evitare il classico “riavvia e prova di nuovo” come prima risposta. Meglio raccogliere evidenze minime. Il primo punto è capire se il dispositivo vede davvero la policy. Il secondo è verificare se Windows Update sta lavorando oppure se è bloccato da un errore locale. Il terzo è controllare gli eventi di sistema e i log del client MDM.

Dal punto di vista pratico, i log più utili si trovano sotto `Event Viewer` e nei report di Intune. Se vuoi un controllo locale, il comando `Get-WindowsUpdateLog` può essere utile in alcuni casi, ma non è sempre il primo strumento da aprire in ambienti moderni. Più spesso conviene partire dallo stato della sincronizzazione MDM e dalla presenza della feature update in elenco. Se la policy è assegnata ma il device non la riceve, la causa è quasi sempre a monte del download.

Un esempio di verifica rapida è questo:

dsregcmd /status
schtasks /query /tn "\Microsoft\Windows\EnterpriseMgmt\*"
Get-EventLog -LogName System -Newest 50

`dsregcmd /status` ti aiuta a capire se il device è correttamente registrato e in quale stato si trova l’accesso al tenant. La query dei task schedulati mostra se il canale di gestione MDM è vivo. Gli eventi di sistema danno indizi su errori di update, riavvii forzati o condizioni di inattività anomale.

Le tre cause più comuni di fallimento e come riconoscerle in pochi minuti

La prima causa è la mancanza di prerequisiti. In pratica il device non è pronto per Windows 11 22H2 e il problema viene scoperto solo quando provi a installare. Lo falsifichi rapidamente guardando compatibilità hardware, TPM, Secure Boot e spazio disco. Se uno di questi elementi è fuori soglia, non serve aprire un ticket su Intune: devi correggere il device.

La seconda causa è il conflitto tra policy o anelli di aggiornamento. Succede quando una configurazione di update ring, una feature update policy e magari una baseline di sicurezza tirano in direzioni diverse. Lo verifichi confrontando assegnazioni e filtri di gruppo, e controllando se il device riceve più istruzioni incompatibili. Se trovi regole sovrapposte, il fix è di governance, non di troubleshooting locale.

La terza causa è l’errore operativo sul rollout: target troppo ampio, poche metriche, nessun pilota. Si riconosce perché il problema non emerge su uno o due device ma su una porzione significativa del parco, spesso con pattern simili. In quel caso il rollback o la sospensione della policy è la mitigazione immediata, non un ammettere sconfitta: è il comportamento corretto quando il blast radius supera la soglia accettabile.

Rollback e mitigazione: cosa fare se il rollout si sporca

Se il rollout mostra errori diffusi, la prima mossa è fermare l’espansione. In Intune questo significa disassegnare temporaneamente la policy dal ring più ampio o restringere il target al solo pilota, in base a come hai strutturato le assegnazioni. Il rollback vero e proprio non è sempre il downgrade immediato del sistema: spesso il rollback più efficace è bloccare la distribuzione e riportare il perimetro a un insieme noto e verificato.

Prima di cambiare qualsiasi cosa, annota il blast radius: quanti device sono coinvolti, quali reparti, quali sedi e quali user profile. Se hai già iniziato il download su molti endpoint, valuta l’impatto di una sospensione rispetto alla prosecuzione. In alcuni casi conviene lasciare completare il ciclo ai device già quasi pronti e fermare solo i nuovi target. In altri, quando emergono errori consistenti di compatibilità, conviene bloccare tutto e rivedere i prerequisiti.

Per una gestione ordinata, tieni traccia di: policy assegnata, gruppo target, finestra di rollout, numero di device in successo e in errore, e note di eventuali eccezioni. Queste informazioni sono la tua rete di sicurezza quando devi spiegare perché hai fermato l’upgrade o perché hai deciso di procedere solo su una parte del parco.

Un dettaglio spesso sottovalutato: applicazioni e driver

Molti upgrade falliscono non per il sistema operativo in sé, ma per il layer applicativo. Un agent VPN, un software di cifratura, un modulo di stampa o un driver di periferica possono essere perfettamente innocui su Windows 10 e diventare un problema al primo feature update. Per questo, nel pilota, non basta verificare che il desktop si avvii: devi verificare che l’utente riesca a lavorare.

La prova utile è concreta: accesso a VPN, stampa, autenticazione a servizi SSO, sincronizzazione file, apertura delle applicazioni core e riavvio successivo. Se una di queste attività si rompe, hai una regressione funzionale anche se l’upgrade risulta “completato con successo” nella console. Questo è il classico caso in cui il reporting da solo non basta: serve una checklist funzionale costruita sulle abitudini reali degli utenti.

Osservabilità minima da tenere aperta durante il cambio

Se vuoi evitare di navigare a vista, tieni sotto controllo almeno tre indicatori: tasso di successo dell’installazione, error rate dei device in target e tempo medio di completamento. Se il tempo medio si allunga troppo, il problema può essere di banda, di prestazioni disco o di policy di riavvio troppo aggressive. Se l’error rate sale, fermati e confronta i log degli endpoint che hanno fallito con quelli che sono andati a buon fine.

La metrica obiettivo non è “far arrivare tutti a Windows 11 22H2 in fretta”. La metrica obiettivo è ridurre il numero di fallimenti per ondata e mantenere stabile l’esperienza utente. Se hai un target interno, fissalo in modo misurabile: ad esempio, completamento del pilota con error rate sotto una soglia concordata e nessuna regressione sulle app critiche. Senza una soglia, ogni decisione diventa opinione.

Conclusione operativa: la migrazione buona è quella che non sorprende

Aggiornare a Windows 11 22H2 con Intune funziona bene quando il processo è disciplinato: readiness prima, pilota ristretto, osservazione reale, espansione graduale. Il valore di Intune non sta nel premere un pulsante, ma nel poter controllare chi riceve cosa, quando e con quali criteri. Se usi questo controllo per ridurre l’incertezza, l’upgrade diventa un change gestibile. Se lo usi come scorciatoia per evitare verifiche, stai solo spostando il problema più avanti.

In pratica, il consiglio è semplice: non fidarti della sola assegnazione della policy, valida il dispositivo e il contesto, misura il comportamento e fermati appena il blast radius cresce oltre il previsto. È meno spettacolare di un rollout massivo, ma molto più utile quando devi arrivare a fine giornata con utenti operativi e una console piena di dati che puoi davvero difendere.