1 11/10/2026 11 min

Windows Autopilot non è un wizard da cliccare a caso: funziona solo se prima hai messo in ordine tenant, identità, licenze, dispositivi e policy. Il punto pratico è questo: l’utente deve accendere il PC, collegarsi a Internet e ritrovarsi un device già governato, con l’azienda che decide cosa può fare, non il contrario. Se salti la preparazione, il risultato tipico è un onboarding che si ferma su errori di enrollment, profili che non arrivano o dispositivi che entrano in Intune ma non ricevono le configurazioni giuste.

Prerequisiti che vanno verificati prima di toccare Autopilot

La parte noiosa è quella che evita le corse dopo. Prima di registrare un solo device, verifica che il tenant abbia almeno Microsoft Entra ID, Intune attivo, licenze compatibili e una strategia chiara per l’unione al dominio cloud. Autopilot vive di tre cose: identità, gestione e profilo di provisioning. Se una di queste manca, il flusso si rompe.

Controlla anche i modelli di licenza. In pratica, l’utente finale deve avere una licenza che consenta l’uso di Intune e delle funzionalità di gestione associate. Se lavori con gruppi pilota, usa un gruppo ristretto e separato, così puoi isolare i test e non coinvolgere tutta l’azienda per errore.

Dal lato dispositivi, assicurati che i PC siano supportati e che il firmware non abbia blocchi strani su Secure Boot, TPM o rete. In scenari moderni serve quasi sempre TPM 2.0 e un device in condizioni sane. Se il parco è misto, fai un inventario iniziale: modello, SKU, versione BIOS/UEFI, stato TPM, stato di Windows e eventuali personalizzazioni OEM.

Architettura minima: cosa fa davvero Autopilot

Autopilot non installa Windows da zero come un classico imaging. Il device arriva con il sistema operativo già presente, si connette ai servizi Microsoft, viene riconosciuto tramite hardware hash e riceve un profilo di provisioning. Da lì, il flusso decide se il dispositivo si unisce a Entra ID, se entra in modalità self-deploying o user-driven, quali app installare, quali policy applicare e se mostrare o meno schermate all’utente.

La distinzione operativa più importante è tra scenari user-driven e scenari senza utente. Nel primo caso l’utente si autentica e completa l’onboarding. Nel secondo caso il dispositivo si prepara da solo o quasi, utile per kiosk, hot desk o stock device. Se non scegli bene il modello, ti ritrovi con una UX incoerente e ticket inutili.

Passo 1: raccogliere l’hardware hash dei dispositivi

Il device deve essere registrato in Autopilot tramite hardware hash. Il metodo più comune è usare lo script ufficiale di raccolta da PowerShell sul PC target. Esegui lo script con privilegi amministrativi e salva il file CSV generato.

Comando tipico:

Set-ExecutionPolicy -Scope Process Bypass -Force
Install-Script -Name Get-WindowsAutopilotInfo -Force
Get-WindowsAutopilotInfo.ps1 -OutputFile C:\Temp\AutopilotHash.csv

Se usi il comando sopra, verifica che il CSV contenga colonne coerenti con il formato richiesto da Intune e che il file non sia vuoto. Se il file non si genera, controlla connettività Internet, policy PowerShell e permessi locali. In ambienti bloccati, puoi eseguire la raccolta da un terminale amministrativo con script firmato e distribuito internamente.

Per un controllo rapido lato file, basta confermare che il CSV esista e abbia righe utili:

Get-Item C:\Temp\AutopilotHash.csv
Import-Csv C:\Temp\AutopilotHash.csv | Measure-Object

Passo 2: importare i dispositivi in Intune

Una volta ottenuto il file CSV, importalo in Intune nella sezione dedicata ai dispositivi Windows Autopilot. Il punto non è solo caricare il file: devi anche controllare che ogni device venga associato correttamente al tenant e che compaia con i metadati giusti, in particolare seriale e modello.

Nella pratica operativa, dopo l’import cerca i dispositivi nella lista e verifica che lo stato sia successivamente “assegnato” o comunque pronto per il profilo. Se il device resta in stato di attesa troppo a lungo, le cause più frequenti sono file errato, record duplicato, sincronizzazione lenta o problemi di autorizzazione nel tenant.

Se vuoi automatizzare il caricamento, usa Graph API o strumenti amministrativi ufficiali, ma solo dopo aver validato il processo manuale su un gruppo pilota. Automatizzare un flusso non compreso è il modo migliore per moltiplicare gli errori.

Passo 3: creare il profilo di deployment corretto

Il profilo di deployment è il pezzo che definisce il comportamento del device al primo avvio. Qui decidi se il dispositivo si unisce a Microsoft Entra ID, se esegue automaticamente il provisioning, se mostra il nome organizzazione, se salta schermate e quali esperienze consentire all’utente.

Per una configurazione standard aziendale, la scelta più comune è un profilo user-driven con unione a Entra ID e provisioning gestito da Intune. Se hai postazioni condivise o device speciali, valuta modalità diverse. La regola è semplice: non forzare un profilo pensato per laptop personali su un parco kiosk o viceversa.

Quando definisci il profilo, documenta almeno questi elementi: tipo di join, modalità di esperienza utente, lingua e regione, eventuale nominazione del dispositivo e comportamento OOBE. Se uno di questi parametri è lasciato ambiguo, il team di supporto dovrà inseguire differenze di comportamento difficili da diagnosticare.

Passo 4: assegnare il profilo ai gruppi giusti

Il profilo non va appeso al caso. Assegna il deployment profile a un gruppo di dispositivi controllato, meglio se dinamico e costruito su criteri chiari. In fase iniziale usa un gruppo pilota con pochi device noti e utenti disponibili al test. È il modo migliore per intercettare errori di policy, app mancanti o conflitti con configurazioni preesistenti.

Se lavori con gruppi dinamici, documenta bene il filtro usato. Un criterio errato può includere device non previsti o escludere quelli giusti. Un errore classico è confondere un gruppo utenti con un gruppo dispositivi: in Autopilot la granularità conta, e una assegnazione sbagliata si traduce in un onboarding incoerente.

Passo 5: configurare Enrollment Status Page e blocchi del provisioning

La Enrollment Status Page, o ESP, è utile se vuoi impedire che l’utente arrivi al desktop prima che il device sia davvero pronto. In ambienti amministrati seriamente è spesso la scelta più prudente, perché evita che l’utente lavori con profili incompleti o app mancanti. Ma va usata con criterio: se la blocchi troppo, puoi trasformare un provisioning lento in un provisioning che sembra rotto.

La logica giusta è applicare l’ESP solo alle fasi che ti servono davvero e non a tutto indiscriminatamente. Se una suite di app è pesante, considera l’impatto sul primo avvio e sulla rete. In una sede con banda limitata, una ESP troppo aggressiva può allungare sensibilmente il tempo di consegna del device all’utente.

Misura almeno il tempo di provisioning e il tasso di fallimento. Se il tuo obiettivo è ridurre i ticket di onboarding, la metrica utile non è “Autopilot attivo”, ma il tempo fino a desktop pronto e il numero di setup falliti al primo tentativo.

Passo 6: applicare policy e app in modo ordinato

Autopilot non è solo enrollment. La parte che fa la differenza è il post-provisioning: policy di sicurezza, configurazioni device, applicazioni aziendali, criteri di compliance e, se serve, restrizioni su BitLocker, Defender, firewall e accesso condizionale. Qui la disciplina conta più della quantità.

Inizia con il minimo indispensabile. App core, policy base di sicurezza, criteri di aggiornamento e configurazioni che il device deve avere per essere usabile. Poi aggiungi il resto. Se installi tutto subito, non capirai mai quale policy ha rotto il flusso o quale app ha rallentato l’onboarding.

Un approccio pulito è separare policy di baseline, policy per reparto e policy per eccezioni. Per esempio, un gruppo IT può ricevere strumenti amministrativi, mentre i device standard no. Questo riduce il rischio di sovraccaricare i profili generici con eccezioni inutili.

Passo 7: gestire join, sicurezza e accesso condizionale

La parte security va progettata insieme ad Autopilot, non dopo. Se il device entra in Entra ID ma non ha una compliance chiara, l’accesso condizionale può bloccare gli utenti a monte. Se il device ha policy troppo permissive, invece, stai solo spostando il problema più avanti.

Per una configurazione robusta, definisci almeno: requisiti di compliance, cifratura disco, stato Defender, blocco su device non conforme e condizioni per l’accesso alle app SaaS. Il flusso corretto è semplice: device enrolato, policy applicate, compliance valutata, accesso concesso. Se inverti l’ordine, avrai ticket su ticket.

Attenzione ai secret e alle credenziali amministrative. Non inserirli in chiaro in script o note operative. Se ti serve automazione, usa identità gestite, certificati o segreti custoditi in un vault, e ruota gli artefatti sensibili quando un tecnico lascia il progetto o quando cambia il perimetro operativo.

Verifica operativa: come capire se il flusso funziona davvero

La verifica non è “il profilo esiste”. Devi fare un test end-to-end con un device reale o di laboratorio. Il ciclo minimo è: reset del device, connessione alla rete, riconoscimento Autopilot, applicazione del profilo, completamento dell’OOBE, accesso dell’utente e installazione delle app previste.

Quando qualcosa non torna, guarda prima gli artefatti verificabili: stato del device nel portale, log lato client, tempi di provisioning e eventuali errori di policy. Sul client, i log di diagnostica di Autopilot e di Intune sono il primo posto da ispezionare. Se il device si ferma durante la fase iniziale, spesso il problema è l’associazione al tenant o una policy che non si applica correttamente.

Un controllo utile è anche quello dei servizi di rete. Se il device non raggiunge i servizi Microsoft, l’intero flusso fallisce prima ancora di iniziare. In ambienti con proxy, captive portal o filtri DNS aggressivi, la causa non è Autopilot ma la connettività iniziale. Prima di cambiare profili, verifica che la macchina riesca a uscire verso Internet senza blocchi.

Errori frequenti e come leggerli senza perdere tempo

Il primo errore tipico è il device non riconosciuto. Di solito dipende da hardware hash mancante, importazione non completata o record duplicato. Il secondo è il profilo assegnato ma non applicato: qui entrano in gioco il gruppo sbagliato, la sincronizzazione o una condizione non soddisfatta. Il terzo è il provisioning che si blocca a metà per app o script problematici.

Se il PC arriva al desktop ma non è pronto per l’utente, il problema spesso non è Autopilot in sé ma il pacchetto di app e policy che hai appeso al flusso. Riduci il carico iniziale e sposta il resto in una seconda fase. È molto meglio un desktop disponibile in tempi ragionevoli con qualche app che arriva dopo, che un provisioning perfetto sulla carta ma ingestibile nella pratica.

Quando invece il problema è più “silenzioso”, come una configurazione parziale o una policy che non arriva, conviene confrontare un device riuscito con uno fallito. Stessa rete, stesso profilo, stesso gruppo, stessa versione di Windows: se cambia un solo elemento, hai già una pista concreta.

Snippet operativo utile per il supporto

In un contesto di troubleshooting, avere un set minimo di comandi aiuta a non andare a tentoni. Sul device puoi controllare versione OS, join e stato di rete, così da capire se il problema è locale o lato servizio.

systeminfo
ipconfig /all
whoami /upn
Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber

Se il device è già in mano all’utente ma non si comporta come previsto, raccogli anche i log di Intune e Autopilot dal portale o dal client. Il valore vero non è il singolo messaggio d’errore, ma la sequenza temporale: quando il device si registra, quando riceve il profilo, quando valuta la compliance e quando installa le app.

Strategia consigliata per andare in produzione senza farsi male

La strada più pulita è questa: pilota piccolo, hardware noto, profilo essenziale, app minime, policy di sicurezza base, verifica end-to-end, poi ampliamento graduale. Non fare il salto diretto dal laboratorio all’intera azienda. Ogni passaggio aggiuntivo deve avere un motivo e una verifica associata.

Se devi scegliere dove investire tempo, fallo su tre cose: qualità del gruppo di assegnazione, ordine delle policy e monitoraggio del provisioning. Sono i tre punti che distinguono un Autopilot usabile da uno che sembra corretto solo finché non arriva il primo lotto di device reali.

In sintesi operativa: raccogli l’hardware hash, importa il dispositivo, assegna un profilo coerente, limita l’ESP a ciò che serve davvero, distribuisci app e policy in modo progressivo, e verifica sempre il primo avvio con un device reale. Se qualcosa si rompe, torna indietro sul profilo o sul gruppo prima di toccare tutto il resto. È il modo più rapido per avere una configurazione stabile e difendibile nel tempo.