In SCCM, Discovery serve a popolare l’inventario con oggetti utili alla console: utenti, gruppi, computer, sistemi e relazioni. Boundary e Boundary Group servono invece a delimitare i client e a dirgli dove cercare il contenuto, il management point e i distribution point più vicini. Se queste due aree sono progettate male, il risultato è sempre lo stesso: client che non si registrano correttamente, policy lente, contenuti presi dal posto sbagliato e troubleshooting inutile perché i sintomi sono sparsi su più livelli.
La regola pratica è semplice: Discovery deve essere abbastanza ampia da trovare ciò che ti serve, ma non così aggressiva da riempire il sito di oggetti duplicati o rumorosi; Boundary deve essere abbastanza precisa da assegnare il client al gruppo corretto, ma non così frammentata da creare buchi di copertura. Il punto non è “accendere tutto”, ma costruire una mappa coerente della rete e del perimetro operativo.
Discovery in SCCM: cosa fa davvero
Le discovery methods di SCCM non installano nulla sui client: interrogano l’infrastruttura e popolano il database del site con oggetti che il resto della piattaforma può usare. Le più comuni sono Active Directory System Discovery, User Discovery, Group Discovery e, in ambienti più controllati, Network Discovery. La scelta dipende dal tipo di dato che vuoi rendere visibile nella console e dal livello di affidabilità della tua directory o della tua rete.
Per esperienza, Active Directory System Discovery è quasi sempre il punto di partenza corretto. Ti permette di importare i computer presenti in OU selezionate, di limitarne l’ambito e di evitare che ogni macchina mai vista da una subnet venga trattata come candidata al management. User Discovery e Group Discovery diventano interessanti quando vuoi fare targeting di collezioni o reporting più puliti, ma vanno configurati con più attenzione perché l’ambito è più facile da allargare troppo.
Network Discovery è il metodo più delicato: scopre dispositivi sulla rete interrogando protocolli e risposte broadcast/ARP o simili. È utile in segmenti piccoli e ben controllati, ma in reti grandi o poco documentate rischia di produrre rumore, duplicati e dati incompleti. In pratica: usalo solo se sai esattamente perché ti serve, e con una finestra di esecuzione e un perimetro molto stretti.
Boundary e Boundary Group: il pezzo che decide dove va il client
Una Boundary è un’area di rete riconoscibile da SCCM: può essere un IP subnet, un IP range, un Active Directory site o, in casi specifici, una vLAN o un range definito in modo da rispecchiare il routing reale. La Boundary da sola non assegna risorse al client: viene aggregata in un Boundary Group, che è il contenitore operativo usato per assegnare site assignment, management point e distribution point.
Qui c’è l’errore classico: creare Boundary accurate ma lasciare Boundary Group vuoti o incompleti. Il client allora “sa” di essere dentro un perimetro, ma non trova i punti di riferimento per scaricare policy e contenuti. Il risultato può sembrare un problema di rete, quando in realtà è solo una configurazione incompleta del gruppo di confine.
La Boundary corretta non deve imitare la topologia ideale sulla carta, ma la realtà di routing e indirizzamento. Se una subnet è annunciata in più sedi, o se una VPN assegna indirizzi che finiscono in un range condiviso, la Boundary va pensata sul comportamento effettivo del traffico, non sul disegno teorico della LAN.
Disegnare le Discovery: partire da Active Directory e limitare il rumore
Il modo più pulito per iniziare è lavorare per livelli. Prima definisci quali oggetti devono esistere in SCCM; poi decidi da dove leggere quei dati; infine verifica che i risultati siano coerenti con le collezioni e con la distribuzione contenuti. In un ambiente standard, la sequenza migliore è: AD System Discovery, eventualmente User Discovery, poi Group Discovery se ti serve targeting di gruppi, e solo dopo eventuale Network Discovery per eccezioni o segmenti non coperti da AD.
Per limitare il rumore, conviene imporre tre regole pratiche:
- seleziona solo le OU necessarie, non l’intero dominio;
- usa filtri di esclusione per oggetti noti come non gestiti, ambienti di test o macchine speciali;
- verifica che il polling interval non sia troppo aggressivo per il volume di oggetti presenti.
Una ricerca troppo frequente non rende SCCM “più reattivo” in senso utile: aumenta solo carico sul site server, traffico verso AD e probabilità di introdurre dati intermedi incoerenti mentre stai ancora progettando le collezioni.
Configurazione pratica: Discovery di computer e utenti
Dal punto di vista operativo, la configurazione si fa dalla console di SCCM nella sezione dedicata ai metodi di discovery. Il percorso preciso varia leggermente a seconda della versione, ma il flusso resta lo stesso: abiliti il metodo, scegli l’oggetto di directory da interrogare, limiti l’ambito e definisci la pianificazione.
Per System Discovery, il criterio più utile è l’OU. Se ad esempio vuoi gestire solo i client corporate, è preferibile puntare le OU dei computer aziendali e non l’intero albero AD. In molti ambienti conviene includere anche un filtro per i sistemi server, così da non mischiare endpoint e server in collezioni nate per i client desktop. Una struttura pulita in partenza evita di dover riparare collezioni e query dopo.
Per User Discovery, il vantaggio è soprattutto nel targeting delle applicazioni e delle collezioni basate sugli utenti. Qui il problema non è tanto la quantità, quanto la qualità: utenti dismessi, account di servizio, account di test e gruppi annidati possono falsare i risultati. Se non hai un requisito preciso, attivala solo sulle OU utente realmente governate e con una cadenza compatibile con il tuo ciclo di provisioning.
Un esempio di logica corretta è questo: computer scoperti da AD System Discovery, utenti scoperti da AD User Discovery, gruppi gestiti da AD Group Discovery, e collezioni costruite sopra oggetti affidabili. Se invece importi tutto e poi provi a correggere con esclusioni, stai usando SCCM al contrario: funziona finché il dataset è piccolo, poi diventa fragile.
Boundary: scegliere il tipo giusto
Il tipo di Boundary non è una formalità. IP subnet è la scelta più semplice e leggibile quando la rete è statica e ben segmentata. IP range è utile quando il routing o l’assegnazione dinamica rende la subnet meno affidabile come unità funzionale. Active Directory site ha senso solo se la tua definizione di site in AD riflette davvero il traffico e la geografia delle sedi. Altrimenti stai delegando a un oggetto directory una decisione di rete che non gli appartiene più.
In ambienti con VPN, SD-WAN o sedi ibride, il Boundary tipo subnet può essere sufficiente, ma va controllato con attenzione. Se un client remoto riceve un indirizzo che ricade in un range già usato in sede, il rischio è che SCCM lo collochi nel boundary group sbagliato. In quei casi conviene preferire range più specifici o una segmentazione che distingua chiaramente i percorsi di accesso ai contenuti.
La regola di base è: una boundary deve avere un significato operativo univoco. Se un indirizzo può appartenere a due significati diversi, la boundary non è pronta. Questo è uno dei punti in cui SCCM ti punisce subito, perché la scelta del boundary group influenza client assignment, content location e discovery del management point.
Boundary Group: assegnare sito, management point e distribution point
Il Boundary Group è il vero centro di gravità della configurazione. Qui associ le boundary a un gruppo e poi assegni i ruoli disponibili. In pratica, il client entra nel gruppo, legge dove deve andare per parlare con il site, trova un management point e riceve i riferimenti ai distribution point adatti. Se questo passaggio è incompleto, la macchina può anche essere scoperta correttamente ma restare di fatto non gestita.
In un’architettura pulita, ogni boundary group dovrebbe avere almeno queste informazioni:
- associazione della boundary corretta;
- site assignment, se previsto dal design;
- management point preferito o disponibile;
- distribution point locali o di rete vicina;
- eventuali fallback ragionati, non casuali.
Il fallback va usato con criterio. Un client che non trova il DP locale non deve per forza andare a pescare contenuti dall’altra parte del WAN come prima opzione. Se il meccanismo di fallback è troppo permissivo, ti accorgi del problema solo quando i trasferimenti saturano il link e il supporto si ritrova a inseguire installazioni lente senza una causa evidente.
Verifica rapida: capire se Discovery e Boundary stanno lavorando bene
La verifica non va fatta “a sensazione”. Devi controllare almeno tre livelli: oggetto scoperto, boundary assegnata e location dei contenuti. Sul client, il file più utile resta spesso LocationServices.log, perché mostra come SCCM decide site assignment e content location. Per la discovery lato server, i log dipendono dal metodo, ma la logica è sempre la stessa: controllare se l’oggetto è stato letto, se è stato inserito nel database e se i dati finali corrispondono a quello che ti aspettavi.
Un controllo minimo da fare su un client è osservare i log di SCCM e confermare che il sistema riceva un boundary group coerente. Se vedi che il client si aggancia a un MP distante, oppure non trova DP vicini, la prima domanda non è “il firewall blocca tutto?”, ma “la boundary assegnata coincide davvero con l’indirizzo e con la sede?”
Se vuoi una verifica più sistematica, confronta questi elementi:
- indirizzo IP del client e subnet effettiva;
- boundary group assegnato in console;
- management point e distribution point che il client sta usando;
- orario dell’ultima discovery utile e della policy update;
- eventuali errori nei log del client o del site server.
Se uno di questi punti non torna, non correggere a caso. Prima isolalo: o la discovery non ha trovato l’oggetto, o la boundary non lo classifica correttamente, o il boundary group non espone i ruoli giusti.
Comandi e controlli utili lato client e lato server
Quando serve un controllo rapido sul client, la prima cosa è forzare una policy update e leggere i log. Non è un fix strutturale, ma è un buon modo per verificare se la configurazione nuova è stata recepita. Su Windows, puoi usare strumenti standard per aprire l’area di gestione dei log oppure interrogare lo stato del client da PowerShell.
Get-CimInstance -Namespace root\ccm -ClassName SMS_Client | Select-Object ClientVersion, ClientState
Per la parte di inventario e boundary, il controllo più utile resta spesso la console di SCCM, ma lato client puoi verificare l’appartenenza al dominio, la subnet e il DNS, perché un errore lì si riflette direttamente nel modo in cui il client viene classificato. Se il client è in una rete diversa da quella prevista, SCCM non può “indovinare” il boundary corretto se i dati di base sono incoerenti.
Un check rapido sul client può essere questo:
ipconfig /all
nltest /dsgetsite
ping -n 1 <MP_FQDN>
Atteso: il sito AD restituito da nltest deve essere coerente con la sede prevista; il management point deve rispondere; l’IP del client deve cadere in una boundary nota. KO: site errato, MP non raggiungibile, o subnet non presente in nessun boundary group.
Pattern di errore più comuni
Il primo errore è usare boundary troppo generiche. Ad esempio, un range ampio che copre sedi diverse porta i client a condividere lo stesso gruppo, con conseguenti DP sbagliati e traffico non ottimale. Il secondo errore è avere discovery troppo ampia, soprattutto su AD: importi oggetti che non devono essere gestiti, poi costruisci collezioni complesse per escluderli e ti ritrovi con una manutenzione permanente.
Il terzo errore è dimenticare la relazione tra boundary e content location. Molti amministratori validano solo che il client sia presente in console, ma non controllano se il gruppo di boundary espone davvero il DP giusto. In SCCM non basta sapere che il client esiste: deve sapere dove andare per ogni funzione critica.
Un quarto problema, meno visibile ma frequente, è la mancata revisione dopo cambi di rete. Nuove subnet, migrazioni di sede, VPN più granulari o modifiche al routing possono rendere obsolete boundary che prima erano corrette. Se non hai un processo di review, SCCM resta fermo su una mappa vecchia mentre la rete evolve.
Approccio consigliato per ambienti medi e grandi
In ambienti medi e grandi conviene separare nettamente tre attività: scoperta degli oggetti, definizione del perimetro di rete e assegnazione dei ruoli. Non mescolare tutto in un unico boundary group enorme. Meglio gruppi coerenti per sede, campus, data center o cluster di subnet con caratteristiche simili. Se una sede ha più subnet, raggruppale solo se condividono davvero lo stesso percorso verso DP e MP.
Per la discovery, la strategia più robusta è partire da OU ben definite e ampliare solo quando esiste una necessità concreta. Per i boundary group, la regola è opposta: meglio un disegno già completo e verificato prima di assegnare massa di client, perché correggere dopo significa rincorrere effetti collaterali su policy e contenuti.
Un dettaglio spesso sottovalutato è la documentazione operativa. Non basta sapere che una subnet è stata inserita in un gruppo; serve anche sapere perché è stata inserita lì, chi l’ha approvata e quale DP o MP deve servire. Quando qualcosa si rompe, questa informazione fa la differenza tra un fix da 10 minuti e un’ora di tentativi.
Sequenza consigliata di implementazione
Se devi mettere ordine da zero, la sequenza più sicura è questa:
- mappa le sedi, le subnet e i percorsi di accesso ai contenuti;
- definisci le OU AD che contengono solo gli oggetti da gestire;
- attiva System Discovery su quelle OU e verifica il numero di oggetti importati;
- aggiungi User Discovery o Group Discovery solo se servono davvero a collezioni o deployment;
- crea boundary coerenti con la rete reale;
- raggruppa le boundary in boundary group con MP e DP corretti;
- testa un client per sede e controlla log, policy e location content;
- solo dopo amplia il perimetro.
Questo approccio riduce il rischio di propagare un errore di progettazione su tutta la piattaforma. SCCM è molto stabile quando il modello è coerente; diventa complicato quando si tenta di correggere un design storto con eccezioni successive.
Conclusione operativa: cosa deve essere vero a fine lavoro
A configurazione finita, devi poter dire tre cose senza ambiguità: gli oggetti giusti sono stati scoperti, i client finiscono nel boundary group corretto e il site assegna management point e distribution point coerenti con la sede. Se uno di questi tre punti manca, la configurazione è solo parzialmente utile.
La qualità della configurazione in SCCM non si misura dal numero di discovery attive o dal numero di boundary create, ma dalla capacità del client di trovare rapidamente il percorso giusto senza ambiguità. Discovery e Boundary non sono due argomenti separati: sono due metà dello stesso problema, cioè rendere il client riconoscibile e servibile nel punto esatto in cui si trova.
Assunzione operativa: la topologia di rete e le OU AD sono già state validate con i responsabili di infrastruttura prima di applicare queste impostazioni in produzione.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.