Distribuire Dell SupportAssist con SCCM e ConfigMgr

Perché trattare SupportAssist come un pacchetto “vero” in ConfigMgr

Con Dell SupportAssist il punto non è soltanto “far partire l’installer”. In ambiente SCCM/ConfigMgr conta soprattutto ottenere un ciclo di distribuzione ripetibile: sorgente versionata, installazione silenziosa, detection coerente, raccolta dei log e possibilità di rollback senza rimettere mano a ogni client. Se il pacchetto viene trattato come un semplice eseguibile lanciato a mano, prima o poi emergono tre problemi classici: installazioni duplicate, rilevazione errata dello stato e update che si sovrappongono a versioni già presenti.

Per questo conviene ragionare come per qualsiasi software enterprise su Windows: prima si definisce il comportamento atteso, poi si prepara il contenuto, infine si costruisce la detection rule che separa in modo netto “installato” da “non installato”. Solo a quel punto ha senso spingere la distribuzione su collection pilota e, dopo verifica, allargare il raggio.

Obiettivo operativo e prerequisiti reali

L’obiettivo è distribuire Dell SupportAssist su postazioni Windows gestite da ConfigMgr, evitando interventi manuali sui client. Il caso d’uso tipico è il supporto remoto su hardware Dell: inventario, telemetria diagnostica, check di salute e, in alcuni scenari, integrazione con i driver e gli update Dell. La parte importante è distinguere SupportAssist dal resto dell’ecosistema Dell: il pacchetto può dipendere da componenti accessori, ma non bisogna confondere l’applicazione con strumenti diversi come Command | Update o i plugin per gestione driver.

Prima di creare il deployment verifica tre cose: versione desiderata, architettura supportata e metodo di installazione silenziosa. Questi tre elementi devono essere fissati prima del packaging, altrimenti ogni aggiornamento diventa una correzione manuale. Se Dell cambia nome al prodotto, prerequisiti o switch dell’installer, il pacchetto va aggiornato di conseguenza e la detection va ricontrollata.

Recupero del pacchetto e preparazione della sorgente

La fonte del software deve essere una share interna o un repository gestito, non un download “al volo” da ogni client. In pratica: scarica il file di installazione dal portale Dell, verifica hash e versione, poi copia tutto in una struttura stabile del contenuto SCCM. Se il pacchetto è un EXE autoestraente, conviene estrarre i file in una cartella di staging e documentare il comando di installazione reale, non quello apparente.

Una struttura ordinata aiuta sia il troubleshooting sia gli aggiornamenti successivi. Per esempio:

\SCCMSource\Applications\Dell\SupportAssist\1.0.0\
  \Source\
  \Install\
  \Logs\
  \Docs\

In Docs tieni note di versione, hash e parametri testati; in Logs conserva un log di installazione campione ottenuto in laboratorio. È un dettaglio banale solo finché non devi capire perché un client remoto risulta “Installed” ma l’app non c’è.

Installazione silenziosa: il punto che decide tutto

Il comando di installazione dipende dalla build del pacchetto Dell scaricato. Non esiste un singolo switch universale valido per ogni release, quindi il metodo corretto è aprire il file di documentazione del vendor o testare il pacchetto in una VM pulita con logging verboso. In genere, per un installer MSI si parte con una riga simile a questa:

msiexec /i "DellSupportAssist.msi" /qn /norestart /l*v "C:\Windows\Temp\SupportAssist-install.log"

Se invece il pacchetto è un EXE wrapper, bisogna usare i parametri supportati dal vendor. Il criterio non cambia: niente finestre, niente reboot forzato, log esplicito in una posizione nota. Il log è la tua prima prova tecnica, non un optional.

Durante il test iniziale controlla sempre tre segnali: exit code dell’installer, presenza dei file in Program Files e comparsa della chiave di uninstall nel registry. Se uno dei tre manca, non forzare il deployment di massa: la detection rule andrà in errore o, peggio, segnalerà un falso positivo.

Creazione dell’application in SCCM/ConfigMgr

In ConfigMgr conviene usare Application e non un vecchio package, salvo esigenze legacy. L’application ti consente detection method, supersedence e requirement rules in modo più pulito. Il flusso pratico è semplice: importi il contenuto, definisci il comando di installazione, costruisci la detection rule e distribuisci prima a una collection ristretta.

1. Apri la console di ConfigMgr e vai in Software Library → Applications.
2. Crea una nuova application e punta alla cartella sorgente preparata in precedenza.
3. Inserisci il comando di installazione silenziosa validato in laboratorio.
4. Definisci una detection rule basata su file, registry o MSI product code, in base a ciò che il pacchetto espone davvero.
5. Imposta almeno una requirement rule se vuoi limitare il deploy a sistemi Dell o a specifiche versioni di Windows.

La scelta della detection è il punto più delicato. Se il pacchetto è MSI, il ProductCode è spesso la strada più robusta. Se il vendor cambia ProductCode a ogni release, allora conviene un file versioned o una chiave di registro stabile. Evita detection basate su semplici stringhe di cartella se l’app aggiorna componenti in place: rischi di dichiarare installato qualcosa che in realtà è parzialmente fallito.

Un esempio di detection file-based può essere utile, ma va adattato alla versione reale installata. Se il binario principale è in una cartella standard, la detection può guardare presenza e versione del file. In questo caso verifica sempre il path esatto sul client di test, perché tra edizioni x86/x64 e release diverse il percorso può cambiare.

Detection rule: meglio una prova solida che un falso “Installed”

La detection rule deve rispondere a una domanda molto semplice: “posso affermare con certezza che SupportAssist è installato e nella versione attesa?”. Per farlo hai tre opzioni pratiche.

• MSI ProductCode: ottimo se la versione è stabile e il codice corrisponde al pacchetto distribuito.
• File/Version: utile quando il file principale è affidabile e la versione del binario è coerente con la release.
• Registry: valido se Dell scrive una chiave stabile sotto HKLM\Software o HKLM\Software\WOW6432Node.

In laboratorio, dopo l’installazione, controlla con un comando come questo quali chiavi sono state davvero create:

reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall" /s | findstr /i "Dell SupportAssist"

Se il prodotto compare solo sotto WOW6432Node, la detection deve puntare lì. Se il nome visualizzato cambia tra release, non basarti sul nome friendly: usa un identificatore più stabile. È il classico punto dove molti deploy falliscono in silenzio: il pacchetto è installato, ma ConfigMgr continua a proporlo perché la regola cerca una chiave sbagliata.

Distribuzione graduale: prima pilota, poi estensione

Non distribuire subito su tutta la base client. Parti con una collection pilota formata da pochi sistemi Dell rappresentativi: notebook recenti, workstation, almeno un client con policy standard e uno con antivirus/EDR più restrittivo. L’obiettivo è intercettare incompatibilità, problemi di reboot e blocchi applicativi prima di coinvolgere centinaia o migliaia di endpoint.

1. Crea una collection di test con 5-10 macchine reali.
2. Assegna il deployment in modalità required solo sulla collection pilota.
3. Monitora stato di installazione, exit code e log client-side.
4. Se il risultato è coerente, estendi a una collection più ampia ma sempre segmentata per tipologia di dispositivo.
5. Solo alla fine valuta una distribuzione più ampia o automatizzata tramite maintenance window.

Se SupportAssist è usato per flussi di assistenza interna, può avere senso limitare il deployment a device Dell effettivamente supportati. Distribuirlo su hardware non Dell non porta benefici e aumenta solo la superficie software da mantenere. Il filtro hardware può essere fatto con query WMI o con regole di raccolta basate su manufacturer e model.

Log da leggere quando qualcosa non torna

Quando il deployment fallisce, i log da guardare sono due: lato client e lato console. Sul client, ConfigMgr scrive normalmente in C:\Windows\CCM\Logs\; i file più utili sono AppEnforce.log, AppDiscovery.log e ExecMgr.log. Lì trovi comando eseguito, detection evaluation ed exit code reale dell’installer.

Un controllo rapido può essere questo:

Get-Content "C:\Windows\CCM\Logs\AppEnforce.log" -Tail 80

Se il log mostra exit code 0 ma la detection resta negativa, il problema è quasi sempre nella regola di rilevazione. Se invece il codice di uscita è diverso da zero, devi cercare il log dell’installer di Dell, che dovrebbe essere stato scritto nel path specificato durante il test. Senza quel log stai lavorando al buio.

Nel caso di errori di content download, verifica anche che il Distribution Point abbia ricevuto correttamente i file e che il Boundary Group del client sia corretto. Una parte sorprendente dei fallimenti “software non installato” in realtà è solo un problema di content non raggiungibile o non distribuito.

Rollback e gestione del cambio versione

Il rollback va pianificato prima del primo deploy, non dopo il primo problema. Se la release di SupportAssist introduce un bug o interferisce con un’altra utility, devi poter tornare indietro senza improvvisare. In ConfigMgr il metodo più ordinato è mantenere la versione precedente come application separata o come supersedence gestita con uninstall della versione nuova e reinstall della precedente, se il vendor lo supporta in modo pulito.

Prima di usare supersedence, verifica il comando di uninstall reale. Un esempio tipico, quando il prodotto è MSI, è questo:

msiexec /x "{PRODUCT-CODE}" /qn /norestart

Se il pacchetto non supporta un uninstall silenzioso affidabile, meglio trattare la release come un’installazione a sé e usare una strategia di sostituzione controllata. In altre parole: prima dismetti la nuova release sulla collection pilota, poi valuti il ritorno alla precedente. Non fare mai un rollback massivo senza aver testato il comportamento su un campione.

Hardening minimo e considerazioni operative

SupportAssist non va esposto o configurato con più privilegi del necessario. Il deployment in sé avviene con il contesto di sistema di ConfigMgr, ma l’applicazione non dovrebbe aprire servizi inutili o lasciare eccezioni firewall permanenti senza motivo. Se il prodotto richiama componenti cloud o servizi di diagnostica, va verificata l’aderenza alle policy aziendali e alla segmentazione di rete.

Dal punto di vista operativo, conviene anche raccogliere una metrica semplice: percentuale di installazioni riuscite, percentuale di detection corretta e numero di client che richiedono remediation manuale. Se il tasso di installazione è alto ma la detection è instabile, il problema è di confezionamento, non di distribuzione. Se invece la detection è corretta ma il prodotto non funziona, il problema è nella compatibilità del pacchetto o nei prerequisiti mancanti.

Sequenza consigliata in pratica

1. Scarica la release Dell e verifica hash, versione e architettura.
2. Testa l’installazione silenziosa su una VM pulita con log esplicito.
3. Individua file, registry o ProductCode affidabile per la detection.
4. Crea l’application in ConfigMgr usando la sorgente versionata.
5. Distribuisci a una collection pilota di sistemi Dell reali.
6. Leggi i log client-side e correggi detection o comando se serve.
7. Solo dopo il pilota estendi il deployment ad altre collection.

Questo approccio evita il classico errore di molti ambienti SCCM: si costruisce il deployment attorno all’installer invece che attorno al comportamento osservabile del client. Con SupportAssist, come con qualunque software di supporto vendor, la differenza tra un rollout pulito e una coda infinita di ticket sta quasi sempre nella qualità della detection e nella disciplina del pilot.

Assunzione: i client sono Windows 10/11 gestiti da ConfigMgr corrente e il pacchetto Dell disponibile è testabile in installazione silenziosa con log locale.