Guida passo passo alla configurazione di Windows Autopilot 2024

Windows Autopilot non è un wizard da cliccare una volta e basta: è una catena di prerequisiti, identità, licenze, profili e sincronizzazioni che deve restare coerente tra tenant Microsoft Entra, Intune, OEM e dispositivo. Se uno di questi punti salta, il risultato tipico è un device che si avvia, ma non entra nel flusso previsto, oppure entra con impostazioni parziali e correzioni manuali in seguito.

La configurazione corretta parte da una scelta architetturale semplice: vuoi usare Autopilot per pre-provisioning, per user-driven o per entrambi. La differenza non è cosmetica. Cambiano tempi, schermate, permessi richiesti e il tipo di controllo che puoi fare prima che l’utente riceva il PC. In ambienti aziendali seri conviene decidere subito il target, altrimenti si finisce con un profilo generico che soddisfa nessuno.

Prerequisiti reali: tenant, licenze e ruoli

Prima di caricare un solo hardware hash, verifica che il tenant abbia i servizi giusti attivi e che gli operatori abbiano i ruoli necessari. Per Autopilot servono Microsoft Entra ID e Intune, con licenze adeguate per gli utenti o per i dispositivi, a seconda del modello adottato. Se la parte licensing è ambigua, non aspettarti che il problema emerga in modo elegante: lo vedrai più avanti come enrollment fallito o policy non applicata.

Ruoli minimi da controllare: chi gestisce Autopilot deve poter leggere e creare dispositivi in Intune, assegnare profili e consultare lo stato di enrollment. In pratica, usa un account amministrativo dedicato per la fase di setup e non il profilo personale di chi fa le prove.

Se vuoi verificare velocemente lo stato lato portale, il punto operativo è il centro di amministrazione Intune: Devices → Windows → Windows enrollment → Windows Autopilot devices. Da lì capisci subito se il tenant sta già ricevendo dispositivi o se sei ancora a zero.

Raccolta dell’hardware hash: il punto che rompe più spesso i progetti

Autopilot identifica il dispositivo tramite hardware hash. Se non carichi quel dato correttamente, il device non può essere associato al profilo giusto. Il problema classico è l’inventario fatto male: file esportati da script vecchi, seriali mancanti, oppure dispositivi che cambiano stato tra test e produzione.

Il metodo più pulito è usare il modulo PowerShell ufficiale sul device o su una macchina di raccolta. Lo script più usato è Get-WindowsAutopilotInfo.ps1. Esempio tipico:

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

Il file CSV deve contenere almeno i campi necessari per l’import Autopilot. Se il file è vuoto o incompleto, il problema non è Intune: è il metodo di acquisizione. Verifica subito che il CSV abbia righe con seriale e hash, altrimenti non perdere tempo a cambiare profili.

Se lavori con device OEM, puoi anche importare in blocco dal portale o ricevere i dispositivi già registrati dal partner. In quel caso controlla che il tenant, il profilo e l’ownership siano coerenti. Un dispositivo importato nel tenant sbagliato è semplicemente un oggetto corretto nel posto errato.

Creazione del profilo Autopilot in Intune

Il profilo è dove decidi il comportamento del primo avvio. Qui definisci se il device entra in modalità user-driven, se salta alcune schermate, se usa Azure AD join o Hybrid join, e quali restrizioni applicare durante l’OOBE. La scelta più pulita oggi, salvo vincoli legacy, è Azure AD join con gestione Intune nativa. Hybrid join ha senso solo se hai dipendenze AD locali reali e non eliminabili.

Nel portale vai su Devices → Windows → Windows enrollment → Deployment profiles → Create profile. Imposta un nome leggibile, ad esempio AP-Win11-UserDriven-Standard. Evita nomi generici: quando avrai dieci profili, “Default” non ti aiuterà.

Le opzioni importanti sono queste:

• Join type: Azure AD joined o Hybrid Azure AD joined.
• Deployment mode: user-driven o self-deploying, se supportato dallo scenario.
• Out-of-box experience: nascondere EULA, privacy, account options e cambiare lingua se serve.
• Device naming template: utile per mantenere naming coerente.

Un template di naming sensato evita conflitti in fase di inventario. Esempio: PC-%SERIAL% o W11-%RAND:6%. Non usare pattern troppo lunghi o troppo creativi: alcuni sistemi di inventario e alcuni operatori li leggono male.

Assegnazione del profilo e filtri di targeting

Il profilo non serve a nulla se non viene assegnato. Qui conviene distinguere tra assegnazione diretta e gruppi dinamici. Per ambienti piccoli, l’assegnazione manuale a un gruppo statico è più prevedibile. Per ambienti più grandi, i gruppi dinamici sono più scalabili ma aggiungono latenza e più punti di errore.

In pratica, l’ordine corretto è: importi il device, verifichi che compaia in Autopilot devices, poi lo assegni a un profilo. Se vuoi filtrare per modello o per sede, usa i device filters di Intune. Sono utili quando devi differenziare notebook standard, device kiosk o hardware per reparti specifici.

Per controllare se il targeting funziona, non fidarti solo del portale. Verifica lo stato di sincronizzazione e l’assegnazione effettiva del profilo. Il device deve risultare assigned e, idealmente, avere un timestamp recente di sincronizzazione. Se è fermo da giorni, l’errore è a monte.

Policy Intune: senza queste il device è “gestito” solo a metà

Autopilot prepara il bootstrap; Intune governa il resto. Devi quindi assegnare almeno le policy base: compliance, configuration profiles, update rings, Defender, BitLocker e, se serve, app obbligatorie. Se ometti questo blocco, il device entra in tenant ma resta incompleto dal punto di vista operativo.

Un set minimo ragionevole per una postazione standard è:

1. Compliance policy per richiedere PIN, cifratura e versione OS minima.
2. Configuration profile per Wi-Fi, VPN, restrizioni locali e impostazioni di sicurezza.
3. BitLocker policy con recovery key salvata in Entra ID.
4. Update ring per controllare gli aggiornamenti senza bloccare il primo avvio.
5. App obbligatorie per Office, browser, agent EDR e tool aziendali.

La regola pratica è non esagerare nella prima ondata. Se imponi troppe app e troppe compliance condition, rischi di trasformare l’enrollment in un collo di bottiglia. Meglio partire con il minimo indispensabile e aggiungere controllo in seguito.

Verifica del flusso OOBE sul dispositivo

Il test corretto si fa su un device realmente reset-tato, non su una macchina già mezza configurata. Se il dispositivo è già stato usato, esegui un wipe o un reset coerente con la tua politica. La sequenza deve mostrarti l’esperienza iniziale di Windows, il riconoscimento del tenant e l’accesso con l’account previsto.

Durante il test osserva questi punti:

• Il device raggiunge la schermata di Autopilot e riconosce il tenant.
• Il profilo assegnato viene applicato senza errori.
• Il device completa l’enrollment in Intune.
• Le policy base arrivano entro il primo ciclo di sincronizzazione.

Se vuoi una verifica rapida lato client, usa il log di provisioning e la sincronizzazione Intune. In molti casi il primo indizio utile è nel registro eventi o nei report di enrollment. Non serve scavare subito nei dettagli più bassi: prima capisci se il problema è di identità, rete o policy.

Comandi utili su Windows per forzare sincronizzazione e raccogliere informazioni base:

dsregcmd /status
Get-IntuneManagementExtensionLog
Start-Process ms-settings:workplace

Il comando dsregcmd /status ti dice se il device è joined correttamente e se la registrazione è coerente. Se i campi di join non tornano, il problema è prima delle policy.

Errori tipici e come leggerli senza perdere tempo

Il primo errore tipico è il device non presente in Autopilot: in quel caso controlla import e sincronizzazione. Il secondo è il profilo non assegnato: verifica gruppo, filtro e stato del device. Il terzo è l’enrollment che parte ma si ferma su app o policy: qui devi guardare i log Intune, non il solo wizard.

Quando il flusso si interrompe subito dopo il login, spesso la causa è una delle seguenti:

1. Problemi di rete verso i servizi Microsoft.
2. Token o identità non coerenti.
3. Policy troppo aggressive o app che bloccano il completion state.

Per isolare il layer, fai una prova minimale: rete, autenticazione, assegnazione profilo, poi app. Se il device arriva al login ma non completa, la causa più probabile non è il DNS: è quasi sempre enrollment/policy o una dipendenza di rete verso endpoint Microsoft.

Scenario Hybrid Join: usarlo solo se devi davvero

Hybrid Azure AD joined resta utile in alcune realtà, ma aggiunge complessità: connettività verso domain controller, line-of-sight, GPO legacy e tempi più lunghi di provisioning. Se non hai un motivo concreto per mantenerlo, evita di iniziare da qui. La maggior parte dei nuovi deployment funziona meglio con Azure AD join puro e policy Intune ben costruite.

Se invece devi usare Hybrid, verifica in anticipo:

• Connettività del device alla rete aziendale o VPN durante il provisioning.
• Stato dei connector e dei servizi necessari.
• Coerenza tra OU, GPO e profilo Autopilot.

Qui il rischio operativo è il ritardo: l’utente vede un provisioning più lento e più fragile. Il rollback, se il pilot fallisce, è tornare a un profilo Azure AD joined per il gruppo di test e tenere il legacy solo dove serve davvero.

Hardening minimo prima del go-live

Prima di estendere il rollout, controlla almeno la parte di sicurezza base: BitLocker attivo, account locali ridotti al minimo, EDR presente, aggiornamenti gestiti e nessun segreto inserito in chiaro nei profili o negli script. Se usi script di post-provisioning, distribuiscili con attenzione e redigi qualunque dato sensibile nei log.

Un controllo rapido che vale più di molte discussioni è verificare che la recovery key di BitLocker sia salvata nel tenant e che il device compaia come conforme dopo la prima sync. Se questo non succede, il device è formalmente enrollato ma non ancora affidabile dal punto di vista operativo.

Rollout controllato e rollback

Il rollout serio parte sempre da un pilot piccolo: pochi modelli, pochi utenti, una sola variante di profilo. Se qualcosa non torna, non correggere tutto insieme. Cambia una variabile alla volta: profilo, gruppo, app obbligatoria o policy specifica.

Il rollback tipico è semplice: rimuovi l’assegnazione del profilo dal gruppo di test, sospendi le policy problematiche, oppure disabilita temporaneamente l’app che blocca il completion state. Se hai già importato dispositivi errati, rimuovili dal profilo e, se necessario, pulisci l’oggetto dal tenant prima di un nuovo tentativo. Fai sempre attenzione al blast radius: un cambio nel profilo assegnato può impattare tutti i device del gruppo, non solo quello di prova.

Assunzione operativa: i passaggi descritti sono pensati per un tenant Microsoft 365 con Intune attivo, dispositivi Windows 10/11 recenti e un rollout controllato in ambiente aziendale.