Creare raccolte SCCM per laptop: guida pratica

Creare raccolte SCCM per i laptop non significa solo “mettere dentro i portatili”. Se la membership è pensata male, finisci con deployment troppo larghi, policy incoerenti e troubleshooting inutile quando una macchina cambia stato, subnet o appartenenza a un gruppo AD. La parte davvero importante è definire un criterio stabile per riconoscere i laptop, separarlo bene dai desktop e poi mantenere la raccolta facile da verificare e da aggiornare.

© TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster — https://trgtkls.it — tutti i diritti riservati.

In pratica, la domanda da porsi è semplice: vuoi una raccolta basata su un attributo hardware affidabile, su un gruppo di Active Directory, su un naming convention, oppure su una combinazione di più segnali? La risposta cambia molto il risultato finale. Per ambienti piccoli può bastare un gruppo AD; in ambienti medi o grandi conviene quasi sempre una query di raccolta ben costruita, con un fallback chiaro per gli eccezionali.

Quando conviene creare una raccolta dedicata ai laptop

Una raccolta separata per i laptop torna utile quando devi distribuire software, impostazioni o aggiornamenti con criteri diversi rispetto ai desktop. I casi più comuni sono la cifratura, le VPN, i profili di alimentazione, i client Wi-Fi, il software per il roaming utente e alcune baseline di sicurezza pensate per dispositivi mobili.

Ha senso anche quando vuoi limitare il rischio operativo. Per esempio, se un pacchetto deve andare solo sui portatili gestiti fuori sede, una raccolta dedicata riduce la probabilità di colpire sistemi che non devono riceverlo. Lo stesso vale per i task sequence o per i deployment che dipendono da condizioni particolari, come la presenza di una docking station o di una VPN sempre disponibile.

Il punto critico è non confondere “laptop” con “computer che oggi sembrano portatili”. Un device può cambiare chassis, essere riclassificato o essere importato male in inventario. Se il criterio è debole, la raccolta diventa rumorosa e poco affidabile. Per questo conviene partire da un attributo il più possibile stabile e verificabile.

Classificazione del metodo: group, query o collezione annidata

In SCCM hai tre strade pratiche. La prima è usare un gruppo di Active Directory e popolare la raccolta con membership diretta. La seconda è una query basata su attributi del dispositivo, in genere la scelta più pulita per i laptop. La terza è una raccolta annidata, utile se hai già una base solida di device collection e vuoi costruire un livello logico sopra una collezione madre.

Se l’obiettivo è la gestione ordinaria, la query è spesso la soluzione migliore: è più leggibile, più facile da auditare e meno dipendente da operazioni manuali. Se invece il reparto endpoint usa già gruppi AD ben tenuti, puoi sfruttarli come ingresso, ma devi accettare che la qualità dipenda dalla disciplina di chi amministra quei gruppi.

La raccolta annidata ha senso quando vuoi creare una logica a strati: per esempio una collection “Workstations” e sotto di essa “Laptops”, “Desktops” e “Rugged Devices”. È una buona architettura se il parco macchine è grande, ma richiede naming coerente e regole di membership chiare, altrimenti il risultato è solo un grafo difficile da mantenere.

Preparare il criterio di identificazione del laptop

Il criterio migliore è quello che puoi verificare sia in console sia nei dati inventariati. In molti ambienti la distinzione tra laptop e desktop si ricava dal chassis type, dal form factor o da una combinazione di hardware inventory e attributi WMI. Il problema è che non tutti i vendor popolano gli stessi campi allo stesso modo, quindi conviene controllare prima quali dati sono davvero disponibili.

Un controllo rapido si fa partendo dall’inventario hardware del client e dal Resource Explorer in console. Se il device riporta un valore coerente per il tipo di chassis, puoi usarlo nella query; se il dato è sporco o mancante, meglio usare un’altra sorgente, come un gruppo AD o un naming convention già controllata a monte.

Prima di costruire la raccolta, verifica almeno tre cose: che l’hardware inventory sia abilitato, che il campo da usare sia presente nei client campione e che il risultato includa davvero sia laptop sia desktop per confronto. Senza questo passaggio, rischi una collection che sembra corretta ma in realtà è incompleta o troppo larga.

Creazione della raccolta in console SCCM

La procedura più lineare è creare una device collection dedicata e impostare una query membership rule. In console, il percorso tipico è Assets and Compliance > Device Collections > Create Device Collection. Da lì definisci nome, limiting collection e regola di membership.

Il limiting collection va scelto con attenzione. Se vuoi che la raccolta dei laptop sia globale, il limite può essere una collection base di tutti i dispositivi gestiti. Se invece vuoi restringere il perimetro a una business unit, a un sito o a un’area geografica, il limiting collection deve riflettere quel confine. Questo evita che la query venga eseguita su un insieme troppo ampio e semplifica anche la lettura operativa.

Una volta creata la collection, aggiungi la query membership rule e testa subito il preview dei membri. Il preview è il primo filtro reale: se la collection restituisce risultati inattesi, non andare oltre con deployment o policy. La correzione a questo stadio costa poco; dopo il rilascio, ogni errore si moltiplica.

Esempio di query per distinguere laptop e desktop

La struttura precisa della query dipende dal dato che hai in inventario. In molti ambienti si usa un attributo equivalente al chassis type. L’idea è filtrare i device che riportano un valore associato ai portatili. Se il tuo schema inventariale espone il valore in una classe WMI o in una tabella già nota, puoi costruire una query del tipo seguente, adattando classi e campi al tuo ambiente.

select SMS_R_System.ResourceID, 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_SYSTEM_ENCLOSURE on SMS_G_System_SYSTEM_ENCLOSURE.ResourceID = SMS_R_System.ResourceID
where SMS_G_System_SYSTEM_ENCLOSURE.ChassisTypes in (8, 9, 10, 14)

Questa logica è utile perché si basa su un dato tecnico, non su un’etichetta manuale. I codici di chassis possono variare a seconda del modello, ma il principio resta lo stesso: includere i tipi che rappresentano laptop o notebook e lasciare fuori i desktop classici. Prima di usarla in produzione, verifica quali codici popolano davvero i tuoi client, perché alcuni vendor espongono valori inattesi o multipli.

Se il tuo ambiente usa un’attributo diverso, per esempio un campo custom o un inventario esteso, la query va adattata di conseguenza. La regola pratica è sempre la stessa: cerca un campo stabile, leggibile e coerente su almeno un campione rappresentativo di device. Se il dato non è affidabile, la query non lo diventa per magia.

Membership rule: manuale, query o collezione annidata

La membership manuale funziona solo per numeri piccoli o casi eccezionali. È utile per un gruppo pilota, per device fuori standard o per una transizione temporanea. Non è la scelta giusta per una raccolta laptop destinata a crescere, perché il costo di manutenzione aumenta rapidamente e il rischio di dimenticare un device è alto.

La query è la soluzione più robusta quando vuoi automazione. Ogni volta che un nuovo laptop entra in inventory e soddisfa il criterio, viene incluso. Quando esce dal perimetro, viene escluso. Questo è il comportamento che vuoi in un sistema di gestione endpoint: meno intervento manuale, meno drift, meno sorprese.

La raccolta annidata è utile se hai già una gerarchia operativa. Per esempio puoi creare una collection madre “Corporate Workstations” e una figlia “Corporate Laptops”. In questo modo puoi applicare in modo differenziato software update, compliance baseline o application deployment. Il vantaggio è organizzativo; lo svantaggio è che devi tenere sotto controllo la catena delle dipendenze.

Verifiche prima di distribuire software o policy

Prima di agganciare la raccolta a un deployment, controlla tre elementi: membership effettiva, limiting collection e frequenza di aggiornamento della collection. Se la raccolta si aggiorna troppo di rado, potresti vedere ritardi tra l’ingresso del device e la comparsa nella collection. Se invece il refresh è troppo aggressivo in un ambiente molto grande, rischi di appesantire il management point e il database.

Un controllo utile è aprire la collection e verificare il numero di membri, poi confrontarlo con un campione reale di laptop noti. Se hai dieci laptop in un reparto ma la collection ne mostra sette, il problema può essere nel dato inventory, nel criterio di query o nel client che non ha ancora inviato l’ultima inventariazione. Serve capire dove si rompe la catena.

Per essere più rigorosi, guarda anche il Last Policy Request o il tempo dell’ultimo inventory cycle dei client campione. Un laptop che non aggiorna l’inventario da settimane può essere tecnicamente corretto nella collection, ma operativo no. In quel caso il problema non è la query; è la salute del client o la sua connettività verso il site.

Errori comuni quando si costruiscono collection per laptop

Il primo errore è usare il nome del device come criterio principale. È comodo, ma fragile. Basta un rename, un reimage o un device importato male e perdi la coerenza. Il secondo errore è basarsi su gruppi AD non governati: se il gruppo non viene mantenuto con disciplina, la raccolta eredita tutti i difetti del processo umano.

Il terzo errore è non testare i casi limite. Laptop 2-in-1, workstation portatili, device rugged e ultrabook aziendali non sempre rientrano in una classificazione banale. Se il tuo ambiente li usa, devi decidere in anticipo se includerli o escluderli. Altrimenti la collection farà esattamente quello che le hai chiesto, non quello che intendevi.

Un altro punto sottovalutato è il refresh schedule. Se la raccolta viene aggiornata troppo raramente, il deployment parte in ritardo e gli utenti percepiscono inconsistenza. Se invece la aggiorni in modo eccessivo senza necessità, sprechi risorse. La scelta va tarata sul ritmo reale del parco macchine, non su una regola astratta.

Manutenzione operativa della raccolta

Una raccolta laptop ben fatta non si abbandona dopo la creazione. Va monitorata nel tempo, soprattutto dopo cambi di hardware inventory, upgrade del client SCCM o modifiche alle classi WMI raccolte. Ogni variazione nel ciclo inventariale può alterare la membership senza che te ne accorga subito.

Per questo conviene documentare tre cose: criterio usato, eventuali eccezioni manuali e frequenza di refresh. Se un domani devi capire perché un device è dentro o fuori, la documentazione ti evita di rifare l’analisi da zero. In ambienti grandi, questa è una differenza concreta tra gestione ordinata e caos operativo.

Se la raccolta serve per deployment critici, ha senso aggiungere una verifica periodica di coerenza: numero membri atteso, numero membri osservato, variazioni rispetto alla settimana precedente e presenza di device anomali. Non serve un processo complesso; serve costanza. Anche un controllo mensile ben fatto vale più di una configurazione brillante lasciata senza manutenzione.

Approccio consigliato in ambienti reali

Se devi scegliere una strada concreta, la più solida è questa: usa un criterio tecnico di inventario per la membership principale, limita la collection a un perimetro sensato, verifica i membri con un campione reale e documenta l’eccezione manuale solo per i casi speciali. È il compromesso migliore tra automazione, leggibilità e manutenzione.

In ambienti piccoli puoi semplificare, ma senza perdere il controllo. In ambienti medi o grandi, invece, la raccolta laptop deve essere trattata come un oggetto operativo vero, non come una cartella comoda in console. Se la usi per distribuire software, patch o policy, la qualità della membership determina la qualità del resto della catena.

La regola finale è abbastanza semplice: prima rendi affidabile il dato, poi costruisci la collection, infine colleghi il deployment. Saltare uno di questi passaggi è il modo più rapido per trasformare una raccolta apparentemente ordinata in una fonte di errori difficili da spiegare agli utenti e ancora più difficili da difendere in audit.