Windows Autopilot Device Association

Introduzione

Finalmente Windows Autopilot Device Association è disponibile in General Availability dal 27 agosto 2026 ed è una funzionalità opzionale di Windows Autopilot device preparation per i dispositivi Windows 11 aziendali. Permette di creare un legame verificabile tra un dispositivo fisico e il tenant dell’azienda prima dell’enrollment nel servizio MDM, utilizzando un’identità protetta dal TPM e una tenant affinity memorizzata nel firmware UEFI.

Il cambiamento interviene in uno dei punti che maggiormente differenziavano Windows Autopilot device preparation dal Windows Autopilot tradizionale:

• senza Device Association, la scelta della device preparation policy dipende normalmente dall’utente che effettua l’accesso durante la Out-of-Box Experience (OOBE)
  
• con un dispositivo pre-associato è invece possibile collegare direttamente una device preparation policy a quello specifico computer, facendo in modo che la configurazione prevista segua il dispositivo anche quando lo stesso utente dispone di più pc
  
• quando esistono contemporaneamente un’assegnazione basata sul dispositivo e una basata sull’utente, prevale quella device-based
  

La Device Association abilita inoltre alcune personalizzazioni della OOBE riservate ai dispositivi associati, permette di definire il naming del computer durante il provisioning e fa sì che l’endpoint venga identificato automaticamente come corporate-owned. Quest’ultimo comportamento lo trovo parecchio utile quando le enrollment restrictions di Intune impediscono l’enrollment dei dispositivi Windows personali.

La distinzione conta anche quando si pianifica una migrazione dal Windows Autopilot tradizionale. Windows Autopilot device preparation può essere valutato per gli scenari user-driven idonei, mentre scenari come Pre-provisioning, Self-deploying mode, Microsoft Entra hybrid join e Autopilot into co-management continuano a richiedere Windows Autopilot. Le due tecnologie possono quindi convivere nello stesso tenant durante una transizione graduale.

Che cos’è Windows Autopilot Device Association

Partiamo dalle basi: Device Association crea una relazione preventiva tra un dispositivo fisico Windows 11 e l’azienda utilizzando l’identità TPM-backed del computer. Durante la fase di pre-associazione viene registrata nel servizio l’intenzione di associare quella specifica identità hardware al tenant; quando il dispositivo raggiunge la Out-of-Box Experience (OOBE) ed è connesso alla rete, la sua identità viene verificata tramite TPM attestation e, se la verifica ha esito positivo, nel firmware UEFI viene scritto un marker contenente la tenant affinity.

Questo marker permette di mantenere una relazione verificabile tra il dispositivo e l’organizzazione anche indipendentemente dall’installazione corrente di Windows. L’associazione non dipende quindi soltanto da un record amministrativo presente nel portale, ma viene completata attraverso la verifica dell’identità hardware del computer.

Che cosa cambia rispetto all’hardware hash di Windows Autopilot?

A prima vista il processo può ricordare molto da vicino la registrazione utilizzata da anni con il Windows Autopilot tradizionale: si raccolgono informazioni dal dispositivo, si genera un file CSV e lo si importa nel portale. I due meccanismi hanno però finalità e architetture differenti.

Nel Windows Autopilot tradizionale viene raccolto l’hardware hash del computer e utilizzato per registrare preventivamente il dispositivo nel servizio Windows Autopilot. Una volta presente nel servizio, il dispositivo può essere riconosciuto durante la OOBE e ricevere il deployment profile previsto. Group Tag, gruppi Microsoft Entra e assegnazioni dei profili possono inoltre essere utilizzati per differenziare il comportamento di provisioning tra dispositivi diversi.

Con Windows Autopilot Device Association non viene invece importato il tradizionale hardware hash e il computer non viene registrato come dispositivo del Windows Autopilot tradizionale. Il file utilizzato per la pre-associazione è un DeviceLink CSV, che contiene le informazioni necessarie per collegare preventivamente al tenant l’identità TPM-backed dello specifico dispositivo.

L’importazione del DeviceLink CSV, inoltre, non completa da sola l’associazione; in questa fase viene registrata l’intenzione dell’organizzazione di associare quel computer al tenant. Quando il dispositivo si presenta successivamente durante la OOBE, la sua identità deve essere verificata tramite hardware-backed attestation; soltanto dopo una verifica riuscita viene scritto nel firmware UEFI il marker di tenant affinity e il dispositivo passa allo stato Associated.

Ma quindi… cosa cambia?

Windows Autopilot device preparation gestisce il deployment, dal Microsoft Entra join all’enrollment in Intune, fino all’installazione delle applicazioni e all’esecuzione degli script previsti dalla policy. Device Association aggiunge a questo flusso il riconoscimento del dispositivo e del tenant prima dell’enrollment, rendendo disponibili le impostazioni OOBE riservate ai dispositivi associati.

Questa relazione consente di assegnare direttamente una device preparation policy a uno specifico computer, riconoscere automaticamente il dispositivo come corporate-owned e utilizzare le funzionalità OOBE e di device naming che dipendono dall’associazione. Diventa quindi possibile, per esempio, consegnare allo stesso utente due computer destinati a utilizzi differenti e fare in modo che ciascuno segua una propria device preparation policy, senza determinare il deployment esclusivamente attraverso l’appartenenza dell’utente ai gruppi.

Device Association introduce alcune capacità di gestione per dispositivo già presenti nel Windows Autopilot tradizionale, ma le integra nell’architettura di Windows Autopilot device preparation attraverso una TPM-backed identity, la relativa attestation e una tenant affinity persistente nel firmware UEFI, anziché attraverso la tradizionale registrazione Autopilot basata sull’hardware hash.

Nel deployment con Device Association, la pre-associazione e l’associazione precedono l’enrollment eseguito tramite Windows Autopilot device preparation. Il lifecycle comprende poi la rimozione della tenant affinity quando il computer lascia definitivamente l’azienda.

Fase	Cosa avviene	Risultato
Pre-association	Viene registrata nel servizio l’intenzione di associare l’identità TPM-backed del dispositivo al tenant	Il computer compare come Pre-associated
Association	L’identità del dispositivo viene verificata tramite attestation e il marker di tenant affinity viene scritto nel firmware UEFI	Il computer passa allo stato Associated
Enrollment	Viene eseguito Windows Autopilot device preparation utilizzando la policy applicabile al dispositivo o all’utente	Il computer completa l’enrollment e passa alla gestione prevista dall’organizzazione
Removal	La tenant affinity viene rimossa dal dispositivo quando questo lascia definitivamente l’azienda	Il legame Device Association con il tenant viene eliminato

La persistenza della tenant affinity nel firmware spiega perché un reset del dispositivo, una reinstallazione di Windows oppure la rimozione dell’enrollment MDM non cancellino Device Association. Queste operazioni intervengono sul sistema operativo o sulla gestione del dispositivo, mentre il marker dell’associazione rimane memorizzato in UEFI. Questa caratteristica facilita il riutilizzo dello stesso computer all’interno dell’azienda, perché l’associazione può continuare a essere riconosciuta anche dopo un nuovo provisioning. Quando invece il dispositivo viene venduto, restituito, riciclato o trasferito definitivamente a un’altra organizzazione, la tenant affinity deve essere rimossa esplicitamente come parte della procedura di decommissioning.

Device-based targeting delle device preparation policy

Uno degli effetti più interessanti di Device Association riguarda la scelta della Windows Autopilot device preparation policy. Nel normale scenario user-driven, la policy viene individuata sulla base dell’utente che effettua l’accesso e, se allo stesso utente sono applicabili più policy, viene utilizzata quella con priorità più alta.

Durante la pre-associazione è invece possibile collegare direttamente una device preparation policy al computer. Se quel dispositivo dispone anche di una policy derivata dall’utente, prevale l’assegnazione device-based. Se durante la pre-associazione non viene scelta alcuna policy, il processo utilizza quella applicabile all’utente che effettua l’enrollment; se anche l’utente non dispone di una policy valida, non viene applicata alcuna device preparation policy.

Questo modello consente, per esempio, di assegnare allo stesso utente un notebook standard e una workstation tecnica facendo ricevere ai due computer esperienze di provisioning differenti; la decisione può quindi essere legata alla funzione del dispositivo anziché esclusivamente all’identità della persona che lo utilizzerà.

Windows Autopilot device preparation utilizza infatti un Microsoft Entra security group di tipo Assigned specificato nella policy: durante il provisioning, il dispositivo viene aggiunto automaticamente a questo gruppo tramite Enrollment Time Grouping. Applicazioni e script che devono essere elaborati durante la OOBE devono essere assegnati allo stesso gruppo e inclusi nella device preparation policy.

Una OOBE più controllabile

Device Association abilita una serie di impostazioni della device preparation policy che vengono utilizzate esclusivamente dai dispositivi associati. Tra queste rientrano Language (Region), la configurazione automatica della tastiera, la possibilità di nascondere i Microsoft Software License Terms, le impostazioni di privacy e le opzioni di cambio account presenti nelle schermate aziendali di sign-in e di domain error. Quest’ultima impostazione richiede che in Microsoft Entra ID sia configurato il company branding.

Sulle edizioni Windows Professional, la pagina che permette di scegliere tra account personale e account aziendale o scolastico viene inoltre nascosta per impostazione predefinita sui dispositivi associati. È un dettaglio utile da conoscere durante i test della OOBE, soprattutto quando si confronta l’esperienza con quella di un dispositivo non associato.

Device naming durante il provisioning

Come mostrato in Figura 2, Device Association supporta anche Apply device name template, che permette di definire nella device preparation policy il nome da assegnare al computer prima dell’enrollment. Il template viene configurato preventivamente dall’amministratore e applicato da Windows durante il flusso di provisioning.

Il nome risultante può contenere lettere, numeri e trattini, può raggiungere 63 caratteri e non può essere costituito soltanto da cifre. Sono supportati %SERIAL%, che inserisce il serial number del computer, e %RAND:x%, che genera una sequenza numerica casuale con il numero di cifre indicato da x. Un’azienda potrebbe quindi utilizzare, per esempio, CL-%SERIAL% oppure WIN-%RAND:6%.

Device Association e Windows corporate identifiers

Windows corporate identifiers e Device Association possono entrambi consentire a Intune di distinguere un dispositivo aziendale da un computer personale, ma hanno finalità e capacità differenti.

I corporate identifiers utilizzano attributi del dispositivo per identificarlo come appartenente all’azienda e sono particolarmente utili quando le enrollment restrictions impediscono l’enrollment dei PC Windows personali. Device Association crea invece una relazione TPM-backed con il tenant e, oltre a determinare automaticamente la corporate ownership, abilita il targeting diretto della device preparation policy, il device naming e le personalizzazioni OOBE riservate ai dispositivi associati.

Se l’azienda non blocca l’enrollment dei dispositivi personali, Windows Autopilot device preparation può essere utilizzato anche senza corporate identifier e senza Device Association. L’associazione rimane però necessaria quando si vogliono utilizzare le capacità specifiche legate alla tenant affinity, al targeting per dispositivo, al naming e alle personalizzazioni OOBE appena descritte.

Device Association rispetto agli altri scenari Windows Autopilot

Il confronto riguarda Windows Autopilot device preparation con Device Association e le modalità del Windows Autopilot tradizionale. Device Association è una funzionalità di device preparation, non una modalità di deployment autonoma.

Windows Autopilot device preparation supporta il modello User-driven e la modalità Automatic utilizzata con Windows 365. Il Windows Autopilot tradizionale continua invece a supportare User-driven, Pre-provisioned, Self-deploying ed Existing devices. Device Association estende lo scenario user-driven per i dispositivi fisici e non si applica ai Windows 365 Cloud PC; non introduce modalità Self-deploying o Pre-provisioned.

Scenario	Preparazione preventiva	Interazione dell’utente	Join	Utilizzo principale
Device preparation user-driven + Device Association	Pre-associazione del dispositivo, con assegnazione diretta facoltativa della device preparation policy	L’utente effettua il sign-in durante OOBE	Microsoft Entra join	Dispositivi aziendali Windows 11 assegnati a utenti, con esigenza di tenant affinity e configurazione device-specific
Windows Autopilot User-driven	Registrazione del dispositivo nel servizio Windows Autopilot e assegnazione di un deployment profile	L’utente effettua il sign-in durante OOBE	Microsoft Entra join o Microsoft Entra hybrid join	Deployment user-driven tradizionali
Windows Autopilot Pre-provisioned	Registrazione Autopilot e technician phase prima della consegna	Il tecnico esegue la prima fase, l’utente completa il provisioning	Microsoft Entra join o Microsoft Entra hybrid join	Dispositivi che devono essere preparati in anticipo da IT, partner o OEM
Windows Autopilot Self-deploying	Registrazione Autopilot e TPM attestation	Minima interazione locale; non richiede un utente per il provisioning	Microsoft Entra join	Kiosk, dispositivi condivisi e scenari senza utente primario
Windows Autopilot for existing devices	Configuration Manager task sequence e configurazione Autopilot; la registrazione preventiva dipende dallo scenario	Il dispositivo viene reimaged e successivamente entra nel flusso Autopilot	Microsoft Entra join o Microsoft Entra hybrid join	Reinstallazione e trasformazione di dispositivi Windows già esistenti

Device Association e Windows Autopilot User-driven

Il confronto più diretto è tra lo scenario user-driven di Windows Autopilot device preparation con Device Association e Windows Autopilot User-driven: entrambi i flussi sono pensati per dispositivi assegnati a un utente che effettua l’autenticazione durante OOBE.

Nel Windows Autopilot tradizionale il computer viene registrato nel servizio e riceve un deployment profile; durante il provisioning possono essere elaborate configurazioni device-based attraverso device ESP e configurazioni user-based attraverso user ESP. Windows Autopilot device preparation utilizza invece una device preparation policy e durante OOBE elabora configurazioni device-based, monitorando le app e gli script selezionati. I profili di configurazione assegnati al device group vengono sincronizzati, ma la loro applicazione non viene monitorata dal provisioning e può terminare anche dopo il deployment.

Device preparation permette attualmente di includere nella policy fino a 25 applicazioni gestite e 10 script PowerShell essenziali. Le applicazioni supportate comprendono LOB, Win32, Microsoft Store compatibili con WinGet, Microsoft 365 ed Enterprise App Catalog. App e script eseguiti durante OOBE devono essere configurati nel System context, perché vengono elaborati prima del primo accesso dell’utente al desktop.

Il Windows Autopilot tradizionale conserva tuttavia capacità che device preparation non offre: Microsoft Entra hybrid join, Pre-provisioned, Self-deploying, Windows Autopilot Reset, DFCI, Autopilot into co-management e un modello ESP che può bloccare l’accesso al desktop in attesa anche delle configurazioni user-based.

Device Association e Windows Autopilot Pre-provisioned

Windows Autopilot Pre-provisioned suddivide il provisioning in una fase eseguita dal tecnico e una fase completata successivamente dall’utente. IT, OEM o partner possono così anticipare una parte consistente delle attività di configurazione e dell’installazione delle applicazioni prima che il computer venga consegnato. Il modello supporta sia Microsoft Entra join sia Microsoft Entra hybrid join.

Device Association non introduce una technician phase equivalente. Il tecnico può raccogliere le informazioni necessarie alla pre-associazione e completare l’association durante OOBE, ma il successivo deployment di un PC fisico rimane user-driven. Quando l’obiettivo principale è eseguire in anticipo una fase strutturata di provisioning prima della consegna all’utente, Pre-provisioned resta quindi uno scenario distinto.

Device Association e Windows Autopilot Self-deploying

Self-deploying mode è destinato soprattutto a kiosk, dispositivi condivisi e scenari nei quali non è richiesto un utente durante il provisioning. Utilizza TPM 2.0 e device attestation e supporta esclusivamente Microsoft Entra join; Microsoft Entra hybrid join non è disponibile.

Device Association utilizza anch’essa TPM attestation, ma con uno scopo differente: l’attestazione permette di verificare che l’identità hardware presentata dal computer corrisponda a quella pre-associata al tenant. Il deployment del dispositivo fisico rimane user-driven e prevede comunque l’autenticazione dell’utente.

Device Association e Windows Autopilot for existing devices

Windows Autopilot for existing devices utilizza una Configuration Manager task sequence per eseguire il reimaging di un computer esistente e portarlo verso un successivo deployment Autopilot user-driven. Il risultato può essere un dispositivo Microsoft Entra joined oppure Microsoft Entra hybrid joined.

La registrazione preventiva in Windows Autopilot non è sempre necessaria. Il flusso può utilizzare un file AutopilotConfigurationFile.json; se il computer è già registrato come dispositivo Autopilot e dispone di un profilo assegnato, quel profilo ha precedenza sul file JSON inserito dalla task sequence.

Device Association non esegue reimaging e non sostituisce Configuration Manager. Può però essere preparata anche su un dispositivo che ha già completato OOBE, recuperando il DeviceLink CSV dai diagnostici Autopilot e pre-associando il computer in vista di un futuro reset o refresh.

E Windows Autopilot Reset?

Windows Autopilot Reset non è una modalità di deployment iniziale, ma un’operazione di lifecycle destinata a riportare un dispositivo già gestito a uno stato business-ready. Rimuove file personali, applicazioni e impostazioni dell’utente, mantenendo la relazione del computer con Microsoft Entra ID e la connessione di gestione con Microsoft Intune. È supportato sui dispositivi Microsoft Entra joined e non supporta Microsoft Entra hybrid join.

Windows Autopilot device preparation non dispone attualmente di un equivalente di Windows Autopilot Reset. La tenant affinity di Device Association sopravvive però a un normale reset o alla reinstallazione di Windows, consentendo al computer di essere nuovamente riconosciuto quando rientra nella OOBE. I due meccanismi rispondono quindi a esigenze diverse e non devono essere considerati equivalenti.

Quando valutare la transizione dal Windows Autopilot tradizionale

Per i nuovi PC aziendali Windows 11, destinati a utenti individuali, Microsoft Entra joined e gestiti con Intune, Windows Autopilot device preparation rappresenta una soluzione da valutare per gli scenari user-driven idonei. La migrazione può essere pianificata progressivamente per le popolazioni compatibili, mantenendo sul Windows Autopilot tradizionale gli scenari che richiedono ancora Pre-provisioning, Self-deploying, Microsoft Entra hybrid join o Autopilot into co-management.

La transizione non richiede un cutover simultaneo dell’intero parco. Le due soluzioni possono coesistere nello stesso tenant e Device Association permette anche di pre-associare computer già registrati nel Windows Autopilot tradizionale senza interromperne immediatamente l’utilizzo. Il cambiamento diventa operativo quando il dispositivo entra nuovamente nella OOBE.

Se un computer è contemporaneamente registrato nel Windows Autopilot tradizionale e associato al tenant, Device Association ha precedenza e viene eseguito Windows Autopilot device preparation. Se il computer è registrato ma non associato, ha invece precedenza il deployment profile del Windows Autopilot tradizionale. Per utilizzare device preparation su un dispositivo registrato senza Device Association occorre prima rimuovere la registrazione Autopilot.

Requisiti di Windows Autopilot Device Association

I requisiti specifici di Device Association sono più restrittivi rispetto a quelli generali di Windows Autopilot device preparation. Alla data di verifica del 20 settembre 2026, è richiesto un dispositivo fisico Windows 11 con TPM 2.0 abilitato e in buono stato; il TPM non deve trovarsi in Reduced Functionality Mode e le macchine virtuali non sono supportate.

Sul sistema operativo sono supportati Windows 11 24H2 e Windows 11 25H2 con KB5120998 o successiva, nelle edizioni Windows 11 Pro, Pro Education, Pro for Workstations, Enterprise, Education ed Enterprise LTSC.

Requisito	Configurazione richiesta
Tipo di dispositivo	Computer Windows fisico
Sistema operativo	Windows 11 24H2 oppure Windows 11 25H2
Livello di aggiornamento	KB5120998 o successiva
Edizioni	Pro, Pro Education, Pro for Workstations, Enterprise, Education, Enterprise LTSC
TPM	TPM 2.0 abilitato, healthy e non in Reduced Functionality Mode
Join risultante dal deployment user-driven	Microsoft Entra join
Virtual machine	Non supportata

Per la rete devono essere rispettati tutti gli endpoint già richiesti da Windows Autopilot device preparation. Device Association aggiunge l’accesso HTTPS sulla porta TCP 443 a ztd.dds.microsoft.com e agli endpoint Azure Attestation elencati nei requisiti correnti. Negli ambienti che utilizzano proxy autenticati, firewall con allowlist o SSL inspection è quindi opportuno effettuare una verifica specifica della connettività dalla rete utilizzata durante OOBE.

Sul fronte licensing non è previsto un add-on dedicato esclusivamente a Device Association: vengono utilizzati gli stessi requisiti di Windows Autopilot device preparation. Tra le sottoscrizioni supportate rientrano Microsoft 365 Business Premium, Microsoft 365 F1/F3, Microsoft 365 Academic A1/A3/A5, Microsoft 365 Enterprise E3/E5, Enterprise Mobility + Security E3/E5, Intune for Education oppure la combinazione Microsoft Entra ID P1/P2 con Microsoft Intune o un MDM alternativo compatibile. Quando viene utilizzata una sottoscrizione Microsoft 365, le licenze necessarie devono comunque essere assegnate agli utenti che eseguono l’enrollment in Intune.

Il requisito KB5120998 e gli aggiornamenti successivi

KB5120998, rilasciata il 27 agosto 2026, è stata una cumulative update Preview per Windows 11 24H2 e 25H2 e ha introdotto sul client le modifiche necessarie per Device Association. Le build risultanti erano rispettivamente 26100.9278 per Windows 11 24H2 e 26200.9278 per Windows 11 25H2.

Il requisito deve però essere letto come KB5120998 o successiva, non come obbligo di distribuire quella specifica preview. La cumulative security update KB5124008 dell’8 settembre 2026, build 26100.9445 e 26200.9445, include i miglioramenti provenienti da KB5120998. Un dispositivo mantenuto aggiornato con una cumulative successiva soddisfa quindi il requisito senza che sia necessario distribuire appositamente la preview di agosto. Maggiori informazioni sono disponibili agli articoli su Endpoint Ninja Aggiornamento cumulativo Windows 11 di settembre 2026 (KB5124008) e Aggiornamento Out-of-band di settembre 2026 (KB5129195).

Ruoli e autorizzazioni

Quando vengono utilizzati ruoli Intune personalizzati, Device Association introduce permessi specifici. Per gestire i dispositivi associati servono le autorizzazioni Enrollment programs > Read device, Create device, Delete device e Device configurations > Assign. La creazione e gestione delle device preparation policy richiede inoltre i permessi previsti per Windows Autopilot device preparation, tra cui le operazioni su Device configurations, Enrollment time device membership assignment, la lettura delle Managed apps e Mobile apps e la lettura delle informazioni Organization.

Poiché l’elenco dei permessi RBAC è soggetto all’evoluzione del prodotto, in ambienti che utilizzano custom role è consigliabile confrontare la configurazione con la pagina dei requisiti corrente prima di delegare la gestione a un team operativo.

Preparare la device preparation policy

Prima del deployment è necessario predisporre una Windows Autopilot device preparation policy configurata per lo scenario user-driven con Microsoft Entra join. La policy definisce il comportamento del provisioning, il gruppo nel quale il dispositivo viene inserito tramite Enrollment Time Grouping, le applicazioni e gli script che devono essere elaborati durante OOBE e, quando viene utilizzata Device Association, anche le impostazioni aggiuntive relative alla personalizzazione della OOBE e al device naming.

Il flusso presuppone che sia già configurato l’automatic enrollment in Microsoft Intune per gli utenti interessati e che questi siano autorizzati a effettuare il join dei dispositivi a Microsoft Entra ID. Nel normale scenario user-driven viene inoltre utilizzato un gruppo utenti per l’assegnazione della device preparation policy. Quando la policy viene successivamente associata direttamente a un dispositivo tramite Device Association, l’assegnazione device-based ha precedenza sull’eventuale assegnazione derivata dall’utente che effettua il sign-in.

Creare l’Assigned device group

Windows Autopilot device preparation richiede un Microsoft Entra security group con Membership type impostato su Assigned. I gruppi dinamici, comunemente utilizzati con il Windows Autopilot tradizionale, non possono essere selezionati come device group nella device preparation policy. Durante il deployment è l’Enrollment Time Grouping ad aggiungere automaticamente il computer al gruppo specificato nella device preparation policy.

Dal Microsoft Intune admin center apriamo Groups > All groups > New group e creiamo quindi un gruppo di tipo Security, impostiamo Membership type su Assigned e utilizziamo un nome che permetta di identificarne chiaramente la funzione, ad esempio “Autopilot Device Preparation – Standard Devices”.

Lo stesso assigned device group può essere utilizzato con più device preparation policy. Per distinguere più facilmente applicazioni, script e configurazioni dei vari deployment, Microsoft consiglia però un gruppo separato per ogni policy. Per esempio, potete predisporre gruppi diversi per notebook standard e workstation tecniche.

Assegnare applicazioni e script al device group

Prima di creare la policy è opportuno predisporre le applicazioni e gli script che devono essere eseguiti durante la OOBE. Windows Autopilot device preparation può elaborare fino a 25 applicazioni gestite e 10 script PowerShell prima che l’utente raggiunga il desktop. Sono supportate applicazioni Line-of-business, Win32, Microsoft Store compatibili con WinGet, Microsoft 365 ed Enterprise App Catalog. È inoltre supportata la presenza contemporanea di applicazioni Win32 e LOB nello stesso deployment.

Non è necessario utilizzare tutti gli slot disponibili. Nella fase iniziale del provisioning conviene includere soltanto le applicazioni e gli script realmente necessari prima che l’utente possa iniziare a lavorare, lasciando le installazioni non essenziali alla normale gestione Intune successiva. Un numero elevato di dipendenze aumenta infatti il lavoro che deve essere completato prima del desktop e deve essere considerato insieme al timeout configurato nella policy.

Creare la Windows Autopilot device preparation policy

Adesso possiamo creare la policy dal Microsoft Intune admin center seguendo il percorso Devices > Windows > Enrollment > Device preparation policies.

Selezioniamo Create > User Driven. Nella pagina Basics assegniamo un nome descrittivo alla policy e, se necessario, aggiungiamo una descrizione che identifichi chiaramente lo scenario a cui è destinata.

Nella pagina Device group selezioniamo l’Assigned security group creato in precedenza; questo è il gruppo nel quale i dispositivi verranno inseriti automaticamente durante il provisioning.

Nella sezione Configuration Settings, espandiamo Deployment settings e selezioniamo User-driven come Deployment mode, Single user come Deployment type e Microsoft Entra joined come Join type (che è anche l’unico selezionabile). L’impostazione User account type determina invece se l’utente che completa il provisioning deve avere privilegi di Standard User oppure Administrator sul dispositivo. Quando viene selezionato Standard User, il processo di device preparation si occupa di rimuovere l’utente dal gruppo Administrators locale prima del completamento del deployment.

Configurare la Device Preparation Page

La sezione Out-of-box experience settings controlla anche il comportamento della Device Preparation Page visualizzata durante l’installazione delle app e l’esecuzione degli script selezionati nella policy.

Minutes allowed before showing installation error stabilisce il timeout complessivo del provisioning e accetta un valore compreso tra 15 e 720 minuti. Il valore riguarda l’intero deployment, non il timeout di una singola applicazione o di uno specifico script. La scelta deve quindi tenere conto del numero e delle dimensioni delle applicazioni incluse nella policy e delle prestazioni delle reti sulle quali verranno configurati i dispositivi.

Con Custom error message è possibile definire il messaggio visualizzato quando il provisioning non riesce.

Allow users to skip setup after multiple attempts controlla la disponibilità del pulsante Continue anyway nella schermata di errore, accanto a Retry. Se abilitato, consente di raggiungere il desktop anche quando il deployment non è riuscito. Negli ambienti nei quali le applicazioni configurate nella Device Preparation Page sono considerate necessarie per sicurezza o operatività, questa scelta dovrebbe essere valutata attentamente.

L’impostazione Show link to diagnostics permette infine di rendere disponibile nella schermata di errore un collegamento attraverso il quale recuperare i log diagnostici. Per un pilot può essere particolarmente utile abilitarla, perché consente di ottenere più rapidamente le informazioni necessarie quando il provisioning non raggiunge il desktop.

Nella stessa sezione troviamo le impostazioni riservate ai dispositivi associati: Language (Region), Automatically configure keyboard, Hide Microsoft Software License Terms, Hide privacy settings, Hide change account options e Apply device name template.

Hide change account options richiede che sia stato configurato il company branding in Microsoft Entra ID. Se viene utilizzato Hide privacy settings, i servizi di localizzazione vengono disabilitati per impostazione predefinita. Durante OOBE su una connessione Wi-Fi, le schermate relative a lingua e tastiera non vengono nascoste.

Con Apply device name template è possibile assegnare il nome al computer prima dell’enrollment. Il template supporta %SERIAL% per utilizzare il serial number e %RAND:x% per aggiungere una sequenza numerica casuale composta dal numero di cifre specificato in x. Il nome risultante può avere una lunghezza massima di 63 caratteri, può contenere lettere, numeri e trattini e non può essere composto esclusivamente da numeri.

Aggiungere applicazioni e script alla policy

Nella sezione Apps selezioniamo Add e scegliamo le applicazioni che devono essere installate prima che il provisioning possa essere considerato completato. La policy permette di includere fino a 25 applicazioni, che devono corrispondere a quelle precedentemente assegnate all’Assigned device group. Le applicazioni possono essere anche applicazioni Win32 dell’ Enterprise App Catalog app.

La sezione Scripts funziona nello stesso modo e consente di selezionare fino a 10 script PowerShell. Anche in questo caso gli script devono essere già assegnati al device group ed essere configurati per l’esecuzione nel System context. La presenza di un’applicazione o di uno script in Intune, da sola, non lo rende quindi parte del provisioning: devono essere presenti sia l’assegnazione al gruppo sia la selezione nella device preparation policy.

Assegnazione e creazione della policy

Nella pagina Assignments selezioniamo il gruppo utenti previsto per lo scenario user-driven. Nel mio esempio utilizzo All users; nel vostro ambiente scegliete il gruppo di utenti a cui destinare la policy.

Dopo avere controllato la configurazione in Review + create, la policy può essere salvata. Quando Device Association verrà configurata nel passaggio successivo sarà possibile associare questa stessa policy direttamente a uno specifico dispositivo; in presenza sia dell’assegnazione device-based sia di quella user-based, avrà precedenza la prima.

A questo punto la parte di Windows Autopilot device preparation è pronta e si può passare alla raccolta del DeviceLink CSV e alla pre-associazione del dispositivo. La Device Association non sostituisce quindi la device preparation policy: aggiunge l’identità preventiva del computer e permette di stabilire quale delle policy già predisposte debba essere utilizzata per quello specifico hardware.

Esportare le informazioni del dispositivo

Nel flusso manuale disponibile tramite Intune, il computer viene avviato nella Windows OOBE, fino alla schermata iniziale di selezione della regione, senza completare il setup. Premendo rapidamente per cinque volte il tasto Windows si apre il menu Autopilot. Selezioniamo Assign device association e poi Next: viene mostrata la schermata con il codice QR e il collegamento Export device information. Dopo aver collegato un supporto rimovibile, selezioniamo questo collegamento per esportare il DeviceLink CSV. La sequenza è illustrata nelle Figure 20-23.

È consigliato utilizzare un supporto USB formattato in NTFS. La stessa schermata mostra anche il codice QR, mentre l’importazione diretta attualmente disponibile in Intune utilizza il CSV generato da Export device information. Il QR code può essere utilizzato da un’applicazione personalizzata che richiama Microsoft Graph per eseguire la pre-associazione.

Se il computer ha già superato la OOBE, il DeviceLink CSV può essere recuperato dai diagnostici Autopilot. Le modalità supportate comprendono:

• l’esportazione dei management logs da Settings > Accounts > Access work or school
  
• il comando elevato MdmDiagnosticsTool.exe -area Autopilot -cab C:\Diagnostics\Autopilot.cab
  
• l’azione Collect diagnostics eseguita dal Microsoft Intune admin center
  

Pre-associare il dispositivo in Microsoft Intune

Il percorso nel Microsoft Intune admin center è Devices > Enrollment > Device association > Devices. Nell’interfaccia mostrata si seleziona Add > Upload a CSV file, si carica il DeviceLink CSV nella pagina Import CSV files e si procede alla pagina Choose device preparation policy. L’assegnazione della policy in questa fase è facoltativa: selezionandola si crea un’assegnazione device-based; lasciando vuoto il campo, durante l’enrollment viene utilizzata la policy applicabile all’utente che effettua l’accesso. In Review si controlla il riepilogo e si seleziona Upload per confermare l’importazione.

Dopo la conferma, il computer viene visualizzato nell’elenco con stato Pre-associated.

Negli screenshot WKS0001 è un identificativo esemplificativo normalizzato per la guida.

Completare l’associazione durante OOBE

Una volta creato il record di pre-associazione, Device Association viene completata automaticamente quando il computer si connette alla rete durante OOBE. Il tecnico può anche forzare immediatamente l’operazione tornando alla schermata Assign device association e proseguendo con Next dopo la pre-associazione.

Il dispositivo contatta il servizio Autopilot, individua il record di pre-associazione e presenta l’identità hardware attesa. Se la verifica riesce, viene mostrato Association complete e viene scritto il marker di tenant affinity nel firmware UEFI. Nel portale il computer passa quindi dallo stato Pre-associated a Associated.

A quel punto il dispositivo può utilizzare la device preparation policy eventualmente assegnata direttamente, viene considerato corporate-owned e può ricevere le personalizzazioni OOBE abilitate dalla Device Association.

Monitorare Device Association

Il monitoraggio dell’associazione avviene dalla stessa pagina, quindi Devices > Enrollment > Device association > Devices. La vista permette di cercare un computer attraverso serial number o device name e di filtrare i risultati per association state, policy, manufacturer e model. Gli stati principali sono Pre-associated, Associated e Pending removal.

Stato	Significato
Pre-associated	Il record è stato importato, ma il dispositivo deve ancora completare l’association durante OOBE
Associated	L’association è stata completata e il dispositivo è pronto per l’enrollment
Pending removal	È stata inviata una richiesta di rimozione ed è in elaborazione

Coesistenza con il Windows Autopilot tradizionale

Un dispositivo già registrato in Windows Autopilot tradizionale può essere anche pre-associato con Device Association; i due record possono quindi coesistere, ma quando il computer entra nella OOBE viene eseguito un solo percorso di provisioning. Se il dispositivo completa Device Association, l’associazione ha precedenza e viene eseguito il deployment Windows Autopilot device preparation, mentre se il computer è invece registrato in Windows Autopilot ma non dispone di un’associazione valida con il tenant, continua ad avere precedenza il deployment profile Autopilot tradizionale.

Questa caratteristica permette di preparare una migrazione graduale senza dismettere anticipatamente l’ambiente esistente. Un computer può essere pre-associato mentre è ancora enrolled e utilizzato normalmente; Device Association entrerà effettivamente in gioco quando il dispositivo tornerà nella OOBE in occasione di un reset o di un refresh pianificato.

Reset, reinstallazione e decommissioning

La tenant affinity di Device Association viene conservata nel firmware UEFI, quindi persiste dopo un reset, una reinstallazione di Windows e la rimozione dell’enrollment. Questa persistenza è utile quando il computer deve essere ricondizionato e riutilizzato all’interno della stessa azienda, ma richiede un processo preciso quando il dispositivo lascia definitivamente il tenant.

Per un record ancora Pre-associated, che non ha completato l’associazione durante OOBE, è sufficiente selezionare il dispositivo in Devices > Enrollment > Device association > Devices e scegliere Delete. Per un computer già Associated, la cancellazione del solo record cloud non rimuove la tenant affinity dal firmware.

Si cancellano poi le informazioni Device Link dal firmware UEFI secondo la procedura Microsoft e infine si elimina il record dall’elenco Device association di Intune. La rimozione locale richiede accesso fisico al dispositivo.

La cancellazione delle variabili Device Link in UEFI rimuove esclusivamente Device Association. Non esegue un TPM reset, non rimuove automaticamente l’enrollment MDM e non cancella gli oggetti del dispositivo da Microsoft Entra ID o Intune; queste attività devono essere gestite separatamente nella procedura di decommissioning.

Una pre-associazione può inoltre diventare stale quando cambia l’identità hardware del dispositivo, per esempio dopo determinate modifiche a BIOS/UEFI o Secure Boot, oppure quando il dispositivo viene associato a un tenant differente. I record stale di pre-associazione vengono cancellati automaticamente dopo 360 giorni.

Come impostare un pilota

Un pilot dovrebbe utilizzare dispositivi fisici rappresentativi dell’hardware realmente presente in azienda e una device preparation policy dedicata, evitando di coinvolgere immediatamente l’intera popolazione user-driven.

La prima verifica riguarda il client. Il computer deve eseguire Windows 11 24H2 o 25H2 con KB5120998 o successiva, il TPM 2.0 deve essere healthy e la rete usata durante OOBE deve poter raggiungere sia gli endpoint generali di Windows Autopilot device preparation sia quelli specifici di Device Association e Azure Attestation. Il test andrebbe eseguito anche sulle tipologie di connettività realmente utilizzate dagli utenti, perché un provisioning eseguito soltanto dalla LAN IT potrebbe non rappresentare ciò che accadrà da una sede remota o da una rete Wi-Fi domestica.

Il secondo controllo riguarda il targeting. Un test utile consiste nell’assegnare direttamente una device preparation policy a un computer e lasciare un secondo dispositivo senza policy device-based, verificando così sia la precedenza dell’assegnazione al dispositivo sia il fallback verso la policy dell’utente.

La validazione dovrebbe comprendere anche il device name template, le personalizzazioni della OOBE, l’appartenenza al device group definito tramite Enrollment Time Grouping, le applicazioni necessarie prima del desktop e gli script PowerShell. Per Win32 app e script è utile verificare anche i log della Microsoft Intune Management Extension, soprattutto quando il deployment report indica un errore generico.

Infine, il pilot dovrebbe includere almeno un reset del computer e una prova controllata di decommissioning. Device Association interviene infatti sull’intero lifecycle dell’endpoint e verificare soltanto il primo enrollment lascerebbe fuori proprio uno degli aspetti più particolari della tecnologia: la persistenza della tenant affinity nel firmware.

Conclusioni

Windows Autopilot Device Association rende Windows Autopilot device preparation molto più adatto agli scenari nei quali il team IT deve conoscere e classificare il computer prima che l’utente completi l’enrollment. Il dispositivo può essere collegato al tenant tramite una relazione TPM-backed, può ricevere direttamente una specifica device preparation policy e può utilizzare personalizzazioni della OOBE e del naming che dipendono dalla sua identità anziché esclusivamente da quella dell’utente.

La disponibilità di Device Association non rende però equivalenti Windows Autopilot device preparation e il Windows Autopilot tradizionale. Pre-provisioning, Self-deploying, Microsoft Entra hybrid join e Autopilot into co-management continuano a richiedere il modello Autopilot esistente, mentre per gli scenari user-driven Windows 11 Microsoft Entra joined idonei può essere valutato Windows Autopilot device preparation.

Per chi gestisce già Windows 11 con Microsoft Intune, l’approccio più prudente consiste quindi nel selezionare una popolazione user-driven rappresentativa, pre-associare pochi dispositivi, validare OOBE, policy selection, Enrollment Time Grouping, naming, applicazioni, reporting, reset e decommissioning, quindi estendere gradualmente il modello alle popolazioni che non dipendono da funzionalità ancora esclusive del Windows Autopilot tradizionale.