Il 10 ottobre 2026 Exchange Online smette di fare da “buon vicino” con le applicazioni che parlano ancora Exchange Web Services (EWS). Da quella data, avere EWS abilitato sul tenant non basta più: ogni app, script o integrazione che chiama EWS deve comparire in un elenco esplicito di AppID autorizzati, altrimenti viene bloccata all’istante. È la fase finale di un ritiro annunciato da anni, ma che molti amministratori hanno rimandato perché “funzionava ancora tutto”. Questo articolo spiega cosa cambia davvero, come verificare se il vostro tenant è a rischio e come costruire l’allow list senza rompere le integrazioni .NET o PowerShell che dipendono da EWS.

Cos’è EWSAllowedAppIDs

EWSAllowedAppIDs è un parametro della configurazione dell’organizzazione Exchange Online che funziona come allow list: contiene l’elenco, separato da virgole, degli Application ID (AppID) di Microsoft Entra ID autorizzati a usare EWS. Qualsiasi chiamata EWS proveniente da un’app il cui AppID non è in quella lista viene rifiutata, indipendentemente dal fatto che EwsEnabled sia impostato su $true.

In pratica Microsoft sta trasformando un interruttore “on/off” globale in un controllo granulare per singola applicazione, lo stesso modello già visto con le app EWS “note” (Outlook per Mac, Skype for Business, strumenti di migrazione) negli anni precedenti.

Le date che contano

La timeline comunicata da Microsoft nel Message Center (MC1485116) è questa:

• 2 ottobre 2026 — Microsoft individua i tenant interessati; da questa data ogni nuova abilitazione di EWS richiede la configurazione manuale dell’AppID.
• 8-9 ottobre 2026 — per i tenant che avevano già EwsEnabled = $true ma nessuna lista configurata, Microsoft popola automaticamente EWSAllowedAppIDs sulla base dell’attività osservata negli ultimi 60 giorni.
• 10 ottobre 2026 — inizia l’enforcement: le applicazioni non presenti nella lista perdono l’accesso a EWS.
• Entro luglio 2027 — completamento del rollout su tutti gli ambienti, inclusi GCC, GCC High e DoD.

Il punto debole dell’auto-popolamento è evidente: un job pianificato che chiama EWS una volta al mese, o un’integrazione usata solo a fine trimestre, può restare fuori dalla finestra di osservazione dei 60 giorni e quindi fuori dall’allow list automatica.

Come verificare lo stato del tenant

Il primo comando da eseguire, con il modulo Exchange Online PowerShell connesso, è:

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsEnabled, EwsAllowedAppIDs

Attenzione a un dettaglio poco intuitivo: lo switch -RetrieveEwsOperationAccessPolicy è obbligatorio. Senza di esso, EwsAllowedAppIDs viene restituito vuoto anche se in realtà è configurato, inducendo falsi allarmi (o false sicurezze).

Trovare le applicazioni che usano ancora EWS

Prima di scrivere la lista, bisogna sapere cosa c’è davvero in circolazione. L’approccio consigliato combina due fonti:

1. La lista attuale (se esiste) restituita dal comando sopra.
2. Le service principal di Microsoft Entra ID che possiedono il ruolo applicativo full_access_as_app su Exchange Online, il cui Role ID è dc890d15-9560-4a4c-9b7f-a736ec74ec40.

Con il modulo Microsoft Graph PowerShell è possibile incrociare le due liste:

Connect-MgGraph -Scopes "Application.Read.All"

$ewsRoleId = "dc890d15-9560-4a4c-9b7f-a736ec74ec40"
$exchangeSpn = Get-MgServicePrincipal -Filter "AppId eq '00000002-0000-0ff1-ce00-000000000000'"

Get-MgServicePrincipal -All | ForEach-Object {
    $assignments = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $_.Id
    if ($assignments.AppRoleId -contains $ewsRoleId) {
        [PSCustomObject]@{ DisplayName = $_.DisplayName; AppId = $_.AppId }
    }
}

Il risultato è l’elenco delle app che potrebbero ancora dover parlare con EWS. Confrontandolo con la lista già approvata si individuano sia le app dimenticate (permesso presente, ma assenti dall’allow list) sia gli AppID “fantasma” già presenti nella lista ma di origine incerta, probabilmente da ripulire.

Configurare l’allow list senza sorprese

Il comando per impostare la lista è semplice, ma nasconde un comportamento critico: la lista viene sovrascritta interamente, non esiste un’operazione di append.

Set-OrganizationConfig -EwsEnabled $true -EwsAllowedAppIDs "f8d98a96-0999-43f5-8af3-69971c7bb423,<app-id-1>,<app-id-2>"

Questo significa che ogni modifica deve includere tutti gli AppID necessari in un unico comando, Outlook e gli strumenti Microsoft compresi se risultano nei log di utilizzo (Outlook classico, Power Query in Excel, alcuni connettori Power BI possono ancora passare da EWS in scenari legacy). Dimenticare un solo AppID equivale a disattivare quell’integrazione dal giorno alla notte.

Un altro dettaglio operativo da non sottovalutare: le modifiche alla allow list richiedono fino a 24 ore per propagarsi su tutto il servizio. Chi arriva al 9 o 10 ottobre a correggere la lista rischia una finestra di downtime non banale.

La vera via d’uscita: migrare a Microsoft Graph

EWSAllowedAppIDs è un cerotto, non una cura. La direzione strategica di Microsoft resta la stessa da anni: migrare da EWS alle API di Microsoft Graph per Mail, Calendar e Contacts. Per chi mantiene integrazioni .NET basate sulla EWS Managed API, il percorso tipico è sostituire le chiamate SOAP con il Microsoft Graph SDK per .NET:

var graphClient = new GraphServiceClient(credential, scopes);

var messages = await graphClient.Users["user@contoso.com"]
    .Messages
    .GetAsync(config =>
    {
        config.QueryParameters.Top = 25;
        config.QueryParameters.Select = new[] { "subject", "from", "receivedDateTime" };
    });

Il vantaggio non è solo la sopravvivenza alla scadenza del 10 ottobre: le API Graph supportano permessi granulari con Microsoft Entra ID, throttling più predicibile e webhook nativi, assenti nel mondo EWS.

Checklist operativa prima del 10 ottobre

• Eseguire Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy su ogni tenant gestito.
• Incrociare la lista con le service principal che hanno il ruolo full_access_as_app.
• Includere esplicitamente le app Microsoft first-party se emergono dai log di utilizzo.
• Pianificare la modifica con almeno 24-48 ore di margine, non il 9 ottobre pomeriggio.
• Avviare (o completare) la migrazione delle integrazioni critiche verso Microsoft Graph, trattando EWSAllowedAppIDs come misura ponte.

Fonte: 4sysops e Microsoft Tech Community.