Capita spesso di dover distribuire una nuova applicazione, una modifica al firewall o una configurazione di sicurezza a centinaia di endpoint. Tecnicamente bastano poche assegnazioni in Intune. Operativamente, però, una modifica sbagliata distribuita a tutti può trasformarsi in un incidente. Microsoft Intune Deployment Plans nasce per dare una struttura riutilizzabile ai rollout graduali: prima un gruppo pilota, poi altri gruppi, infine il resto del parco.
La novità è comparsa nelle note Microsoft della settimana del 21 settembre 2026 ed è in Public Preview. In questa guida vediamo come funziona davvero, cosa succede alle assegnazioni e soprattutto quali controlli rimangono responsabilità dell’amministratore.
Da un clic a 2.000 endpoint.
Ma non tutti insieme.
Esplora un rollout a ring, simula un errore e scopri cosa resta realmente assegnato quando premi Pause o Cancel.
PILOT 50IT 150BIZ 400PROD 1400
Esempio didattico: numeri e gruppi sono ipotetici, non un template Microsoft né una connessione a un tenant reale.
1. Che cosa è cambiato rispetto a prima?
I ring non sono una novità assoluta nella gestione IT: chi lavora con endpoint li utilizza da anni per Windows Update, applicazioni e policy. La novità è poter formalizzare una sequenza di assegnazioni in un piano Intune riutilizzabile, invece di affidarsi a un calendario esterno e a un amministratore che modifica manualmente i gruppi uno dopo l’altro.
Microsoft distingue due oggetti. Clicca su ciascuno per esplorarli:
Plan ≠ Deployment
Uno stabilisce la regola; l’altro esegue una distribuzione concreta.
Un deployment può usare un piano già esistente oppure definire i ring una sola volta. Una volta creato, puoi cambiarne nome e descrizione, ma non payload, nomi dei ring, calendario, gruppi e scope tag attraverso il deployment. Per modificarne la struttura occorre pianificarne uno nuovo. E non puoi associare lo stesso payload a due deployment contemporaneamente pianificati o attivi.
2. Come funziona il rollout: quattro ring, una sola applicazione
Prendiamo un esempio: un’azienda vuole distribuire una nuova versione di un’applicazione Win32 a 2.000 PC. Prepara quattro gruppi Entra non sovrapposti e imposta i tempi di attivazione. La piattaforma aggiunge progressivamente le Required include assignments al payload sottostante: le assegnazioni dei ring già attivati rimangono e si sommano a quelle dei successivi.
Simula il rollout di 2.000 endpoint
Premi “Attiva ring successivo”, poi prova a mettere in pausa o annullare. Puoi anche simulare un incidente: la progressione NON si ferma automaticamente per un fallimento del pilot.
Utenti e hardware rappresentativi
Supporto interno e early adopters
Reparti pilota allargati
Resto del parco aziendale
Il minimo intervallo ammesso tra ring è di un’ora. Il calendario non verifica da solo una soglia di successo prima di passare al ring seguente: il controllo dei risultati e l’eventuale pausa vanno governati operativamente.
Pause non è Rollback. Microsoft chiarisce che Pause blocca la progressione dei ring futuri; Cancel la interrompe definitivamente. In entrambi i casi, le assegnazioni dei ring già attivati restano sul payload. Per ritirarle occorre intervenire sulle sue proprietà. Anche questo è un motivo per mantenere un piano di remediation separato dalla sola pianificazione temporale.
3. Dove si configura, concretamente?
Dal portale Microsoft Intune admin center → Devices → Manage devices → Deployments puoi creare i piani e avviare le distribuzioni. Prima serve preparare il payload supportato (app o policy) e i gruppi Microsoft Entra per ciascun ring.
Dalla bozza al rollout
Clicca una delle fasi per vedere i controlli da fare prima del passaggio successivo.
Un piano può includere filtri di assegnazione, gruppi da escludere in tutti i ring e scope tag per limitare la visibilità amministrativa. Può anche essere progettato per All platforms, ma durante la preview l’effettivo payload distribuibile rimane limitato ai casi esplicitamente supportati.
4. Cosa posso distribuire durante la Public Preview?
Qui è facile fare confusione: un template genericamente configurabile non significa che ogni tipologia di configurazione o dispositivo sia pronta. Microsoft documenta al momento Windows 10 e successivi, con i seguenti payload. Seleziona un caso per visualizzare il perimetro attuale:
Il tuo payload è supportato?
Le opzioni sotto riflettono la preview, non una promessa per il rilascio generale.
Per le applicazioni Win32 ed Enterprise App Catalog sono supportate soltanto le distribuzioni con intento Required, non Available o Uninstall. Nell’Enterprise App Catalog è supportato l’update tramite supersedence, ma non la funzione Automatically update abbinata ai Deployment Plans. Le policy coperte sono Settings catalog ed Endpoint security, non ogni oggetto presente nella console.
5. Il dettaglio insidioso: Intune non crea una copia delle assegnazioni
Il deployment agisce sulle assegnazioni Required del payload originale. Non è un secondo sistema isolato con regole separate. Se una stessa security group è assegnata direttamente al payload e compare anche in un ring, Intune rileva una collisione: alla creazione devi risolverla; se emerge quando il ring si attiva, il deployment entra in errore e si mette in pausa.
Una modifica manuale può bloccare il rollout
Simula l’assegnazione diretta dello stesso gruppo sia nel payload sia nel ring successivo.
Un’altra situazione poco intuitiva riguarda All users / All devices. Se inserisci uno di questi gruppi virtuali, il ring diventa automaticamente l’ultimo e non può contenere anche gruppi di sicurezza Entra. Quando quel ring si attiva, sostituisce le precedenti Required include assignment del payload; le esclusioni preesistenti sono preservate.
Cosa succede con “All devices” nell’ultimo ring?
Premi il comando e osserva come cambia l’elenco delle Required include assignments.
6. E se aggiorni l’applicazione mentre il deployment è in corso?
Il deployment non blocca il payload. Se modifichi direttamente un’app o una policy durante un rollout, i gruppi già assegnati ricevono la modifica al successivo check-in dei dispositivi; i gruppi dei ring ancora da attivare ricevono il payload aggiornato quando entrano nella distribuzione. È un punto rilevante per chi vuole mantenere versioni diverse tra pilot e produzione: un deployment non è di per sé un sistema di version pinning per ring.
Modifica al payload a metà del percorso
Visualizza come cambia il comportamento dei ring già attivi e di quelli futuri.
7. Governance: chi può creare un rollout e chi lo approva?
La gestione è integrata con il modello RBAC di Intune. I permessi sul piano sono distinti da quelli sul payload: per creare un deployment servono Read + Assign nella categoria pertinente (Device configurations o Mobile apps). Gli scope tag sono assegnabili ai piani; per i deployment la visibilità dipende dagli scope tag del payload.
Se hai configurato una policy di Multi Admin Approval per la categoria interessata, il flusso di approvazione si applica alle azioni supportate. Prova a esplorarlo:
Chi autorizza l’operazione?
Clicca un’azione amministrativa. Il risultato presuppone una policy MAA già attiva per la categoria del payload.
La documentazione Microsoft elenca Create, Resume, Cancel e Delete tra le azioni che attivano la richiesta di approvazione quando si applica una access policy MAA. Pause non è inclusa in quell’elenco. In caso di approvazione necessaria alla creazione, il deployment compare nell’elenco soltanto dopo l’autorizzazione.
8. Le cose che controllerei prima di portarlo in produzione
La preview è interessante, ma non sostituisce una progettazione accurata. In particolare, pianificazione e successo non sono sinonimi: poter aspettare 24 ore tra due ring non significa che Intune certifichi automaticamente il buon esito del primo.
Checklist pre-deploy
Usala come traccia per il CAB o per il change record. È un modello editoriale MarFedLab, non una checklist prescrittiva Microsoft.
☐ Il payload è tra le tipologie supportate dalla preview.
☐ I gruppi Entra sono stati verificati, senza collisioni o sovrapposizioni indesiderate.
☐ I filtri e le exclusion sono stati controllati per tutti i ring.
☐ La detection rule dell’app Win32 e i requisiti sono stati testati.
☐ Gli intervalli prevedono il tempo utile per monitoraggio e decisione umana.
☐ Helpdesk, owner del change e criteri per Pause sono definiti.
☐ Esiste un piano di remediation: Cancel non ritira le assegnazioni precedenti.
☐ Scope tag, RBAC e MAA sono coerenti con la governance aziendale.
Quindi è la fine delle assegnazioni manuali?
No. È un modo più strutturato per governare una specifica categoria di rollout. Le assegnazioni tradizionali restano il meccanismo sottostante, e in preview non tutto il mondo Intune è coperto. Il valore è avere un modello ripetibile e una sequenza esplicita: il pilot non esiste solo su un foglio Excel, ma entra nel processo di deployment.
La parte più importante, per me, è non confondere la presenza dei ring con un automatic quality gate. Intune pianifica quando ampliare l’assegnazione; l’organizzazione deve ancora stabilire cosa osservare tra un ring e il successivo, quando fermarsi e come intervenire sugli endpoint che hanno già ricevuto il payload.
Il punto: distribuire gradualmente riduce l’esposizione iniziale a un cambiamento non testato. Ma il vero controllo sta nel collegare quei ring a monitoraggio, ownership e decisioni operative, non nel limitarci ad aspettare che il calendario proceda.
Nota sulle demo: tutti i simulatori presenti nell’articolo sono esempi concettuali locali; non leggono dati dal tuo tenant Intune, non inviano richieste API e non cambiano alcun dispositivo. Funzionalità e limitazioni riportate fanno riferimento alla documentazione Microsoft della Public Preview consultata il 2 ottobre 2026.