1 11/04/2026 9 min

Prima di installare SCCM, AD va preparata bene

System Center Configuration Manager non “si appoggia” ad Active Directory in modo generico: si integra con oggetti, permessi, discovery e pubblicazione dei client. Se l’AD è sporca, poco coerente o troppo permissiva, l’installazione può anche partire, ma poi ti ritrovi con boundary group incoerenti, client che non si auto-registrano, distribuzioni lente e troubleshooting inutile.

La regola pratica è semplice: prima sistemi identità, DNS, OU e deleghe; poi installi SCCM. L’errore più comune è trattare AD come un requisito burocratico, quando invece è una dipendenza strutturale dell’intero stack di gestione endpoint.

Cosa serve davvero in Active Directory

Per un’installazione pulita di SCCM, i punti essenziali sono questi:

  1. Un dominio Active Directory funzionante e coerente con il DNS interno.
  2. Una struttura OU già pensata per separare server, workstation, dispositivi di test e oggetti di servizio.
  3. Account di servizio dedicati, con privilegi minimi e deleghe mirate.
  4. Permessi per creare e pubblicare oggetti nel container System Management.
  5. Un piano di discovery basato su AD, ma non dipendente solo da AD.

Il punto più sottovalutato è il DNS. SCCM usa in modo esteso la risoluzione dei nomi: se i client non risolvono correttamente MP, DP e site server, la console può sembrare sana mentre sul campo i client falliscono registrazione o policy retrieval.

Struttura OU: non improvvisarla durante il setup

Prima dell’installazione, definisci una struttura OU che separi chiaramente i dispositivi per funzione e lifecycle. Non serve complicare: serve coerenza. Una struttura tipica può essere questa:

OU=Workstations,DC=contoso,DC=local
OU=Servers,DC=contoso,DC=local
OU=Test,DC=contoso,DC=local
OU=Service Accounts,DC=contoso,DC=local

Questa organizzazione ti aiuta su tre fronti: applicazione delle GPO, targeting dei client e pulizia operativa. Se metti tutto in una sola OU, poi devi inseguire eccezioni con filtri, collection e scope ridondanti.

Se hai già un dominio in produzione, non fare il refactor delle OU dentro la finestra di installazione SCCM. Prima verifica l’effetto delle GPO esistenti con:

gpresult /h C:	emp
esult.html

Il file HTML ti mostra subito se ci sono policy che interferiscono con firewall, WinRM, client management o installazione dei componenti.

Account e deleghe: meno privilegi, più controllo

Per SCCM non basta “un account admin qualsiasi”. Conviene separare almeno questi ruoli:

  1. Account di installazione: usato per il setup iniziale e con privilegi temporanei elevati, se necessari.
  2. Account di servizio SCCM: per il site server e i processi applicativi, con diritti mirati.
  3. Account di pubblicazione in AD: per creare o mantenere il container System Management.

In ambienti ben gestiti, l’account che pubblica SCCM in AD non deve essere Domain Admin permanente. Gli dai il minimo necessario: creare il container e delegare i permessi di lettura ai computer del dominio sui record pubblicati. Il resto è solo superficie d’attacco in più.

Per verificare chi ha accesso al container, controlla da Active Directory Users and Computers con Advanced Features attivo, oppure usa strumenti di auditing se hai policy di sicurezza più strette.

Il container System Management va creato e delegato correttamente

SCCM pubblica in Active Directory alcune informazioni di sito nel container System Management. Se il container non esiste o non è delegato correttamente, i client AD discovery possono funzionare solo a metà e la diagnostica diventa confusa.

Procedura pratica:

  1. Apri Active Directory Users and Computers.
  2. Abilita View > Advanced Features.
  3. Individua il container System nel dominio e crea, se non esiste, System Management come child object.
  4. Delega al computer account del site server o all’account previsto i permessi necessari sul container.

Se preferisci validare da riga di comando, puoi almeno controllare che il container sia presente e che l’oggetto sia visibile in AD con strumenti LDAP o con PowerShell su una macchina amministrativa. Un controllo semplice, lato Windows, è questo:

Get-ADObject -LDAPFilter '(cn=System Management)' -SearchBase 'CN=System,DC=contoso,DC=local'

Se il comando non restituisce nulla, il container non è stato creato correttamente o stai interrogando il path sbagliato.

DNS interno: il prerequisito che rompe tutto quando è fragile

Molti problemi attribuiti a SCCM sono in realtà problemi di DNS. Prima dell’installazione verifica che i controller di dominio, il site server e i client usino solo DNS interni autorevoli per il dominio. Se i client puntano a resolver esterni, il discovery può essere incoerente e i record SRV del dominio possono sparire dal percorso di risoluzione.

Controlli minimi:

  1. Il nome del dominio risolve correttamente dal site server.
  2. I record SRV di AD sono presenti.
  3. I client vedono il domain controller giusto.

Verifica con:

nslookup contoso.local
nslookup -type=SRV _ldap._tcp.dc._msdcs.contoso.local

Se il secondo comando fallisce, non hai un problema SCCM: hai un problema di AD DNS. Risolvilo prima di andare oltre.

Discovery: usa AD, ma non fidarti solo di AD

SCCM può sfruttare più metodi di discovery: Active Directory Forest, AD Group, AD System, AD User, heartbeat discovery e discovery basate su rete o client già noti. La tentazione è attivare tutto subito. Non farlo.

Meglio partire con una combinazione minima e leggibile:

  1. Active Directory System Discovery per individuare computer presenti nel dominio.
  2. Active Directory User Discovery se devi fare mapping utenti-dispositivi o raccolte per profilo.
  3. Heartbeat Discovery per confermare che i client già noti restano aggiornati.

La discovery da sola non installa i client né garantisce che i boundary siano corretti. Serve come base dati, non come verità assoluta. Se usi solo AD e non hai un inventario di rete coerente, poi ti mancano pezzi nella fase di content distribution.

Boundary e site assignment: l’errore che si paga dopo

Active Directory ti aiuta a mappare gli oggetti, ma SCCM decide dove serve contenuto e a quale site assegnare il client in base ai boundary. Se la tua rete è segmentata, prepara prima subnet, AD site e VLAN.

Il punto operativo è questo: un client che vede il dominio non significa un client che può scaricare contenuti dal distribution point giusto. Le boundary devono riflettere la realtà di rete, non l’organigramma.

Un controllo minimo lato client è:

ipconfig /all
nslookup nome-dp.contoso.local

Se il client risolve il DP ma poi non raggiunge il contenuto, il problema è nel boundary group, nel routing o nel firewall. Non nell’AD in sé.

GPO e firewall: prepara il terreno prima della site installation

Per i client Windows, SCCM si appoggia a servizi e porte che spesso vengono bloccati da policy troppo rigide. Prima di installare, controlla che le GPO non disabilitino:

  1. WMI e remote management dove servono.
  2. Windows Firewall in modo incompatibile con i profili richiesti.
  3. Accesso a SMB, RPC o HTTPS verso i componenti SCCM, in base all’architettura scelta.

Per un primo riscontro, controlla i log eventi e le policy applicate. Su un client test:

gpupdate /force
Get-WinEvent -LogName System -MaxEvents 20

Se hai bloccato qualcosa con una GPO di hardening, meglio saperlo prima che i client inizino a registrarsi male. In ambienti seri, la maggior parte dei “SCCM non funziona” nasce da una policy di sicurezza applicata senza coordinamento con il team endpoint.

Service account e gestione credenziali

Non memorizzare segreti in chiaro in documenti operativi o script lasciati in share comuni. Per SCCM, l’approccio pulito è usare account dedicati, password ruotate secondo policy e, dove possibile, managed service account o soluzioni equivalenti compatibili con il design adottato.

Se devi documentare credenziali operative, documenta il processo, non il valore. Ad esempio: chi può ruotare l’account, dove viene aggiornato, quali sistemi dipendono da quel segreto e come verificare che la rotazione non abbia rotto il servizio.

Un controllo utile è verificare che i servizi SCCM usino l’account atteso e non un vecchio profilo locale o un account scaduto. Lato Windows Services o console di gestione, confronta il nome dell’account con la configurazione prevista prima di andare in produzione.

Sequenza pratica consigliata

Se devi installare SCCM da zero su un dominio già esistente, la sequenza che riduce gli errori è questa:

  1. Verifica DNS interno e salute AD.
  2. Definisci OU, gruppi e deleghe.
  3. Crea o valida il container System Management.
  4. Prepara account di servizio e permessi minimi.
  5. Controlla GPO e firewall sui server e su un client di test.
  6. Configura discovery iniziale e boundary.
  7. Solo dopo, esegui l’installazione di SCCM.

Questa sequenza evita il classico scenario in cui l’installazione va a buon fine, ma i client non si registrano, i record non compaiono in console e ogni team scarica la colpa su un componente diverso.

Verifiche minime prima del setup

Prima di lanciare il wizard di installazione, esegui almeno questi controlli:

dcdiag /v
repadmin /replsummary
nslookup -type=SRV _ldap._tcp.dc._msdcs.contoso.local
Get-ADDomain
Get-ADForest

Se uno di questi controlli fallisce, fermati e chiudi il problema di base. Non ha senso installare SCCM sopra un dominio che ha già problemi di replica o risoluzione nomi.

Un errore comune: confondere AD con inventario endpoint

AD ti dice chi esiste nel dominio, non chi è realmente gestibile, aggiornato o raggiungibile. SCCM lavora meglio quando AD è la sorgente di partenza, ma l’inventario operativo viene poi consolidato da heartbeat, client installati e boundary corretti.

In pratica: non aspettarti che l’OU giusta equivalga a un client pronto. Se il client non riceve policy, se il management point non è raggiungibile o se il certificate chain è incompleto, la presenza in AD serve a poco.

Decisione finale: installare SCCM solo quando AD è stabile

Il criterio giusto non è “AD esiste”, ma “AD è affidabile per discovery, autenticazione, DNS e deleghe”. Quando questi quattro elementi sono in ordine, l’installazione di SCCM diventa prevedibile. Quando non lo sono, SCCM amplifica i difetti invece di nasconderli.

Se vuoi ridurre i tempi di troubleshooting, tratta Active Directory come parte del progetto SCCM, non come prerequisito esterno. È la differenza tra una piattaforma gestibile e una piattaforma che sembra funzionare solo finché non devi davvero usarla.

Assunzione operativa: ambiente Windows Server recente, dominio AD già esistente, installazione SCCM in contesto enterprise con DNS interno gestito correttamente.