Distribuire applicazioni di terze parti con SCCM

Distribuire applicazioni di terze parti con SCCM senza trasformare il deployment in un salto nel buio

Con SCCM il problema non è “installare un software”, ma renderlo ripetibile. Le applicazioni di terze parti funzionano bene quando il pacchetto è trattato come un oggetto controllato: sorgente nota, comando di installazione deterministico, criterio di rilevamento affidabile, requisiti chiari e rollback definito. Se manca uno di questi pezzi, il risultato tipico è sempre lo stesso: distribuzione apparentemente riuscita, ma client fuori stato, detection sbagliata o upgrade che si mangia la fiducia del catalogo applicativo.

La logica giusta è questa: SCCM non deve “capire” il prodotto, deve solo eseguire una procedura che tu hai reso prevedibile. Quando il vendor fornisce MSI, il lavoro è semplice. Quando fornisce EXE, script, prerequisiti sparsi o installazioni per utente, il margine di errore cresce e conviene compensarlo con packaging più rigoroso, test su una collection pilota e telemetria minima prima della diffusione ampia.

Classificare bene il caso prima di creare il pacchetto

Non tutte le applicazioni di terze parti si distribuiscono allo stesso modo. La prima decisione utile è capire che tipo di installazione stai gestendo.

• MSI puro: il caso migliore. Hai product code, proprietà MSI e spesso un uninstall coerente.
• EXE wrapper: spesso è un installer che chiama MSI o scompone componenti. Serve capire i parametri silenziosi reali.
• App con configurazione post-install: oltre all’installazione devi gestire file, registry, servizi o certificati.
• App per utente: il comportamento cambia in base al profilo loggato e al contesto di esecuzione.

Questa classificazione non è accademica. Determina come costruisci detection, uninstall e manutenzione successiva. Un MSI può essere rilevato in modo stabile sul registry o tramite product code. Un EXE richiede più disciplina: meglio se il vendor pubblica un silent switch documentato e un return code prevedibile. Le app per utente, invece, vanno valutate con attenzione perché una distribuzione “per device” può risultare formalmente riuscita ma sostanzialmente inutile.

Il pacchetto SCCM utile nasce fuori da SCCM

Il punto più sottovalutato è la preparazione della sorgente. Prima ancora di aprire la console, conviene mettere ordine in una struttura file stabile, ad esempio con sottocartelle separate per sorgente, script, log e documentazione del vendor. La regola pratica è semplice: se dopo sei mesi non riesci a capire perché quel pacchetto funziona, non è pronto per la produzione.

Una struttura minima ragionevole può essere questa:

\Source\AppName\1.2.3\
  setup.exe
  install.cmd
  uninstall.cmd
  detection-notes.txt
  vendor-release-notes.pdf

Il file `detection-notes.txt` è spesso più utile di quanto sembri. Serve a fissare in chiaro quale chiave registry, file, versione o servizio rappresenta lo stato “installato”. Questo evita il classico errore: pacchetto funzionante oggi, rotto al primo upgrade perché la detection era troppo generica o legata a un path che il vendor ha cambiato senza preavviso.

Application, non Package, nella maggior parte dei casi

In SCCM, quando hai una vera applicazione con requisiti, dipendenze, supersedence e compliance, il modello Application è quasi sempre preferibile al vecchio Package. Il package resta utile per casi semplici o script di supporto, ma appena entra in gioco il ciclo di vita del software, l’application model dà molto più controllo.

Con Application puoi gestire meglio:

• requisiti hardware e software;
• regole di detection;
• dipendenze tra componenti;
• supersedence per upgrade controllati;
• distribuzione per collection con enforcement più leggibile.

Il vantaggio reale non è estetico. È operativo. Se una release nuova deve sostituire la precedente, la supersedence evita di lasciare in giro versioni miste senza una logica centrale. Se invece usi package e script ad hoc, finisci presto con una collezione di eccezioni difficili da manutenere.

Silent install: il comando giusto conta più della console

Molti deployment falliscono non per SCCM, ma perché il comando di installazione non è stato verificato in locale. Prima di importare l’applicazione, il setup deve funzionare in modo silenzioso da prompt elevato, con output prevedibile e senza finestre interattive. Se il vendor non documenta bene i parametri, si lavora per prove controllate, ma sempre annotando il comando finale e i return code osservati.

Esempio tipico di wrapper CMD per MSI:

msiexec /i setup.msi /qn /norestart /l*v C:\Windows\Temp\AppName-install.log

Per un EXE, il concetto è lo stesso, ma la sintassi varia. Il punto non è imitare l’MSI: è ottenere un comportamento deterministico. Se l’installer produce un proprio log, meglio ancora. In assenza di log vendor, il minimo sindacale è redirigere l’output del wrapper e verificare i codici di ritorno supportati da SCCM.

Un errore comune è trattare tutti i return code diversi da zero come guasto. Alcuni installer usano codici particolari per reboot richiesto o successo con riavvio differito. Se non li mappi correttamente, SCCM può segnare come fallite installazioni che in realtà sono andate a buon fine ma richiedono una gestione esplicita del reboot.

Detection method: qui si vince o si perde tutto

La detection è il cuore della distribuzione. Se è troppo debole, SCCM considera installata un’app che non c’è. Se è troppo rigida, considera assente un’app correttamente presente. La regola pratica è usare un indicatore che il vendor cambi solo quando cambia davvero lo stato del software.

Le opzioni più solide sono queste:

1. Product code MSI, quando il vendor lo mantiene coerente per la stessa versione.
2. Registry key/value con versione o build, se il prodotto scrive un dato stabile in `HKLM`.
3. File version su un binario principale, quando il path è affidabile e non cambia a ogni patch.
4. Servizio Windows, solo se il servizio rappresenta davvero il prodotto e non un componente accessorio.

In ambienti reali spesso la detection migliore è una combinazione: file + versione, oppure registry + chiave di configurazione. Questo riduce i falsi positivi. Per esempio, un file può esistere anche dopo un uninstall fallito, mentre una chiave registry può restare se il vendor lascia residui. Per questo conviene verificare ciò che il software lascia davvero sul sistema dopo installazione e rimozione, non ciò che promette la documentazione.

Se la tua app ha più edizioni o architetture, la detection deve distinguere chiaramente x86 e x64, oppure branch diversi di configurazione. Una detection ambigua crea collisioni tra versioni e complica le supersedence. È uno dei motivi per cui un test di upgrade è obbligatorio prima della distribuzione larga.

Requisiti, dipendenze e supersedence: il trio che evita i ticket inutili

Molti software di terze parti non falliscono per il loro installer, ma per l’ambiente in cui arrivano. Un prerequisito mancante, una versione di .NET non allineata, un VC++ runtime assente o un certificato non distribuito nel posto giusto bastano a trasformare un deployment formalmente corretto in un ticket di secondo livello.

Le dipendenze in SCCM servono a dichiarare che un’app non vive da sola. È meglio esplicitarle, anche quando il setup sembra “autonomo”. In pratica, conviene costruire una catena ordinata: prerequisito di base, runtime, libreria comune, applicazione finale. Questo aiuta anche il supporto, perché separa i problemi di infrastruttura da quelli dell’applicazione.

La supersedence è il passaggio che fa la differenza tra manutenzione e accumulo. Se devi sostituire una versione con un’altra, definisci chiaramente se la vecchia va disinstallata o solo resa non più applicabile. In alcuni casi la coesistenza è accettabile; in altri, lasciarla in giro crea conflitti di associazione file, plugin duplicati o servizi sovrapposti.

Collection pilot: il punto giusto per trovare il problema prima degli utenti

Una distribuzione seria non parte mai da “All Systems”. Si parte da una collection pilota con macchine rappresentative: una configurazione pulita, una sporca, una con profilo utente standard, una con privilegi elevati, una con software confliggenti già presenti. Se il pacchetto regge lì, hai già ridotto molto il rischio.

Nel pilot non guardare solo l’esito “Success” in console. Controlla anche:

• presenza dei file installati nel path atteso;
• chiavi registry create o aggiornate;
• servizi avviati con il corretto account;
• log dell’installer nel path previsto;
• tempo di installazione e bisogno di reboot.

Se il deployment fallisce sul pilot, la domanda giusta non è “SCCM non funziona?”, ma “qual è il punto esatto della catena che si rompe?”. Senza questa distinzione, si finisce a correggere il contenitore invece del contenuto.

Log e osservabilità: sapere dove guardare fa risparmiare ore

Quando qualcosa non torna, i log da controllare sono quelli del client SCCM e quelli dell’installer. In genere, il client scrive sotto `C:\Windows\CCM\Logs\`, mentre il comportamento dell’app dipende dal packaging e dal vendor. I file più utili cambiano in base al flusso, ma il principio è sempre lo stesso: prima si verifica il motivo del fallimento, poi si tocca la distribuzione.

Il vantaggio di avere un log di installazione esplicito è enorme. Ti permette di distinguere tra:

• errore di download del contenuto;
• errore del comando silenzioso;
• blocco per prerequisito mancante;
• problema di detection;
• reboot in attesa.

Se manca il log, il gap va chiuso subito nel wrapper, non “più avanti”. Un pacchetto senza telemetria minima è difficile da supportare anche quando sembra semplice.

Rollback: non è un optional, è parte della distribuzione

Ogni applicazione di terze parti dovrebbe avere almeno una strategia di ritorno. A volte è un uninstall MSI standard. A volte è uno script che rimuove file, servizi e chiavi residue. A volte il rollback completo non è realistico, ma allora va dichiarato chiaramente e il change va trattato come potenzialmente invasivo.

Prima di distribuire in massa, verifica almeno questo:

1. il comando di uninstall funziona in silenzioso;
2. la detection torna “not installed” dopo la rimozione;
3. non restano servizi orfani o processi appesi;
4. il rollback non rompe dipendenze condivise con altre app.

Se l’app modifica file di configurazione, conserva una copia del diff o un backup del file prima del deployment. Non serve fare versioning completo del mondo, ma almeno i file toccati devono essere reversibili. È una misura banale che evita ore di ricostruzione quando il vendor cambia un default e l’app si comporta in modo inatteso.

Un flusso operativo che regge in produzione

Un flusso sano per distribuire app di terze parti con SCCM può essere riassunto così: verifica il silenzioso fuori da SCCM, definisci detection e rollback, crea l’application, aggiungi eventuali requisiti, distribuisci su una collection pilota, controlla log e stato reale, poi allarghi la diffusione. È un percorso meno spettacolare di una pubblicazione “rapida”, ma molto più difendibile quando qualcosa si rompe.

In pratica, il successo non dipende dalla console ma dalla disciplina del pacchetto. SCCM è un orchestratore: se gli dai istruzioni chiare, distribuisce bene; se gli dai ambiguità, le amplifica. Per questo le installazioni di terze parti vanno trattate come un piccolo prodotto interno, con naming coerente, log, criteri di detection e una strategia di rollback che non lasci il supporto a inseguire sintomi casuali.

Assunzione operativa: qui si considera un ambiente Windows enterprise con SCCM/MECM, client healthy e accesso amministrativo ai pacchetti e alle collection di test.