Distribuire Cisco Webex App con SCCM e ConfigMgr

Distribuire Cisco Webex App con SCCM e ConfigMgr senza incastrarsi tra MSI, update e detection

Se devi portare Cisco Webex App su una flotta Windows gestita con SCCM/ConfigMgr, il punto non è “far partire l’installer”. Il punto è farlo restare gestibile: detection affidabile, installazione silenziosa, aggiornamenti prevedibili e una logica chiara per il rollback. Webex è un caso abbastanza tipico: il pacchetto è semplice solo in apparenza, ma se sbagli il metodo di detection o confondi il canale di update ti ritrovi con client che sembrano installati e non lo sono, oppure con deployment che tornano sempre in retry.

Il criterio giusto è trattarlo come un software di produttività con ciclo di vita proprio, non come un MSI qualsiasi da “pubblicare e basta”. In pratica: prima definisci come riconoscerne la presenza, poi scegli se distribuire l’exe bootstrap o un pacchetto estratto, infine decidi dove vuoi che avvenga l’aggiornamento. Se non chiarisci questi tre punti all’inizio, il troubleshooting dopo diventa inutilemente lungo.

Scelta del pacchetto: EXE, MSI o contenuto estratto

Per Webex App, nella pratica amministrativa hai tre strade. La prima è usare l’installer ufficiale eseguibile, che è la soluzione più lineare quando vuoi restare vicino al supporto del vendor. La seconda è cercare un MSI, quando disponibile per il canale o per una specifica esigenza di packaging. La terza è estrarre il contenuto e costruire un deployment più controllato, ma ha senso solo se sai esattamente cosa stai facendo e perché.

Per un ambiente SCCM standard, la scelta più robusta è di solito l’EXE ufficiale in modalità silenziosa, con detection basata su versione o su file/registro. È meno elegante di un MSI puro, ma è spesso più aderente al comportamento reale del prodotto. L’errore classico è basarsi solo sul successo del comando di installazione: SCCM deve capire se il client è davvero presente, non solo se il bootstrap ha restituito exit code 0.

Prerequisiti che conviene verificare prima del deployment

Prima di creare l’applicazione in ConfigMgr, conviene mettere in ordine alcuni aspetti che poi fanno la differenza in produzione. Il primo è la connettività verso i repository Cisco e i canali di update, soprattutto se i client escono tramite proxy o TLS inspection. Il secondo è il contesto utente: Webex può installarsi in modo per-user o per-machine a seconda del pacchetto e delle opzioni, quindi non dare per scontato dove finiranno file e chiavi di registro. Il terzo è la gestione di eventuali installazioni precedenti: se hai vecchie versioni o canali differenti, la detection va pensata per evitare falsi positivi.

Inoltre, su macchine con profili aggressivi di hardening, conviene controllare che il profilo non blocchi componenti di aggiornamento, esecuzione da cartelle utente o scrittura nelle aree local app data. Non è un problema “di SCCM” in senso stretto, ma è lì che poi si rompe il deployment: l’installazione termina, il client parte una volta, e al primo update non riesce più a mantenersi.

Struttura consigliata dell’applicazione in ConfigMgr

In ConfigMgr conviene usare un’applicazione, non un package legacy, salvo casi particolari. L’applicazione ti dà detection method, supersedence, requisiti, dipendenze e reporting più utili. Per Webex il pattern più pulito è: una singola deployment type per il sistema operativo supportato, installazione silenziosa, detection basata su chiave di registro o file version, e supersedence per gestire il passaggio tra release.

Il nome dell’applicazione deve essere operativo, non creativo. Un esempio sensato è Cisco Webex App x64, con la versione nel dettaglio della deployment type o nei metadati. In questo modo i report rimangono leggibili e, quando fai supersedence, capisci subito quale canale sta sostituendo quale. Se lavori in ambienti multi-lingua o multi-tenant, aggiungi anche il canale o il tipo di distribuzione, così non confondi il pacchetto corporate con eventuali installazioni manuali degli utenti.

Comando di installazione e logica di silent install

Il comando preciso dipende dal pacchetto rilasciato da Cisco, quindi qui non conviene inventare parametri a memoria. La regola operativa è semplice: usa la sintassi supportata dal pacchetto ufficiale e verifica sempre l’exit code documentato nel file di release o nella guida del vendor. Se il pacchetto è un EXE bootstrap, fai attenzione ai parametri di installazione silenziosa e al comportamento del riavvio. Se è un MSI, la logica cambia e puoi appoggiarti ai classici switch di Windows Installer.

In SCCM, l’install command va testato prima in locale e poi con il contesto del sistema, perché molti installer si comportano diversamente quando non girano sotto l’utente interattivo. Un controllo minimo utile è avviare il comando da una sessione amministrativa, osservare il log di installazione temporaneo e verificare che il processo non dipenda da credenziali utente o da finestre GUI invisibili. Se compare un prompt, hai già trovato il problema: l’installazione non è davvero silenziosa.

Un pattern pratico è separare sempre installazione e aggiornamento. Se il pacchetto installa il core client ma gli update vengono poi gestiti dal meccanismo interno dell’applicazione, documentalo chiaramente. Se invece vuoi che sia SCCM a governare il ciclo di vita completo, devi disabilitare o limitare il self-update secondo le opzioni del vendor, altrimenti il client si aggiorna per conto proprio e il tuo stato di compliance perde senso.

Detection method: la parte che decide se tutto funziona

La detection è il vero centro del lavoro. Per Webex, il metodo più affidabile è in genere la combinazione di chiave di registro e versione del file eseguibile, perché ti permette di distinguere una presenza reale da un residuo parziale. Se usi solo una directory esistente, rischi di scambiare file lasciati da una installazione incompleta per un’installazione valida. Se usi solo il nome del processo, il client può essere presente ma non attivo, e SCCM lo considererà comunque assente.

La regola è: scegli un indicatore che cambi solo quando il software è davvero installato. Se il vendor scrive una chiave di registro stabile, quella è spesso la migliore. Se invece la struttura è fragile o cambia tra release, allora punta alla versione del file principale o a un manifest affidabile. Il test da fare è banale ma decisivo: installi, verifichi detection, disinstalli, verifichi che la detection torni negativa. Se non passi entrambe le prove, la detection è sbagliata.

In ambiente ConfigMgr, questo si traduce anche in report più puliti. Un’app con detection errata ti genera stati di compliance falsati, remediation inutili e ticket di utenti che vedono il software presente ma il deployment continua a proporlo. Non è un problema estetico: è rumore operativo che consuma tempo sul lato helpdesk e sul lato packaging.

Supersedence e aggiornamenti: come evitare conflitti tra versioni

Con Webex l’aggiornamento è il punto in cui molti ambienti si inceppano. Se pubblichi una nuova versione senza pianificare la supersedence, puoi ritrovarti con più release presenti, detection ambigua o client che si autoaggiornano in un momento diverso da quello che hai previsto. La supersedence in ConfigMgr serve proprio a dire quale versione sostituisce la precedente e con quale comportamento.

La scelta pratica è tra due modelli. Nel primo, lasci che SCCM distribuisca la nuova versione e, quando possibile, rimuova la precedente. Nel secondo, usi SCCM per il primo deploy e poi lasci il self-update del prodotto entro una finestra controllata. Il primo è più coerente in ambienti molto governati; il secondo è più leggero, ma richiede disciplina sulla telemetria e una policy chiara su quando l’utente può ricevere la nuova build.

Se hai una baseline di sicurezza o un anello pilota, usa gruppi di test piccoli e osserva il comportamento per almeno un ciclo di aggiornamento. Il segnale da controllare non è solo “si installa”, ma anche “resta nella versione attesa dopo riavvio, logoff e riapertura”. In altre parole, la vera verifica è la persistenza dello stato, non il primo avvio.

Distribuzione: collection, maintenance window e impatto sugli utenti

La collection di destinazione non va scelta per comodità, ma per rischio. Se distribuisci a tutta l’azienda senza una finestra di manutenzione, stai implicitamente accettando che l’installazione parta quando capita. Per Webex questo può essere accettabile se il pacchetto è davvero innocuo e non richiede riavvio, ma devi comunque considerare il carico sul link e la possibilità di collisione con altre installazioni software.

Una pratica prudente è pilotare su un gruppo IT o su un reparto con utenti noti e macchine rappresentative. Poi estendi per anelli. Questo non serve solo a scoprire bug del pacchetto, ma anche a verificare se i dispositivi gestiti hanno policy, proxy o restrizioni che alterano il comportamento del client. Un deployment che passa in laboratorio e fallisce in sede remota non è raro; è il motivo per cui l’anello pilota esiste.

Log utili quando il deployment fallisce

Quando qualcosa non torna, la diagnosi va fatta sui log giusti. Dal lato SCCM, i riferimenti classici sono i log del client sotto `C:\Windows\CCM\Logs\`, in particolare quelli legati a `AppEnforce.log`, `AppDiscovery.log` e `CAS.log` a seconda del punto di rottura. Dal lato installazione dell’app, cerca il log generato dal pacchetto o dal bootstrap, spesso in `%TEMP%`, `%LOCALAPPDATA%` o nella cartella prevista dal vendor. Se il log non esiste, è già un indizio: il comando non sta partendo nel contesto che pensi.

Il pattern di lettura è semplice. Se `AppEnforce.log` mostra exit code corretto ma la detection resta negativa, il problema è quasi certamente nella regola di detection. Se l’installer termina con codice di errore, il problema è nel comando, nei prerequisiti o nei permessi. Se l’installazione va a buon fine ma il client poi non si avvia, guarda policy locali, antivirus, proxy o restrizioni sull’esecuzione. Non saltare subito alla reinstallazione: prima identifica il layer che si è rotto.

Disinstallazione e rollback: non lasciare il client in mezzo

Ogni deployment serio ha un piano di ritorno. Per Webex questo significa sapere come rimuovere il client in modo pulito e come impedire che una versione nuova venga subito ridistribuita mentre stai investigando. Il rollback non è solo uninstall: è anche sospensione della deployment, eventuale supersedence invertita e pulizia di eventuali residui che interferiscono con la detection.

Prima di toccare la configurazione, conserva una copia della deployment type e annota i parametri effettivi usati in produzione. Se il pacchetto cambia comportamento tra release, avere lo storico del comando e della detection ti evita di andare a tentativi. In caso di problema diffuso, la mitigazione più rapida è spesso mettere in pausa la distribuzione e fermare l’espansione del guasto, non cercare subito il fix definitivo.

Checklist operativa che evita il 90% degli errori

Prima di promuovere l’applicazione in produzione, conviene passare una checklist breve ma rigorosa. Il pacchetto si installa in silent mode senza interazione? La detection torna positiva solo quando il software è davvero presente? La disinstallazione pulisce abbastanza da far tornare la detection negativa? Le versioni precedenti vengono sostituite o gestite in modo esplicito? Il client resta funzionante dopo reboot e logon?

Se tutte le risposte sono sì, il deployment è probabilmente pronto. Se una sola è incerta, non hai un problema di SCCM in senso stretto: hai un problema di packaging o di comportamento del vendor. In quel caso la soluzione giusta è tornare alla documentazione del pacchetto, verificare i log e rifinire detection e supersedence. È lavoro noioso, ma è quello che separa una distribuzione stabile da una che produce ticket ogni lunedì mattina.

Quando conviene fermarsi e chiedere un dato in più

Ci sono casi in cui non conviene andare a memoria, soprattutto se ti manca il formato esatto del pacchetto Cisco che devi distribuire. Se non hai il nome preciso del file, la versione, il canale o il tipo di installer, la procedura va adattata e non indovinata. In quel caso la chiusura corretta è semplice: recupera il pacchetto effettivo, apri le note di rilascio, verifica i parametri supportati e testa in un gruppo pilota ristretto prima della diffusione ampia.

In sintesi, distribuire Cisco Webex App con SCCM e ConfigMgr funziona bene quando tratti il problema come un ciclo completo: packaging, detection, update, reporting e rollback. Se uno di questi pezzi manca, il deployment resta fragile. Se li governi tutti e cinque, invece, il client diventa una normale applicazione gestita, non una fonte continua di eccezioni.