EWS forsvinner fra Exchange Online 1. april 2027: slik flytter du integrasjonene til Microsoft Graph

Microsoft har begynt å slå av Exchange Web Services (EWS) i Exchange Online. De første håndhevingstrinnene kjøres denne måneden, leiere (tenants) som aldri har rørt EWS-innstillingene sine, slås av én etter én etter det, og fra 1. april 2027 er EWS borte for alle Microsoft 365-leiere. Microsoft har sagt rett ut at det blir ingen unntak etter april 2027.

Snakker noe selskapet ditt har bygget, med Microsoft 365-postbokser over EWS, slutter det å virke senest på den datoen, og muligens mye tidligere. De vanlige mistenkte: et CRM-system som arkiverer kunde-e-poster mot kontoer, et arkiverings- eller oppbevaringsskript, en skjerm for booking av møterom, et sakssystem som leser en delt supportpostboks, en rapportjobb som teller e-poster per team. Løsningen er å skrive det om mot Microsoft Graph, og noe av det EWS kunne gjøre, har ingen motsvarighet i Graph i det hele tatt.

Hva som skjer, dato for dato

Microsoft styrer EWS per leier gjennom innstillingen EWSEnabled, som har tre verdier: Null (standard), True og False. Ved siden av den finnes det nå en innstilling til, EWSAllowedAppIDs: en liste over applikasjons-ID-er som fortsatt kan bruke EWS. Den gjeldende siden på Microsoft Learn gir hovedlinjene: «Oktober 2026: EWS begynner å bli deaktivert globalt for alle organisasjoner» og «April 2027: EWS er fullstendig deaktivert.»

Detaljene står i Exchange-teamets innlegg av 1. oktober, EWS Deprecation Is Here. For den globale kommersielle skyen:

• 2. oktober 2026, ved dagens slutt etter stillehavstid (Pacific Time): Microsoft registrerer hver leier som har EWSEnabled satt til True, men ingen tillatelsesliste.
• 8. og 9. oktober 2026: for disse leierne oppretter Microsoft tillatelseslisten og fyller den med applikasjons-ID-ene som brukte EWS de foregående 60 dagene.
• Fra 10. oktober 2026: når EWSEnabled er True, er tillatelseslisten påkrevd. En app som ikke står på den, blir avvist.
• Andre fase, deretter: leiere som fortsatt står på Null, får EWSEnabled satt til False, som blokkerer EWS for alle applikasjoner. Hver av dem får et varsel sju dager i forveien i Message Center, og Microsoft fyller en tillatelsesliste ut fra 60 dagers bruk kort tid før, slik at en administrator kan slå EWS på igjen med True.
• 1. april 2027: EWS er «fullstendig og permanent deaktivert», og administratorer for leiere mister muligheten til å endre EWSEnabled i det hele tatt.

Leiere i Microsofts andre skyer får egne tidslinjer gjennom Message Center.

Tillatelseslisten kjøper tid, ikke en løsning

Den automatiske listen bygges ut fra 60 dagers trafikk, og Microsofts egen veiledning av 4. september advarer om at den «kan gå glipp av applikasjoner som kjører sjelden». En eksport ved kvartalsslutt eller en arkiveringsjobb ved årsslutt vil ikke stå på den, og vil feile neste gang den kjører.

Endringer i tillatelseslisten tar 24 timer før de trer i kraft, og endringer i EWSEnabled tar omtrent en time. Enhver rettelse du gjør etter en feil, koster minst ett døgn.

For å se hvor leieren din står, kan en administrator med Exchange Online PowerShell kjøre:

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

Hvem dette er for, og hvem som kan slutte å lese

Lokal Exchange Server berøres ikke. Microsoft sier at utfasingen gjelder «bare Microsoft 365 og Exchange Online», og at «det blir ingen endringer i EWS i Exchange Server». Ligger alle postboksene deres på egne servere, kan du stoppe her.

Hybridoppsett må undersøkes nærmere. Lokale postbokser kan fortsette å bruke EWS; postbokser i skyen må over på Graph. Microsofts innlegg om hybrid av 30. september dekker to tilfeller som krever handling nå, blant annet lokale postbokser med arkiv i Exchange Online, der rådet foreløpig er å la EWS være aktivert og sette hybridapplikasjonen på tillatelseslisten.

Standardprogramvare er leverandørens jobb. Er det som kaller EWS, et kommersielt produkt, er det leverandørens jobb å levere en Graph-versjon, og din jobb å få en dato fra dem og installere oppdateringen. Microsofts egne klienter er ikke annerledes: noen dukker fortsatt opp i bruksrapportene og trenger tillatelseslisten til de er oppdatert.

Egenutviklet kode er din jobb. Skript, interne tjenester, tilpassede verktøy med åpen kildekode og integrasjoner et byrå bygget for mange år siden, har ingen oppstrøms som retter dem. Det er der arbeidet ligger. Som en pekepinn på omfanget: exchangelib, et Python-bibliotek for å snakke med Exchange over EWS, ble lastet ned 1 174 625 ganger fra PyPI den siste måneden. Noe av det er lokal bruk, men det gir et inntrykk av hvor mye kode som snakker EWS direkte.

Trinn én: finn alt som bruker EWS

Start med EWS-bruksrapporten i administrasjonssenteret for Microsoft 365 (Reports, Usage, Exchange og deretter fanen EWS usage). For hver applikasjon viser den applikasjons-ID-en i Microsoft Entra, hver SOAP-handling applikasjonen har kalt, kallvolumet og datoen for siste aktivitet. Du kan se 7, 30 eller 90 dager tilbake og eksportere til CSV.

Tre ting du bør vite om den:

• Dataene aggregeres ukentlig og kan bruke opptil 10 dager på å dukke opp.
• En applikasjons-ID er ikke en eier. Match hver ID mot Enterprise applications i Microsoft Entra, og finn deretter personen eller teamet som drifter den. Regn med noen ID-er ingen kjenner igjen.
• Kolonnen med SOAP-handlinger forteller hvor stor hver jobb er. En app som bare kaller FindItem og GetItem, er en kort jobb. En som kaller SyncFolderItems, Subscribe og ExportItems, er et prosjekt.

Selv 90 dager går glipp av årlige jobber, så sjekk den andre siden også: planlagte oppgaver og cron-oppføringer, og kodelagre gjennomsøkt etter EWS-endepunktet (Exchange.asmx), EWS Managed API for .NET og exchangelib. Microsofts side om utfasingen lenker også til en EWS-analysator for .NET-kode (den flagger EWS-kall i Visual Studio og VS Code og foreslår motsvarigheter i Graph) og en veiledning i KI-assistert refaktorering.

Trinn to: bestem hva hver integrasjon skal bli

Hver applikasjon på listen får ett av fire svar:

1. Avvikle den. Noen integrasjoner finnes bare fordi ingen slo dem av.
2. Oppdatere den. Leverandørprodukter får en oppgradering fra leverandøren. Avtal datoen nå.
3. Skrive den om mot Microsoft Graph. Standardsvaret for egenutviklet kode.
4. Designe den på nytt. For alt som er avhengig av en funksjon Graph aldri kommer til å få (se nedenfor).

Microsoft oppgir også Power Platform som en måte å implementere en arbeidsflyt på nytt. For et skript som videresender vedlegg til en mappe, kan det være det billigste svaret.

Hva en omskriving til Graph faktisk innebærer

De fleste EWS-operasjoner har en direkte motsvarighet i Graph, og Microsoft vedlikeholder en kobling fra EWS til Graph. Koblingen er den enkle delen. De vanskeligere delene er dem den ikke viser.

Tillatelsene blir smalere, og det er en fordel

En app som bruker EWS uten en innlogget bruker, har EWS-applikasjonstillatelsen, som Microsoft beskriver som «full tilgang til alle postbokser». Graph deler den opp i separate tillatelser: Mail.Read, Mail.ReadBasic, Mail.Send, Calendars.ReadWrite, MailboxSettings.Read og så videre.

Du kan også begrense hvilke postbokser en app når. RBAC for Applications i Exchange Online tildeler en tillatelse mot et administrasjonsomfang eller en administrativ enhet, og erstatter de eldre Application Access Policies. En skjerm for møteromsbooking kan lese kalenderne til tolv rompostbokser og ingenting annet. Én felle: tillatelser gitt på denne måten legges til en eventuell tillatelse for hele leieren i Microsoft Entra, så er Mail.Read fortsatt godkjent der, begrenser omfanget ditt ingenting. Fjern tildelingen i Entra.

Bruk sertifikater i stedet for klienthemmeligheter for autentisering av apper der du kan, og hold legitimasjon unna skript og kodelagre.

Synkronisering og varsler bygges på nytt, de oversettes ikke

Dette er som regel den største endringen for alt som holder en lokal kopi av postboksdata.

Synkronisering. SyncFolderItems tilsvarer delta-spørringen for meldinger i Graph, og SyncFolderHierarchy delta-spørringen for e-postmapper. Delta for meldinger fungerer én mappe om gangen, så en full synkronisering av en postboks betyr å følge mappetreet og lagre en egen delta-lenke per mappe. Filtreringen er begrenset (bare på mottaksdato), og resultatene omfatter slettinger, flyttinger ut av mappen og endringer i lest-status, selv når de ikke samsvarer med filteret ditt.

Varsler. Strømmings- og push-abonnementer i EWS blir endringsvarsler i Graph, levert til en webhook du drifter, eller til Azure Event Hubs eller Event Grid. En webhook må kunne nås fra Microsofts side, og det er en arkitekturendring for et skript som pleide å holde en forbindelse åpen bak brannmuren. Abonnementer for e-post, kalender og kontakter varer i høyst 10 080 minutter (litt under sju dager), eller 1 440 minutter når varselet inneholder dataene, så noe må fornye dem. Hver postboks tillater høyst 1 000 aktive abonnementer på tvers av alle applikasjoner.

Mønsteret som holder: behandle et varsel som et hint, kjør delta-spørringen for å se hva som er endret, og kjør den også på en timer for å fange opp det et tapt varsel ville ha mistet.

Data, ID-er og kapasitet

• Lagrede ID-er. Har CRM- eller sakssystemet ditt lagret EWS-element-ID-er for å koble e-poster til poster, må de koblingene konverteres. Graph har funksjonen translateExchangeIds nettopp for dette. Planlegg konverteringen som et eget migreringstrinn.
• Oppslag. ResolveNames tilsvarer People API, GetUserAvailability tilsvarer getSchedule, fraværsinnstillinger tilsvarer postboksinnstillinger. Nære motsvarigheter, ikke identiske.
• Struping. Graph begrenser hvert par av app og postboks til 10 000 forespørsler per 10 minutter, fire samtidige forespørsler og 150 MB opplasting per 5 minutter. En massejobb som kjørte dusinvis av parallelle EWS-tråder mot én postboks, må designes på nytt rundt de tallene.

Hullene, og det som aldri kommer

Microsoft publiserer et veikart over EWS-funksjoner som fortsatt mangler i Graph. Det omfatter fullverdig import og eksport for arkivpostbokser, offentlige mapper og gruppepostbokser, tilgang til in-place-arkiver, mappetillatelser gjennom Exchange Admin API og oppretting av meldinger som ikke er utkast, fra MIME. De fleste målene er fjerde kvartal 2026. Noen få skulle komme i tredje kvartal, som nå er over, så sjekk hva som faktisk er levert før du designer rundt det. Microsofts egen advarsel: står en funksjon ikke på veikartet, bør du «ikke planlegge med» en motsvarighet i Graph før EWS slås av.

Microsoft har bekreftet at tre funksjoner aldri kommer til Graph:

• Generell tilgang til offentlige mapper (opprette, lese, oppdatere og slette mapper og elementer).
• Generell tilgang til postbokser for Microsoft 365-grupper. Graph dekker i stedet gruppesamtaler, tråder og innlegg.
• Tilgang til discovery-postbokser. Microsoft viser i stedet til Purview eDiscovery.

Er et verktøy avhengig av én av disse, er det ikke nok å portere koden: dataene eller arbeidsflyten må flyttes et annet sted først, og det tar lengre tid enn en omskriving.

En plan over seks måneder

Fra i dag til 1. april 2027 er det litt under seks måneder. En realistisk rekkefølge:

Oktober 2026: se hvor du står. Sjekk EWSEnabled og tillatelseslisten. Eksporter 90 dager av bruksrapporten. Gå gjennom listen Microsoft fylte ut, fjern det som ikke skal være der, og legg til de sjeldne jobbene du vet om. Står leieren din fortsatt på Null, vurder å sette listen og True selv i stedet for å vente på at Microsoft setter False og så finne ut hva som slutter å virke.

November 2026: prioriter. Gi hver applikasjons-ID en eier og et svar (avvikle, oppdatere, skrive om, designe på nytt). Skann koden. Flagg alt som berører offentlige mapper, gruppepostbokser eller discovery-postbokser, og start redesignet nå. Opprett appregistreringene i Graph med avgrensede tillatelser.

Desember 2026 til januar 2027: utvikling. Start med integrasjonen virksomheten ville savnet først. Bygg rørleggerarbeidet for synkronisering og varsler én gang og gjenbruk det. Konverter lagrede ID-er.

Februar 2027: kjør begge side om side. Mens EWS fortsatt virker, kjør gammel og ny versjon mot de samme postboksene og sammenlign resultatet. Etter hvert som hver av dem godkjennes, fjern ID-en fra tillatelseslisten. Det er også testen: vent de 24 timene og bekreft at ingenting annet stoppet.

Mars 2027: slå av EWS selv. Sett EWSEnabled til False god tid før 1. april. Alt du har oversett, feiler mens du fortsatt kan slå EWS på igjen. Etter 1. april er den muligheten borte. Gi også kvartals- og årsjobber en bevisst testkjøring før det: en jobb som kjører når første kvartal avsluttes, vil kjøre for første gang etter at EWS er borte.

Hvor du får hjelp

Det vanskelige tilfellet er integrasjonen der den opprinnelige utvikleren har gått. Vår tjeneste for vedlikehold av eldre systemer er laget for nettopp det: vi leser den eksisterende koden, skriver om EWS-delene mot Microsoft Graph (tillatelser, synkronisering, varsler, migrering av ID-er) og kjører gammelt og nytt side om side til tallene stemmer. Trenger du i stedet utviklere som jobber inne i ditt eget team, se vår tjeneste for teamforsterkning.

Er bruksrapporten din full av applikasjons-ID-er ingen kjenner igjen, skriv til office@c9group.dev.