40 domande e risposte per colloquio su SCCM

SCCM, oggi Microsoft Configuration Manager, resta uno degli strumenti più usati quando serve governare un parco macchine Windows con criteri seri: distribuzione software, patching, inventario, compliance e automazione del ciclo di vita dei client. Non è un prodotto da “installo e dimentico”: funziona bene solo se la struttura dei boundary, dei ruoli, dei client e dei contenuti è pensata con metodo. Le domande che seguono sono quelle che emergono davvero in colloquio, in assessment tecnici o quando si deve prendere in mano un ambiente già esistente e capire dove si rompe.

Domande e risposte su SCCM / Microsoft Configuration Manager

1. Che cos’è SCCM?
SCCM è la piattaforma Microsoft per gestire endpoint Windows in modo centralizzato. Serve a distribuire applicazioni, aggiornamenti, sistemi operativi e policy, oltre a raccogliere inventario hardware e software. Il suo valore vero non è nel singolo task, ma nella capacità di standardizzare l’amministrazione su larga scala.

2. Qual è la differenza tra SCCM e Intune?
SCCM nasce per ambienti on-premises e per scenari complessi di gestione locale. Intune è più orientato al cloud e al mobile device management moderno. In molti contesti i due convivono: SCCM per controllo profondo e distribuzioni pesanti, Intune per gestione cloud-first e policy moderne.

3. Quali sono i componenti principali di un’infrastruttura SCCM?
Servono almeno un site server, un database SQL Server, i role point necessari come management point e distribution point, e i client. In ambienti più strutturati entrano in gioco software update point, reporting services point e, se necessario, endpoint dedicati per contenuti o integrazioni.

4. Che cos’è un Primary Site?
È il sito principale che gestisce client, policy e distribuzione dei contenuti in una porzione dell’infrastruttura. In molte installazioni è il cuore operativo del sistema. Non va confuso con il database: il Primary Site coordina, il database conserva stato e dati di configurazione.

5. A cosa servono i Boundary e i Boundary Group?
I Boundary definiscono aree di rete come subnet, IP range o Active Directory site. I Boundary Group raggruppano questi confini e assegnano i punti di riferimento per client, contenuti e fallback. Se sono configurati male, il client può registrarsi ma scaricare contenuti dal posto sbagliato o non trovarne affatto.

6. Perché i Boundary Group sono così importanti?
Perché controllano il comportamento operativo del client. Un boundary errato non genera solo un problema di geografia logica: può tradursi in distribuzioni lente, fallback non previsto o failure di policy. In pratica, sono una delle prime cose da verificare quando il client “vede” il sito ma non consuma bene i contenuti.

7. Che differenza c’è tra Package, Application e Program?
Il Package è il modello più vecchio e semplice, usato spesso per script o installazioni lineari. L’Application è più moderno e supporta detection method, requirements, supersedence e dipendenze. Il Program appartiene al vecchio paradigma dei package e viene usato in contesti legacy o molto specifici.

8. Quando conviene usare Application invece di Package?
Quando serve un controllo più affidabile dello stato installato, una detection logic chiara e una gestione migliore delle versioni. Se devi distribuire software con requisiti, sostituzioni o installazioni condizionali, Application è quasi sempre la scelta più pulita. I Package restano utili per task semplici o script one-shot.

9. Cos’è la Detection Method in una Application?
È il criterio con cui SCCM decide se l’app è già presente o no. Può basarsi su file, registry, MSI product code o query personalizzate. Una detection sbagliata è una delle cause più frequenti di installazioni ripetute o di applicazioni che risultano “installed” quando non lo sono.

10. Che cosa sono le Collection?
Sono insiemi logici di dispositivi o utenti usati per targeting e automazione. Le collection possono essere statiche o basate su query. In SCCM la qualità delle collection incide direttamente su quanto è pulito il rollout: una collection rumorosa produce distribuzioni rumorose.

11. Qual è la differenza tra User Collection e Device Collection?
Le User Collection seguono l’utente, le Device Collection seguono la macchina. La scelta dipende dallo scenario: software personale, profili e alcuni criteri di accesso funzionano meglio con utenti; patching, imaging e software machine-wide richiedono di solito device targeting.

12. Che cos’è una Task Sequence?
È una sequenza orchestrata di passi per installare o reimpostare il sistema operativo, distribuire driver, applicare aggiornamenti e installare software. Le task sequence sono il punto in cui SCCM mostra la sua forza, ma anche dove gli errori di prerequisiti, driver o step condizionali diventano più evidenti.

13. A cosa serve il PXE in SCCM?
Permette l’avvio di rete per deployment del sistema operativo. Con PXE il client può bootare da rete e avviare una task sequence senza media fisici. È comodo, ma richiede attenzione sulla rete, sui permessi e sulla protezione da avvii non desiderati.

14. Come si distribuiscono gli aggiornamenti software in SCCM?
Di solito tramite Software Update Point, sincronizzato con WSUS. SCCM importa metadata, classifica gli update, li approva e li distribuisce alle collection. Il punto critico non è solo l’approvazione: è la coerenza tra sincronizzazione, deployment package e compliance reporting.

15. Qual è il ruolo di WSUS dentro SCCM?
WSUS fornisce la base per la catalogazione degli aggiornamenti. SCCM lo usa come motore di sincronizzazione, ma la gestione operativa resta in mano a ConfigMgr. Quando WSUS è rotto, SCCM spesso sembra “lento” o “vuoto”, ma il problema reale è a monte nella sincronizzazione dei metadata.

16. Come funziona il client SCCM?
Il client riceve policy, comunica con il management point, scarica contenuti dai distribution point e invia inventario e stato. Se il client è sano ma la comunicazione è degradata, il problema può stare nel boundary, nei certificati, nella rete o nel canale verso i role server.

17. Come si verifica se il client SCCM è installato correttamente?
Si controllano servizio client, policy retrieval, inventario e canale con il management point. In pratica si guarda se il client è registrato, se riceve policy e se processa azioni come hardware inventory o machine policy retrieval. I log del client sono la fonte più utile quando qualcosa non torna.

18. Quali log sono i più utili per il troubleshooting?
Quelli del client e quelli dei role server coinvolti. Sul client sono spesso decisivi log come ClientIDManagerStartup.log, PolicyAgent.log, LocationServices.log e ContentTransferManager.log. Sul server contano i log del management point, del distribution point e del software update point.

19. Come si distribuisce un’applicazione a un gruppo di utenti o computer?
Si crea l’application, si definiscono detection e requirements, poi si assegna a una collection come deployment available o required. La scelta tra disponibile e obbligatorio cambia l’effetto operativo: available lascia l’iniziativa all’utente, required forza l’installazione secondo la finestra configurata.

20. Che cos’è il Content Distribution?
È il processo con cui i file vengono copiati sui distribution point per essere resi disponibili ai client. Se il contenuto non è distribuito o è distribuito male, il client può ricevere policy correttamente ma fallire al download. In quel caso il problema non è il deployment, è la catena di distribuzione dei contenuti.

21. Qual è il significato di “Content Library”?
È il repository interno che SCCM usa per gestire i file distribuiti sui punti di contenuto. La content library aiuta a deduplicare e tracciare i file. Se viene corrotta o saturata, i deployment iniziano a comportarsi in modo imprevedibile, soprattutto sul distribution point.

22. Come si gestiscono i driver in una task sequence?
Si possono importare i driver e organizzarli per modello, categoria o package separati. Il punto delicato è evitare di iniettare driver in modo troppo ampio: un driver sbagliato può far fallire il boot, rompere la rete o creare instabilità post-deployment. Meglio essere selettivi che “abbondanti”.

23. Che cos’è il Software Center?
È l’interfaccia lato utente per vedere applicazioni disponibili, stato dei deployment e aggiornamenti. È il volto visibile del client SCCM. Se il Software Center non mostra ciò che ci si aspetta, il problema può essere di policy, targeting, compliance o cache locale del client.

24. Come si forza il recupero delle policy sul client?
Dal client si possono avviare manualmente le azioni di machine policy retrieval e policy evaluation. In GUI si usa il pannello del Configuration Manager nel Control Panel; lato log si verifica che la policy venga scaricata e processata senza errori. È uno dei test più rapidi per capire se il canale è vivo.

25. SCCM usa ancora i vecchi “Advertisements”?
Il termine è storico. Oggi il modello moderno è basato su deployment di application, package, update e task sequence. In ambienti legacy può ancora comparire la vecchia terminologia, ma in colloquio conviene dimostrare di conoscere il lessico attuale e quello storico.

26. Cosa significa “supersedence” in una Application?
Vuol dire che una versione nuova può sostituire una vecchia, con logiche di rimozione o aggiornamento. È utile per gestire il lifecycle del software senza lasciare troppe versioni in circolazione. Se impostata male, però, può produrre rimozioni indesiderate o installazioni a cascata.

27. Come si controlla la compliance degli update?
Si usa il reporting di SCCM per vedere quanti client sono compliant, non compliant o unknown. Il dato utile non è solo il numero totale, ma il trend per collection, per categoria di update e per finestra temporale. La compliance senza contesto può sembrare buona e invece nascondere ritardi seri.

28. Qual è la differenza tra compliance e enforcement?
La compliance descrive lo stato, l’enforcement applica la correzione. Un client può risultare non compliant finché non entra nella finestra prevista o finché non completa il ciclo di installazione. È un concetto semplice, ma in audit e troubleshooting evita molti fraintendimenti.

29. Come si gestisce il reporting in SCCM?
Di solito si appoggia a SQL Server Reporting Services. I report servono per inventario, compliance, deployment status e analisi operative. Se i report non funzionano, spesso il problema è a livello di permessi, connessione al database o configurazione del reporting point.

30. Cosa si intende per client push installation?
È l’installazione del client avviata dal server verso i computer target. È comoda, ma dipende da connettività, credenziali e reachability amministrativa. Se fallisce, non significa che SCCM sia rotto: spesso il problema è solo nel canale di accesso remoto o nei permessi usati dal push.

31. Quali sono i problemi più comuni del client SCCM?
Installazione incompleta, policy non ricevute, boundary errati, download contenuti fallito, inventario bloccato e certificati non coerenti. In molte situazioni il client non è “guasto”: è semplicemente fuori dal perimetro corretto o non riesce a parlare con il role giusto.

32. Come si diagnostica un problema di content download?
Si parte da boundary group, availability del distribution point e stato del contenuto distribuito. Poi si leggono i log del client per capire se il problema è di location, accesso o trasferimento. Se il client non risolve un DP valido, il problema è a monte della rete o della configurazione del boundary.

33. SCCM richiede SQL Server dedicato?
In ambienti piccoli può convivere con altri ruoli, ma in produzione seria è preferibile separarlo o almeno dimensionarlo con attenzione. Il database è centrale per prestazioni e stabilità. Se SQL è sotto pressione, la lentezza si riflette in policy, reporting e gestione generale del sito.

34. Cosa guardare se SCCM è lento?
Prima di tutto SQL latency, code sui role server, stato dei componenti e dimensione del contenuto distribuito. Anche la rete conta, ma non è il primo alibi da usare. In un ambiente sano, i ritardi si vedono prima nei log e nelle code, poi nella percezione degli utenti.

35. Come si gestiscono i privilegi degli operatori?
Con RBAC e ruoli ben definiti. Non tutti devono poter distribuire software, modificare boundaries o avviare task sequence. Il principio è semplice: meno privilegi, meno incidenti. In SCCM i permessi troppo larghi diventano rapidamente un problema operativo e di audit.

36. SCCM è utile per la sicurezza?
Sì, se usato bene. Permette di distribuire patch, raccogliere inventario, verificare configurazioni e standardizzare baseline. Non è un SIEM e non sostituisce un EDR, ma resta un controllo molto concreto sulla postura dei client Windows. La sicurezza qui passa soprattutto da disciplina e reporting.

37. Come si controlla la versione del client?
Si può verificare dalla console, dal client o tramite inventario. È importante perché alcune funzionalità e fix dipendono dalla versione del client stesso. In ambienti grandi, tenere il client allineato evita differenze di comportamento tra gruppi di macchine.

38. Qual è un errore tipico nei colloqui su SCCM?
Dire che SCCM “serve solo a installare software”. È riduttivo. Un buon candidato sa parlare di lifecycle, targeting, compliance, OS deployment, boundaries, reporting e troubleshooting. La parte più interessante non è il click in console, ma il modello con cui si governa l’ambiente.

39. Come risponderesti se ti chiedono un caso pratico?
Conviene raccontare un problema reale: client fuori boundary, deployment che non parte, update non conformi o task sequence fallita per driver errati. Poi si spiega il metodo: verifica log, isolamento del layer, correzione minima e controllo finale. È molto più credibile di una risposta teorica generica.

40. Qual è la mentalità giusta per lavorare con SCCM?
Trattarlo come una piattaforma di controllo, non come un semplice tool di installazione. Ogni scelta su collection, boundary, detection, content distribution e aggiornamenti ha impatto operativo. Chi lo usa bene ragiona per processi, osservabilità e rollback, non per tentativi casuali.

Come studiare SCCM per un colloquio tecnico

Se devi prepararti in modo efficace, concentrati su tre aree. La prima è l’architettura: site, role, SQL, client, boundary e content flow. La seconda è l’operatività: application, package, task sequence, software update e compliance. La terza è il troubleshooting: log, policy, detection, DP, MP e sintomi tipici del client. Chi sa collegare questi pezzi risponde meglio di chi memorizza definizioni isolate.

Un buon esercizio è prendere un problema e descriverlo per layer: il client riceve policy? vede il contenuto? scarica i file? installa davvero? registra correttamente lo stato? Questo approccio vale più di molte nozioni sparse, perché replica il modo in cui SCCM va davvero gestito in produzione.

In SCCM la differenza tra un ambiente stabile e uno ingestibile spesso non la fanno i singoli role, ma la qualità delle regole di targeting, dei boundary e della lettura dei log.

Se vuoi usare queste domande come traccia di ripasso, prova a rispondere a voce in modo sintetico e poi allarga solo dove serve. In un colloquio conta molto la capacità di spiegare cosa controlleresti prima, cosa consideri un falso positivo e come limiteresti l’impatto di una modifica. Su SCCM, come quasi sempre in sistemi enterprise, il metodo pesa quanto la conoscenza del prodotto.