1 14/04/2026 5 min

Se vuoi cambiare il logo che gli utenti vedono nel Software Center di SCCM, il punto giusto non è il singolo deployment ma il branding del client. In pratica il logo viene letto dal client ConfigMgr e può essere personalizzato con un file immagine locale, con una policy di client setting oppure con una combinazione delle due cose. Il risultato atteso è semplice: aprendo Software Center, l’utente deve vedere il logo aziendale corretto, con proporzioni accettabili e senza effetti collaterali su aggiornamenti, applicazioni o compliance.

La parte che crea più confusione è che molti cercano l’impostazione dentro il pacchetto o dentro il singolo application deployment. Non è lì. Il branding del Software Center è una proprietà del client, quindi va trattato come una modifica controllata: prima definisci il file grafico, poi lo distribuisci, poi forzi il refresh del client e infine verifichi che l’interfaccia abbia preso la nuova immagine. Se il logo non compare subito, il problema di solito è uno tra questi: cache del client, percorso file non raggiungibile, dimensioni immagine non adatte, oppure client settings non applicati al device.

Come funziona il branding del Software Center

Il Software Center non legge un logo “dal sito” in modo dinamico come farebbe un portale web. Il client scarica e conserva localmente i parametri di branding, quindi la modifica deve arrivare al computer tramite le impostazioni di Configuration Manager. Questo significa due cose pratiche: il file immagine deve essere accessibile al client nel momento giusto, e il client deve ricevere una policy aggiornata. Se uno dei due elementi manca, l’interfaccia continua a mostrare il branding precedente o quello di default.

Nella maggior parte degli ambienti conviene usare un’immagine PNG o JPG semplice, con sfondo trasparente solo se serve davvero. Evita file enormi: un logo da 2 MB per un elemento UI è una cattiva idea anche quando “funziona”, perché peggiora il caricamento e complica la resa su DPI diversi. In genere è meglio preparare una versione quadrata o quasi quadrata, con margini puliti e senza testi troppo piccoli. Se il logo è pensato per una barra laterale o per un header, l’aspect ratio conta più della risoluzione assoluta.

Prerequisiti da controllare prima di toccare SCCM

Prima di cambiare la configurazione, verifica che il file immagine sia pronto e che il percorso di distribuzione sia sensato. Se usi un file locale sul client, devi sapere da dove viene copiato. Se usi una share o un web server, devi considerare permessi, raggiungibilità e affidabilità della sorgente. Se il logo viene pubblicato in una cartella condivisa, l’account del client deve poter leggere il file; se no vedrai un comportamento incoerente tra dispositivi diversi.

Un controllo rapido lato file può essere questo:

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

Atteso: formato immagine valido, dimensioni ragionevoli, nessun errore di lettura. Se `identify` non è installato, il punto non cambia: l’obiettivo è confermare che il file esista davvero e non sia corrotto. Se stai lavorando su Windows, il controllo equivalente è aprire il file e verificarne dimensioni e anteprima, ma per evitare errori operativi è preferibile usare un file testato e versionato.

Metodo corretto: Client Settings con logo personalizzato

Il percorso più pulito è impostare il branding da console SCCM, perché rende la modifica tracciabile e reversibile. La logica è questa: crei o modifichi una Client Device Settings, abiliti il branding del Software Center e associ l’immagine al parametro previsto. In molti ambienti questo approccio è preferibile rispetto a interventi manuali sul singolo endpoint, perché ti evita drift e ti permette di applicare la stessa configurazione a collection diverse con un controllo centralizzato.

In console, il percorso tipico è nella sezione di amministrazione delle impostazioni client. L’etichetta precisa può cambiare leggermente a seconda della versione, ma il concetto non cambia: devi arrivare alla configurazione del Software Center branding e assegnare il logo. Se la tua build espone un campo dedicato per l’immagine, usa quello. Se la tua organizzazione usa un file distribuito su share, valuta con attenzione la latenza e la disponibilità della sorgente: il branding non dovrebbe dipendere da un percorso instabile.

Un approccio operativo sensato è questo:

  1. Prepara il logo finale in PNG o JPG, con nome file stabile e senza caratteri ambigui.
  2. Caricalo su una sorgente interna affidabile, meglio se con controllo versioni o cartella di distribuzione dedicata.
  3. Modifica la Client Settings di SCCM e abilita il branding del Software Center.
  4. Assegna la policy alla collection corretta, partendo da un gruppo pilota.
  5. Aggiorna la policy sul client e verifica il rendering nel Software Center.

Se vuoi essere rigoroso, tratta il logo come un asset applicativo: nome file coerente, percorso documentato, owner chiaro e changelog. In ambienti grandi, la differenza tra una modifica ordinata e un problema di supporto è quasi sempre nella tracciabilità. Un file chiamato `logo_new_final2.png` è una cattiva abitudine; un file versionato come `softwarecenter-logo-2024q4.png` è molto più gestibile.

Distribuzione del file: share, package o copia locale

Hai tre modelli pratici. Il primo è una share interna raggiunta dal client. È comoda, ma devi garantire permessi di lettura e alta disponibilità. Il secondo è un package o una distribuzione controllata tramite SCCM, utile se vuoi che il file venga copiato localmente. Il terzo è una soluzione ibrida, dove il logo è pubblicato in una cartella accessibile solo in fase di configurazione iniziale e poi referenziato localmente. Per il branding del Software Center, la copia locale è spesso la scelta più robusta, perché riduce dipendenze runtime.

Se distribuisci localmente, il punto chiave è il path sul client. Un esempio tipico è una directory sotto `C:\ProgramData\Company\Branding\`. Non usare percorsi temporanei o directory utente, perché il Software Center è un componente di sistema e deve leggere un file stabile anche dopo logoff o cambio profilo. Se il file viene aggiornato spesso, mantieni il nome costante e sostituisci il contenuto, così riduci il rischio di policy incoerenti.

Per verificare che la copia locale sia presente, puoi usare una verifica minima sul client Windows:

powershell -NoProfile -Command