Autopilot Device Preparation diventa lo standard, Hybrid Join rimane indietro

A settembre Microsoft ha dichiarato Autopilot Device Preparation il metodo raccomandato per i deployment Windows user-driven. Il nuovo modello è più semplice e affidabile, ma supporta solo Entra Join. Chi oggi effettua ancora il provisioning di nuovi dispositivi con Hybrid Join dovrebbe prestare attenzione proprio a questo punto, perché questa limitazione pesa più della scelta dello strumento di provisioning.

In sintesi

• Nuova raccomandazione: Da settembre Microsoft raccomanda Autopilot Device Preparation per gli enrollment user-driven, perché i deployment risultano più rapidi e affidabili.
• Solo Entra Join: Device Preparation supporta esclusivamente Entra Join; Hybrid Join non è previsto nel nuovo modello.
• Nessun aggiornamento in-place: Microsoft non offre un percorso supportato per passare da un dispositivo con Hybrid Join a Entra Join senza un reset. Chi oggi fa il rollout di nuovi dispositivi con Hybrid Join dovrà in seguito riprovisionarli o rimanere dipendente dalla tecnologia on-premises per un altro intero ciclo hardware.
• Nessuna data di dismissione: Il classico Autopilot e Device Preparation coesisteranno nel prossimo futuro.
• La nostra raccomandazione: La scelta cruciale è il tipo di join, non lo strumento. Per i nuovi dispositivi continuiamo a utilizzare il classico Autopilot con Entra Join, perché produttori e rivenditori possono così registrare i dispositivi nel tenant già prima della consegna. Questo percorso zero-touch non è ancora disponibile con Device Preparation.

Fonte: Microsoft Learn, Compare Windows Autopilot device preparation and Windows Autopilot

Cosa ha annunciato Microsoft

A metà settembre Microsoft ha descritto nel blog Intune Customer Success come dovrebbe avvenire il passaggio dal classico Windows Autopilot a Device Preparation. Il messaggio è chiaro: per i deployment user-driven, Device Preparation è ora il percorso raccomandato.

La tecnologia in sé non è nuova: Device Preparation esiste dal 2024 come variante riprogettata di Autopilot, più semplice e affidabile, che mostra i deployment quasi in tempo reale. Fino a poco tempo fa presentava però una lacuna: prima del primo accesso, il dispositivo non sapeva a quale tenant apparteneva. Da fine agosto questa lacuna è colmata dalla Device Association, che consente di associare un dispositivo Windows al proprio tenant già prima del deployment. Il dispositivo viene così riconosciuto automaticamente come dispositivo aziendale, riceve un nome predefinito e un'Out-of-Box-Experience personalizzata, ancora prima che l'utente completi la configurazione.

Non è necessario migrare immediatamente. Il classico Autopilot e Device Preparation coesistono nello stesso tenant, ma ogni dispositivo utilizza uno solo dei due modelli. Se un dispositivo è registrato sia per Autopilot sia tramite Device Association, la Association ha la precedenza.

Una policy invece di quattro componenti

Il classico Autopilot si compone di profili di deployment, Enrollment Status Page, Group Tag e gruppi dinamici. Device Preparation si basa invece su un'unica provisioning policy che definisce tutto ciò che avviene durante l'Out-of-Box-Experience (OOBE): dalle impostazioni del dispositivo alle app e agli script, fino al nome del dispositivo. In pratica questo significa:

• Assegnazioni più rapide: All'enrollment i dispositivi vengono inseriti immediatamente in un gruppo statico di Entra tramite Enrollment Time Grouping. Le app e gli script assegnati a quel gruppo sono disponibili durante il provisioning senza dover attendere la valutazione dei gruppi dinamici.
• Separazione netta delle fasi: Durante il provisioning vengono applicate solo le impostazioni relative al dispositivo e le app strettamente necessarie. Tutto ciò che riguarda l'utente arriva non appena il desktop è disponibile, rendendo la configurazione iniziale più breve e meno soggetta a errori.
• Reporting migliorato: Ogni deployment è visibile quasi in tempo reale, con molti più dettagli rispetto al classico Autopilot, e la ricerca dei problemi diventa notevolmente più semplice.

Device Preparation supporta solo Entra Join

Device Preparation supporta solo Entra Join. Hybrid Join non è previsto nella nuova architettura, e nulla negli annunci di Microsoft lascia intendere che questo cambierà. Il classico Autopilot supporta ancora Hybrid Join, ma lo sviluppo di Microsoft punta chiaramente verso deployment senza Domain Controller. Su Microsoft Learn è ora riportato esplicitamente:

„Microsoft recommends deploying new devices as cloud-native using Microsoft Entra join. Deploying new devices as Microsoft Entra hybrid join devices isn't recommended …"

Chi ha usato Hybrid Join con Autopilot conosce bene gli ostacoli: durante il provisioning il dispositivo deve raggiungere un Domain Controller, il connettore Intune per Active Directory deve essere disponibile e funzionante, e le Group Policy girano in parallelo a Intune. Sono esattamente queste dipendenze la causa principale dei deployment che falliscono o si bloccano. Per noi Hybrid Join è sempre stato una soluzione transitoria, mai un obiettivo.

Un dispositivo con Entra Join ha bisogno solo di una connessione Internet durante la configurazione. Configurazione, app, aggiornamenti e policy di conformità arrivano interamente tramite Intune, mentre il Conditional Access gestisce l'accesso alle risorse aziendali. Questo modello si adatta a un mondo del lavoro che si svolge sempre più al di fuori della rete aziendale: in home office, in mobilità o ovunque ci si trovi.

Da anni chiamiamo questo principio "Starbucks Deployment", e già nel 2019 siamo stati premiati per questo con il Microsoft Global Modern Desktop Partner of the Year Award.

Da Hybrid Join a Entra Join serve un reset

Per la pianificazione c'è un punto fondamentale: un dispositivo con Hybrid Join può essere convertito a Entra Join, seguendo un percorso supportato, solo tramite reset. Ogni dispositivo che oggi viene fatto il rollout con Hybrid Join dovrà quindi essere riprovisionato per il passaggio a Entra Join.

A prima vista sembra un onere significativo, ma nella pratica è possibile pianificarlo in modo ordinato. Il percorso più comune è quello del normale ciclo hardware: i nuovi dispositivi vengono configurati direttamente con Entra Join, mentre quelli con Hybrid Join vengono gradualmente dismessi. Chi vuole accelerare il passaggio al cloud può anche rifare da zero i dispositivi esistenti in più fasi con Entra Join.

Perché consigliamo comunque il classico Autopilot

Nonostante ciò, non raccomandiamo ancora il passaggio a Device Preparation. Per i nuovi dispositivi continuiamo a consigliare il classico Autopilot, ma con Entra Join in modo coerente.

Il motivo principale è l'integrazione con produttori e rivenditori. Con il classico Autopilot, l'OEM o il rivenditore registra il dispositivo direttamente nel tenant prima ancora della spedizione. Il dispositivo arriva direttamente ai collaboratori, mostra il branding aziendale al primo avvio e si configura da solo, senza alcun intervento dell'IT.

Per la Device Association occorre invece leggere le informazioni del dispositivo localmente e caricarle manualmente in Intune. Questo funziona bene per lo staging in magazzino, i rollout con tecnici o i deployment interni, ma non per la spedizione diretta agli utenti. Microsoft ha annunciato che OEM e partner potranno in futuro associare i dispositivi in anticipo, ma senza comunicare una data.

A ciò si aggiungono scenari che Device Preparation non copre ancora completamente:

• Pre-Provisioning: Un partner installa app e applica policy già prima della consegna, in modo che i collaboratori ricevano un dispositivo quasi completamente configurato.
• Self-Deploying Mode: Dispositivi kiosk e shared che vengono distribuiti senza accesso utente.
• Opzioni di provisioning avanzate: Un numero maggiore di app durante la configurazione e la possibilità di bloccare il desktop fino al completamento della configurazione utente necessaria.
• Scenari di dispositivi speciali: Teams Rooms e gestione del firmware tramite DFCI.

Non appena produttori e rivenditori potranno associare i dispositivi in anticipo per Device Preparation, rivedremo la nostra raccomandazione. La strategia di fondo non cambia: chi pianifica oggi un nuovo deployment, lo pianifica con Entra Join. Un successivo passaggio dal classico Autopilot a Device Preparation riguarderà solo il percorso di provisioning per i nuovi dispositivi, non il modello di gestione, la piattaforma di identità o l'architettura dei dispositivi.

"Senza Domain Join i nostri dispositivi non funzionano"

Questa frase la sentiamo continuamente. La tecnologia alla base di Entra Join è matura e consolidata, e quando sorgono problemi raramente dipendono da Entra Join in sé, ma piuttosto da dipendenze, processi e assunzioni accumulate negli anni attorno ad Active Directory.

• Group Policy: Molte organizzazioni hanno molte più GPO del necessario, e dalla nostra esperienza una parte significativa non ha più alcun effetto. Con il nostro blueprint, i client Entra partono in pochi minuti su una baseline collaudata e flessibile, che gestiamo interamente come Infrastructure as Code in Managed Intune e manteniamo costantemente aggiornata.
• Accesso alle risorse on-premises: File server, stampanti e applicazioni web interne rimangono accessibili anche per i dispositivi con Entra Join. Finché il dispositivo raggiunge un Domain Controller, ottiene ticket Kerberos e accede alle risorse on-premises tramite Single Sign-On, con Windows Hello for Business tramite Cloud Kerberos Trust. Vale comunque la pena testare questi scenari con utenti reali e applicazioni specifiche.
• Certificati e accesso alla rete: L'autenticazione di rete e VPN dipende spesso da certificati macchina emessi da una CA on-premises, verificati tramite un Network Policy Server (NPS). Per i dispositivi con Entra Join, Intune distribuisce i certificati, ad esempio tramite Microsoft Cloud PKI o SCEPman, mentre l'autenticazione di rete viene gestita da una soluzione RADIUS cloud-native come RADIUSaaS.
• Deployment di app affidabili: Quando i deployment Autopilot falliscono, la causa è quasi sempre legata a pacchetti software mal costruiti o non manutenuti, non al tipo di join. Per questo utilizziamo RealmJoin, il nostro strumento complementare a Intune con oltre 2.500 applicazioni già pacchettizzate. Indipendentemente dallo strumento, vale la regola: durante la configurazione iniziale vanno installate solo le app di cui l'utente ha bisogno il primo giorno. Tutto il resto arriva in seguito, una volta che il dispositivo è operativo, oppure è disponibile per l'autoinstallazione tramite Intune Company Portal o il catalogo app di RealmJoin.

Conclusione

Device Preparation non copre ancora tutto ciò che può fare il classico Autopilot. La direzione è tuttavia chiara: Microsoft investe in Entra Join, e Hybrid Join diventa sempre più un modello legacy.

Continuare a gestire i dispositivi con Hybrid Join esistenti fino alla fine del loro ciclo di vita può avere senso, anche se ciò significa gestire in parallelo un modello di gestione moderno e uno classico. Fare però il rollout di nuovi dispositivi con Hybrid Join oggi significa legarsi per un altro ciclo hardware intero alle dipendenze on-premises, mentre Microsoft continua a sviluppare provisioning e gestione per Entra Join.

Se stai pianificando il passaggio da Hybrid Join a Entra Join, hai difficoltà con i tuoi deployment Autopilot o vuoi gestire i tuoi dispositivi Windows interamente tramite Intune, siamo a tua disposizione.

Fonti

• Moving from Windows Autopilot to Windows Autopilot device preparation (Microsoft Tech Community, settembre 2026)
• Introducing device association for Windows Autopilot device preparation (Microsoft Tech Community, agosto 2026)
• Compare Windows Autopilot device preparation and Windows Autopilot (Microsoft Learn)
• Windows Autopilot device association FAQ (Microsoft Learn)
• Microsoft Entra joined vs. hybrid joined (Microsoft Learn)