Guida semplice al deploy di VMware Workstation con SCCM

Distribuire VMware Workstation con SCCM si fa bene solo se si chiarisce subito un punto: non è un’operazione “clicca e via”, ma un deploy software che va trattato come un change controllato, con prerequisiti verificabili, detection affidabile e un piano di rollback se l’installazione fallisce su una parte del parco macchine.

In pratica, l’obiettivo non è solo copiare un installer sui client. Serve far arrivare la versione giusta, con parametri silenziosi coerenti, senza interrompere l’utente più del necessario e senza lasciare in giro installazioni parziali o stati ambigui. Se il pacchetto è costruito male, SCCM farà comunque il suo lavoro: distribuirà il problema su larga scala.

Quando ha senso usare SCCM per VMware Workstation

Ha senso quando devi standardizzare una versione su molte postazioni Windows, gestire aggiornamenti controllati oppure sostituire installazioni manuali fatte in momenti diversi. SCCM è utile anche per tenere traccia della compliance, cioè per sapere chi ha davvero installato la versione prevista e chi no.

Non è invece la strada migliore se devi distribuire a pochissimi utenti, se il software cambia spesso senza una policy chiara o se non hai modo di testare prima su un gruppo pilota. In quel caso rischi di trasformare un semplice deploy in un problema di supporto diffuso.

Prerequisiti da verificare prima del pacchetto

Prima di creare l’application in SCCM, conviene verificare tre cose: la versione esatta di VMware Workstation da distribuire, il tipo di licenza/attivazione previsto dalla tua organizzazione e i prerequisiti del sistema operativo client. Non tutti i contesti sono uguali, e la differenza spesso sta nei dettagli: diritti amministrativi, eventuali componenti già presenti, compatibilità con Hyper-V o con altri hypervisor installati sulla macchina.

Il punto operativo è semplice: devi sapere in anticipo se stai distribuendo un installer completo, un aggiornamento minore o un pacchetto che richiede trasformazioni particolari. Se questa parte non è chiara, il rischio è costruire una detection rule che funziona solo “quasi sempre”.

Pacchetto di installazione: struttura pulita e parametri silenziosi

Per il deploy, la regola migliore è tenere il contenuto del package ordinato e minimale. In genere conviene avere una cartella dedicata con l’eseguibile originale, eventuali file di risposta o script di pre-check, e un file di log destinato all’installazione. Evita di mischiare materiale di test e materiale di produzione: quando poi devi fare troubleshooting, ogni file superfluo complica il quadro.

Il comando esatto dipende dalla versione del prodotto e dal formato dell’installer che hai in mano. Qui non conviene inventare parametri universali: la cosa corretta è leggere la documentazione del vendor della build specifica e testare il silent install in una macchina di laboratorio. Quello che conta davvero per SCCM è avere un comando di installazione ripetibile, un exit code coerente e un log consultabile.

Un esempio di logica di lavoro, non di sintassi da copiare alla cieca, è questo: installer in silenzioso, log locale, controllo dell’esito tramite exit code e successiva verifica della presenza del binario o della chiave di uninstall. Se il pacchetto richiede privilegi elevati, va eseguito nel contesto corretto del sistema, non dell’utente standard.

Creazione dell’application in SCCM

In SCCM, la strada più lineare è creare una nuova application invece di un semplice package, perché ti dà detection method, supersedence, requisiti e controllo più preciso del ciclo di vita. Per VMware Workstation, questa scelta è quasi sempre preferibile quando vuoi mantenere ordine nel tempo.

Il flusso pratico è questo: importi il contenuto, definisci il comando di installazione, imposti il metodo di detection e poi associ il tutto a una collection di test. Il punto delicato è il detection method: deve dirti con precisione se il software è presente e nella versione corretta, non solo se “qualcosa di simile” esiste sul client.

Per la detection, in molti casi si usa uno di questi approcci: controllo della chiave di registry dell’applicazione, verifica della versione del file eseguibile principale oppure presenza di un MSI product code, se il pacchetto lo consente. Il metodo migliore è quello più stabile per la tua build, non quello più comodo da configurare al volo.

Detection method: come evitare falsi positivi

Il falso positivo classico è questo: SCCM considera installato il software perché trova un componente residuo, ma l’applicazione non è davvero operativa o non è nella versione prevista. Per evitare il problema, la detection dovrebbe essere specifica e, quando possibile, combinata: versione file più chiave di registro, oppure chiave di uninstall più versione attesa.

Se usi il registry, verifica il percorso reale con un client già installato e controlla che il valore di versione sia stabile tra reinstallazioni e aggiornamenti. Se usi il file version, assicurati che il file controllato sia quello che cambia davvero con gli upgrade. Se la detection è fragile, il deploy sembrerà riuscito ma il compliance report sarà poco credibile.

Un buon test è semplice: installi su una macchina pilota, poi disinstalli e reinstalli, e controlli che SCCM cambi stato in modo coerente in tutti e tre i passaggi. Se il risultato non è pulito, la detection va corretta prima di allargare il deployment.

Distribuzione su collection di test prima della produzione

La collection di test non è un optional. È il posto giusto per verificare installazione, tempi, impatto sul sistema e comportamento del client. Se salti questo passaggio, stai chiedendo ai primi utenti di fare da laboratorio, e quello in una community IT si paga in ticket e tempo perso.

Nel pilot group scegli macchine rappresentative: una con privilegi standard, una con profilo amministrativo, una con software di sicurezza più restrittivo e, se possibile, un sistema con configurazione hardware diversa. L’obiettivo è scoprire subito eventuali conflitti con driver, policy di protezione o componenti già presenti.

Se il prodotto richiede riavvio, valutalo in base alla finestra operativa. Non dare per scontato che un reboot sia innocuo: su una postazione usata per attività critiche, un riavvio fuori orario è già un impatto. In SCCM conviene esplicitare il comportamento atteso e documentarlo nel change.

Log da controllare quando qualcosa non torna

Quando il deploy fallisce, la prima cosa utile non è cambiare impostazioni a caso, ma leggere i log giusti. Sul client, i log di SCCM sono quelli che ti dicono se il content download è avvenuto, se il comando di installazione è partito e quale exit code ha restituito. Se il problema è nel contenuto, lo vedi lì quasi subito. Se il problema è nel comando, lo stesso principio vale: il log ti mostra il punto esatto in cui l’esecuzione si interrompe.

Per VMware Workstation, conviene tenere sotto osservazione anche il log dell’installer, se lo hai configurato. È spesso il modo più rapido per distinguere un problema di packaging da un problema del software stesso. Senza questo doppio livello di verifica, rischi di attribuire a SCCM un errore che in realtà nasce dall’installer.

Se il client mostra download completato ma installazione mancata, controlla anche i permessi sulla cartella di contenuto e la reachability del distribution point. Se invece il comando parte ma termina con errore, la priorità diventa leggere l’exit code e confrontarlo con la tabella prevista nella deployment type. È lì che si capisce se l’errore è gestito o no.

Rollback: come tornare indietro senza improvvisare

Il rollback va pensato prima del rilascio, non dopo il primo problema. Per un deploy di VMware Workstation, il piano minimo è semplice: disabilitare o ritirare la deployment, rimuovere l’application dalla collection interessata e, se necessario, forzare la disinstallazione controllata della versione appena distribuita. Se hai versioni precedenti in supersedence, verifica che il ritorno indietro sia realmente supportato dal ciclo che hai costruito.

Il blast radius dipende da come hai impostato la collection. Se è un pilot group piccolo, il raggio d’azione è limitato e il rollback è rapido. Se invece hai già puntato a una collection ampia, il danno potenziale cresce: più installazioni da annullare, più utenti da informare, più probabilità di ritrovarti con macchine in stato misto.

Prima di ritirare il deployment, conserva sempre una copia del pacchetto, della detection rule e dei parametri usati. Senza questi elementi, il rollback operativo c’è, ma poi diventa difficile capire perché il job ha fallito o quale variazione ha introdotto il problema.

Buone pratiche che evitano guai inutili

La prima buona pratica è banale ma decisiva: usa una naming convention chiara. Se nel console hai più versioni di VMware Workstation, il nome dell’application deve dire subito versione, architettura e stato. Il secondo punto è la tracciabilità: tieni nota di chi ha approvato il pacchetto, quando è stato testato e su quali client.

La terza regola è non sovrascrivere il contenuto senza controllo. Quando aggiorni l’application, meglio creare una nuova versione del pacchetto o una revisione documentata, così hai un riferimento preciso se qualcosa si rompe. Anche in SCCM, la storia del deploy conta quanto il deploy stesso.

Infine, non fidarti solo del “success” della console. Guarda sempre una macchina reale: applicazione visibile, versione corretta, avvio funzionante e nessun errore residuo nei log. Un deployment sano non è quello che passa in console, ma quello che resta sano sul client dopo il riavvio e l’uso normale.

Sequenza operativa consigliata

1. Prepara il contenuto in una cartella dedicata, con installer e log separati.
2. Verifica il silent install su una macchina di test e annota exit code e comportamento.
3. Crea l’application in SCCM con detection method affidabile e versionata.
4. Distribuisci prima a una collection pilota, non direttamente alla produzione.
5. Controlla client log, detection e avvio dell’applicazione prima di allargare il rilascio.
6. Solo dopo il pilot, estendi il deployment al resto del parco con finestra e rollback già definiti.

Assunzione operativa: il contesto è Windows con SCCM gestito in modo standard, VMware Workstation da distribuire in modalità silenziosa e produzione da trattare come ambiente a impatto potenziale sugli utenti.