Microsoft Intune: Deployments & Deployment Plans

Introduzione

La distribuzione graduale di applicazioni e configurazioni è una pratica consolidata negli ambienti enterprise. Prima di estendere una nuova applicazione Win32, una policy di sicurezza o una configurazione a migliaia di endpoint, è normale partire da un gruppo ristretto di dispositivi, osservare il comportamento per un determinato periodo e procedere successivamente verso gruppi più ampi.

Con Microsoft Intune Deployments, disponibile in Public Preview, questo modello entra direttamente nel servizio Intune anche per applicazioni e configuration policy. La nuova esperienza consente di creare rollout composti da più ring, definire quando ciascun ring deve entrare in funzione e riutilizzare lo stesso modello attraverso i Deployment plans. La funzionalità è stata annunciata nel What’s new di Intune nella settimana del 21 settembre 2026.

Fino ad oggi un rollout di questo tipo richiedeva normalmente di progettare gruppi pilota e gruppi di produzione e modificare nel tempo gli assignment della singola app o policy, oppure di automatizzare il processo esternamente. La nuova feature Deployments introduce invece un livello di orchestrazione sopra gli assignment già esistenti: Intune aggiunge progressivamente i gruppi dei diversi ring al payload secondo la pianificazione configurata.

Il Deployment non sostituisce il sistema di assignment di Intune: l’app o la policy continua a essere assegnata ai dispositivi tramite i normali assignment. Il Deployment interviene su questi assignment aggiungendo progressivamente i gruppi definiti nei diversi ring, in base alla pianificazione configurata.

Deployment plans e Deployments

La nuova esperienza si basa su due elementi distinti: Deployment plans e Deployments. I nomi sono simili, ma i due oggetti hanno responsabilità diverse.

• Un Deployment plan descrive il modello con cui un’azienda vuole eseguire i rollout: contiene i ring, i gruppi associati, eventuali Assignment Filters, gli exclusion group e il tempo che deve trascorrere tra un ring e quello successivo. Il piano non contiene invece l’applicazione o la policy che sarà distribuita.
  
• Un Deployment rappresenta invece l’esecuzione vera e propria del rollout: viene associato a un singolo payload già esistente in Intune e può utilizzare un Deployment plan precedentemente creato oppure una configurazione di ring definita direttamente per quella specifica distribuzione.
  

Elemento	Deployment plan	Deployment
Scopo	Definire un modello di rollout riutilizzabile	Eseguire il rollout di un payload
Payload	Non contiene app o policy	Contiene un singolo payload
Ring	Sì	Sì
Gruppi Microsoft Entra	Sì	Sì
Assignment Filters	Supportati	Supportati quando applicabili
Exclude groups	Sì	Sì
Pianificazione	Definisce le attese tra i ring	Definisce l’avvio effettivo del rollout
Scope tags	Associabili direttamente al piano	Derivano dal payload
Riutilizzabile	Sì	No, rappresenta una specifica esecuzione
Pause/Resume/Cancel	Non applicabile	Supportati

Questa separazione permette, ad esempio, di creare un piano denominato “Windows – Standard rollout” con tre ring e riutilizzarlo successivamente per una nuova applicazione Win32, per una configurazione del Settings Catalog o per una Endpoint security policy compatibile. Una modifica successiva al Deployment plan non modifica però i Deployment già creati utilizzando quel piano: il Deployment riceve la configurazione del piano nel momento in cui viene creato e prosegue con quella configurazione.

Workload supportati durante la Public Preview

Il perimetro iniziale è volutamente limitato, infatti durante la Public Preview i Deployment sono disponibili per Windows 10 and later e per un insieme specifico di app e configuration policy.

Categoria	Payload supportato
Device configuration	Settings Catalog
Endpoint security	Endpoint security policies
Applications	Windows app (Win32)
Applications	Enterprise App Catalog app

Per le applicazioni Win32 e le Enterprise App Catalog app è supportato esclusivamente l’intent Required, mentre gli intent Available e Uninstall non possono quindi essere utilizzati con Deployments. Per le applicazioni provenienti dall’Enterprise App Catalog, gli aggiornamenti gestiti mediante supersedence sono supportati, mentre la funzione Automatically update di Enterprise App Management non è attualmente compatibile con Deployments. Per approfondire potete consultare gli articoli Enterprise App Management con Microsoft Intune e Auto-update per Enterprise App Management, pubblicati su Endpoint Ninja.

Come avrete capito, il supporto iniziale è quindi chiaramente orientato a Windows. Il Deployment plan può essere creato anche scegliendo All platforms come modello generico, ma il Deployment effettivamente eseguito rimane vincolato ai payload e alle piattaforme supportate dalla funzionalità nella versione corrente.

Come funzionano i ring

Il concetto di ring rappresenta il cuore della funzionalità, ogni ring contiene almeno un gruppo e viene attivato secondo la pianificazione definita nel Deployment. Possiamo immaginare, ad esempio, una distribuzione articolata in questo modo:

Ring	Target	Attivazione
Ring 1 – IT Pilot	Dispositivi del team IT	Avvio del Deployment
Ring 2 – Early Adopters	Gruppo di utenti o dispositivi pilota	2 giorni dopo Ring 1
Ring 3 – Production	All devices	5 giorni dopo Ring 2

Il primo ring riceve una Start date e una Start time e per i ring successivi viene configurato invece il tempo di attesa rispetto al ring precedente, espresso in giorni e ore (tra due ring deve trascorrere almeno un’ora). Il vantaggio rispetto alla gestione manuale degli assignment è evidente soprattutto quando questo modello viene utilizzato regolarmente. Ad esempio, la sequenza Pilot 🡪 Early Adopters 🡪 Production può essere definita una volta nel Deployment plan e riutilizzata per payload differenti.

Cosa accade agli assignment

Questa è probabilmente la parte più importante da comprendere prima di utilizzare Deployments. Quando un ring viene attivato, Intune modifica gli assignment del payload originale aggiungendo i gruppi appartenenti al ring; gli assignment Required diventano quindi progressivamente cumulativi.
Supponiamo che una Win32 app abbia già un assignment Required verso il gruppo Existing devices e venga successivamente utilizzata in un Deployment con due ring.

Dopo l’attivazione del primo ring gli assignment del payload diventerebbero:
Existing devices + Pilot

Dopo l’attivazione del secondo ring:
Existing devices + Pilot + Production

I gruppi dei ring precedenti non vengono rimossi quando si passa a quello successivo, e questo significa anche che il payload rimane modificabile durante il Deployment. I Deployments non creano uno snapshot e non bloccano la versione dell’app o della policy: se la configurazione del payload viene modificata mentre il rollout è in corso, i gruppi già assegnati riceveranno la nuova configurazione al successivo check-in e i ring che devono ancora essere attivati riceveranno la versione aggiornata del payload.

Il comportamento particolare di All users e All devices

I gruppi virtuali All users e All devices hanno un comportamento specifico: quando uno dei due viene inserito in un ring, quel ring diventa automaticamente il ring finale del Deployment.

Inoltre, un gruppo virtuale non può essere combinato nello stesso ring con gruppi di sicurezza Microsoft Entra. Quando il ring contenente All users o All devices viene attivato, il gruppo virtuale sostituisce i precedenti Required include-group assignments del payload. Gli assignment di esclusione vengono invece mantenuti. Riprendendo l’esempio precedente:

Fase	Required include assignments
Prima del Deployment	Existing devices
Ring 1	Existing devices + Pilot
Ring 2	Existing devices + Pilot + Early Adopters
Ring finale con All devices	All devices

Creare un Deployment plan

I Deployment plans si trovano nel Microsoft Intune admin center seguendo il percorso Devices > Deployments. Da questa pagina è possibile accedere alla sezione dedicata ai Deployment plans e selezionare Create plan.

Nella pagina Basics inseriamo un nome facilmente riconoscibile e una descrizione che permetta di capire come verrà utilizzato il modello. In un ambiente strutturato può essere utile adottare una nomenclatura che identifichi piattaforma e finalità, ad esempio “Windows – Standard rollout – 3 rings”

Proseguendo nella pagina Deployment schedule viene richiesta la piattaforma. La scelta della piattaforma determina anche quali Assignment Filters potranno essere associati ai gruppi inseriti nei ring. È possibile scegliere All platforms quando il piano deve rimanere generico; in quel caso i filtri vengono definiti successivamente, dopo la selezione del payload durante la creazione del Deployment.

Se utilizzate Assignment Filters per restringere ulteriormente il target, può essere utile approfondire anche il funzionamento dei filtri e delle proprietà disponibili in Intune, soprattutto quando i ring devono includere soltanto dispositivi con determinate caratteristiche.

Definire i ring

Selezionando Add rings si apre la configurazione della sequenza di rollout. Al primo ring viene assegnato un nome. La data di partenza non viene memorizzata nel Deployment plan perché sarà stabilita quando il piano verrà utilizzato per creare un Deployment. Per ogni ring successivo viene invece configurato Wait time to next ring, indicando quanti giorni e ore devono trascorrere prima della fase successiva. Il valore minimo tra due ring è un’ora.

Una volta definita la struttura, associamo almeno un gruppo Microsoft Entra a ciascun ring. Dove supportato è possibile applicare anche un Assignment Filter alla singola assegnazione. Gli eventuali Exclude groups vengono invece applicati a tutti i ring del Deployment plan.

Prima della creazione è possibile associare gli eventuali Scope tags previsti dal modello RBAC del tenant.

Dopo il controllo della pagina Review + create, selezioniamo Save.

Il Deployment plan rimane modificabile anche dopo la creazione: le modifiche effettuate successivamente vengono però utilizzate soltanto dai nuovi Deployment e non vengono propagate alle distribuzioni già create con quel piano.

Creare un Deployment

Una volta preparato il modello di rollout possiamo creare il Deployment vero e proprio. Torniamo in Devices > Deployments e selezioniamo Create. Nella sezione Basics specifichiamo Name e Description: nel nostro esempio “Deployment – Windows LAPS”.

Successivamente, nela pagina Payload selection è possibile scegliere tra:

• Device configuration
• App
  

Con Add payload selezioniamo l’applicazione o la policy che vogliamo distribuire, nel nostro caso selezioneremo Device configuration per la distribuzione della policy per Windows LAPS. Il payload deve essere già presente in Intune e deve appartenere a una delle categorie supportate dalla Public Preview. Inoltre, lo stesso payload non può essere utilizzato contemporaneamente da un altro Deployment che si trovi nello stato scheduled o active.

Una volta scelta la configurazione, confermiamo la selezione con Select payload e selezioniamo Next.

Utilizzare un Deployment plan

Nella pagina Deployment schedule selezioniamo Load deployment plans. Prima di scegliere il piano viene impostata la Start date e la Start time del primo ring. I ring successivi vengono calcolati utilizzando gli intervalli definiti nel piano. Dopo aver caricato il Deployment plan, gruppi e Assignment Filters possono essere adattati per quella specifica distribuzione prima della creazione definitiva del Deployment. Il Deployment plan rimane quindi un modello di partenza e non obbliga necessariamente ogni esecuzione a utilizzare esattamente gli stessi gruppi.

Una volta eseguita la selezione, confermiamo con Select.

Verranno visualizzati i dettagli del Deployment plan selezionato adattato agli orari inseriti in precedenza.

Controlliamo infine il riepilogo nella pagina Review + create e selezioniamo Create.

Configurare i ring senza utilizzare un piano

Attenzione, l’utilizzo di un Deployment plan non è obbligatorio: per distribuzioni occasionali è possibile selezionare Add rings direttamente durante la creazione del Deployment e definire manualmente nomi, gruppi e intervalli. La differenza è principalmente organizzativa… una configurazione manuale appartiene soltanto a quel Deployment, mentre un Deployment plan consente di codificare e riutilizzare lo stesso modello di rollout per payload differenti.

Pause, Resume e Cancel

Dopo la creazione, il Deployment può essere messo in pausa, ripreso oppure annullato tramite i comandi Pause, Resume e Cancel.

È però importante interpretare correttamente queste operazioni:

Pause

Pause interrompe la progressione verso i ring successivi. Gli assignment introdotti dai ring già attivati rimangono però presenti sul payload. Di conseguenza, i dispositivi appartenenti ai ring già raggiunti continuano a essere destinatari dell’app o della policy. Se il payload viene modificato direttamente durante la pausa, questi dispositivi possono ricevere la modifica durante i successivi check-in.

Resume

Resume riavvia la progressione del Deployment. Se il Deployment è entrato in uno stato di errore, ad esempio a causa di una collisione negli assignment, la causa deve essere corretta prima di poter proseguire.

Cancel

Cancel impedisce l’attivazione dei ring futuri, ma non rimuove gli assignment aggiunti dai ring già completati. Per effettuare un vero rollback del targeting è quindi necessario intervenire successivamente sugli Assignments del payload.

Modificare il Deployment

Un altro elemento da considerare riguarda la modificabilità del Deployment. Dopo la creazione è possibile aggiornare nome e descrizione, mentre payload, ring, schedule, gruppi e informazioni relative agli Scope tags non possono essere modificati direttamente dal Deployment. Questa limitazione rende particolarmente importante controllare con attenzione il riepilogo prima della creazione.

Assignment collision

Deployments verifica che lo stesso gruppo non sia contemporaneamente presente negli assignment del payload e all’interno di uno dei ring. Se una collisione viene rilevata durante la creazione, Intune richiede di rimuovere il gruppo da una delle due configurazioni prima di poter procedere. La verifica viene ripetuta anche quando ciascun ring deve essere attivato. Questo secondo controllo è importante perché gli assignment del payload possono essere modificati mentre il Deployment è già in esecuzione.

Se al momento dell’attivazione di un ring il relativo gruppo è stato nel frattempo assegnato direttamente al payload, il Deployment entra in error state e viene sospeso. È necessario rimuovere il gruppo in conflitto dagli assignment del payload e successivamente utilizzare Resume.

Cosa accade se un gruppo viene eliminato

I Deployment e i Deployment plans dipendono dai gruppi Microsoft Entra utilizzati per costruire i ring, la cancellazione di uno di questi gruppi può quindi interrompere il rollout.

• se un gruppo è soft-deleted, il Deployment entra in errore quando il ring interessato deve attivarsi. Durante il periodo di recupero di 30 giorni è possibile ripristinare il gruppo e successivamente riprendere il Deployment.
  
• se il gruppo è stato eliminato definitivamente, il Deployment non può essere riparato ripristinando l’oggetto: è necessario annullarlo o eliminarlo ed eventualmente crearne uno nuovo.
  

Nei Deployment plans, i gruppi cancellati vengono evidenziati quando si apre il piano e devono essere rimossi o ripristinati prima di poter utilizzare nuovamente la configurazione. Un ring rimasto senza gruppi deve inoltre ricevere almeno un nuovo assignment.

RBAC e Scope tags

La gestione dei Deployment plans introduce una specifica categoria di autorizzazioni RBAC denominata Deployment plan, con le azioni:

• Create
  
• Read
  
• Update
  
• Delete
  

Le autorizzazioni sono già incluse in diversi built-in role di Intune, tra cui Application Manager, Endpoint Security Manager, Policy and Profile Manager, School Administrator, oltre alle autorizzazioni di lettura previste per Read Only Operator e Help Desk Operator.

Per i Deployment non esiste invece una permission dedicata: le autorizzazioni dipendono dalla categoria del payload. Per creare un Deployment relativo a una device configuration servono Read e Assign sulla categoria Device configurations. Per le applicazioni servono gli stessi permessi sulla categoria Mobile apps.

Anche il comportamento degli Scope tags segue questa distinzione: un Deployment plan può avere Scope tags propri, mentre un Deployment non dispone di Scope tags assegnabili direttamente: la sua visibilità amministrativa deriva dal payload associato. Quindi, se un amministratore non può visualizzare l’app o la policy a causa del proprio scope, non potrà visualizzare o selezionare neppure il relativo Deployment.

Integrazione con Multi Admin Approval

Deployments supporta anche Multi Admin Approval, permettendo di aggiungere un controllo amministrativo al rollout. Se esiste una Access policy MAA che protegge il tipo di payload utilizzato, le operazioni effettuate sul Deployment vengono sottoposte al relativo processo di approvazione. Le operazioni che possono richiedere Multi Admin Approval sono:

• Create
  
• Resume
  
• Cancel
  
• Delete
  

L’approver deve inoltre disporre dell’autorizzazione Read sul payload per poter accedere correttamente alle proprietà del Deployment dalla richiesta di approvazione. Quando la creazione di un Deployment richiede approvazione, l’oggetto non compare nell’elenco Deployments finché il processo MAA non è stato completato. Questa integrazione è particolarmente interessante per i rollout ad alto impatto, perché permette di separare la preparazione della distribuzione dall’autorizzazione alla sua esecuzione.

Limiti e known issues della Public Preview

Oltre ai limiti relativi ai payload supportati, la versione attuale presenta alcuni known issues documentati. Alla data della pubblicazione di questo articolo:

• la pagina Deployments non supporta ancora l’ordinamento manuale;
  
• la ricerca viene effettuata esclusivamente sul nome del Deployment;
  
• un Deployment in attesa dell’approvazione MAA non compare nell’elenco finché l’approvazione non viene completata;
  
• lo stato MAA può essere controllato aprendo il Deployment oppure dalle aree Multi Admin Approval e Admin tasks.
  

Come imposterei i Deployment in produzione

La funzionalità rende molto più semplice formalizzare un modello di rollout che in molti tenant esiste già attraverso gruppi e procedure interne.

Un possibile Deployment plan Windows potrebbe prevedere un primo ring composto dal team IT e da alcuni dispositivi di laboratorio, seguito da un gruppo di early adopter sufficientemente rappresentativo e da un ultimo ring di produzione. Gli intervalli dovrebbero essere stabiliti in base al rischio del payload: un’applicazione utilizzata da pochi utenti può richiedere osservazioni diverse rispetto a una Endpoint security policy che modifica il comportamento di migliaia di dispositivi.

Gli Assignment Filters possono inoltre evitare la proliferazione di gruppi creati esclusivamente per una singola condizione tecnica. Ad esempio, un ring può essere assegnato a un gruppo ampio e ristretto successivamente in base alla versione del sistema operativo o ad altre proprietà supportate dal filtro.

Per le applicazioni dell’Enterprise App Catalog, Deployments può essere utile per introdurre nuove versioni tramite supersedence seguendo un modello pilota controllato. Bisogna però ricordare che l’attuale Public Preview non supporta la combinazione con Automatically update, quindi i due modelli di aggiornamento non devono essere considerati intercambiabili.

Un ultimo aspetto riguarda la governance degli assignment. Poiché il Deployment opera direttamente sugli assignment del payload, è opportuno evitare modifiche parallele non coordinate durante il rollout. In ambienti dove più team amministrano Intune, RBAC, Scope tags e Multi Admin Approval diventano quindi parte integrante del processo e non semplici impostazioni accessorie.

Conclusioni

Microsoft Intune, con i Deployments e Deployment plans, introduce finalmente un meccanismo generico per orchestrare rollout progressivi di applicazioni e configuration policy senza dover modificare manualmente gli assignment a ogni fase.

La possibilità di creare Deployment plans riutilizzabili permette di trasformare il modello di rollout dell’organizzazione in un oggetto Intune vero e proprio, con ring, gruppi, Assignment Filters, exclusion group e intervalli predefiniti. Il Deployment applica successivamente quel modello a un singolo payload e consente di sospendere, riprendere o interrompere la progressione.

Per utilizzarlo correttamente bisogna però tenere presente il suo funzionamento interno. Gli assignment vengono effettivamente aggiunti al payload, rimangono cumulativi tra i ring e non vengono rimossi utilizzando Pause o Cancel. Anche le modifiche dirette al payload continuano ad avere effetto mentre il Deployment è attivo.

La Public Preview è attualmente limitata a Windows, Win32 app, Enterprise App Catalog app, Settings Catalog ed Endpoint security policies, ma l’impostazione introdotta con Deployments permette già di costruire procedure di rollout più ripetibili e controllabili. In particolare, la combinazione tra Deployment plans, Assignment Filters, RBAC e Multi Admin Approval offre una base interessante per gli ambienti Intune in cui la distribuzione graduale è già parte dei processi operativi.