Come distribuire GoodSync con SCCM e Configuration Manager

Distribuire GoodSync con SCCM / Microsoft Configuration Manager funziona bene quando lo tratti come un’applicazione enterprise normale: pacchetto ripetibile, installazione silenziosa, rilevamento affidabile e disinstallazione pulita. Il punto non è far partire il setup, ma evitare che ogni client si comporti in modo diverso per colpa di profili utente, permessi locali o parametri messi male nel comando di installazione.

Con GoodSync conviene separare subito due piani: installazione per macchina e configurazione per utente. SCCM è molto forte sul primo, molto meno sul secondo se il flusso non è progettato bene. Quindi il pacchetto deve installare il binario in modo prevedibile, mentre eventuali job, licenze o impostazioni personali vanno gestiti separatamente, senza infilare credenziali o dati sensibili dentro il deployment.

Che cosa deve fare davvero il deployment

Prima di creare la distribuzione, chiarisci l’obiettivo operativo. In un ambiente aziendale il deployment di GoodSync di solito serve a uno di questi scenari:

• installare il client su postazioni standardizzate;
• abilitare sincronizzazioni o backup locali con criteri uniformi;
• preparare endpoint gestiti senza esporre credenziali in chiaro;
• mantenere aggiornato il software con una disruption minima.

Se questi punti non sono chiari, il rischio è costruire un’app SCCM che risulta installata ma non è davvero pronta all’uso. L’errore classico è considerare sufficiente il setup e ignorare il fatto che l’applicazione può richiedere un primo avvio per utente, una licenza, oppure un file di configurazione in un percorso specifico.

Per un deployment serio, la domanda giusta è: cosa deve essere vero dopo l’installazione? Se la risposta è “l’eseguibile è presente”, il detection method sarà semplice. Se la risposta è “l’utente deve trovare già un profilo pronto”, allora serve un secondo componente, separato e controllato, perché SCCM non dovrebbe portarsi dietro logiche interattive o segreti in chiaro.

Scelta del formato: MSI, EXE o wrapper

La scelta del formato determina quasi tutto il resto. Se GoodSync è disponibile in MSI, il lavoro è più lineare: SCCM gestisce installazione, rilevamento e disinstallazione con meno attrito. Se il vendor distribuisce un EXE, spesso conviene usarlo comunque, ma solo dopo aver verificato parametri silent, exit code e comportamento in contesto sistema.

Il wrapper serve quando il setup non è abbastanza pulito per SCCM da solo. Ad esempio, puoi dover pre-creare directory, copiare file di configurazione, impostare un servizio o eseguire un post-install. In quel caso il pacchetto deve restare reversibile: se qualcosa fallisce, l’operatore deve poter capire rapidamente se il problema è nel setup, nel detection method o in una dipendenza esterna.

Se il vendor non documenta bene i parametri silent, non indovinare il comando definitivo: testa in laboratorio, osserva exit code, log del setup e stato finale del software. La differenza tra un deployment affidabile e uno fragile spesso è tutta lì.

Preparazione del pacchetto in SCCM

Il contenuto del source share deve essere minimale e ordinato. Evita cartelle piene di versioni mischiate o file temporanei. Un layout semplice aiuta sia il troubleshooting sia gli aggiornamenti futuri.

\SCCMSource\GoodSync\1.0.0\install.cmd
\SCCMSource\GoodSync\1.0.0\uninstall.cmd
\SCCMSource\GoodSync\1.0.0\GoodSync.msi
\SCCMSource\GoodSync\1.0.0\detection.txt
\SCCMSource\GoodSync\1.0.0\logs\

Se il pacchetto è un MSI, conserva anche il file originale e, se serve, un transform MST solo se hai davvero un motivo tecnico per usarlo. Non usare MST per comodità: se modifichi troppo il comportamento del setup, dopo qualche versione perdi il controllo della manutenzione.

In SCCM, crea l’applicazione e non un vecchio package se puoi evitarlo. L’Application Model ti dà detection method, supersedence, requirement rules e distribuzione più robusta. Il package classico ha ancora senso in casi semplici o legacy, ma per un client come GoodSync l’Application Model è quasi sempre la scelta più pulita.

Se devi distribuire a più sedi o con anelli diversi, separa il contenuto per versione e non sovrascrivere mai il source path di una release già pubblicata. Ti evita errori di content corruption e ti rende più semplice il rollback se una build si comporta male su un gruppo limitato di client.

Comando di installazione silenziosa

Il comando esatto dipende dalla build che stai distribuendo. Qui il punto non è inventare un parametro specifico non verificato, ma impostare un metodo di verifica corretto. Devi identificare il comando silent supportato dal vendor e provarlo localmente con gli stessi privilegi con cui SCCM eseguirà il processo, cioè tipicamente Local System.

Esempio di struttura, da adattare al setup reale:

setup.exe /quiet /norestart

Se il vendor usa un MSI, il pattern classico resta questo:

msiexec /i GoodSync.msi /qn /norestart

Per la disinstallazione, usa l’UninstallString rilevata dal sistema o l’MSI ProductCode, evitando scorciatoie manuali non ripetibili. In ambiente enterprise è meglio avere un comando di uninstall verificato che un comando “probabile” ma non documentato.

Quando testi il setup, controlla almeno tre cose: che non apra finestre, che restituisca un exit code coerente e che non richieda interazione al primo avvio. Se compare una UI anche minima, il deployment non è ancora pronto per SCCM.

Detection method affidabile

Il detection method è il punto che più spesso fa fallire un deployment apparentemente corretto. Se il rilevamento è fragile, SCCM continuerà a reinstallare l’app o a considerarla assente anche quando non lo è. Per GoodSync, la regola è usare un criterio semplice e stabile: file, versione, chiave di registro o ProductCode, a seconda del formato.

Se hai un MSI, il rilevamento tramite ProductCode è spesso la strada più pulita. Se invece distribuisci un EXE, puoi usare una chiave di registro o un file binario con versione verificabile. Evita detection basati su elementi che cambiano facilmente, come file di log o cartelle utente.

Un esempio pratico di check file è questo:

C:\Program Files\GoodSync\GoodSync.exe

Se usi la versione del file, assicurati che il criterio sia coerente con il ciclo di release. Un detection method troppo permissivo crea falsi positivi; uno troppo rigido crea falsi negativi e reinstallazioni inutili.

Per i casi più delicati, è utile aggiungere un controllo secondario sul registro o sul file di configurazione installato dal setup, ma senza trasformare il detection in un mini-script fragile. Più condizioni metti, più aumenti la probabilità di un falso KO su macchine sane.

Gestione della configurazione per utente

GoodSync può avere impostazioni o job legati al profilo dell’utente. Questo è il punto dove molti progetti si inceppano: SCCM installa il software, ma il profilo vero e proprio vive sotto l’utente loggato. Se provi a forzare tutto nel contesto sistema, rischi di creare file nel posto sbagliato o di esporre dati sensibili.

La soluzione pulita è separare il provisioning del client dal provisioning della configurazione. Il client si installa via SCCM. La configurazione per utente, se necessaria, va distribuita con un meccanismo dedicato: script in contesto utente, prima esecuzione controllata, task pianificato, oppure un profilo predefinito solo se il caso d’uso lo giustifica davvero.

Se devi distribuire impostazioni comuni, evita di mettere credenziali nel pacchetto. Meglio usare meccanismi aziendali per secret handling, come vault o account di servizio dedicati con privilegi minimi, e lasciare nel deployment solo riferimenti o placeholder. Un buon pacchetto non contiene segreti in chiaro, punto.

In pratica, il deployment dovrebbe rispondere a questa domanda: il client funziona da solo appena installato, oppure serve un secondo step per utente? Se serve il secondo step, documentalo chiaramente e trattalo come parte del design, non come un “dopo vediamo”.

Log, troubleshooting e primi controlli

Quando qualcosa non torna, non partire dal pacchetto: parti dall’evidenza. In SCCM controlla lo stato dell’applicazione e l’installazione sul client, poi verifica i log del setup e il comportamento del processo. Se il client è in produzione, considera sempre il possibile impatto su utenti e usa prima metodi osservabili, poi modifiche.

I controlli utili sono questi:

• stato applicazione in console SCCM;
• exit code del deployment sul client;
• log del setup generato dal vendor, se disponibile;
• presenza del file o della chiave usata per detection;
• eventuali errori in C:\Windows\CCM\Logs e nei log applicativi del software.

Se il problema è che l’installazione parte ma fallisce, cerca prima dipendenze mancanti, privilegi insufficienti o conflitti con una versione precedente. Se invece risulta installata ma non lo è, il colpevole è quasi sempre il detection method.

Per velocizzare l’analisi, fai sempre una prova locale con lo stesso comando usato da SCCM, poi confronta il risultato con quello ottenuto in contesto sistema. Molti setup si comportano in modo diverso quando non hanno un profilo utente interattivo.

Disinstallazione e rollback

La disinstallazione deve essere tanto affidabile quanto l’installazione. In SCCM non basta dire che l’app è installata: devi anche poterla rimuovere senza lasciare residui critici o rompere la configurazione di altri componenti. Se GoodSync è stato distribuito con un MSI, usa il comando di uninstall previsto dal pacchetto o il ProductCode. Se è stato distribuito con un EXE, verifica che il vendor esponga un uninstall silent coerente.

Per il rollback operativo, la regola è semplice: prima disabilita la distribuzione o la supersedence, poi ritira il contenuto se serve, e solo dopo valuta la rimozione dai client. In caso di problema grave, è meglio bloccare la nuova release che inseguire correzioni a caldo senza diagnosi.

Se hai distribuito anche configurazioni utente, il rollback deve coprire pure quelle. Altrimenti rischi di lasciare file o job parziali che interferiscono con la versione successiva. Per questo conviene sempre tenere separati binario e configurazione: il rollback del primo non dovrebbe distruggere il secondo, a meno che il progetto lo richieda esplicitamente.

Strategia consigliata per un rollout pulito

La sequenza che funziona meglio, nella pratica, è questa: laboratorio, pilot, anello ristretto, distribuzione ampia. Nel laboratorio validi silent install, detection e uninstall. Nel pilot osservi il comportamento reale su macchine standard e con utenti reali. Solo dopo allarghi il rilascio.

Se devi aggiornare una versione già presente, usa supersedence o una logica di sostituzione ben definita, invece di pubblicare app parallele indistinte. Il vantaggio è doppio: mantieni chiara la versione attiva e riduci il rischio di conflitto tra vecchi e nuovi pacchetti.

In sintesi, GoodSync con SCCM funziona bene quando il deployment è pensato come un processo controllato e non come una semplice copia di un installer. Il binario va installato in modo ripetibile, il rilevamento deve essere stabile, la configurazione per utente va separata e i segreti non devono mai finire nel pacchetto. Se tieni fermi questi quattro punti, il resto diventa manutenzione ordinaria.