Importare ed esportare policy di catalogo impostazioni in Intune

Quando ha senso esportare una policy Intune e quando no

Le policy di catalogo impostazioni in Intune non sono un file di configurazione portabile come un export di firewall o un template YAML. Sono oggetti legati al tenant, ai gruppi, agli scope tag, alle piattaforme e, in parte, alla disponibilità delle impostazioni nel momento in cui esporti. Per questo il primo errore da evitare è trattare l’export come una migrazione 1:1. In pratica, l’operazione serve soprattutto per tre casi: documentare lo stato attuale, replicare una baseline tra ambienti diversi e fare change controllati con confronto prima/dopo.

Se l’obiettivo è spostare una configurazione da un tenant all’altro, conviene pensarla come una ricostruzione assistita, non come un restore. Il dato utile è la struttura della policy: nome, descrizione, piattaforma, elenco delle impostazioni, valori selezionati, assegnazioni e filtri. Quello che cambia quasi sempre è il contesto: gruppi, device categories, compliance conditions, scope tag e, spesso, anche il set di impostazioni disponibile nella versione del servizio in quel momento.

In altre parole, esportare è utile per ridurre l’errore umano; importare serve per accelerare la ricreazione, ma va sempre verificato sul tenant di destinazione. Se manca una dipendenza, il file o il pacchetto non fallisce sempre in modo evidente: a volte l’oggetto entra parzialmente, a volte resta non assegnato, a volte alcune impostazioni vengono ignorate perché non supportate sulla piattaforma target.

Oggetti coinvolti: catalogo impostazioni, assegnazioni e dipendenze

Una policy di catalogo impostazioni in Intune è composta da elementi che non viaggiano tutti con lo stesso peso. Il nucleo è il set di configurazioni applicate a un profilo: puoi avere impostazioni per Windows, iOS/iPadOS, Android Enterprise e macOS, con vari livelli di granularità. Il secondo livello è l’assegnazione: gruppi Azure AD/Entra, include/exclude, filtri per device o user, e in alcuni casi scope tag per separare chi vede e chi amministra l’oggetto.

La parte che crea più problemi in export/import è la dipendenza esterna. Un profilo può puntare a gruppi che non esistono nel tenant di destinazione, a filtri non presenti, o a un set di impostazioni che cambia nel tempo. Se il profilo include riferimenti a risorse con ID diversi, il mapping manuale diventa obbligatorio. Per questo è utile mantenere una tabella di corrispondenza tra sorgente e destinazione prima di fare qualsiasi import massivo.

Un’altra distinzione importante è tra controllo operativo e automazione. Dal portale puoi esportare documentazione e, in alcuni casi, ricreare policy tramite importazione di template o tramite strumenti di terze parti. Con Graph API, invece, puoi estrarre i dettagli in modo ripetibile e versionabile. La scelta dipende dall’uso: se devi fare governance, il portale basta; se devi fare drift detection o migrazioni ricorrenti, serve un flusso scriptato.

Esportazione: cosa salvare davvero

Un export utile non è solo una copia del nome del profilo. Devi salvare almeno questi elementi: ID della policy, nome visuale, descrizione, piattaforma, elenco impostazioni con valori, assegnazioni, filtri, scope tag e data di estrazione. Se fai change management serio, aggiungi anche il tenant di origine, la versione del profilo e il riferimento al ticket o alla richiesta di modifica.

Se usi il portale, la limitazione è nota: non sempre ottieni un file importabile pronto all’uso. Per questo il metodo più robusto è estrarre via API e serializzare in JSON. Un esempio minimale di approccio con Microsoft Graph è interrogare le device configuration policy e le setting catalog policy, poi salvare l’output in un repository privato con redazione dei dati sensibili. In particolare, non conservare token, segreti, certificati o valori che possano esporre informazioni riservate.

Per una raccolta rapida, il flusso base è questo: