1 12/10/2026 11 min

Raccogliere i dispositivi Microsoft Edge in SCCM senza trascinarsi dietro il rumore

In SCCM la parte delicata non è tanto creare la raccolta, quanto definire un criterio che resti stabile nel tempo e che selezioni davvero i client che ti interessano. Se l’obiettivo è raggruppare i dispositivi che usano Microsoft Edge, conviene partire da un dato verificabile nel database del client, non da supposizioni sul nome del browser o da controlli manuali sul singolo endpoint. In pratica devi decidere se vuoi una raccolta basata sull’installazione del prodotto, sulla presenza dell’applicazione, sulla versione, oppure sull’uso effettivo del browser. Sono quattro problemi diversi, e in SCCM vanno trattati in modo diverso.La scelta più robusta, nella maggior parte dei casi, è usare una collezione costruita su una query WQL che interroghi l’inventory hardware o il discovery della presenza di Edge. Questo approccio funziona bene quando ti serve applicare una policy, distribuire un aggiornamento, fare un test di compatibilità o segmentare i client per una fase di migrazione da un browser all’altro. Se invece vuoi sapere chi apre Edge almeno una volta al giorno, SCCM da solo non è lo strumento giusto: lì serve telemetria applicativa o un sistema di analytics dedicato. La differenza è importante, perché molte raccolte “sbagliate” nascono proprio da un obiettivo formulato male.

Prima scelta: installazione rilevata o utilizzo reale

Una raccolta dispositivi in SCCM può essere basata su attributi del computer, non su eventi di navigazione. Per Microsoft Edge hai almeno tre strade pratiche. La prima è cercare la presenza del binario o del prodotto installato. La seconda è usare la classe di inventario software, se è già raccolta nel tuo ambiente. La terza è basarti su una query che individui i sistemi con Edge Chromium o, più raramente, con Edge Legacy ancora residuo. In ambienti attuali, la distinzione utile è quasi sempre tra Edge Chromium installato e tutto il resto.Se devi distribuire estensioni, policy o aggiornamenti, la raccolta deve includere i dispositivi con Edge installato, non i dispositivi “che lo usano”. Se devi fare una migrazione, può avere senso separare i client che hanno già Edge in versione nuova da quelli che presentano ancora componenti legacy o configurazioni vecchie. Questo ti permette di evitare distribuzioni a pioggia e di ridurre i falsi positivi. Un errore tipico è usare criteri troppo generici, come il nome del produttore Microsoft o la presenza di qualunque voce Edge nel software inventariato: così dentro ci finiscono anche componenti di sistema, helper, residue di vecchie release o voci duplicate.

Creare la raccolta in console SCCM

La procedura parte dalla console di Configuration Manager. Il percorso classico è: Assets and Compliance, poi Device Collections, quindi Create Device Collection. Qui assegni un nome esplicito, per esempio “Dispositivi con Microsoft Edge”, e una descrizione che dica chiaramente il criterio usato. Non è un dettaglio estetico: quando la raccolta finisce in mano ad altri amministratori, la descrizione evita interpretazioni creative.Scegli come limiting collection una raccolta coerente con lo scope del tuo ambiente, di solito “All Systems” o una collezione padre più ristretta se lavori per sedi, OU o business unit. La limiting collection non è un filtro decorativo: delimita davvero il perimetro della query. Se la imposti male, la raccolta figlia può restare vuota anche con una query corretta. Per ambienti grandi, usare una limiting collection già segmentata aiuta anche le prestazioni e rende più leggibile il comportamento della raccolta.Nel passaggio successivo scegli il tipo di membership. Per questo caso serve una query rule, non una rule basata su direct membership. Le direct membership sono utili per eccezioni o test rapidi, ma non sono manutenzionabili su larga scala. Una raccolta di Edge deve aggiornarsi da sola quando un dispositivo installa o rimuove il browser, quindi la query è la scelta naturale.

Query WQL per Microsoft Edge: la base da cui partire

Il metodo più pulito è interrogare la presenza del software tramite la classe di inventario o la rilevazione applicativa disponibile nel tuo sito SCCM. La forma precisa della query dipende da come hai configurato l’inventory e da quali classi sono già presenti nel tuo environment. Per questo conviene sempre validare il nome della classe e dei campi nella console prima di copiare una query trovata altrove. In SCCM, la stessa idea può essere espressa in modi diversi, ma il principio resta identico: selezionare i dispositivi che riportano Microsoft Edge come prodotto rilevato.Un esempio di logica corretta è cercare il nome prodotto che contiene Edge e, se serve, filtrare la versione per distinguere il canale stabile dalle build obsolete. Non fissarti sul testo esatto del nome se non hai verificato come viene popolato l’inventory nel tuo ambiente. In alcuni casi il nome è “Microsoft Edge”, in altri trovi varianti che includono il canale o il tipo di installazione. La query va quindi testata su un campione noto di macchine, non solo scritta “bene” sulla carta.Una query di esempio, da adattare alla tua classe inventariata, può essere costruita in modo concettualmente simile a questa:
select SMS_R_System.ResourceID, SMS_R_System.Name
from SMS_R_System
inner join SMS_G_System_ADD_REMOVE_PROGRAMS on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceID
where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName like "%Microsoft Edge%"
Questa è una traccia di lavoro, non una formula universale. In molti ambienti la classe ADD_REMOVE_PROGRAMS non è la scelta migliore per i software moderni, oppure non contiene i dati che ti aspetti. Se l’inventory hardware raccoglie una classe più affidabile per i programmi installati, usa quella. Se il tuo ambiente usa asset intelligence o discovery specifici, adatta il criterio alla sorgente che hai realmente abilitato. Il punto non è copiare una query, ma far sì che il criterio sia verificabile e ripetibile.

Come evitare falsi positivi e raccolte troppo larghe

Il rischio più comune è includere dispositivi che hanno una voce residua di Edge ma non un’installazione realmente utilizzabile. Questo succede, per esempio, dopo upgrade incompleti, uninstall parziali o inventory non aggiornato. Per ridurre il rumore, puoi aggiungere un secondo criterio: versione minima, presenza del file eseguibile, oppure una condizione su una proprietà più specifica del prodotto. Se lavori con la console e vuoi mantenere la raccolta leggibile, è spesso meglio una query un po’ più selettiva che una raccolta enorme da ripulire a mano.Un altro errore classico è includere sia Edge Chromium sia vecchie installazioni legacy senza distinguerle. Se il tuo obiettivo è amministrativo, questa mescolanza complica tutto: distribuzioni, compliance, report e troubleshooting. Meglio creare raccolte separate, per esempio “Microsoft Edge Chromium” e “Microsoft Edge Legacy”, solo se hai una ragione concreta per farlo. Se non ti serve davvero la distinzione, tieni una sola raccolta e usa una versione minima o una regola di esclusione per i casi obsoleti.Quando l’ambiente è grande, la query deve essere pensata anche in termini di impatto sul provider. Una raccolta che interroga troppe classi o usa filtri troppo complessi può rallentare il refresh e rendere meno prevedibili gli aggiornamenti. In questi casi conviene preferire un criterio semplice e lasciare eventuali raffinamenti a una seconda raccolta di esclusione. È un approccio più pulito rispetto a una singola query mostruosa che nessuno vuole più toccare.

Testare la membership prima di metterla in produzione

Prima di affidare a una raccolta la distribuzione di policy o aggiornamenti, verifica che i membri restituiti siano quelli attesi. In console puoi usare il Run Now del refresh, controllare il conteggio dei membri e confrontare il risultato con un paio di client noti. Se hai accesso ai dettagli del dispositivo, controlla che il client sia davvero inventariato e che la data dell’ultimo hardware inventory non sia vecchia. Una raccolta corretta ma non aggiornata è quasi peggio di una raccolta sbagliata, perché ti dà un falso senso di sicurezza.Se vuoi un riscontro più tecnico, puoi verificare il client con i log locali di SCCM e con l’inventario applicativo. I log utili dipendono dalla versione del client, ma in genere ti interessano quelli legati all’hardware inventory e alla discovery delle applicazioni. Sul dispositivo, controlla che il software esista davvero nel percorso previsto e che la versione corrisponda a quella letta dalla raccolta. Se la console mostra Edge ma il sistema no, il problema non è la raccolta: è il dato sorgente.Per un test rapido, scegli tre endpoint: uno che sai avere Edge, uno senza Edge e uno borderline, per esempio appena aggiornato o appena rimosso. Se la query li classifica correttamente, hai già una buona evidenza. Se uno dei tre finisce nel gruppo sbagliato, non correggere a colpi di eccezioni casuali: torna alla sorgente dati e capire se il problema è nella classe inventariata, nel refresh o nella logica della query.

Versione, canale e criteri operativi

In ambienti maturi non basta sapere se Edge c’è. Spesso vuoi distinguere per canale, per versione minima o per stato di compatibilità con una policy aziendale. Qui la raccolta diventa uno strumento operativo, non solo inventariale. Per esempio, puoi creare una raccolta che contenga solo i dispositivi con Edge sopra una certa release, utile per distribuire una configurazione che richiede una funzione specifica del browser. Oppure puoi costruire una raccolta per i client ancora sotto una soglia da aggiornare prioritariamente.Questo tipo di segmentazione ha senso solo se hai un motivo chiaro e una metrica da seguire. Se l’obiettivo è ridurre il rischio operativo, la metrica può essere il numero di client non conformi. Se l’obiettivo è distribuire un’estensione, la metrica può essere il tasso di successo della distribuzione e il numero di endpoint che ricevono il pacchetto senza errori. In altre parole, la raccolta non è il fine: è il mezzo per tenere sotto controllo un’azione.

Raccolte dinamiche, maintenance windows e deployment

Una volta creata la raccolta, il passaggio sensato è usarla per una distribuzione mirata. Se devi spingere una policy, una baseline o un’applicazione collegata a Edge, aggancia il deployment alla raccolta e non a un gruppo statico costruito a mano. Così i dispositivi entrano ed escono in base allo stato reale. Se l’azienda cambia browser standard o aggiorna il canale Edge, la raccolta riflette il cambiamento senza interventi manuali.Se lavori con maintenance windows, fai attenzione a non assegnare la raccolta a finestre troppo strette senza prima capire la dimensione reale del gruppo. Una raccolta di Edge può essere molto più ampia di quanto sembri, soprattutto in ambienti dove il browser è installato di default. Prima di lanciare un deployment pesante, verifica il numero di membri e l’impatto sulle distribuzioni. Un pacchetto ben fatto su una raccolta enorme ma non testata può creare più rumore che valore.

Quando la console non basta: controlli lato client

Se il risultato della raccolta non torna, il controllo vero va fatto sul client. Verifica la presenza di Edge nel sistema operativo, la versione installata e l’eventuale corrispondenza con il software inventariato. In alcuni casi il browser è presente ma non viene riportato perché l’inventario non è aggiornato o perché la classe scelta non intercetta quella specifica installazione. Qui la soluzione non è “forzare” la raccolta, ma correggere il dato che la alimenta.Un controllo utile è incrociare il nome del prodotto con il percorso del file eseguibile e con la build effettiva. Se il browser è installato in una posizione standard, il binario dovrebbe essere coerente con la versione vista in inventario. Se non lo è, hai probabilmente un problema di rilevazione o di reinstallazione parziale. Anche in questo caso, la raccolta è solo il sintomo visibile di un dato interno non allineato.

Buone pratiche per non doverla rifare tra sei mesi

Dai un nome che spieghi cosa contiene e con quale criterio è costruita. Evita etichette vaghe come “Edge PCs” o “Browser Microsoft”, perché diventano ambigue al primo cambio di requisito. Inserisci nella descrizione il nome della classe usata, l’eventuale soglia di versione e la data dell’ultimo affinamento. Quando qualcuno dovrà manutenerla, queste informazioni risparmiano tempo e riducono il rischio di rompere una distribuzione esistente.Se la query è complessa, conserva una copia del criterio fuori dalla console, in un file di testo versionato o in un repository interno, con una nota sul perché è stata scelta quella sorgente dati. Non serve un documento lungo: bastano un paio di righe che dicano da dove arriva il dato e quali dispositivi devono entrare o restare fuori. È il modo più semplice per evitare che una raccolta utile diventi una scatola nera.Alla fine, creare una raccolta dispositivi Microsoft Edge in SCCM è facile solo in apparenza. La parte davvero importante è definire bene il perimetro, scegliere il dato giusto e verificare che la raccolta rappresenti il parco macchine reale, non una fotografia approssimativa. Se la base è solida, poi tutto il resto viene da sé: distribuzioni mirate, report puliti e meno tempo perso a inseguire falsi positivi.