Configurare facilmente le notifiche email di SCCM

Se le notifiche email di SCCM non partono, il problema quasi mai è “SCCM non invia”: di solito si rompe uno dei pezzi attorno al flusso, cioè SMTP, permessi del ruolo, profilo email, DNS, TLS o semplicemente il tipo di alert che stai cercando di notificare. La strada più rapida è configurare tutto in modo minimale, testare il trasporto, poi agganciare gli alert che servono davvero.

Qui sotto trovi un percorso pratico per configurare le notifiche email di SCCM/MECM in modo pulito, con i punti da verificare prima di toccare la console, gli snodi che causano più errori e un set di controlli finali per non scoprire il problema quando manca un update critico o un client è fuori compliance.

Prima di aprire la console: cosa deve esistere già

Le notifiche email in SCCM non sono un sistema di mail generico: dipendono da un mail server raggiungibile dal server del sito o dal componente che genera l’azione, da un mittente valido e da un ruolo amministrativo che abbia i permessi giusti. Se uno di questi elementi manca, la console spesso ti lascia configurare metà strada e poi fallisce al primo invio.

Prima di iniziare, verifica questi punti:

• hai un server SMTP raggiungibile dalla rete del site server;
• sai se il relay richiede autenticazione, TLS o whitelisting per IP;
• hai un indirizzo mittente dedicato, ad esempio sccm-alerts@dominio.tld;
• hai diritti amministrativi sufficienti in SCCM per gestire la configurazione email e gli alert;
• hai una mailbox di test che puoi controllare lato destinatario.

Se non sai ancora quale SMTP usare, chiudi prima quel gap: senza il dato del relay, il resto è solo una configurazione provvisoria. Il modo corretto di chiuderlo è farti dare dal team mail il nome host, la porta, il metodo di autenticazione e l’eventuale policy di relay per IP o account.

Ruolo e permessi: dove SCCM decide se puoi inviare o no

In SCCM le notifiche non si agganciano a un utente “qualsiasi” della console. La configurazione passa da un ruolo amministrativo con privilegi adeguati e, in alcune installazioni, da deleghe più strette sul livello di sicurezza della console. Se stai lavorando con RBAC, non dare per scontato che un account possa vedere la sezione email solo perché può leggere i siti o i device collection.

La verifica minima è questa: entra con l’account che userai per amministrare le notifiche e controlla che la sezione relativa alle email sia visibile. Se non lo è, il problema è di autorizzazione, non di SMTP. In quel caso la correzione va fatta lato ruoli, non lato relay.

Configurare il profilo email in SCCM

La logica corretta è: prima definisci il trasporto, poi il mittente, poi gli alert. Se salti il profilo e vai subito a cercare la notifica di un report o di un avviso, finisci a inseguire sintomi invece della causa.

1. Apri la console di Configuration Manager.
2. Vai nell’area di amministrazione dove sono gestite le impostazioni del sito e le notifiche.
3. Individua la configurazione email del sito o del componente notifiche.
4. Inserisci il server SMTP, la porta e il tipo di connessione richiesto.
5. Specifica il mittente, preferibilmente un indirizzo dedicato e non personale.
6. Salva la configurazione e annota data e ora del cambio per correlare eventuali errori nei log.

Se il tuo SMTP accetta relay senza autenticazione da un IP specifico, è spesso la soluzione più robusta per SCCM: riduce il rischio di gestione credenziali in chiaro o embedded in configurazioni meno trasparenti. Se invece serve autenticazione, usa un account dedicato, con password ruotata e documentata in modo sicuro, non un mailbox personale.

Un esempio pratico di impostazione lato relay, quando hai accesso al server SMTP e vuoi validare il flusso, è questo:

smtp.example.tld:25
sender: sccm-alerts@dominio.tld
relay allowed from: 10.10.10.15

Qui 10.10.10.15 rappresenta l’IP del site server o del server che effettivamente invia. Se non sai quale host stia originando il traffico, non andare a tentativi: identifica prima il punto di uscita con un test di rete o con i log del servizio coinvolto.

Test SMTP: prima il trasporto, poi la logica applicativa

Il test vero non è “ho salvato la configurazione”, ma “un messaggio esce e arriva”. In questa fase devi separare il problema di trasporto da quello di SCCM. Se il relay non accetta il messaggio da linea di comando, SCCM non lo farà magicamente funzionare.

Dal server che invierà la posta, prova un test base. Su Linux useresti strumenti diversi, ma su Windows Server la verifica pratica passa spesso da PowerShell o da un client SMTP di test. Se hai già un relay raggiungibile, controlla prima la porta e la connettività:

Test-NetConnection smtp.example.tld -Port 25

Atteso: TcpTestSucceeded : True. Se è False, il problema è di rete, firewall o routing. In quel caso non ha senso toccare SCCM finché la porta non è aperta o il relay non è raggiungibile.

Se il tuo ambiente richiede TLS, verifica anche che il relay presenti un certificato valido e che il nome usato in configurazione coincida con il SAN o il CN previsto. Un mismatch qui genera errori intermittenti o rifiuti che sembrano “notifiche non inviate”, ma in realtà sono fallimenti di handshake.

Log utili quando l’email non parte

Quando il test fallisce, il punto non è leggere “tutti i log”, ma guardare quelli che hanno davvero il segnale giusto. In SCCM il log più utile dipende dal componente che sta generando la notifica, ma la logica è sempre la stessa: cercare errori di connessione SMTP, autenticazione, permessi o formati non validi del destinatario.

Se hai accesso ai log del site server o del componente di notifica, cerca stringhe come queste:

SMTP connection failed
Authentication failed
Mailbox unavailable
Relay denied
TLS handshake failed

Se il problema è nel trasporto, il log spesso mostra un errore immediato e ripetibile. Se invece il log è pulito ma la mail non arriva, allora il problema è più probabilmente lato destinatario: filtro antispam, quarantena, policy di trasporto o regole della mailbox.

Un controllo spesso ignorato è il filtro sul dominio mittente. Se usi un indirizzo generico o un dominio non allineato con SPF/DKIM/DMARC, il messaggio può essere accettato dal relay ma poi fermato a valle. In quel caso la configurazione SCCM è corretta, ma la consegna non lo è. La correzione passa dal mail team, non dalla console SCCM.

Attivare gli alert giusti, non tutti gli alert

Una configurazione email ben fatta fallisce comunque se abiliti alert troppo rumorosi o non pertinenti. In SCCM conviene partire da pochi eventi ad alto valore: errori di distribuzione contenuti, fallimenti di compliance, problemi di aggiornamento, stato critico di client o infrastruttura. L’obiettivo non è ricevere tutto, ma ricevere ciò che richiede azione umana.

1. Individua gli alert più utili per il tuo contesto operativo.
2. Abilita la notifica email solo per quei casi.
3. Associa un destinatario o una lista dedicata, non un inbox personale.
4. Verifica che la frequenza non generi spam operativo.
5. Documenta chi riceve cosa e in quali condizioni.

In ambienti grandi, una sola mailbox per tutto è una cattiva idea. Meglio separare per funzione: ad esempio una casella per deployment, una per compliance e una per incidenti infrastrutturali. Così puoi filtrare e fare triage senza trasformare la posta in una coda ingestibile.

Esempio di percorso operativo pulito

Se devi metterlo in piedi da zero, questo è un flusso che riduce i falsi positivi:

1. Conferma con il team mail il relay SMTP, la porta e il metodo di autenticazione.
2. Verifica con Test-NetConnection che il server SCCM raggiunga il relay.
3. Configura il mittente dedicato in SCCM.
4. Invia un messaggio di test verso una mailbox esterna al dominio del server.
5. Controlla gli header del messaggio ricevuto per vedere il percorso effettivo.
6. Abilita un solo alert a basso rumore e verifica che arrivi in tempi ragionevoli.
7. Espandi gradualmente agli altri alert solo dopo conferma operativa.

Questa sequenza è più lenta di una configurazione “a sensazione”, ma ti evita il classico scenario in cui tutto sembra impostato correttamente e poi il primo alert serio sparisce in un black hole di relay, filtri o permessi mancanti.

Errori tipici che fanno perdere tempo

• usare un indirizzo mittente non autorizzato dal relay;
• confondere il server SMTP con il server SMTP autenticato del proprio tenant cloud;
• aprire la porta giusta ma bloccare il traffico in uscita con firewall applicativi o policy di rete;
• ignorare il certificato TLS del relay quando il server richiede STARTTLS;
• inviare verso una mailbox che filtra automaticamente i messaggi di sistema;
• abilitare troppi alert senza una logica di priorità.

Il punto più insidioso è il terzo: la porta può risultare raggiungibile da un test generico, ma il percorso reale del servizio SCCM può essere diverso per identità di servizio, proxy, segmentazione o policy locali. Quando succede, il test di rete va fatto dal server effettivo e, se possibile, con lo stesso contesto di esecuzione del servizio.

Controllo finale: cosa deve risultare vero

A configurazione completata, devi poter dire con precisione che queste condizioni sono vere:

• il server SCCM raggiunge il relay SMTP;
• il relay accetta il mittente configurato;
• la mail di test arriva alla mailbox prevista;
• gli alert selezionati generano un messaggio quando scatta l’evento;
• i log non mostrano errori ripetuti di autenticazione, TLS o relay denied.

Se uno di questi punti non è vero, non considerare la configurazione “finita”. La parte più costosa in produzione non è il setup iniziale, ma l’illusione che la notifica funzioni mentre in realtà nessuno la sta ricevendo.

Assunzione operativa: il tuo ambiente usa SCCM/MECM su Windows Server recente, con un relay SMTP già disponibile in rete e con controllo amministrativo almeno sul sito e sui log del componente che invia le notifiche.