Creare raccolte SCCM basate sulle OU di Active Directory

Le raccolte in SCCM non dovrebbero essere usate come semplice contenitore “per reparto”, ma come strumento operativo per distribuire software, applicare compliance e controllare il perimetro di un deployment. Quando il criterio organizzativo è l’OU di Active Directory, la scelta va fatta con attenzione: l’OU è utile come filtro iniziale, ma non sempre coincide con il reale stato operativo dei client. In pratica, conviene costruire la raccolta in modo che l’appartenenza all’OU sia verificata sui sistemi presenti in inventario e non come assunzione statica.

Il punto chiave è questo: SCCM non “legge” direttamente le OU come farebbe un amministratore guardando ADUC. Le raccolte si basano su query WQL verso le classi del database di ConfigMgr, quindi bisogna interrogare gli attributi giusti del client o del computer account. Il risultato migliore si ottiene combinando una query robusta, un aggiornamento della membership ben calibrato e una nomenclatura coerente, così da evitare raccolte che sembrano corrette ma poi includono host fuori target o, peggio, escludono macchine appena spostate di OU.

Quando ha senso usare l’OU come criterio di raccolta

L’OU ha senso quando l’organizzazione usa Active Directory come fonte primaria di segmentazione: postazioni per sede, per funzione, per ambiente o per gruppo di gestione. In questi casi puoi creare raccolte dedicate a un dominio amministrativo ben definito, ad esempio una OU per i PC di un ufficio, una per i kiosk, una per i server di test o una per gli endpoint dei reparti che hanno policy specifiche.

Non ha invece molto senso se le OU sono usate in modo disordinato, se i computer vengono spostati spesso senza una disciplina precisa, o se l’assetto AD non riflette la reale gestione dei dispositivi. In quei casi la raccolta basata su OU diventa fragile e conviene valutare criteri più stabili, come collezioni basate su membership di gruppo, naming convention, query su Active Directory Site, oppure una combinazione di più attributi.

Prima di costruire la raccolta, chiarisci sempre l’obiettivo operativo: vuoi fare un deployment una tantum, una baseline ricorrente o una segmentazione amministrativa permanente? La risposta cambia il livello di rigidità della query e la frequenza con cui la membership deve aggiornarsi.

Attributo corretto da usare: distingui OU del computer e OU dell’utente

In ConfigMgr bisogna distinguere il computer account dall’utente. Se stai creando raccolte per distribuire software ai dispositivi, l’attributo da usare deve riferirsi al sistema, non all’utente che accede. È un errore comune costruire una raccolta che “sembra” legata al reparto ma che in realtà si basa sugli utenti presenti in una OU di persone: il deployment finisce su macchine sbagliate o perde consistenza quando il personale cambia ruolo.

La strada più pulita è verificare quale classe espone l’informazione di OU nel tuo ambiente. In molti casi si lavora con informazioni di discovery derivanti da Active Directory System Discovery, che popola attributi utili nel database di ConfigMgr. Se l’attributo non è disponibile nella console o nella query builder, non forzarlo: prima controlla quali campi sono effettivamente valorizzati nel sito.

Un metodo pratico è aprire le proprietà del computer nell’area Assets and Compliance, verificare i dettagli della risorsa e capire se il percorso AD viene riportato in un campo interrogabile. Se il dato non compare, il problema non è la raccolta ma la discovery. In quel caso va chiuso prima il gap a monte, altrimenti la query resterà vuota o incoerente.

Procedura consigliata per creare la raccolta

La procedura più affidabile è creare una raccolta device-based, aggiungere una query di membership e poi validare il risultato con un sottoinsieme di test. Evita di partire con una raccolta “tutto il dominio” e restringerla dopo: è il modo più rapido per ritrovarti con migliaia di client non attesi in un deployment.

Se vuoi ridurre il rischio operativo, crea prima una raccolta di test con pochi client noti. Una volta confermata la correttezza della query, puoi clonarla e adattarla alla raccolta definitiva. È un approccio più lento solo all’inizio; poi ti evita debugging inutili quando una distribuzione non parte o parte sul parco sbagliato.

Esempio di query WQL basata su OU

La sintassi esatta dipende dal campo disponibile nel tuo database ConfigMgr, ma il principio è sempre lo stesso: filtrare i computer in base al percorso OU memorizzato nei dati di discovery. In alcune installazioni il dato è presente come distinguished name o come percorso LDAP equivalente. L’obiettivo è intercettare il segmento di OU che ti interessa senza dipendere da una stringa troppo fragile.

Un esempio concettuale di query, da adattare ai nomi reali delle classi e degli attributi del tuo ambiente, può essere questo:

select SMS_R_System.ResourceID, SMS_R_System.Name, SMS_R_System.Client from SMS_R_System
inner join SMS_G_System_SYSTEM on SMS_G_System_SYSTEM.ResourceID = SMS_R_System.ResourceID
where SMS_G_System_SYSTEM.SystemOUName like "%OU=Milano%"

Questa forma è utile come modello, ma non va presa come universale: il nome dell’attributo può cambiare a seconda della versione, della discovery e di come il sito espone i dati. Prima di usarla in produzione, verifica nella query builder quale classe contiene davvero il campo OU e prova il filtro con un set ristretto di dispositivi noti.

Se vuoi essere più preciso, puoi filtrare anche per dominio o per una parte completa del distinguished name, ad esempio includendo l’intero ramo AD. È una scelta più sicura quando esistono OU con nomi simili in sedi diverse. Il rovescio della medaglia è che ogni modifica alla struttura AD richiederà un aggiornamento della query.

Membership rule: query dinamica o collezione intermedia

Per casi semplici, una query diretta è sufficiente. Per ambienti più grandi, invece, conviene spesso usare una collezione intermedia. Ad esempio, puoi creare una raccolta “staging” che intercetta tutti i client di una certa OU, e poi derivare da quella una raccolta più specifica per distribuzioni pilota, patching o software di reparto.

Questo approccio migliora la leggibilità e riduce il rischio di query troppo complesse. Inoltre ti permette di controllare meglio il blast radius: se un filtro viene scritto male, l’errore resta confinato nella collezione intermedia e non si propaga subito a tutti i deployment associati.

In pratica, la struttura può essere questa: una raccolta base per l’OU, una raccolta derivata per i client attivi e una terza raccolta per il deployment. Così puoi separare il criterio di appartenenza dal criterio operativo, che è quasi sempre la soluzione più pulita in SCCM.

Aggiornamento della membership: rapido ma non troppo

Se la membership si aggiorna troppo lentamente, dopo uno spostamento di OU puoi trovarti con client ancora presenti nella vecchia raccolta per diverse ore. Se si aggiorna troppo spesso, aumenti il carico sul sito senza un reale beneficio. Il compromesso va tarato in base alla criticità del deployment.

Per raccolte usate in distribuzioni sensibili, un aggiornamento incrementale può essere utile, ma va testato per capire se il sito regge bene il volume. Per collezioni meno critiche, una sincronizzazione pianificata è spesso più che sufficiente. La regola pratica è questa: prima osserva il comportamento del sito, poi stringi i tempi se il dato operativo lo giustifica.

Controlla sempre i log lato sito quando la membership non si aggiorna come previsto. I log più utili sono quelli di elaborazione collezioni e di valutazione delle query, perché ti dicono se il problema è la query, la discovery o il semplice ritardo di elaborazione.

Validazione pratica prima del deployment

La raccolta è pronta solo quando la verifichi su tre piani: contenuto, tempistica e coerenza con il target. Il contenuto è corretto se i device attesi sono presenti e quelli esclusi non compaiono. La tempistica è corretta se un cambio di OU si riflette entro il tempo atteso. La coerenza è corretta se la collezione resta stabile nel tempo e non “migra” per effetto di query troppo larghe.

Se qualcosa non torna, non correggere subito a colpi di esclusioni manuali. Prima individua se il problema sta nel dato di discovery, nella query o nel limiting collection. Le correzioni manuali sono utili per emergenze, ma non devono diventare la struttura portante della raccolta.

Errori tipici da evitare

Il primo errore è usare la OU come se fosse un gruppo di sicurezza. Non lo è. L’OU è una struttura amministrativa, non una membership autorizzativa. Se la usi come criterio unico per policy importanti, stai assumendo che la governance AD sia perfetta, e nella realtà quasi mai lo è.

Il secondo errore è costruire query troppo generiche, ad esempio basate su un semplice like su una stringa comune. Se hai OU simili in sedi diverse, rischi di includere sistemi non previsti. Il terzo errore è dimenticare la manutenzione: quando la struttura AD cambia, la raccolta va rivista, altrimenti il perimetro diventa obsoleto senza che nessuno se ne accorga.

Un altro punto da non sottovalutare è il naming. Se il nome della raccolta non dice chiaramente cosa intercetta, dopo sei mesi nessuno saprà più se quella collezione è per una sede, per un ambiente o per un progetto temporaneo. In SCCM i nomi vaghi diventano problemi operativi molto in fretta.

Una struttura pratica che funziona davvero

In ambienti reali, la struttura più solida è spesso questa: OU ben definita in AD, discovery corretta lato SCCM, raccolta base che intercetta i sistemi della OU, raccolta derivata per il pilot e raccolta finale per il deployment. È una catena semplice, ma solo se ogni anello è verificato con dati reali e non per supposizione.

Se devi partire da zero, il consiglio operativo è di creare prima una raccolta piccola, osservare come si popola, e solo dopo allargare il perimetro. È il modo più pulito per evitare effetti collaterali su software, patching e compliance. In un ambiente SCCM, una query corretta ma non testata è comunque una sorgente di rischio.

Assunzioni: l’ambiente usa Active Directory System Discovery, la console ConfigMgr è già operativa e la raccolta serve per dispositivi Windows gestiti da SCCM.