Distribuire Foxit PDF Editor con ConfigMgr

Se devi distribuire Foxit PDF Editor con ConfigMgr, la parte delicata non è copiare i file MSI o EXE nel package: è far convivere installazione, rilevamento, aggiornamenti e licenze senza lasciare la console piena di app “installed” che in realtà non lo sono. In pratica, il lavoro si gioca su tre punti: un installer ripetibile, una detection rule che non si rompa al primo update, e una strategia chiara per gli upgrade.

Qui conviene ragionare come su qualunque software desktop enterprise: prima standardizzi il comportamento dell’installer, poi lo impacchetti, infine decidi come vuoi mantenerlo nel tempo. Foxit non fa eccezione, ma ha abbastanza variabili da meritare un approccio ordinato.

Prima decisione: MSI, EXE o repackaging

Se hai a disposizione un MSI ufficiale, è quasi sempre la strada più pulita con ConfigMgr. Ti semplifica detection, repair, uninstall e upgrade. Se invece il vendor ti fornisce solo un EXE bootstrapper, puoi comunque distribuirlo, ma devi controllare bene i parametri silenziosi e verificare se l’EXE estrae un MSI interno o installa direttamente i componenti.

Il repackaging puro, cioè trasformare l’installazione in un pacchetto “catturato”, è la soluzione che eviterei salvo casi estremi. Funziona male sui prodotti che scrivono componenti in più punti del sistema, registrano servizi, aggiungono plugin o gestiscono attivazioni in modo non banale. Foxit, in un contesto enterprise, è più affidabile se lasci parlare il suo installer originale.

In sostanza: se hai MSI ufficiale, usa quello. Se hai solo EXE, verifica che supporti installazione silenziosa e che il comportamento sia stabile tra release. Se non lo è, fermati e cerca nel pacchetto un payload MSI o un canale enterprise del vendor, invece di costruire un pacchetto fragile.

Raccogliere i parametri reali dell’installer

Prima di creare l’app in ConfigMgr, esegui l’installer in lab e annota i parametri effettivi. Non fidarti del “/quiet” generico finché non hai verificato che il processo termini con exit code coerente e che il prodotto compaia davvero nel sistema con la stessa edizione prevista.

Una verifica utile è questa: estrai i comandi supportati o prova l’help del setup, poi lancia un’installazione silenziosa in una VM pulita. La parte importante non è solo installare, ma capire dove scrive il prodotto, quale versione registra, e come disinstalla.

setup.exe /?

Se il vendor non documenta bene i parametri, fai un test controllato e osserva i log locali del setup, il registro eventi applicazione e il comportamento del processo padre. Se l’installer genera un MSI secondario, cerca anche i log Windows Installer. Il punto è arrivare a un comando ripetibile, non a un tentativo “a mano” che poi non sai più riprodurre.

Struttura consigliata del package in ConfigMgr

Con ConfigMgr, tieni il contenuto del package semplice e prevedibile. Una cartella per la sorgente, una per i log di test, una per eventuali trasformazioni o file di risposta se davvero servono. Evita di mescolare installazione e configurazione utente nello stesso passaggio se puoi separarle.

Una struttura tipica è questa:

\SOURCES\Applications\FoxitPDFEditor\1.0.0\Source\setup.exe
\SOURCES\Applications\FoxitPDFEditor\1.0.0\Source\Transforms\custom.mst
\SOURCES\Applications\FoxitPDFEditor\1.0.0\Source\Scripts\install.cmd

Non è obbligatorio usare uno script wrapper, ma in molti ambienti è utile per normalizzare exit code, log path e parametri. Se il setup è già ben documentato, puoi puntare direttamente al comando di installazione nell’Application Model. Se invece hai dipendenze, prerequisiti o controlli preliminari, lo script wrapper ti evita di infilare troppa logica nel campo “Install program”.

Un dettaglio spesso trascurato: il content location deve essere stabile e accessibile dai Distribution Point senza ritardi strani. Se il pacchetto è pesante, verifica anche la distribuzione del contenuto prima di assegnare la deployment collection. Non c’è niente di peggio di un’app che risulta “available” ma fallisce perché il contenuto non è ancora arrivato ovunque.

Application Model: perché è preferibile al Package classico

Per Foxit PDF Editor, in genere conviene creare una Application e non un semplice Package/Program. L’Application Model ti dà detection rules, supersedence, requisiti e dipendenze. Per un software desktop che verrà aggiornato nel tempo, è il modo giusto di evitare installazioni duplicate o stati incoerenti.

Con una Application puoi definire una detection rule robusta basata su MSI ProductCode, se disponibile, oppure su file/versione o chiave di registro. Il ProductCode è la scelta più comoda quando il vendor mantiene una logica MSI pulita. Se cambia a ogni major release, va bene lo stesso: in quel caso userai supersedence per sostituire la vecchia versione con la nuova.

Se devi gestire più edizioni, per esempio standard e business, separa le Application. Mischiare SKU diverse in un solo contenitore porta quasi sempre a detection ambigue e a ticket inutili. Ogni edizione deve avere il suo comando di installazione, la sua detection e, se serve, la sua catena di upgrade.

Detection rule: la parte che evita il caos

La detection rule va pensata come una domanda secca: “come so, senza dubbio, che Foxit PDF Editor è presente e della versione giusta?”. Se la risposta è vaga, la console prima o poi ti presenterà un’app sempre non installata o sempre installata nel momento sbagliato.

La scelta migliore, quando possibile, è una detection MSI. Se il prodotto espone un ProductCode affidabile, ConfigMgr può verificare direttamente la presenza dell’installazione. Se invece il vendor cambia GUID o non usa MSI in modo pulito, passa a una detection per file versione o registro.

Un esempio pratico: controlla l’eseguibile principale nella cartella di installazione e verifica la versione file. Questo è utile quando il prodotto lascia un binario stabile e la versione file è allineata alla release. In alternativa, una chiave di registro sotto il ramo uninstall può essere più solida, purché il valore DisplayVersion sia coerente.

HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\{GUID}
DisplayVersion=xx.x.x.x

Evita detection basate solo sul nome della cartella o su file generici. “Esiste un exe” non basta: un aggiornamento parziale, un rollback fallito o una vecchia build lasciata sul disco possono ingannarti. La detection deve distinguere tra presenza del software e presenza della versione desiderata.

Comando di installazione e logging

Ogni distribuzione seria deve produrre un log leggibile. Senza log, stai lavorando al buio. Il comando va adattato al pacchetto reale, ma il principio è sempre lo stesso: installazione silenziosa, log persistente, exit code normalizzati.

Se il setup supporta MSI, il logging standard di Windows Installer è il punto di partenza. Se è un EXE con wrapper MSI, spesso conviene passare comunque un log file dedicato al bootstrapper e uno a MSI, così distingui il livello di errore.

msiexec /i FoxitPDFEditor.msi /qn /L*v C:	empoxit-install.log

Se lavori con un EXE, il pattern cambia ma la logica resta: silent mode, log path, exit code. In ConfigMgr, controlla sempre la tabella degli exit code e definisci come “success” quelli che il vendor usa per riavvio richiesto o installazione già presente, se documentati. Senza questo passaggio, rischi fallimenti falsi o retry inutili.

Un consiglio pratico: salva il log in una posizione temporanea locale durante il test, poi copia il contenuto nel sistema di raccolta log solo se necessario. In produzione, la priorità è che il log esista e sia leggibile; la priorità non è costruire un meccanismo elaborato per archiviarlo se non serve davvero.

Distribuzione delle licenze e profilo utente

Con Foxit devi capire subito come gestisce l’attivazione. Alcune edizioni usano licenza nominativa, altre chiavi aziendali, altre ancora attivazione online o server di licenze. Questo impatta direttamente la distribuzione, perché installare il software non significa averlo reso operativo per l’utente finale.

Qui la regola è semplice: non mettere segreti in chiaro dentro script, task sequence o commenti di configurazione. Se serve una chiave o un token, usa un meccanismo protetto, ruotalo quando possibile e redigilo nei log. Se il vendor richiede un file di licenza, trattalo come materiale sensibile e distribuiscilo solo dove serve.

Se la licenza si associa al primo avvio, valuta se il software deve essere disponibile per l’utente o installato in contesto macchina con configurazione post-installazione. Nei contesti VDI o terminal server questa distinzione conta molto: un’attivazione per utente può diventare ingestibile se la base utenti è ampia o se i profili sono effimeri.

In ambienti enterprise, conviene documentare anche il comportamento offline. Se il client non raggiunge il server di licenze, il software parte lo stesso? E per quanto tempo? Questo non è un dettaglio commerciale: è un requisito operativo che va verificato prima di aprire la deployment a una collection larga.

Supersedence e aggiornamenti senza sorprese

Per gli aggiornamenti, usa supersedence se il vendor rilascia nuove build con compatibilità lineare. È il modo più pulito per sostituire una vecchia versione con una nuova, conservando coerenza nella console e nei report. Se invece il vendor cambia struttura di installazione o edizione, potresti dover trattare l’upgrade come una nuova Application separata.

Prima di abilitare il supersedence in produzione, prova tre casi: installazione pulita, upgrade da versione precedente, reinstallazione sopra una build già presente. Devi capire se il setup esegue un in-place upgrade, se rimuove automaticamente la versione vecchia, e se lascia componenti residui. Questo è il punto in cui emergono i problemi peggiori, non durante la prima installazione.

Se il vendor pubblica patch o cumulative update, verifica se sono gestibili come deployment separati o se devono essere integrate nella stessa Application. La scelta dipende da come il pacchetto registra versione e stato. Un update che non modifica la detection può sembrare installato ma lasciare la console ferma alla versione vecchia.

Verifica in lab: cosa controllare davvero

La verifica in lab non deve limitarsi a “si apre il programma”. Serve controllare installazione, detection, uninstall, aggiornamento e comportamento con utente standard. Se Foxit parte solo con privilegi elevati o scrive in percorsi non accessibili, lo scopri subito qui e non quando hai già coinvolto cento endpoint.

Controlli minimi:

Se qualcosa non torna, non correggere al buio la detection per farla “passare”. Prima osserva cosa è cambiato davvero nel sistema: GUID, percorso file, versione, chiave uninstall, comportamento del servizio. Sistemare la detection per nascondere un’installazione difettosa ti crea solo un problema più grande al rollout successivo.

Disinstallazione e pulizia residui

La disinstallazione è la prova più utile per capire se il pacchetto è sano. Se il vendor supporta un uninstall silenzioso, testalo con la stessa cura dell’installazione. Se invece lascia residui in `AppData`, `ProgramData` o in chiavi utente, devi decidere se accettarli o pulirli con uno script separato e giustificato.

Attenzione però: la pulizia aggressiva è un cambio di stato con blast radius più alto dell’installazione. Se tocchi dati utente, cache o configurazioni personali, documenta il rollback e limita il raggio d’azione ai percorsi davvero appartenenti al software. Non cancellare profili o impostazioni condivise solo perché “sembrano vecchie”.

Per capire se l’uninstall è andata bene, verifica la scomparsa della detection, la rimozione della voce da “App installate” e l’assenza di processi residui. Se restano servizi o driver, fermati e identifica il componente prima di automatizzare la rimozione.

Errore comune: confondere installazione riuscita con deployment riuscito

In ConfigMgr un’app può risultare installata anche quando il contesto reale non è quello che ti aspetti. Per esempio: installazione in system, ma licenza o impostazioni salvate solo nel profilo utente; oppure versione corretta sul disco, ma detection che guarda il file sbagliato. Il risultato è un report rassicurante e utenti che aprono ticket.

Per questo conviene sempre separare tre domande: il software è stato installato? È rilevato correttamente? È utilizzabile dall’utente finale? Se una sola risposta è negativa, il deployment non è davvero risolto.

Un trucco semplice è testare con un account standard su una macchina appena ricevuta dal deployment, non con l’account amministrativo che ha fatto il push. È il modo più veloce per scovare problemi di permessi, associazione licenza e configurazioni per-user che la console non vede.

Schema operativo che funziona in pratica

Se vuoi un flusso senza fronzoli, usa questo approccio: prendi il pacchetto ufficiale, valida l’installazione silenziosa in lab, definisci una detection robusta, testa uninstall e upgrade, poi distribuisci a una collection pilota prima di andare larga. È un percorso banale, ma è quello che riduce davvero gli errori.

La distribuzione di Foxit PDF Editor con ConfigMgr non è complessa perché il software sia “difficile” in sé. Diventa complessa quando si salta la verifica dei dettagli operativi: parametri del setup, detection, licenza, upgrade e residui. Se mantieni questi cinque punti sotto controllo, il resto è routine da amministrazione endpoint.

La regola finale è sempre la stessa: prima osserva, poi impacchetta, poi automatizza. Se automatizzi un comportamento non compreso, ConfigMgr amplifica il problema invece di risolverlo.