Distribuire Silverlight con SCCM 2012 R2

Silverlight con SCCM 2012 R2: quando ha senso e quando no

Distribuire Silverlight oggi ha senso solo in ambienti che mantengono applicazioni legacy, portali interni o console web che dipendono ancora dal runtime. In SCCM 2012 R2 il punto non è “installarlo” e basta: il punto è trattarlo come componente applicativo con dipendenze, versioni precise e una finestra di supporto limitata. Se lo si gestisce come un normale software utente, si finisce rapidamente con installazioni incoerenti, riavvii non previsti e client che risultano “conformi” solo sulla carta.

La scelta corretta è quasi sempre questa: pacchetto locale, detection affidabile, targeting ristretto e distribuzione controllata. Silverlight non va spinto a tutta la base client se non c’è un requisito reale. In pratica, prima si verifica che l’applicazione che lo usa sia ancora necessaria, poi si prepara il deployment con rollback semplice e si limita il blast radius ai soli device coinvolti.

Il punto critico: non confondere runtime, browser e applicazione

Silverlight non è un browser plugin “generico” da distribuire per comodità. È un runtime che deve combaciare con il browser supportato dal contesto applicativo e con la versione richiesta dal vendor o dal team interno. Con SCCM 2012 R2 questo cambia parecchio il modo di lavorare: non basta importare un installer MSI o EXE, bisogna capire se il pacchetto è davvero silente, se lascia tracce di detection affidabili e se richiede un riavvio o una chiusura preventiva del browser.

Un errore tipico è distribuire Silverlight su client dove il browser usato dall’utente non lo sfrutta più, oppure dove la policy aziendale lo ha già disabilitato. In quel caso il deployment risulta tecnicamente riuscito, ma funzionalmente inutile. Il controllo utile non è “installer completato”, ma “l’applicazione legacy si apre e i controlli Silverlight vengono caricati senza warning”.

Pacchetto o Application: la scelta pratica in SCCM 2012 R2

In SCCM 2012 R2 la via più pulita è quasi sempre Application, non Package, perché hai detection method, requisiti e supersedence più gestibili. Il Package rimane una scorciatoia valida solo se hai un installer elementare e non ti serve vera compliance. Per Silverlight, però, l’Application è preferibile perché puoi verificare la presenza della versione esatta e impedire ridistribuzioni inutili.

Se il file è un MSI, la detection può appoggiarsi alla Product Code o a una chiave di registro ben definita. Se è un EXE, serve più attenzione: spesso bisogna usare la presenza del file binario, una chiave in registry o un file di versione. La detection deve essere stabile, altrimenti SCCM continuerà a reinstallare il runtime o a considerarlo assente.

Un criterio semplice: se riesci a descrivere la presenza del software con una prova oggettiva e ripetibile, hai una detection buona. Se devi “fidarti” del log di installazione, sei già in zona rischio.

Preparazione del media: quello che conviene verificare prima del deployment

Prima di creare l’application in console, conviene testare il pacchetto su una macchina pulita o su una VM di laboratorio. Il controllo minimo è questo: installazione silente, assenza di prompt, eventuale chiusura del browser e presenza del runtime nel sistema. Per non andare a tentoni, annota il comportamento dell’installer e conserva il log locale generato durante il test.

Se il pacchetto supporta il logging, usalo sempre. Un esempio tipico per installer basati su MSI è il log dettagliato su file locale. Per un EXE dipende dal vendor, ma spesso esistono parametri simili. Il punto non è avere il log “per archivio”, ma poter risalire subito a errori di prerequisito, versione incompatibile o reboot pendente.

msiexec /i Silverlight.msi /qn /norestart /l*v C:	emprowserplugin-install.log

Il comando sopra è un esempio di test locale: non va lanciato in massa senza aver verificato che il pacchetto sia davvero MSI e che i parametri siano supportati. Se il pacchetto non è MSI, il log va ottenuto con la sintassi prevista dal vendor.

Creazione dell’applicazione in SCCM 2012 R2

In console, il percorso operativo è quello classico di SCCM 2012 R2: Software Library → Application Management → Applications → Create Application. Da qui puoi importare il pacchetto o definire manualmente il deployment type. Se hai un installer semplice, l’import può velocizzare; se hai bisogno di controllo fine, conviene creare un deployment type personalizzato.

Il nome dell’applicazione deve essere esplicito e includere versione e architettura, se rilevanti. Per esempio, una nomenclatura del tipo “Microsoft Silverlight 5.x x86” evita ambiguità quando tra qualche mese dovrai capire se stai distribuendo la build corretta o una variante vecchia. In ambienti con più collection, la chiarezza del naming vale più di un commento nella descrizione.

Nel tab della detection, scegli la prova più robusta disponibile. Se c’è una chiave di registro, meglio usare quella. Se c’è un file versionato, controlla path e versione. Se usi il file system senza versione, rischi falsi positivi dopo una reinstallazione parziale.

Il punto non è fare qualcosa che “funzioni oggi”, ma qualcosa che resti leggibile e verificabile fra sei mesi, quando il problema sarà un client che non aggiorna più il runtime ma continua a risultare compliant.

Detection method: dove si fanno gli errori più costosi

Per Silverlight la detection sbagliata è il guasto più comune. Se imposti una chiave troppo generica, SCCM può considerare installata una versione diversa o incompleta. Se imposti un file path troppo fragile, una patch cumulativa o un aggiornamento del browser può spostare il risultato. La regola pratica è semplice: usa un identificatore che il runtime non cambia senza un vero upgrade.

Se l’installer crea una chiave di registro, verifica la presenza con un controllo manuale su una macchina già installata. Un esempio utile è ispezionare il ramo del registro relativo a Uninstall o alla specifica applicazione. L’obiettivo è trovare un campo stabile come DisplayVersion, DisplayName o ProductCode. Non basta che il software sia “visibile” nel pannello Programmi e funzionalità: serve un criterio che il client usi sempre allo stesso modo.

reg query