1 18/05/2026 10 min

Il contenitore di sistema per SCCM non è un dettaglio cosmetico

Quando si parla di SCCM, o Microsoft Configuration Manager, il punto debole non è quasi mai il software in sé. Il problema nasce prima: struttura di Active Directory, deleghe, naming, posizionamento degli oggetti e coerenza del contenitore in cui finiscono server, client e riferimenti infrastrutturali. Se il contenitore di sistema è impostato male, il risultato è prevedibile: discovery sporca, client che non trovano i riferimenti giusti, policy che arrivano in ritardo e troubleshooting che si trasforma in caccia al sintomo invece che alla causa.

In questa logica, “creare il contenitore di sistema per SCCM ed estendere AD” non significa solo spuntare una casella in console. Vuol dire preparare il terreno perché il sito possa pubblicare informazioni in Active Directory in modo ordinato, leggibile e soprattutto affidabile. Se l’architettura è piccola si tende a sottovalutare il passaggio; se è grande, il costo di una scelta improvvisata si paga dopo, quando bisogna rifare OU, ACL o scope di pubblicazione senza interrompere i client già distribuiti.

Cosa deve esistere prima di estendere lo schema o creare il container

La prima decisione utile è separare tre concetti che spesso vengono confusi: schema extension, container di sistema e delega di permessi. Lo schema serve a introdurre gli attributi e le classi richieste da Configuration Manager; il container di sistema è il punto in cui SCCM pubblica i propri oggetti; la delega definisce chi può scrivere e leggere in quel ramo di directory. Se uno dei tre pezzi manca, l’infrastruttura può anche installarsi, ma non si comporta in modo pulito.

Il prerequisito operativo minimo è avere un Domain Controller raggiungibile con credenziali che possano modificare lo schema e creare oggetti nel container designato. In ambienti ben governati, queste attività non si fanno con un account personale: si usa un account amministrativo tracciato, si conserva evidenza del cambiamento e si limita la delega al solo ambito necessario. Qui il vantaggio non è burocratico, è tecnico: meno permessi superflui significa meno effetti collaterali quando qualcuno eredita la configurazione mesi dopo.

Un secondo punto è il DNS. SCCM vive di record, riferimenti e risoluzione coerente tra client, site server, management point e distribution point. Se il DNS interno è sporco, il container AD non risolve tutto, ma aiuta solo a rendere visibile ciò che già esiste. Per questo conviene considerare l’estensione AD e la creazione del contenitore come parte di un pacchetto più ampio: directory, DNS, permessi e pubblicazione dei servizi devono andare nella stessa direzione.

Schema extension: perché farla una sola volta e con tracciabilità

L’estensione dello schema di AD per Configuration Manager è un’operazione irreversibile nel senso pratico del termine: non si “disinstalla” come un componente qualunque. Per questo va trattata come un change controllato, non come una prova in laboratorio fatta alla leggera sul dominio di produzione. L’errore tipico è partire dal setup di SCCM senza documentare che cosa si sta estendendo, con quale versione e con quale account. Il risultato è che, quando qualcosa non torna, si finisce a discutere del sintomo invece che a verificare l’effettivo stato dello schema.

In un cambio ben gestito, la sequenza sensata è: snapshot logico del contesto, verifica della versione di Configuration Manager che si intende installare, controllo dei privilegi dell’account usato e conferma che il backup di AD o almeno la finestra di rollback organizzativa siano chiari. Non sto dicendo che si debba ripristinare lo schema in caso di errore: quello non è realistico. Sto dicendo che bisogna sapere prima qual è il piano se l’operazione viene eseguita con credenziali sbagliate, su forest errata o in un momento in cui il team AD non è disponibile.

La verifica minima, prima di toccare qualsiasi cosa, è controllare che il server da cui si avvia il setup punti al dominio corretto e che il DNS interno risolva il domain controller previsto. Un controllo banale ma utile è questo:

nslookup _ldap._tcp.dc._msdcs.dominio.local
nltest /dsgetdc:dominio.local

Se questi due test mostrano un DC inatteso, un suffisso sbagliato o timeout, fermarsi è la scelta giusta. Estendere lo schema in una forest sbagliata o con risoluzione incoerente non è una scorciatoia: è un modo rapido per creare un problema più costoso del precedente.

Il contenitore di sistema di SCCM: dove metterlo e perché non usare il default senza pensarci

Il contenitore di sistema è il ramo di Active Directory in cui SCCM pubblica le informazioni di sito, i riferimenti ai server e i dati che i client usano per trovare ciò che serve. In molte installazioni si lascia il container predefinito previsto da Microsoft, e in tanti casi va bene. Il punto non è cambiare per forza, ma capire cosa si sta ereditando. Se il dominio ha già una struttura AD ordinata, il container dedicato a SCCM può convivere con altri oggetti di servizio senza confusione. Se invece la directory è storicamente cresciuta male, conviene mantenere un contenitore specifico e una delega strettamente limitata.

La buona pratica è evitare di pubblicare oggetti SCCM in un ramo generico dove transitano anche altre applicazioni. La ragione non è estetica: è operativa. Un container dedicato rende più semplice audit, permessi, troubleshooting e pulizia futura. Quando un client non trova un management point o un site server, sapere che tutti gli oggetti SCCM stanno in un punto preciso riduce il tempo di diagnosi. Se invece il contenuto è sparso, ogni verifica diventa una caccia al tesoro tra OU, container, filtri e deleghe ereditate.

Dal punto di vista della sicurezza, il contenitore deve avere il minimo indispensabile: lettura per i client e scrittura limitata ai componenti di SCCM che pubblicano oggetti. Non serve dare diritti larghi a un gruppo di amministratori generici del dominio. Serve invece sapere quale account di servizio o quale security group gestisce la pubblicazione, e documentarlo. Se oggi il sito funziona solo perché un account “storico” ha privilegi troppo ampi, il problema non è teorico: è un debito tecnico che prima o poi presenterà il conto.

Estendere AD in modo corretto: percorso console, script e punti di controllo

Nei contesti Microsoft, l’estensione di Active Directory per SCCM si fa in genere attraverso i supporti di installazione del prodotto, che preparano schema e pubblicazione in directory. In pratica, il punto di partenza è sempre il media o la sorgente corretta della versione che stai installando. Non usare file vecchi, non mischiare build diverse e non dare per scontato che “funzioni lo stesso”. Con Configuration Manager, la coerenza della versione è parte del controllo qualità del change.

Il controllo più utile, dopo l’estensione, è verificare che gli attributi e i container attesi siano effettivamente presenti e che la pubblicazione AD sia leggibile dai client. Non basta che il setup termini senza errore. Bisogna controllare i log del setup e quelli del componente AD publishing, oltre a verificare dal lato client che la discovery della site information funzioni. In caso contrario si rischia di avere un’infrastruttura formalmente installata ma operativamente muta.

Un esempio pratico di verifica lato dominio è controllare la presenza del container e dei relativi oggetti con strumenti standard di amministrazione AD o con la console di Active Directory Users and Computers, se la delega è stata impostata per rendere visibile il ramo. Se il container non compare, o compare ma non consente la pubblicazione, il problema è quasi sempre uno tra questi tre: estensione non eseguita, permessi insufficienti o replica AD non ancora completata.

Se vuoi una verifica rapida senza fare assunzioni, conviene osservare anche la replica tra domain controller. Un container creato su un DC ma non ancora replicato altrove può far sembrare “rotto” SCCM quando in realtà è solo in attesa di convergenza. In questi casi il test minimo è:

repadmin /replsummary
repadmin /showrepl

Se la replica è in errore, prima si sistema AD e solo dopo si torna a SCCM. Invertire l’ordine porta a falsi positivi e diagnosi sbagliate.

Permessi: il punto più trascurato e quello che rompe tutto in silenzio

Il tema dei permessi merita più attenzione della procedura di setup. Un container SCCM può esistere perfettamente e restare comunque inutilizzabile se le ACL non consentono al sito di pubblicare o ai client di leggere i riferimenti. Questo è uno dei casi più fastidiosi perché non genera sempre un errore evidente: a volte il sistema sembra quasi funzionare, ma i client impiegano troppo a trovare i riferimenti o lo fanno in modo intermittente.

La regola pratica è semplice: delega esplicita, documentata e verificabile. Niente ereditarietà casuale da OU superiori, niente gruppi “onnipotenti” creati per comodità, niente eccezioni non annotate. Se il team AD usa un modello standard di delega, il container SCCM dovrebbe aderire a quel modello, non aggirarlo. Questo aiuta anche quando bisogna fare audit: si vede subito chi può fare cosa e perché.

Per controllare che la pubblicazione avvenga davvero, oltre alla console, conviene verificare i log del site server e del componente di directory publishing. I nomi cambiano in base alla versione, ma il principio è lo stesso: cercare errori di accesso negato, problemi di binding LDAP, replica incompleta o oggetti non creati. Un errore di permesso spesso non è un “crash”: è un rifiuto silenzioso che compare solo nei log giusti.

Un ordine di lavoro sensato per evitare di rifare tutto due volte

Se l’obiettivo è predisporre il contenitore di sistema per SCCM ed estendere AD con il minimo rischio, l’ordine operativo dovrebbe essere questo: validare il dominio e la replica, confermare la versione di Configuration Manager, eseguire l’estensione dello schema se richiesta dalla versione, creare o verificare il container di sistema, assegnare le ACL minime necessarie e infine controllare che la pubblicazione sia visibile dai client. Saltare un passo per “fare prima” di solito sposta il tempo perso più avanti, quando il problema è più difficile da leggere.

La parte più utile, in un ambiente serio, non è la velocità del setup ma la ripetibilità. Se il processo è documentato bene, un secondo amministratore deve poter capire in pochi minuti dove si trova il container, quali permessi ha, quale versione lo ha creato e come si verifica che la directory sia in stato corretto. Quando questa informazione manca, il rischio non è solo tecnico: è organizzativo, perché ogni intervento successivo dipende dalla memoria di chi c’era la prima volta.

Un dettaglio che vedo spesso trascurato è la distinzione tra “funziona adesso” e “è mantenibile”. SCCM in AD può continuare a operare anche con un setup poco pulito, ma appena si aggiungono site secondari, nuovi management point o una riorganizzazione del dominio, il debito accumulato emerge. Investire mezz’ora in più sul contenitore, sui permessi e sulla documentazione evita ore di analisi quando il problema non è più localizzato ma distribuito.

Verifiche finali che danno davvero valore

Le verifiche finali non devono limitarsi a “setup completato”. Devono rispondere a tre domande concrete: il dominio pubblica i riferimenti corretti, i client li leggono e la replica AD non introduce incoerenze. Dal lato pratico, questo significa controllare la presenza del container, l’assenza di errori nei log di pubblicazione e la capacità di un client di risolvere il site server o il management point senza passaggi manuali.

Se qualcosa non torna, il rollback realistico non è cancellare l’estensione dello schema; quel treno è passato. Il rollback utile riguarda invece le modifiche di configurazione introdotte di recente: ACL, container personalizzati, deleghe errate, oppure l’uso di un account sbagliato per la pubblicazione. Per questo conviene tenere sempre un diff della modifica e, quando possibile, esportare le ACL prima di toccarle. Il ripristino del solo contenitore o dei soli permessi è molto più semplice di una ricostruzione a posteriori basata sui ricordi.

Assunzione operativa: il dominio è in stato sano, la replica è conforme e la versione di SCCM è quella prevista dal change; se uno di questi tre punti non è verificato, prima si chiude il gap e poi si procede con estensione e pubblicazione.