EWS chiude in Exchange Online il 1° aprile 2027: portare le integrazioni su Microsoft Graph

Microsoft ha iniziato a spegnere Exchange Web Services (EWS) in Exchange Online. I primi passi applicativi partono questo mese, poi i tenant che non hanno mai toccato le impostazioni EWS vengono disattivati uno alla volta, e dal 1° aprile 2027 EWS sparisce per tutti i tenant Microsoft 365. Microsoft ha detto chiaramente che non ci saranno eccezioni oltre aprile 2027.

Se qualcosa che la vostra azienda ha costruito parla con le caselle di Microsoft 365 tramite EWS, smette di funzionare al più tardi in quella data, e forse molto prima. I soliti sospetti: un CRM che archivia le email dei clienti sui rispettivi account, uno script di archiviazione o conservazione, uno schermo per la prenotazione delle sale riunioni, un sistema di ticketing che legge una casella condivisa del supporto, un job di reportistica che conta le email per team. La soluzione è una riscrittura su Microsoft Graph, e alcune cose che EWS sapeva fare in Graph non hanno alcun equivalente.

Cosa succede, data per data

Microsoft controlla EWS per tenant tramite l'impostazione EWSEnabled, che ha tre valori: Null (il predefinito), True e False. Accanto ora c'è una seconda impostazione, EWSAllowedAppIDs: un elenco di ID applicazione a cui è ancora consentito usare EWS. La pagina attuale di Microsoft Learn traccia le linee generali: «ottobre 2026: EWS inizia a essere disattivato a livello globale per tutte le organizzazioni» e «aprile 2027: EWS è completamente disattivato».

I dettagli sono nel post dell'Exchange Team del 1° ottobre, EWS Deprecation Is Here. Per il cloud commerciale mondiale:

• 2 ottobre 2026, a fine giornata ora del Pacifico: Microsoft registra ogni tenant che ha EWSEnabled impostato a True ma nessun elenco di autorizzazione.
• 8 e 9 ottobre 2026: per quei tenant, Microsoft crea l'elenco di autorizzazione e lo riempie con gli ID delle applicazioni che hanno usato EWS nei 60 giorni precedenti.
• Dal 10 ottobre 2026: quando EWSEnabled è True, l'elenco di autorizzazione è obbligatorio. Un'app che non è nell'elenco viene rifiutata.
• Seconda fase, dopo: i tenant ancora a Null si ritrovano EWSEnabled impostato a False, il che blocca EWS per tutte le applicazioni. Ciascuno riceve un preavviso di 7 giorni nel Centro messaggi, e poco prima Microsoft riempie un elenco di autorizzazione in base a 60 giorni di utilizzo, così un amministratore può riattivare EWS con True.
• 1° aprile 2027: EWS è «disattivato in modo completo e permanente», e gli amministratori dei tenant perdono del tutto la possibilità di modificare EWSEnabled.

I tenant negli altri cloud di Microsoft ricevono calendari propri tramite il Centro messaggi.

L'elenco di autorizzazione fa guadagnare tempo, non risolve

L'elenco automatico si basa su 60 giorni di traffico, e le stesse indicazioni di Microsoft del 4 settembre avvertono che «potrebbe non includere applicazioni eseguite di rado». Un'esportazione di fine trimestre o un job di archiviazione di fine anno non ci saranno, e falliranno alla prossima esecuzione.

Le modifiche all'elenco di autorizzazione hanno effetto dopo 24 ore, quelle a EWSEnabled dopo circa un'ora. Qualsiasi correzione fatta dopo un errore costa almeno un giorno.

Per vedere a che punto è il vostro tenant, un amministratore con Exchange Online PowerShell può eseguire:

Get-OrganizationConfig | Format-List EWSEnabled
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

A chi si rivolge, e chi può smettere di leggere

Exchange Server on-premises non è coinvolto. Microsoft dice che il ritiro riguarda «solo Microsoft 365 ed Exchange Online» e che «non ci sono modifiche a EWS in Exchange Server». Se tutte le vostre caselle stanno sui vostri server, potete fermarvi qui.

Le configurazioni ibride vanno guardate da vicino. Le caselle on-premises possono continuare a usare EWS; quelle nel cloud devono passare a Graph. Il post di Microsoft sugli ambienti ibridi del 30 settembre tratta due casi che richiedono un intervento adesso, tra cui le caselle on-premises con archivi in Exchange Online, per le quali il consiglio per ora è tenere EWS attivo e inserire l'applicazione ibrida nell'elenco di autorizzazione.

Il software pacchettizzato è compito del produttore. Se a chiamare EWS è un prodotto commerciale, distribuire una versione per Graph spetta al produttore, e a voi spetta ottenere una data e installare l'aggiornamento. I client di Microsoft non fanno eccezione: alcuni compaiono ancora nei report di utilizzo e hanno bisogno dell'elenco di autorizzazione finché non vengono aggiornati.

Il codice interno è compito vostro. Script, servizi interni, strumenti open source personalizzati e integrazioni costruite anni fa da un'agenzia non hanno nessuno a monte che li sistemi. È lì che sta il lavoro. Per dare un'idea delle dimensioni: exchangelib, una libreria Python per parlare con Exchange tramite EWS, è stata scaricata 1.174.625 volte da PyPI nell'ultimo mese. Una parte è uso on-premises, ma rende l'idea di quanto codice parli direttamente EWS.

Primo passo: trovare tutto ciò che usa EWS

Partite dal report di utilizzo di EWS nell'interfaccia di amministrazione di Microsoft 365 (Report, Utilizzo, Exchange, poi la scheda dell'utilizzo di EWS). Per ogni applicazione elenca l'ID applicazione di Microsoft Entra, ogni azione SOAP chiamata da quell'applicazione, il volume di chiamate e la data dell'ultima attività. Potete guardare indietro di 7, 30 o 90 giorni ed esportare in CSV.

Tre cose da sapere:

• I dati vengono aggregati settimanalmente e possono impiegare fino a 10 giorni per comparire.
• Un ID applicazione non è un responsabile. Confrontate ogni ID con le applicazioni aziendali in Microsoft Entra, poi trovate la persona o il team che la gestisce. Aspettatevi qualche ID che nessuno riconosce.
• La colonna delle azioni SOAP vi dice quanto è grosso ogni lavoro. Un'app che chiama solo FindItem e GetItem è un lavoro breve. Una che chiama SyncFolderItems, Subscribe ed ExportItems è un progetto.

Anche 90 giorni non bastano a cogliere i job annuali, quindi controllate anche dall'altro lato: attività pianificate e voci di cron, e repository di codice in cui cercare l'endpoint di EWS (Exchange.asmx), la EWS Managed API per .NET ed exchangelib. La pagina di Microsoft sul ritiro rimanda anche a un analizzatore EWS per il codice .NET (segnala le chiamate EWS in Visual Studio e VS Code e suggerisce gli equivalenti Graph) e a un tutorial sul refactoring assistito dall'IA.

Secondo passo: decidere cosa diventa ogni integrazione

Ogni applicazione dell'elenco riceve una di quattro risposte:

1. Dismetterla. Alcune integrazioni esistono solo perché nessuno le ha spente.
2. Aggiornarla. I prodotti di terzi ricevono un aggiornamento dal produttore. Concordate la data adesso.
3. Riscriverla su Microsoft Graph. La scelta predefinita per il codice interno.
4. Riprogettarla. Per tutto ciò che si basa su una funzionalità che Graph non avrà mai (vedi sotto).

Microsoft indica anche Power Platform come modo per reimplementare un flusso di lavoro. Per uno script che inoltra gli allegati in una cartella, può essere la risposta più economica.

Cosa comporta davvero una riscrittura su Graph

La maggior parte delle operazioni EWS ha una controparte diretta in Graph, e Microsoft mantiene una corrispondenza tra EWS e Graph. La corrispondenza è la parte facile. Le parti difficili sono quelle che non mostra.

I permessi si restringono, ed è un vantaggio

Un'app che usa EWS senza un utente connesso possiede il permesso applicativo EWS, che Microsoft descrive come «accesso completo a tutte le caselle di posta». Graph lo divide in permessi separati: Mail.Read, Mail.ReadBasic, Mail.Send, Calendars.ReadWrite, MailboxSettings.Read e così via.

Potete anche limitare le caselle che un'app raggiunge. RBAC for Applications in Exchange Online assegna un permesso rispetto a un ambito di gestione o a un'unità amministrativa, e sostituisce le vecchie Application Access Policies. Uno schermo di prenotazione può leggere i calendari di dodici caselle delle sale e nient'altro. Una trappola: le autorizzazioni concesse in questo modo si sommano a qualsiasi autorizzazione a livello di tenant in Microsoft Entra, quindi se Mail.Read ha ancora il consenso lì, il vostro ambito non limita nulla. Rimuovete l'autorizzazione in Entra.

Dove potete, usate certificati anziché segreti client per l'autenticazione delle app, e tenete le credenziali fuori da script e repository.

Sincronizzazione e notifiche si ricostruiscono, non si traducono

Di solito è il cambiamento più grande per tutto ciò che tiene una copia locale dei dati della casella.

Sincronizzazione. SyncFolderItems corrisponde alla delta query sui messaggi di Graph, e SyncFolderHierarchy alla delta query sulle cartelle di posta. La delta sui messaggi lavora una cartella alla volta, quindi una sincronizzazione completa della casella significa seguire l'albero delle cartelle e salvare un delta link separato per ciascuna. I filtri sono limitati (solo sulla data di ricezione), e i risultati comprendono eliminazioni, spostamenti fuori dalla cartella e cambi dello stato di lettura anche quando non corrispondono al filtro.

Notifiche. Le sottoscrizioni streaming e push di EWS diventano notifiche di modifica di Graph, consegnate a un webhook gestito da voi oppure ad Azure Event Hubs o Event Grid. Un webhook deve essere raggiungibile dal lato Microsoft, il che è un cambiamento architetturale per uno script che teneva una connessione aperta da dietro il firewall. Le sottoscrizioni per posta, calendario e contatti durano al massimo 10.080 minuti (poco meno di sette giorni), o 1.440 minuti quando la notifica trasporta i dati, quindi qualcosa deve rinnovarle. Ogni casella consente al massimo 1.000 sottoscrizioni attive tra tutte le applicazioni.

Lo schema che regge: trattate una notifica come un indizio, eseguite la delta query per vedere cosa è cambiato, ed eseguitela anche a intervalli regolari per recuperare ciò che una notifica persa avrebbe fatto perdere.

Dati, ID e capacità

• ID salvati. Se il vostro CRM o sistema di ticketing ha salvato gli ID degli elementi EWS per collegare le email ai record, quei collegamenti vanno convertiti. Graph ha una funzione translateExchangeIds proprio per questo. Pianificate la conversione come un passaggio di migrazione a sé.
• Ricerche. ResolveNames corrisponde alla People API, GetUserAvailability a getSchedule, le impostazioni di fuori sede alle impostazioni della casella. Equivalenti vicini, non identici.
• Limitazione delle richieste. Graph limita ogni coppia di app e casella a 10.000 richieste ogni 10 minuti, quattro richieste simultanee e 150 MB di upload ogni 5 minuti. Un job massivo che faceva girare decine di thread EWS paralleli su una casella va riprogettato intorno a questi numeri.

Le lacune, e ciò che non arriverà mai

Microsoft pubblica una roadmap delle funzionalità EWS ancora mancanti in Graph. Comprende importazione ed esportazione ad alta fedeltà per le caselle di archivio, delle cartelle pubbliche e dei gruppi, l'accesso agli archivi sul posto, i permessi delle cartelle tramite l'Exchange Admin API e la creazione di messaggi non in bozza a partire da MIME. La maggior parte degli obiettivi è fissata al quarto trimestre del 2026. Alcuni erano previsti per il terzo trimestre, che ormai è finito, quindi verificate cosa è stato davvero rilasciato prima di progettarci sopra. L'avvertimento di Microsoft stesso: se una funzionalità non è nella roadmap, «non contateci» come equivalente Graph prima che EWS venga spento.

Tre funzionalità sono confermate come destinate a non arrivare mai in Graph:

• Accesso generico alle cartelle pubbliche (creazione, lettura, modifica ed eliminazione di cartelle ed elementi).
• Accesso generico alle caselle dei Gruppi di Microsoft 365. Graph copre invece conversazioni, thread e post dei gruppi.
• Accesso alle caselle di individuazione. Microsoft indica invece Purview eDiscovery.

Se uno strumento dipende da una di queste, non basta portare il codice: i dati o il flusso di lavoro devono prima spostarsi altrove, e richiede più tempo di una riscrittura.

Un piano di sei mesi

Da oggi al 1° aprile 2027 mancano poco meno di sei mesi. Un ordine realistico:

Ottobre 2026: capire a che punto siete. Controllate EWSEnabled e l'elenco di autorizzazione. Esportate 90 giorni del report di utilizzo. Rivedete l'elenco riempito da Microsoft, togliete ciò che non dovrebbe esserci e aggiungete i job poco frequenti che conoscete. Se il vostro tenant è ancora a Null, valutate di impostare voi l'elenco e True anziché aspettare il passaggio a False da parte di Microsoft e scoprire cosa si rompe.

Novembre 2026: smistamento. Assegnate un responsabile e una risposta (dismettere, aggiornare, riscrivere, riprogettare) a ogni ID applicazione. Analizzate il codice. Segnalate tutto ciò che tocca cartelle pubbliche, caselle dei gruppi o caselle di individuazione e avviate subito la riprogettazione. Create le registrazioni delle app Graph con permessi circoscritti.

Da dicembre 2026 a gennaio 2027: sviluppo. Partite dall'integrazione di cui l'azienda sentirebbe per prima la mancanza. Costruite una volta sola l'infrastruttura di sincronizzazione e notifica e riusatela. Convertite gli ID salvati.

Febbraio 2027: far girare entrambe in parallelo. Finché EWS funziona ancora, fate girare la versione vecchia e quella nuova sulle stesse caselle e confrontate i risultati. Man mano che ciascuna viene accettata, togliete il suo ID dall'elenco di autorizzazione. È anche il test: aspettate le 24 ore e verificate che nient'altro si sia fermato.

Marzo 2027: spegnere EWS da soli. Impostate EWSEnabled a False ben prima del 1° aprile. Tutto ciò che vi è sfuggito fallisce quando potete ancora riattivare EWS. Dopo il 1° aprile quella possibilità sparisce. Fate anche un'esecuzione di prova deliberata dei job trimestrali e annuali prima di allora: un job che gira alla chiusura del primo trimestre girerà per la prima volta dopo la fine di EWS.

Dove trovare aiuto

Il caso difficile è l'integrazione il cui sviluppatore originale se n'è andato. Il nostro servizio di manutenzione dei sistemi legacy è pensato proprio per questo: leggiamo il codice esistente, riscriviamo le parti EWS su Microsoft Graph (permessi, sincronizzazione, notifiche, migrazione degli ID) e facciamo girare vecchio e nuovo in parallelo finché i numeri non coincidono. Se invece vi servono ingegneri che lavorino dentro il vostro team, vedete il nostro servizio di staff augmentation.

Se il vostro report di utilizzo è pieno di ID applicazione che nessuno riconosce, scrivete a office@c9group.dev.