Monitorare l’uso di Microsoft Edge con SCCM

Con SCCM non stai “leggendo il browser in uso” in senso assoluto: stai raccogliendo segnali utili per stimare installazione, presenza di processi, frequenza di esecuzione e, se configuri bene i dati, adozione reale di Microsoft Edge nel parco macchine. La differenza conta, perché un inventario software ti dice che Edge è presente; un log di utilizzo ti dice se viene davvero aperto dagli utenti.

Il punto di partenza è semplice: in Configuration Manager devi decidere quale livello di visibilità ti serve. Se ti basta sapere su quali endpoint Edge è installato, puoi appoggiarti all’inventario hardware/software. Se vuoi capire chi lo usa, quando e con quale frequenza, devi aggiungere raccolta dati più mirata: asset intelligence, rilevamento processi, eventi di accesso o report personalizzati. Senza questa distinzione si finisce a confondere presenza del software con utilizzo effettivo.

Che cosa puoi misurare davvero con SCCM

Microsoft Edge lascia tracce diverse, e SCCM può intercettarne alcune meglio di altre. La misura più affidabile, di solito, è la presenza del pacchetto e della versione installata. Da lì puoi risalire alla distribuzione del browser, ma non all’uso. Per l’uso servono indicatori indiretti: esecuzione del processo msedge.exe, frequenza di avvio, profili utente che accedono a Edge, estensioni installate, oppure policy applicate al browser.

In ambienti enterprise, il dato più utile non è “Edge è aperto adesso”, ma “Edge viene usato come browser primario o secondario”. Questo lo ottieni incrociando più fonti: software inventory, endpoint analytics, report di compliance e, se serve, una baseline o uno script di discovery che rileva il processo e lo invia come hardware inventory custom class. È il classico caso in cui una singola metrica è troppo debole e il valore arriva dalla correlazione.

Inventario software: la base, ma non basta

La via più lineare è verificare che Edge compaia nell’inventario software. In SCCM, questo ti permette di sapere su quali client il browser è installato, con quale versione e, in molti casi, con quale canale: Stable, Beta, Dev o Canary. Per una governance minima è già utile, perché puoi capire se le release sono allineate e se ci sono endpoint rimasti indietro.

Il limite è evidente: l’inventario non distingue tra browser installato e browser realmente usato. Un PC può avere Edge presente e l’utente continuare a navigare con Chrome o Firefox. Se il tuo obiettivo è fare una reportistica di adozione, l’inventario è solo il primo strato, non il risultato finale.

In pratica, conviene partire da qui per rispondere a domande come: quante macchine hanno Edge? qual è la versione dominante? ci sono installazioni non conformi? Questo tipo di dato è stabile, poco rumoroso e adatto a un primo cruscotto. Quando però vuoi parlare di “uso”, devi aggiungere un secondo segnale.

Rilevare l’esecuzione di Edge con una custom hardware inventory

Se vuoi misurare l’avvio del browser, una strada pratica è aggiungere una classe di inventario personalizzata che rilevi la presenza del processo msedge.exe o di artefatti correlati. L’idea non è monitorare ogni click, ma raccogliere un indicatore semplice: il browser è stato eseguito sul client durante la finestra di raccolta.

Questo approccio funziona bene quando vuoi rispondere a una domanda operativa: “Su quanti endpoint Edge viene effettivamente lanciato almeno una volta nel periodo osservato?”. Per farlo puoi usare un client setting di SCCM con hardware inventory esteso, oppure una baseline di compliance che esegue uno script e scrive il risultato in una chiave di registro o in un file che poi diventa inventariabile.

Un esempio pratico è rilevare il processo in esecuzione e trasformare il dato in una proprietà inventariata. In pseudologia operativa, il flusso è: script locale, raccolta del risultato, normalizzazione nel database SCCM, report. Il vantaggio è che il dato entra nel sistema già in forma interrogabile. Lo svantaggio è che stai misurando una finestra temporale, non la storia completa dell’uso.

Se il tuo ambiente è molto distribuito, tieni presente il bias: un client che si collega raramente al management point può sembrare “non usato” solo perché non ha ancora inviato l’ultimo inventario. Per questo la cadenza di raccolta va scelta in funzione del KPI, non per comodità amministrativa.

Asset Intelligence e report: utili, ma da verificare sul tuo tenant

Asset Intelligence può aiutare a classificare software e versioni, ma la sua utilità reale dipende da come è configurato il tuo ambiente SCCM e da quanto è aggiornata la catalogazione. Per Edge è spesso più efficace come supporto alla normalizzazione dei dati che come fonte unica di verità. Se il catalogo non riconosce correttamente i canali o le build, il report rischia di diventare rumoroso.

Qui serve una verifica concreta, non un’ipotesi. Nel console path dei report SCCM, controlla se hai viste che distinguono il prodotto, il publisher e la versione. Se il dato è troppo generico, non forzare interpretazioni: in quel caso conviene arricchire il dataset con un campo custom, invece di fidarsi di una classificazione troppo ampia.

Un buon uso di Asset Intelligence è questo: confrontare la lista dei sistemi che hanno Edge installato con la lista dei sistemi che hanno effettivamente aperto il browser almeno una volta nel periodo definito. La differenza tra i due insiemi è spesso più interessante del totale assoluto, perché ti mostra dove la distribuzione non si traduce in adozione.

Endpoint Analytics: quando vuoi un segnale più vicino all’uso reale

Se nel tuo stack è disponibile Endpoint Analytics, puoi usarlo come complemento per capire come i client vengono effettivamente impiegati. Non è un sostituto dell’inventario SCCM, ma spesso fornisce un indicatore più vicino al comportamento utente. In contesti moderni, infatti, il dato più utile è quello che descrive l’esperienza d’uso, non solo l’asset inventory.

Per monitorare Edge, l’idea è verificare se il browser compare tra le app usate, tra i processi più ricorrenti o nei dati di produttività associati al dispositivo. Questo dipende dalla versione del client, dal livello di integrazione e dalle licenze disponibili. Se non hai questa componente, non inventare un equivalente: meglio dichiarare il gap e restare su inventario e processi rilevati lato SCCM.

Il vantaggio di questo approccio è che ti aiuta a rispondere a domande più vicine al business: quanti utenti aprono Edge come browser principale? quanti lo usano solo per portali aziendali? quanti lo hanno installato ma non lo avviano mai? Sono domande che un inventario puro non riesce a coprire bene.

Raccolta dati con script: il modo più flessibile per ambienti misti

Quando i report nativi non bastano, uno script di discovery è spesso la soluzione più pulita. Puoi eseguire una scansione locale per verificare se Edge è installato, se il processo è stato avviato, se esistono profili utente creati per il browser e, in alcuni casi, se sono presenti policy o estensioni gestite. Il risultato viene poi esportato in una forma che SCCM può leggere e importare.

Per esempio, un controllo PowerShell può leggere i percorsi di installazione comuni, verificare la versione del binario e cercare il processo msedge.exe. Il punto non è il linguaggio in sé, ma la disciplina del dato: un output semplice, ripetibile e facile da interrogare nel database di inventario.

Se vuoi tenere il dato pulito, evita di salvare informazioni sensibili o inutili. Non servono nomi utente in chiaro né dettagli personali: basta un flag di presenza, un timestamp tecnico o una versione software. Questo riduce il rischio operativo e rende il report più facile da proteggere e da auditare.

Report utili: adozione, conformità, versioning

Un monitoraggio serio di Edge con SCCM di solito produce tre report distinti. Il primo è di adozione: quanti endpoint hanno Edge installato e quanti lo usano. Il secondo è di conformità: quanti endpoint sono sulla versione approvata. Il terzo è di distribuzione: quali canali sono presenti e dove si trovano eccezioni o installazioni anomale.

Il report di adozione è quello più delicato, perché è facile sovrastimarlo. Se una macchina avvia Edge una volta al mese, non significa che sia il browser di lavoro dell’utente. Per questo conviene definire una finestra temporale: per esempio, uso rilevato negli ultimi 7, 14 o 30 giorni. Senza una finestra, il dato diventa ambiguo.

Il report di conformità invece è più affidabile. Ti basta confrontare la versione installata con quella attesa e verificare se il canale corrisponde alla policy aziendale. Qui SCCM rende bene, perché il problema è tecnico e non interpretativo. Il report di distribuzione, infine, ti aiuta a capire se stai spingendo il canale giusto nei gruppi corretti, ad esempio Stable sui client standard e Beta solo su gruppi pilota.

Come evitare falsi positivi e letture sbagliate

Il falso positivo tipico è questo: Edge risulta “usato” perché il processo è stato visto una volta durante una scansione, ma in realtà l’utente non lo adopera in modo ricorrente. Il falso negativo opposto capita quando il client non ha ancora inviato l’inventario aggiornato e il browser sembra assente o mai aperto. In entrambi i casi il problema non è il dato in sé, ma la finestra temporale e la frequenza di raccolta.

Per ridurre l’errore, conviene usare almeno due sorgenti. Ad esempio: inventario software per l’installazione e custom discovery per l’esecuzione. Se i due segnali convergono, il report è robusto. Se divergono, hai un caso interessante da investigare: browser installato ma non usato, oppure browser usato ma non correttamente inventariato.

Un altro punto spesso trascurato è il multi-sessione. Su terminal server, VDI o ambienti con profili roaming, il processo può essere avviato da più utenti sullo stesso host. In quel caso il dato va letto per sessione o per profilo, non solo per macchina. Se non distingui il contesto, il report ti dice poco o ti dice male.

Una strategia pratica per ambienti reali

Se devi partire da zero, la sequenza più sensata è questa: prima inventario software, poi versione e canale, quindi rilevamento dell’esecuzione, infine report di adozione. È una progressione a basso rischio, perché ogni passo aggiunge visibilità senza rompere il funzionamento degli endpoint.

Il vantaggio operativo è che puoi fermarti al livello che ti serve davvero. Se l’obiettivo è solo la standardizzazione del browser, l’inventario basta. Se devi produrre un indicatore di adozione per il management, serve il livello successivo. Se devi fare un progetto di migrazione da un altro browser, allora ti servono entrambi, più una finestra temporale coerente.

In uno scenario tipico, la dashboard finale dovrebbe mostrare almeno tre numeri: endpoint con Edge installato, endpoint con Edge avviato nel periodo osservato, endpoint conformi alla versione target. Con questi tre valori puoi già costruire una lettura credibile, senza inseguire metriche troppo sofisticate che poi nessuno mantiene.

Il limite più importante: SCCM non è un telemetry engine

Vale la pena dirlo chiaramente: SCCM è ottimo per inventario, compliance e distribuzione software, ma non nasce come motore di telemetria fine sul comportamento applicativo. Se vuoi sapere quanto tempo l’utente passa in Edge, quali siti visita o quali tab apre, sei fuori dal perimetro di SCCM e devi guardare ad altri strumenti, con tutti i vincoli di privacy e governance del caso.

Questa distinzione evita molta confusione in fase di progetto. SCCM può dirti che Edge c’è, che è aggiornato e che viene lanciato. Può anche darti un indicatore ragionevole di utilizzo. Non può, da solo, trasformarsi in uno strumento di analisi comportamentale completa. Pretendere di più porta quasi sempre a report fragili o a raccolte dati inutilmente invasive.

Se imposti bene il perimetro, però, il risultato è solido: una visione tecnica del browser, utile per standardizzazione, supporto, migrazione e controllo della compliance. In un ambiente aziendale è spesso esattamente quello che serve.