Query SCCM per creare una raccolta di PC x86 e x64

In SCCM la distinzione tra client x86 e x64 è una di quelle cose che sembrano banali finché non devi usarla davvero in una collection dinamica. Il punto non è solo scrivere una query che filtri per architettura: serve capire quale attributo interrogare, in quale classe WQL vive, e soprattutto come evitare raccolte che si popolano male quando l’hardware inventory non è allineato o quando il sistema operativo gira a 64 bit ma alcune proprietà espongono ancora nomi fuorvianti.

Se l’obiettivo è creare due raccolte, una per PC x86 e una per PC x64, la strada più pulita è partire da System Resource e verificare la proprietà System Type. In molti ambienti viene popolata con valori come “x64-based PC” e “x86-based PC”. È semplice, leggibile e in genere abbastanza stabile per una query di membership rule. Però non è l’unico campo possibile, e non sempre è il più robusto se il parco macchine è eterogeneo o se hai macchine virtuali, immagini legacy e inventario hardware incompleto.

La query giusta dipende dal dato, non dal nome della macchina

In SCCM/ConfigMgr la raccolta dinamica non ragiona “come un amministratore”, ragiona sulla WQL e sulle classi esposte dal provider. Per questo la prima verifica da fare è guardare il dato reale disponibile nella console, non assumere che “x64” significhi sempre la stessa cosa in ogni tabella.

Per le workstation Windows gestite correttamente, una query tipica usa la classe SMS_R_System e il campo SystemType. La distinzione funziona bene quando il valore restituito è coerente con l’architettura del sistema operativo installato. In pratica: se il PC è a 64 bit, il valore atteso è x64-based PC; se è a 32 bit, x86-based PC.

Questa è la base più usata perché è facile da leggere e da mantenere. Ma in ambienti misti conviene sempre validare anche un secondo indicatore, ad esempio OperatingSystemArchitecture quando disponibile nel tuo schema, oppure un attributo hardware inventory più specifico. Il motivo è semplice: alcune proprietà sono derivate dal sistema inventariato, altre dal BIOS/firmware, altre ancora dal modo in cui ConfigMgr ha normalizzato il record. Se il dato a monte è sporco, la collection eredita lo sporco.

Query WQL per una raccolta x64

Se vuoi una collection dinamica per i client a 64 bit, la query più lineare è questa:

select SMS_R_System.ResourceID,
       SMS_R_System.ResourceType,
       SMS_R_System.Name,
       SMS_R_System.SMSUniqueIdentifier,
       SMS_R_System.ResourceDomainORWorkgroup,
       SMS_R_System.Client
from SMS_R_System
where SMS_R_System.SystemType = "x64-based PC"

Questa membership rule è leggibile e facile da debuggare. Se la collection resta vuota, il problema in genere non è la sintassi, ma il valore presente nel record inventariato. Per questo, prima di cambiare la query, va controllato almeno un device campione in console o direttamente sul DB di report, se il tuo processo operativo lo consente.

Per fare una verifica rapida lato SQL reporting, puoi cercare i valori effettivi memorizzati nei record dei sistemi. In ambienti grandi è utile perché ti fa vedere subito se il campo contiene davvero x64-based PC o se trovi varianti inattese, spazi, record incompleti o dispositivi non ancora inventariati.

select top 50 Name0, SystemType0
from v_R_System
where SystemType0 is not null
order by Name0

Se il campo restituisce valori coerenti, la query WQL sopra è sufficiente. Se invece il dato è sporco, conviene correggere la sorgente: inventario hardware, task sequence, client policy o eventuale remediation del parco macchine.

Query WQL per una raccolta x86

Per la raccolta dei sistemi a 32 bit, la struttura è identica, cambia solo il valore del filtro:

select SMS_R_System.ResourceID,
       SMS_R_System.ResourceType,
       SMS_R_System.Name,
       SMS_R_System.SMSUniqueIdentifier,
       SMS_R_System.ResourceDomainORWorkgroup,
       SMS_R_System.Client
from SMS_R_System
where SMS_R_System.SystemType = "x86-based PC"

Qui la trappola classica è confondere architettura del sistema operativo con architettura del processore o con il tipo di applicazione installata. Un PC Windows a 64 bit può eseguire software x86, ma questo non lo rende un client x86. La collection deve riflettere l’architettura della macchina, non quella dei binari che ospita.

Se invece ti serve una raccolta per targettare pacchetti o applicazioni in base alla piattaforma, a volte è meglio usare una query su Operating System o su una custom collection basata su una query di inventario hardware più specifica. Dipende dal caso d’uso: distribuzione software, compliance, esclusione di legacy app, oppure separazione per immagini OS.

Come creare la collection in console senza farsi fregare dai dettagli

In console, il percorso tipico è semplice: Assets and Compliance > Device Collections > Create Device Collection. Il passaggio importante non è la creazione in sé, ma il modo in cui imposti la membership rule.

1. Apri Create Device Collection e assegna un nome esplicito, ad esempio PC x64 o PC x86.
2. Scegli un limiting collection coerente, di solito una parent collection ampia ma controllata, come All Systems o una collection di produzione separata da lab e test.
3. Aggiungi una Query Rule e incolla la WQL con il filtro corretto su SystemType.
4. Abilita il refresh schedule in base al bisogno: manuale, periodico o incrementale, valutando il carico sul provider e sui tempi di aggiornamento delle membership.
5. Salva e fai un Update Membership manuale per il primo controllo.

Qui il dettaglio operativo che spesso viene trascurato è il limiting collection. Se limiti la collection in modo troppo stretto, puoi avere il risultato formalmente corretto ma con membership parziale. Se la limiti in modo troppo largo, aumenti il rumore e il tempo di valutazione. In ambienti grandi questa scelta incide più della query stessa.

Verifica pratica: cosa controllare se la collection resta vuota

Quando la membership non si popola, il problema quasi mai è la sintassi WQL. Più spesso è uno di questi tre casi: il campo non contiene il valore atteso, l’hardware inventory è vecchio, oppure il device non è ancora valutato dal provider.

1. Controlla il device in console e verifica che compaia come Client = Yes. Se non è client, non aspettarti un record utile per una collection standard.
2. Apri le proprietà del device e cerca il valore System Type. Se il campo non è visibile nella vista corrente, usa una query o un report che mostri il dato inventariato.
3. Forza un Machine Policy Retrieval & Evaluation Cycle sul client, poi aggiorna la membership della collection.
4. Se il dato resta incoerente, controlla l’inventario hardware e i log del client, in particolare i file di inventory e policy, per capire se il record è stato riportato correttamente al site server.

Per una verifica CLI sul client Windows, puoi usare il log di inventario o i dati WMI locali. Non serve andare pesante: basta capire se il sistema si presenta davvero come x86 o x64 nella sessione locale. Un controllo rapido con WMI/CIM è spesso sufficiente per isolare il problema prima di toccare la collection.

wmic os get osarchitecture

Il risultato atteso è qualcosa come 64-bit o 32-bit. Se il sistema locale dice una cosa e SCCM ne mostra un’altra, il problema è quasi certamente nella pipeline di inventory, non nella query della collection.

Alternativa più robusta: filtrare su una classe inventariata esplicita

In alcuni ambienti conviene evitare il solo SystemType e costruire la collection su un attributo inventariato più esplicito, soprattutto se vuoi usarla per compliance o per deployment critici. Il motivo è che alcuni campi sintetici possono essere aggiornati con ritardo o essere meno trasparenti da auditare.

Se hai abilitato l’inventario hardware per classi aggiuntive, puoi utilizzare una query sulla classe corretta del tuo schema, ad esempio per leggere la proprietà dell’architettura del sistema operativo. La logica resta la stessa: individuare il campo affidabile, poi usarlo come criterio di membership. La differenza è che il dato diventa più difendibile in fase di troubleshooting e meno dipendente da una singola etichetta testuale.

Un approccio pratico è questo: prima crei la collection basata su SystemType, poi confronti un campione di device con un report SQL o con un export della console. Se il delta tra i due mondi è nullo, hai un criterio affidabile. Se il delta cresce, hai una pista concreta da seguire: inventory, client health, policy, oppure problemi di valorizzazione del dato.

Query pronte da riusare e variante con collezione esclusiva

In alcuni casi non vuoi una collection separata x86/x64, ma una collection che escluda una delle due architetture. Ad esempio, se devi distribuire un pacchetto solo ai sistemi x64, puoi usare la query precedente oppure costruire una collezione di esclusione per evitare sovrapposizioni in più deployment.

Una variante utile è la raccolta “non x64”, ma va usata con attenzione: se il campo contiene valori inattesi o null, rischi di includere device che non dovrebbero esserci. Per questo, nel dubbio, meglio fare raccolte esplicite e poi usare una collection di esclusione ben definita per i casi borderline.

select SMS_R_System.ResourceID,
       SMS_R_System.Name
from SMS_R_System
where SMS_R_System.SystemType <> "x64-based PC"
  and SMS_R_System.Client = 1

Questa forma è comoda, ma non è sempre quella migliore. Il motivo è semplice: un filtro negativo dipende dalla qualità dell’intero dataset, mentre un filtro positivo dipende solo dai device che corrispondono al valore atteso. In ambienti con inventario sporco, il positivo è quasi sempre più sicuro.

Quando la query è corretta ma i risultati sono sbagliati

Se la WQL è sintatticamente corretta ma la membership non coincide con la realtà, i colpevoli più probabili sono tre: inventario incompleto, ritardo nella valutazione della collection, oppure client non sano. In un contesto SCCM questo è normale, non eccezionale.

1. Inventario incompleto: il record non è stato aggiornato. Verifica il cycle di hardware inventory e il timestamp dell’ultima sincronizzazione.
2. Refresh della collection: la rule è giusta ma non ancora ricalcolata. Forza un update e osserva l’esito della membership.
3. Client health: il device è online ma non riceve policy o non invia dati. Controlla i log del client e lo stato di comunicazione col management point.

Se vuoi ridurre il rischio operativo, tieni separati i gruppi di test da quelli di produzione e non usare subito la collection per deployment critici. Prima fai un confronto numerico: quanti device ti aspetti, quanti ne ottieni, quanti sono coerenti con un campione manuale. È un controllo semplice, ma evita errori che poi si pagano in patching o software rollout.

Scelta consigliata in pratica

Se ti serve una risposta operativa e non teorica, la scelta consigliata è questa: usa SystemType per la maggior parte dei casi, crea due collection esplicite con query positive, valida il dato su un campione di device, poi passa a un criterio più robusto solo se il tuo ambiente mostra incoerenze reali. È la strada più pulita tra semplicità, manutenzione e affidabilità.

In altre parole: non complicare la query finché il dato a monte è sano. In SCCM il 90% dei problemi sulle collection non nasce dalla WQL, ma dal fatto che si sta interrogando un inventario non ancora affidabile. La query serve a selezionare; il lavoro vero è far sì che il dato selezionato sia corretto.

Se l’obiettivo è separare i PC x86 e x64 per deployment, reporting o governance, parti da queste due query, verifica il valore reale con un campione e poi standardizza il naming delle collection. Una convenzione chiara, tipo COL-OS-x64 e COL-OS-x86, riduce errori umani e rende più leggibili le regole di distribuzione successive.

Il punto non è solo “far funzionare la query”. Il punto è fare in modo che chi eredita l’ambiente tra sei mesi capisca subito perché quella collection esiste, quale dato la alimenta e dove guardare se smette di popolarsi. In SCCM questo vale più della formula perfetta.