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 Entra ID, 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:

# Esempio concettuale: esportazione via Microsoft Graph con PowerShell
# Richiede Graph PowerShell SDK e permessi adeguati in lettura

Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All"

$policies = Get-MgDeviceManagementConfigurationPolicy -All |
  Select-Object Id, Name, Description, Platforms, Technologies, CreatedDateTime, LastModifiedDateTime

$policies | ConvertTo-Json -Depth 10 | Out-File .\intune-setting-catalog-policies.json -Encoding utf8

Questo esempio salva l’elenco delle policy, ma in un export serio devi aggiungere anche le assegnazioni e i dettagli delle impostazioni. Se il tuo obiettivo è la documentazione, puoi fermarti qui e integrare con un dump separato delle assegnazioni. Se invece vuoi preparare un re-import, il JSON deve contenere anche la mappatura delle opzioni selezionate e non solo i metadati.

Importare una policy: ricreazione, mapping e validazione

L’import in Intune va inteso come ricostruzione della policy nel tenant di destinazione. Il punto non è “caricare un file”, ma riallineare oggetti equivalenti: gruppi, filtri, scope tag, piattaforme e impostazioni disponibili. Se il tenant di arrivo non ha gli stessi gruppi o usa naming diverso, l’import deve passare da una fase di mapping esplicita.

La sequenza corretta è semplice: prima crei o verifichi le dipendenze, poi importi la policy senza assegnazioni definitive, infine applichi gli assignment dopo il controllo. Questo riduce il rischio di spingere una configurazione su device sbagliati o su un perimetro troppo ampio. In un cambio controllato, l’assegnazione è quasi sempre l’ultimo passo, non il primo.

Se usi strumenti che promettono import diretto da JSON o da template, controlla sempre tre cose: se supportano davvero la policy di catalogo impostazioni, se gestiscono i riferimenti esterni e se preservano i campi non visibili nel portale. Molti problemi nascono qui: il profilo sembra corretto, ma alcune impostazioni non vengono trasferite perché la versione del servizio o del connettore non le riconosce.

Un approccio prudente è questo:

1. Esporta la policy sorgente in JSON o in un formato equivalente e versionato.
2. Prepara una tabella di mapping tra gruppi, filtri e scope tag del tenant sorgente e quelli del tenant di destinazione.
3. Ricrea la policy senza assegnazioni, verificando che tutte le impostazioni siano supportate.
4. Applica un’assegnazione pilota a un gruppo ristretto.
5. Confronta lo stato risultante con l’export originale e solo dopo estendi il rollout.

Importazione ed esportazione con Graph: il flusso che regge nel tempo

Se l’obiettivo è fare il lavoro una volta sola, il portale può bastare. Se invece devi gestire ambienti multipli, audit periodici o migrazioni ricorrenti, Graph API è la strada più pulita. Il vantaggio non è solo tecnico: è anche operativo. Un export scriptato produce un artefatto ripetibile, confrontabile nel tempo e adatto a essere messo sotto controllo versione.

Il flusso tipico prevede tre passaggi: estrazione, normalizzazione e reimport. L’estrazione raccoglie i dati grezzi; la normalizzazione rimuove gli ID non portabili e sostituisce i riferimenti con chiavi logiche; il reimport usa quei riferimenti per creare l’oggetto nel tenant di destinazione. Senza normalizzazione, il file è solo una fotografia; con la normalizzazione diventa un template operativo.

In pratica, conviene separare i campi in due gruppi: quelli portabili e quelli da rimappare. I primi sono nome, descrizione, impostazioni e parte della struttura. I secondi sono ID di gruppi, filtri, scope tag e qualunque riferimento a oggetti del tenant. Questa distinzione evita il classico errore di importare un oggetto “corretto” ma inutilizzabile perché punta a risorse inesistenti.

Controlli prima e dopo l’import

Prima di importare, verifica che il tenant di destinazione abbia la stessa base funzionale: licenze Intune attive, ruoli amministrativi corretti, connettività con Entra ID, piattaforme abilitate e, se servono, filtri già creati. Se manca uno di questi elementi, l’import può riuscire solo in apparenza.

Dopo l’import, controlla almeno quattro punti: la policy esiste con il nome atteso, le impostazioni risultano tutte presenti, le assegnazioni puntano ai gruppi corretti e i dispositivi target ricevono effettivamente la configurazione. Per il controllo operativo, il portale Intune è sufficiente; per una verifica più rigorosa, confronta il JSON esportato prima e dopo oppure interroga di nuovo Graph e fai un diff strutturale.

Se noti discrepanze, non correggere subito a mano senza traccia. Prima identifica se il problema è nel mapping, nella disponibilità dell’impostazione o nella propagazione verso i device. In molti casi il difetto non è nella policy ma nella destinazione: gruppo sbagliato, filtro troppo restrittivo o impostazione non supportata dalla piattaforma selezionata.

Errori tipici che fanno perdere tempo

Il primo errore è confondere nome uguale con oggetto uguale. In Intune due policy possono avere lo stesso scopo ma differire per piattaforma, scope tag o assegnazione. Il secondo errore è esportare solo i metadati e dimenticare i valori reali delle impostazioni. Il terzo è importare senza aver preparato il mapping dei gruppi.

Un altro punto critico è la gestione delle versioni del catalogo. Intune evolve e alcune impostazioni cambiano disponibilità nel tempo. Quello che oggi esiste nel tenant sorgente potrebbe non essere identico domani nel tenant di destinazione. Per questo un export fatto bene deve includere anche la data e, se possibile, un riferimento alla versione del profilo o al momento di estrazione.

Infine, attenzione ai permessi. Un export parziale spesso non genera un errore evidente: semplicemente non restituisce tutti i dati. Se il tuo account ha privilegi insufficienti, il risultato può sembrare valido ma essere incompleto. In un flusso serio, il primo controllo non è sul file, ma sulla sessione e sui ruoli con cui hai interrogato Intune.

Buona pratica operativa: repository, naming e tracciabilità

Il modo più solido per gestire import ed export è trattare le policy come codice operativo, anche se non sono ancora Infrastructure as Code puro. Ogni export dovrebbe finire in un repository privato con naming coerente, cartelle per tenant e piattaforma, e un file di metadati che indichi chi ha fatto l’estrazione, quando, da quale ambiente e con quale scopo.

Un naming utile evita ambiguità. Ad esempio, separa ambiente, piattaforma e funzione: produzione, pilot, Windows, baseline, hardening. In questo modo il confronto tra versioni è più semplice e il rischio di sovrascrivere la policy sbagliata si riduce. Se il profilo è destinato a più tenant, mantieni anche una tabella di corrispondenza dei gruppi e dei filtri, aggiornata a ogni change.

La tracciabilità non è burocrazia: è il modo più rapido per capire perché una policy è arrivata in uno stato diverso da quello atteso. Se qualcosa non torna, devi poter risalire all’export originale, al mapping usato e all’assegnazione applicata. Senza questi tre elementi, ogni import diventa una ricostruzione a memoria.

Quando fermarsi e non forzare l’import

Ci sono casi in cui l’import non va forzato. Se il tenant di destinazione non supporta alcune impostazioni, se il mapping dei gruppi non è affidabile o se la policy tocca un perimetro troppo ampio per un test controllato, conviene fermarsi e riprogettare. Un import “quasi riuscito” in Intune può essere più pericoloso di un import fallito, perché lascia una configurazione apparentemente sana ma in realtà incompleta.

La regola pratica è questa: se non puoi verificare l’equivalenza dei riferimenti esterni, non assegnare. Se non puoi verificare la compatibilità delle impostazioni, non importare in massa. Se non hai un export completo e versionato, non considerarlo una baseline affidabile.

Usato bene, l’export/import delle policy di catalogo impostazioni diventa un acceleratore per governance, migrazioni e change control. Usato male, produce solo copie parziali e troubleshooting inutile. La differenza sta nella qualità dell’artefatto esportato e nella disciplina con cui gestisci dipendenze, mapping e verifica finale.