Come configurare gli avvisi di spazio disco basso per SCCM

Se vuoi avvisi utili sullo spazio disco basso in SCCM, la regola è semplice: non basta “sapere che un disco è pieno”, serve decidere quando avvisare, chi deve ricevere il segnale e quale evidenza usare per evitare falsi positivi. In pratica il lavoro si divide in tre livelli: raccolta della metrica sul client, soglia di allarme in SCCM e canale di notifica verso chi gestisce l’infrastruttura.

La strada più pulita, in ambienti Microsoft, è usare un Configuration Item o una combinazione di Compliance Settings e Alert legati a una baseline. Se l’obiettivo è un avviso operativo, la parte importante non è solo “leggere il disco”, ma tradurre quel dato in una condizione verificabile e ripetibile. Un disco al 10% libero su una workstation non ha lo stesso peso di un file server con volumi dati critici: la soglia va tarata sul ruolo della macchina, non sul numero in astratto.

Decidere la soglia prima della console

Prima di aprire SCCM, definisci la policy. In genere si lavora con due soglie: una di warning e una di critical. Per esempio, warning sotto il 15% di spazio libero e critical sotto il 10%. Su server con picchi di crescita rapida, conviene aggiungere anche una soglia basata su GB liberi assoluti, perché una percentuale può essere fuorviante su dischi molto grandi.

Questa scelta non è cosmetica: incide sul numero di ticket, sulla fiducia nel sistema di alert e sulla possibilità di automatizzare la remediation. Se segnali troppo presto, l’operatore ignora l’avviso; se segnali troppo tardi, arrivi alla saturazione e perdi margine per operare con calma.

Un criterio pratico è questo: usa la percentuale per la visibilità generale, e i GB liberi per evitare che un volume enorme con il 12% residuo ma ancora 300 GB disponibili venga trattato come emergenza. Viceversa, un volume piccolo con 8 GB liberi può essere già critico anche se la percentuale sembra accettabile.

Raccogliere il dato sul client con una baseline di compliance

In SCCM, il modo più robusto per controllare lo spazio disco è creare una Configuration Item che verifica una proprietà locale del sistema e la confronta con una soglia. La verifica può essere fatta con script PowerShell, che hanno il vantaggio di essere abbastanza leggibili e facili da aggiornare senza ricostruire tutto il pacchetto di monitoraggio.

Il principio è questo: lo script legge i volumi locali, filtra quelli che vuoi monitorare e produce un esito compliant/non-compliant. La baseline poi genera il segnale che puoi usare per l’alert. Se la macchina non rispetta la condizione, SCCM la marca come non conforme e puoi agganciare notifica, collection o remediation.

Uno script minimo per verificare lo spazio libero su un volume può essere simile al seguente. È volutamente semplice: non fa automazioni distruttive, non modifica nulla, e serve solo a produrre un esito leggibile dal sistema di gestione.

Get-PSDrive -PSProvider FileSystem | Select-Object Name, Free, Used, @{Name='FreeGB';Expression={[math]::Round($_.Free/1GB,2)}}

In produzione però non basta stampare valori. Devi trasformare il controllo in una condizione, per esempio: “se FreeGB è inferiore a 10, allora non conforme”. In una CI puoi usare uno script di detection che restituisce exit code coerenti oppure un valore da confrontare con la soglia. Il punto è mantenere la logica leggibile, così quando fra sei mesi qualcuno dovrà cambiare la soglia non dovrà decifrare un controllo oscuro.

Se devi escludere alcuni volumi, fallo esplicitamente. Non dare per scontato che tutti i dischi vadano trattati allo stesso modo: spesso il disco di sistema ha una soglia diversa da un volume dati, e il disco destinato a cache o staging può avere un comportamento ancora differente.

Configurare l’avviso in SCCM con Compliance Settings

La parte operativa in console segue questa logica: crei la CI, la inserisci in una baseline e poi colleghi la baseline a una collection di dispositivi. Il percorso esatto può variare leggermente in base alla versione, ma il flusso resta quello.

Qui il punto delicato è la raccolta. Se la baseline valuta troppo raramente, rischi di scoprire il problema quando il disco è già al limite. Se valuta troppo spesso, aumenti il rumore e il carico amministrativo. In ambienti server, una cadenza ogni poche ore è spesso più sensata di un controllo giornaliero; per workstation può bastare meno frequente, a seconda della criticità.

Quando SCCM marca il client come non conforme, hai il segnale base. Da lì puoi decidere se usare il reporting nativo, una subscription a SSRS, una dashboard, oppure un’integrazione con mail o sistema ticket. La scelta dipende da quanto vuoi che l’alert sia immediato e da chi deve riceverlo.

Collegare la non conformità a un alert operativo

Il valore della baseline cresce quando la trasformi in un evento osservabile. In SCCM puoi usare i meccanismi di alerting e reporting per far emergere la condizione di non conformità. Se l’ambiente è ben strutturato, l’alert dovrebbe contenere almeno: nome del device, volume interessato, soglia violata, valore rilevato e timestamp dell’ultima valutazione.

Se il tuo processo passa da report a ticket, evita il classico errore di inviare solo “disco basso” senza contesto. Un operatore che riceve un alert così deve aprire mezza console per capire se si tratta del C:, di un data volume o di una macchina temporanea. Molto meglio includere già i campi utili nel messaggio o nel template del ticket.

Un esempio pratico di contenuto minimo per la notifica:

Host: SRV-FILE-12
Volume: D:
Free space: 8.4 GB
Threshold: 10 GB
Status: Non compliant
Last evaluation: 2026-04-16 08:00

Questo tipo di messaggio è molto più utile di un avviso generico. Se poi hai una pipeline verso un sistema di ticketing, puoi aggiungere priorità e gruppo di assegnazione in base al tipo di server o alla collection SCCM di appartenenza.

Usare PowerShell dove SCCM non basta

In alcuni ambienti la UI di SCCM non copre bene la logica che vuoi applicare. In quel caso PowerShell è il modo più pulito per standardizzare il controllo. Puoi usarlo per leggere i volumi, filtrare quelli locali, escludere punti di mount particolari e produrre un output coerente per il meccanismo di compliance.

Per esempio, se vuoi verificare il volume di sistema e ottenere un esito semplice, puoi scrivere uno script che restituisce un valore booleano o un codice di uscita. La logica deve essere banale da leggere, perché il vero rischio non è il codice in sé: è la manutenzione nel tempo.

$thresholdGB = 10
$drive = Get-PSDrive -Name C -PSProvider FileSystem
if (($drive.Free / 1GB) -lt $thresholdGB) {
    Write-Output 'Non compliant'
    exit 1
}
Write-Output 'Compliant'
exit 0

Questo esempio non è pensato per essere copiato alla cieca in produzione, ma per mostrare la struttura. Se devi usarlo davvero, aggiungi gestione degli errori, log locale e un elenco esplicito dei volumi da controllare. Nei server con storage multiplo, il controllo su un solo drive non basta quasi mai.

Ridurre falsi positivi e rumore operativo

Gli avvisi sul disco diventano inutili quando non distingui tra saturazione reale e crescita attesa. Un file server che riceve archivi giornalieri può scendere sotto soglia in modo fisiologico prima del ciclo di pulizia. In quel caso l’alert deve essere calibrato sul processo, non solo sul numero.

Per limitare il rumore, applica almeno una di queste regole: soglie diverse per ruolo macchina, esclusione di volumi temporanei, finestra di osservazione prima dell’alert, o doppia condizione percentuale+GB. Se hai un cluster o un ambiente virtualizzato, considera anche il comportamento dello storage sottostante: il disco guest può sembrare lento a crescere, ma il datastore host può essere già vicino al limite.

Un altro errore frequente è non documentare chi deve intervenire quando scatta l’alert. Se il team endpoint riceve notifiche per server critici senza sapere che esiste un owner di applicazione, il ticket rimbalza. L’avviso deve portare già il minimo indispensabile per indirizzare la presa in carico.

Verifiche dopo il deploy

Dopo aver distribuito la baseline, verifica tre cose: che i client ricevano la policy, che la valutazione produca uno stato coerente e che l’alert sia effettivamente generato quando la soglia viene superata. Se una di queste tre parti manca, il sistema è incompleto anche se in console “sembra tutto verde”.

Se il test non genera alert, il problema può stare nella baseline, nella raccolta del dato, nella distribuzione della policy o nel canale di notifica. Non saltare subito a cambiare soglia: prima dimostra dove si rompe il flusso.

Rollback e modifica sicura

Ogni modifica alla baseline o allo script va trattata come change controllato. Prima di pubblicarla, conserva una copia della CI e della baseline precedente, oppure esporta l’oggetto se il tuo processo lo consente. Se l’avviso produce troppo rumore, il rollback deve essere rapido: disabilitare la distribuzione, riportare la soglia precedente o sospendere temporaneamente la notifica è preferibile a cancellare tutto e ricostruire da zero.

Se il controllo è stato implementato via script, il rollback più sicuro è ripristinare la versione precedente del file e rilanciare la valutazione. Se invece hai toccato anche un canale di notifica esterno, tieni presente il blast radius: puoi continuare a ricevere alert duplicati o perderli del tutto se il binding tra SCCM e sistema esterno non è stato verificato.

In sintesi operativa: definisci soglia e ambito, implementa la compliance in SCCM, collega la non conformità a un alert utile, verifica con un test controllato e conserva sempre la possibilità di tornare indietro senza interrompere il resto del monitoraggio.