Il problema: server Exchange datati che parlano ancora con Exchange Online

Molte organizzazioni con un deployment ibrido Exchange non hanno mai completato la migrazione completa al cloud: mantengono uno o più server Exchange 2016 o 2019 on-premises esclusivamente per gestire l’autenticazione, i connettori di posta o alcuni carichi di lavoro legacy, mentre il grosso delle cassette postali vive già su Exchange Online. È un’architettura comune, ma comporta un rischio spesso sottovalutato: se quel server ibrido non viene aggiornato, diventa silenziosamente un anello debole nella catena di sicurezza dell’intero tenant.

Microsoft ha deciso di intervenire con un piano di enforcement che, a partire dalla seconda settimana di settembre 2026, comincerà a limitare e infine a bloccare i messaggi provenienti da server Exchange 2016 e 2019 che non rispettano una baseline minima di aggiornamento. La notizia è particolarmente rilevante perché il calendario coincide con questi stessi giorni: chi gestisce un ambiente ibrido dovrebbe verificare la propria postura di patching immediatamente, non “quando avrà tempo”.

Cosa cambia esattamente

Il meccanismo riguarda specificamente i server che inviano posta a Exchange Online attraverso un connettore in ingresso di tipo OnPremises: è la configurazione tipica di un ambiente hybrid, dove il server locale viene autorizzato a inoltrare la posta al cloud bypassando alcuni controlli anti-spam standard, sulla base di una relazione di fiducia. È proprio questa fiducia implicita che Microsoft vuole condizionare a un livello di patching adeguato.

La baseline richiesta è quella dell’ultimo aggiornamento di sicurezza pubblico rilasciato per queste versioni, ovvero il Security Update di ottobre 2025 (Oct25SU) — l’ultimo pacchetto di sicurezza pubblicamente disponibile prima che queste release entrassero nella fase di solo supporto esteso. In pratica, i livelli minimi accettati sono:

• Exchange 2016 CU23 + Oct25SU → build 15.1.2507.61
• Exchange 2019 CU15 + Oct25SU → build 15.2.1748.39
• Exchange 2019 CU14 + Oct25SU → build 15.2.1544.36

Un dettaglio che genera spesso confusione: verificare di avere installato il CU corretto non basta. Bisogna controllare la build completa, perché due server sullo stesso Cumulative Update possono trovarsi a livelli di patch di sicurezza diversi se uno dei due ha saltato l’ultimo rollup.

Come si manifesta l’enforcement

Il processo segue tre fasi progressive, già collaudate da Microsoft su altre versioni obsolete di Exchange in passato: segnalazione, throttling e infine blocco.

Throttling

Nella fase di rallentamento, Exchange Online ritarda deliberatamente l’accettazione dei messaggi in arrivo dai server non conformi. Il sintomo tipico è un accumulo di code sul server mittente, con retry ripetuti: da fuori sembra un problema di congestione della rete o del server, e questo rende il throttling insidioso da diagnosticare se non si sa cosa cercare.

Blocco

Superata la fase di throttling, i messaggi vengono respinti in modo esplicito, generando NDR (non-delivery report) per i mittenti. A quel punto il problema diventa visibile a tutti — utenti compresi — ma nel frattempo l’organizzazione avrà già perso giorni preziosi di consegna della posta.

Come verificare la propria esposizione

Il primo passo è capire quali server nel proprio ambiente utilizzano effettivamente un connettore OnPremises. Da Exchange Online PowerShell:

Get-InboundConnector |
  Where-Object ConnectorType -eq 'OnPremises' |
  Format-List Name,Enabled,SenderIPAddresses,TlsSenderCertificateName

Questo comando elenca i connettori attivi e gli indirizzi IP autorizzati a inviare posta attraverso di essi: è la mappa di partenza per capire quali server on-premises sono coinvolti.

Sul singolo server Exchange, la versione esatta della build si verifica interrogando ExSetup.exe, molto più affidabile del semplice numero di build mostrato nell’Exchange Admin Center:

Get-Command ExSetup.exe |
  ForEach-Object { $_.FileVersionInfo } |
  Format-List ProductVersion,FileVersion,FileName

Per un controllo più ampio, che copra anche altri parametri di salute del server (certificati in scadenza, servizi non funzionanti, configurazioni TLS deboli), vale la pena eseguire lo script Exchange Health Checker, lo strumento diagnostico ufficiale mantenuto dal team Exchange su GitHub, che segnala automaticamente anche gli scostamenti dalla baseline di sicurezza raccomandata.

Cosa fare prima della scadenza

Il piano d’azione per chi si trova sotto la baseline è relativamente lineare, ma richiede una finestra di manutenzione pianificata con attenzione:

• Individuare tutti i server che instradano posta tramite connettori OnPremises e verificarne la build esatta.
• Programmare l’installazione dell’aggiornamento di sicurezza di ottobre 2025 (o successivo, se nel frattempo Microsoft ne rilascia uno più recente per questi rami) durante una finestra di manutenzione, con riavvio del server.
• Ripetere la verifica della build dopo il riavvio: un’installazione fallita silenziosamente è più comune di quanto si pensi.
• Testare i percorsi di failover e i bilanciamenti di carico se si dispone di più server ibridi, per assicurarsi che l’aggiornamento non abbia introdotto regressioni nel routing della posta.

Chi non riesce a completare l’aggiornamento entro i tempi può richiedere una esenzione temporanea, valida fino a 90 giorni per tenant per anno solare (frazionabile in più blocchi), tramite l’Exchange Admin Center o il cmdlet dedicato alla gestione delle esenzioni di enforcement. È una valvola di sfogo utile per chi ha vincoli di change management stringenti, ma va vista come un rinvio, non come una soluzione: la strada obbligata resta l’aggiornamento, oppure — nel medio termine — la migrazione a Exchange Server Subscription Edition o il completamento dello spostamento delle cassette postali residue su Exchange Online.

Conclusione

Questo enforcement non è un capriccio burocratico: i server Exchange ibridi non aggiornati sono uno dei vettori più sfruttati per compromissioni che, partendo dalla posta, arrivano fino ad Active Directory. Microsoft sta semplicemente smettendo di fidarsi implicitamente di infrastrutture che non dimostrano di essere mantenute in modo attivo. Per i sistemisti che gestiscono ambienti ibridi, il consiglio pratico è di eseguire subito i comandi PowerShell indicati sopra, capire la propria esposizione reale e pianificare l’aggiornamento prima che il throttling si trasformi in un incidente di produzione con gli utenti che segnalano email in ritardo o mai arrivate.

Fonte: Practical365 e Microsoft Tech Community.