Door Kristijan Sekereš

EWS stopt in Exchange Online op 1 april 2027: uw integraties overzetten naar Microsoft Graph

Een opengeklapte laptop met een e-mailinbox in een donkere kamer

Microsoft is begonnen met het uitschakelen van Exchange Web Services (EWS) in Exchange Online. De eerste handhavingsstappen lopen deze maand, daarna worden tenants die nooit aan hun EWS-instellingen hebben gezeten een voor een uitgeschakeld, en vanaf 1 april 2027 is EWS weg voor elke Microsoft 365-tenant. Microsoft heeft duidelijk gezegd dat er na april 2027 geen uitzonderingen komen.

Praat iets wat uw bedrijf heeft gebouwd via EWS met Microsoft 365-mailboxen, dan werkt het uiterlijk op die datum niet meer, en mogelijk veel eerder. De gebruikelijke verdachten: een CRM dat klantmails bij accounts archiveert, een archiverings- of bewaarscript, een scherm voor het boeken van vergaderruimtes, een ticketsysteem dat een gedeelde supportmailbox leest, een rapportagetaak die e-mails per team telt. De oplossing is herschrijven tegen Microsoft Graph, en een deel van wat EWS kon, heeft in Graph helemaal geen tegenhanger.

Wat er gebeurt, datum voor datum

Microsoft regelt EWS per tenant met de instelling EWSEnabled, die drie waarden kent: Null (de standaard), True en False. Daarnaast is er nu een tweede instelling, EWSAllowedAppIDs: een lijst met applicatie-ID's die EWS nog mogen gebruiken. De huidige pagina op Microsoft Learn geeft de hoofdlijn: “oktober 2026: EWS wordt wereldwijd uitgeschakeld voor alle organisaties” en “april 2027: EWS is volledig uitgeschakeld.”

De details staan in de post van het Exchange-team van 1 oktober, EWS Deprecation Is Here. Voor de wereldwijde commerciële cloud:

  • 2 oktober 2026, einde van de dag Pacific Time: Microsoft legt elke tenant vast waarin EWSEnabled op True staat maar geen toestemmingslijst bestaat.
  • 8 en 9 oktober 2026: voor die tenants maakt Microsoft de toestemmingslijst aan en vult die met de applicatie-ID's die EWS in de voorgaande 60 dagen hebben gebruikt.
  • Vanaf 10 oktober 2026: staat EWSEnabled op True, dan is de toestemmingslijst verplicht. Een app die er niet op staat, wordt geweigerd.
  • Tweede fase, daarna: bij tenants die nog op Null staan, wordt EWSEnabled op False gezet, wat EWS voor elke applicatie blokkeert. Elke tenant krijgt zeven dagen van tevoren een waarschuwing in het Berichtencentrum, en Microsoft vult kort daarvoor een toestemmingslijst op basis van 60 dagen gebruik, zodat een beheerder EWS met True weer kan aanzetten.
  • 1 april 2027: EWS is “volledig en permanent uitgeschakeld”, en tenantbeheerders kunnen EWSEnabled helemaal niet meer wijzigen.

Tenants in de andere clouds van Microsoft krijgen hun eigen tijdlijn via het Berichtencentrum.

De toestemmingslijst koopt tijd, geen oplossing

De automatische lijst wordt opgebouwd uit 60 dagen verkeer, en de eigen richtlijn van Microsoft van 4 september waarschuwt dat die “applicaties kan missen die zelden draaien”. Een export aan het eind van het kwartaal of een archiveringstaak aan het eind van het jaar staat er niet op, en mislukt de volgende keer dat ze draait.

Wijzigingen in de toestemmingslijst worden pas na 24 uur actief, en wijzigingen in EWSEnabled na ongeveer een uur. Elke reparatie na een storing kost u dus minstens een dag.

Om te zien waar uw tenant staat, kan een beheerder met Exchange Online PowerShell het volgende draaien:

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

Voor wie dit is, en wie kan stoppen met lezen

Exchange Server on-premises wordt niet geraakt. Microsoft zegt dat de uitfasering “alleen geldt voor Microsoft 365 en Exchange Online” en dat “er niets verandert aan EWS in Exchange Server”. Staan al uw mailboxen op uw eigen servers, dan kunt u hier stoppen.

Hybride omgevingen verdienen een nadere blik. Mailboxen on-premises kunnen EWS blijven gebruiken; mailboxen in de cloud moeten naar Graph. De post van Microsoft over hybride omgevingen van 30 september behandelt twee gevallen waarin nu actie nodig is, waaronder mailboxen on-premises met archieven in Exchange Online, waarvoor het advies voorlopig luidt EWS ingeschakeld te laten en de hybride applicatie op de toestemmingslijst te zetten.

Standaardsoftware is het werk van de leverancier. Is wat EWS aanroept een commercieel product, dan is het leveren van een Graph-versie het werk van de leverancier, en het uwe om een datum los te krijgen en de update te installeren. De eigen clients van Microsoft zijn niet anders: sommige verschijnen nog in gebruiksrapporten en hebben de toestemmingslijst nodig tot ze zijn bijgewerkt.

Eigen code is uw werk. Scripts, interne diensten, aangepaste opensourcetools en integraties die een bureau jaren geleden bouwde, hebben niemand stroomopwaarts die ze repareert. Daar zit het werk. Ter vergelijking: exchangelib, een Python-bibliotheek om via EWS met Exchange te praten, werd de afgelopen maand 1.174.625 keer gedownload van PyPI. Een deel daarvan is on-premisesgebruik, maar het geeft een idee van hoeveel code rechtstreeks EWS spreekt.

Stap één: vind alles wat EWS gebruikt

Begin met het EWS-gebruiksrapport in het Microsoft 365-beheercentrum (Rapporten, Gebruik, Exchange, daarna het tabblad EWS-gebruik). Per applicatie toont het de applicatie-ID in Microsoft Entra, elke SOAP-actie die de applicatie heeft aangeroepen, het aantal aanroepen en de datum van de laatste activiteit. U kunt 7, 30 of 90 dagen terugkijken en naar CSV exporteren.

Drie dingen om te weten:

  • De gegevens worden wekelijks samengevoegd en kunnen tot 10 dagen nodig hebben om te verschijnen.
  • Een applicatie-ID is geen eigenaar. Koppel elk ID aan de bedrijfsapplicaties in Microsoft Entra en zoek daarna de persoon of het team dat de applicatie beheert. Reken op een paar ID's die niemand herkent.
  • De kolom met SOAP-acties vertelt u hoe groot elke klus is. Een app die alleen FindItem en GetItem aanroept, is een korte klus. Een app die SyncFolderItems, Subscribe en ExportItems aanroept, is een project.

Zelfs 90 dagen mist jaarlijkse taken, dus controleer ook de andere kant: geplande taken en cron-regels, en coderepository's doorzocht op het EWS-endpoint (Exchange.asmx), de EWS Managed API voor .NET en exchangelib. De uitfaseringspagina van Microsoft linkt ook naar een EWS-analyzer voor .NET-code (die EWS-aanroepen in Visual Studio en VS Code markeert en Graph-equivalenten voorstelt) en naar een tutorial over refactoring met hulp van AI.

Stap twee: beslis wat elke integratie wordt

Elke applicatie op de lijst krijgt een van vier antwoorden:

  1. Uitfaseren. Sommige integraties bestaan alleen omdat niemand ze heeft uitgezet.
  2. Bijwerken. Leveranciersproducten krijgen een upgrade van de leverancier. Spreek de datum nu af.
  3. Herschrijven tegen Microsoft Graph. De standaard voor eigen code.
  4. Herontwerpen. Voor alles wat afhangt van een mogelijkheid die Graph nooit zal krijgen (zie hieronder).

Microsoft noemt ook Power Platform als manier om een workflow opnieuw te implementeren. Voor een script dat bijlagen naar een map doorstuurt, kan dat het goedkoopste antwoord zijn.

Wat herschrijven naar Graph echt inhoudt

De meeste EWS-bewerkingen hebben een directe tegenhanger in Graph, en Microsoft onderhoudt een mapping van EWS naar Graph. De mapping is het makkelijke deel. De moeilijke delen zijn die welke ze niet laat zien.

Machtigingen worden smaller, en dat is een voordeel

Een app die EWS gebruikt zonder aangemelde gebruiker, heeft de EWS-applicatiemachtiging, die Microsoft omschrijft als “volledige toegang tot alle mailboxen”. Graph splitst dat op in aparte machtigingen: Mail.Read, Mail.ReadBasic, Mail.Send, Calendars.ReadWrite, MailboxSettings.Read enzovoort.

U kunt ook beperken welke mailboxen een app bereikt. RBAC for Applications in Exchange Online kent een machtiging toe binnen een beheerbereik of een administratieve eenheid, en vervangt de oudere Application Access Policies. Een boekingsscherm voor ruimtes kan dan de agenda's van twaalf ruimtemailboxen lezen en verder niets. Eén valkuil: op deze manier toegekende rechten komen bovenop elke tenantbrede toekenning in Microsoft Entra, dus is Mail.Read daar nog steeds goedgekeurd, dan beperkt uw bereik niets. Verwijder de toekenning in Entra.

Gebruik waar het kan certificaten in plaats van clientgeheimen voor de authenticatie van apps, en houd inloggegevens buiten scripts en repository's.

Synchronisatie en meldingen worden opnieuw gebouwd, niet vertaald

Dit is meestal de grootste verandering voor alles wat een lokale kopie van mailboxgegevens bijhoudt.

Synchronisatie. SyncFolderItems wordt de delta query voor berichten in Graph, en SyncFolderHierarchy de delta query voor mailmappen. Delta voor berichten werkt per map, dus een volledige mailboxsynchronisatie betekent de mappenstructuur bijhouden en per map een aparte deltalink opslaan. Filteren is beperkt (alleen op ontvangstdatum), en de resultaten bevatten verwijderingen, verplaatsingen uit de map en wijzigingen in de leesstatus, ook als die niet aan uw filter voldoen.

Meldingen. Streaming- en pushabonnementen in EWS worden change notifications in Graph, afgeleverd bij een webhook die u zelf draait of bij Azure Event Hubs of Event Grid. Een webhook moet vanaf de kant van Microsoft bereikbaar zijn, en dat is een architectuurwijziging voor een script dat vroeger van achter de firewall een verbinding openhield. Abonnementen voor mail, agenda en contactpersonen duren hoogstens 10.080 minuten (net geen zeven dagen), of 1.440 minuten als de melding de gegevens bevat, dus iets moet ze verlengen. Elke mailbox staat hoogstens 1.000 actieve abonnementen toe, over alle applicaties samen.

Het patroon dat standhoudt: behandel een melding als hint, draai de delta query om te zien wat er is veranderd, en draai die ook op een timer om op te vangen wat een gemiste melding zou hebben laten liggen.

Gegevens, ID's en doorvoer

  • Opgeslagen ID's. Heeft uw CRM of ticketsysteem EWS-item-ID's opgeslagen om e-mails aan records te koppelen, dan moeten die koppelingen worden omgezet. Graph heeft daar precies een functie voor: translateExchangeIds. Plan de omzetting als aparte migratiestap.
  • Opzoekingen. ResolveNames wordt de People API, GetUserAvailability wordt getSchedule, instellingen voor afwezigheid worden mailboxinstellingen. Nauwe equivalenten, geen identieke.
  • Throttling. Graph beperkt elk paar van app en mailbox tot 10.000 verzoeken per 10 minuten, vier gelijktijdige verzoeken en 150 MB aan uploads per 5 minuten. Een bulktaak die tientallen parallelle EWS-threads op één mailbox losliet, moet rond die getallen opnieuw worden ontworpen.

De gaten, en wat nooit komt

Microsoft publiceert een roadmap van EWS-mogelijkheden die nog in Graph ontbreken. Daarop staan onder meer volledige import en export voor archief-, openbare-map- en groepsmailboxen, toegang tot in-place archieven, mapmachtigingen via de Exchange Admin API, en het aanmaken van berichten die geen concept zijn vanuit MIME. De meeste doelen liggen in het vierde kwartaal van 2026. Een paar stonden gepland voor het derde kwartaal, dat inmiddels voorbij is, dus controleer wat er echt is uitgebracht voordat u eromheen ontwerpt. De eigen waarschuwing van Microsoft: staat een mogelijkheid niet op de roadmap, reken dan niet op een Graph-equivalent voordat EWS wordt uitgeschakeld.

Drie mogelijkheden komen bevestigd nooit naar Graph:

  • Generieke toegang tot openbare mappen (mappen en items aanmaken, lezen, bijwerken en verwijderen).
  • Generieke toegang tot Microsoft 365-groepsmailboxen. Graph dekt in plaats daarvan groepsgesprekken, threads en posts.
  • Toegang tot discovery-mailboxen. Microsoft verwijst in plaats daarvan naar Purview eDiscovery.

Hangt een tool van een van deze af, dan is de code overzetten niet genoeg: de gegevens of de workflow moeten eerst ergens anders heen, en dat duurt langer dan herschrijven.

Een plan van zes maanden

Van vandaag tot 1 april 2027 is net geen zes maanden. Een realistische volgorde:

Oktober 2026: zie waar u staat. Controleer EWSEnabled en de toestemmingslijst. Exporteer 90 dagen van het gebruiksrapport. Bekijk de lijst die Microsoft heeft ingevuld, verwijder wat er niet op hoort en voeg de zelden draaiende taken toe die u kent. Staat uw tenant nog op Null, overweeg dan zelf de lijst en True in te stellen in plaats van te wachten tot Microsoft naar False omschakelt en u ontdekt wat er stukgaat.

November 2026: triage. Wijs aan elke applicatie-ID een eigenaar en een antwoord toe (uitfaseren, bijwerken, herschrijven, herontwerpen). Scan de code. Markeer alles wat aan openbare mappen, groepsmailboxen of discovery-mailboxen raakt en begin nu met het herontwerp. Maak de app-registraties voor Graph aan met afgebakende machtigingen.

December 2026 tot januari 2027: bouwen. Begin met de integratie die het bedrijf als eerste zou missen. Bouw het loodgieterswerk voor synchronisatie en meldingen één keer en hergebruik het. Zet opgeslagen ID's om.

Februari 2027: beide naast elkaar draaien. Zolang EWS nog werkt, draait u de oude en de nieuwe versie tegen dezelfde mailboxen en vergelijkt u de output. Is een integratie goedgekeurd, haal haar ID dan van de toestemmingslijst. Dat is meteen de test: wacht de 24 uur af en controleer of er niets anders is gestopt.

Maart 2027: zet EWS zelf uit. Zet EWSEnabled ruim vóór 1 april op False. Alles wat u hebt gemist, mislukt dan op een moment waarop u EWS nog weer kunt aanzetten. Na 1 april is die optie weg. Geef kwartaal- en jaartaken daarvoor ook een bewuste testrun: een taak die draait als het eerste kwartaal wordt afgesloten, draait anders voor het eerst nadat EWS weg is.

Waar u hulp krijgt

Het lastige geval is de integratie waarvan de oorspronkelijke ontwikkelaar is vertrokken. Onze dienst voor onderhoud van legacysystemen is daarvoor gebouwd: we lezen de bestaande code, herschrijven de EWS-delen tegen Microsoft Graph (machtigingen, synchronisatie, meldingen, migratie van ID's) en draaien oud en nieuw naast elkaar tot de cijfers kloppen. Hebt u liever engineers die binnen uw eigen team werken, kijk dan bij onze dienst voor staff augmentation.

Staat uw gebruiksrapport vol applicatie-ID's die niemand herkent, schrijf dan naar office@c9group.dev.