1 12/10/2026 10 min

Prerequisiti che conviene verificare prima di toccare SCCM

Il ruolo Endpoint Protection in Microsoft Configuration Manager si usa per distribuire, configurare e monitorare Microsoft Defender Antivirus sui client gestiti. In pratica, SCCM diventa il punto di controllo per policy, aggiornamenti delle definizioni e stato di protezione. L’errore più comune è partire dall’installazione del ruolo senza aver chiarito due cose: la versione dell’infrastruttura e il modello di gestione già in uso sui client.

Prima di procedere, conviene distinguere tra ambiente con Defender già attivo e ambiente con antivirus di terze parti. Se c’è già un prodotto di sicurezza endpoint installato, il ruolo Endpoint Protection non “sostituisce” automaticamente nulla: può distribuire policy e monitorare, ma la coesistenza dipende dal comportamento dell’agente presente. In un parco misto, la verifica preliminare evita di interpretare come problema di SCCM quello che in realtà è un conflitto lato endpoint.

Controlla anche che il site server abbia connettività verso i componenti Microsoft necessari per aggiornamenti e sincronizzazione delle definizioni, se prevedi di usare il canale integrato. In ambienti chiusi o con proxy restrittivi, il ruolo funziona comunque, ma devi sapere in anticipo da dove arriveranno le signature e come verrà gestita la distribuzione ai client.

Dove si installa il ruolo e cosa fa davvero

Endpoint Protection si installa come ruolo di sistema in Configuration Manager, tipicamente sul site server o sul server che ospita i componenti del sito primario. Non è un agente da mettere sul client manualmente: il suo scopo è abilitare la gestione centralizzata delle impostazioni di protezione e dei contenuti correlati. Se il tuo obiettivo è solo attivare Microsoft Defender su poche macchine, puoi farlo anche con Group Policy o con impostazioni locali; se invece vuoi coerenza, reporting e distribuzione controllata, SCCM è il punto giusto.

Dal punto di vista operativo, il ruolo aggiunge la parte di integrazione tra console, policy e reporting. Il vantaggio reale non è “installare un antivirus”, ma avere un canale amministrativo unico per abilitazione, eccezioni, schedulazioni e telemetria. Questo vale soprattutto quando devi mantenere standard diversi tra gruppi di dispositivi o tra sedi diverse.

Installazione del ruolo Endpoint Protection in console

La procedura può variare leggermente tra versioni di Configuration Manager, ma la logica resta la stessa: apri la console, vai nella sezione di amministrazione del sito e avvia l’aggiunta del ruolo. In genere il percorso è sotto Administration, poi Site Configuration, quindi Servers and Site System Roles. Da lì selezioni il server interessato e aggiungi il ruolo Endpoint Protection.

  1. Apri la console di Configuration Manager con un account che abbia diritti amministrativi sul site.
  2. Vai in Administration > Site Configuration > Servers and Site System Roles.
  3. Seleziona il server di site system e avvia Add Site System Roles.
  4. Quando compare la lista dei ruoli, scegli Endpoint Protection Point o il ruolo equivalente previsto dalla tua versione.
  5. Verifica i prerequisiti richiesti dalla procedura guidata e conferma la selezione.
  6. Completa il wizard e attendi la distribuzione del ruolo sul server.

In alcune installazioni il nome del ruolo o la schermata possono cambiare, ma il concetto resta identico: devi associare al site system il componente che gestisce le funzionalità Endpoint Protection. Se il wizard segnala dipendenze o warning, non ignorarli a occhi chiusi. In un ambiente di produzione, ogni warning va letto: spesso indica un problema di connettività, permessi o prerequisiti mancanti che poi si traduce in policy non applicate o in reporting incompleto.

Se vuoi tenere traccia della modifica, prima di confermare annota la configurazione attuale del server. Non serve inventarsi un change complesso: basta registrare in modo chiaro quale site system stai modificando e quali ruoli sono già presenti. In caso di rollback, questa informazione evita di togliere un componente sbagliato.

Verifica dei prerequisiti lato client

Il ruolo installato non basta da solo: i client devono essere in grado di ricevere le impostazioni. Il punto di partenza è verificare che i dispositivi siano correttamente assegnati al site e che il client SCCM sia sano. Se il client è rotto, la console mostrerà magari il ruolo come installato, ma il comportamento reale sui dispositivi resterà fermo.

Un controllo utile è il log del client Configuration Manager. Su Windows, i log risiedono in genere sotto C:\Windows\CCM\Logs. I file da guardare dipendono dall’attività, ma per la gestione di compliance e policy sono spesso rilevanti PolicyAgent.log, EndpointProtectionAgent.log e i log legati al client health. Se il client non riceve policy, lì trovi la prima evidenza concreta.

Per un check rapido puoi anche usare PowerShell sul client per capire se Defender è presente e attivo.

Get-MpComputerStatus | Select-Object AMServiceEnabled,AntivirusEnabled,RealTimeProtectionEnabled,AntispywareEnabled

Se i valori risultano incoerenti rispetto alla tua policy attesa, il problema non è per forza nel ruolo SCCM. Potrebbe esserci una GPO che sovrascrive l’impostazione, un antivirus terzo che disabilita Defender, oppure una mancata ricezione della policy da parte del client. La distinzione è importante perché cambia il tipo di intervento.

Configurazione della protezione in SCCM dopo l’installazione

Una volta installato il ruolo, il passo utile è configurare la parte di protezione vera e propria. In Configuration Manager questo significa lavorare sulle impostazioni Endpoint Protection, definire le baseline o le policy necessarie e decidere come distribuirle ai collection target. Qui l’obiettivo non è “accendere un interruttore”, ma stabilire uno standard misurabile.

  1. Apri la sezione dedicata alle impostazioni Endpoint Protection nella console.
  2. Definisci i valori di protezione coerenti con il tuo standard interno: real-time protection, cloud-delivered protection, esclusioni, scansioni programmate.
  3. Assegna la policy a una collection di test prima di toccare il parco completo.
  4. Monitora la ricezione della policy e il risultato sui dispositivi campione.
  5. Solo dopo il test estendi la distribuzione alle collection di produzione.

La fase di test è quella che evita i danni collaterali. Un’esclusione troppo ampia, una scansione schedulata nel momento sbagliato o una policy troppo aggressiva possono creare impatti sulle prestazioni o lasciare scoperte aree importanti. In un contesto enterprise, è meglio una policy inizialmente prudente ma tracciabile che una configurazione “perfetta” sulla carta e ingestibile in produzione.

Se devi verificare che la policy sia arrivata al client, puoi forzare un ciclo di machine policy retrieval dal client SCCM, poi controllare i log. In generale, dopo l’aggiornamento della policy, il client dovrebbe mostrare cambiamenti coerenti nello stato di Defender e nei report del sito.

Distribuzione degli aggiornamenti delle definizioni

Uno degli aspetti più utili del ruolo Endpoint Protection è la gestione dei file di definizione. Su una rete ben organizzata, non conviene lasciare tutto al caso o ai singoli client: meglio decidere da dove arrivano gli update e con quale frequenza. SCCM può aiutare a centralizzare questo flusso, soprattutto se hai segmenti di rete con accesso Internet limitato.

Se usi un punto di aggiornamento definizioni interno, verifica che il contenuto sia distribuito ai distribution point corretti e che i client abbiano il boundary group giusto. Un errore classico è avere il ruolo installato e la policy applicata, ma il client non riesce a scaricare le definizioni perché il contenuto non è raggiungibile. In quel caso il sintomo è una protezione formalmente attiva ma non aggiornata.

Un controllo semplice lato client è confrontare la data dell’ultima firma e lo stato dell’aggiornamento. Se vuoi un riscontro veloce, usa ancora PowerShell:

Get-MpComputerStatus | Select-Object AntivirusSignatureLastUpdated,AntivirusSignatureVersion,AntispywareSignatureLastUpdated

Se la data resta ferma troppo a lungo, il problema va cercato nella distribuzione del contenuto, nella connettività verso il punto di update o nella policy di aggiornamento. Non ha senso “riprovare” a caso: meglio verificare il percorso del contenuto nella console e il log del client, così capisci se il guasto è a monte o a valle.

Log utili quando qualcosa non torna

Quando il ruolo è installato ma il comportamento non è quello atteso, i log sono la parte che separa un’ipotesi da un fatto. Sul server di sito controlla i log del componente SCCM legati al ruolo appena aggiunto, oltre ai log generali del site. Sul client, come già detto, i file più interessanti stanno sotto C:\Windows\CCM\Logs.

In pratica, i segnali da cercare sono tre: installazione del ruolo andata a buon fine, policy distribuita correttamente e stato endpoint coerente sul client. Se uno dei tre manca, hai già ristretto molto il campo. La cosa più utile è abbinare il timestamp dell’azione in console con il timestamp del log, così capisci subito se l’operazione è stata recepita o no.

Per un controllo rapido puoi anche verificare che il servizio del client SCCM sia in esecuzione e che il sistema non abbia errori evidenti di health. Su Windows, un controllo essenziale è:

Get-Service CcmExec

Se il servizio non è avviato, la gestione del client non può funzionare correttamente. In quel caso non insistere sul ruolo Endpoint Protection: prima va rimesso in salute il client SCCM.

Errori tipici e come leggerli senza perdere tempo

Il primo errore tipico è credere che l’installazione del ruolo equivalga alla protezione effettiva dei client. Non è così: il ruolo abilita la gestione, ma il risultato finale dipende da policy, distribuzione e stato del client. Il secondo errore è ignorare la presenza di GPO che confliggono con le impostazioni distribuite da SCCM. Se una policy di dominio forza un comportamento diverso, il client può apparire gestito ma non conformato.

Il terzo errore è trascurare il canale di aggiornamento delle definizioni. In molti ambienti la parte “difesa” si rompe non per il ruolo in sé, ma perché il contenuto non arriva ai dispositivi o arriva in ritardo. Per questo ha senso trattare Endpoint Protection come un flusso completo: ruolo, policy, contenuto, reporting.

Se devi isolare rapidamente il punto di rottura, usa questa sequenza: console, log server, log client, stato Defender, aggiornamento definizioni. È un ordine pratico che evita di passare subito a cambiamenti invasivi.

Approccio prudente al rollout in produzione

In produzione conviene sempre partire da una collection pilota con pochi dispositivi rappresentativi. È il modo migliore per vedere se il ruolo, le policy e gli aggiornamenti si comportano bene in condizioni reali. La collezione pilota dovrebbe includere almeno una macchina standard, una con carico più alto e, se esiste, un endpoint con rete più limitata o sede remota.

Durante il test, misura tre cose: stato di protezione, aggiornamento delle definizioni e assenza di effetti collaterali sulle prestazioni. Se gli endpoint diventano lenti durante le scansioni o se il tasso di errore cresce, il problema non è solo tecnico ma anche di tuning. A quel punto conviene rivedere pianificazione e esclusioni, non spegnere tutto alla cieca.

Se devi fare rollback, il punto di ritorno più semplice è la rimozione del ruolo dal site system e l’annullamento della policy appena distribuita, sempre con attenzione a non toccare componenti condivisi. Prima di rimuovere qualcosa, salva la configurazione della console o annota la policy interessata, così puoi ripristinare la stessa impostazione se il test fallisce.

Quando Endpoint Protection in SCCM è la scelta giusta

Questo ruolo ha senso quando vuoi standardizzare la protezione su un parco Windows gestito e ottenere visibilità centralizzata. È particolarmente utile in ambienti con più sedi, in reti parzialmente isolate o in contesti dove il controllo locale dei client non basta più. Se invece hai pochi host o un modello di sicurezza già coperto da strumenti diversi, può essere più semplice mantenere la gestione fuori da SCCM.

La decisione non è solo tecnica ma anche operativa: il valore di SCCM emerge quando la gestione centralizzata riduce davvero il numero di eccezioni e di interventi manuali. Se finisci per inseguire problemi su ogni client singolarmente, hai scelto uno strumento giusto ma lo stai usando nel posto sbagliato.

Assunzione: la procedura descritta si riferisce a un site Configuration Manager già funzionante, con console amministrativa disponibile e client Windows gestiti da SCCM.