Distribuire Brave Browser con SCCM e ConfigMgr

Distribuire Brave Browser con SCCM e ConfigMgr ha senso quando vuoi un browser moderno, aggiornabile e gestito come qualsiasi altro software di postazione, senza affidarti a installazioni manuali o GPO improvvisate. La parte delicata non è l’installazione in sé: è farla in modo ripetibile, rilevabile e reversibile, soprattutto se hai collezioni miste, finestre di manutenzione strette e client che non devono perdere il profilo utente o le policy già in uso.

Il punto di partenza è semplice: tratta Brave come un’applicazione enterprise, non come un installer da lanciare una volta. Questo significa scegliere il pacchetto giusto, definire una detection rule robusta, decidere come gestire gli aggiornamenti e sapere dove guardare quando qualcosa non si allinea tra console e client. In pratica, il lavoro vero è nel ciclo di vita, non nel primo deploy.

Pacchetto giusto: MSI, source affidabile e comportamento prevedibile

Per ConfigMgr la strada più pulita è usare un MSI se disponibile per il canale che vuoi distribuire. Il vantaggio non è solo la silenziosità dell’installazione: l’MSI porta con sé ProductCode, proprietà standard e una detection rule più stabile rispetto a un wrapper EXE. Se devi usare l’EXE, fallo solo quando non hai alternative, perché la detection diventa più fragile e il troubleshooting si complica.

Prima di pubblicare il pacchetto, verifica sempre che il file arrivi da una fonte coerente con la tua policy di software management. In ambienti seri non basta “funziona”: serve sapere quale build stai distribuendo, con che firma, e se il canale di aggiornamento è allineato alla tua strategia. Un mismatch qui ti crea il classico problema da help desk: due utenti sulla stessa collection che vedono versioni diverse senza una spiegazione immediata.

Se il file è già in mano, controlla hash e firma prima di importarlo nel package source. Un controllo minimo dal server di staging evita di propagare un artefatto sbagliato a centinaia o migliaia di client.

Get-FileHash .rave_installer.msi -Algorithm SHA256

Se il risultato non coincide con quello atteso, fermati lì: non correggere “a valle” un pacchetto che nasce già incoerente. In ConfigMgr il tempo perso a inseguire un artefatto sbagliato costa più di un controllo iniziale fatto bene.

Application model o Package: quando usare l’uno e quando l’altro

Per Brave, in quasi tutti gli scenari conviene usare il model Application di ConfigMgr. Ti dà detection rule, supersedence, requirement, dipendenze e reporting migliori rispetto al vecchio Package. Il Package resta utile se hai un processo legacy o se devi fare una distribuzione molto semplice, ma appena entri nel territorio del software gestito su larga scala, l’Application è più pulita.

Con Application puoi anche dividere bene i casi d’uso: installazione iniziale, aggiornamento, eventuale migrazione da Chrome o Edge, e controllo della versione minima. Se hai collezioni diverse per reparti o sedi, puoi applicare requirement rule diverse senza duplicare il contenuto. È un vantaggio concreto quando la tua base client non è omogenea.

Il criterio pratico è questo: se vuoi sapere con un colpo d’occhio chi ha cosa, usa Application. Se vuoi solo copiare un file e far girare un comando, stai probabilmente semplificando troppo un problema che poi si ripresenterà nei report di conformità.

Command line di installazione: silenziosa, loggata e senza sorprese

La command line deve essere prevedibile. Per un MSI, la base è sempre l’installazione silenziosa con logging. Il log locale è il tuo primo punto di verità quando il client dice “installato” e la console dice “failed”.

msiexec /i