Come recuperare tutte le query in SCCM con SQL

Recuperare le query in SCCM significa partire dal punto giusto

Se l’obiettivo è recuperare tutte le query in SCCM, la domanda vera non è solo “dove sono?”. In Configuration Manager le query possono vivere in più strati: console, oggetti WMI, database SQL e, in certi casi, esportazioni o report già creati. Quindi il recupero corretto dipende da cosa intendi per “tutte”: le query visibili nella console, quelle personalizzate, quelle salvate nei report, oppure anche le query usate internamente da collezioni e strumenti di amministrazione.

La distinzione conta perché in SCCM non sempre una query è un file facilmente leggibile. Spesso è un oggetto del sito, con metadati, limiti di sicurezza e dipendenze dalla versione del prodotto. Il modo più pulito per estrarle è partire dalla console, poi validare con SQL solo quando serve davvero. Così eviti di confondere le query dell’admin con i dati di configurazione effettivi.

In pratica, il recupero va fatto su tre livelli: ciò che è esposto all’operatore, ciò che è modellato dal provider WMI e ciò che è persistito nel database del site server. Se salti uno di questi livelli, il risultato è quasi sempre incompleto.

Dove si trovano le query in SCCM

Le query “classiche” create in console si trovano normalmente sotto Assets and Compliance e poi nella sezione Queries. Da lì puoi vedere quelle create dagli amministratori e quelle eventualmente distribuite tramite procedure operative interne. Ma non basta aprire la console: se devi fare inventario completo, devi considerare anche gli oggetti legati alle collezioni, ai report e alle regole di membership che usano logica simile a una query.

In pratica, i punti da controllare sono questi:

• Console SCCM: elenco delle query salvate e gestite dall’interfaccia.
• WMI del sito: oggetti amministrativi che espongono query e metadati.
• Database SQL del site server: utile per estrazione massiva e verifica incrociata.
• Collection membership rules: non sono “query” in senso stretto, ma spesso contengono condizioni equivalenti.

Se stai facendo recovery o audit, questa mappa ti evita il classico errore: cercare solo nella console e perdere parte della configurazione realmente in uso.

Metodo più rapido: esportare dalla console SCCM

Per una ricognizione operativa, il primo passo è usare la console. È il metodo meno invasivo e quello con meno ambiguità, perché leggi l’oggetto così come lo vede l’amministratore del sito.

1. Apri la console SCCM.
2. Vai in Assets and Compliance > Queries.
3. Ordina per nome, autore o cartella se la tua organizzazione usa una tassonomia interna.
4. Apri le query una per una e copia la definizione.
5. Se serve un inventario strutturato, esporta con procedura interna o usa gli strumenti di script disponibili nel tuo ambiente.

Qui il controllo minimo è banale ma utile: la query deve risultare visibile in console, modificabile se hai i permessi, e con testo coerente con il workflow aziendale. Se non la vedi in console, non dare per scontato che non esista: potrebbe essere in un altro scope, in un altro sito o legata a permessi RBAC che la nascondono.

Osservazione pratica: in ambienti grandi, molte query vengono duplicate con nomi quasi identici. Prima di esportare, conviene normalizzare nomi e cartelle, altrimenti il recupero produce un elenco tecnicamente corretto ma poco utile per chi dovrà manutenerlo.

Estrazione massiva con WMI: il punto giusto quando la console non basta

Se devi recuperare molte query insieme, o vuoi automatizzare l’operazione, WMI è spesso il primo canale sensato. Non è il più “amichevole”, ma è quello che permette di leggere gli oggetti di configurazione senza passare dall’interfaccia grafica. Il vantaggio è soprattutto operativo: puoi ripetere la raccolta, confrontare ambienti diversi e creare un archivio versionato.

Il principio è questo: interroghi il namespace del sito SCCM e cerchi le classi che rappresentano query e oggetti correlati. Il namespace varia in base al site code, quindi devi partire dall’istanza corretta del tuo ambiente. In molti casi ti serve anche il permesso amministrativo adeguato sul site server o sul sistema da cui esegui la query WMI.

Un controllo preliminare utile è verificare che il namespace sia raggiungibile e che l’account abbia accesso. Se questo fallisce, il problema non è la query: è il livello di autorizzazione o la connettività verso il provider SMS.

Get-WmiObject -Namespace root\SMS\site_ABC -Class SMS_Query -ComputerName site-server

Se il tuo ambiente usa PowerShell moderno, puoi usare anche Get-CimInstance al posto di Get-WmiObject. L’importante è verificare che il risultato contenga i campi attesi, per esempio nome, oggetto query e identificativi coerenti con il sito.

Un esempio di controllo rapido è questo:

Get-CimInstance -Namespace root\SMS\site_ABC -ClassName SMS_Query -ComputerName site-server | Select-Object Name, QueryID, QueryExpression

Se la classe non risponde, la falsificazione è semplice: namespace errato, permessi insufficienti o provider non funzionante. In meno di cinque minuti lo capisci con un test mirato sul namespace e un controllo dei log del provider, invece di inseguire il database SQL a caso.

Recuperare le query direttamente da SQL quando serve un inventario completo

Il database SQL entra in gioco quando vuoi un’estrazione completa, ripetibile e confrontabile. È il canale giusto per un audit, per una migrazione o per una verifica incrociata tra console e oggetti effettivamente persistiti. Qui però bisogna essere precisi: non tutte le informazioni che vedi in console sono comode da leggere in SQL, e non tutte le tabelle sono pensate per essere consultate manualmente.

La strategia corretta è partire dalla ricerca degli oggetti legati alle query nel database del site server, usando viste o tabelle del modello dati SCCM. Il nome esatto delle tabelle può variare in base alla versione e al tipo di oggetto, quindi non conviene indovinare: conviene cercare i campi descrittivi e i riferimenti alle query memorizzate.

Un approccio pratico è interrogare il database con una selezione limitata, così da capire dove sono salvati i metadati e il testo della query.

SELECT TOP 50 * FROM v_ConfigurationItems WHERE ModelName LIKE '%Query%'

Se questa query non restituisce nulla, non significa che le query non esistano: può voler dire che stai cercando nel punto sbagliato del modello dati. In quel caso il passo successivo è cercare viste o tabelle collegate a oggetti di amministrazione, collezioni o report, usando i nomi esposti dal catalogo del database.

Per evitare confusione, il controllo finale deve sempre essere doppio: il testo estratto da SQL deve coincidere con quello che vedi in console o via WMI. Se i valori differiscono, il problema può essere caching, scope RBAC, oggetti non aggiornati o un ambiente non allineato.

Query delle collection: non sono la stessa cosa, ma spesso vanno recuperate insieme

Molti amministratori cercano “le query SCCM” e in realtà intendono anche le regole di membership delle collection. È un errore comprensibile, perché la logica è simile: c’è una condizione, c’è un risultato atteso, e spesso il testo assomiglia a una query SQL o WQL.

Per recuperarle devi aprire le collection interessate e leggere le regole di membership. Qui il recupero non è solo archivistico: serve anche a capire se una collection dinamica dipende da una query che, a sua volta, va salvata e documentata.

• Direct membership: non contiene una query, quindi non va trattata come tale.
• Query-based membership: contiene una logica da recuperare e versionare.
• Include/Exclude: non sono query pure, ma influenzano il risultato finale e vanno annotate.

Se l’obiettivo è un backup logico della configurazione, recuperare solo le query salvate in “Queries” non basta. Devi includere anche quelle usate per costruire collezioni critiche, perché sono spesso quelle che impattano davvero su deployment e targeting.

Verifica del contesto: nome, scope, versione e permessi

Una query recuperata senza contesto è poco utile. Prima di archiviarla, conviene salvare almeno quattro informazioni: nome dell’oggetto, sito di appartenenza, scope RBAC e versione del client/console o del site server che l’ha generata. Questo evita il classico problema del “funziona nel vecchio ambiente ma non nel nuovo”.

Se stai migrando o consolidando siti, il contesto diventa ancora più importante: due query con lo stesso nome possono avere testo diverso, oppure la stessa query può comportarsi diversamente per via di permessi o di differenze di schema.

Una query SCCM non è solo testo SQL o WQL: è un oggetto amministrativo con dipendenze operative. Recuperarla bene significa conservare anche il suo contesto.

Per questo motivo, il risultato finale non dovrebbe essere un semplice copia-incolla, ma un inventario con almeno questi campi: nome, descrizione, testo, origine, data di estrazione e metodo usato per recuperarla.

Automatizzare l’estrazione senza perdere affidabilità

Se il recupero va fatto spesso, ha senso automatizzarlo con PowerShell o con una procedura SQL controllata. L’errore da evitare è costruire uno script che estrae solo il testo e ignora metadati e controlli. Un export utile deve essere ripetibile e verificabile.

Una sequenza minima sensata è questa:

1. Verifica accesso alla console o al provider WMI.
2. Estrai l’elenco oggetti con identificativi stabili.
3. Salva il testo in formato leggibile, per esempio CSV o JSON, insieme ai metadati.
4. Confronta un campione con la console per controllare che il recupero sia coerente.

Se lavori in ambienti con molte query, conviene anche introdurre una normalizzazione del nome file o del record esportato. Senza questa pulizia, il tuo archivio cresce ma diventa difficile da usare.

Problemi tipici durante il recupero

Ci sono alcuni casi ricorrenti che fanno sembrare “persa” una query quando in realtà il problema è altrove.

• RBAC: l’oggetto esiste ma non è visibile per il tuo ruolo.
• Namespace WMI errato: stai interrogando il site code sbagliato.
• Replica o sincronizzazione incompleta: console e database non sono allineati.
• Query duplicate: hai trovato una versione, ma non quella effettivamente usata.
• Oggetti correlati: la logica è in una collection, non nella sezione Queries.

Il modo corretto per falsificare queste ipotesi è semplice: controlla la visibilità in console, verifica il namespace WMI con un test diretto e confronta il testo estratto con un campione noto. Se uno di questi passaggi fallisce, hai già ristretto il problema senza toccare la configurazione.

Metodo consigliato per non perdere nulla

Se vuoi davvero recuperare tutte le query in SCCM senza lasciare buchi, la sequenza migliore è questa:

1. Esporta o copia le query visibili in console.
2. Recupera via WMI i metadati e il testo degli oggetti amministrativi.
3. Usa SQL per un controllo incrociato e per trovare eventuali oggetti non emersi dagli altri canali.
4. Includi le query delle collection e annota quelle che influenzano il targeting.
5. Conserva sempre il contesto: sito, scope, versione e data di estrazione.

Questo approccio riduce gli errori perché non si affida a una sola vista del sistema. SCCM è un prodotto a strati, quindi anche il recupero va fatto a strati.

Se il tuo obiettivo è documentare o migrare, il risultato finale migliore è un archivio strutturato e verificabile, non una raccolta disordinata di stringhe. In altre parole: recuperare tutte le query in SCCM non significa solo leggerle, ma renderle riutilizzabili senza perdere significato operativo.