EWS ophører i Exchange Online 1. april 2027: sådan flytter I jeres integrationer til Microsoft Graph

Åben bærbar computer med en e-mailindbakke i et mørkt rum

Microsoft er begyndt at slukke for Exchange Web Services (EWS) i Exchange Online. De første håndhævelsestrin kører i denne måned, lejere (tenants), der aldrig har rørt deres EWS-indstillinger, bliver derefter slukket én efter én, og fra 1. april 2027 er EWS væk for alle Microsoft 365-lejere. Microsoft har sagt ligeud, at der ikke vil være nogen undtagelser efter april 2027.

Taler noget, jeres virksomhed har bygget, med Microsoft 365-postkasser over EWS, holder det op med at virke senest på den dato og muligvis meget før. De sædvanlige mistænkte: et CRM-system, der arkiverer kundemails på konti, et script til arkivering eller opbevaring, en skærm til booking af mødelokaler, et ticketsystem, der læser en delt supportpostkasse, et rapportjob, der tæller e-mails pr. team. Løsningen er en omskrivning mod Microsoft Graph, og noget af det, EWS kunne, har slet ikke noget modstykke i Graph.

Hvad der sker, dato for dato

Microsoft styrer EWS pr. lejer gennem indstillingen EWSEnabled, som har tre værdier: Null (standard), True og False. Ved siden af findes nu en anden indstilling, EWSAllowedAppIDs: en liste over applikations-id'er, der stadig må bruge EWS. Den aktuelle side på Microsoft Learn giver det overordnede billede: »Oktober 2026: EWS begynder at blive deaktiveret globalt for alle organisationer« og »April 2027: EWS er fuldt deaktiveret.«

Detaljerne står i Exchange-teamets indlæg fra 1. oktober, EWS Deprecation Is Here. For den globale kommercielle cloud:

2. oktober 2026, ved dagens udgang, stillehavstid (Pacific Time): Microsoft registrerer alle lejere, der har EWSEnabled sat til True, men ingen tilladelsesliste.
8. og 9. oktober 2026: for de lejere opretter Microsoft tilladelseslisten og fylder den med de applikations-id'er, der har brugt EWS inden for de seneste 60 dage.
Fra 10. oktober 2026: når EWSEnabled er True, er tilladelseslisten påkrævet. En app, der ikke står på den, afvises.
Anden fase, derefter: lejere, der stadig står på Null, får EWSEnabled sat til False, hvilket blokerer EWS for alle applikationer. Hver får en advarsel syv dage før i Message Center, og kort forinden fylder Microsoft en tilladelsesliste ud fra 60 dages brug, så en administrator kan slå EWS til igen med True.
1. april 2027: EWS er »fuldt og permanent deaktiveret«, og lejernes administratorer mister helt muligheden for at ændre EWSEnabled.

Lejere i Microsofts andre clouds får deres egne tidsplaner gennem Message Center.

Tilladelseslisten køber tid, ikke en løsning

Den automatiske liste bygges ud fra 60 dages trafik, og Microsofts egen vejledning af 4. september advarer om, at den »kan overse applikationer, der kører sjældent«. En eksport ved kvartalsslut eller et arkivjob ved årsskiftet vil ikke stå på den og fejler, næste gang det kører.

Ændringer i tilladelseslisten tager 24 timer om at træde i kraft, og ændringer i EWSEnabled tager omkring en time. Enhver rettelse, I laver efter en fejl, koster mindst en dag.

For at se, hvor jeres lejer står, kan en administrator med Exchange Online PowerShell køre:

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

Hvem det her er til, og hvem der kan stoppe med at læse

Exchange Server i eget datacenter er ikke berørt. Microsoft siger, at udfasningen gælder »kun Microsoft 365 og Exchange Online«, og at »der ikke er nogen ændringer af EWS i Exchange Server«. Ligger alle jeres postkasser på jeres egne servere, kan I stoppe her.

Hybride opsætninger kræver et nærmere kig. Postkasser i eget datacenter kan fortsætte med at bruge EWS; postkasser i skyen skal flytte til Graph. Microsofts indlæg om hybridmiljøer af 30. september dækker to tilfælde, der kræver handling nu, herunder postkasser i eget datacenter med arkiver i Exchange Online, hvor rådet indtil videre er at holde EWS slået til og sætte hybridapplikationen på tilladelseslisten.

Standardsoftware er leverandørens opgave. Er det, der kalder EWS, et kommercielt produkt, er det leverandørens opgave at levere en Graph-version, og jeres opgave er at få en dato fra dem og installere opdateringen. Microsofts egne klienter er ikke anderledes: nogle optræder stadig i forbrugsrapporterne og har brug for tilladelseslisten, indtil de er opdateret.

Egenudviklet kode er jeres opgave. Scripts, interne tjenester, tilpassede open source-værktøjer og integrationer, som et bureau byggede for år tilbage, har ingen opstrøms til at rette dem. Det er dér, arbejdet ligger. Til sammenligning: exchangelib, et Python-bibliotek til at tale med Exchange over EWS, blev hentet 1.174.625 gange fra PyPI inden for den seneste måned. Noget af det er brug mod Exchange i eget datacenter, men det giver et indtryk af, hvor meget kode der taler EWS direkte.

Trin et: find alt, der bruger EWS

Start med rapporten over EWS-forbrug i Microsoft 365 Administration (Reports, Usage, Exchange og derefter fanen EWS usage). For hver applikation viser den applikations-id'et i Microsoft Entra, hver SOAP-handling, applikationen har kaldt, antallet af kald og datoen for seneste aktivitet. I kan se 7, 30 eller 90 dage tilbage og eksportere til CSV.

Tre ting, I skal vide om den:

Data samles ugentligt og kan tage op til 10 dage om at dukke op.
Et applikations-id er ikke en ejer. Match hvert id mod Enterprise applications i Microsoft Entra, og find derefter den person eller det team, der driver det. Regn med nogle få id'er, som ingen genkender.
Kolonnen med SOAP-handlinger fortæller jer, hvor stor hver opgave er. En app, der kun kalder FindItem og GetItem, er en kort opgave. En, der kalder SyncFolderItems, Subscribe og ExportItems, er et projekt.

Selv 90 dage overser årlige job, så tjek også den anden side: planlagte opgaver og cron-poster samt kodearkiver gennemsøgt for EWS-endpointet (Exchange.asmx), EWS Managed API til .NET og exchangelib. Microsofts side om udfasningen linker også til en EWS-analysator til .NET-kode (den markerer EWS-kald i Visual Studio og VS Code og foreslår modstykker i Graph) og en vejledning i AI-assisteret refaktorering.

Trin to: beslut, hvad hver integration skal blive til

Hver applikation på listen får et af fire svar:

Udfas den. Nogle integrationer findes kun, fordi ingen har slukket dem.
Opdatér den. Leverandørprodukter får en opgradering fra leverandøren. Aftal datoen nu.
Omskriv den mod Microsoft Graph. Standardsvaret for egenudviklet kode.
Design den om. For alt, der afhænger af en funktion, Graph aldrig får (se nedenfor).

Microsoft nævner også Power Platform som en måde at genimplementere et workflow på. For et script, der videresender vedhæftede filer til en mappe, kan det være det billigste svar.

Hvad en omskrivning til Graph faktisk indebærer

De fleste EWS-handlinger har et direkte modstykke i Graph, og Microsoft vedligeholder en mapping fra EWS til Graph. Mappingen er den lette del. De sværere dele er dem, den ikke viser.

Rettighederne bliver snævrere, og det er en fordel

En app, der bruger EWS uden en indlogget bruger, har EWS-applikationsrettigheden, som Microsoft beskriver som »fuld adgang til alle postkasser«. Graph deler den op i separate rettigheder: Mail.Read, Mail.ReadBasic, Mail.Send, Calendars.ReadWrite, MailboxSettings.Read og så videre.

I kan også begrænse, hvilke postkasser en app når. RBAC for Applications i Exchange Online tildeler en rettighed mod et administrationsområde (management scope) eller en administrativ enhed, og den erstatter de ældre Application Access Policies. En skærm til booking af lokaler kan læse kalenderne for tolv lokalepostkasser og intet andet. Én fælde: tildelinger lavet på den måde lægges oven i en eventuel lejerdækkende tildeling i Microsoft Entra, så er Mail.Read stadig godkendt dér, begrænser jeres afgrænsning ingenting. Fjern tildelingen i Entra.

Brug certifikater frem for klienthemmeligheder til appens autentificering, hvor I kan, og hold legitimationsoplysninger ude af scripts og kodearkiver.

Synkronisering og notifikationer bygges om, de oversættes ikke

Det er som regel den største ændring for alt, der holder en lokal kopi af postkassedata.

Synkronisering. SyncFolderItems svarer til Graphs delta query for beskeder, og SyncFolderHierarchy til delta query for mailmapper. Delta for beskeder virker én mappe ad gangen, så en fuld synkronisering af en postkasse kræver, at I følger mappetræet og gemmer et separat deltalink pr. mappe. Filtrering er begrænset (kun på modtagelsesdato), og resultaterne omfatter sletninger, flytninger ud af mappen og ændringer i læst-status, også når de ikke matcher jeres filter.

Notifikationer. Streaming- og push-abonnementer i EWS bliver til change notifications i Graph, leveret til en webhook, I selv driver, eller til Azure Event Hubs eller Event Grid. En webhook skal kunne nås fra Microsofts side, og det er en arkitekturændring for et script, der før holdt en forbindelse åben bag firewallen. Abonnementer for mail, kalender og kontakter varer højst 10.080 minutter (lige under syv dage) eller 1.440 minutter, når notifikationen bærer data, så noget skal forny dem. Hver postkasse tillader højst 1.000 aktive abonnementer på tværs af alle applikationer.

Det mønster, der holder: behandl en notifikation som et hint, kør delta query for at se, hvad der er ændret, og kør den også på en timer for at fange det, som en mistet notifikation ellers ville have tabt.

Data, id'er og kapacitet

Gemte id'er. Har jeres CRM- eller ticketsystem gemt EWS-element-id'er for at koble e-mails til poster, skal de koblinger konverteres. Graph har funktionen translateExchangeIds til netop det. Planlæg konverteringen som et selvstændigt migreringstrin.
Opslag. ResolveNames svarer til People API, GetUserAvailability til getSchedule og fraværsindstillinger til postkasseindstillinger. Nære modstykker, ikke identiske.
Throttling. Graph begrænser hvert par af app og postkasse til 10.000 anmodninger pr. 10 minutter, fire samtidige anmodninger og 150 MB upload pr. 5 minutter. Et massejob, der kørte snesevis af parallelle EWS-tråde mod én postkasse, skal designes om omkring de tal.

Hullerne, og det der aldrig kommer

Microsoft offentliggør en køreplan over EWS-funktioner, der stadig mangler i Graph. Den omfatter import og eksport i fuld kvalitet for arkiv-, offentlige mappe- og gruppepostkasser, adgang til in-place-arkiver, mapperettigheder via Exchange Admin API og oprettelse af beskeder, der ikke er kladder, ud fra MIME. De fleste mål ligger i fjerde kvartal 2026. Nogle få skulle være kommet i tredje kvartal, som nu er slut, så tjek, hvad der faktisk er leveret, før I designer omkring det. Microsofts egen advarsel: står en funktion ikke på køreplanen, skal I »ikke regne med« et modstykke i Graph, før EWS slukkes.

Tre funktioner er bekræftet til aldrig at komme til Graph:

Generel adgang til offentlige mapper (oprettelse, læsning, opdatering og sletning af mapper og elementer).
Generel adgang til postkasser for Microsoft 365-grupper. Graph dækker i stedet gruppesamtaler, tråde og indlæg.
Adgang til discovery-postkasser. Microsoft henviser i stedet til Purview eDiscovery.

Afhænger et værktøj af en af dem, er det ikke nok at portere koden: data eller workflowet skal først flyttes et andet sted hen, og det tager længere tid end en omskrivning.

En plan på seks måneder

Fra i dag til 1. april 2027 er der lige under seks måneder. En realistisk rækkefølge:

Oktober 2026: se, hvor I står. Tjek EWSEnabled og tilladelseslisten. Eksportér 90 dage af forbrugsrapporten. Gennemgå den liste, Microsoft har udfyldt, fjern det, der ikke skal være der, og tilføj de sjældne job, I kender til. Står jeres lejer stadig på Null, så overvej selv at oprette listen og sætte True i stedet for at vente på Microsofts skift til False og finde ud af, hvad der går i stykker.

November 2026: prioritering. Giv hvert applikations-id en ejer og et svar (udfas, opdatér, omskriv, design om). Scan koden. Markér alt, der rører offentlige mapper, gruppepostkasser eller discovery-postkasser, og start omdesignet nu. Opret appregistreringerne i Graph med afgrænsede rettigheder.

December 2026 til januar 2027: udvikling. Start med den integration, forretningen først ville savne. Byg rørføringen til synkronisering og notifikationer én gang, og genbrug den. Konvertér gemte id'er.

Februar 2027: kør begge side om side. Mens EWS stadig virker, så kør gammel og ny version mod de samme postkasser, og sammenlign outputtet. Efterhånden som hver enkelt godkendes, fjernes dens id fra tilladelseslisten. Det er også testen: vent de 24 timer, og bekræft, at intet andet er holdt op med at virke.

Marts 2027: sluk selv for EWS. Sæt EWSEnabled til False i god tid før 1. april. Alt, hvad I har overset, fejler, mens I stadig kan slå EWS til igen. Efter 1. april er den mulighed væk. Giv også kvartals- og årsjob en bevidst testkørsel inden da: et job, der kører, når første kvartal lukkes, vil køre for første gang efter, at EWS er væk.

Hvor I kan få hjælp

Det svære tilfælde er integrationen, hvis oprindelige udvikler er væk. Vores service til vedligeholdelse af ældre systemer er bygget til det: vi læser den eksisterende kode, omskriver EWS-delene mod Microsoft Graph (rettigheder, synkronisering, notifikationer, migrering af id'er) og kører gammelt og nyt side om side, indtil tallene stemmer. Har I i stedet brug for ingeniører, der arbejder i jeres eget team, så se vores service til teamforstærkning.

Er jeres forbrugsrapport fuld af applikations-id'er, som ingen genkender, så skriv til office@c9group.dev.