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:\temp\browserplugin-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 funziona 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 "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" /s /f Silverlight

Se il risultato mostra più chiavi, non scegliere quella che “sembra giusta” solo perché contiene il nome atteso: confronta DisplayVersion, Publisher e il ProductCode con il file di installazione testato in laboratorio. Se la versione non coincide, la detection va stretta.

Targeting: la parte che evita di trasformare un fix in un incidente

Silverlight va distribuito solo ai device che ne hanno davvero bisogno. In SCCM 2012 R2 questo significa collection dedicate, membership chiara e, se possibile, esclusioni esplicite per i sistemi dove il runtime non serve. La tentazione di usare una collection ampia “per stare tranquilli” produce l’effetto opposto: più client coinvolti, più stato da inseguire, più ticket per installazioni percepite come inutili.

Il targeting corretto si basa su un requisito applicativo, non su una categoria generica di utenti. Se l’applicazione legacy è usata solo da un reparto o da una funzione specifica, la collection deve riflettere quel perimetro. Se il requisito è temporaneo, conviene usare una collection con scadenza o un processo di rimozione pianificata, così non lasci il runtime installato più del necessario.

Prima del deployment, verifica sempre quale client finirà nel scope reale. Una query WQL troppo larga o una membership rule non aggiornata può includere macchine di test, kiosk, server gestiti come desktop o postazioni che non dovrebbero vedere il runtime. In un ambiente serio, il targeting è parte del controllo di rischio, non un dettaglio amministrativo.

Dipendenze, prerequisiti e compatibilità

Silverlight non vive da solo: dipende dal contesto di navigazione, dalla versione del sistema operativo, dal browser e in alcuni casi da policy locali o restrizioni di sicurezza. In SCCM conviene modellare questi aspetti come requisiti dell’application, non come supposizioni operative. Se una postazione non rispetta il prerequisito, meglio escluderla prima che fallisca in fase di installazione.

Se il deployment richiede un browser specifico, un plugin abilitato o una configurazione di sicurezza coerente, documentalo nell’application e nel piano di rollout. Non è raro che il runtime sia presente ma l’applicazione continui a non funzionare perché il browser corretto non viene usato, o perché una policy blocca l’esecuzione del contenuto. In quel caso la remediation non è reinstallare Silverlight, ma correggere il contesto applicativo.

Quando possibile, separa il problema “runtime installato” dal problema “applicazione funzionante”. Il primo si risolve con SCCM; il secondo spesso richiede test funzionali con l’app legacy, perché la compatibilità reale dipende da fattori che il solo inventario software non vede.

Distribuzione controllata: pilot, monitoring e rollback

Il modo corretto di distribuire Silverlight è partire da un pilot ristretto. Una prima collection piccola, composta da macchine rappresentative, ti dice subito se la detection è affidabile, se il comando silente è corretto e se ci sono effetti collaterali sul browser o sull’esperienza utente. Solo dopo il pilot si allarga il deployment.

Durante il monitoraggio guarda tre cose: esito dell’installazione, coerenza della detection e funzionalità dell’applicazione che dipende dal runtime. Se una di queste tre non torna, fermati prima di estendere il rollout. In un deployment legacy, il successo apparente è spesso più pericoloso del fallimento esplicito, perché ti fa credere che tutto sia a posto mentre il business process continua a non funzionare.

Il rollback deve essere semplice: se il runtime rompe un’app o crea un conflitto, devi poterlo rimuovere con lo stesso livello di controllo con cui lo hai distribuito. Conserva il comando di uninstall, il log del deployment e la lista delle collection coinvolte. Se hai usato una supersedence o una versione più recente del pacchetto, verifica prima in lab che la rimozione non lasci residui.

msiexec /x {PRODUCT-CODE-QUI} /qn /norestart /l*v C:\temp\browserplugin-uninstall.log

Prima di eseguire un rollback, conferma che il Product Code sia quello del pacchetto effettivamente distribuito nel pilot. Se il deployment è stato fatto con un EXE, il comando di rimozione deve essere quello previsto dal vendor o dal pacchetto stesso.

Verifiche post-deployment: non fermarti al verde della console

Il controllo finale non è solo il report di SCCM. Dopo la distribuzione, verifica su un campione di client che il runtime sia presente, che la versione sia quella attesa e che l’applicazione legacy si apra davvero. Se il software è installato ma l’utente continua a vedere errori, il problema è nella catena applicativa e non nel deployment in sé.

Un controllo utile è confrontare il dato di inventario con il risultato di una prova funzionale. Se SCCM dice “success” ma il browser mostra ancora un blocco o un warning, allora la detection è corretta solo a metà o il requisito applicativo è incompleto. In questa situazione, correggere il pacchetto senza capire il contesto porta quasi sempre a un secondo giro di incidenti.

Conserva sempre una nota operativa con versione, data di distribuzione, collection coinvolte e eventuale eccezione. Quando Silverlight entra in gioco, la manutenzione ordinaria vale più dell’installazione iniziale: il rischio vero è dimenticare dove e perché lo hai distribuito.

Quando conviene smettere di distribuirlo

Se l’applicazione che dipende da Silverlight è stata sostituita, il runtime va rimosso dal perimetro il prima possibile. Continuare a distribuirlo “per sicurezza” aumenta superficie d’attacco, complessità di supporto e possibilità di conflitto con browser o policy più recenti. In un ambiente maturo, il deployment di componenti legacy deve avere una data di fine vita, non solo una data di inizio.

Prima di dismetterlo, verifica che non esistano più collezioni attive, task sequence o application dipendenti. Poi pianifica la rimozione in modo graduale, partendo dai device pilota e monitorando i ticket aperti. Se emerge che una funzione critica lo usa ancora, il problema non è tecnico ma di governance applicativa: significa che qualcuno sta mantenendo un requisito non più documentato.

La regola pratica è semplice: Silverlight si distribuisce solo finché esiste un’applicazione che lo richiede davvero e solo nel perimetro necessario. Appena il requisito sparisce, il runtime va trattato come un residuo tecnico da ritirare, non come un componente da lasciare in giro.

Sintesi operativa

Con SCCM 2012 R2, Silverlight va gestito come application legacy con detection robusta, targeting stretto e test funzionali prima del rollout. Il valore non sta nel “far partire l’installer”, ma nel mantenere coerenza tra inventario, requisito applicativo e stato reale delle postazioni. Se questa catena è chiara, il deployment resta controllabile; se non lo è, il runtime diventa solo un altro oggetto da inseguire in console.

Assunzione: il pacchetto Silverlight è richiesto da una web application legacy ancora in uso e distribuito su client Windows gestiti da SCCM 2012 R2.