Duplicare un'applicazione in SCCM: guida alla copia

Duplicare un’applicazione in SCCM conviene quando devi creare una variante quasi identica: stesso installer, parametri diversi, pubblico diverso, oppure una seconda release da testare senza toccare l’originale. Il punto è che in SCCM la copia non è mai solo estetica: alcuni campi si portano dietro riferimenti che vanno verificati subito, altrimenti ti ritrovi con detection sbagliata, contenuto non distribuito o deployment che punta alla collection sbagliata.

La regola pratica è semplice: duplica solo se vuoi preservare la struttura dell’applicazione, ma considera la copia come un oggetto da validare, non come un clone pronto all’uso. In ambienti Microsoft Configuration Manager, il rischio più comune non è il fallimento dell’installazione in sé, ma l’illusione che la copia sia già coerente con il nuovo contesto operativo.

Quando ha senso duplicare un’app in SCCM

Ci sono tre scenari tipici. Il primo è il cambio controllato: stessa app, ma con un nuovo parametro, un nuovo canale di distribuzione o una nuova versione da pilotare. Il secondo è il troubleshooting: vuoi isolare una configurazione senza alterare il package originale. Il terzo è la standardizzazione: hai una base comune e devi creare varianti per reparti, sedi o gruppi di sicurezza.

Se invece devi rifare da zero detection, install command e requirement rule, spesso è più pulito creare una nuova application e usare la vecchia come riferimento. La copia ha senso quando almeno metà del lavoro è già valida e vuoi ridurre il rischio di introdurre differenze involontarie.

Che cosa viene copiato davvero

In SCCM una application contiene più livelli: proprietà generali, deployment types, detection methods, requisiti, supersedence, dipendenze, user experience, content e associamenti alle collection. La copia può preservare gran parte di questi elementi, ma non devi assumere che tutto sia automaticamente consistente nel nuovo contesto.

Il punto più delicato è il content: il riferimento al source path può rimanere valido solo se il contenuto è identico e già disponibile sul distribution point. Se stai clonando per una nuova versione o per un branch diverso, il source va rivisto subito. Altro punto classico: le detection rule possono continuare a puntare a file o chiavi di registro che non rappresentano la nuova variante.

Occhio anche alle dependency e alla supersedence. Se copi una app che dipende da un’altra, la dipendenza resta spesso sensata solo finché il naming e la logica di rilascio non cambiano. Se invece stai creando una versione “2” o una variante per un ambiente separato, controlla che la catena di sostituzione non introduca effetti collaterali sul parco client.

Procedura pratica dal console path

Il percorso più lineare è dalla console di Configuration Manager. Vai in Software Library, poi Application Management, quindi Applications. Seleziona l’app da duplicare e usa l’azione di copia disponibile dal menu contestuale o dalla ribbon, a seconda della versione della console.

Dopo la copia, il primo controllo non è il nome ma il Deployment Types. Apri la nuova application e verifica che i deployment type abbiano ancora senso: tipo di installer, detection, requirement, return code, install behavior e system context. Se il nome è cambiato ma il detection method no, potresti avere una copia formalmente corretta e operativamente sbagliata.

Se lavori da console e non da script, conviene seguire sempre lo stesso ordine: validazione dei deployment type, revisione del content, eventuale aggiornamento delle proprietà globali, poi distribuzione su distribution point e solo alla fine deployment verso collection di test. Saltare i controlli iniziali è il modo più rapido per pubblicare un clone rotto in produzione.

Controlli da fare subito dopo la copia

Qui si evita il classico errore da copia “troppo fiduciosa”. I controlli minimi sono questi:

• Nome e versione: il naming deve distinguere chiaramente la nuova app dall’originale.
• Detection method: file, registro, MSI product code o script devono corrispondere alla nuova variante.
• Content source: il path di origine deve essere coerente con il pacchetto che vuoi distribuire.
• Requirement rule: OS, architettura, spazio disco, lingua o prerequisiti devono restare validi.
• Dependencies e supersedence: verifica che non puntino a oggetti che non vuoi coinvolgere.
• Collections: assicurati di non aver ereditato un target ampio o sbagliato.

Se vuoi una verifica rapida senza aspettare i client, controlla nel nodo delle proprietà dell’application che il deployment type mostri ancora i valori attesi. Per esempio, un detection basato su file deve puntare al percorso giusto e con la versione giusta; un detection basato su registry deve leggere la chiave corretta e non una chiave ereditata da un prodotto simile.

Il punto debole: detection method e contenuto

La maggior parte dei problemi dopo una copia nasce da qui. SCCM decide se un’app è presente o no sulla base della detection. Se copi l’app per una versione nuova ma lasci la stessa detection, il client può segnare l’installazione come già soddisfatta oppure, al contrario, tentare reinstallazioni inutili.

Un esempio concreto: hai un’applicazione che rileva la presenza di un file in `C:\Program Files\Vendor\App\app.exe`. La nuova variante installa però in una cartella diversa, oppure cambia nome del binario. La copia continuerà a “vedere” il vecchio criterio e il deployment fallirà in modo ambiguo: lato console sembra tutto corretto, lato client non lo è.

Stesso discorso per gli MSI. Se il package originario usa un Product Code e la nuova release ne ha uno diverso, la detection deve riflettere il nuovo codice. Se non lo fai, la console ti mostra un oggetto pulito, ma il client non trova corrispondenza e il deployment resta in stato non conforme.

Quando la copia va rifatta con un approccio più pulito

Ci sono casi in cui duplicare non è la scelta migliore. Se cambiano contemporaneamente installer, logica di detection, requisiti e contenuto, la copia ti fa risparmiare poco e ti espone a errori di eredità. In quel caso è meglio creare una nuova application e riusare solo la documentazione funzionale dell’oggetto originale.

Vale anche per gli ambienti con governance stretta. Se ogni application deve avere naming, versioning e lifecycle molto chiari, una copia senza disciplina genera oggetti quasi identici ma con differenze invisibili. Il risultato è un catalogo difficile da gestire, soprattutto quando devi capire quale app è realmente distribuita su quali collection.

Una buona soglia pratica è questa: se più del 30-40% dei campi devono essere modificati, probabilmente stai facendo un lavoro di creazione, non di copia. La duplicazione conviene quando la differenza è mirata e delimitata.

Distribuzione e test senza impattare gli utenti

Dopo aver validato la copia, il deployment va sempre fatto prima su una collection di test o pilot. Non usare direttamente una collection ampia solo perché l’app sembra identica all’originale. In SCCM il comportamento reale emerge solo quando il client scarica content, valuta detection e applica le regole locali.

Per un controllo rapido, verifica il lato client con i log di SCCM, in particolare quelli legati a policy, content download e application enforcement. I nomi possono variare in funzione della versione, ma il principio resta lo stesso: vuoi vedere che la nuova application venga valutata, scaricata e installata come previsto. Se il client si ferma prima, il problema non è quasi mai “la copia in sé”, ma una dipendenza o una detection incoerente.

Se la distribuzione è critica, fai un test su una macchina rappresentativa per sistema operativo, lingua e spazio disco. È un check più utile di una validazione solo in console, perché intercetta gli errori di requirement e i problemi di path prima che arrivino agli utenti.

Versioning, naming e manutenzione nel tempo

Una copia ben fatta non deve creare ambiguità fra le versioni. Usa un naming che faccia capire subito se l’oggetto è una variante, un pilot, una release maggiore o una build di test. Evita nomi generici come “Copy of…” o suffissi casuali: tra tre mesi non aiutano nessuno.

Se gestisci molte applicazioni, conviene adottare una convenzione minima: prodotto, variante, versione, ambiente. Per esempio, una distinzione netta fra produzione, pilot e test evita di distribuire per errore un oggetto copiato ma non ancora validato. In SCCM il vero problema non è creare il clone, è ricordarsi perché è stato creato e quale ciclo di vita deve seguire.

Questo vale ancora di più quando le application vengono aggiornate con supersedence. Se la copia rappresenta una nuova linea di rilascio, documenta il legame con l’originale e chiarisci se la vecchia app deve restare disponibile, essere ritirata o essere sostituita. Senza questa informazione, la manutenzione diventa un rebus al primo audit o al primo cambio di team.

Esempio operativo di controllo rapido

Un controllo essenziale, dopo la copia, è confrontare origine e destinazione lato console e lato client. Non serve uno script complesso: basta verificare che la nuova application abbia un deployment type coerente e che il contenuto sia stato distribuito al distribution point.

Console: Software Library > Application Management > Applications
Check: Deployment Types, Detection Method, Content Location, Requirements
Client log check: ApplicationModel.log / AppDiscovery.log / AppEnforce.log

Se il client non vede l’app nuova, il problema sta spesso in una di queste tre aree: content non distribuito, detection non valida, target collection errata. Se invece la vede ma non la installa, il punto è quasi sempre nei requirement o nei return code interpretati male.

Una regola che evita metà degli errori

Copiata l’app, il primo file da fidarsi non è la console: è la differenza tra ciò che l’oggetto dichiara e ciò che il client riesce davvero a installare.

È una regola semplice ma utile. SCCM è molto bravo a replicare oggetti; è molto meno indulgente quando la replica viene trattata come garanzia di correttezza. La copia ti dà velocità, non verità. La verità arriva solo da detection, log e test su un client reale.

Chiusura pratica

Duplicare un’applicazione in SCCM è un’operazione sensata quando vuoi risparmiare tempo senza perdere controllo. Funziona bene se mantieni un ordine preciso: copia, verifica dei deployment type, controllo del content, revisione delle regole, test su pilot, solo dopo eventuale estensione al resto delle collection. Se salti uno di questi passaggi, la copia smette di essere un aiuto e diventa una fonte di drift operativo.

In pratica, il criterio è questo: duplica per accelerare il lavoro, ma valida come se stessi pubblicando un oggetto nuovo. È il modo più pulito per evitare che una variazione apparentemente minima si trasformi in un problema distribuito su centinaia o migliaia di client.