Come duplicare una policy Settings Catalog in Intune

In Intune, una policy Settings catalog non ha un pulsante nativo per il clone completo come succede in altri strumenti di gestione. Il punto pratico è questo: se vuoi duplicarla, devi trattarla come un oggetto composto da impostazioni, scope tags, assegnazioni, filtri e, spesso, note operative. Copiare solo la parte visibile in console non basta, perché il comportamento reale della policy dipende anche dal contesto di distribuzione.

La strada corretta cambia a seconda dell’obiettivo. Se ti serve una copia quasi identica per un altro gruppo, puoi creare una nuova policy e replicare manualmente i setting. Se invece devi standardizzare più versioni simili, conviene costruire un metodo ripetibile con esportazione documentale o automazione via Microsoft Graph. La differenza non è accademica: nel primo caso lavori in pochi minuti, nel secondo riduci il rischio di drift e di configurazioni incoerenti nel tempo.

Quando ha senso duplicarla davvero

Duplicare una Settings Catalog policy ha senso quando vuoi mantenere una base comune ma cambiare uno o due parametri: per esempio una policy Windows che abilita lo stesso set di hardening, ma con assegnazioni diverse tra utenti IT, pilota e produzione. Ha meno senso se la nuova policy diverge molto dalla sorgente: in quel caso è meglio partire da zero, perché la copia manuale del catalogo può diventare fragile e difficile da mantenere.

Un buon criterio operativo è questo: se la nuova policy condivide almeno il 70-80% delle impostazioni con quella esistente, la duplicazione è un approccio sensato. Se invece cambia il profilo di device, il sistema operativo o il modello di compliance, stai più probabilmente cercando un nuovo design, non una copia.

Cosa Intune non duplica per te

La console non ti offre un clone one-click della Settings Catalog con tutti i dettagli preservati. In pratica, quando ricrei una policy devi considerare almeno questi elementi:

• nome e descrizione della policy;
• impostazioni selezionate nel catalogo;
• scope tags;
• assegnazioni a gruppi;
• filtri di targeting, se usati;
• eventuali esclusioni;
• stato di rollout e osservazioni operative.

Se trascuri uno di questi punti, la “copia” funziona solo sulla carta. Il caso più comune è la policy che sembra identica nelle impostazioni ma finisce su gruppi sbagliati, o con filtri mancanti, e quindi produce un comportamento diverso in produzione.

Procedura manuale in console: la via più sicura per una copia singola

Se devi duplicare una sola policy e vuoi minimizzare gli errori, la procedura manuale in console è spesso la più pulita. Non è la più elegante, ma è quella che ti permette di verificare ogni passaggio visivamente.

1. Apri Intune admin center e vai su Devices > Configuration profiles.

2. Apri la policy Settings Catalog sorgente e annota nome, descrizione, piattaforma, scope tag e assegnazioni.

3. Entra nella sezione Properties e salva l’elenco delle impostazioni configurate. Se il numero è alto, fai uno screenshot o una documentazione operativa esterna.

4. Crea una nuova policy con lo stesso tipo: Settings catalog, stessa piattaforma, stesso target logico.

5. Rimetti manualmente le impostazioni, verificando che i valori siano identici e che non manchino sotto-sezioni espandibili del catalogo.

6. Replica Assignments, Scope tags e, se presenti, Filters.

7. Salva e usa Review + create solo dopo aver ricontrollato il delta rispetto alla policy originale.

Il controllo più utile non è “sembra uguale”, ma “ha lo stesso comportamento di targeting”. Una policy identica ma assegnata a gruppi diversi può sembrare un clone riuscito e invece produrre effetti opposti nel tenant.

Metodo operativo consigliato: esporta il contenuto, ricrea la policy, poi valida il delta

Se lavori in modo ripetibile, conviene costruire una traccia della policy sorgente prima di creare la copia. Intune non ti fornisce sempre una vista comoda per confrontare due profili Settings Catalog riga per riga, quindi il trucco è portarti fuori dalla console le informazioni che servono davvero.

Una traccia minima utile contiene: nome policy, piattaforma, lista impostazioni, gruppi assegnati, filtri, scope tag e data dell’ultimo change. Se la policy è critica, aggiungi anche il motivo del profilo e il ticket o la change request di riferimento.

Per documentare il contenuto, una pratica semplice è usare un file interno con struttura coerente. Per esempio:

Policy source: Windows-Hardening-Base v1.4
Platform: Windows 10 and later
Assignments: GRP-WIN-PILOT, GRP-WIN-PROD
Filters: DeviceOwnership != Personal
Scope tags: IT-Sec
Notes: baseline for laptop fleet

Questo non sostituisce la console, ma evita di lavorare “a memoria”. In ambienti con molte policy simili, la memoria è il modo più rapido per introdurre differenze invisibili.

Quando usare Microsoft Graph per duplicare in modo serio

Se devi clonare più policy, o vuoi farlo in modo controllato e ripetibile, Microsoft Graph è la strada giusta. Non perché sia più raffinato, ma perché ti permette di leggere la policy sorgente, ricreare un oggetto nuovo e riapplicare le stesse impostazioni con meno rischio di errori manuali.

Il punto da chiarire subito è che non tutte le proprietà sono sempre facili da trattare allo stesso modo. Alcuni campi sono semplici da copiare, altri richiedono normalizzazione o mapping. Per questo la duplicazione via Graph va pensata come un processo in due fasi: estrazione e ricostruzione.

1. Recupera l’ID della policy sorgente.

2. Esporta i dettagli della configuration policy.

3. Crea una nuova policy con nome diverso.

4. Applica le stesse impostazioni, escludendo gli identificativi interni non riutilizzabili.

5. Replica assegnazioni, filtri e scope tags.

6. Valida il risultato con un confronto tra policy source e policy target.

Un esempio di chiamata utile per leggere una policy è questo:

GET https://graph.microsoft.com/beta/deviceManagement/configurationPolicies/{policyId}

Per vedere le impostazioni collegate, devi poi interrogare anche le risorse figlie della policy. Il dettaglio esatto cambia in base al tipo di profilo e alla versione dell’API, quindi qui il punto operativo è non fermarsi al solo oggetto principale. Se ti manca un campo, la verifica è semplice: controlla la documentazione Graph della specifica risorsa o la risposta JSON della policy sorgente.

Struttura di un clone affidabile: cosa deve essere uguale e cosa no

Non tutto va copiato in modo cieco. Alcuni campi devono essere identici, altri devono essere adattati. Questa distinzione evita di trasferire errori insieme alla policy.

• Da copiare: impostazioni del catalogo, descrizione operativa, scope tag se la governance è la stessa.
• Da adattare: nome policy, assegnazioni, filtri, eventuali esclusioni, rollout progressivo.
• Da non riutilizzare alla cieca: ID interni, riferimenti temporanei, note legate a un change specifico, valori già superati da una nuova baseline.

Un errore frequente è fare una copia “perfetta” e poi assegnarla allo stesso gruppo della sorgente. Se la policy nuova serve a testare una variante, il targeting deve essere volutamente diverso, altrimenti non stai creando una copia utile: stai solo duplicando la superficie di gestione.

Controllo del confronto: come capire se la copia è davvero equivalente

Dopo la ricostruzione, devi verificare che il comportamento atteso sia coerente. La validazione minima non è solo “la policy esiste”, ma “ha le stesse impostazioni e colpisce gli stessi device o un sottoinsieme voluto”.

1. Confronta il numero di impostazioni selezionate nella policy sorgente e nella copia.

2. Verifica che i gruppi assegnati siano quelli attesi, senza sovrapposizioni involontarie.

3. Controlla i filtri di targeting: spesso qui si annida il drift più subdolo.

4. Apri un device di test e verifica la ricezione della policy in Device status o User status, a seconda del caso.

5. Se la policy impatta impostazioni di sicurezza o hardening, controlla il lato dispositivo per conferma, non solo la console.

In pratica, la console ti dice che hai assegnato qualcosa; il device ti dice se quella cosa ha davvero effetto. Quando c’è discrepanza, il problema è quasi sempre nel targeting o in un conflitto con altre policy.

Conflitti e precedenze: il punto che rompe le copie “identiche”

Due policy uguali sulla carta possono comportarsi in modo diverso perché Intune non valuta il vuoto: valuta il contesto. Se una copia entra in collisione con un’altra policy, con una baseline o con un profilo di sicurezza già applicato, il risultato finale può cambiare senza che il clone sia formalmente errato.

Per questo, prima di considerare riuscita la duplicazione, conviene verificare il quadro di applicazione sul device. Se il problema è un conflitto, non serve rifare la policy da zero: serve capire quale oggetto la sovrascrive o la neutralizza.

Qui il lavoro corretto è osservare almeno questi segnali:

• stato di applicazione della policy nel device;
• eventuali errori o conflitti in report Intune;
• presenza di policy sovrapposte sullo stesso setting;
• filtri che escludono device attesi;
• tempi di sincronizzazione non ancora completati.

Approccio pratico consigliato in ambienti reali

Se devi farlo spesso, io imposterei questa sequenza operativa:

1. Documenta la policy sorgente con nome, scope, assegnazioni e lista setting.

2. Definisci cosa deve rimanere uguale e cosa deve cambiare nella nuova policy.

3. Crea la nuova policy con naming coerente ma distinto.

4. Replica solo le impostazioni necessarie, evitando di portarti dietro elementi non più validi.

5. Applica targeting minimo iniziale, idealmente su un gruppo pilota.

6. Valida su un device reale e solo dopo estendi il rollout.

Questo approccio è più lento di una copia brutale, ma evita il classico problema del clone che funziona solo finché non arriva il primo conflitto. In un tenant con molte policy, la velocità vera non è copiare più in fretta: è correggere meno volte.

Errore comune: confondere duplicazione con migrazione

Duplicare una Settings Catalog policy non è la stessa cosa che migrare una configurazione tra tenant o tra ambienti. Nel clone locale resti nello stesso contesto e puoi riusare gran parte della struttura. Nella migrazione, invece, cambiano spesso gruppi, nomi, scope tag, filtri e persino la strategia di rollout.

Se stai passando da un tenant a un altro, il rischio maggiore non è tecnico ma organizzativo: importi una policy con un significato che nel nuovo ambiente non esiste più. In quel caso la soluzione non è duplicare, ma reinterpretare la policy nel nuovo schema di governance.

Una copia utile non è quella che replica tutto; è quella che replica solo ciò che ha ancora senso nel nuovo contesto.

Conclusione operativa: scegli il metodo in base alla complessità

Per una duplicazione occasionale, la console basta. Per più copie, per policy critiche o per evitare drift, serve un processo documentato e, se possibile, automatizzato. Il vero obiettivo non è clonare un oggetto Intune: è mantenere coerente il comportamento del parco device con il minimo margine di errore umano.

Se vuoi una regola semplice: manuale per una copia singola e verificata, Graph per ripetibilità, nuova policy da zero quando la divergenza supera la somiglianza. È una scelta pratica, non teorica, e ti evita di portarti dietro complessità inutili.