1 12/04/2026 10 min

Creare una raccolta dispositivi SCCM per Windows Server 2022

In SCCM la parte delicata non è tanto creare la raccolta, quanto fare in modo che la membership corrisponda davvero ai server attesi. Se la query è troppo larga, dentro finisce di tutto. Se è troppo stretta, ti perdi macchine valide e poi ti ritrovi a inseguire anomalie di inventario invece di gestire il parco server.

Per Windows Server 2022 la strada più pulita è partire dai dati già presenti in ConfigMgr: nome del sistema operativo, tipo di prodotto, stato client e, se serve, eventuali attributi aggiuntivi come dominio, OU o tag di naming. In pratica: prima definisci il perimetro, poi costruisci la query, poi verifichi con pochi esempi reali che il risultato sia quello atteso.

Qui sotto trovi un approccio operativo che evita i classici errori: usare il solo nome OS senza controllare il tipo di macchina, dimenticare l’aggiornamento della membership o creare una raccolta che si aggiorna troppo spesso senza bisogno.

Decidere il criterio: OS, versione e tipo dispositivo

Per Windows Server 2022 il primo filtro utile è il sistema operativo. In SCCM i campi più usati arrivano dalla classe SMS_R_System e dagli attributi inventariati dal client. Il dettaglio importante è non fermarsi al solo nome visualizzato, perché in ambienti misti puoi avere risultati fuorvianti se fai matching troppo generico.

In genere conviene verificare almeno questi elementi:

  • nome OS che contenga Windows Server 2022;
  • tipo di prodotto coerente con un server e non con una workstation;
  • client SCCM installato e online, se la raccolta serve per deploy o compliance;
  • eventuale esclusione di ambienti di test o lab, se il naming lo consente.

Se hai bisogno di una raccolta “pulita” per patching o distribuzione software, è meglio essere conservativi. Una raccolta che include un server sbagliato crea più danni di una macchina mancante, perché può ricevere contenuti o policy non previste.

Creazione della raccolta dalla console SCCM

La procedura da console è la più sicura per chi lavora già dentro il pannello di Configuration Manager. Il vantaggio è che puoi verificare subito il query preview e il tipo di aggiornamento della membership.

  1. Apri la console SCCM e vai in Assets and Compliance > Device Collections.
  2. Seleziona il nodo corretto dove vuoi creare la raccolta, ad esempio una cartella per server o per ambiente.
  3. Fai clic su Create Device Collection.
  4. Assegna un nome chiaro, per esempio COL - Windows Server 2022.
  5. Imposta il Limiting Collection. Di solito conviene partire da una collezione ampia ma controllata, come i dispositivi server già censiti.
  6. Scegli il tipo di aggiornamento: Incremental updates solo se ti serve quasi in tempo reale; altrimenti meglio aggiornamento pianificato per ridurre carico inutile.
  7. Apri la sezione delle Membership Rules e crea una Query Rule.

La scelta della limiting collection non è un dettaglio. Se limiti la ricerca a una raccolta troppo piccola, la query non troverà nulla anche se i server esistono nel database. Se la limiti a una raccolta enorme e non filtrata, allarghi il perimetro più del necessario. Il punto giusto è una collezione già coerente con il ruolo dei dispositivi.

Query WQL di base per Windows Server 2022

Una query di partenza semplice, ma già utile, può cercare il nome del sistema operativo e filtrare sui server. Esempio:

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
inner join SMS_G_System_OPERATING_SYSTEM
    on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceID
where SMS_G_System_OPERATING_SYSTEM.Caption like "%Windows Server 2022%"

Questa query è utile quando il campo Caption è popolato correttamente. Però in molti ambienti conviene essere più rigorosi e aggiungere un filtro sul client o sul tipo di macchina, così riduci il rumore e i casi ambigui.

Se vuoi una variante un po’ più prudente, puoi aggiungere il controllo sul client attivo:

select SMS_R_System.ResourceID,
       SMS_R_System.Name,
       SMS_R_System.Client,
       SMS_G_System_OPERATING_SYSTEM.Caption
from SMS_R_System
inner join SMS_G_System_OPERATING_SYSTEM
    on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceID
where SMS_G_System_OPERATING_SYSTEM.Caption like "%Windows Server 2022%"
  and SMS_R_System.Client = 1

Questa seconda versione evita di includere oggetti non gestiti dal client, che possono essere presenti nel database ma non adatti a un deployment operativo. Se la tua politica richiede solo server con agent installato e sano, è il filtro minimo sensato.

Verificare la query prima di pubblicarla

La verifica migliore non è “sembra giusta”, ma “restituisce i server giusti”. In SCCM puoi usare il Query Statement e il preview della membership per controllare se i risultati corrispondono ai nomi attesi.

  1. Apri la query della collection.
  2. Usa il pulsante di Run Now o il refresh della collection, se previsto dal tuo workflow.
  3. Controlla i primi host inclusi: devono essere server reali con Windows Server 2022, non workstation o VM di test.
  4. Se i risultati sono pochi o zero, verifica prima la limiting collection, poi i dati inventariati, poi il campo usato nella query.

Un controllo rapido da lato database, se hai accesso amministrativo al sito SCCM, è utile per capire se il problema sta nella raccolta o nei dati. Non è un passaggio obbligatorio per tutti, ma in troubleshooting fa risparmiare tempo quando la console non basta a spiegare il comportamento.

-- Esempio concettuale: validare che il campo OS sia popolato nel database del sito
SELECT TOP 20
       sys.Name0,
       os.Caption0,
       sys.Client0
FROM v_R_System sys
JOIN v_GS_OPERATING_SYSTEM os
  ON os.ResourceID = sys.ResourceID
WHERE os.Caption0 LIKE '%Windows Server 2022%'

Se la vista SQL restituisce risultati ma la collection no, il problema è quasi sempre nella query WQL, nella limiting collection o nei tempi di aggiornamento della membership. Se invece anche la vista SQL è vuota, il problema è nei dati di inventario o nel fatto che i client non hanno ancora aggiornato l’informazione OS.

Quando conviene usare attributi aggiuntivi

In ambienti grandi, la sola stringa “Windows Server 2022” non basta sempre. Puoi voler separare i server per ruolo, sito, dominio o ambiente. SCCM non è un CMDB perfetto, quindi se i dati di naming sono puliti puoi sfruttarli; se sono sporchi, meglio non costruire regole fragili sopra di essi.

Per esempio, se i server di produzione hanno un prefisso coerente, puoi aggiungere una condizione sul nome:

where SMS_G_System_OPERATING_SYSTEM.Caption like "%Windows Server 2022%"
  and SMS_R_System.Name like "PRD-%"

Questo approccio è utile, ma va trattato come una dipendenza operativa. Se il naming cambia o qualcuno sbaglia prefisso, la raccolta perde precisione. Per questo conviene documentare la regola e non affidarsi a convenzioni non controllate.

Gestione dell’aggiornamento membership

La raccolta può essere statica oppure dinamica. Per Windows Server 2022 in genere ha senso una query membership dinamica, perché i server possono essere aggiunti, riclassificati o rebuildati senza intervento manuale. Però l’aggiornamento incrementale va usato con criterio: non sempre serve, e in ambienti grandi può aumentare il rumore operativo.

Regola pratica:

  • incremental updates se devi reagire rapidamente a nuovi server o cambi di inventario;
  • scheduled full update se la raccolta serve per report, compliance o gruppi abbastanza stabili;
  • evita di combinare troppe regole complesse se non hai una reale necessità operativa.

Se il tuo obiettivo è distribuire software o aggiornamenti critici, la latenza della membership conta. Se invece stai costruendo un gruppo di reporting, una finestra di aggiornamento più larga è spesso sufficiente e più sana per il sito SCCM.

Problemi tipici e come riconoscerli

Il caso più comune è una raccolta vuota. Di solito non significa che non esistano Windows Server 2022, ma che uno dei tre punti sotto non è allineato: la query, la limiting collection o l’inventario client.

  1. Query troppo stretta: il campo usato non matcha il valore reale. Verifica il contenuto di Caption o del campo equivalente nella vista SQL.
  2. Limiting collection errata: la collection madre non contiene i dispositivi cercati. Controlla la membership della collezione limitante prima di cambiare la query.
  3. Dati non aggiornati: il client non ha ancora riportato l’OS corretto. Verifica la policy di hardware inventory e l’ultimo ciclo di policy retrieval sul client.

Un’altra situazione frequente è l’inclusione di macchine sbagliate, soprattutto in ambienti virtualizzati o con immagini standardizzate. Se il nome del sistema operativo non viene inventariato in modo coerente, la query può agganciare versioni sbagliate o sistemi con naming ambiguo. In quel caso conviene introdurre un secondo filtro o correggere il dato alla fonte.

Validazione lato client e lato sito

Quando la raccolta non si comporta come previsto, controlla prima il client e poi il sito. Sul server Windows il punto d’ingresso utile è il log dell’agent SCCM; sul sito, invece, puoi guardare i log di valutazione della membership e le viste SQL correlate.

Per il client, una verifica rapida può essere questa:

Get-WmiObject -Namespace root\ccm -Class CCM_ClientUtilities | Select-Object *

Non è il comando risolutivo per la query della collection, ma ti aiuta a capire se il client è operativo e risponde. Se il client è degradato, l’inventario può essere vecchio e la membership rimane incoerente rispetto allo stato reale del server.

Sul lato sito, i log da tenere d’occhio dipendono dalla versione e dal ruolo, ma il concetto resta identico: verificare se la valutazione della collection viene eseguita, se la query è valida e se l’oggetto viene incluso o scartato per un motivo preciso.

Versione consigliata della raccolta per uso operativo

Se devi creare una raccolta da usare davvero, non solo per esercizio, la formula più solida è questa: nome chiaro, limiting collection coerente, query su Windows Server 2022, client attivo, aggiornamento pianificato o incrementale in base al bisogno. Nella maggior parte dei casi non serve inventare filtri complicati.

Una struttura pratica potrebbe essere:

COL - Windows Server 2022 - Prod
COL - Windows Server 2022 - Test
COL - Windows Server 2022 - All Managed

Separare produzione, test e parco completo ti evita di distribuire policy con lo stesso target a contesti diversi. È una banalità solo fino al giorno in cui una baseline o un aggiornamento va sulla macchina sbagliata.

Snippet di query più robusta

Se vuoi una base un po’ più rigorosa, puoi usare una query con doppio controllo su OS e client. Adattala al tuo ambiente prima di metterla in produzione:

select SMS_R_System.ResourceID,
       SMS_R_System.Name,
       SMS_R_System.Client,
       SMS_G_System_OPERATING_SYSTEM.Caption
from SMS_R_System
inner join SMS_G_System_OPERATING_SYSTEM
    on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceID
where SMS_G_System_OPERATING_SYSTEM.Caption like "%Windows Server 2022%"
  and SMS_R_System.Client = 1
  and SMS_R_System.Name not like "LAB-%"

Il filtro not like sul naming è opzionale, ma utile se hai un prefisso affidabile per escludere i laboratori. Se non hai una convenzione stabile, meglio non usarlo: una regola fragile è peggio di nessuna regola.

Checklist finale prima del rilascio

  1. La limiting collection contiene davvero i server che vuoi targettizzare.
  2. La query restituisce solo Windows Server 2022 e non workstation o host ambigui.
  3. La membership si aggiorna con la frequenza adatta al tuo caso d’uso.
  4. Hai verificato almeno un host reale nella console prima di distribuire policy o applicazioni.
  5. Se hai usato naming o tag aggiuntivi, la convenzione è documentata e mantenuta nel tempo.

Assunzione: la collection viene usata per gestione operativa in un ambiente SCCM già funzionante, con inventario client attivo e accesso alla console o alle viste SQL per la verifica.