Come configurare il logo delle notifiche in Software Center SCCM

Il logo del Software Center in SCCM non si cambia dentro il deployment dell’applicazione: si cambia nel branding del client. Questo è il punto che evita metà dei fraintendimenti operativi. Se vuoi che l’utente veda il logo aziendale corretto quando apre Software Center, devi intervenire su Client Settings, sul file immagine e sulla distribuzione del contenuto, non sul contenuto del pacchetto. Il risultato atteso è lineare: logo visibile, proporzioni corrette, nessun impatto su installazioni, aggiornamenti o compliance.

In pratica il client ConfigMgr conserva localmente le impostazioni di branding e le applica all’interfaccia. Quindi la modifica va trattata come un change controllato: prima prepari il file grafico, poi lo rendi disponibile al client, poi applichi la policy, infine verifichi il rendering. Se il logo non compare subito, le cause più probabili sono sempre le stesse: policy non ancora arrivata, file non raggiungibile, immagine non adatta oppure cache del client ancora vecchia.

Il punto giusto dove intervenire: branding del client, non deployment

Software Center non pesca il logo da un contenuto applicativo come farebbe una pagina web. Il branding è una proprietà del client, quindi il controllo va cercato nella configurazione di Configuration Manager. Questo dettaglio cambia completamente il troubleshooting: se il logo è sbagliato, non devi aprire il deployment dell’app, ma verificare la Client Settings assegnata al device e il file che il client deve leggere.

La conseguenza pratica è semplice: se modifichi solo il pacchetto o l’application, il logo non cambia. Se modifichi la Client Settings ma il file non è disponibile, il client resta sul vecchio branding o sul default. Se distribuisci bene il file ma la policy non arriva, il risultato è identico. Il problema va quindi letto come una catena: file, policy, rendering.

Formato e caratteristiche dell’immagine da usare

Per il logo conviene usare un file leggero, pulito e prevedibile. PNG e JPG sono le scelte più comuni; il PNG è spesso la soluzione migliore quando serve uno sfondo trasparente, mentre il JPG va bene per loghi semplici senza trasparenza. Evita immagini pesanti o con dettagli minuscoli: un logo da diversi megabyte è inutile per un elemento UI e può introdurre ritardi o resa scadente su schermi diversi.

Conta più l’aspect ratio della risoluzione assoluta. Un’immagine troppo stretta o troppo alta può essere deformata nel Software Center, mentre un file ben bilanciato mantiene una resa stabile. Se il logo contiene testo, verifica che resti leggibile anche in dimensioni ridotte: quello che sembra perfetto in un editor grafico può diventare illeggibile nell’interfaccia reale.

Prima di toccare SCCM, controlla il file sorgente in modo banale ma rigoroso:

ls -lh /path/al/logo/softwarecenter-logo.png
file /path/al/logo/softwarecenter-logo.png
identify /path/al/logo/softwarecenter-logo.png 2>/dev/null

Atteso: formato valido, dimensioni coerenti, nessun errore di lettura. Se identify non è disponibile, il controllo non cambia: il punto è confermare che il file esista, sia leggibile e non sia corrotto.

Prerequisiti da verificare prima della modifica

Prima di impostare il branding, chiarisci dove vivrà il file e come raggiungerà il client. Se lo distribuisci su una share, devi garantire permessi di lettura e disponibilità costante. Se lo copi localmente, devi sapere chi effettua la copia e in quale path finisce l’asset. Se il percorso è instabile, il branding diventa fragile per definizione.

Un buon prerequisito è anche la baseline operativa: logo attuale, collection coinvolta, versione del client e percorso del file. Questi dati servono quando qualcosa non torna, perché distinguono subito un problema di policy da un problema di rendering. In ambienti con più siti o più versioni di Configuration Manager, non dare per scontato che il comportamento sia identico ovunque.

Se lavori su Windows, una verifica rapida del file locale può essere questa:

powershell -NoProfile -Command "Test-Path 'C:\ProgramData\Company\Branding\softwarecenter-logo.png'; Get-Item 'C:\ProgramData\Company\Branding\softwarecenter-logo.png' | Select-Object FullName,Length,LastWriteTime"

Atteso: True sul controllo del percorso e un oggetto con dimensione e timestamp coerenti. Se il file non esiste, il branding non può funzionare. Se esiste ma ha dimensione anomala o data incoerente, il problema è nella distribuzione del contenuto.

Configurazione corretta in SCCM: Client Settings e assegnazione

Il metodo pulito è usare una Client Settings dedicata al branding del Software Center. In console, il percorso preciso può cambiare leggermente in base alla versione, ma la logica resta la stessa: apri le impostazioni client, abilita la personalizzazione del Software Center e associa il logo al parametro previsto. Questo approccio è tracciabile, reversibile e soprattutto centralizzato.

Il vantaggio rispetto a interventi manuali sul singolo endpoint è evidente: riduci il drift e puoi applicare la stessa configurazione a più collection in modo controllato. Se vuoi fare le cose bene, crea una Client Settings separata per il branding, assegnala prima a una collection pilota e solo dopo estendila al resto dell’ambiente.

Il flusso operativo sensato è questo:

1. Prepara il logo finale in PNG o JPG, con nome stabile e senza caratteri ambigui.
2. Pubblicalo in una sorgente interna affidabile o distribuiscilo localmente con un metodo controllato.
3. Modifica la Client Settings e abilita il branding del Software Center.
4. Assegna la policy alla collection corretta, partendo da un gruppo pilota.
5. Forza il refresh del client e verifica il rendering nel Software Center.

Se vuoi mantenere ordine operativo, tratta il logo come un asset di configurazione: nome file coerente, percorso documentato, owner chiaro e changelog. Un file chiamato final-logo-ok.png è una cattiva abitudine; un file come softwarecenter-logo-2024q4.png è molto più gestibile nel tempo.

Distribuzione del logo: share, package o copia locale

Hai tre modelli pratici. Il primo è una share interna letta dal client: è semplice, ma richiede disponibilità e permessi corretti. Il secondo è una distribuzione controllata tramite SCCM, utile se vuoi copiare il file sul device. Il terzo è un approccio ibrido, dove il file viene distribuito una volta e poi referenziato localmente. Per il branding del Software Center, la copia locale è spesso la soluzione più solida perché riduce le dipendenze runtime.

La copia locale è particolarmente utile se vuoi evitare che il branding dipenda da una share momentaneamente non raggiungibile. Un path tipico può essere sotto C:\ProgramData\Company\Branding\. Evita directory utente o percorsi temporanei: il Software Center è un componente di sistema e deve leggere un file stabile anche dopo logoff, cambio profilo o accesso con utente diverso.

Se il file viene aggiornato spesso, mantieni il nome costante e sostituisci il contenuto. Così riduci il rischio di referenze incoerenti e semplifichi la gestione della policy. Per verificare la presenza del file sul client, il controllo minimo è questo:

powershell -NoProfile -Command "Test-Path 'C:\ProgramData\Company\Branding\softwarecenter-logo.png'; Get-Item 'C:\ProgramData\Company\Branding\softwarecenter-logo.png' | Select-Object FullName,Length,LastWriteTime"

Atteso: percorso presente e file con dimensione valida. Se il file manca, il branding non può essere applicato. Se il file c’è ma non coincide con la sorgente, il problema è nella distribuzione o nella sostituzione del contenuto.

Forzare l’aggiornamento della policy sul client

Dopo aver pubblicato il logo e assegnato la Client Settings, devi confermare che il device abbia ricevuto la policy. Qui non basta aspettare: serve osservare il client. Il Software Center dipende dai cicli di policy di ConfigMgr, quindi se il refresh non è avvenuto o il device è rimasto con configurazione vecchia, il logo non cambia.

Il controllo più utile è forzare il download della policy e poi leggere i log del client. Se la policy arriva, ma il logo resta invariato, il problema si sposta sul file o sul rendering. Se la policy non arriva, il problema è nella collection, nell’assegnazione o nella sincronizzazione del client.

Un refresh manuale della policy può essere avviato così:

powershell -NoProfile -Command "Invoke-CimMethod -Namespace root\ccm -ClassName SMS_Client -MethodName TriggerSchedule -Arguments @{sScheduleID='{00000000-0000-0000-0000-000000000021}'}"
wevtutil qe Microsoft-Windows-ClientUI/Operational /c:20 /f:text 2>nul

Atteso: nessun errore nel trigger e nessun evento che segnali problemi di caricamento dell’interfaccia. Se nel tuo ambiente il troubleshooting passa dai log classici, controlla anche i file sotto C:\Windows\CCM\Logs\, in particolare quelli legati a policy e client UI.

Verifica del rendering nel Software Center

Quando file e policy sono allineati, apri Software Center e controlla il logo nella posizione prevista. Non testare un solo endpoint: prova almeno una macchina pilota e, se possibile, un secondo device con risoluzione o DPI diversi. Il branding UI può sembrare corretto su una macchina e risultare deformato su un’altra se l’immagine è stata preparata male.

Osserva tre aspetti: nitidezza, proporzioni e stabilità. Il logo deve apparire senza stretching evidente, senza bordi tagliati e senza ritardi anomali nell’apertura dell’interfaccia. Se compare il logo vecchio, devi distinguere tra cache e policy: controlla timestamp del file locale, verifica l’assegnazione della collection e conferma che il client abbia scaricato la nuova configurazione.

Se il logo non compare ma le applicazioni continuano a funzionare, le cause più comuni sono tre: file nel path sbagliato, immagine non supportata bene dal client oppure policy assegnata a un gruppo diverso da quello testato. In questi casi conviene confrontare un device corretto con uno errato, file per file e setting per setting.

Problemi tipici e come isolarli in pochi minuti

Il primo problema tipico è il file errato. Se il logo è troppo grande, corrotto o in un formato poco adatto, il client può ignorarlo o renderizzarlo male. Il secondo è la policy non distribuita: in console tutto sembra corretto, ma il device non appartiene alla collection o non ha ancora ricevuto il refresh. Il terzo è la cache locale: il file è stato aggiornato, ma Software Center mostra ancora la versione precedente.

Per falsificare rapidamente queste ipotesi, controlla in quest’ordine: esistenza del file, dimensione del file, appartenenza del client alla collection e presenza della policy nei log. Se il file è presente e la policy è arrivata, ma il logo resta invariato, il passo successivo è chiudere e riaprire Software Center oppure riavviare il client per forzare il reload dell’interfaccia. Se anche così non cambia, il problema è quasi certamente nel modo in cui il branding viene referenziato.

Un controllo utile è confrontare anche hash o timestamp tra sorgente e client. Se il file è distribuito da share, verifica i permessi con l’account macchina o con il contesto reale del client, non con il tuo account amministrativo. È un errore classico validare tutto con privilegi troppo alti e poi scoprire che il device non può leggere la sorgente.

Soluzione consigliata in produzione

In produzione la strada più robusta è questa: logo leggero, distribuito localmente su un path stabile, assegnato tramite Client Settings a una collection pilota e poi esteso al resto dell’ambiente solo dopo verifica. Così riduci le dipendenze esterne e mantieni semplice il rollback. Se qualcosa va storto, puoi rimuovere l’assegnazione della policy o sostituire il file locale senza toccare i deployment applicativi.

Se vuoi evitare sorprese, prepara anche un fallback: un logo neutro o il branding precedente da ripristinare rapidamente. In questo modo il rollback non richiede di cercare l’asset originale sotto pressione. Mantieni inoltre una nota operativa con percorso del file, collection coinvolta, data del cambio e versione del client testata. Sono dettagli banali solo finché non devi fare troubleshooting su un parco macchine ampio.

Una buona pratica finale è verificare il risultato su un endpoint con profilo utente standard, non solo su una macchina gestita da remoto. Il branding del Software Center è un elemento visivo e va validato nel contesto reale di utilizzo. Se l’utente finale vede il logo corretto e il client non registra errori, la modifica è stata applicata nel modo giusto.

Controlli finali e rollback

Prima di chiudere il change, conferma che il logo sia visibile nel Software Center, che il file locale sia presente nel path previsto e che i log del client non riportino errori di caricamento. Un controllo minimo accettabile è questo: file presente, policy assegnata, Software Center aggiornato e nessun evento anomalo nei log del client. Se uno solo di questi punti fallisce, la modifica non è da considerare conclusa.

Per il rollback, rimuovi o disabilita la Client Settings che introduce il branding, oppure ripristina il file precedente sul path locale. Se hai cambiato solo l’immagine, puoi tornare al logo originale sostituendo il file e forzando un refresh della policy. Se invece hai modificato anche l’assegnazione della collection, annulla quell’associazione prima di ampliare il test. Il blast radius resta limitato se hai lavorato su una collection pilota e su un path locale ben definito.

Assunzione: l’ambiente usa Configuration Manager con client Windows standard e una gestione centralizzata delle Client Settings; se la tua versione espone nomi diversi nei menu, il flusso operativo resta comunque lo stesso.